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. But working with those files outside of the DBMS, even for read-only access to the data stored in the DB, is practically impossible. So what can be done if some setup requires data in files while at the same time, the data processing and storage requires a use of a DB(MS)? The answer is synchronization between two storage places – a DB and files. It can either be from the DB to the files where the files are then treated as read-only for the parties working with the data, or with modifications of the files being synchronized to the DB. In the former setup, the DB is the single source of truth – the data in the files may be out of sync, but the DB has the up to date version. In the latter setup, the DB provides a backup or alternative read-only access to the data that is primarily stored in the files or the files provide an alternative write-only access to the DB. A two-way synchronization and thus a combination of read and write access in both places, the DB and the files, should be avoided because it's very hard (one could even say impossible) to properly implement mechanisms ensuring data consistency. Both between the two storages, but even in each of them alone.
Looking to be more efficient writing CFEngine policy?
Michael Bolen (Founder, CISOfy and author of Lynis) gives us some history on Lynis (including how to pronounce it, spoiler it’s “lee nus”). Nick Anderson (Doer of Things, Northern.tech) shows off reporting Lynis scan findings with CFEngine Enterprise and the lynis CFEngine build module.
Video The video recording is available on YouTube:
At the end of every webinar, we stop the recording for a nice and relaxed, off-the-record chat with attendees. Join the next webinar to not miss this discussion.
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. PostgreSQL's Overview of Trigger Behavior describes the basics of triggers with the following sentences:
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. This can both undermine the understanding of the desired state of the permissions as well as confidence that the policy accurately describes the resulting state and we have decided the convenience is not worth the cost.
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.
