This guide is designed for the novice user of CFEngine who wishes to explore the power of Emacs while developing CFEngine policy files – and will introduce the use of some Emacs features and plugins along the way. There are two types of editors available in the Unix and Linux world: line and visual. Examples of line editors are ed and sed. These allow you to edit a file one line at a time.
As a person who tries to work with as few resources as possible, whether it’s editing everything with ed(1) or using old laptops without screens for servers or turning off computers as much as possible I am happy to announce nightly packages are available for the aarch64 (ARM 64-bit) architecture. This enables low-power, low-cost devices such as the Raspberry Pi and many others to run CFEngine Enterprise. Why run CFEngine? It is lean on resources and rich in features!
What’s autorun? Autorun is a feature of the Masterfiles Policy Framework (MPF)1 that simplifies the process of adding and executing new policy. We have talked about Modular policies with autorun and the Augments before. This time, we dig into autorun a bit deeper to explore some of its current features and look at how to implement your own as we did during The Agent is In, Episode 15 - Extending Autorun
This is the second blog post in a short series about processes on UNIX-like systems. It is a followup to the previous post which focused on basic definitions, creation of processes and relations between them. This time we analyze the semantics of two closely related system calls that play major roles in process creation and program execution. fork() and exec() The UNIX-based operating systems provide the fork() system call1 to create a clone of an existing process and the execve() system call to start executing a program in a process.
While working on the integration of CFEngine Build into Mission Portal we came to the point where we needed to start executing separate tools from our recently added daemon - cf-reactor. Although it may seem like nothing special, knowing a bit about the process creation and program execution specifics (and having to fight some really hard to solve bugs in the past) we spent a lot of time and effort on this step.
Since joining the CFEngine team in 2019 I’ve heard and read numerous times that the configuration management market is dying and becoming obsolete. While I and many others don’t personally adopt this line of thinking, I can understand why one would come to this conclusion being that we’re in an ever-changing industry and talking about solutions that have been around for decades. Configuration management solutions like CFEngine are certainly not a new concept, however there are many changes that are happening across the industry that will continue to drive usage and will ultimately pave the way for a new era in this market.
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.
We are pleased to announce two new patch releases for CFEngine, version 3.15.6 and 3.18.2! These releases mainly contain bug fixes and dependency updates. What’s new Some smaller features and improvements were added to 3.18.2. Most of these are centered around newer functionality, such as compliance reports. Compliance report widgets and improved UI Compliance reports are one of our most powerful report types, allowing you to compile all your security and compliance requirements into one checklist, and easily see exactly how many hosts are failing and passing each check.
Recently we introduced new feature where you can trigger agent runs and report collection from the Mission Portal UI. This required our daemon cf-execd to behave a bit differently when periodic agent runs occur. Previously the daemon would create a new thread in which to run cf-agent, capture output, wait for completion and move on. We changed the behavior so that the daemon forks itself and then fork/execs cf-agent as before, with the forked cf-execd processing agent run output.
A while back we released version 2 of cfbs, and even though we release versions of this tool quite frequently, without announcing it on the blog, we thought this was a good opportunity to talk a bit about the tool, what’s new and our direction with it in the future. The reason why we called this the “2.0” release is that we are trying to follow semantic versioning, and there were some big new features in the release which could be considered breaking changes.
Sign up for CFEngine Enterprise and connect up to 25 hosts for free. No credit card required. Get started in minutes.
Try enterprise for free
