Running a puppetmaster in ec2
I struggled with this for a few days before figuring it out, so I’ll post it here in hopes it saves someone a few minutes. When you install puppet and start the puppetmaster (webrick or rack-enabled) it generates a ssl cert for that machine and also generates a CA that you will use to sign all of your clients.
Recent versions of puppet do not add subjectAltNames to the server certificate when it’s generated by the puppetmaster process. This means that if you do not use the same name as your masters hostname to connect to puppet you will get a lovely cert mismatch. I posted a question on serverfault about this (here). It looks like the common practice for EC2 in particular is to use a uuid as the certname for each puppet client. This avoids name collisions and problems with hostnames changing everytime the instance is rebooted. It’s a little harder to keep track of since they aren’t very easy to remember, so caveat emptor.
First get puppet installed. I tend to use gems (even though I despise them) since they update much faster upstream than anything else. Do NOT run puppet or start the puppetmaster.
Generate a uuid or pick some string/name/moniker that’s going to be uniq and consistent. (uuidgen to get a uuid)
Setup a basic puppet.conf, rpm installs will do this for you, gem installs you are on your own.
logdir = /var/log/puppet
rundir = /var/run/puppet
vardir = /var/lib/puppet
ssldir = $vardir/ssl
pluginsync = true
server = puppet
environment = production
certname = ENTER_UUID_HERE
dns_alt_names = puppet
report = true
You can also manually generate the cert with the following.
puppet cert generate --dns_alt_names puppet ENTER_UUID_HERE
Your master cert will have the subjectAltNames field now, This is all addressed in http://projects.puppetlabs.com/issues/10739 and should be fixed in the next puppet release.
The concept of using the uuid for ec2 type instances is sound and will prevent ssl headaches in the future.