Chris's Wiki :: blog/sysadmin/EasyVersusVirtuousSetup

The easy path versus the virtuous path (in system setup)

July 27, 2013

For reasons beyond the scope of this entry I've decided that it's time for me to get my own server somewhere. At one level this is easy; any number of places will give you, say, Ubuntu 12.04 machines and I'd have no problem setting up the relatively minimal web server environment I want from there.

At another level, this is not the virtuous way to set up your server today (especially if it's a virtual server). There are several tools to automatically provision virtual servers through various places' infrastructure and then all sorts of tools to customize the configuration and set up a standardized, repeatable environment. Doing it right, even for a one-off personal server, would be to use these tools instead of just trying to note down everything I did by hand. This would give me repeatable builds for recreating the server in case of a disaster, testing or moving to another provider, and upgrading the operating system (which is sure to be needed someday).

The problem with taking the virtuous path right now is that it would take me a lot more work. I could set up a virtual server by hand tomorrow (and then recreate it from scratch just to make sure that my notes were correct). Simply picking a configuration automation system could take me days of research, never mind learning my chosen system well enough to set everything up and figure out how to embody my somewhat odd requirements in it.

(If I already had a chosen automation system it would be a lot easier, of course. Then it would just be a matter of writing the necessary recipe and that should be simple.)

If I was doing this as a learning exercise it would be one thing (then I might even try out several different systems). But I'm not. My goal is to get my server up and doing something useful without leaving me with a big annoying mess that will cause me pain in the future. And for that, the virtuous path is looking awfully thorny right now.

Comments on this page:

From 80.193.24.91 at 2013-07-27 06:00:33:

Why not just go for something halfway there and use version control for the quickly hand-crafted configs? This will at least get you the most laborious part of it in a repeatable state with little effort. Then lists of required packages etc if that is non-obvious.

Converting to a configuration management tool later on by retro-fitting isn't that difficult when you have time and inclination to do so :)

From 89.70.184.230 at 2013-07-27 08:53:35:

I'd also throw in Blueprint, a tool for getting differences out of installed system. (Unfortunately I haven't used that yet, I just have it on my TODO list.)

About automation, go either Puppet or CFEngine 3.x. To pick one up, you may just flip a coin.

For more insightful choice, here are some (my) arguments:

Puppet has a way of writing plugins (in Ruby)

CFEngine is more a language and what you would do, is to write those plugins in CFEngine's language

CFEngine is written in C, so it uses less resources, it's faster and doesn't require tons of dependencies (could be important on Red Hat derivatives; on Debians Puppet is in standard repository, so somebody already took care of packaging the dependencies)

CFEngine is by design a standalone agent that sometimes may pull some files to apply to the system (but pulling files is not generally a must); Puppet by design talks to Puppet Master, so there should be one (there is a movement of masterless Puppet, but it's not widely announced and talked by Puppet team, and requires some manual work, like adding a cron job). Both these make CFEngine my first choice for personal server.

team building CFEngine is less noisy; I see their blog posts more insightful, less look-at-how-awsome-we-are and more technical (but this, of course, is only a subjective feeling)

CFEngine team is less focused on DevOps trend, and more on general automation -- this results in less DevOps marketing and propaganda

As you may see, I'm slightly skewed in favour of CFEngine.

Anyway, give Blueprint a try on some test server. It may save you manually noting down what you did to personalize the machine.

-- dozzie

Written on 27 July 2013.

«	Communication is work and a corollary

The constraints shaping kernel APIs