Is your CFEngine policy set a Frankensteinian monster of outdated files and custom tweaks? Take a look at tooling we have in development (cfbs analyze) to help shed light on the makeup of your policy set.
In this episode the team showcases a new tool for analyzing CFEngine policy sets. Learn how to identify modifications, missing files, and stale policies from old MPF versions and hear about additional features we can look forward to when it’s fully released.
In the latest version of the CFEngine network protocol (filestream - v4), we leveraged librsync for efficient file copying using their Streaming API.
While implementing the file streaming in CFEngine, I found that the documentation on the Streaming API was a bit unclear. Thus, I created two example programs to experiment with how it works. I thought I’d share them in this blog post as a tutorial to help other developers get up to speed faster.
The MPF or Masterfiles Policy Framework is intended to provide a stable base policy for installations and upgrades, and is used by both CFEngine Enterprise and CFEngine community.
When you create a new cfbs project with cfbs init one of the questions is related to the MPF:
Do you wish to build on top of the default policy set, masterfiles? (Recommended) [YES/y/no/n]: Added module: masterfiles The default commit message is 'Added module 'masterfiles'' - edit it? [yes/y/NO/n] Committing using git: [main f84d0d4] Added module 'masterfiles' 1 file changed, 16 insertions(+), 1 deletion(-) Of particular interest to policy writers is the lib sub-directory:
Ever tried to wrangle a fleet of servers with just a text file? Nick shows how CFEngine can take advantage of genders for classification.
In this episode, Nick dives into the configuration file, /etc/genders. Originally developed by Lawrence Livermore National Laboratory and currently maintained by the Chaos development team, genders often seen in use in High-Performance Computing (HPC) environments. Nick presents two practical examples demonstrating policy implementations, using genders for inventory reporting and grouping hosts.
When writing CFEngine policy we create files ending in the .cf extension but this alone won’t cause the policy to be parsed and evaluated. By default cf-agent runs ${sys.inputdir}/promises.cf.
For a non-privileged user running cf-agent this will be in their $HOME directory:
command cf-promises --show-vars=sys.inputdir output Variable name Variable value Meta tags Comment default:sys.inputdir /home/craig/.cfagent/inputs source=agent Usually though, CFEngine is run as a privileged user so the more common value is:
Did you notice that CFEngine 3.25.0 shipped with librsync as a new dependency?
Lars joins Cody, Craig, Herman and Nick to show and tell the massive savings we can expect to see from librsync for remote file copies. Spoiler alert, Lars sees > 80% savings from a simple policy update between 3.24.0 and 3.24.1! From the audience, Jay mentioned that they saw similar rates of savings from their use of rsync with savings accumulating to over 16TB a day.
We are writing to inform you of a recently discovered security issue in the CFEngine Enterprise web UI, Mission Portal. The issue has been fixed in the recently released 3.21.6 and 3.24.1 versions. Prior versions (3.24.0, 3.21.5, and below) are affected. We have no indications of this issue being exploited or known outside of the company. The issue was discovered thanks to the vulnerability scanning software Acunetix by Invicti.
Description On the affected versions, some fields lack input validation, allowing an authenticated user with administrator-level privileges to enter javascript into input text fields, which will be evaluated by other users of the system who open up the same form. In addition to fixing this specific issue of confirmed XSS, we also added much more strict input validation to many other fields in Mission Portal, to prevent similar issues, even though we were not able to find something exploitable in those cases.
Today, we are pleased to announce the release of CFEngine 3.25.0! The code word for this release is auditability. Being a non-LTS (not supported) release, this release allows users to test the new functionality we’ve been working on before it arrives in an LTS release ~1 year from now.
What’s new The audit log CFEngine Mission Portal now logs user actions in a structured audit log. This means you can go back and see who edited group data, who deleted a host, who created a user, etc. The audit log can be filtered by time and date, resource type, who performed the action, and what was affected.
This series of blogs, Monthly Module Mondays , started on April Fool’s Day 2024 discussing how to Inventory and remediate Red Hat Enterprise Linux with Security Technical Implementation Guides (STIGs) has now reached the 10th installment showcasing a couple of modules to take stock of what services are running on your systems.
Command line tools are useful! Thanks to both systemd and Windows Services command line tools systemctl and Powershell’s Get-Service supporting output of json format lists of running services it is easy to bring together the power of CFEngine to run commands, read json files and collect inventory which can be used for many purposes such as: reporting, alert widgets, compliance reports as well as our new Groups feature.
With another year behind us, we take a look back at what happened with CFEngine in 2024.
Webinars: ‘The agent is in’ We are 3 years in to our webinar series, ‘The agent is in’, and the show had, as expected, 12 new episodes. You can find all the recordings, and the registration link, at cfengine.com/webinars. Additional show notes are also available on our blog.
Module Mondays and Feature Fridays Nick and Craig have been writing regularly throughout the year about their favorite features and modules. You can find these posts on our blog:
