Cfengine: Running scripts with cfengine

From GridPP Wiki
Revision as of 10:57, 22 November 2006 by Graeme stewart (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

A great deal of power in cfengine derives from its ability to call other scripts and commands in its "shellcommands" section.

When this is combined with the ability to set classes on the fly cfengine becomes a very useful tool indeed. Here's an example for ganglia:

group:
        worker = ( HostRange(node,1-140) )

control: 
        any::
                actionsequence = ( 
                        copy
                        shellcommands
                        ) 

copy:
        worker::
                $(skel)/worker/etc/gmond.conf mode=0644 dest=/etc/gmond.conf define=newgmon type=sum


shellcommands:
        newgmon::
                "/sbin/service gmond restart" umask=022

For our worker nodes the gmond.conf file is controlled by cfengine. If it changes then the new copy is installed and a new class, newgmon is set for this host. Then in the shellcommands section cfengine restarts gmond, so that it will re-read this new configuration file.

Umask: a big gotcha

Notice above we set umask=022 against the shellcommand. This is important because the default umask for cfengine's shellcommands is the very conservative 077. If any files are written which need to be world readable (e.g., running YAIM) then cfengine will have done the wrong thing and your site will be broken.

Setting Classes Inside shellcommands

As with most cfengine commands, further classes can be set is the shell command's exit status is 0 or not. This can then trigger further actions:

shellcommands:
       ce.setuptorque::
                # This is a bit too complex and fiddly to do directly
                # Note - torque needs to be running to set it up!
                "/sbin/service maui restart" umask=022
                "/sbin/service pbs_server restart" umask=022
                "/var/cfengine/inputs/scripts/torque_admin_cfg" umask=022 define=starttorque elsedefine=stoptorque
                "/var/cfengine/inputs/scripts/torque_queue_cfg $(torquequeues)"  umask=022 elsedefine=stoptorque

        ce.starttorque::
                "/sbin/chkconfig pbs_server on" umask=022
                "/sbin/chkconfig maui on" umask=022
                "/sbin/service pbs_server start" umask=022
                "/sbin/service maui start" umask=022

        ce.stoptorque::
                # Trouble 't mill...
                "/sbin/chkconfig pbs_server off" umask=022
                "/sbin/chkconfig maui off" umask=022
                "/sbin/service pbs_server stop" umask=022
                "/sbin/service maui stop" umask=022

Notice how the exit status from the torque setup scripts are used to either make sure the batch system is started or forced to stop.