Puppet

Puppet is a multi-platform configuration management service that is meant to take the place of CFEngine. There is a Puppet Master which controls the OS configuration of the Agent Nodes. When the Puppet Agent runs on a client system, a catalog of information about the client is sent to the Master. The Master interprets the catalog and uses the information to decide what configuration classes (in the form of Puppet code/scripts) should be applied to the client. These classes are then sent back to the client, which executes the Puppet code.

Common Tasks

See the main article on Fixing Certificates

Run the Agent

Running puppet agent manually from a client host. This will generate a certificate request if a cert does not already exist:

root@agent# puppet agent -t

List pending certificate requests from the Master

[root@coresrv04 puppetlabs]# puppet cert list
  "aft.cs.virginia.edu"          (SHA256) 5F:EC:21:2B:A2:F9:E8:BB:DB:22:F2:E8:E0:C3:89:4F:4B:55:37:C0:68
  "ai0.cs.virginia.edu"          (SHA256) E1:D5:F2:70:45:43:AA:01:03:0D:7F:B2:8D:B3:FF:85:20:4A:71:AA:7D
  "ai01.cs.virginia.edu"         (SHA256) 7D:E9:49:C6:E7:19:5F:6F:8D:5F:2A:2F:36:AA:03:0E:78:EB:36:B4:E0
  "ai02.cs.virginia.edu"         (SHA256) 8B:B2:93:B0:CF:8B:70:B6:DF:17:4C:AB:F6:C0:85:D2:53:BF:E4:85:7E

List all certs, both approved and pending

[root@coresrv04 puppetlabs]# puppet cert list -a

Sign a pending cert request from the Master

[root@coresrv04 puppetlabs]# puppet cert sign kurma.cs.virginia.edu

Clean or revoke a certificate form the Master

[root@coresrv04 puppetlabs]# puppet cert clean kurma.cs.virginia.edu

Issue/re-issue cert for client

[root@coresrv04 puppetlabs]# bash /sw/pkgs/scripts/puppet/puppet-reissue-cert.sh

Package Details

The way to get the latest Puppet packages is through the Puppet Collections repositories. For Red Hat based Linux distributions we can add the official repository using yum:

# yum localinstall http://yum.puppetlabs.com/puppetlabs-release-pc1-el-7.noarch.rpm

And for Debian/Ubuntu systems we can add the repository using dpkg to install the repos:

# wget https://apt.puppetlabs.com/puppetlabs-release-pc1-xenial.deb
# sudo dpkg -i puppetlabs-release-pc1-xenial.deb

The Puppet Collections packages install the binary distribution to /opt/puppetlabs and the configuration files to /etc/puppetlabs. The Client/Agent config is found in /etc/puppetlabs/puppet and the Puppet Master server config located in /etc/puppetlabs/puppetserver

Config Files

/etc/puppetlabs/puppet/puppet.conf	puppet.conf is where the main agent configuration is kept. The agent configuration is marked by the tag [main]. This section should include the Master node, set with the line `server=coresrv04.cs...`. The Master node has an additional [master] section.
/etc/puppetlabs/puppet/autosign.conf	autosign.conf is used to tell the Master to auto-accept certificate requests from certain hosts. The hostname of an Agent node is placed in this file and any subsequent cert requests will be approved automatically. This mechanism will be used to automate certificate management so certificates don't need to be manually approved.
/etc/puppetlabs/puppet/code/environments/{env-name}/environment.conf	Module Environment configuration. Environments can contain a unique modulepath and default manifest which can be declared here.

Puppet Master

The server coresrv04 acts as our Puppet Master. In a Puppet environment, it is standard practice for the Master node to also act as a client. The master also hosts the Module code that does the actual work of configuring a node. Modules are stored under /etc/puppetlabs/code.

Host Certificates

The first step in setting up the relationship between the Master and Clients involves certificates. Dialog between the Master and Clients is encrypted for security reasons. This encryption is done with identity certificates, similar to ssh keys. The first time the Puppet Agent is run on a Client a set of certificates is generated. This certificate is sent to the Master for approval. Once approved, the Master will use this cert to ensure the identity of the Client. If the certificate changes (which happens when the OS on a client is reinstalled) the Master will refuse to serve to the Client. For this reason we need to clean the old certificate and re-approve after an OS reinstall.

Modules & Development

See Main Article on Puppet Development.

Puppet Modules contain the actual code that is executed by the Puppet Agent. Modules code can be found in /etc/puppetlabs/code on the Puppet Master.

Here is some example Puppet code:

class motd {
  node 'applecake.cs.virginia.edu' {
    file { '/etc/motd':
      ensure      => present,
      source      => 'puppet:///modules/motd/motd-applecake'
    }
 
  }
 
  file { '/etc/motd':
    ensure      => present,
    source      => 'puppet:///modules/motd/motd'
  }
 
}

Environments

Inside /etc/puppetlabs/code there are several module environments. The idea behind environments is to allow us to isolate node groups which can be used for different purposes. For example, we can create a testing environment that would only be applied to a specific group of nodes. This is useful for module development. Environments can also in situations where you want different versions of the same code to apply to different node groups. If we have a cluster that needs to be configured in a fundamentally different way from our standard systems, we can create an environment specifically for that cluster with custom code to do what is needed.

The default environment for a node is defined in the [main] section of puppet.conf.

Table of Contents