Provisioning Puppet

08 May 2006

A configuration management tool like [Puppet]( ensures that the local configuration of a machine agrees with its configuration stored on a central server, and makes it possible to install packages, change configuration files, start and stop services etc. by editing the puppet manifest on the central server. But before you can enjoy changing configurations of many machines from one central server, you need to solve the chicken-and-egg problem of getting the puppet client on the machine in the first place: since puppet is not in any of the Linux distributions (yet), you need a way to get the puppet client installed and configured through your distribution's provisioning mechanism. In particular, there are three big things you need to integrate into provisioning to enable puppet: (1) Installation of the puppet packages, (2) distribution of the SSL certificates for puppet's client/server communication, and (3) telling the client the name of the puppet server puppetmaster

For RHEL and Fedora Core, the puppet packages can be installed during kickstart of a machine by adding a %post section to the kickstart file:

  CONF=`mktemp -t puppet.conf.XXXXXX`
  /usr/bin/wget -O $CONF
  # It should be possible to pass the URL directly to yum,
  # but when I tried it, it died because of a bug
  /usr/bin/yum -y -c $CONF install puppet
  chkconfig --level 345 puppet on

Initially, I wanted to do the first puppet run from the %post section, too, but that fails since anaconda does not set the hostname, and the puppetmaster will not recognize the client localhost.localdomain. There is little lost by waiting with the initial puppet run until the first full boot of the machine; if that poses a problem, you need to determine and set the hostname of the client in the %post section before running the client for the first time with /etc/init.d/puppet once

Puppet uses SSL certificates to authenticate clients. There are two ways to automate the provisioning of certificates: autosigning and pregenerating certificates. The easier of the two is [autosigning](, though it has the drawback that you need to delete an existing client certificate with puppetca --clean HOST before the client checks in for the first time. This can become annoying if you are going to reprovision HOST frequently

If you are just a little paranoid about security, it is much better to generate the certificates on the puppetmaster ahead of time using puppetca --generate HOST and then copy the generated files onto the client during kickstart. To be exact, you need to copy the following files from the puppetmaster to the client (all paths are relative to /var/lib/puppet/ssl on the appropriate machine):

  Puppetmaster          Client HOST
  certs/ca.pem          certs/ca.pem
  certs/HOST.pem        certs/HOST.pem
  private_keys/HOST.pem private_keys/HOST.pem
  signed/HOST.pem       public_keys/HOST.pem

A final impediment to completely automated management with puppet is the name of the puppetmaster server that a client should connect to: by default, the puppet client tries to connect to a server called puppet. If possible, that name should be added as a CNAME for the machine running the puppetmaster. If that is not possible, the kickstart file also needs to copy a custom /etc/puppet/puppetd.conf to the client, with the server entry in the puppetd section set to the name of the appropriate machine.

With all these things in place, provisioning a new machine with puppet installed, configured and running should be painless and easy

Creative Commons License Watzmann.Blog by David Lutterkort is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Generated with Jekyll