Looking for a place to chat about CFEngine?
Historically CFEngineers could be found in #cfengine on irc.freenode.net but we moved to #cfengine on irc.libera.chat in 2021. At that time we introduced some chat bridges linking various channels together. The bridge between Matrix and Libera was temporarily shut down last August but that temporary measure eventually became a permanent situation leaving our channels split.
Since then we have decided to remain on Matrix and have established a new channel CFEngine:matrix.org, we hope to see you there!
You may see a new warning in the upcoming releases of 3.21.5 and 3.24.0. A new warning was introduced with a fix to the behavior of depth_search when combined with a copy_from source targeting a file:
depth_search (recursion) is promised for a base object '<filename>' that is not a directory Prior to versions 3.21.5 and 3.24.0 CFEngine would copy the file initially but would subsequently avoid updating the file providing only debug log message about the fact that the file was being skipped (because it’s not possible to descend into a file). Beginning with 3.21.5 and 3.24.0 CFEngine will copy the file and properly update the file but will also emit a warning that recursion was promised for something that was not a directory.
When executing commands in a shell, the program and its arguments are typically separated by spaces. This command reads the content of two files and prints it out (concatenating it):
command cat one.txt two.txt In the example above, cat is the command / program, while one.txt is the first argument, and two.txt is the second argument. This is great because it makes commands really easy to read and type, however there is one obvious drawback: When a space has a special meaning (separating arguments), what do you do when you actually need a space?
ignore_interfaces.rx can be populated with regular expressions that match network interface names. When an interface matches CFEngine will ignore the interface.
In the upcoming release of 3.23.0, and in the future release of 3.21.4 there is a change in behavior with respect to the preferred location of ignore_interfaces.rx from $(sys.inputdir) (typically /var/cfengine/inputs) to $(sys.workdir) (typically /var/cfengine). The change from $(sys.inputdir) to $(sys.workdir) makes it easier to ignore different interfaces on different hosts.
In the upcoming release of 3.23.0, there is a change in behavior with respect to the self upgrade policy. Beginning with 3.23.0 the self upgrade policy will default to the binary version that is running on the hub instead of the version of the policy framework that is executing.
When upgrading CFEngine1 there are three major steps:
Upgrade the Masterfiles Policy Framework (MPF) Upgrade the hub binaries Upgrade the client binaries Generally it’s desirable that the MPF version is equal to or greater than the hub binary version and the hub binary version is equal to or greater than the client binary version. This way the policy has necessary knowledge in place prior to a binary upgrade where behavior may change.
In February, our team attended both FOSDEM and CfgMgmtCamp (Configuration Management Camp) in Belgium. At CfgMgmtCamp we held several talks, and we'll upload some of the recordings.
In the upcoming release of CFEngine 3.21.0 there is a change in behavior with respect to default permissions of created directories. From 3.21.0 and later directories will be created with read, write, execute permissions only for the file owner. No permissions are granted for group or other.
This change improves the default security posture to make sure that only the user executing CFEngine (typically root) will have access to content in newly created directories. This also aligns default directory permissions with default file permissions.
Our beloved cfbs CLI tool for working with CFEngine Build is rapidly evolving. At the time of writing, we are currently at version 3.2.1. Thus I would like to take this opportunity to talk a bit about the latest and greatest features; including support for users to manipulate input parameters in modules, as well as a couple of new build steps.
If you haven’t yet got a hold of the latest version of cfbs, you can update it with pip using the following command:
As a person who tries to work with as few resources as possible, whether it’s editing everything with ed(1) or using old laptops without screens for servers or turning off computers as much as possible I am happy to announce nightly packages are available for the aarch64 (ARM 64-bit) architecture.
This enables low-power, low-cost devices such as the Raspberry Pi and many others to run CFEngine Enterprise.
Why run CFEngine? It is lean on resources and rich in features! It helps keep your systems secure and compliant with whatever policy you may require.
Recently we introduced new feature where you can trigger agent runs and report collection from the Mission Portal UI.
This required our daemon cf-execd to behave a bit differently when periodic agent runs occur. Previously the daemon would create a new thread in which to run cf-agent, capture output, wait for completion and move on.
We changed the behavior so that the daemon forks itself and then fork/execs cf-agent as before, with the forked cf-execd processing agent run output. When the agent is finished the forked cf-execd process is left a zombie/defunct. The daemon wakes up every minute to see if it should do an agent run. The next time the original daemon cf-execd “wakes up” it will clean up that defunct forked cf-execd.
