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:
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.
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:
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:
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.
Recently we had a Fireside Chat with long-time contributor and CFEngine Champion Bas Van der Vlies. During that talk he mentioned a Build module he developed: promise-type-docker-compose.
For this month’s Module Monday post I thought I would take this promise type for a spin alongside the Docker Compose Quickstart tutorial.
Setup For this blog I brought up a libvirt vagrant VM with Debian 12 and installed the latest LTS (3.24.0) with cf-remote. To install docker I follow the instructions at Install Docker Engine. I was using Debian 12 “bookworm” and found that the default packages docker.io and docker-compose are rather old and were not compatible with the promise-type-docker-compose module. Additionally, the module relies on the jq utility, so I install that as well. I may write policy some time to take care of these dependencies but especially the Docker Engine install involves quite a few steps so will leave that for another time.
Over three years ago we introduced git and systemd custom propmise types.
While these are quite functional I recently needed to manage a git repository that was private and so needed a way to authenticate to a git server, in this case gitlab.
Gitlab has project access tokens but we didn’t directly support any sort of authentication attributes on the promise type.
I ran across git credential as a way to provide authentication and thought it was a good fit.
I promised more Build modules in my previous monthly Monday module blog post: package-method-winget.
And here they are: windows-capability and windows-optional-feature.
Inventory Both of these modules use similar usage details to control whether to inventory and to promise the state for specific capabilities and optional features.
By default inventory is taken in the form of a classic array which ends up in the Mission Portal as a comma separated list:
OpenSSH.Server~~~~0.0.1.0:Installed, OpenSSH.Client~~~~0.0.1.0:Installed, etc. To disable this inventory, define the class disable_windows_capability_inventory or disable_windows_optional_feature_inventory in the data namespace. The data namespace is the default if you use Host specific data or Group data. If you want to set these in augments you will need to specify the namespace explicitly like this:
As a developer and user of CFEngine I want to use policy to manage the software on my systems so that I can switch operating systems, distributions, computers and have all my normal tools available wherever I go.
Towards this end I searched for a Windows package manager and found one in winget. I showed a prototype in Agent Is In - Episode 37 - Windows package management as well as refined the whole process in Agent Is In - Episode 40 - Windows module workshop.
The rather serious recent OpenSSH vulnerability CVE-2024-6387 could affect as many as 14 million server instances exposed on the internet. Let’s make it easy to examine your infrastructure and see if you need to do any upgrades or mitigations.
On the back of my CFEngine T-shirt it says:
Know more, React faster When I have a problem to solve in CFEngine I look for an easy and correct solution. CFEngine Build is a good first place to look. Two modules stand out as possibly useful;
