Difference between revisions of "Cfengine: Classes"
Colin morey (Talk | contribs) |
(No difference)
|
Latest revision as of 13:55, 23 November 2006
As was seen in the first example cfengine defines many classes which a host is in, based on its flavour of unix, kernel, hostname, the time of day, etc:
Defined Classes = ( 10_141_0 10_141_0_1 32_bit Day22 DiskFree_high_dev1 Hr10 Hr10_Q4 LoadAvg_high_dev1 Min50_55 Min51 November Q4 RootProcs_high_dev1 UserProcs_high_dev1 Wednesday Yr2006 any autofs beowulf_cluster cfengine_2 cfengine_2_1 cfengine_2_1_20 cluster compiled_on_linux_gnu grid i686 ipv4_10 ipv4_10_141 ipv4_10_141_0 ipv4_10_141_0_1 linux linux_2_4_21_47_0_1_ELhugemem linux_i686 linux_i686_2_4_21_47_0_1_ELhugemem linux_i686_2_4_21_47_0_1_ELhugemem__1_SMP_Thu_Oct_19_10_29_49_CDT_2006 net_iface_eth1 net_iface_lo node001 node001_beowulf_cluster redhat scientific scientific_sl scientific_sl_3 scientific_sl_3_0 torque worker )
These classes are a good start, but you'll want to tell cfengine about other classes based on your machine's roles in your cluster. This is done with the groups section:
(Colin's note: groups and classes: are synonymous, and it's almost a matter of style. )
Here's an example from Glasgow:
groups: worker = ( HostRange(node,1-140) ) gridsvr = ( HostRange(svr,016-023) ) disksvr = ( HostRange(disk,032-041) ) # Nicer names for grid servers ce = ( svr016 ) dpm = ( svr018 ) mon = ( svr019 ) ui = ( svr020 ) sitebdii = ( svr021 ) ## Compound groups # Batch system nodes torque = ( ce worker ) # Nodes which look at the autofs system autofs = ( worker ce ui ) # All grid nodes grid = ( worker gridsvr disksvr )
Note that classes can usefully be defined using cfengine's functions.
Defining Classes in Other Sections
cfengine is not limited to classes defined in the groups stanza. Other parts of cfengine can define additional classes based on the results of tests, e.g.,
copy: autofs:: $(skel)/autofs/auto.master mode=0644 dest=/etc/auto.master define=newautofs type=sum
In this case, when auto.master changes the newautofs class is defined.
Some other examples:
shellcommands: worker.runyaim:: # Only define startmom if this looks ok, otherwise withdraw from the batch system "/opt/glite/yaim/scripts/configure_node /opt/glite/yaim/etc/site-info.def WN" umask=022 define=startmom elsedefine=stopmom
This defines the startmom class is YAIM run sucessfully, otherwise defines stopmom
One thing to watch out for is that classes defined by package tests are slightly conterintuitive:
packages: ce:: # httpd to serve CRLs httpd action=install elsedefine=installhttp shellcommands: installhttp:: "/sbin/chkconfig httpd on" umask=022
N.B. that installhttp is triggered with an elsedefine, because it is triggered on the package not being installed - of course by the time the shellcommands run it will have been installed, otherwise the shellcommand doesn't make must sense.
Compound Class Statements
In each of cfengine's class specifiers, classes can be logically grouped. A dot means AND and a pipe symbol means OR:
copy: torque|ui:: # On torque hosts (and the ui) distribute the shadow and password files to avoid problems with account locking, etc. $(skel)/torque/passwd mode=644 dest=/etc/passwd define=localpoolaccounts type=sum $(skel)/torque/shadow mode=400 dest=/etc/shadow type=sum $(skel)/torque/group mode=644 dest=/etc/group type=sum
So here the copy is done for the UI and the batch system boxes.
shellcommands: worker.runyaim:: # Only define startmom if this looks ok, otherwise withdraw from the batch system "/opt/glite/yaim/scripts/configure_node /opt/glite/yaim/etc/site-info.def WN" umask=022 define=startmom elsedefine=stopmom
Here the YAIM command is only executed for hosts in the classes worker and runyaim.
There's a NOT specifier too, which binds more tightly than the others:
copy: # Master server is exempt from default files any.!svr031:: ....
See the documentation for more details.