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!