Do you maintain multiple policy sets? Do you leverage policy written by others? Ever wished for an easier way to upgrade your policy framework? cfbs can help to improve all of these cases.

What’s the easiest way to install cfengine? Have you heard of cf-remote? cf-remote was born out of a developer’s itch for an easy way to get CFEngine installed on some host for testing. We have featured cf-remote in several posts1 since it was first released in 2019, but today is Friday, so let’s review its features.

Security Technical Implementation Guides (STIGs) are an excellent body of knowledge to leverage in securing your infrastructure. With the stig-rhel-7 module you can easily add inventory and remediation policy for RHEL 7 with CFEngine. Do note that as of March 2024 this module does not provide comprehensive coverage but rather an initial 10 findings are implemented.

When you want to inspect both the return code and output from a command execresult_as_data() might be the function you are searching for. Most CFEngine policy writers have used execresult() and returnszero(). They are useful when you want to do something based on the output of a command or based on its successful execution (returning zero). For example: /tmp/feature-friday-3.cf command output But, sometimes, you care about specific return codes.

Ever wanted to manipulate a string - temporarily - for an individual promise? Check out the with attribute and its special, $(with) variable. Sometimes you need some variation on a string for a specific case. Traditionally, to achieve this you’d simply define another variable. Here is a contrived example: I have a string, nginx and I want to emit a report that contains both the string itself and the upper case version of the string.

Looking for a way to concisely set a variable conditionally? Have you heard of ifelse()? In CFEngine, traditionally class expressions are used to constrain promises to different contexts. Setting a variable to different values based on context might look like this: /tmp/feature-friday-1.cf command output That’s great, lots of flexibility, but with an increasing number of options the policy can get quite long and it’s easier for a human interpreter to lose track of the context.

As we bid farewell to 2023, it’s once again time to reflect on the milestones and progress we’ve made throughout the year. This year is especially significant because it marks 30 years since CFEngine’s birth. From its humble beginnings at the University of Oslo to the thousands of implementations across the world and counting, CFEngine has not only weathered the twists and turns of life, but has thrived in an industry where many have come and gone.

Today, we are pleased to announce the release of CFEngine 3.23.0! This is a non-LTS (non-supported) release, where we introduce new features for users to test and give feedback on, allowing us to polish before the next LTS.(CFEngine 3.24 LTS is scheduled to release summer 2024). The codename for this release is anniversary, as this year is CFEngine’s 30th anniversary.

For CFEngine we manage several public and private repositories of code in GitHub for our Open Source and Enterprise products. In order to ensure quality we run many checks on the code both with nightly builds as well as on each pull request. We use a Jenkins server for nightlies which also includes more extensive deployment tests on all of the platforms we support. Previously we had used Travis for many of these checks but that system started to show its age and limitations.

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.