On [2019-07-29 Mon] we released new builds of our Enterprise Hub packages for 3.12.2 and 3.14.0. This release addresses CVE-2019-10164.
PostgreSQL versions 10.x before 10.9 and versions 11.x before 11.4 are vulnerable to a stack-based buffer overflow. Any authenticated user can overflow a stack-based buffer by changing the user’s own password to a purpose-crafted value. This often suffices to execute arbitrary code as the PostgreSQL operating system account.
CFEngine Enterprise LTS versions 3.12.0, 3.12.1, 3.12.2-1, 3.12.2-2, and non-LTS version 3.14.0 vendor PostgreSQL versions affected by this vulnerability. In the default configuration as access to root or cfpostgres local users must be achieved first.
This post has been re-published with permission.
CFEngine provides the services promise type to manage the state of a given service. services type promises are an abstraction of agent bundles, they can be used to declare the desired state for a collection of things identified by a name. Most commonly services type promises are used to manage standard operating system services though they can be used for abstracting other logical states. By default, bundle agent standard_services is used for the service_method in promises that specify no specific service_method.
This was originally published here, it has been re-published with permission.
How can I execute a command that uses command substitution in CFEngine?
On the console I might execute something like this:
Listing 1: Example command substitution
touch /tmp/file-$(date --iso-8601) ls /tmp/file-* /tmp/file-2019-03-08 I recommend not executing commands using substitution. Instead, prepare all that you need up front. Get the result of the data command and put it into a CFEngine variable, then use the CFEngine variable directly.
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.
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.
We’re happy to announce that CFEngine 3.7.6 is released! With 3.7 being a stable LTS branch, 3.7.6 brings bug fixes and stability enhancements to the CFEngine customers and community. Looking at the CFEngine release schedule, we can see:
3.7 LTS is maintained (and supported for enterprise customers) until July 17th 2018. 3.10 LTS is maintained (and supported for enterprise customers) until December 27th 2019. If you are planning to contribute feature to the next feature release (thank you!), please note that we wold need the pull requests ready for merging by the end of September for incorporation into 3.12. If you are planning to contribute fixes to 3.10 or 3.7 LTS please note that we would need the pull requests ready for merging by the end of September for incorporation into 3.7.7 and 3.10.3. RPM packages now respect the chkconfig specified state when stopping a service. Now if the cfengine3 service is off for runlevel 2 the CFEngine services are stopped when you switch to runlevel 2. cf-monitord now correctly detects the usernames for processes on AIX. Classification when running under the Xen Hypervisor was also fixed. Masterfiles got fixes to the apt_get package module so that it works correctly when more than one source repository contains the package. Masterfiles also saw the addition of oslevel (on AIX), mailx (on Linux, Darwin, OpenBSD, NetBSD, and FreeBSD) to the paths bundle. The prunetree bundle was added to the standard library making it easier to recursively delete files and directories up to a specified depth older than a specified number of days. Enterprise gets bug fixes related to exporting reports and sharing host categorization views and reports. Additionally when hostnames are displayed in reports they now link to the individual host info page and usernames are now allowed to contain dots (.). Masterfiles now ensures the postrgres log file is rotated. The verbosity of some maintenance policy was increased and the policy to clear a build up of unreported data now includes previous_state and untracked reports. Some Enterprise dependencies were updated:
With more and more services using SSL keeping track of the certificates in use across a global infrastructure can be challenging. The inventory reporting features in CFEngine Enterprise can be useful in identifying services using SSL as well as when their certificates will expire. cf-monitord provides lists of ports that are listening. We can use openssl to connect to each listening port and if successful we can extract the certificate information for inventory. We won’t be able to find ALL certificates like this. This policy only covers up-front SSL/TLS. From Serverfault:
We’re happy to announce that CFEngine 3.11.0 Beta (non-LTS) is now ready. Thanks to everyone for all of the contributions! Please test extensively and submit bug reports. 3.11.x introduces some new features and deprecates some underutilized functionality. Please note that 3.11.0 will be a non-LTS release, which means that it will be maintained only for 6 months from the release date and not supported for CFEngine Enterprise customers (but Enterprise packages will be available). Looking at the CFEngine release schedule, we can see:
We’re happy to announce maintenance releases for both supported CFEngine release branches today! Being maintenance (aka patch) releases, the goal is to increase stability and reliability for CFEngine users and enable a safe upgrade-path. As such, the releases primarily include bugfixes and low-risk changes that do not impact the compatibility between previous patch releases. Looking at the CFEngine release schedule, we can see that
3.7 LTS is maintained (and supported for Enterprise customers) until July 17th 2018 3.9 non-LTS is no longer maintained 3.10 LTS is maintained (and supported for Enterprise customers) until December 27th 2019 If you are planning to contribute features to the next feature release (thank you!), please note that we would need the pull requests ready for merging by early-April in order to have time to incorporate them into 3.11. If you are planning to contribute fixes to 3.10 LTS please note that we would need the pull requests ready for merging by early-May in order to have time to incorporate them into 3.10.2 LTS.
Last week we attended Config Management Camp in Gent Belgium.
How did automation start? In the beginning Mark split light from dark…
There were 7 talks in the CFEngine devroom. Christian Linden kicked things off with his presentation “Get set for getting work done by CFEngine”. He covered the basics of what you need to know when getting started with CFEngine as well as some tips to help in debugging policies. After Christians Kickoff I talked about “Testing CFEngine Policy”. Why you should test, currently available testing frameworks, how to get started writing tests that produce TAP and or JUnit output and finally how to expand CFEngines test coverage while contributing to examples in the documentation. Martin Simons wrapped up the first day with his talk “CFEngine Hero of IoT”. Martin brought a Raspberry Pi running Raspbian told us how he is using it to implement a motion-activated security system built with commodity hardware at home and then demonstrated how CFEngine can easily manage it and deployed a tomcat application. The main topic of conversation on Tuesday was data. How to separate it from policy, how to make use of external data, and how it can make your life easier in SURFsara. Bas van der Vlies started us off with his talk “How to use the augments file (def.json)”. He showed how he defined a host specific data file that let him easily override default values for a specific service/bundle. He discussed how this has had great benefits for non CFEngine users in his environment, allowing them to easily identify which service/bundles are activated for a host and exceptions that each host is overriding. Next Jurica Borozan talked about “Merging Technologies, ideas on using CFEngine with cloud and container technologies”. He discussed how his tag based classification system enabled host specific policies to be delivered and the varying ways that this common model could be applied to physical systems, docker containers, and cloud hosts leveraging the features available in each technology stack. He finished up by demonstrating his policy that managed maintaining a specific number of AWS instances for a given image and how a simple change in his data source (a json file) resulted in nodes being provisioned or destroyed within 5 minutes. Neil Watson gave a short remote talk “CFEngine Simplified with EFL”. He discussed the design philosophy of EFL and how you can leverage the framework to get things accomplished with CFEngine without having to know any policy. I wrapped up talks with a short presentation on “The Masterfiles policy Framework: A short history and future direction”. I presented the lineage of the current policy framework, how we got to where we are today and how data (the augments file def.json) is very much at the core of how we expect to improve usability and ease future policy framework upgrades without having to edit policy. Special thanks to Christian, Martin, Bas, and Neil for sharing your thoughts and presentations. We look forward to seeing everyone again next year!
