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
puppet.conf at server provision time (before the very first puppet run). My process would look something like this:
- basic o.s. installation
- basic network configuration, enough to reach the internet and resolve dns
- install puppet and set up certname
- start puppet and let him manage the whole configuration
- test, fix problems in config (via puppet), re-test, and so on...
- manually stop puppet
- set up new network configuration for the datacenter network
- move the machine to DC
- turn it on
- 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?