www.delorie.com/gnu/docs/cfengine/cfengine-Reference_13.html

search

	Buy GNU books!

GNU cfengine

3.3 Cfengine classes

A cfengine action looks like this:

action-type: compound-class:: declaration

A single class can be one of several things:

• The name of an operating system architecture e.g. ultrix, sun4 etc. This is referred to henceforth as a hard class.

• The (unqualified) name of a particular host. If your system returns a fully qualified domain name for your host, cfagent truncates it so as to unqualify the name.

• The name of a user-defined group of hosts.

• A day of the week (in the form Monday Tuesday Wednesday..).

• An hour of the day (in the form Hr00, Hr01 ... Hr23).

• Minutes in the hour (in the form Min00, Min17 ... Min45).

• A five minute interval in the hour (in the form Min00_05, Min05_10 ... Min55_00)

• A quart hour (in the form Q1, Q2, Q3, Q4)

• An abbreviated time with quarter hour specified (in the form Hr00_Q1, Hr23_Q4 etc.)

• A day of the month (in the form Day1 ... Day31).

• A month (in the form January, February, ... December).

• A year (in the form Yr1997, Yr2001).

• An arbitrary user-defined string. (see the reference manual).

• The ip-address octets of any active interface, in the form (ipv4_192_0_0_1, ipv4_192_0_0,ipv4_192_0,ipv4_192).

A compound class is a sequence of simple classes connected by dots or `pipe' symbols (vertical bars). For example:

myclass.sun4.Monday:: sun4|ultrix|osf::

A compound class evaluates to `true' if all of the individual classes are separately true, thus in the above example the actions which follow compound_class:: are only carried out if the host concerned is in myclass, is of type sun4 and the day is Monday! In the second example, the host parsing the file must be either of type sun4 or ultrix or osf. In other words, compound classes support two operators: AND and OR, written `.' and `|' respectively. Cfengine doesn't care how many of these operators you use (since it skips over blank class names), so you could write either

solaris|irix::

or

solaris||irix::

depending on your taste. On the other hand, the order in which cfengine evaluates AND and OR operations does matter, and the rule is that AND takes priority over OR, so that `.' binds classes together tightly and all AND operations are evaluated before ORing the final results together. This is the usual behaviour in programming languages. You can use round parentheses in cfengine classes to override these preferences.

Cfengine allows you to define switch on and off dummy classes so that you can use them to select certain subsets of action. In particular, note that by defining your own classes, using them to make compound rules of this type, and then switching them on and off, you can also switch on and off the corresponding actions in a controlled way. The command line options -D and -N can be used for this purpose. See also addclasses in the Reference manual.

A logical NOT operator has been added to allow you to exclude certain specific hosts in a more flexible way. The logical NOT operator is (as in C and C++) `!'. For instance, the following example would allow all hosts except for myhost:

action: !myhost:: command

and similarly, so allow all hosts in a user-defined group mygroup, except for myhost, you would write

action: mygroup.!myhost:: command

which reads `mygroup AND NOT myhost'. The NOT operator can also be combined with OR. For instance

class1|!class2

would select hosts which were either in class 1, or those which were not in class 2.

Finally, there is a number of reserved classes. The following are hard classes for various operating system architectures. They do not need to be defined because each host knows what operating system it is running. Thus the appropriate one of these will always be defined on each host. Similarly the day of the week is clearly not open to definition, unless you are running cfengine from outer space. The reserved classes are:

ultrix, sun4, sun3, hpux, hpux10, aix, solaris, osf, irix4, irix, irix64 sco, freebsd, netbsd, openbsd, bsd4_3, newsos, solarisx86, aos, nextstep, bsdos, linux, debian, cray, unix_sv, GnU, NT

If these classes are not sufficient to distinguish the hosts on your network, cfengine provides more specific classes which contain the name and release of the operating system. To find out what these look like for your systems you can run cfengine in `parse-only-verbose' mode:

cfagent -p -v

and these will be displayed. For example, solaris 2.4 systems generate the additional classes sunos_5_4 and sunos_sun4m, sunos_sun4m_5_4.

Cfengine uses both the unqualified and fully host names as classes. Some sites and operating systems use fully qualified names for their hosts. i.e. uname -n returns to full domain qualified hostname. This spoils the class matching algorithms for cfengine, so cfengine automatically truncates names which contain a dot `.' at the first `.' it encounters. If your hostnames contain dots (which do not refer to a domain name, then cfengine will be confused. The moral is: don't have dots in your host names! NOTE: in order to ensure that the fully qualified name of the host becomes a class you must define the domain variable. The dots in this string will be replaced by underscores.

In summary, the operator ordering in cfengine classes is as follows:

`()'

Parentheses override everything.

`!'

The NOT operator binds tightest.

`.'

The AND operator binds more tightly than OR.

`|'

OR is the weakest operator.