ReleaseEngineering/PuppetAgain/Puppetmasters: Difference between revisions

ReleaseEngineering/PuppetAgain/Puppetmasters (view source)

Revision as of 01:09, 18 January 2012

829 bytes added , 18 January 2012

no edit summary

Djmitche

canmove, Confirmed users

1,394

edits

@@ Line 1: / Line 1: @@
+Within releng, the puppet master should respond at the unqualified hostname <tt>puppet</tt>.  This is adjustable through <tt>manifests/settings.pp</tt> for other environments.
+== Master System ==
+Masters are RHEL6 systems running same version of puppet as used in sysadmins (currently 2.7.9).  This is frontended by Passenger.
+The manifests at http://hg.mozilla.org/build/puppet are checked out at <tt>/etc/puppet/production</tt>.  Environments are also set up as described below.
 The masters update their manifests from mercurial once every 5 minutes, with a bit of "splay" added (so it does not always occur on the 5-minute mark).  Any errors during the update are emailed, as well as a diff of the manifests when they change; the latter forms a kind of change control.
-Within releng, the puppet master should respond at the unqualified hostname <tt>puppet</tt>.  This should also be adjustable through <tt>manifests/settings.pp</tt>.
+== Environments ==
+For each of the members of release engineering, an environment is set up with e.g.,
+{{{
+[jford]
+    modulepath = /etc/puppet/environments/jford/env/modules
+    templatedir = /etc/puppet/environments/jford/env/templates
+    manifestdir = /etc/puppet/environments/jford/env/manifests
+    manifest = $manifestdir/site.pp
+}}}
+and per-user logins are enabled.  A clone of the hg library at this location, along with any necessary secrets and settings, can be used to test and develop changes to puppet.
+Puppet logs currently go to syslog, which is not accessible except to root.  A method for accessing these logs is TBD.
 == Cert Signing ==
@@ Line 11: / Line 31: @@
    The sysadmin was enlightened.
-All of our installation tools are scriptable.  These tools are responsible for fetching a signed certificate from the puppet master and installing it on the client before its first boot.  This transaction IS be authenticated using a protected secret.  Non-Mozilla users can simply omit this part of the setup and sign certificates by hand.
+All of our installation tools are scriptable.  These tools are responsible for fetching a signed certificate from the puppet master and installing it on the client before its first boot.  This transaction IS be authenticated using a protected secret.  Non-Mozilla users can simply omit this part of the setup and sign certificates by hand.  The shared secret is a password.  For systems where the base image is access-restricted, this password is embedded in the image.  For other systems (e.g., kickstart), the password must be supplied by the person doing the imaging, at the beginning of the process.
-That secret takes the form of an SSH private key.  This "deploykey" is added to the image by a means that depends on the install process, and is used by the [http://hg.mozilla.org/build/puppet/file/71467849a704/setup/puppetize.sh puppetize.sh script] to contact the puppetmaster.  The key does not allow login, but generates and returns a puppet certificate for the machine connecting to it.