In the upcoming release of 3.23.0, there is a change in behavior with respect to the self upgrade policy. Beginning with 3.23.0 the self upgrade policy will default to the binary version that is running on the hub instead of the version of the policy framework that is executing.
When upgrading CFEngine1 there are three major steps:
Upgrade the Masterfiles Policy Framework (MPF) Upgrade the hub binaries Upgrade the client binaries Generally it’s desirable that the MPF version is equal to or greater than the hub binary version and the hub binary version is equal to or greater than the client binary version. This way the policy has necessary knowledge in place prior to a binary upgrade where behavior may change.
Imagine having the power to identify the exact lines of your CFEngine policy that are slowing down your executions. In this episode, we’ll guide you through the art of profiling CFEngine policy for improved performance.
In Episode 30 of “The agent is in,” Nick and team dives into the topic of profiling CFEngine policy. We explore tools and techniques to identify performance bottlenecks and optimize CFEngine deployments. The episode covers the following main points:
Ever been curious about Docker details or the cruft that has built up and could be cleared out?
Craig, Cody, and Nick chat about some of the work Craig has been doing recently, using Docker in development and CI. Craig shows how to develop policy to inventory various Docker details like image names, counts of dangling images, and reclaimable disk space.
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.
Have you been interested in automating the testing of your CFEngine policy?
Cody, Craig and Nick follow up on the Policy Examples episode and dive a bit deeper into testing. Nick walks through some policy and related tests that leverage lib/testing.cf from the Masterfiles Policy Framework and Craig walks through implementing a GitHub Workflow to run the tests in a Docker container for each Pull Request.
Video The video recording is available on YouTube:
This question was covered in The agent is in, Episode 27 - CFEngine Q&A: Policy questions.
Given the following JSON, how can I get a list containing just the values of name?
[ { "name": "Aurora", "description": "Illuminating" }, { "name": "Orion", "description": "Stellar" }, { "name": "Luna", "description": "Serene" }, { "name": "Phoenix", "description": "Resilient" }, { "name": "Atlas", "description": "Strong" } ] Using maparray() The most concise and direct way to achieve something like this is to use the maparray() function. It iterates over a list or data container applying a pattern based on $(this.k) and $(this.v) of the currently iterated element to produce a list.
This question was covered in The agent is in, Episode 27 - CFEngine Q&A: Policy questions.
Testing is an important part of the software life-cycle. Writing tests for your CFEngine policy can help to bring improved assurance that your policy behaves as expected. Follow along and write your first test policy.
Test stages When writing tests there are three or four basic stages that typically need to be handled.
Initialization - Set up the necessary conditions for the test, e.g. create some files to be edited. Testing - Running the policy whose behavior you wish to test. Checking - Inspecting the results of the test policy to see if they conform with expectations. Cleanup - You might need to cleanup artifacts produced by the test if your testing system does not handle it for you. These stages map well to a sequence of bundles. So, a simple test template could look like this:
Unlock the power of CFEngine with expert insights and get your burning policy questions.
Cody, Craig and Nick discuss and answer CFEngine policy questions submitted by users.
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.
I was chatting with someone recently about some security maintenance tasks and they were bemoaning that some software updates had turned into a yack shaving1. Updating this required updating that, required updating that on N hosts of varying platforms and flavors. So, they asked me how could they avoid updating a specific package and naturally I said, let’s just prototype some policy.
The incipiency of said yak shaving was updating packages via apt, Debian flavored systems default package manager. apt upgrade is being used to update all packages, but we need to exclude a specific package from the updates until the dependency chain has been resolved.
Have you seen what’s new in CFEngine 3.22.0?
Ole Herman Elgesem, CFEngine Product Manager joins Cody, Craig and Nick to give a tour of the changes in recently released CFEngine 3.22.0 Mission Portal. See how filters have been improved and how the new Groups feature makes it easier to affect change across your infrastructure and enforce package compliance with a new module, packages-allowlist-snapshot from CFEngine Build.
Video The video recording is available on YouTube:
Traditionally, CFEngine policy sets are managed as a whole. When upgrading the Masterfiles Policy Framework (MPF)1 users must download the new version of the policy framework and integrate it into the existing policy set, carefully diffing the vendored policy files against their currently integrated policy. Updates to policy authored by others must be sought out and similarly integrated. The burden is on the user to maintain the knowledge of where policy is sourced, if updates are available, and how it is integrated into the policy set as a whole.
