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. We’ll have a look at it from both the policy writers- and the promise module developers point of view.
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. That’s what this post is about, using cfbs with your traditionally manged policy set. Note: This post assumes that you already have cfbs installed and understand the basics of how it works. Check out our previous blog posts if you want to review how to get started with cfbs.
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. Join the next webinar to not miss this discussion.
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.defs is set to SHA512.
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.
When working with CFEngine, it’s common to hear advice about separating data from policy. Separating data from policy allows for separation of concerns, delegation of responsibilities and integration with other tooling. Each organization is different, and a strategy that works well in one environment may not work as well in a similar environment of another organization, so CFEngine looks to provide various generic ways to leverage external data. For example, Augments (def.json) is useful for setting classes and defining variables very early during the agent execution which can be applied to the entire policy having differences based on system characteristics as well as being used for host specific data.
CFEngine is well suited for use in IoT environments due to it’s portability, size, and performance. There already exists a meta layer for including the CFEngine community client and Masterfiles Policy Framework in Yocto Project builds. This enables developing policy to:
ensure a service stays running track changes to important files monitor a value over time for normalcy Let’s walk through bringing up a qemu environment with CFEngine and ensure that a few basic things work: ensure the udev service stays running, tracking changes to important files like /etc/group and a look at monitoring capabilities.
Manually managing groups on a large infrastructure can be a tedious task, and is therefore best suited through automation software like CFEngine. Unfortunately - at time of writing - CFEngine does not have any built-in promise types for managing groups. But fear not; in CFEngine 3.17, custom promise types were introduced. This new exhilarating feature does not only allow for members of our community to make their own custom promise types, but also lets the CFEngine Core developers prototype new future promise types. In this blog post, I’d like to introduce one of our prototypes; the experimental groups promise type.
Come see what’s new in CFEngine policy management!
Herman (Product Manager) introduces and demonstrates new tooling, the CFEngine Build System (cfbs). cfbs is a command line tool to facilitate policy management and consuming modules written by others.
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.
