This section covers the steps you need to provision a host quickly and easily, without diving into the gory details.
The easiest way to get started is to use the provided NCSU puppet roles and profiles. With these you can quickly create a system that will use Wolftech for authentication and have access to campus AFS resources.
Write your own Puppet classes
If you want to jump straight in see Starting with Puppet for information about how to configure your workstation to work with Puppet.
Roles, Profiles, and Repos
To simplify the management of large number of hosts, you classify hosts into “roles.” A Role can describe a single system, for example, “Library Master Database Server” or many systems, for example “ECE Graduate Student Loaner Chromebooks.” Both Roles and Profiles are implemented as Puppet Classes, and are stored in git repos.
Profiles perform apply specific configurations to a box. For example we have a profile that configure authentication sources. Another installs the afs client. A role will call any number of profiles to configure the machine to meet the role requirements.
ncsu:: class is a parent class, owned by the campus and supported by the
RLSC/OIT/Other? that contains roles and profiles tested and recommended for
general use on campus. It’s kept in a github.ncsu.edu repo named
“Supported” means that if you encounter a bug or have a problem implementing
a class in the
ncsu:: name-space on a supported operating system you can get assistance using the
LINUX workgroup in ServiceNow. We intend this class to be
reliable and trustworthy for all who use it.
If you prefer and have the in-house expertise, you can set up your own Puppet Control Repo, and ignore the classes here.
The NCSU class is already available on the Foreman server. If you wish to build a box using only the
ncsu:: class you can do that immediately. See the Foreman docs for more detail.
Your organizations class
Your organization also has at least one git repo that you control for your
own roles and profiles. If OIT hosts your repo, it generally has the name
YourOrg_puppet and it has been populated with a directory structure to
help you get started.
Unless you are managing your own Puppet Control repo, your organizations repo is tied in to the campus Puppet Master server(s) so that whenever you change the git repo, it automatically updates the Puppet Masters.
Puppet environments map directly to branches within git. This allows us to test code without impacting production. We support several pre-built puppet environments with Foreman.
- Production: Any code committed to this branch will be deployed into production.
- NCSU-Test: This environment allows you to test your Puppet code against the most recent proposed changes to the production environment.
- ForgeLatest: This branch allows you to test your puppet code against the latest module changes from the Forge. The list of modules in this environment is copied daily from the Production environment.
Hiera is where we will store data to be used by Puppet when building systems. For example we use hiera to store the names of AD groups we want to have access to our systems.Edit me