CFEngine 3.5.2 is now available for download. This is a maintenance release of CFEngine 3.5, and introduces a number of fixes and improvements to both Community and Enterprise editions. New functionality has been included to the SQL builder and the Design Center integration in Mission Portal.
Changes in CFEngine Enterprise:
MongoDB has been upgraded to version 2.2.4 monitoring data has moved into a separate database - see db-move-monitoring-to-cfmonitor.js script to migrate data Improvements to the Mission Portal:
Every year, on the last Friday of July, we pause for a moment and think about the impact of system administrators on our world. It is hard to imagine how different our life would be if it was not for the sysadmin. The goal of the Annual SysAdmin Appreciation Day is to make us all think about that and find ways to express our appreciation for them. At CFEngine we know many of them. In the past weeks we have interviewed hundreds of them and we want to share some fun facts we have discovered which show why they deserve our appreciation.
CFEngine 3.5.1 is now available for download. This is the first maintenance release of CFEngine 3.5, and introduces a number of fixes and improvements to both Community and Enterprise editions. New functionality has been included to the SQL builder and the Design Center integration in Mission Portal.
Community repositories will be updated shortly.
Core Changes:
the CFEngine Standard Library in masterfiles/libraries is now split into promise-type specific policy files, and lives in a version-specific directory. This should have no impact on current code, but allows more granular include of needed stdlib elements (Redmine #3044) file changes are logged with log level Notice, not Error Bug fixes:
After work and discussion, the CFEngine developer team produced https://github.com/cfengine/core/pull/784 to make libraries/cfengine_stdlib.cf compatible with 3.4.x and older again, to modularize it, and to improve the upgrade experience. These changes will be in the upcoming CFEngine 3.5.1 release:
libraries/cfengine_stdlib.cf is now 3.4-compatible again, so upgrading will not break existing CFEngine installations. lib/3.5 and lib/3.6 contain the standard library with changes that require 3.5.x and 3.6.x, respectively lib/3.5 and lib/3.6 have multiple files instead of a single cfengine_stdlib.cf. This is the same content as the cfengine_stdlib.cf content, but split by promise type (e.g. lib/3.5/files.cf has file-related bodies and bundles). common.cf has promise bodies common to all promises, e.g. action and classes paths.cf has a utility common bundle called paths that lets you say, for instance, “$(paths.path[rpm])” instead of hard-coding the location of the RPM manager executable. 3.5.1 and newer will have new variables to store the CFEngine major, minor, and patch version separately. It all works just like before 3.5.0, except you don’t have to include a huge library. If you just want to set classes for a promise, include common.cf. If you just want process filters, include processes.cf.
CFEngine 3.5.0 Community Edition is now available for download!
At the same time we have updated the CFEngine documentation, which now lives in a new design and information architecture at https://docs.cfengine.com.
This latest release of CFEngine Community comes with a ton of improvements and new language features for policy writers. Many of these changes have been motivated by the great feedback and reports from our users, and a lot of changes were contributed by members of the growing CFEngine community. A big “Thank You!” to you all! Our package repositories will be updated shortly, and we will continue from here with monthly maintenance releases of CFEngine 3.5.x.
The Release Candidate of CFEngine 3.5.0 Community Edition is now available for download at:
https://cfengine.com/inside/myspace
We’re looking forward to your feedback to the changes and improvements!
Significantly improved parsing and evaluation of policies A large number of parser and evaluation problems have been fixed. Iterating over arrays with nested lists has caused many headaches and workarounds in previous versions of CFEngine. With 3.5, many of those can disappear.
Policy developers get clear and consistent messages from the stricter parser. Note: If your policy has syntactically incorrect code, then the new parser will mark those as errors. Fixing those errors should be straight forward, but we’re interested in hearing about your experience with this so that we can make this as smooth as possible and document the typical issues for the final release!
Bruce Carleton is the organizer of the San Francisco CFEngine User Group. He has a deep understanding of system administration for distributed systems and how to make it easy (and fun!) to use CFEngine for that. He sent a message to the user group email list, that we want to share with you:
Re: [SF-Cfengine-Users-Group] Automation Adoption Challenges and Analogies
During the last SF CFEngine users group, we had a good discussion about promoting adoption of CFEngine in our various environments. It can be a challenging thing to do, and I think it’s worth sharing some of my thoughts on the matter. This is an edited version of an email I sent out on the help-cfengine mailing list, so I apologize in advance for the resend to those who have dual subscriptions.
Recently support for Windows PowerShell was merged into the Enterprise Windows version of CFEngine. PowerShell is Microsoft’s enhanced shell, intended for more advanced system administration and programming tasks.
The change to CFEngine means you can seamlessly use PowerShell in your configuration policies, just like the normal “cmd” shell. It’s very easy, for example, say you have the following bundle:
bundle agent mybundle { vars: "mymessage" string => execresult("echo This is a message from cmd", "useshell"); reports: "$(mymessage)"; } This uses the regular “cmd” shell. To switch to PowerShell, just replace it with the following:
Over the last year we have changed the way we test our software from a manual process to a highly automated process. This new system is capable of taking a change from our source code repository and follow it all the way up to where we update our internal staging servers, thus giving us incredibly valuable information while keeping manual intervention to a minimum.
Overview Our test system consist of the following pieces:
If you are a programmer, you probably know and maybe even love the sprintf family of functions, which format output based on a format specification and on some input data. Here’s a description of the formats available in the GNU libc implementation.
I wrote an implementation called format() which will be in the upcoming 3.5.0 release. The format() function offers string and number formatting. To reduce the chance of security compromises, you can’t print pointer offsets or single characters for instance. The available specifiers are:
