Puppet – server management made easy

So let’s get into the details: first we define that the module requires the file /etc/ntp.conf, which has the permission bits set as 644. The contents of the file are taken from the template named ntpconf.erb, which we’ll explain in a moment.

Then we define a variable named $ntp_service, because the service name differs from system to system: on Debian (and many other Linux systems) the service is called just ntp, while on FreeBSD its name is ntpd. We check the pre-defined variable $operatingsystem to decide which value the variable $ntp_service gets.

Another difference between Debian and FreeBSD is the package names. It’s even more complex: ntp is a package on Debian, while on FreeBSD it’s installed already as part of the base system. Therefore, we check the operating system the client is running on and ensure the ntp package is installed on Debian, while we do nothing on FreeBSD. On Debian, we also ensure that the package is installed before we run the ntp service.
The last part of the ntp configuration is the service. We ensure it is running and we enable its init script. By default, Puppet watches the process with the same name as the service to know when it has to restart it, but if the name differs, we can set it explicitly here. On both Debian and FreeBSD, the process is called ntpd, but we can add other names for other operating systems. In the last line, we let the service subscribe to the /etc/ntp.conf file, which means that the service will be restarted when the file is changed by a Puppet configuration change.

Now the only thing that is left is the template for the file ntp.conf. We place this in /etc/puppet/modules/ntp/templates/ntpconf.erb:

# Generated by Puppet
# DON’T EDIT!!!
server 0.<%= country %>.pool.ntp.org iburst
server 1.<%= country %>.pool.ntp.org iburst
server 2.<%= country %>.pool.ntp.org iburst
server 3.<%= country %>.pool.ntp.org iburst

Now when Puppet sees the line mentioning template(“ntp/ntpconf.erb”), it looks at the file ntpconf.erb in the templates directory of the ntp module. This template file is written in ERB, Ruby’s templating system. So the file just lists some plain text, but you can add Ruby code or variables inside special tags. In our example, we used this to add the value of the variable country. Remember the file /etc/puppet/manifests/nodes.pp? There we added the line ‘$country = “us” ’ to our node. Combining this with the template for /etc/ntp.conf, we let each node use a local ntp server in its own country.

Puppets on a string
So now that we have written our first Puppet module, we have to apply this configuration to all our nodes. You can test this on each node by issuing the following command:

# puppetd --test

If all goes well, you see some messages. Now after the configuration has been applied, check whether /etc/ntp.conf has the right contents, whether ntp is installed and whether the service is running. Now if you change something locally, for example by changing /etc/ntp.conf manually, and then rerun puppetd, you’ll see that Puppet notices the change and reverts it. Or if you remove the ntp package, Puppet will reinstall it the next time it runs. The following is an example output showing the latter event:

# puppetd -test
info: Caching catalog at /var/lib/puppet/state/localconfig.yaml
notice: Starting catalog run
notice: //ntp/Package[ntp]/ensure: created
info: Sent transaction report in 0.42 seconds
notice: Finished catalog run in 2.50 seconds

So you see that Puppet notices the absence of the ntp package and installs it. If all works, it’s time to enable and start the Puppet service on the client instead of starting it manually. You can even write a Puppet module for it, which we’ll leave to the reader as an exercise.

Puppet Dashboard
A relatively new project is Puppet Dashboard, a web interface for Puppet. It provides a quick way to see the status of recent Puppet runs, including charts of failure percentages and an activity feed of recent changes to your nodes. You can also click on a specific node to view the configuration of the node, status information for recent Puppet runs on the node, a list of configuration changes made and so on. You can also update or remove nodes.

For now, you still have to build the source code of Puppet Dashboard yourself, as it hasn’t been packaged yet in mainstream Linux distributions. The program requires Ruby, Rake, MySQL and the Ruby MySQL bindings. Support for other databases is expected to come. After starting the Dashboard server, which is a Ruby on Rails application, you can reach the web interface on port 3000 of localhost.

Puppet recipes
While this article only scratched the surface of Puppet, the example module shows a lot of the concepts of this configuration management solution. You can find more information about the possibilities on the project’s website. The wiki also has an extensive language tutorial and a lot of ‘Puppet recipes’, which are modules written by other users for specific services.

You can learn a lot by reading these modules and adapting them for your own needs. The next time you have to manage or install a specific service on one of your servers, try to write a Puppet module for it. This requires more time and effort upfront than just manually installing and configuring it, but will save you a lot of time in the long run.