Provisioning Puppet
A configuration management tool like [Puppet](http://reductivelabs.com/projects/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:
%post CONF=`mktemp -t puppet.conf.XXXXXX` /usr/bin/wget -O $CONF http://boot.example.com/yum-puppet.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](http://reductivelabs.com/projects/puppet/documentation/security), 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
Watzmann.Blog by David Lutterkort is licensed under
a Creative Commons Attribution-Share Alike 3.0
United States License.
Generated with Jekyll