Pro Puppet by Jeffrey McCune James Turnbull Page A

definitions in place, we can now move on to creating our modules for the various hosts. But first, let’s do a quick refresher on modules in general.
Making (More) Magic With Modules
    In Chapter 1 , we learned about modules: self-contained collections of resources, classes, files that can be served, and templates for configuration files. We’re going to use several modules to define the various facets of each host’s configuration. For example, we will have a module for managing Apache on our Web server and another for managing Postfix on our mail server.
    Recall that modules are structured collections of Puppet manifests. By default Puppet will search the module path, which is by default
/etc/puppet/modules/
and
/var/lib/puppet/modules
, for modules and load them. These paths are controlled by the
modulepath
configuration option. This means we don’t need to import any of these files into Puppet – it all happens automatically.
    It’s very important that modules are structured properly. For example, our
sudo
module contains the following:
    sudo/
sudo/manifests
sudo/manifests/init.pp
sudo/files
sudo/templates
    Inside our
init.pp
we create a class with the name of our module:
    class sudo {
configuration…
}
    Lastly, we also discovered we can apply a module, like the
sudo
module we created in Chapter 1 , to a node by using the
include
function like so:
    node 'puppet.example.com' {
  include sudo
}
    The included function adds the resources contained in a class or module, for example adding all the resources contained in the
sudo
module here to the node
puppet.example.com
.
    Let’s now see how to manage the contents of our modules using version control tools as we recommended in Chapter 1 .
    Note You don’t have to always create your own modules. The Puppet Forge at
http://forge.puppetlabs.com
contains a large collection of pre-existing modules that you can either use immediately or modify to suit your environment. This can make getting started with Puppet extremely simple and fast.
Version Controlling Your Modules
    Because modules present self-contained collections of configuration, we also want to appropriately manage the contents of these modules, allowing us to perform change control. To manage your content, we recommend that you use a Version Control System or VCS.
    Version control is the method most developers use to track changes in their application source code. Version control records the state of a series of files or objects and allows you to periodically capture that state in the form of a revision. This allows you to track the history of changes in files and objects and potentially revert to an earlier revision should you make a mistake. This makes management of our configuration much easier and saves us from issues like undoing inappropriate changes or accidently deleting configuration data.
    In this case, we’re going to show you an example of managing your Puppet manifests with a tool called Git, which is a distributed version control system (DVCS). Distributed version control allows the tracking of changes across multiple hosts, making it easier to allow multiple people to work on our modules. Git is used by a lot of large development projects, such as the Linux kernel, and was originally developed by Linux Torvalds for that purpose. It’s a powerful tool but it’sd easy to learn the basic steps. You can obviously easily use whatever version control system suits your environment, for example many people use Subversion or CVS for the same purpose.
    First, we need to install Git. On most platforms we install the
git
package. For example, on Red Hat and Ubuntu:
    $ sudo yum install git
    or,
    $ sudo apt-get install git
    Once Git is installed, let’s identify ourselves to Git so it can track who we are and associate some details with actions we take.
    $ git config --global user.name "Your Name"
$ git config --global user.email [email protected]
    Now let’s version control the path containing our