Looking to be more efficient writing CFEngine policy?
Nick Anderson (Doer of Things) walks us through setting up Spacemacs for CFEngine. Get syntax highlighting, on the fly error checking, function prototypes, integration with the venerable org-mode and more!
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 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.
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.
I re-stumbled across this mailing list post from Bryan Burke about some policy framework upgrade issues where he also asked about hooking in and customizing the update policy. I thought this sounded like a good opportunity for an example using a cfbs module. So, let’s take a look at making a cfbs module for a custom update policy.
As mentioned in the thread there are just a couple of things you need to do in order to hook in and customize the behavior of the update policy.
Last year we had a look at managing local groups with the custom groups promise type. As you may or may not recall, we used JSON-strings to imitate CFEngine bodies. This was due to the fact that the promise module protocol did not support bodies at that time. Today, on the other hand, we’re happy to announce that as of CFEngine 3.20, this will no longer be the case. In this blog post we’ll introduce the long awaited feature; custom bodies.
With the recent release of build.cfengine.com and cfbs I have been thinking about the process of converting a traditionally manged policy set. I consider a traditionally manged policy set one where you have a repo with the root of masterfiles being the root of the repository, or even having no repository at all and managing masterfiles by editing directly in the distribution point (e.g. /var/cfengine/masterfiles). Before jumping in with both feet and converting to a cfbs managed policy set you might want a hybrid situation where you can leverage some of the benefits of cfbs but without making drastic changes to the way policy is currently managed.
Join us as we embark on an adventure to create and publish a new CFEngine Build module.
Nick (Doer of Things) demonstrates he knows the proper offerings the gods require by writing and publishing a new CFEngine Build Module from scratch, live, with no safety net!
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.
With the release of build.cfengine.com, I have been working to migrate some of our own security related policy into modules of their own. CFEngine Build and the cfbs tooling allows us to organize policy into modules, which are easy to update independently and share with other users. Let’s take the scenic route and look at what life is like with cfbs.
One of our security policies requires that the password hashing algorithm in /etc/login.
Earlier this year, we hinted at what we were working on - a place for users to find and share reusable modules for CFEngine. Today, the CFEngine team is pleased to announce the launch of CFEngine Build:
The new website, build.cfengine.com, allows you to browse for modules, and gives you information about how to use each one of them. When you’ve found the module you were looking for, it can be downloaded and built using the command line tooling.
