Automate System Administration Tasks with Puppet

substituting the name of your puppetmaster
for puppet.example.com, which creates the user and directory structure on
the client, and then begin the SSL key exchange between the client and
the server. You will get an error about certificate validation, because
the certificates are not trusted yet.

Back on the puppetmaster, run puppetca --list to show the outstanding
certificate requests. You then can use puppetca
--sign to accept the
certificate, as shown below:

At this point, the client and server have a mutually trusted connection. The
next step is to define the manifest. For this article, I'm using the network
time protocol (NTP) dæmon as an example. The goal is to define a
manifest that ensures the dæmon is installed, configured and in the boot
sequence.

Defining the Manifest

In Puppet terms, a resource is something being managed and the attributes
that define it. A resource might be a file that has permission attributes
or a package with a name and a version. Puppet comes bundled with many
resource types; you also can create your own or download those that
others have made.

The central manifest is defined in /etc/puppet/manifests/site.pp. Start
with a simple resource defining the NTP package:

package {
ntp:
ensure => installed
}

The above defines a package resource called ntp with one
attribute called ensure. The ensure attribute defines the state
of the package, with values such as installed, absent, latest
or even a version number.

Puppetmaster will notice the change in site.pp and reload the
manifest. The client will check in only every half-hour, so you can
restart puppetd or send the process the SIGUSR1 signal to force the
client to check back with the server immediately. If all goes well,
your client will read the manifest and install the ntp package. Try
removing the package, and it will be replaced within 30 minutes.
If not, check your logs (usually /var/log/messages) for any errors,
and make sure your site.pp is correct.

NTP also requires a configuration file called /etc/ntp.conf. Puppet has a
resource type called file that handles files. The puppetmaster will hold the
master ntp.conf and copy it to the clients should they change their copies.

Create a directory in /var/puppet called files. Then, create
/etc/puppet/fileserver.conf as shown below, and restart puppetmasterd:

[files]
path /var/puppet/files
allow *

fileserver.conf defines file shares for the internal Puppet file server. The
above example implements a share called files, which corresponds to a
directory on the puppetmaster called /var/puppet/files. Use a URL like
puppet://puppet.example.com/files/etc/ntp.conf to access a file located
at /var/puppet/files/etc/ntp.conf on the puppetmaster. The allow
* grants
access to all puppet clients.

Put a working ntp.conf in /var/puppet/files/etc/, and then add the
following to your existing site.pp:

The format of this file resource is much like the package you previously
set up. The resource has a tag of ntp.conf (which is quoted because of the
period). The mode, owner and group attributes specify the file's
permissions. The path attribute is the local path, which, if omitted,
defaults to the value of the tag (the tag does not have a full path in
this case, however). Finally, the file's source is a puppet URI that
will be pulled from the puppetmaster.

Restart the puppet dæmon on the client (or wait 30 minutes), and you
will see ntp.conf has been updated. If you try to change it, you will
see that it is replaced in the next cycle.

The final resource needed is the service resource, whose job is to make
sure a dæmon is running and that the dæmon is in the startup scripts (or
not, if that's your desire). Add the following fragment to your site.pp:

The service resource handles the ntpd service. The ensure attribute makes
sure the dæmon is running, and the enable attribute makes sure it is part
of the startup script. The mechanics of this are handled by a provider, and each OS and distribution can have a different provider for each type
of service. On Red Hat and Fedora systems, the service provider uses the
chkconfig and service utilities.

The subscribe attribute brings the three resources together. The service
resource is subscribed to the ntp.conf file resource and the ntp package
resource. If any one of them change, the service resource is notified, which is
an indication that the service should be restarted. This means you can push out
changes by editing the master file on the puppetmaster, and on the next cycle,
the client will download the new configuration and restart the dæmon without
your intervention.

The subscribe attribute can take either a single element, such as
Package[ntp], or multiple elements written in array format, such as
[ element1, element2]. Also be careful to capitalize the reference,
as the lowercase version has been deprecated and will not work at some
point in the future.

I really like your organization. Puppet is a great tool. One more area for people to look into is the use of templates. They're a very powerfully addition to puppet, leveraging ruby's erb files.

Erb files probably get the greatest exposure in ruby on rails, but can prove to be a very powerful tool for system administrator in lending a hand to remove human error when managing the differences in configuration between different environments.

Speaking of environments, that's also great asset puppet provides and should be considered another area of interest for potential adopters of puppet to look into.