This year, we are improving CFEngine’s ease of use, so it should come as no surprise that we need to rethink our documentation site. For software like CFEngine, great documentation is not just “nice to have”, but a must for our users, both beginners and experienced.
CFEngine has helped DevOps teams to automate their day-to-day tasks and make better decisions by providing a holistic overview of their systems. Part of our responsibility is to help users quickly understand how to conduct standard jobs while giving them insight into the possibilities of the product and features they might find useful next.
In the upcoming CFEngine 3.20 release we are making a change in the behaviour of the create attribute for the files promises that manage the entire content of a file. This includes promises with the template methods mustache, inline_mustache and cfengine; as well as promises with the content attribute.
The motivation behind these new changes is two-fold; make it easier to learn CFEngine policy language and understand what policy is doing, and to prevent CFEngine from creating empty configuration files.
A recent change in the Masterfiles Policy Framework (MPF) is renaming bundle agent main to bundle agent mpf_main.
This change is intended to make it easier to run individual parts of your policy leveraging the library main bundle functionality (bundle agent __main__).
Library main bundles were first introduced in CFEngine 3.12.0. The functionality allows for the definition of bundle agent __main__. When this bundle definition is present in the policy entry (the first policy file that CFEngine reads) the bundle is understood to be used as the default bundlesequence.
The CFEngine team is pleased to announce a competition for students in Norway. We want you to write a module in Python, and submit it to CFEngine Build. Your module will be Open Source (MIT License), available for our community of users worldwide. CFEngine is a programming language, and modules can be added to do whatever the user needs, so the possibilities are endless. You can look at some examples for inspiration at the end of this blog post.
Databases are great for data processing and storage. However, in many cases it is better or easier to work with data in files on a file system, some tools even cannot access the data in any other way. When a database (DB) is created in a database management system (DBMS) using a file system as its data storage, it of course uses files on the given file system to store the data.
In this blog post we show how it is possible to run an arbitrary program, script, or execute arbitrary code in reaction to changes and generally events in a PostgreSQL database.
Triggers Database management systems (DBMS) provide mechanisms for defining reactions to certain actions or, in other words, for defining that specific actions should trigger specific reactions. PostgreSQL, the DBMS used by CFEngine Enterprise, is no exception. These triggers can be used for ensuring consistency between tables when changes in one table should be reflected in another table, for recording information about actions, and many other things.
rxdirs has provided a convenient default when setting permissions recursively. When enabled (the default prior to version 3.20.0) a promise to grant read access on a directory is extended to also include execution since quite commonly if you want to read a directory you also want to be able to list the files in the directory. However, the convenience comes with the cost of complicating security reviews since the state requested on the surface is more strict than what is actually granted.
Saint Patrick’s Day makes us think of the color green. Spring is coming. Plants are starting to sprout amongst the dead grass and leaves from Fall/Winter:
Earth Day is just around the corner on April 22nd.
This reminds us of our commitment to the environment and ecosystems that surround us. As we at Northern.tech state in our corporate social responsibilities:
We have set an ambitious company-objective to “Become a net-zero carbon business by the end of 2022”.
Last year, we launched functionality for users to add policy for reporting data, compliance reports, promise types, and other code as modules. With CFEngine Build, users can manage and update their own policy, the default policy and any additional modules separately. This makes it very easy to utilize policy or other modules written by the CFEngine team, or other community members. In this post we will take a look at using some modules to improve the security of our infrastructure.
The CFEngine engineering team has recently discovered two security issues in the CFEngine Enterprise product, specifically in the hub package:
CVE-2021-44215 - PostgreSQL log file world readable. CVE-2021-44216 - Apache and Mission Portal Application log files world readable. CVE-2021-44215 is a regression affecting currently supported versions 3.18.0 and 3.15.4 as well as some unsupported versions. CVE-2021-44216 affects all supported versions prior to 3.18.1 and 3.15.5 as well as some unsupported versions.
