[Classes][classes and decisions] fall into hard (discovered) and soft (defined) types. This reference documents the hard classes that might be set by CFEngine, and soft classes used by CFEngine’s default policy.

Listing Classes

To see hard classes and soft classes defined in common bundles on a particular host, run cf-promises --show-classes as a privileged user.

Example:

console [root@hub masterfiles]# cf-promises --show-classes Class name Meta tags 10_0_2_15 inventory,attribute_name=none,source=agent,hardclass 127_0_0_1 inventory,attribute_name=none,source=agent,hardclass 192_168_33_2 inventory,attribute_name=none,source=agent,hardclass 1_cpu source=agent,derived-from=sys.cpus,hardclass 64_bit source=agent,hardclass Afternoon time_based,source=agent,hardclass Day22 time_based,source=agent,hardclass ...

Note that some of the classes are set only if a trusted link can be established with [cf-monitord][cf-monitord], i.e. if both are running with privilege, and the /var/cfengine/state/env_data file is secure.

You can also use the built-in classesmatching() function to get a list of all the defined classes in a list, inside CFEngine policy itself. classesmatching() is especially useful because it also lets you specify tag regular expressions.

See also: The --show-vars option.

Tags

Classes and variables have tags that describe their provenance (who created them) and purpose (why were they created).

While you can provide your own tags for soft classes in policy with the [meta][Promise Types and Attributes#meta] attribute, there are some tags applied to hard classes and other special cases. This list may change in future versions of CFEngine.

Enterprise only:

Hard Classes

Soft Classes

Soft classes can be set by using the -D or --define options wihtout having to edit the policy. Multiple classes can be defined by separating them with commas (no spaces).

console $ cf-agent -Dclass

or

console $ cf-agent --define class1,class2,class3

This can be especially useful when requesting a remote host to run its policy by using cf-runagent to activate policy that is normally dormant.

console $ cf-runagent -Demergency_evacuation -H remoteclient

If you’re using dynamic inputs this can be useful in combination with cf-promises to ensure that various input combinations syntax is validated correctly. Many people will have this run by pre-commit hooks or as part of a continuous build system like Jenkins or Bamboo.

console $ cf-promises -f ./promises.cf -D prod $ cf-promises -f ./promises.cf -D dev ./promises.cf:10:12: error: syntax error "global1" expression => "any"; ^ ./promises.cf:10:12: error: Check previous line, Expected ';', got '"global1"' "global1" expression => "any"; ^ ./promises.cf:10:23: error: Expected promiser string, got 'expression' "global1" expression => "any"; ^ ./promises.cf:10:26: error: Expected ';', got '=>' "global1" expression => "any"; ^ 2014-05-22T13:46:05+0000 error: There are syntax errors in policy files

Note: Classes, once defined, will stay defined either for as long as the bundle is evaluated (for classes with a bundle scope) or until the agent exits (for classes with a namespace scope). See cancel_kept, cancel_repaired, and cancel_notkept in classes body.

persistent_disable_DAEMON

Description: Disable a CFEngine Enterprise daemon component persistently.

DAEMON can be one of cf_execd, cf_monitord or cf_serverd.

This will stop the AGENT from starting automatically.

clear_persistent_disable_DAEMON

Description: Re-enable a previously disabled CFEngine Enterprise daemon component.

DAEMON can be one of cf_execd, cf_monitord or cf_serverd.