Within the configuration management space, people often distinguish between agent-based and agent-less approaches. In short, an agent-based solution means that you install a software agent to run in the background / periodically on the system. That software agent then makes changes to the system as desired, and also commonly communicates over the network to send and receive updates, policy, commands, scripts, data, etc. On the other hand, an agentless system does not involve installing something new, they instead rely on some software which is (presumed) already installed, like the SSH server, which can be used to acces and make changes to the system.
Curious about getting visibility of a host where you can’t install CFEngine natively, but can run a container?
Craig shows us how he’s getting inventory from his Torizon Verdin IMX8MP by deploying a container with a chroot containing volumes bind mounted from the host.
A long post show discussion was had about CfgMgmtCamp as well as a long troubleshooting session dealing with a prickly package management situation.
Video The video recording is available on YouTube:
Join the team for a sneak peek of what’s coming in 3.23.0.
Herman joins Cody, Craig and Nick to discuss what’s new in the upcoming release of CFEngine 3.23.0. We look at improvements to Groups in Mission Portal with easier ways to specify specific hosts that should or should not be part of the group based on reported attributes. This new functionality makes it much easier to affect change across a set of hosts without touching policy.
Ever been curious about Docker details or the cruft that has built up and could be cleared out?
Craig, Cody, and Nick chat about some of the work Craig has been doing recently, using Docker in development and CI. Craig shows how to develop policy to inventory various Docker details like image names, counts of dangling images, and reclaimable disk space.
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.
File integrity monitoring is an important aspect in managing your infrastructure. Tripwire and AIDE are often cited as necessary tools by compliance frameworks1,2,3. Of course CFEngine can manage a file to make sure it contains desired content, but did you know that CFEngine also has the capability to simply monitor a file for change? In this blog post we take a look at CFEngines’ changes attribute for files promises.
File promises, changes body To monitor a file for change in CFEngine you must have a files promise with a changes body attached.
On October 25th 2022 the OpenSSL project team announced 1 the forthcoming release of OpenSSL version 3.0.7. From the announcement we know that a fix will be made available on Tuesday November 1st, 2022 for a CRITICAL security issue.
Note: CVE-2022-3786 and CVE-2022-3602 (X.509 Email Address Buffer Overflows) have been published 2. CVE-2022-3602 originally assessed as CRITICAL was downgraded to HIGH after further review prior to being published.
Affected versions The vulnerability is reported to affect version 3.0.x and does not impact OpenSSL 1.1.1 or LibreSSL3 4 5. The first stable version of OpenSSL 3.0, was released in September 2021. Older operating systems are likely using OpenSSL 1.1.1, which is not affected.
CFEngine and Ansible are two complementary infrastructure management tools that both work with so-called inventories. However, the common term can be quite confusing because the way they are defined and created is very different for an Ansible Inventory and for a CFEngine Inventory. In the most basic case, an Ansible Inventory is just a file with a list of hosts and groups of hosts that Ansible then manages when fed the inventory file. On the other hand, CFEngine Inventory is a database of information about all the hosts in the infrastructure managed by CFEngine which the hosts themselves report. In a more complex scenario, an Ansible Inventory can also contain a lot of information about the hosts in the infrastructure, but those need to be pulled from somewhere else and given to Ansible. With CFEngine, hosts talk to a CFEngine Hub, pull policy from it and report information back to it. On the other hand, with Ansible, policy is pushed to the hosts from one place which thus must have a list of all hosts available in advance, potentially with some extra information (parameters) of the hosts.
If you are debugging issues with a host, it is quite common to want to make changes to CFEngine policy, and speed up the process of fetching, evaluating and reporting for that host. You can do this by running cf-runagent and cf-hub from the command line, now we’ve brought this functionality into Mission Portal:
You can see the feature in action, here:
I have a setup at home where I keep a local git server running on a Raspberry Pi 3 which contains personal/work journal, dotfiles and a personal policy repository. It was set up manually so before adding a new git repository for a family password store I set about retrofiting the configuration in CFEngine. The goal in this blog is to ensure that what I have already is managed by CFEngine and that what I want to add, /srv/git/passwords.git, is created.
Blazing the trail CFEngine was the first Configuration Management solution on the market, and while we have made many and significant changes and improvements to CFEngine in that time, we stay true to the principles that make it such a great product and technology. There are many things that have changed in the market, not at least the competitive situation, we believe that fundamentally many of the challenges stay the same. It then follows that good architecture should not be sacrificed for short term hype. In this short blog post, I will go over a few of the items that lead to CFEngine’s excellence, longevity in the market, and current strong position.
