Steven Van Acker

E-mail: steven AT singularity DOT be
Gothenburg, Sweden

Puppet

24 Mar 2008 There was a time when I was very openminded and pragmatic. Sadly though, I've been pushed into some kind of defensive posture for a while now because everyone keeps attacking me on my choice to use Debian and Debian derivatives over anything else. Because of this, a lot of my replies can be snappy and condescending.

I'll apologize for that right now :)

One of the readers (Karanbir Singh) of this blog (who ever thought people would be reading this) suggested that I look at Puppet or CFEngine as a better means of maintaining a large number of servers.
At first I was very sceptic about this solution and replied very quickly that it was probably no good in my case. However, after thinking about it for a while walking in the snow (yes, spring has just begun and its snowing... this global warming thing is starting to act up) I realised that it is (or could be) actually a nice solution.

Current approach

My current approach to maintain lots of Debian servers is based on some kind of server templates. I've finetuned a Debian install CD to do a fully automated installation using preseeding. The installation CD makes sure my server is setup with the correct network settings, correct firewall, correct partition scheme, debian repositories and a whole lot more stuff. In addition, the installation process installs a virtual package (or metapackage, if you want to call it that) which depends on a lot of other software. This list of software consists of all the tools that are commonly used on all servers.

The result is the installation is a clean empty server, more or less like a stemcell. From this base, some extra software can be installed and some configuration changed to shape it into its final form.

A webserver for example will start from a base installation, which takes care of things like postfix config, backup schedules, syslog configuration, SSH-keys for maintenance, ... etc.
On top of that, I just install apache with apt-get, change the configuration of apache, and its done.

This process is very easy to document, because the documentation only needs to consist of the parameters I passed to the installation process (basically, servername and IP address), and the command "apt-get install apache" and a copy of the apache configuration.

Considering the state of the servers I found when I started working at the university, my installation CD and process were a major revolution. I will not regress to the previous way of managing the servers.

Trying CentOS and Puppet

Now I'm trying CentOS. I wanted to use the same approach to maintaining CentOS servers as I used for Debian servers. But CentOS is obviously different.

Instead of trying the tried-and-true method to maintain my Debian servers on CentOS servers, maybe I should try Puppet.
I have seen talks about Puppet on several occasions, but I always assumed that I would need to have a central configuration server accessible by all other servers. This contradicts what my paranoid mindset tells me to do: build network security in layers. Allow connections outward, but limit inward connections as much as possible.
Maybe Puppet can also push configurations to servers instead of having the data going the other way. And then still, I could setup a central configserver with a copy of the real data, and push the data onto it from the central configserver.

Enough ways of satisfying my mind.

So how do I map my current setup on Puppet ? I don't know yet.
Some elements that are needed:


Maybe I need more, but I'll start with this. I've joined the #puppet channel on freenode IRC to see what kind of souls roam there, and I have found them very helpful. If I run into problems, I'm sure I can ask them there.

An interesting blog with posts on Puppet: http://plathrop.tertiusfamily.net/blog/