This tutorial focuses on how to write a promise module, implementing a new CFEngine promise type. It assumes you already know how to install promise modules and use custom promise types, as shown in the previous blog post.
Why Python? Promise modules can be written in any programming language, but there are some advantages of using python:
Readable and beginner friendly language / syntax Popular and familiar to a lot of people, also used in some CFEngine package modules Big standard library, allowing you to reuse data structures, parsers, etc. without reinventing the wheel or adding dependencies Official CFEngine promise module library Most of the code needed is already done (protocol, parsing, etc.) You can focus on only the business logic, what is unique to your new promise type With that said, there are some reasons why you might not always want to use python:
In CFEngine 3.17, custom promise types were introduced. This allows you to extend policy language, managing resources which don’t have built in promise types. The implementation of custom promise types is open source, and available in both CFEngine Enterprise and CFEngine Community. To implement a new custom promise type, you need a promise module. (The promise type is what you use in policy language (the concept), while the module is the underlying implementation - can be a python script, compiled executable or similar).
We are pleased to announce the release of CFEngine 3.17.0, with the theme Flexibility! This is a non-LTS release and allows the CFEngine community to test the features which will be in CFEngine 3.18.0 LTS (Summer 2021).
What’s new? A new look - Mission Portal Dark Mode Mission portal now gives you the option of switching to an alternate color theme, dark mode:
Trigger report collection from Host Info Page You no longer have to wait for the next reporting interval, or use the command line to get updated reports. Click the button on the host info page to trigger a report collection:
We are pleased to announce two new patch releases for CFEngine, version 3.12.6 and 3.15.3! These releases mainly contain bug fixes and dependency updates, but in 3.15.3 there are also some new enhancements in Mission Portal. The new cf-secret binary is also included in 3.15.3 packages.
New in Mission Portal 3.15.3 Synchronizing roles between Mission Portal and Active Directory When using LDAP for authentication, Mission Portal can now automatically grant roles based on the tags received from your LDAP server (for example Active Directory). This means that new users can start using Mission Portal immediately, without having to wait for an administrator to grant the appropriate roles manually. Enable this in Mission Portal Authentication Settings:
Nightly packages are very useful for testing new features of CFEngine. Right now (as of August 2020), nightly packages can be used to test out these new features:
Compliance Reports. Mission Portal Dark Mode. New host info page with variable pinning and copy buttons. Note that these features are in development, some parts may be unfinished or buggy. Nightly packages are not supported and should not be used in production environments.
Today we announce the newest additions to CFEngine. CFEngine 3.16 brings several improvements, bug fixes, and new features. The theme for this release has been compliance, and it notably includes a new category of reports for proving compliance to regulation and other compliance frameworks in high level, easy to read reports. If you are interested to learn more about CFEngine, schedule training, or hear about pricing options, feel free to reach out to us!
Yesterday, packages for CFEngine 3.12.5 and 3.15.2 were made available. This release announcement was delayed in support of Blackout Tuesday in the United States of America. We are pleased to announce two new patch releases for CFEngine, version 3.12.5 and 3.15.2! These patch releases don’t contain major changes or new features, but rather fix important bugs reported by our community of users and customers. Some users reported issues with federated reporting, specifically related to non-reporting hosts. These issues are fixed in policy in the newest releases, upgrading to the latest version of Masterfiles Policy Framework (MPF) resolves them. A race condition during report collection was mitigated. This could in some cases cause a failed report collection, scheduling a retry (rebase), and emitting errors in syslog. The race condition only happened with long running agents, or agents running at the same time as report collection. It only caused errors in some very specific situations, so this was not caught by our tests, and most users did not experience the issue. Also, in relation to reporting, the hub can now query itself over the IPv6 loopback address, ::1, similar to 127.0.0.1.
Contributor and CFEngine Champion, Jon Henrik Bjørnstad, developed a tool for encrypting files using CFEngine host keys, called cf-keycrypt. Thank you to Jon Henrik and all of our contributors for helping improve the CFEngine project. Our developer, Vratislav Podzimek, recently took some time to review the cf-keycrypt code, and made many improvements and fixes. The most notable changes were:
Switched to hybrid encryption (payload is encrypted with randomly generated AES key, AES key is encrypted with RSA key). Added file format, with HTTP-like headers for metadata Files can be encrypted for multiple hosts (host keys) Name changed to cf-secret cf-secret is now merged and will be a part of the upcoming 3.16 release.
A vulnerability was recently discovered in CFEngine Mission Portal and has now been fixed. Under certain circumstances, it was possible to inject JavaScript code into data presented in Mission Portal, that would be run in the user’s browser. This security issue was fixed in CFEngine 3.10.7, 3.12.3, and 3.15.0, and will be mitigated by upgrading your hub to one of these versions (or later). No other action is required than upgrading the Hub. This issue is present in CFEngine Enterprise 3.7 versions, 3.10.0 through 3.10.6, as well as 3.12.0, 3.12.1, and 3.12.2. All customers have been notified prior to this announcement and had time to address the issue. Any community users who use CFEngine Enterprise Free 25 should upgrade immediately. Open source versions of CFEngine (CFEngine Community) are not affected, as they do not include the Mission Portal Web UI. The security of the CFEngine product and our users is something we take very seriously, and we will continue to look for, fix and responsibly disclose serious weaknesses in our product(s). This issue has been registered as CVE-2019-19394 in the official public CVE registry. If you have any questions or concerns please contact CFEngine support if you have a support contract or email security@cfengine.com
About a year ago, I wrote a small python script to automate installing and bootstrapping CFEngine on virtual machines in AWS. It had some hard coded IP addresses that I needed to update when I spawned new hosts, but other than that, it worked well. During manual testing, it saved me a lot of time instead of having to do things manually. Deploying CFEngine normally consists of these steps:
Determine what CFEngine package to use. Download appropriate package if you haven’t already - curl. Copy the package to the host - scp. Log into the host - ssh. Install the package - rpm / dpkg. Bootstrap CFEngine - cf-agent -B. At a company hackathon I decided to make my script into something better, something that would be useful to my colleagues, and maybe even CFEngine users in general. Enter cf-remote.
