cron
One of cfengine's strengths is its use of classes to identify systems
from a single file or set of files. Many administrators think that it
would be nice if the cron daemon also worked in this way. One possible
way of setting up cron from a global configuration would be to use the
cfengine editfiles facility to edit each cron file separately. A
much better way is to use cfengine's time classes to work like a user
interface for cron. This allows you to have a single, central cfengine
file which contains all the cron jobs on your system without losing any
of the fine control which cron affords you. All of the usual advantages
apply:
The central idea behind this scheme is to set up a regular cron
job on every system which executes cfengine at frequent intervals.
Each time cfengine is started, it evaluates time classes and
executes the shell commands defined in its configuration file.
In this way we use cfengine as a wrapper for the cron scripts,
so that we can use cfengine's classes to control jobs for mulitple
hosts. Cfengine's time classes are at least as powerful as cron's
time specification possibilities, so this does not restrict you
in any way, See section Building flexible time classes. The only price
is the overhead of parsing the cfengine configuration file.
To be more concrete, imagine installing the following `crontab' file onto every host on your network:
# # Global Cron file # 0,15,30,45 * * * * /usr/local/cfengine/inputs/run-cfengine
This file contains just a single cron job, namely a script which calls cfengine. Here we are assuming that you will not want to execute any cron script more often than every fifteen minutes. If this is too restrictive, the above can be changed. We refer to the time interval between runs of the script `run-cfengine' as the `scheduling interval' and discuss its implications in more detail below.
The script `run-cfengine' would replace any `cfdaily' or `cfhourly' scripts which you might have, and can as simple as this
#!/bin/sh # # Script run-cfengine export CFINPUTS=/usr/local/cfengine/inputs /usr/local/gnu/bin/cfengine # # Should we pipe mail to a special user? #
or it could be more fancy. You could also use the `cfwrap' script, See section cfwrap, if you have perl on all your systems, to pipe mail to the mail address described in the cfengine file, See section sysadm.
# # Global Cron file # 0,15,30,45 * * * * path/cfwrap path/run-cfengine
You might not want to run your entire system configuration `cfengine.conf' every time cron fires up cfengine. An alternative would be to keep a separate fil for cron jobs called, say, `cf.cron'. You would then replace the `run-cfengine' file by
#!/bin/sh # # Script run-cfengine export CFINPUTS=/usr/local/cfengine/inputs /usr/local/gnu/bin/cfengine -f cf.cron # # Should we pipe mail to a special user? #
There is no particular advantage to doing this unless you are running cfengine on some very slow hardware. A better way to approach the problem is to think of the `cf.cron' file as a module which can be imported into the main configuration file. This gives you the maximum amount of flexibilty, since it allows you to decide exactly what you want to happen any any given time from the central file.
Go to the first, previous, next, last section, table of contents.