I re-stumbled across this mailing list post from Bryan Burke about some policy framework upgrade issues where he also asked about hooking in and customizing the update policy. I thought this sounded like a good opportunity for an example using a cfbs module. So, let’s take a look at making a cfbs module for a custom update policy. As mentioned in the thread there are just a couple of things you need to do in order to hook in and customize the behavior of the update policy.

Last year we had a look at managing local groups with the custom groups promise type. As you may or may not recall, we used JSON-strings to imitate CFEngine bodies. This was due to the fact that the promise module protocol did not support bodies at that time. Today, on the other hand, we’re happy to announce that as of CFEngine 3.20, this will no longer be the case. In this blog post we’ll introduce the long awaited feature; custom bodies.

CFEngine and Ansible are two complementary infrastructure management tools. Findings from our analysis show that they can be combined and used side by side with joint forces to handle all areas in the best possible way. Part of infrastructure management is hosts deployment, either when building a brand new infrastructure or when growing one by adding new hosts.

With the recent release of build.cfengine.com and cfbs I have been thinking about the process of converting a traditionally manged policy set. I consider a traditionally manged policy set one where you have a repo with the root of masterfiles being the root of the repository, or even having no repository at all and managing masterfiles by editing directly in the distribution point (e.g. /var/cfengine/masterfiles).

For our final blog post of 2021 and continuing our tradition, we’d like to reflect on all the CFEngine accomplishments throughout the year and provide a sneak peak of what to expect in 2022.

This is the final summary of our 2021 security hardening holiday calendar. We wanted to provide educational, useful, and actionable security advice, and we’re really pleased with the reception! Thank you for reading and following along.

The internet has been ablaze since the announcement of Log4Shell, the nickname for CVE-2021-44228, an arbitrary remote code execution vulnerability in the Java logging utility Log4j. So far two additional vulnerabilities ( CVE 2021-45046, CVE-2021-45105) have now been identified. The code has been vulnerable since 2013 and millions of hosts and services are affected.

This december, we are posting security advice and modules, every day until December 25th. Now, it’s December 21st, and we’ve gotten through most of the security hardening holiday calendar.