1.2. Introduction to Puppet Common Modules

One of the major advantageous features of Puppet is the ability for it to simply load modules. I can, and so will others, strongly recommend you use modules as much as you can.

They are environment aware, they can have separate Source Code Management system trees under the hood (with access control applied to each of them differently, if needed), and they require the configuration management tree to be clean.

And so, the Puppet community discussed ways to come to a common set of modules. You can find parts of the result on http://reductivelabs.com/trac/puppet/wiki/CommonModules.

1.2.1. Three Different Module Approaches

There are basically three different ways to manage a node's configuration. These three ways lead to three basic types of modules, as one module will always try to keep true to either of these three principles. Mixing and matching different approaches would only make life harder, not simpler.

Override anything on a per-file basis, putting the right configuration file in the right location on the Puppet master.
Set variables (in the node manifest) to influence the end-result (file) that is generated from a template.
Let Puppet control only some settings in a configuration file through Augeas, leaving the rest of the (original) file intact.

1.2.1.1. Put the right file in the right place

This type of approach allows you to customize all settings available in any configuration file, by letting you supply your version of the configuration file. The modules attempt to obtain the file from a certain number of locations ordered by exclusivity, taking the file that first hits. For example; The sources that are being attempted for /etc/httpd/conf/httpd.conf are, in order:

This seems like a lot of sources for one file, but bear in mind Puppet will eventually use only one of the listed sources. Puppet will take the first source that is available, when given a list of sources.

Source #1 and #2 come from private domain name space specific configuration trees, which are entirely optional, and most probably only used in shared service center Puppet setups. Source #5 comes from the module itself, and resembles the package default configuration file with minor adjustments to make it fit with the rest of the module.

Source #4 and #5 probably are the most reasonable locations for your Puppet setup to finally find the file you wanted.

The ultimate goal of these type of modules is to have absolute control over the contents of a configuration file, within modules that can be used, re-used, and distributed without any modification to the module itself. Side-effect is that the modules allow multi-domain name space configuration trees, but that is not a feature that is used very often.

1.2.1.1.1. Advantages

Ultimate control over the contents of the distributable files, allowing you to alter each and every setting available in your average application configuration file.
The option of private domain name specific configuration trees enables you to create more then one configuration tree with separate Source Code Management repositories. These Source Code Management repositories could have different types of Access Control, can be in different locations, and enable you to securely divide system administration for one domain name space from another domain name space.
Distributed files are actual files in your copy of the tree, and you can read it's contents from within your local working copy.
Per-file based modules are easier to setup. You are not required to set any variables in a node manifest in order to get the correct logic in the module apply the correct configuration to the node.
There is no additional processing required on the Puppet master.

1.2.1.1.2. Disadvantages

When not using the private domain name space specific configuration trees, the fileserver takes a hit or two it cannot satisfy. This can potentially increase the Puppet run duration especially if you plan on transferring large amounts of files.
When using the private domain name space specific configuration trees, the Puppet manifests need to be synchronized from /var/lib/puppet/private/$domain/$environment/puppet/manifests/, to the appropriate directory in /var/lib/puppet/manifests/development/.
In the light of private domain name space configuration trees, the only common denominator used right now is the $domain of a node. This is a hard limit, since changing the sources of a File resource basically includes forking the module.

1.2.1.2. Set the variables

This type of Puppet module lets you set variables. In the Puppet module, a template is directed to use the variables, resulting in a version of the configuration file which can then be distributed. This can come in handy if you have a lot of very much different servers.

1.2.1.2.1. Advantages

In case you need the same thing to happen lots of times, but need it to happen in different ways most of the time, using variables and templates in a node manifest can save the day.

1.2.1.2.2. Disadvantages

Most of the time, you are required to set a couple of variables in the node manifest in order for the Puppet client to be able to initialize.
Templates come from one location only (or can be specified by using yet another variable).
There simply can't be enough variables available for you to configure, to ultimately control all settings in any type of configuration file.
Although just a few variables may suffice, a modification to a file's contents means you need to fork the module, alter its template -maybe even alter its manifests-, to adjust the setting in the template or make available a variable to control the template's parsing logic with.
The more variables, the more obfuscated the template.
All variables this type of module allows you to configure need to be negotiated, so that a variable used in the template is never nil. A variable used in the template with a nil value causes the rendering of the template to fail.
Templates are being parsed server-side. In larger environments, this can overload the Puppet master, or increase the duration of not only this node's Puppet run, but the Puppet run of other nodes as well.

1.2.1.3. Per-setting control through Augeas

Controlling one setting in a configuration file using Puppet's integration with Augeas is a neat feature. Imagine all you want is to not permit remote logins of root through SSH. With Augeas, you can control this setting and let the rest of the SSHd configuration file be.

Imagine, though, you have a configuration file with a 1000 settings. If you need just 1 setting changed, it is OK to use Augeas (and have a single Puppet type instantiated to control the setting with), but if you need more settings (100? 400?) changed, you will see that controlling all these settings through Puppets Augeas type will leave you with a (node) manifest that is not as readable as a copy of the configuration file itself.