Drive failures are a matter of when, not if. The good news is that most modern drives warn you before they fail, using S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology). The challenge is collecting that data across a fleet and making it actionable. The new inventory-smartctl module makes this straightforward with a single cfbs add.
Once installed, the module auto-detects all storage devices, caches their SMART data, and exposes it as inventory attributes in Mission Portal.
We’re 60 episodes in, and today we’re getting back to one of the most fundamental tasks in systems management, package management.
In this episode we look at three new dnf-related improvements for managing packages on Enterprise Linux (Red Hat, Rocky Linux , AlmaLinux). We walk through the new dnf and dnf_group package modules, and the appstreams custom promise type.
Why new package modules? The existing yum package module works, but it shells out to run commands. The new dnf module takes a different approach: it uses the dnf and rpm Python libraries directly. This matters for security, reliability, and performance on modern Enterprise Linux where dnf has replaced yum as the native package manager.
Three notable dnf related improvements making it easier to manage packages on modern Enterprise Linux based systems (Red Hat, Rocky Linux, Alama Linux, etc …) have been merged recently.
dnf package module - Manage packages using dnf
dnf_group package module - Manage package groups using dnf
appstreams promise type - Manage application stream modules and profiles
dnf package module The new dnf package module unlike the existing yum module does not perform any shell operations, instead it leverages only the dnf and rpm python libraries for querying and modifying the system.
CFEngine 3.24.4+, 3.27.1+, and 3.28.0+ include a change to how findfiles() handles trailing slashes on directory paths. This change restores trailing slashes to directory results, but with improved consistency compared to earlier versions. The new behavior ensures that directory paths always include a trailing slash, making them reliably distinguishable from file paths regardless of the glob pattern used.
The behavior changes CFEngine 3.23.0 and earlier: Pattern-dependent behavior The presence of a trailing slash in the returned paths depended on whether the glob pattern itself included a trailing slash. If you use findfiles("/path/*/") (with trailing slash in pattern), the results include trailing slashes. If you use findfiles("/path/*") (without trailing slash in pattern), the results do not include trailing slashes.
When using CFEngine with the Masterfiles Policy Framework there are two standard “stages” involved in periodic maintenance: update the policy (update.cf) and evaluated the policy (promises.cf). In a standard install the cf-execd component periodically runs first the update policy and then the policy proper.
We have talked in the past about Extending the CFEngine Policy Update Procedure as well as Writing a cfbs module for your custom policy update.
While both of these previous strategies are very useful I have a couple of different itches to scratch this time:
The standard process for managing that monolithic set, it is a fair amount of git diffing. It’s not hard once you get used to it, but it’s still a lot to do and read.
In this episode we take a monolithic CFEngine policy set, the kind most of us have been managing for years in production, and turn it into cfbs-managed project using cfbs convert. We start with cfbs analyze to see what we’re working with, walk through the interactive conversion, and finish with running cfbs update to jump from masterfiles 3.24.0 to 3.27 in seconds.
(This blog post was updated February 10th, 2026)
We are writing to inform you of multiple recently discovered security issues in the CFEngine policy and Mission Portal. These issues have been fixed in the recently released 3.27.0, 3.24.3 and 3.21.8 versions. Prior versions (3.24.2, 3.21.7, and below) are affected. We have no indications of these issues being exploited or known outside of the company and the security researchers that reported them.
We here at CFEngine have seen the collaboration possibilities with Ansible for a long time. See our many ansible related blog posts including previously where I discussed our promise-type-ansible module which enables you to run ansible playbooks from CFEngine policy.
You might ask why you would want to do such a thing?
We came up with one possible answer: what happens if you block ssh access to a host? Now you can certainly setup ansible-pull but that requires configuring credentials and access to a repository.
Today, we are pleased to announce the release of CFEngine 3.27.0! The code word for this release is exploration.
This release also marks an important event, the beginning of the 3.27 LTS series, which will be supported for 3 years.
Several new features have been added since the release of CFEngine 3.24 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.
Take a fast thing and make it faster.
In this Christmas special, Nick and Herman chat about the new built-in profiling support for cf-agent in the upcoming release.
The upcoming 3.27 LTS release introduces a first-class profiling capability directly into cf-agent. Unlike previous solutions (like cf-profile or the Perl-based profiler) which often required real-time analysis or significant logging overhead, this new approach decouples collection from analysis.
To profile a run, you simply add the --profile option, redirect the output to a file for later analysis.
