Node:Running user scripts, Next:Compressing logs, Previous:Disabling and the file repository, Up:Global configurations
Above all, the aim of cfengine is to present a simple interface to
system administrators. The actions which are built into the engine are
aimed at solving the most pressing problems, not at solving every
problem. In many cases administrators will still need to write
scripts to carry out more specific tasks. These scripts can still be
profitably run from cfengine. Variables and macros defined in cfengine
can be passed to scripts so that scripts can make maximal advantage of
the class based decisions. Also note that, since the days of the week
are also classes in cfengine, it is straightforward to run weekly
scripts from the cfengine environment (assuming that the configuration
program is executed daily). An obvious use for this is to update
databases, like the fast-find database one day of the week, or to run
quota checks on disks.
shellcommands: myhost.Sunday:: "/usr/bin/find/updatedb"
Cfengine scripts can be passed variables using normal variable
substitution:
control: cfbin = ( /local/gnu/lib/cfengine/bin ) backupdir = ( /iu/dax/backup ) shellcommands: "$(cfbin)/cfbackup -p -f $(backupdir) -s /iu/nexus/u1"
If you need to write a particularly complex script to expand cfengine's capabilities, it might be useful to have full access to the defined classes. You can do this in one of two ways:
$(allclasses)
to the script. This contains a
list of all classes in the form of a string
CFALLCLASSES=class1:class2:...
This variable always contains an up to date list of the defined classes.
-u
or --use-env
. When this
is defined, cfengine defines an internal environment variable
called CFALLCLASSES
which contains the same list as above.
Unfortunately, system 5 boxes don't seem to like having to update
an environment variable continuously and tend to dump core, so
this is not the default behaviour!