Cfengine Notes

Use this area to put miscellaneous notes that don't quite fit into other areas.

Run 'cf-agent -B' to repair the working cfengine config in /var/cfengine/inputs based on the failsafe configuration.

Classes are defined in Bundles stanzas.¹⁾ Bundles of type common yield classes that are global in scope, whereas in all other bundle types classes are local in scope.

The sequence in which the different parts of a bundle are processed in version 3.1.0 are summarised here:

char *TYPESEQUENCE[] =
   {
   "vars",
   "classes",
   "outputs",
   "interfaces",
   "files",
   "packages",
   "environments",
   "methods",
   "processes",
   "services",
   "commands",
   "storage",
   "databases",
   "reports",
   NULL
   };

char *EDITLINETYPESEQUENCE[] =
   {
   "vars",
   "classes",
   "delete_lines",
   "field_edits",
   "insert_lines",
   "replace_patterns",
   "reports",
   NULL
   };

Classes may be combined with these operators, listed here in order from highest to lowest precedence:

Special variables are documented at cfengine.org. Below are mention of a few:

For complex promises, it is often helpful to have debugging messages appear using the reports: stanza, but once a promise is working properly these messages may no longer be desired. Rather than deleting them (assuming they may be helpful at some future date when the promise is further developed) it is handy to set a class to enable and disable them.

For example, we can set a private class called “debug” that can be enabled and disabled easily, and then use it to decide whether to issue certain reports:

  classes:
    any::
      "debug" expression => strcmp("1","0");  #|Default is 'disabled'.

  reports:
    iptables_backup.debug::
      "Backup file is $(ipt_bkup_file)";
    fw_apache.firewall_changed.debug::
      "Apache rules inserted";

To enable the debugging messages just pass ”–define debug” on the command line. For example, if the above was in a bundle called “firewall” you might use this command to run it with debugging enabled:

cf-agent -IKb firewall -f ./promises.cf --define debug

Regarding the different stanzas of Cfengine policy files, I found this is on the Cfengine forum:

Bundles and bodies are different syntax parsers. You can see that the bundle generic syntax is:

<section>:
  [<class_expression>::]
    "<item>" <property> => <value> [, <property> => <value> ...];

while the body generic syntax is shorter a bit:

  [<class_expression>::]
    <property> => <value>;

Accordingly, bodies are only used as property containers while bundles are only used for promises definitions. The control bodies are an exception to the naming convention: the control word comes third, not second, and they define the Cfengine component controls.

In version 3.1.0 I observed a bug that always writes a file if the “preserve_block” option is used. The bug is filed in Cfengine's Bug Tracker at this URL.

Repeating patterns (i.e., those using *, +, or ?) are “elastic”: they will start by occupying as much as possible and leaving the remainder of the string for the rest of the pattern to attempt to match. Then, if no match is found, the elastic components “contract” to match less and less in an attempt to get the rest of the pattern to match.

So if you have a string “enabled = 0” and a pattern of ”=\s*[^0]” (match an equality sign plus any number of spaces plus a character that is not zero) the “\s*” first matches the space after the equality sign, but then the [^0] does not match so the spaces contract (all the way down to “zero spaces” due to '*') at which point the “[^0]” matches the space that was surrendered by the “contraction” of the elastic “\s*” part of the pattern.