Puppetmaster XCVII: Getting your new server registered

So, this post has nothing to do with low-rent horror movies. Sorry to disappoint.

What it’s really about is the Puppet server management system deployed to keep general server Linux settings synchronized–stuff like NTP servers and user accounts. Puppet is extremely powerful, but this will only be an introduction to what it can do, as I’m learning as I go.

It may seem a little backward to start with the client configuration, but this really seems like the easiest part to me: tell the client who the server is, sign some certificates, and wait for the updates. The puppet master server is where all the heavy lifting is done.

Once the puppet master server is created and configured with manifests and such (take for granted that they exist already), it’s time to configure your client and get it registered.


[email protected]:~$ sudo aptitude install puppet

An Ubuntu server will tell you all of the packages that must be installed and will give you the option to continue. If you choose to continue, Ubuntu will install all of the packages then warn you that it could not start the puppet agent

 * Starting puppet agent

puppet not configured to start, please edit /etc/default/puppet to enable

which means you need to edit the file the message refers to. So, sudo nano /etc/default/puppet, change

# Start puppet on boot?


# Start puppet on boot?

and save the file. Once saved, sudo service puppet start.


Puppet uses certificates for authentication, so the master is basically a CA who signs certificates from the clients. Unless you tell the client otherwise, it’ll assume that the puppetmaster’s name is puppet, so you either have to handle that with DNS or by editing the client’s puppet.conf. I took the first route, which seemed easier to me.

On the client, we tell it to send it’s certificate to be signed by the puppetmaster by telling it to test:

[email protected]:~$ sudo puppet agent --test
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
Exiting; no certificate found and waitforcert is disabled
[email protected]:~$

Once that’s done, we have the puppetmaster approve the client’s certificate:

[email protected]:/etc/puppet$ sudo puppetca --list
  new-server.local (6F:47:D1:6B:F3:B0:4B:94:00:92:5E:F7:E5:38:7C:C9)
[email protected]:/etc/puppet$
[email protected]:/etc/puppet$ sudo puppetca --sign new-server.local
notice: Signed certificate request for new-server.local
notice: Removing file Puppet::SSL::CertificateRequest new-server.local at '/var/lib/puppet/ssl/ca/requests/new-server.local.pem'
[email protected]:/etc/puppet$

After the client certificate is signed, it’s no longer in the server’s pending list.

[email protected]:/etc/puppet$ sudo puppetca --list
[email protected]:/etc/puppet$M

At this stage, the client is essentially configured. Within the next 30 minutes, it will contact the puppet master to see if any new or changed catalog items exist for it–if they do, the client will make the changes. If you’re impatient like me, you can force the client to check in by forcing another test:

[email protected]:~$ sudo puppet agent --test
warning: peer certificate won't be verified in this SSL session
info: Caching certificate for new-server.local
info: Caching certificate_revocation_list for ca
info: Caching catalog for new-server.local
info: Applying configuration version '1330636935'
notice: /Stage[main]//Package[ntp]/ensure: ensure changed 'purged' to 'present'
--- /etc/ntp.conf       2011-09-02 18:42:40.000000000 +0000

Keep in mind that it’s possible that some of the client’s catalog cannot be completed while your user is logged in, depending on what the changes are. For instance, if the catalog for that client changes your user’s UID or GID, you’ll receive an error until your user is no longer logged in.

To be sure that your client is checking in on it’s own, just take a look at it’s syslog:

[email protected]:~$ sudo more /var/log/syslog | grep puppet-agent

Next time, we’ll take a look at the files that make up a “catalog”.

Leave a Reply