puppetmanaged.org

Puppetmanaged.org is a collection of modules for Puppet, the next-generation enterprise configuration management suites. When we say "configuration management" however, we are not talking about the ITIL or ITSM configuration management. Read more on what configuration management also means.

The Value of Modules

Using modules for Puppet can help you in a variaty of ways. For one, modules are supposed to be portable between different environments because they let you adjust the exact configuration applied to a node. The portability allows efficient development, and effective deployment. Secondly, environments that apply configuration management through the use of modules are often more consistent, which makes all of our lives a lot easier.

When using modules however, you would want to choose to share that module with others, so that the module may evolve and become better, while helping others solve their problems very efficiently as well.

Some will argue that Puppet modules you get from the Internet will never work exactly the way you want them too, but luckily some of the module developers use the Open Source development model; you can contribute back –and you should.

Modules for Puppet can be created using three different approaches, or a mixture thereof:

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

There is something to say for each of these methods. Each of them may have its advantages and disadvantages. Also, none of these different types of approaches is mutually exclusive with any other approach. However, I would recommend that you stick with one single approach for an entire environment as much as you can.

A given module (including those from puppetmanaged.org) using either of the aforementioned approaches can still include one or two types using the other method. For example, the puppetmanaged.org webserver module allows you to specify a template for a webserver's virtualhost.

File-based Distribution

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 the distribution of /etc/httpd/conf/httpd.conf are, in order:

1. puppet://$server/private/$environment/webserver/httpd.conf.$hostname
2. puppet://$server/private/$environment/webserver/httpd.conf
3. puppet://$server/files/webserver/httpd.conf.$hostname
4. puppet://$server/files/webserver/httpd.conf
5. puppet://$server/webserver/httpd.conf

The ultimate goal of this approach is to make it as simple as humanly possible to make use of the module, and to have absolute control over the contents of a configuration file. These modules can be used, re-used, and distributed without any modification to the module itself. A side-effect is that the modules allow one single puppetmaster to run multiple domain name space specific configuration trees.

Module Function Logic

This type of Puppet module lets you set a couple of variables (and have a default for all variables you neglect to define). In the Puppet module, a template is used using the variables defined, 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.

There simply can't be enough variables to set, to ultimately control all settings in any type of configuration file. Although this may suffice for your needs, 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.

Per Setting (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, or 20 configuration files with 50 settings each. If you need just 1 setting changed, of you really only require control over a few settings, 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.