Over three years ago we introduced git and systemd custom propmise types.
While these are quite functional I recently needed to manage a git repository that was private and so needed a way to authenticate to a git server, in this case gitlab.
Gitlab has project access tokens but we didn’t directly support any sort of authentication attributes on the promise type.
I ran across git credential as a way to provide authentication and thought it was a good fit.
Did you know CFEngine can self-organize hosts into different groups?
Say you have a few hosts that you want to reboot once a month. You don’t care when, but you want the hosts to self-organize and pick a date. The select_class attribute for classes type promises might be what you’re looking for. Let’s take a look.
We’ll keep things simple, so we want each host to self-select a day of the month (1-28).
The prolific contributor and CFEngine Champion Bas Van der Vlies joins the team for a chat about his history and experience with CFEngine dating back to version 1.0.3.
For this special Halloween edition Bas joined Cody, Craig and Nick to reflect on his journey getting into information technology beginning with chemical engineering through joining the Dutch National Compute Center where he was managing many SGI and AIX machines and where he discovered CFEngine and how it could help him manage all the machines. Bas went on to highlight some of his favorite features and discussed how CFEngine has evolved over the years. His advice for both new and old users is to check out some of the newer tooling like cf-remote and cfbs for the CFEngine Build system as they can dramatically help to simplify policy maintenance.
What’s the difference between an associative array and a data container in CFEngine?
CFEngine has two ways in which structured data can be used, associative arrays (sometimes called classic arrays) and data containers. Let’s take a look at a simple data structure.
Here we have two data structures, a_email an associative array and d_email a data container. The policy emits the JSON representation of each.
bundle agent __main__ { vars: "a_email[john@example.com][FirstName]" string => "John"; "a_email[john@example.com][LastName]" string => "Doe"; "d_email" data => '{ "john@example.com": { "FirstName": "John", "LastName": "Doe" } }'; reports: "JSON representation of a_email (associateve array):$(const.n)$(with)" with => storejson( a_email ); "JSON representation of d_email (data container):$(const.n)$(with)" with => storejson( d_email ); } Looking at the output, they are identical:
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.
Ever need to do some math during policy evaluation?
Sometimes configuration settings are based on available resources. For example, what if you want to calculate the size of shared buffers to be 25% of your available memory?
Let’s write some policy.
First, we need to figure out how much memory we have. Let’s parse this out from /proc/meminfo:
bundle agent __main__ { vars: "d_meminfo" data => data_readstringarray( "/proc/meminfo", "", "(:|\s+)", inf, inf); reports: "$(with)" with => storejson( "d_meminfo[MemTotal]" ); } R: [ "", "65505464", "kB" ] So, we have 65505464 kB of memory in total. Knowing that we can use eval() to calculate what 25% is.
Ever need to visualize the data your working with? storejson() to the rescue!
Let’s re-visit our example for sys.os_release from Feature Friday #12: Special variables:
bundle agent __main__ { reports: "My custom key 'NORTHERN_TECH_OWNER' contains $(sys.os_release[NORTHERN_TECH_OWNER])"; } R: My custom key 'NORTHERN_TECH_OWNER' contains Nick Anderson So, we saw the value of a single key, but if we don’t know what keys are available it can be useful to render the JSON representation. The with attribute in combination with storejson() provides a convenient way to visualize the JSON representation of structured data in CFEngine. Let’s adjust the policy:
I promised more Build modules in my previous monthly Monday module blog post: package-method-winget.
And here they are: windows-capability and windows-optional-feature.
Inventory Both of these modules use similar usage details to control whether to inventory and to promise the state for specific capabilities and optional features.
By default inventory is taken in the form of a classic array which ends up in the Mission Portal as a comma separated list:
OpenSSH.Server~~~~0.0.1.0:Installed, OpenSSH.Client~~~~0.0.1.0:Installed, etc. To disable this inventory, define the class disable_windows_capability_inventory or disable_windows_optional_feature_inventory in the data namespace. The data namespace is the default if you use Host specific data or Group data. If you want to set these in augments you will need to specify the namespace explicitly like this:
Ever want a custom CFEngine Agent logo? Check out agentsvg.
You can find agentsvg in core/contrib/ it’s a python script that can generate CFEngine agent logos.
python3 ./agentsvg.py > agent.svg python3 ./agentsvg.py --body="#f5821f" --head="#052569" > agent-body-head-colors.svg In addition to customizing the head and body colors you can customize the arm positions to be up, down, out or angled and the legs can be straight or out
python3 ./agentsvg.py --arms angled --legs out > agent-arms-legs.svg Happy Friday! 🎉
Did you know you can use variables in class expressions?
If you are reading this, you probably are already familiar with the ability to use class expressions to restrict the context of multiple promises. For example, here we have three reports type promises, all guarded by the class expression linux::.
bundle agent __main__ { reports: linux:: "Only hosts with the linux class"; "Will have these promises"; "In context"; } And, if you are tracking this series, you know that you can restrict the context of a single promise using if or unless.1 However, you can also use variables in class expressions. Let’s take a look.
