The Linux Foundation

 
LSB Puppet

From The Linux Foundation

Revision as of 20:20, 31 July 2013 by Herrold (Talk | contribs)

(diff) ←Older revision | view current revision (diff) | Newer revision→ (diff)

The LSB uses Puppet (http://puppetlabs.com) to manage its infrastructure, following a "devops" model. All system configuration should be controllable via a change to our Puppet configuration.

Contents

Version Control

We keep our Puppet configuration in the "puppet-lsb" Bazaar repository. Note that access to this repository is restricted; only people with commit access to the LSB repositories generally can even read the repository. This is because some of the information in that repository may have security implications.

The URL for checking out the Puppet repository is:

https+urllib://(username)@bzr.linuxfoundation.org/lsb/devel/puppet-lsb

General Organization

The initial work done here was done with Puppet 2.6, and should remain compatible with that version for the foreseeable future.

Configuration is defined per-service in Puppet modules, and per-node in the "nodes" directory. Whenever possible, it's best to define services as modules, rather than include all the gory details in the per-node config. This makes it easy to move services between nodes; a quick "include 'foo'" creates the service on the node and gets it working.

The configuration will, in general, reflect a SUSE bias, as the initial node was a SLES 11 virtual machine. However, we are trying to isolate SUSE-specific things as much as possible, so we should be able to accomodate nodes running other Linux distributions as well. This will obviously not be foolproof, so sticking with SUSE may be the best bet for making things work well. Although we're using SLES, OpenSUSE should also work.

Please test configuration changes on a test node before pushing them into production!

Please file bugs related to our configuration at the LSB bug tracker (http://bugs.linuxbase.org), in the Infrastructure section. There is a DevOps component; this should be used only for bugs or request specifically aimed at Puppet itself. Bugs in other components that happen to be configured in Puppet should be filed in that component, not in DevOps. Patches or bzr merge directives against this repository are welcome to bugs in any Infrastructure component.

Adding a node to Puppet

Adding a node to this Puppet configuration is pretty much standard Puppet, with only a few tweaks required for our local setup:

  • Check out the puppet-lsb repository from version control.
  • In puppet-lsb, create a node configuration file in manifest/nodes. You can use one of the other node configuration files as a model. Or, if you prefer, something like this is the minimum configuration required for a node:
   node 'my.host.name' { include puppet }

The filename can be descriptive, but the actual node name in the file must correspond to the FQDN Puppet expects on the node. You can find this hostname via this command:

   facter | grep fqdn
  • Once the node file is in place, use version control to add the new file, commit it, and push it.
  • On the node, install puppet, and run the following command as root:
   puppet agent --server puppet.linuxbase.org --waitforcert 60 --test

Puppet should report that it is creating a new key and cert request and that the peer certificate won't be verified. It should then wait, reporting every so often that it can't receive the certificate.

  • On the master, "puppet cert list" should report that a certification request exists for the node. Run "puppet cert sign (hostname>)" to sign the certificate.
  • On the node, the running puppet agent should report within 60 seconds that it is caching the certificate, and should then retrieve and apply the node's configuration (if any) without further errors.
  • Since puppet resets things like sudo, it's possible to lose access to root after puppet has run. We therefore recommend setting the password for the user 'lfadmin' and starting the puppet service manually once the puppet agent succeeds.

Running "puppet agent -t" on the node tests the connection, and also can force the current configuration to apply immediately without waiting for the normal agent update interval.

The puppet-secret modules

In a few cases, this configuration refers to modules that don't seem to exist. These are from the "puppet-secret" area, and contain information that shouldn't be accessible to the public: passwords, secret keys, and so on.

In all cases, puppet-secret contains modules which either expose variables to Puppet, or install files. Someone with experience in Puppet should be able to recreate puppet-secret with nothing more than the information contained here, and thus create an independent working implementation. Of course, the passwords, keys, etc. will be different than on the live production copy.

It might be worth asking whether a "blank" public copy of puppet-secrets could be provided. The worry is that the blank copy would get stale, and implementors would be forced to reverse-engineer the missing bits from this repository anyway. Suggestions for fixing this problem are welcome.

Deployment considerations

Keep in mind: A later (higher version numbered) puppet master is compatible with older puppet agents, but later puppet agents are not compatible with earlier masters. That is, one may run 2.7 agents with a 3.1 master, but not a 3.1 agent with 2.7 master. The present (2013) LSB puppet master is in version 3.1 series for this reason.


[Article] [Discussion] [View source] [History]