SLUG Mailing List Archives
Re: [SLUG] Most valuable free/OSS software that doesn't exist?
- To: slug@xxxxxxxxxxx
- Subject: Re: [SLUG] Most valuable free/OSS software that doesn't exist?
- From: Gavin Carr <openfusion@xxxxxxxxxxxxx>
- Date: Mon, 15 Nov 2004 14:03:21 +1100
- Organisation: Open Fusion
- User-agent: Mutt/1.4.1i
On Mon, Nov 15, 2004 at 01:15:39PM +1100, Jamie Wilkinson wrote:
> This one time, at band camp, James Gregory wrote:
> >I've also heard of people storing all of /etc in version control for
> >this purpose. In my opinion it would be unnecessary if you kept your
> >cfengine stuff in a source control system, but it would give you that
> >absolute confidence that you could roll back and forward, even if
> >cfengine failed.
> cfengine vs all-etc-in-vc is like procedural vs functional programming;
> one of them lets you describe in detail how the operation is going to be
> done, the other one lets you describe the problem. That's probably not a
> good analogy, but with cfengine I can describe the goal state of the system
> and have cfengine sort out what needs to be done to get it there.
Except that that assumes describing the goal state is about the same complexity
(or easier) as making the changes directly. In my playing around with cfengine
I've found the learning curve and the extra layer of indirection mostly
annoying, rather than helpful. Usually I know the changes I want to make in
/etc; it's faster just to go ahead and do it than figure out how to convince
cfengine to do the same thing.
> etc and rolling out changes also means handling heterogenous systems adds
> complexity to the system you use; cfengine effectively "factors out" the
> common parts and lets you describe the small changes meaningfully.
True enough - where cfengine really seems to shine is in large heterogenous
networks (e.g. >= 25 machines). OTOH, most of the server environments I
encounter are much smaller than that; typically 5-15 machines, and usually
mostly or all Linux. In this kind of environment I've found cfengine to be
overkill - the learning curve for the local admins is just too much to
justify the benefits.
I'm currently experimenting with a etc-in-vc model instead (though storing
only the deltas from base OS versions, not the full etc tree), and using
arch branches to manage machine classes, so that changes get propogated via
inheritance down the tree i.e.
etc--all # Common stuff
etc--web # Webserver configs
etc--app # Appserver configs
etc--db # Database configs
So far it's working pretty well, and much more fun that battling cfengine