Forge Home


Automates the process of moving a node between puppet masters


10,207 latest version

1.9 quality score

We run a couple of automated
scans to help you access a
module's quality. Each module is
given a score based on how well
the author has formatted their
code and documentation and
modules are also checked for
malware using VirusTotal.

Please note, the information below
is for guidance only and neither of
these methods should be considered
an endorsement by Puppet.

Version information

  • 0.1.0 (latest)
released Aug 28th 2013

Start using this module

  • r10k or Code Manager
  • Bolt
  • Manual installation
  • Direct download

Add this module to your Puppetfile:

mod 'dhgwilliam-cutover', '0.1.0'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add dhgwilliam-cutover
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install dhgwilliam-cutover --version 0.1.0

Direct download is not typically how you would use a Puppet module to manage your infrastructure, but you may want to download the module in order to inspect the code.



dhgwilliam/cutover — version 0.1.0 Aug 28th 2013

dhgwilliam-cutover documentation


  • You have two trusted puppet masters (you'll be giving your old-master full control over the new-master CA)
  • The old-master is Puppet Open Source and the new-master is Puppet Enterprise; this shouldn't be required, and the module should be updated shortly to reflect a more generalized use case

10,000 Feet

Basically, the cutover module is intended to aid you in the process of moving an agent node between two "trusted" masters.

Given a configuration of old-master, new-master, and agent, the module is applied as such:

# manifests/site.pp on old-master

node 'agent.puppet.labs' {
  class { 'cutover':
    new_master => 'new-master.puppet.labs',
    old_master => 'old-master.puppet.labs',

This currently utilizes the cutover::pitcher class to apply the necessary changes to the agent and the new-master CA to hand it over to the new-master; a cutover::catcher class should be implemented soon which will take care of the changes necessary to clean up after the handoff.

laying the groundwork

In order for this to work, we utilize the fingerpuppet gem to manipulate the CA on new-master. Start with:

on old-master.puppet.labs

gem install fingerpuppet
env HOME=/var/lib/puppet fingerpuppet --init --server new-master.puppet.labs --certname old-master.puppet.labs

on new-master.puppet.labs

puppet cert list  # confirm that the old-master has successfully submitted a CSR
puppet cert sign old-master.puppet.labs

find the following stanza in /etc/puppetlabs/puppet/auth.conf and update it accordingly:

  path  /certificate_status
  method find, search, save, destroy
  auth yes
- allow pe-internal-dashboard
+ allow pe-internal-dashboard, old-master.puppet.labs

back on old-master.puppet.labs

env HOME=/var/lib/puppet fingerpuppet --install
env HOME=/var/lib/puppet fingerpuppet --cert_status old-master.puppet.labs  
# output should resemble the following:

What happens

After three puppet runs, the agent node should be successfully "handed off" to the new-master:

  • After the first run, the agent node generates a new SSL private key and submits a CSR to the new-master, and the CA cert is retrieved
  • After the second run, the CSR is signed and the agent's private cert is retrieved
  • After the third run, the agent's puppet.conf is updated to take advantage of the new $ssldir and the server and ca_server config directives are set to new-master
  • On the next run, the agent should run against new-master instead of old-master


The folder old-master:/var/lib/puppet/.fingerpuppet may become relevant to your life.