Ever want a custom CFEngine Agent logo? Check out agentsvg.
You can find agentsvg in core/contrib/ it’s a python script that can generate CFEngine agent logos.
python3 ./agentsvg.py > agent.svg python3 ./agentsvg.py --body="#f5821f" --head="#052569" > agent-body-head-colors.svg In addition to customizing the head and body colors you can customize the arm positions to be up, down, out or angled and the legs can be straight or out
python3 ./agentsvg.py --arms angled --legs out > agent-arms-legs.svg Happy Friday! 🎉
Did you know you can use variables in class expressions?
If you are reading this, you probably are already familiar with the ability to use class expressions to restrict the context of multiple promises. For example, here we have three reports type promises, all guarded by the class expression linux::.
bundle agent __main__ { reports: linux:: "Only hosts with the linux class"; "Will have these promises"; "In context"; } And, if you are tracking this series, you know that you can restrict the context of a single promise using if or unless.1 However, you can also use variables in class expressions. Let’s take a look.
Class expressions are powerful. They let you restrict the context for multiple promises in a single statement. What if you want to further control the context of a specific promise?
Let’s take a look at a contrived example:
/tmp/feature-friday-28-0.cf bundle agent __main__ { reports: "I am running $(sys.os_release[PRETTY_NAME])"; linux:: "I love Linux!"; linux.ubuntu:: "Especially Ubuntu."; linux.redhat:: "Especially RedHat."; linux.!(ubuntu|redhat):: "But not RedHat or Ubuntu."; } command cf-agent -Kf /tmp/feature-friday-28-0.cf output R: I am running Ubuntu 22.04.4 LTS R: I love Linux! R: Especially Ubuntu. Here, we have a report showing the distribution we’re running through class expressions protecting the individual promises. We would see I love Linux! on Linux hosts. Depending on the specific distribution running we would see Especially Ubuntu. or Especially RedHat.. If we are running something other than those two distributions But not RedHat or Ubuntu. would be reported.
When promises are actuated, a class can be defined based on its result. For example, if a promise modifies a file’s content, you could define a class that indicates it has been repaired. However, did you know that promises can have multiple outcomes concurrently?
That’s right! Native promises (but not custom promises) can have multiple outcomes. For example, a promise can be both kept and repaired at the same time. Let’s take a look.
There’s a users promise type for managing local users. However, did you know there is also a custom one for managing local groups?
You might have seen it mentioned in the CFEngine Build announcement, the blog post on Managing local groups, or in the announcement supporting custom bodies post. But let’s take another look. The easiest way to integrate the groups custom promise type is by using cfbs, simply cfbs add promise-type-groups in your project. Next, we need some policy that leverages the groups promise type. Let’s create groups.cf in the projects root directory and add it to the project with cfbs add ./groups.cf, selecting the option to add the groups bundle to the bundlesequence.
Generally, cf-agent runs as a privileged user. But did you know that you can also run as an unprivileged user?
A major benefit of running cf-agent unprivileged is the ability to prototype policies during development. However, attempting to execute cf-agent as an unprivileged user without proper configuration will result in errors. Let’s create /tmp/feature-friday-25.cf with the following content:
/tmp/feature-friday-25.cf bundle agent main { reports: "Happy Friday!"; } Now, let’s try running that policy with cf-agent as an unprivileged user:
You probably know about the def.json Augments file. However, are you familiar with host_specific.json?
The def.json Augments file is read, if it’s adjacent to the policy entry. As such, this file is generally distributed as part of the policy set. Its settings apply to all hosts that receive and run the policy. The host_specific.json Augments file, is on the other hand loaded from the $(sys.workdir)/data/ directory. And it is expected to be independent from the policy.
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:
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.
