Puppet at CSAIL

For the past several years, we have used a confusing and ill-specified mixture of FAI, the automatic CSAILUbuntu installer, and cfengine to manage our Linux systems. Puppet is a newer, more flexible configuration-management system, and we are looking to replace the old FAI/cfengine system with Puppet as we replace systems. We are also trying to bring our FreeBSD systems under configuration management, to reduce the likelihood of bus-fault failures.

This page will summarize the various things we’ve done with Puppet and some of the pitfalls we’ve run into, and also include links to the Puppet modules we’ve either written or rewritten to meet our needs. Where practical, we are providing a clonable Git repository so that others can easily take advantage of what we’ve done; we welcome input from the Puppet community.

General issues

We’ve found that many of the PuppetForge modules are rather less useful than they first appear (“of course it’s cross-platform – it works on both Fedora and Ubuntu”). This requires us to keep our own private repositories for many of these modules rather than being able to reference the official public source. Whether the repository is local or remote, Git submodules are a real pain (albeit less painful than the other ways of doing the same thing in Git) – that’s particularly true when we need to support read-write access by administrators and read-only access by the Puppet servers to these shared repositories using the same URL across all systems (which do not all implement a shared filesystem).


Our Hiera hierarchy is organized as follows: 1 $::fqdn 2 $::group 3 $::role 4 $::osfamily 5 common

group and role are custom facts defined in /etc/facter/facts.d at installation time, and are used to identify the research group (Vision, Computer Architecture, Theory of Computation, etc.) and function (workstation, compute server, NFS server, etc.) for each system. common includes site-wide defaults such as IP addresses of management workstations, system administrator mailing-lists (who gets root@ mail) and similar variables that either don’t vary at all across CSAIL or vary only across a limited subset of CSAIL machines. Because some of the configuration is either private or security-sensitive, we are not sharing the contents of our Hiera data files.

We would like to encourage all Puppet sites to implement a few standard Hiera variables; adopting a common practice would greatly improve the default out-of-the-box usability of many Puppet modules, and the modules that we are distributing here often depend on them. Currently, these are:

Modules we have implemented

(Links are git cloneable and also browsable using gitweb. Note that our modules require the use of a pkgng Puppet package provider and appropriate pre-compiled packages on FreeBSD.)

Modules from elsewhere that we have hacked on

Modules that we were able to adopt without significant changes