https://www.gridpp.ac.uk/w/index.php?title=Cfengine:_Running_scripts_with_cfengine&feed=atom&action=historyCfengine: Running scripts with cfengine - Revision history2024-03-28T21:55:26ZRevision history for this page on the wikiMediaWiki 1.22.0https://www.gridpp.ac.uk/w/index.php?title=Cfengine:_Running_scripts_with_cfengine&diff=1615&oldid=prevGraeme stewart at 10:57, 22 November 20062006-11-22T10:57:57Z<p></p>
<p><b>New page</b></p><div>A great deal of power in [[cfengine]] derives from its ability to call other scripts and commands in its "shellcommands" section.<br />
<br />
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:<br />
<br />
<pre><br />
group:<br />
worker = ( HostRange(node,1-140) )<br />
<br />
control: <br />
any::<br />
actionsequence = ( <br />
copy<br />
shellcommands<br />
) <br />
<br />
copy:<br />
worker::<br />
$(skel)/worker/etc/gmond.conf mode=0644 dest=/etc/gmond.conf define=newgmon type=sum<br />
<br />
<br />
shellcommands:<br />
newgmon::<br />
"/sbin/service gmond restart" umask=022<br />
</pre><br />
<br />
For our worker nodes the <tt>gmond.conf</tt> file is controlled by cfengine. If it changes then the new copy is installed and a new class, <tt>newgmon</tt> is set for this host. Then in the shellcommands section cfengine restarts <tt>gmond</tt>, so that it will re-read this new configuration file.<br />
<br />
===Umask: a big gotcha===<br />
<br />
Notice above we set <tt> umask=022</tt> 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.<br />
<br />
===Setting Classes Inside shellcommands===<br />
<br />
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:<br />
<br />
<pre><br />
shellcommands:<br />
ce.setuptorque::<br />
# This is a bit too complex and fiddly to do directly<br />
# Note - torque needs to be running to set it up!<br />
"/sbin/service maui restart" umask=022<br />
"/sbin/service pbs_server restart" umask=022<br />
"/var/cfengine/inputs/scripts/torque_admin_cfg" umask=022 define=starttorque elsedefine=stoptorque<br />
"/var/cfengine/inputs/scripts/torque_queue_cfg $(torquequeues)" umask=022 elsedefine=stoptorque<br />
<br />
ce.starttorque::<br />
"/sbin/chkconfig pbs_server on" umask=022<br />
"/sbin/chkconfig maui on" umask=022<br />
"/sbin/service pbs_server start" umask=022<br />
"/sbin/service maui start" umask=022<br />
<br />
ce.stoptorque::<br />
# Trouble 't mill...<br />
"/sbin/chkconfig pbs_server off" umask=022<br />
"/sbin/chkconfig maui off" umask=022<br />
"/sbin/service pbs_server stop" umask=022<br />
"/sbin/service maui stop" umask=022<br />
</pre><br />
<br />
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.<br />
<br />
[[Category:cfengine]]</div>Graeme stewart