Puppet: The Good, The Bad, And The Config – Part 2

In the previous post we went over some wordy basics of Puppet along with some quick tips. In this post we’ll actually get to the install.

Worth note, I use RHEL (well, a clone: Scientific Linux) but I’m confident that the RH specific bits are easy to translate to another distro, it’s the config that’s more important.

Yum Repos

Add the puppet repos to both client and server (I do this in the kickstart of the machines). The official repos are here. I chose http://yum.puppetlabs.com/el/6/products/x86_64/ and http://yum.puppetlabs.com/el/6/dependencies/x86_64/ because I’m on RHEL6. I believe you’ll also need EPEL for some dependencies but I’m not totally sure of this since I had it anyway (if you’re running RHEL, you’ll almost certainly want it).

Yum Install

Install puppet on both the clients and on the master (your master should be one of the clients, it needs to stay in line just as much if not more than every other client). There’s no need to install puppet-server because we’re not going to use their server, we’re going to use Apache/Passenger.

Both clients and server:

yum install puppet

Config

Puppet config is in /etc/puppet/puppet.conf. My config looks like this both on master and client (substitute DOMAIN for your domain, also, my server host is called puppet1, if yours is different, substitute that too):

[main]
    # The Puppet log directory.
    # The default value is '$vardir/log'.
    logdir = /var/log/puppet
 
    # Where Puppet PID files are kept.
    # The default value is '$vardir/run'.
    rundir = /var/run/puppet
 
    # Where SSL certificates are kept.
    # The default value is '/ssl'.
    ssldir = /ssl
 
    moduledir = /etc/puppet/modules
    server = puppet1.DOMAIN
    pluginsync = true
 
[agent]
    # The file in which puppetd stores a list of the classes
    # associated with the retrieved configuratiion.  Can be loaded in
    # the separate ``puppet`` executable using the ``--loadclasses``
    # option.
    # The default value is '$confdir/classes.txt'.
    classfile = $vardir/classes.txt
 
    # Where puppetd caches the local configuration.  An
    # extension indicating the cache format is added automatically.
    # The default value is '$confdir/localconfig'.
    localconfig = $vardir/localconfig
 
[master]
    certname = puppet1.DOMAIN

The changes to the default are the moduledir, server, pluginsync and certname parameters. moduledir and pluginsync we’ll get to later, server is so clients know where to go, and certname clearly defines the name of the puppet master server for certificate generation. I’ve had to use this because the server I’m using has a fairly random name and is CNAMEd to puppet1. Had I not provided certname, it would have used the machine’s real hostname.

Auto-signing

We’ve gone with auto-signing of client certificates. There are lots of reasons to be careful when doing this, explained here but after weighing the options, we’ve decided to go ahead with it, so on the master we’ve created /etc/puppet/autosign.conf which looks like this:

*.DOMAIN

Basic Puppet Module Config

On the master, create /etc/puppet/manifests/site.pp with the following content:

$puppetserver = 'puppet1.DOMAIN'
 
node default {
}

Certificate Generation

Run the following command on the puppet master to generate the server-side certificates.

sudo puppet master --no-daemonize --verbose

Once it’s done with the initial generation and has started the server, kill it with Ctrl-C.

Next Steps

Now, I know no client runs have actually been done yet; that’s in Part 3, where Apache/Passenger will be set up as the server so as not to use Puppet’s built in WEBrick (it doesn’t scale).