Splitting puppetd from puppetmaster

My relationship with Puppet is one of love and hate. I am forced to use it simply because there is no better tool around, but I hate it in so many ways that I don’t even want to start to enumerate (hint: most have to do with Ruby, actually).

Today I decided to put an end to one thing that has been driving me insane: the fact that puppetd (the client) and puppetmasterd (the server) use the same working directory, /var/lib/puppet. Since I consider and would like to treatthe machine on which puppetmasterd is running just another puppet client, I was running into funky issues related to SSL certificate confusion, obscure errors, and SSL revocation horrors.

The following hence assumes that you have installed or are planning to install puppetd on the machine running your puppetmaster, and that you have two fully-qualified domain names for the machine. For instance, I run puppetmaster on vera.madduck.net, and puppetmaster.madduck.net is an alias for the same machine. I’ll use these names in the following as examples.

The following may be Debian-specific, as I am solely using the puppet and puppetmaster packages for my experimentation and verification. Your mileage may vary, but the concept shall be the same.

Stop everything:
```
/etc/init.d/puppetmaster stop
/etc/init.d/puppet stop
```
(also verify that you have not instructed cron to restart these services)
Rename the working directory:
```
mv /var/lib/puppet /var/lib/puppetmaster
```
and amend /etc/puppet/puppet.conf accordingly:
```
[main]
# …
vardir=/var/lib/puppetmaster
ssldir=$vardir/ssl
# …


[puppetmasterd]
certname=puppetmaster.madduck.net
# …
```
I am doing this in [main], planning to override it for puppetd later, because puppetd is the only program which makes sense to be separated from the rest. Since only the puppetmaster needs a special certificate name, that is set specifically in the [puppetmasterd] section.

If you use apache2 or nginx in front of your puppetmasters, make sure to amend the SSL file locations in the virtual host definition and restart (!) the service.

You can verify that the configuration has been amended by making sure that there is no output from the following command:
```
# puppetmasterd --genconfig | grep -q '/var/lib/puppet/' && echo SOMETHING IS WRONG
```
Now restart puppetmaster:
```
/etc/init.d/puppetmaster start
```
and verify that it starts.

If your puppetmaster previously ran under a different name, it will create itself a new certificate and sign it.

Since the client will get its own working directory (and thus a new SSL certificate), you want to remove all records of the old certificate:
```
# puppetca --list --all
+ puppetmaster.madduck.net
+ vera.madduck.net
# puppetca --clean vera.madduck.net
```

Change the configuration file to tell puppetd about its working directory:

[puppetd]
server=puppetmaster.madduck.net
vardir=/var/lib/puppet
ssldir=$vardir/ssl
# …

This you can verify with the following command, which should not print anything:

# puppetd --genconfig | grep -q '/var/lib/puppet[^/]' && echo SOMETHING IS WRONG

Now install puppet, or (re)start it if it’s already installed:

# /etc/init.d/puppet stop
# puppetd --no-daemonize --onetime --verbose --waitforcert 30 &
info: Creating a new SSL key for vera.madduck.net
warning: peer certificate won't be verified in this SSL session
info: Caching certificate for ca
info: Creating a new SSL certificate request for vera.madduck.net


# puppetca --list
vera.madduck.net
# puppetca --sign vera.madduck.net
notice: Signed certificate request for vera.madduck.net
notice: Removing file Puppet::SSL::CertificateRequest vera.madduck.net at '/var/lib/puppetmaster/ssl/ca/requests/vera.madduck.net.pem'


# fg
info: Caching certificate for vera.madduck.net
info: Caching certificate_revocation_list for ca
[…]


# puppetca --list --all
+ puppetmaster.madduck.net
+ vera.madduck.net


# /etc/init.d/puppet start

Do yourself the favour and check that it’s all working.

Optionally, you can now clean up the client stuff in the server’s working directory, for instance like this (it worked for me, but this is the sledgehammer approach):

# /etc/init.d/puppetmaster stop
# cd /var/lib/puppetmaster
# tar -cf /tmp/puppetmaster.workingdir-backup.tar .
# find ../puppet -type f -printf '%P\n' | xargs rm
# /etc/init.d/puppetmaster start

If you stopped cron before (and your puppet recipes have not since restarted it):
```
/etc/init.d/cron start
```

All done. I wish puppet, or at least Debian’s puppet packages would do this by default. Please let me know if the above conversion works for you. Then I might start working on an automated migration.

NP: Genesis: Selling England by the Pound