cf-runagent is a component for triggering remote agent runs using the CFEngine network protocol. It does not allow for arbitrary commands to be executed, but rather asks the remote host to run the policy it already has. To trigger cf-runagent from other systems or web interfaces, you want to be able to run it as non-root.
Install and bootstrap I will use cf-remote to set up a demo hub running CFEngine Enterprise 3.12.1:
CFEngine is very simple to set up and use, especially if all of the clients and the hub are going to be using the same promises. But what if there are certain things you want to enforce on a hub and not a client? What if there are certain things you want to enforce on a client but not on a hub? For example, if you are using the Git Setup, you want the hub to pull from the Git repository, but you don’t want the clients to do this. You want the hub to make those changes available to the clients only after it’s verified them. So how do you have a promise that only enforces on the hub, and not on a client? A simple solution is to use the am_policy_hub class to conditionally pull from Git if the server is a hub:
The CFEngine policy analyzer is an awesome new service introduced in CFEngine 3.13. The policy analyzer allows you to quickly debug policies and inspect what is going on under hood of CFEngine. A known challenge with CFEngine, and most DSL based automation tools, relates to understanding what is actually going on during live operations. Many users view it as “black-box magic”. Unfortunately, the amount of magic and the size of the black box increases with the level of automation. This is undesirable. Enter the policy analyzer.
This post was syndicated with permission from the original source.
CFEngine 3.12.0 introduced the augments key to the Augments file format. If you are not already familiar with Augments, check it out. It’s a very easy way to define classes and variables very early during agent execution, before policy.
The new augments key allows you to merge additional data in the augments format on top of the base augments. I However, there is, I think, still a simple way to accomplish this. This can provide a flexible way of providing different data to different sets of machines.
CFEngine 3.12.1 LTS has now been released. This release brings many stability and performance improvements to the 3.12 LTS series. It is a stable and well-tested version of CFEngine. We wish to extend a big thanks to the ecosystem that helps make CFEngine great by reporting bugs, contributing fixes and suggesting new and improved functionality. Without you, CFEngine would not be the powerful, high performance, widely used product we all appreciate today! We hope and think this release meets the high standards we know all our users have. That is why you chose CFEngine in the first place! This is a good time to start thinking about updating to 3.12, as this is the best and most long-term solution available. You can read more about our supported versions here, but in short, we can highlight that:
Today we are very happy to announce the release of CFEngine 3.13.0. This is a non-LTS release, introducing new features and functionality. There is a lot happening with CFEngine these days! This release is closely following last weeks release of CFEngine 3.10.5 LTS, and soon we will also release the next patch version of our 3.12 LTS series. So keep following our updates!
Contribute to CFEngine Did you know that CFEngine is a dual license open source project? And not only that, we are encouraging community contributions, and are always looking for ways to improve and grow our ecosystem. We encourage you to contribute and participate in the fun development of CFEngine! Do you want to start contributing but are unsure how?
This post was syndicated with permission from the original source.
How do you deal with config files that need different settings based on various services that are running on a host and cooperate with other teams? It’s a common question, and it came up on in #cfengine on libera.chat recently.
The issue is that team A might be working on package A, which requires some environment variables set. But team B might be working on a totally different thing – and want to achieve the same thing. I hoped to give them a bit of ’library’ code to take care of it, rather than have them touch a centralized environment-setting policy file.
Today we are very happy to announce the maintenance release of CFEngine 3.10.5. This is an update to the LTS 3.10 series, adding improved stability, several bug fixes and increased performance. 3.10 LTS is the successor of 3.7 LTS that, since August 2018, is no longer supported. We recommend everyone still using CFEngine 3.7 to upgrade to either 3.10 or 3.12. We are available to support you with such an upgrade if you need it. 3.10.5 LTS is a maintenance release (also known as a patch release), with the goal to increase the stability and reliability for CFEngine users and enable a safe upgrade path. As such, this release primarily includes bug fixes and low-risk changes that do not impact the compatibility between previous patch releases. Looking at the CFEngine release schedule, we can see that
At SURFsara we use CFEngine on our National Compute Cluster (LISA) and other systems as our configuration management tool. With the release of CFEngine 3.12 I want to highlight 2 new features, namely:
missing_ok multiple augments We use these 2 new features heavily in our framework in combination with my open source library cf_surfsara_lib. This library aims to be a central repository for configuring services, eg: ssh. For configuring the services we use JSON as data format and it is easily to override the default values via JSON. Pre CFEngine 3.12 there is only one strategy possible:
In some performance critical situations, it makes sense to limit management software to a single CPU (core). We can do this using systemd and cgroups. CFEngine already provides systemd units on relevant platforms, we just need to tweak them. I’m using CFEngine Enterprise 3.12 on CentOS 7, but the steps should be very similar on other platforms/versions. This post is based on an excellent article from Red Hat: https://access.redhat.com/solutions/1445073
Using ps to check what CPU core is utilized Listing all processes and their core We can use ps to check CPU core for desired processes: