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.
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.
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.
When you first told me that this change was coming I was astonished because I know that normal order, the normal ordering is very intentional like a lot of thought went into it right and it’s not configurable, again on purpose, right!?
In this episode, Nick is joined by long-time CFEngine user and trainer, Aleksey Tsalolikhin. It was a conversation with Aleksey at a LISA conference in 2010 that set Nick on his CFEngine journey, asking, “What do you want from your configuration management tooling?”. Nick knew immediately that the tool he was using, while great, didn’t fit the characteristics he was looking for.
“I came here to chew bubble gum and demo the next LTS. And I’m all out of chewing gum.”
Herman joined Cody, Craig and Nick to give a sneak peek of the upcoming CFEngine 3.27 LTS release. Herman shows off some of the new features, including:
An AI agent to query your infrastructure using natural language. Audit log improvements. A new first-time setup experience for Mission Portal. An enhanced Mission Portal UI. New policy language functions like getgroups(), getgroupinfo(), findlocalgroups(), getacls(), isconnectable(), isnewerthantime(), and classfilterdata() (which we covered in The agent is in - Episode 51 - Data-driven configuration with classfilterdata()). A new evaluation_order control to run promises in a top-down order. We also answer some great questions from the audience about custom promise modules, nested groups, and AI model integration.
In these times dominated by ever growing amounts of technology, have you ever considered the power of less?
In this very special episode, we celebrate Craig Comstock’s 8-year anniversary with the company! Craig takes us on a journey into the concept of “decomputing” - the idea of using computer systems less and within limits.
Join us as Craig explores how CFEngine’s philosophy and design principles, such as being lightweight and having few dependencies, align with the decomputing mindset. He shares some book recommendations (The Mechanic and the Luddite, Resist AI), and examples of fun, interesting, old, and resource constrained platforms where he exercises CFEngine regularly.
Is 5 minutes of drift too long? Winter is coming, and so is CFEngine support for dealing with immutable files.
CFEngine has always been a powerful tool for enforcing configuration and preventing drift. It’s the very essence of its mission to ensure the state of a system remains in line with its policy.
For years, that periodic enforcement with the speed and frequency of execution has been the core of CFEngine’s value. But what if you need to add another layer of protection? What if you want to make files on a system even more resistant to change, whether from a well-meaning administrator, an errant process, or even a malicious actor but not necessarily hamper CFEngine?
