Re: Puzzler: Can cfengine replace make?

[Steve Traugott]

On Tue, Nov 06, 2001 at 09:50:05AM -0500, Ted Zlatanov wrote:
> Steve Traugott <stevegt@TerraLuna.Org> writes:
> >
> > Now, here's the question:  Can anyone see a way to do this once-only
> > type of action cleanly in cfengine?  I've tried several different ways
> > over the years, but I've never been satisfied with the results.  
> 
> I think cfengine can do what you want, but in a different way.  If you
> set it up right, every time you run it you will get the timezone set,
> the ntp config file symlinked, xntpd installed, and ntpdate will run.

That is not what I want to do.  One of our 500-1000 line makefiles
would translate into a *very* long-running cfengine run if written
that way.  

You're talking dozens of installp and rpm executions, as well as gobs
of miscellaneous things like setting license counts and kernel
tunables, not to mention the stray filesystem resize operation.  Most
of these would fail horribly, spewing stderr and non-zero return codes
left and right, because they only need to be done once.  And it would
take 15 minutes or more to grind through them all.

The 'make' equivalent completes in about 10 seconds if there's nothing
to do.

On top of that, that cfengine run would need lots of special checks to
prevent repeating things which *cannot* be run more than once without
seriously breaking the machine; installing and configuring HACMP, for
instance, is not something you want to do more than once.

> Why is that a good thing?  Because cfengine (from my understanding of
> Mark Burgess' goals) is an agent that drives a system towards a stable
> state, instead of assuming that the state is stable once it's been
> achieved.

I would agree that that is a cfengine design goal.  Are we right here,
Mark?  

As near as I can tell, cfengine works best when your machines are
starting from an unknown state and you want to do perpetual
convergence.  It's the computer immunology thing -- assume they're
likely to get sick, and make sure you have the tools to detect and
cure them.  At the same time, you need to expect your machines to
always have a degree of unknown-ness about them, since they started
from an unknown state -- if you didn't use your management toolset to
put the bits there, then you don't know what those bits are.  This
will always make for a small degree of indeterminacy when rolling out
new patches or applications.

A make-like algorithm works best when your machines start from a known
state and you want to keep them that way, with a more deliberate
degree of control over the bits on disk -- you design out the
unknown-ness.  From an immunology standpoint, this is basically
genetic engineering.  ;-)  This is an opportunity that only presents
itself when you are starting from scratch or have the luxury of
reinstalling existing machines, but it's an opportunity I look for and
never pass up.  It does not work well when you are starting from an
unknown state -- go to cfengine.

> Imagine a malicious attacker, for instance, who replaces your xntpd
> binary with something nasty.  If you install xntpd through cfengine
> from a known "good" location, cfengine will remove the bad xntpd if
> the checksums don't match.  If the xntpd binary checksum hasn't
> changed, though, no action will be taken.

Cfengine is good for overwriting the work of both crackers and junior
sysadmins.  ;-)  You get the same thing if you use make+anonymous
rsync, which give you the once-only behavior and a few other things.
Cfengine does a good job of packaging together *some* of these
features in a single language; I'd love to see the rest.

> A *huge* advantage of this approach is that you don't have to jump
> through hoops to get commands to run just once.  You can run the
> cfengine script every day, every hour, every minute if you wish, and
> it will be just as efficient and do the right thing.

I understand, agree with, and use this philosophy for things that
won't impact users or running services.  But you *can't* let a
management tool install and/or reconfigure critical parts of a 24x7
machine at any arbitrary time -- there is actually *no* particular
timeslot you can give it.  The only thing you can do is have some sort
of once-only functionality, and have things happen automatically when
the next window of opportunity presents itself, whether that's a
planned outage or a spontaneous reboot.

> So basically, there shouldn't be a need to do once-only actions with
> cfengine.  If you do need them, then you can certainly simulate them
> with a class defined from "/bin/test -f $SOMEFILE", and "/bin/touch
> $SOMEFILE" in your shellcommands section.

That's the closest I've been able to get to what I'm looking for.  But
it's a lot cleaner to write that in 'make', which is where I keep
ending up.  

Anyone else see a syntax that might work?

Steve
-- 
                        .       .    `   *    
Steve Traugott   ` .  *  +                       
Infrastructure Architect            + `     
stevegt@TerraLuna.Org    '   *  .   '  +`   *   
http://www.stevegt.com/

pgpo6non1Pvif.pgp
Description: PGP signature