Tag: puppet

In the previous post the basic setup of puppet on both the server and client was described, but, because I’d rather not use their built in server (scalability issues) it’s still left to install Passenger on Apache to handle the server side of things. Details are below…

Passenger Repo and Installs

The Puppet docs suggest you use rubygem to install Passenger. Personally I prefer if everything goes in with yum to keep it all handled by one package manager. Since Passenger isn’t in any of the usual repos, add this one then install the necessary bits and pieces.

yum install httpd mod_ssl mod_passenger rubygem-rake rubygem-rack ruby-rdoc

The httpd/rack Config

First, set up a DocumentRoot for the Ruby/Rack bits and copy the config into it.

mkdir -p /etc/puppet/rack/public /etc/puppet/rack/tmp
cp /usr/share/puppet/ext/rack/files/config.ru /etc/puppet/rack/.

Create an httpd configuration for the puppetmaster. It uses mod_passenger to run the Puppet server through the more scalable Apache backend. If your network is very large, you may need to run more than one and reverse proxy them, but I’ll leave that for you to Google for if needed. Otherwise, it’ll look like this:

PassengerHighPerformance on
PassengerMaxPoolSize 15
PassengerPoolIdleTime 300
PassengerStatThrottleRate 120
PassengerUseGlobalQueue on
 
Listen 8140
 
<VirtualHost *:8140>
        SSLEngine on
        SSLProtocol -ALL +SSLv3 +TLSv1
        SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
 
        SSLCertificateFile      /ssl/certs/puppet1.DOMAIN.pem
        SSLCertificateKeyFile   /ssl/private_keys/puppet1.DOMAIN.pem
        SSLCertificateChainFile /ssl/ca/ca_crt.pem
        SSLCACertificateFile    /ssl/ca/ca_crt.pem
        SSLCARevocationFile     /ssl/ca/ca_crl.pem
        SSLVerifyClient optional
        SSLVerifyDepth  1
        SSLOptions +StdEnvVars
 
        RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
        RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
        RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e
 
        DocumentRoot /etc/puppet/rack/public/
        RackBaseURI /
        <Directory /etc/puppet/rack/>
                Options None
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>
</VirtualHost>

Once that’s all in place, start httpd and make sure it starts at boot:

/etc/init.d/httpd start
chkconfig httpd on

A Test Run

Now that we’ve got a working Puppet server, we should be able to test it from the client. Run the following as root:

puppet agent --test

This should do a run, but because our default node setup is empty, won’t actually do anything.

Next Steps

I know this was a short one, but the next bit is setting up Dashboard, which is a bit more involved. Once that’s done, finally we can get to actually using Puppet for what it’s intended: managing hosts’ state.

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).

I work for a large visual effects company and manage a decent sized network of machines (a few hundred Linux, Mac and Windows workstations, a few hundred headless render nodes and tens of servers). A configuration management system is obviously crucial and I’d been using cfengine2.

Recently several friends at other facilities had started singing the praises of Puppet and since I was reviewing our cfengine install anyway, I took a look. First impressions were not good. Puppet seems to leak (two links) and their own website tells you not to use their built-in webserver for more than 10 machines (link) which seems a bit crazy since you’ve got to figure that the majority of people looking for a system like this will have more than that.

Now you can stump for Puppet Enterprise where they apparently wrap it all up and make it easy for you along with packaging the nice web-UI bits. If you’ve got the budget, great, we went with the do-it-yourself option.

All that said, the syntax and concepts are really nice and its failings seem easy to work around, so I figured we should try setting it up and having a go. Here are some tips:

• Use the Puppet repos rather than those supplied with your distro. They’re the official, supported repos and will be up-to-date.
• Go straight for Passenger setups backed by Apache. Why set yourself up for failure by using the server they tell you won’t scale? (benchmarks)
• Install Puppet Dashboard – It’s a faff to get it working, but worth it. Again, this is where Puppet just doesn’t feel very polished, it really shouldn’t be this hard to set up but I guess this is how they’ve decided to convince people to pay for Enterprise.
• Get a copy of Pro Puppet. Although there are lots of docs on their site and all over the web, this seems to be the howto guide. Written by one of the Puppet Labs guys, it’s helped a lot.
• Have a read of some posts about different configurations and work out how best to represent your facility’s nodes

In the next post, I’ll start putting the specifics of how we set the various components up along with how we mixed and matched the ideas in the posts linked above to best work for us.