We are today very excited to bring you new updates to CFEngine. This is a set of patch releases for the CFEngine 3.12 LTS and 3.15 LTS series. We usually release new patch releases every 6 months, but we want to bring new features and all improvements and bug fixes to our users as soon as possible. Hence these early releases. In CFEngine 3.15 LTS we introduced Federated Reporting, our single pane of glass reporting architecture. This is a great new feature that allows you to set up a dedicated Hub that collects all reporting data from your entire infrastructure to really provide a single pane of glass into all your operations. In this patch release, we have included several performance improvements and bug fixes. There are no new features or larger changes in these patch releases. We focus on stability, improving performance, fixing bugs and are actively listening to open source users and customers alike when planning what to fix. We hope you enjoy the faster release this time and benefit from some of the improvements we have made.
CFEngine 2 network communication is insecure by today’s standards.
CFEngine 2 CVE-2016-6329: CFEngine 2 uses Blowfish cipher (1993) which today is considered: Weak Deprecated Subject to key recovery attack No security fixes since 2008. Protocol communications not encrypted; only data transfer (which facilitates attack). Encryption is off by default. CFEngine 3 All communication is encrypted Uses TLS 1.3 (current state of the art) Up to date, maintained, secure from the software vendor Full Enterprise support, with SLA. Solution CFEngine 3 was intentionally designed so that you can install it side by side with 2, so you have time to migrate your policies from 2 to 3.
Recently I wanted to start measuring the length of time it took for PostgreSQL to acquire a lock so that I could keep an eye on how it changes over time.
My PostgreSQL logs contain entries like the following that record the amount of time in ms it took to acquire a lock.
2019-06-11 18:49:39 GMT LOG: process 10427 acquired AccessShareLock on relation 17949 of database 16384 after 1118.396 ms at character 269 Measurement promises store and track values. Values can be sampled from either a pipe (command output) or a file as defined by the promises stream_type. Values are stored according to the promises history_type. When a measured value is not expected to change frequently a history_type of scalar or static will result in the measurement being sampled less frequently and the single value with compressed statistics will be stored. A history_type of log results in the measured value being logged as an infinite time-series in $(sys.statedir)/<PromiseHandle>_measure.log. A history_type of weekly results in the storing of a two-dimensional time average over a weekly period. Measurements with history_type of weekly are automatically graphed in Mission Portal if they are collected.
This was originally published here, it has been re-published with permission.
How can I execute a command that uses command substitution in CFEngine?
On the console I might execute something like this:
Listing 1: Example command substitution
touch /tmp/file-$(date --iso-8601) ls /tmp/file-* /tmp/file-2019-03-08 I recommend not executing commands using substitution. Instead, prepare all that you need up front. Get the result of the data command and put it into a CFEngine variable, then use the CFEngine variable directly.
This post was syndicated with permission from the original source.
CFEngine 3.12.0 introduced the augments key to the Augments file format. If you are not already familiar with Augments, check it out. It’s a very easy way to define classes and variables very early during agent execution, before policy.
The new augments key allows you to merge additional data in the augments format on top of the base augments. I However, there is, I think, still a simple way to accomplish this. This can provide a flexible way of providing different data to different sets of machines.
This post was syndicated with permission from the original source.
How do you deal with config files that need different settings based on various services that are running on a host and cooperate with other teams? It’s a common question, and it came up on in #cfengine on libera.chat recently.
The issue is that team A might be working on package A, which requires some environment variables set. But team B might be working on a totally different thing – and want to achieve the same thing. I hoped to give them a bit of ’library’ code to take care of it, rather than have them touch a centralized environment-setting policy file.
At SURFsara we use CFEngine on our National Compute Cluster (LISA) and other systems as our configuration management tool. With the release of CFEngine 3.12 I want to highlight 2 new features, namely:
missing_ok multiple augments We use these 2 new features heavily in our framework in combination with my open source library cf_surfsara_lib. This library aims to be a central repository for configuring services, eg: ssh. For configuring the services we use JSON as data format and it is easily to override the default values via JSON. Pre CFEngine 3.12 there is only one strategy possible:
Authored by Brian Bennett of Digital Elf
I’ve been working a lot with CFEngine newbies. CFEngine has been described as flour, eggs, milk and butter. All the ingredients needed to make a cake. Getting the new CFEngine user to recognize, then become excited about the possibilities that CFEngine provides they are now faced with the question of “What next?”
Indeed, anybody can throw some flour, eggs, milk and butter into a bowl, mix and bake it. But will it taste good?
