Are you familiar with CFEngines special variables?
Probably you are familiar with sys variables like sys.fqhost (the fully qualified host name) and sys.policy_hub (the IP address of the machine the host is bootstrapped to) but I want to highlight a few other special variables you may not be so familiar with.
sys Sys variables are derived from the system discovery done by the agent as it initializes.
sys.os_release - A data structure derived from /etc/os-release /etc/os-release, introduced by systemd provides a nice record of the current distributions release information.1 CFEngine prefers information from this file for determining system classification like the definition of the redhat and debian classes. The file can also be extended with custom keys, like I have done on my system to set NORTHERN_TECH_OWNER=Nick Anderson. Since files information is exposed as a data container in this sys variable it can be useful for influencing policy behavior, like selecting additional Augments to load.2
Curious about package management with CFEngine on Windows?
After sharing some history on Microsoft’s global advertising campaign for “Where do you want to go today?” Craig shared some of his recent experiments with several windows based package managers as well as their related challenges.
Craig discussed difficulties with the msiexec package module, such as distinguishing which packages need installation through msi while also identifying software for removal by name, a task that can be challenging. He demonstrated this using examples from winget, chocolatey, Scoop, and PowerShell’s install-module commands.
Did you know that CFEngine has namespaces? Let’s see how they can facilitate policy sharing while avoiding “duplicate definitions of bundle” errors.
Most of the Masterfiles Policy Framework (MPF) and policy examples for CFEngine use the default namespace. However, body file control allows you to specify a namespace that applies for the rest of the file or until it’s set again by another body file control.
Let’s consider a contrived example. Say we have two policy files (policy-1.cf, policy-2.cf) for different services. In each policy file, we want to have a bundle where we store settings related to that policy. Traditionally this would be handled by using some bundle naming convention, so we might have bundle agent policy_1_settings and bundle agent policy_2_settings. Using namespaces you can keep your bundle names brief and use different namespaces to avoid “duplicate definitions of bundle” errors.
Found a bug, asking for help? Use cf-support to collect info quickly.
cf-support was born from interactions supporting Enterprise customers to streamline data collection and was introduced in late 2022 with the release of 3.18.31 and 3.21.02. Furthermore, it was featured on The Agent is In3 episode 21 Troubleshooting with cf-support. It gathers various details about the system and creates an archive that you can attach to your ticket. While its inception was geared towards Enterprise customers, it’s still both useful and available for community users as well.
Editing and copying large files or large numbers of files is slow. For a configuration management tool, it is probably one of the slowest things we do, apart from waiting for other programs to finish or waiting for network communication. In this blog post, we look at how to copy files. More specifically, the most performant approaches available on modern Linux systems. We are working on implementing these techniques so CFEngine and all your policy will copy files more efficiently.
Did you know you can include one policy file from another?
Traditionally you specify the files you want to make up a policy set using inputs in body common control found in your policy entry (promises.cf by default).
body common control { # Paths are relative to $(sys.policy_entry_dirname) if not # fully qualified inputs => { "path/to/policy-1.cf", "path/to/policy-2.cf", }; } body file control lets you specify additional inputs from any file that’s included in the policy and those files can include other files.
Two modules are available for this task: allow-all-hosts and allow-hosts.
The first module, allow-all-hosts, configures the most open situation which is to accept hosts from anywhere. This is only recommended in network restricted environments such as a local machine’s virtual machine network or other such closed down situations.
The second module, allow-hosts, uses cfbs module input to let you decide which hosts (specified by IP addresses and subnets) are allowed to connect to your hub, authenticate, fetch policy, etc. This is by far the more common scenario.
Ever want to run just a one or a few select bundles from your policy?
While developing policy it’s common to run cf-agent -KI so that you can quickly iterate on changes and the run the policy without locks. But if you are focused on select bundles you may not need the full policy to run, you can use the --bundlesequence option to specify one or more bundles overriding the bundlesequence defined in body common control.
Ever wanted to make sure a promise only runs if some other promise has succeeded?
Consider this contrived example with two reports type promises, It's Friday! and I love CFEngine Feature Friday. Per normal ordering1, these two promises will be emitted in the written order.
/tmp/feature-friday-7.cf bundle agent feature_friday { reports: "It's Friday, Friday"; "Gotta get down on Friday"; } command cf-agent --no-lock --bundlesequence feature_friday --file /tmp/feature-friday-7.cf output R: It's Friday! R: I love CFEngine Feature Friday. If we want them in the opposite order, we could either change the order or define classes based on the results of the promises. But today’s feature, depends_on, lets us influence the ordering using a more lightweight method via handle.
It’s easy to switch from Community to Enterprise.
Craig demonstrates the process of migrating from Community to Enterprise and touches on using many of the available components and tools from cf-remote to cf-net and so much in-between.
Video The video recording is available on YouTube:
At the end of every webinar, we stop the recording for a nice and relaxed, off-the-record chat with attendees. Join the next webinar to not miss this discussion.
