CFEngine 3.20 released - Modularity

Today, we are pleased to announce the release of CFEngine 3.20.0! Over the past few years we’ve focused on ease of use, new user experience, and out of the box value, giving you the ability to do much more through only the Mission Portal Web UI. This has resulted in several important steps forward; policy analyzer, compliance reports, host specific data (CMDB), and CFEngine Build with custom promise types and other modules. In this release we take this one step further, focusing on modules and modularity, and the ability to find and use modules, making changes to your infrastructure, directly from Mission Portal (API or GUI). The 3.20 release is not supported, but it’s an excellent opportunity for our users to see and test what will be in the next release - CFEngine 3.21 LTS, about 6 months from now.

What’s new

CFEngine Build in Mission Portal

With CFEngine Build, we want to enable collaboration between community members and the CFEngine team, and ease the management of policy and modules from multiple sources. Additionally we want to deliver valuable functionality in the form of modules directly to our users outside of the regular release cycle. Until now, this has been done with the use of build.cfengine.com and the cfbs command line tool. The website is great for finding new modules and seeing what others have made, and the tooling allows you to download, manage, update, and build modules into a deployable policy set.

Today, we bring this functionality into Mission Portal; you can browse for modules, add, and deploy on your hub, all within the web UI:

Getting started

The first time you open the Build application, you will be prompted to create a project, and set it up to synchronize with your git repository. If you are unsure here, we recommend creating a repository on GitHub, choosing to generate an SSH key in Mission Portal, and adding that to your GitHub repository settings, under “Deploy keys”. If you just want to check out the UI, you can skip the git repo settings, but we recommend setting it up, so your changes are saved and pushed somewhere and you can deploy your project to your hub(s). After creating your project, you see the Build UI and a guide for quickly getting started:

You can search for modules just like on build.cfengine.com:

Clicking on modules gives you some of the same information as on the website, and a button to add (or remove) the module:

After adding modules you can see them on the left:

Deploying

In the top right corner you can deploy your changes:

The first time you click the deploy button, you will be asked if you want Mission Portal to change the settings so it starts using this repository to pull policy from:

After doing this, any git push to that repository, including the ones you make by clicking Deploy in Mission Portal, will result in the policy being updated on your hub, and thus the rest of your hosts on this hub. In the background, Mission portal uses the cfbs and git command line tools to manage your project. This also means you can work with the same project in your terminal and editor, or whatever tools and websites you use to work with git repositories. Here we can see the commits we made in Mission Portal from the GitHub UI:

Tip: CFEngine Build in Mission Portal will never force push to your git repository, so commit history is never lost. This means, in case of bugs or human errors, you always have the option to go back and revert undesired changes.

Updating

If there is a new version available for one of your modules, this will be highlighted by the UI:

And you can easily upgrade:

Tip: The same goes for masterfiles, the first module and the default policy set we provide. The traditional way of managing your policy is to make a fork of our default policy set and have all your policy mixed into it. The first step of upgrading to a new version of CFEngine is to upgrade your policy, which can be painful with this approach. Once you are using CFEngine Build to manage your policy, upgrading to a new version of the framework and standard library is done in seconds, not days.

Separation of data and policy

It is quite common to want to separate policy from data (configuration values). Policy might be shared across multiple environments and teams, while each hub has it’s own CMDB of configuration values. Additionally you may want some teams to be able to edit policy, while others only change values in the database. Today, with CFEngine Build in Mission Portal, and the CMDB functionality we’ve introduced previously, this is possible. Some modules already look for data from the CMDB and act based on it, for example:

The module for uninstalling telnet allows you to make an exception for specific hosts, using Host Specific Data. We will go further along this path, enabling more powerful input-based modules, and giving you a nice UI to specify inputs on many levels: project, hub, subset of hosts on a hub, or individual host.

Video

In this developer demo video, you can see the new functionality in action:

CFEngine Build System command line tool

Now, with CFEngine Build in Mission Portal, the cfbs command line tool is included in all Hub installations. We’ve also made several improvements to this tool, such as interactive prompts, automatic git commits, version selection, and more. Read more about this in the cfbs version 2 blog post.

Bodies for custom promise types

Custom promise types can now use custom bodies. These new bodies look exactly like the built in body types, to a policy writer there is no difference. For example, take a look at the experimental groups promise type:

body members foo
{
  include => { "alice", "bob" };
  exclude => { "malcom" };
}

bundle agent main
{
  groups:
    "foo"
      policy => "present",
      members => foo;
}

To learn more about custom bodies, read the blog post.

Changes in behavior

In the past few months we’ve announced some changes coming in this release:

• Renaming bundle agent main in MPF
• Files promises creating files by default
• Multiple cf-execd processes

Although we believe most users won’t be affected by this in a negative way, it is a good idea to look through them.

Inventory refresh and compliance report widgets

This release includes the new inventory refresh handling, compliance report design and widget which we also included in 3.18.2. See the 3.18.2 release announcement for more details on these features.

Changelogs

As always, you can see a full list of changes and improvements in our changelogs:

• 3.20.0 Changelog for CFEngine Community
• 3.20.0 Changelog for CFEngine Enterprise
• 3.20.0 Changelog for Masterfiles Policy Framework

Please note that the Enterprise changelogs contain only changes specific to enterprise. To get a full overview of all changes in a version, read all 3 changelogs.

Dependency updates

Compared to the 3.19.0 release from half a year ago, these dependencies have been updated:

Thank you to all the developers and maintainers of Open Source Software which make CFEngine possible!

Downloads

CFEngine Enterprise is free for up to 25 hosts, click here to go to the download pages with new packages.

Contributions

We encourage all of our users to get involved in the community and contribute. Feel free to use one of the following channels:

• Ask for help, share an idea, or start a discussion on GitHub Discussions
• Submit a bug report or feature request in our issue tracker
• Look through our curated list of issues for new contributors
• Browse the code or submit a pull request through GitHub
• Improve the documentation by fixing typos, adding examples, or explaining things you found difficult