[UFO Chicago] syncing multiple workstations to one master

[Jesse Becker]

--- On Thu, 9/1/11, Nick Moffitt <nick at zork.net> wrote:
From: Nick Moffitt <nick at zork.net>
Subject: Re: [UFO Chicago] syncing multiple workstations to one master
To: ufo at ufo.chicago.il.us
Date: Thursday, September 1, 2011, 8:58 AM

Calvin Pryor:
>> I know I read something somewhere about a Linux/Debian type tool that
>> will sync multiple computers to one "master". You just make changes to
>> the master (updates, etc) and the changes are magically propagated to
>> all others computers set up to do so.
>> 
>> What am I thinking of ?

>Configuration management, as a whole.  Most likely Puppet, which is the
>Least Bad of all the options out there right now.  Possibly older and
>more broken/dangerous systems like CFEngine, or newer and equally
>dangerous systems like Chef.

I'm going to have to take issue with the "broken/dangerous" comment about CFEngine and the other tools.  Configuration management is a *hard problem* if you are doing anything besides a "golden master" sort of replication.  Of the three tools you mentioned (and a host you omitted, like BCF2, LCFG, SmartFrog, among others), I posit that CFEngine is probably the most mature, has the most amount of solid research behind it in terms of operation and theory, and one of the smallest resource footprints of the main alternatives.

CFEngine version 1.5.4 dates back to 2000-3-2, and that's far from the oldest released version.  Development has been pretty constant since then, with version 2.0 appearing almost exactly 2 years later (2002-3-12), and version 3.0 showing up at the end of December 2008.  The community is active, and well supported.  Puppet was created after CFEngine (IIRC, the lead developers for CFEngine and Puppet had a fairly nasty falling out), and Chef sometime after that.  BCF2 and LCFG both have long histories, but I don't think they go back quite as far.

It is also based on a large amount of research into making sure that the tool is *NOT* "dangerous", and does in fact properly implement your configuration rules.  For the curious, here are a series of publications, starting in 1993 and going more or less to the present, based on CFEngine and the field of Promise Theory:   https://cfengine.com/science/.  The more recent papers directly tie into the development of version 3.x, and much of it quite interesting.

While someone managing a series of workstations may not care much (as the original poster said he was doing), the footprint of your CM tools is very important when dealing with large server farms.  CFEngine is written in C.  Most--but not all--of the other CM tools are either Java, Perl, Python (which isn't so bad), or Ruby.  I'll cite http://www.usenix.org/publications/login/2010-02/pdfs/bjorgeengen.pdf and http://blog.normation.com/2011/02/23/why-we-use-cfengine-memory-footprint/ as references, in addition to my own experience (which deals with managing several HPC clusters).

So why, exactly, is CFEngine "broken/dangerous?"  I'll be the first person to tell you it has warts, and is far from perfect (no software is, really).  And while version 3.x is a *huge* improvement over 2.x in pretty much every way possible, but could still be improved further.  

I'll propose that cfengine is no more dangerous than any other tool in the toolbox.  For example 'rm' is pretty dangerous--it can remove your files.  So can cfengine ('files: "/path/file" delete => tidy";' does that nicely), but does that make either of the broken?  Probably not.  In fact, given you can guard exactly where and how the delete rule is run in cfengine, there's an argument that it is less broken than, say, trying to automate a series of remote SSH calls.

So, this is far longer than I intended, and not a flame--believe it or not--but I would like to what the basis of your comments are.  I really would like to know how these tools are broken (aside form the usual coding bugs you find in *all* software), and adjust accordingly if needed.

Cheers,

--
Jesse Becker