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.
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.
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.
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.
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?
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.
