Pro Puppet (10 page)

Lastly, in this resource we’ve also specified a new attribute,
require
. The
require
attribute is a metaparameter. Metaparameters are resource attributes that are part of Puppet’s framework rather than belonging to a specific type. They perform actions on resources and can be specified for any type of resource.

The
require
metaparameter creates a dependency relationship between the
Package["sudo-ldap"]
resource and the
Package["sudo"]
resource. In this case, adding the
require
metaparameter to the resource tells Puppet that the
Package["sudo"]
is required by the
Package["sudo-ldap"]
resource. Hence, the
Package["sudo"]
resource must and  will be installed first.

Relationships are an important part of Puppet. They allow you to instantiate real world relationships between configuration components on your hosts. A good example of this is networking. A number of resources on your hosts, for example a Web server or an MTA (Mail Transfer Agent), would rely on your network being configured and active before they can be activated. Relationships allow you to specify that certain resources, for example those configuring your network, are processed before those resources that configure your Web server or MTA.

The usefulness of relationships does not end there. Puppet can also build triggering relationships between resources. For example, if a file resource changes, then you can tell Puppet to restart a service resource. This means you can change a service’s configuration file and have that change trigger a restart of that service to ensure it is running with the updated configuration. We’ll see a lot more of these relationships and other metaparameters in
Chapter 3
.

The last resource in the
sudo
class is a file resource,
File["/etc/sudoers"]
, which manages the
/etc/sudoers
file. Its first three attributes allow us to specify the owner, group and permissions of the file. In this case, the file is owned by the
root
user and group and has its mode set to 0440 (currently the mode can only be set using octal notation).

The next attribute,
source
, allows Puppet to retrieve a file from the Puppet file server and deliver it to the client. The value of this attribute is the name of the Puppet file server and the location and name of the file to retrieve.

Let’s break down this value. The
puppet://
part specifies that Puppet will use the Puppet file server protocol to retrieve the file.

The
$puppetserver
variable contains the hostname of our Puppet server. Remember that we created this variable and placed it in our
site.pp
file earlier? Instead of the variable, you could also specify the host name of the file server here.

The next portion of our
source
value tells Puppet where to look for the file. This is the equivalent of the path to a network file share. The first portion of this share is
modules,
which tells us that the file is stored in a module. Next we specify the name of the module the file is contained in, in this case
sudo
. Finally, we specify the path inside that module to find the file.

All files in modules are stored under the
files
directory; this is considered the “root” of the module’s file “share.” In our case, we would create the directory
etc
under the
files
directory and create the
sudoers
file in this directory.

VERSION CONTROL

We’ve created our first Puppet module! Let’s step through what will happen when we connect an agent that includes this module.

1. It will install the
   sudo
package.
   
2. If it’s an Ubuntu host, then it will also install the
   sudo-ldap
package
   
3. Lastly, it will download the
   sudoers
file and install it into
   /etc/sudoers
.
   

Now let’s see this in action and include our new module on the agent we’ve created,
node1.example.com
. Remember we created a node statement for our host in Listing 1.4:

When the agent connects it will now include the
sudo
module. To do this we run the Puppet agent again, as shown in
Listing 1-7
.

In
Listing 1-7
, we’ve run the Puppet agent and connected to the master. We’ve run the agent in the foreground, in verbose mode and with the --onetime option that tells the Puppet agent to only run once and then stop. We can see a configuration run commence on our host:

notice: Starting Puppet client version 2.6.1
info: Caching catalog for node1.example.com
info: Applying configuration version '1272631279'
notice: //sudo/Package[sudo]/ensure: created
notice: //sudo/File[/etc/sudoers]/checksum: checksum changed
 '{md5}9f95a522f5265b7e7945ff65369acdd2' to '{md5}d657d8d55ecdf88a2d11da73ac5662a4'
info: Filebucket[/var/lib/puppet/clientbucket]: Adding
 /etc/sudoers(d657d8d55ecdf88a2d11da73ac5662a4)
info: //sudo/File[/etc/sudoers]: Filebucketed /etc/sudoers to puppet with sum
 d657d8d55ecdf88a2d11da73ac5662a4
notice: //sudo/File[/etc/sudoers]/content: content changed
 '{md5}d657d8d55ecdf88a2d11da73ac5662a4' to '{md5}9f95a522f5265b7e7945ff65369acdd2'
notice: Finished catalog run in 10.54 seconds