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.
Interested in running CFEngine for IoT?
Craig (Digger) shows building CFEngine for Yocto.
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.
I recently had a minor task involving changing an option - on one of our command line tools - from taking a required argument, to taking an optional argument. This should be easy they said; just change the respective option struct to take an optional argument, add a colon to the optstring, and get on with your life.
Well, it proved to be easier said than done. My initial expectation was that a solution similar to the one below should just work. And it does work, just not in the way I expected.
Interested writing CFEngine policy faster?
Jeff (CFEngine Community user) demonstrates his YASnippet library for CFEngine to make writing CFEngine policy significantly faster.
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.
This blog post will focus on the bash programming part of implementing a promise type. To understand what custom promise types are, and how to use them, you should read the introduction first.
To implement a custom promise type in CFEngine, you need a promise module. The module is an executable, and can be written in any language. It’s possible to write one from scratch, but to make it as easy as possible, we decided to provide libraries for common programming languages. In our previous blog post, we showed how to implement modules in Python. That’s great, it’s a powerful, expressive and readable programming language, however there is one drawback; installing python. Many systems don’t have python already, or have a version which is too old. So you will need to add policy to install / update Python, to make sure modules work correctly everywhere.
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:
Introduction In the CFEngine Core team, we have recently been working on a fix for our WaitForCriticalSection() function. In short, the function checks a timestamp in a chunk of (lock) data stored in a local LMDB database and if the timestamp is too old, it writes a new chunk of (lock) data with the new timestamp. However, this used to be done in separate steps - read the data from the DB and close DB, check the data and potentially write the new data into the DB. So, there was a race condition because if multiple processes did the same steps at the same time, they could have read and checked the same timestamp value and then write their own data with their new timestamps one after another. On the high-level perspective that meant multiple processes could have entered the critical section at the same time.
Announcing CF4! (or is it CF-FORTH?!) I imagine you didn’t expect such a big release so soon after our most recent release of 3.12.4 and 3.15.1 on March 26, but here it is: our alpha-release. Thus the reason for the .-4 in the version number. Of course choosing -4 has something to do with the fun of spelling FORTH without the ‘U’. Also, it’s nearly a palindrome and I imagine we’ll have a few alphas/betas before the final release is finished. (a good palindrome: a man a plan a canal panama)
Problem to solve When working on the new Federated Reporting feature for CFEngine we had to solve the problem of collecting data from multiple CFEngine hubs (feeders) on a single hub (superhub). CFEngine hubs are using PostgreSQL to store data, so, more specifically, the problem was how to collect data from multiple PostgreSQL databases in one PostgreSQL database. And because we are talking about ~1 GiB of SQL data per feeder hub and for example 10 feeders connected to a superhub here, the initial and trivial solution using basically this ETL (Extract Transform Load) pipeline - pg_dump | gz | ssh | gunzip | psql - provided really poor performance. The problem was in the last part of the pipeline - importing data using psql. Reading and writing 10 GiB of data of course takes a while, but we soon realized that I/O speed was not the bottleneck in this case.
In some performance critical situations, it makes sense to limit management software to a single CPU (core). We can do this using systemd and cgroups. CFEngine already provides systemd units on relevant platforms, we just need to tweak them. I’m using CFEngine Enterprise 3.12 on CentOS 7, but the steps should be very similar on other platforms/versions. This post is based on an excellent article from Red Hat: https://access.redhat.com/solutions/1445073
Using ps to check what CPU core is utilized Listing all processes and their core We can use ps to check CPU core for desired processes:
