Dynamic CFEngine3 - Revision history

Martin: /* Host taylor made provisioning of promises */

2025-07-08T16:34:30Z

Host taylor made provisioning of promises

← Older revision		Revision as of 16:34, 8 July 2025
Line 3:		Line 3:
	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.		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 ==		== 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.<br/>		Dynamic CFEngine is the Webhuis way of providing a taylor made set of promises to each and every node. Webhuis believe this is a neseccisty from a security perspective, because the host only has the bundles and the data it needs.<br/>
	Webhuis offers Dynamic CFEngine under [http://webhuis.nl/GPL-license GPL-2] as its contribution to the community.		Webhuis offers Dynamic CFEngine under [http://webhuis.nl/GPL-license GPL-2] as its contribution to the community.

	== How does it work? ==		== 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:		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:

Martn admin: Martn admin moved page Dynamic Cfengine3 to Dynamic CFEngine3: Alignment met de productnaam

2022-06-01T15:02:25Z

Martn admin moved page Dynamic Cfengine3 to Dynamic CFEngine3: Alignment met de productnaam

← Older revision

Revision as of 15:02, 1 June 2022

Martn admin at 15:02, 1 June 2022

2022-06-01T15:02:12Z

← Older revision		Revision as of 15:02, 1 June 2022
Line 62:		Line 62:
	Here you find the [[bundle_agent_backup_recovery \| bundle agent backup_recovery ]] details.		Here you find the [[bundle_agent_backup_recovery \| bundle agent backup_recovery ]] details.
	<hr>		<hr>
	Return to: [[~~Cfengine~~]]		Return to: [[CFEngine]]

Martin: /* The host */

2014-07-02T14:26:38Z

The host

← Older revision		Revision as of 14:26, 2 July 2014
Line 12:		Line 12:
	=== The host ===		=== The host ===
	Each host requires a file ${uqhost}.cf in this example.<br/>		Each host requires a file ${uqhost}.cf in this example.<br/>
	In small operations this is not a problem and is the set of host files to maintain easily.<br/>		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.<br/>
	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.		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 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.<br/>		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.<br/>

Martin: /* bundle common role */

2014-07-02T14:24:24Z

bundle common role

← Older revision		Revision as of 14:24, 2 July 2014
Line 34:		Line 34:
	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".		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 ==		== 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 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 \| bundle common role ]] details.		Here you find the [[bundle_common_role \| bundle common role ]] details.

	== bundle common g ==		== 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		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

Martin: /* How does it work? */

2014-07-02T14:21:19Z

How does it work?

← Older revision		Revision as of 14:21, 2 July 2014
Line 10:		Line 10:
	* A host has a role		* 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.<br/>		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.<br/>
			=== The host ===
⚫	~~Each host requires a file ${uqhost}.cf in this example.~~ 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 better to have a host naming convention, so that the host name contains the role name and for instance an instance number.
			Each host requires a file ${uqhost}.cf in this example.<br/>
			In small operations this is not a problem and is the set of host files to maintain easily.<br/>
		⚫	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.
			=== 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.<br/>
			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 ==		== Data driven approach ==

Martin: /* How does it work? */

2014-07-02T14:14:44Z

How does it work?

← Older revision		Revision as of 14:14, 2 July 2014
Line 10:		Line 10:
	* A host has a role		* 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.<br/>		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.<br/>
	Each host requires a file ${uqhost}.cf in this example. 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 better to have a host naming convention		Each host requires a file ${uqhost}.cf in this example. 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 better to have a host naming convention, so that the host name contains the role name and for instance an instance number.

	== Data driven approach ==		== Data driven approach ==

Martin: /* How does it work? */

2014-07-02T14:09:26Z

How does it work?

← Older revision		Revision as of 14:09, 2 July 2014
Line 9:		Line 9:
	* A host belongs to a domain		* A host belongs to a domain
	* A host has a role		* 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.		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.<br/>
			Each host requires a file ${uqhost}.cf in this example. 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 better to have a host naming convention

	== Data driven approach ==		== 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.		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.

Martin: /* The dynamics is in the data */

2014-07-02T13:54:18Z

The dynamics is in the data

← Older revision		Revision as of 13:54, 2 July 2014
Line 1:		Line 1:
	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.		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 =		= The dynamics is in the data =
	A best practice in ~~CFEgine~~ 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.		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 ==		== 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.<br/>		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.<br/>

Martin: /* The structure */

2014-05-24T14:46:20Z

The structure

← Older revision		Revision as of 14:46, 24 May 2014
Line 28:		Line 28:
	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 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.
	Here you find the [[bundle_common_role \| bundle common role ]] details.		Here you find the [[bundle_common_role \| bundle common role ]] details.
⚫	== bundle agent update ==
⚫	The bundle agent update carries out very important tasks specific to Dynamic CFEngine3.<br/>
⚫	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.<br/>
⚫	Here you find the [[bundle_agent_update \| bundle agent update ]] details.

	== bundle common g ==		== 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		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
Line 38:		Line 33:
	* A dynamic inputs specific branch /var/cfengine/inputs-webhuis		* A dynamic inputs specific branch /var/cfengine/inputs-webhuis
	Here you find the [[bundle_common_g \| bundle common g ]] details.		Here you find the [[bundle_common_g \| bundle common g ]] details.
		⚫	== bundle agent update ==

		⚫	The bundle agent update carries out very important tasks specific to Dynamic CFEngine3.<br/>
		⚫	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.<br/>
		⚫	Here you find the [[bundle_agent_update \| bundle agent update ]] details.
	== bundle agent webhuis common ==		== 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.<br/>		The bundle webhuis_common carries out common tasks like installing base packages and housekeeeping. Still it uses the variables of the dynamic bundles.<br/>
	Here you find the [[bundle_agent_webhuis_common \| bundle agent webhuis common ]] details.		Here you find the [[bundle_agent_webhuis_common \| bundle agent webhuis common ]] details.

	== bundle agent webhuis_nl ==		== 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.<br/>		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.<br/>
	Here you find the [[bundle_agent_webhuis_nl \| bundle agent webhuis_nl ]] details.		Here you find the [[bundle_agent_webhuis_nl \| bundle agent webhuis_nl ]] details.

	== bundle agent bur ==		== 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.<br/>		The bundle bur defines a couple of variables that are specific to the host and adapt to the role that it has.<br/>
	Here you find the [[bundle_agent_bur \| agent bur ]] details.		Here you find the [[bundle_agent_bur \| agent bur ]] details.

	== bundle agent backup_recovery ==		== 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.<br/>		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.<br/>