Dynamic CFEngine3

Although this website is predominatly written in Dutch, because it is aimed at Dutch people using Debian, this set of pages is in English. The reason behind this is Webhuis' desire to support the international CFEngine community.

The dynamics is in the data

A best practice in CFEngine is to make promises or bundles as generic as possible, so that they suite the needs of as many situations as possible. Hosts and Domains contain specific information or data that is applicable to the Host only and that to be used in the configuration of the Host.

Host taylor made provisioning of promises

Dynamic CFEngine is the Webhuis way of providing a taylor made set of promises to each and every node. Webhuis believe this is a security feature, because the host only has the bundles and the data it needs.
Webhuis offers Dynamic CFEngine under GPL-2 as its contribution to the community.

How does it work?

Dynamic CFEngine extends on convergence because it provides the promises to the system in a convergent way, not all the promises are available as of the bootstrap of the host. The Webhuis example setup is structured:

• A host belongs to a domain
• A host has a role

In the example the host, domain and role bundles contain data that drive the common logic in the common bundles. When the host is bootstrapped to the CFEngine Master Hub it starts configuring itself by pulling the host and domain bundles from the hub. The host bundles file contains the role information, which convergently is being pulled from the hub in a subsequent iteration.

The host

Each host requires a file ${uqhost}.cf in this example.
In small operations this is not a problem and is the set of host files to maintain easily. Smaller operations in general will have hosts that have common names.
The downside of this approach is that a big data center will have hundreds, if not thousands of host.cf files. In a situation like that it probably is the better option to have a host naming convention, so that the host name contains the role name and for instance an instance number. Big operations in general will have a host naming convention in place.

The role

The role the host has in crucial in this concept, because the role defines the machine and the software that has to be installed and configured.
If the role is defined by a host naming convention then a regular expression is applied to fetch the role name from the host name.

Data driven approach

Because the data in the host, domain and role bundles drive the common logic in the common bundles Dynamic CFEngine makes little use of classes or contexts. The context is defined beforehand and no decisions have to be made, thus leading to a reduction of complexity in the logic in the common bundles.

The structure

The bundlesequence in promises.cf is as follows:

• "role"
• "g"
• "update"
• "@(webhuis_common)"
• "${g.class_domain}"
• "${g.class_host}"
• "${role.role}"

Step by step

In the first iteration almost everything fails, the bundles g, update and the bundlesequence in @(webhuis_common) will execute but will not fulfill all the promises. In the example "${g.class_domain}" is replaced by webhuis_nl, "${g.class_host}" is replaced by bur and "${role.role}" is replaced by backup_recovery. @(webhuis_common) is an slist that contains the bundle names "common_bundles", "os_layer", "hardening".

bundle common role

The bundle common role is the first bundle to be executed when available to the host. It defines the common variable role that has the name of the role to the system and it sets a class with the name of the role. The role name becomes available to cf-agent once the role is identified by either:

• Fetching the role name from the host name, if host naming is done by convention
• Fetching the role name from the host file.

Here you find the bundle common role details.

bundle common g

The bundle common g is contained in promises.cf and it defines common variables to the system. In the Webhuis Dynamic CFEngine3 solution two special slist variables are generated, in order to have dynamic inputs. The dynamic inputs consists of two branches

• A standard inputs branch in /var/cfengine/inputs
• A dynamic inputs specific branch /var/cfengine/inputs-webhuis

Here you find the bundle common g details.

bundle agent update

The bundle agent update carries out very important tasks specific to Dynamic CFEngine3.
The agents use it to pull their specific configuration information from the CFEngine hub they are bootstrapped to. It pulls the standard masterfiles to inputs, but it also pulls domain, host and role specific information from the webhuis branch on the hub and places these bundles into a branch next to inputs /ver/cfengine/inputs-webhuis.
Here you find the bundle agent update details.

bundle agent webhuis common

The bundle webhuis_common carries out common tasks like installing base packages and housekeeeping. Still it uses the variables of the dynamic bundles.
Here you find the bundle agent webhuis common details.

bundle agent webhuis_nl

The bundle webhuis_nl is an example domain bundle, the webhuis branch that is next to masterfiles could contain any number of domains. The domain bundle for the most part defines data that are common to the domain. In this example it defines network addresses, and servers for ldap, dns and ntp.
Here you find the bundle agent webhuis_nl details.

bundle agent bur

The bundle bur defines a couple of variables that are specific to the host and adapt to the role that it has.
Here you find the agent bur details.

bundle agent backup_recovery

The bundle agent backup_recovery is an example of role hosts can have. It deals with the variables it gets passed and takes care of the installation of packages required to carry out the task that belongs to the role.
Here you find the bundle agent backup_recovery details.

---

Return to: CFEngine