ReleaseEngineering/PuppetAgain/HowTo/Bootstrap a Puppetmaster: Difference between revisions

ReleaseEngineering/PuppetAgain/HowTo/Bootstrap a Puppetmaster (view source)

Revision as of 15:15, 21 August 2013

991 bytes added , 21 August 2013

no edit summary

Djmitche

canmove, Confirmed users

1,394

edits

@@ Line 1: / Line 1: @@
 {{note|You only need to bootstrap the first master in an organization.  Subsequent masters should be installed like any other server - just turn them on.  Well, it's not that easy, but puppetize them and they will tell you what to do.}}
+= First Master =
 # Build a CentOS system with only a Base install
@@ Line 8: / Line 10: @@
 #* [http://www.homebrewtalk.com/wiki/index.php/Relax_Don%27t_Worry,_Have_a_Home_Brew Relax, don't worry, have a homebrew!]
 #* For help with the SSL portions, see [[ReleaseEngineering/PuppetAgain/Certificate Chaining]]
+= Subsequent Masters =
+* Synchronize /data from an existing master to the new master.
+* Add a node definition for the new master and install it.  Do not add the new master to the org config yet.  Puppet will eventually fail with complaints about synchronizing git and secrets with the distinguished master.  The trick here
+* Temporarily add the new master's fqdn to ~puppetsync/.ssh/authorized_keys (you may need to repeat this if puppet runs on the DM and reverts your changes) and
+** run the failing secrets crontask
+** run puppet - it will fail with a message about the master CA cert.
+* Follow those instructions to sign a new cert for the new master.
+* run puppet again, solving errors.  Note that httpd will start successfully only on the final run.
+The master should now be ready.  Test it by running the agent against the new master:
+  puppet agent --test --server=$(facter fqdn)
+once you're satisfied, add the master to the list of masters in the org config.