Running user scripts

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:

• Pass the variable $(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.
• Use the command line option `-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!

Go to the first, previous, next, last section, table of contents.