Pro Puppet (9 page)

Our first step in creating our first agent configuration is defining and extending the
site.pp
file. See an example of this file in
Listing 1-3
.

The
import
directive tells Puppet to load a file called
nodes.pp
. This directive is used to include any Puppet configuration we want to load. For example, if we specify resources in a file called
resources.pp,
we would need to import it this way:

When Puppet starts, it will now load the
nodes.pp
file and process the contents. In this case, this file will contain the node definitions we create for each agent we connect. You can also import multiple files like so:

The
import
statement will load all files with a suffix of
.pp
in the directories
nodes
and
classes
.

The
$puppetserver
statement sets a variable. In Puppet, configuration statements starting with a dollar sign are variables used to specify values that you can use in Puppet configuration.

In
Listing 1-3
, we’ve created a variable that contains the fully qualified domain name of our Puppet master, enclosed in double quotes.

Let’s add our first agent definition to the
nodes.pp
file we’ve just asked Puppet to import. In Puppet manifests, agents are defined using
node
statements.

You can see the node definition we’re going to add in
Listing 1-4
.

For a node definition we specify the node name, enclosed in single quotes, and then specify the configuration that applies to it inside curly braces
{ }
. The client name can be the hostname or the fully qualified domain name of the client. At this stage, you can’t specify nodes with wildcards (e.g.,
*.example.com
) but you can use regular expressions, such as:

This example will match all nodes from the domain
example.com
with the hostname
www1
,
www12
,
www123
, etc.

Next, we specify an
include
directive in our node definition. The
include
directive specifies a collection of configuration that we want to apply to our host. There are two types of collections we can include in a node:

• Classes – a basic collection of resources
  
• Modules – an advanced, portable collection of resources that can include classes, definitions, and other supporting configuration
  

You can include multiple collections by using multiple
include
directives or separating each collection with commas.

In addition to including collections of resources, you can also specify individual resources to a node, like so:

In this case however, as we’ve seen in
Listing 1-4
, we’re just going to add a single collection of resources: the
sudo
module.

The next step is to create the
sudo
module. A module is a collection of manifests, resources, files, templates, classes, and definitions. A single module would contain everything required to configure a particular application. For example, it could contain all the resources (specified in manifest files), files and associated configuration to configure Apache or the
sudo
command on a host.

Each module needs a specific directory structure and a file called
init.pp
. This structure allows Puppet to automatically load modules. To perform this automatic loading, Puppet checks a series of directories called the module path. The module path is configured with the
modulepath
configuration option in the
[main]
section of the
puppet.conf
file. By default, Puppet looks for modules in the
/etc/puppet/modules
and
/var/lib/puppet/modules
directories, but you can add additional locations if required:

The automatic loading of modules means, unlike our
nodes.pp
file, modules don’t need to be loaded into Puppet using the
import
directive.

Let’s start by creating a module directory and file structure in
Listing 1-5
. We’re going to create this structure under the directory
/etc/puppet/modules
. We will name the module
sudo
. Modules (and classes) must be normal words containing only letters, numbers, underscores and dashes.

The
manifests
directory will hold our
init.pp
file and any other configuration. The
init.pp
file is the core of your module and every module must have one. The
files
directory will hold any files we wish to serve as part of our module. The
templates
directory will contain any templates that our module might use.

Now let’s look inside our
sudo
module, starting with the
init.pp
file, which we can see in
Listing 1-6
.

Our
sudo
module’s
init.pp
file contains a single class, also called
sudo
. There are three resources in the class, two packages and a file resource.

The first package resource ensures that the
sudo
package is installed,
ensure => present
. The second package resource uses Puppet’s if/else syntax to set a condition on the installation of the
sudo-ldap
package.

Puppet will check the value of the
operatingsystem
fact for each connecting client. If the value of the
$operatingsystem
fact is Ubuntu, then Puppet should install the
sudo-ldap
package.