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:

[root@test1 etc]# puppetca --list
test2.ertw.com
[root@test1 etc]# puppetca --sign test2.ertw.com
Signed test2.ertw.com

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.

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:

file {
    "ntp.conf":
        mode => 644,
        owner => root,
        group => root,
        path => "/etc/ntp.conf",
        source => "puppet://puppet.example.com/files/etc/ntp.conf"
}

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:

service {
    ntpd:
        ensure => true,
        enable => true,
        subscribe => [ File["ntp.conf"], Package[ntp] ]
}

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.