You have probably heard of cowsay, but have you heard of agentsay? Just in case you haven’t seen the greatness of cowsay, here is an example: command cowsay "Gee, I wish I was a cf-agent!" output _______________________________ < Gee, I wish I was a cf-agent! > ------------------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || || If you look in core/contrib you will find agentsay among other goodies.
Did you know that CFEngine can simply warn about something not being in the desired state? Traditionally with CFEngine, you define your desired state and CFEngine works towards making that happen. Sometimes you might not want CFEngine to take action and instead warn that a given promise wants to change something. Let’s take a look at a contrived example. Say we want the file /tmp/feature-friday-22.txt to exist, we might write a policy that looks like this:
The rather serious recent OpenSSH vulnerability CVE-2024-6387 could affect as many as 14 million server instances exposed on the internet. Let’s make it easy to examine your infrastructure and see if you need to do any upgrades or mitigations. On the back of my CFEngine T-shirt it says: Know more, React faster When I have a problem to solve in CFEngine I look for an easy and correct solution. CFEngine Build is a good first place to look. Two modules stand out as possibly useful;
Who cares about that promise? Today, I want to highlight one of the lightweight knowledge management features in CFEngine. That is, Promisees, also known as Stakeholders. Promisees are references to things that might care about a specific promise. And they can be attached to any promise. Let’s take a look at a contrived example: bundle agent __main__ { methods: "example_promisees" -> { "Feature Friday #21" }; } bundle agent example_promisees { reports: "Happy Friday!"; } From the example above, we can see that the methods promise - promising to run the example_promisees bundle - has Feature Friday #21 defined as the only promisee. It provides us with a hint that Feature Friday #21 cares that the bundle will be run. Promisees have no effect on the execution of the policy. However, they provide breadcrumbs that can be useful when the policy is re-visited.
Did you know CFEngine has Macros? They were first introduced in CFEngine 3.7 (back in 2015), and more have been introduced since then. Macros are convenient for preventing the parsing of a section of the policy. It is handy for protecting older binaries from getting tripped up on newer syntax the agent does not understand. Let’s take a look. Currently there are 8 macros. minimum_version - Prevent the section of policy from being parsed unless the agent meets a minimum version. maximum_version - Prevent the section of policy from being parsed when the agent exceeds a maximum version. at_version - Prevents the section of policy from being parsed unless the agent is of a specific version. between_versions - Prevents a section of policy from being parsed unless the agent is between (inclusive) a minimum and maximum version. before_version - Prevents a section of policy from being parsed unless the agent is below a specified version (not inclusive). after_version - Prevents a section of policy from being parsed unless the agent is above a specified version (not inclusive). else - Allows the agent to parse a section of policy only if the preceding macro is not applicable. feature - Prevents a section of policy from being parsed based on feature availability. You can find examples of use within the Masterfiles Policy Framework. For example, body action fresh_systemd_state uses the minimum_version macro to control the setting of ifelapsed => "0" to versions 3.18.1 and higher since versions below might produce a warning.
Ever want to manage subvalues in a configuration file? In episode 39 we talk about using field_edits in edit_line bundles. Cody and Craig join Nick as he prototypes and iterates on some policy showing how to manage subvalues in KEY = quoted values. A question raised during one of our recent post show discussions. 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.
This is a heads up to anyone upgrading to CFEngine 3.24.0 or newer versions, about a small change that can be considered a breaking change. In CFEngine versions prior to 3.24.0, the CFEngine roles inventory attribute showed up in Mission Portal with the value policy_server for the hub, and as (Not reported) for all the other hosts (clients). The technical reason for this was that the policy_server class was tagged with inventory,attribute_name=CFEngine roles. Now, (in 3.24.0+) the CFEngine roles attribute will show the roles Client, Policy server, and Reporting hub, as shown and explained below.
Today, we are pleased to announce the release of CFEngine 3.24.0! The code word for this release is consistency. This release also marks an important event, the beginning of the 3.24 LTS series, which will be supported for 3 years. Several new features have been added since the release of CFEngine 3.21 LTS, in the form of non-LTS releases. In this blog post we’ll highlight the most important features since the previous LTS release, even though some of them technically landed in intermediate non-supported releases.
Do you know how to quickly see what variables and classes are defined? Often, while developing CFEngine policy it’s convenient to emit a variable value or a report based on the presence of a class. For example: bundle agent main { reports: "Unqualified hostname = '$(sys.uqhost)'"; linux:: "I am running on linux"; } In some cases, this is because you are exploring what classes are available. In other cases, it might be DEBUG-related reports helping you understand how a variable is resolved during policy evaluation. Often, you can get this information without writing CFEngine policy to emit it by using the --show-vars or --show-classes options to cf-promises.
Ever want to get some data into CFEngine? Have you heard about the def.json Augments file?1 Augments are JSON data files that allow you to define classes and variables very early during agent initialization, before policy. Augments are practical in a variety of ways. Perhaps most notably for overriding policy defaults. Let’s look at a simple example. Here we have a policy /tmp/feature-friday/18-0.cf /tmp/feature-friday/18-0.cf bundle agent main { reports: "MyVariable $(with) defined '$(MyVariable)'" with => ifelse( isvariable( MyVariable ), "is", "is not" ); } Running it, we can see that MyVariable isn’t defined
Sign up for CFEngine Enterprise and connect up to 25 hosts for free. No credit card required. Get started in minutes.
Try enterprise for free
