Re: Puzzler: Can cfengine replace make?

[Ted Zlatanov]

Steve Traugott <stevegt@TerraLuna.Org> writes:

> Now look at the flow for xntpd.  On the first boot after the machine
> is installed, these stanzas will execute, in this order:
>
>       set_timezone
>       ntp_config
>       ntpdate
>       xntpd
>
> ...of those four, they all do a 'touch' of a stampfile except ntpdate.
> That means that the timezone will be set once, the ntp config file
> symlink will be set once, ntpdate will run, and then xntpd will be
> installed once, at first boot only, for the life of the machine.  Make
> sense?
>
> But ntpdate will still run every time, at each subsequent boot.  Still
> make sense?
>
> 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.

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.

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.

Or say that someone changes your timezone by mistake.  Cfengine would
go and fix that, and optionally run some extra commands afterwards
(you can define classes when editing is successful).  The overhead is
minimal unless cfengine needs to actually edit the file.

Or say that the ntp config symlink gets erased by accident.  Next time
you run cfengine, it will recreate it.

Essentially, you are paying a little CPU and I/O time every time you
run the script, and you won't be affected if a problem does occur.

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.

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.

Thanks
Ted