Puppet: is it ok to "force" certname when you expect to shuffle nodes around?

Posted by Luke404 on Server Fault See other posts from Server Fault or by Luke404
Published on 2012-09-05T21:50:31Z Indexed on 2012/09/08 15:40 UTC
Read the original article Hit count: 214

Filed under:
|

We all know (good example on SF) that Puppet hostname detection could be... fun.

At our company (and I guess we're not alone at this) we usually pre-configure servers at our offices and test them before bringing the gear to a remote datacenter and rack them. Of course the reverse dns will change when doing that, even if we don't change the actual hostname of the system.

We're slowly drafting our puppet setup and I'd like to be sure those moves won't create problems. My idea is to explicitly configure the desired full FQDN of the system as certname in puppet.conf at server provision time (before the very first puppet run). My process would look something like this:

  1. basic o.s. installation
  2. basic network configuration, enough to reach the internet and resolve dns
  3. install puppet and set up certname
  4. start puppet and let him manage the whole configuration
  5. test, fix problems in config (via puppet), re-test, and so on...
  6. manually stop puppet
  7. set up new network configuration for the datacenter network
  8. move the machine to DC
  9. turn it on
  10. puppet should automatically start and keep on doing its job

The process is supported by detecting the environment in puppet's manifests (eg. based on subnet, like they do at Wikimedia) and modify configuration as needed (eg. resolv.conf contents appropriate for each network). Each node's certname will never change for the whole system life cycle.

Is there any problem with this approach? Could it be improved?

© Server Fault or respective owner

Related posts about linux

Related posts about puppet