8

How can I migrate our existing puppet clients to point to a new puppetmaster server? I'd rather not manually go to each client box and generate a new certificate.

When trying the obvious -- rsync all the files from /etc/puppet and /var/lib/puppet to the new server -- we got the certificate error

/etc/init.d/puppetmaster start 
* Starting puppet master                
Could not run: Retrieved certificate does not match private key; please remove certificate from server and regenerate it with the current key

I was able to work around that by copying the /var/lib/ssl/certs and /var/lib/ssl/private_key files from old_hostname to new_hostname, which is basically what's suggested in migrating puppet clients to a new puppet master (old puppet master server gone, only using backup)

Unfortunately, my clients still know there's something amiss, and give me the following error:

sudo puppetd --test --server newservername.example.net --noop 
info: Retrieving plugin
err: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate': hostname was not match with the server certificate
err: /File[/var/lib/puppet/lib]: Could not evaluate: hostname was not match with the server certificate Could not retrieve file metadata for puppet://newservername.example.net/plugins: hostname was not match with the server certificate
err: Could not retrieve catalog from remote server: hostname was not match with the server certificate
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run

So I'm guessing the client certificates still know the hostname they're associated with, and aren't happy about a switch.

Is there a way to use puppet (pointing to the legacy puppetmaster) to deploy new certificates, or somehow automate the signing process?

SUMMARY: Two solutions were presented: 1) turn on autosign on the master, thus skipping certification entirely, or 2) set the old CNAME to point to the new master, since certificates are bound to the master's hostname. I chose #2 because autosign felt like it was just turning off security (albeit for a limited time).

Community
  • 1
mrisher
  • 401
  • 1
  • 5
  • 12

2 Answers2

3

Are you looking to keep both puppet masters up and running for a time, and migrate clients over a little at a time?

If so, you're stuck touching each client system regardless; whether it's to point to a new master, or add a hosts file entry, or some such. If that's the case, then you might as well just start the new master fresh and re-sign each client (it's better than a hosts file hack to work around the validation issues).

If not (if you're planning to take down the old server and cut everything over at once), then just take the old server's hostname over with the new server; the certificate will be recognized as valid if the clients are connecting to the new server on the old name (the name that is on the certificate).

Shane Madden
  • 114,520
  • 13
  • 181
  • 251
  • Yeah, the question was around whether it's possible to *automate* re-signing of each client. I think you've answered it by pointing out that the certificates are bound to the hostname the client is using to reach a particular server, so if I reuse the hostname, I will be able to reuse the certificates. Thanks! – mrisher Jun 09 '11 at 06:50
  • Well, a simple `puppetca --sign --all` will do the trick for the client certificates; the server one is the one giving you issues with the mismatch errors. – Shane Madden Jun 09 '11 at 14:18
3

You can simply use the $ssldir of the old puppetmaster and use that in the new puppetmaster.

Other than that it should be possible to deploy a script that will:

  • (Unrelated to the client script: possibly activate autosign on the new puppet server)
  • run a bit later
  • stop puppet client
  • clean out the client ssldir
  • modify the puppet.conf on the client to point to the new server
  • create a lock file to make sure it doesn't cause an endless reconfiguration loop
  • start puppet again

Ugly but as long as the do migration module is only on the old server and the make sure there's no migration module is only on the new server it's a one shot thing and should just do the magic...

serverhorror
  • 6,478
  • 2
  • 25
  • 42
  • Hi: The `autosign` trick is a good one, but seems risky. Without it, does this solution actually address the client certificate-mismatch problem? – mrisher Jun 09 '11 at 06:47
  • It does, autosign is just the lazy way of not having to deal with thousands of clients that will be new on the puppetmaster. The concept is the same the difference is that clients that migrated to the new master won't do any work unless they're signed – serverhorror Jun 09 '11 at 08:31