In CFEngine Enterprise we collect information from each system in the infrastructure as inventory. Some inventory is available by default, and more can be added using modules or writing policy. You can use inventory information to create a Compliance Report with checks that determine if the information complies with your security requirements. In this blog post, we will use some modules from CFEngine Build which provide inventory data, and build a Compliance Report on top of those.
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.
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. When the agent is finished the forked cf-execd process is left a zombie/defunct. The daemon wakes up every minute to see if it should do an agent run. The next time the original daemon cf-execd “wakes up” it will clean up that defunct forked cf-execd.
Saint Patrick’s Day makes us think of the color green. Spring is coming. Plants are starting to sprout amongst the dead grass and leaves from Fall/Winter:
Earth Day is just around the corner on April 22nd.
This reminds us of our commitment to the environment and ecosystems that surround us. As we at Northern.tech state in our corporate social responsibilities:
We have set an ambitious company-objective to “Become a net-zero carbon business by the end of 2022”.
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.
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.
Several months ago I started the practice of using CFEngine Enterprise and its Mission Portal UI on a daily basis to manage the connected devices in my home. To start, I brought up an old desktop machine, cfengine-hub, to use as my hub and downloaded Enterprise, which is free for use up to 25 hosts. The next step in using best practices is to deploy policy from a version control repository. I use a local git server named git-server-zero instead of GitHub or GitLab as I like to be independent of the cloud when possible due to privacy and environmental concerns. I will use the Mission Portal Version Control Repository settings section to setup this repo as the source of policy for cfengine-hub.
As a follow up to my previous “personal policy” blog I have exciting news:
An improved CFEngine is available for Termux! This provides a way to play with policy and implement policy on your non-rooted Android phone! Version 3.17.0a1-termux is an alpha release so understand it’s not heavily tested. That said, CFEngine for Termux is looking pretty awesome and useful. Highlights of features:
allow self-bootstrap to loopback since Android devices often change their IP address and bootstrapping locally seems to make some sense for a developer device and ability to play around, this is just as helpful on the desktop for that matter. packages promises work with local masterfiles or with patched policy server masterfiles (pkg uses apt_get which CFE supports) since Termux supports “real” versions of commands and doesn’t rely exclusively on busybox, CFEngine considers a Termux environment as a fairly full featured linux box in terms of commands and features runs as un-privileged account, CFEngine for Termux does NOT require root files promises work inside the /data/data/com.termux/files scope, not outside (unless possibly you have a rooted device, which is completely untested) masterfiles policy framework works well, paths for common commands are modified to adjust to termux’s prefix $PREFIX being /data/data/com.termux/files/usr. Some common paths are setup for creating policy that works on Termux and other unices (etc_path, tmp_path, bin_path, var_path). Not supported (yet):
My laptop was getting stale… I’ve been using it every work day for about 2.5 years now and so much software is installed it just boggles my mind. I really love it otherwise, open source, trying to be transparent, generally has worked amazingly! I have a Librem 15v3 from Purism. My home dir is a maze of old and new directories, odd files, tons of ~/Downloads junk. And the real kicker? I can’t build CFEngine core anymore! :( I tried to fix the situation but just couldn’t quite fix it. So the solution? Well reinstall PureOS of course and see if that helps things out.
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)
