Have you ever wondered how a site was designed and how the ideas were conceptualized into the final result? If your answer is yes, you are in the right place! In this post, I will show you our journey to create our latest website, CFEngine Build. From start to finish, how did we do the design and make the design decisions? So without further delay, let’s jump straight in!
Earlier this year, we hinted at what we were working on - a place for users to find and share reusable modules for CFEngine. Today, the CFEngine team is pleased to announce the launch of CFEngine Build: The new website, build.cfengine.com, allows you to browse for modules, and gives you information about how to use each one of them. When you’ve found the module you were looking for, it can be downloaded and built using the command line tooling.
Still interested in running CFEngine on IoT? Craig (Digger) shows building CFEngine Enterprise for Yacto and deploys a Raspberry Pi Zero with a sensor to measure the height of Nick’s (Doer of Things) desk. 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.
The CFEngine engineering team has recently discovered two security issues in the CFEngine Enterprise product: CVE-2021-38379 - Publicly available exported reports CVE-2021-36756 - Certificate not checked in Federated Reporting While the latter one (CVE-2021-36756) only affects CFEngine Enterprise deployments using the Federated Reporting functionality, the former one (CVE-2021-38379) affects all deployments running all supported versions of CFEngine Enterprise (and many unsupported versions, 3.5 or newer, to be more precise). Both issues were discovered internally during development and testing and we have no indications of these vulnerabilities being exploited or known of outside of the development team.
When working with CFEngine, it’s common to hear advice about separating data from policy. Separating data from policy allows for separation of concerns, delegation of responsibilities and integration with other tooling. Each organization is different, and a strategy that works well in one environment may not work as well in a similar environment of another organization, so CFEngine looks to provide various generic ways to leverage external data. For example, Augments (def.json) is useful for setting classes and defining variables very early during the agent execution which can be applied to the entire policy having differences based on system characteristics as well as being used for host specific data.
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.
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.
Interested in running CFEngine for IoT? Craig (Digger) shows building CFEngine for Yocto. 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.
Manually managing groups on a large infrastructure can be a tedious task, and is therefore best suited through automation software like CFEngine. Unfortunately - at time of writing - CFEngine does not have any built-in promise types for managing groups. But fear not; in CFEngine 3.17, custom promise types were introduced. This new exhilarating feature does not only allow for members of our community to make their own custom promise types, but also lets the CFEngine Core developers prototype new future promise types. In this blog post, I’d like to introduce one of our prototypes; the experimental groups promise type.
Come see what’s new in CFEngine policy management! Herman (Product Manager) introduces and demonstrates new tooling, the CFEngine Build System (cfbs). cfbs is a command line tool to facilitate policy management and consuming modules written by others. 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.
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
