The good we secure for ourselves is precarious and uncertain until it is secured for all of us and incorporated into our common life. How often do you verify your compliance? Once or twice a year? Have you considered reporting on compliance continually?
The usual suspects, Cody Valle (Head of community), Criag Comstock (Digger), and Nick Anderson (Doer of Things) see how CFEngine Enterprise can be used to implement and report on compliance, specifically the Ubuntu 20.04 Security Technical Implementation Guide (STIG). Nick shows how tagging variables for inventory and Mission Portals compliance reports can be used to implement compliance reporting that is continually verified.
Ever wish that you could run Mission Portal at Home?
Some of the CFEngine team gathers in Oslo Norway to do the show live, together. Criag Comstock (Digger) demonstrates how to use cf-remote to access new ARM64 packages for CFEngine Enterprise (Hub and Clients) and experiments with CFEngine Build in Mission Portal.
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 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! It helps keep your systems secure and compliant with whatever policy you may require.
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
Note: All paths unless otherwise noted are relative to the root of your policy set (typically /var/cfengine/masterfiles is the distribution point). cf-agent and other commands are run as the root user.
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. Windows, on the other hand, provide the CreateProcess() function which starts a given program in a newly created process. Why are UNIX-based systems doing things in a more complicated way? There are many reasons for that, some simply historical, as described in The Evolution of the Unix Time-sharing System:
How can I run my own bundles automatically, like autorun from the MPF (Masterfiles Policy Framework), but with different logic?
Cody Valle (Head of community), Criag Comstock (Digger), Ole Herman Elgesem (Product Manager) and Nick Anderson (Doer of Things) review the existing capabilities and limitations of autorun in the MPF. After reaching the limits offered by the stock framework they explore implementing a custom autorun, for example recursively finding policy files or only including policy files with associated enablement classes.
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. Now we want to share the story and the results of the effort, but since understanding of the reasons behind the work together with how the implementation works requires quite deep knowledge of how processes are being created and programs are being started on UNIX-like systems, we first start with a series of blog posts focused on this seemingly simple area. They cover the basics as well as some advanced topics in two parts:
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. 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.
