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:
Last week, we revamped the way CFEngine formats output. You can continue to use the old output format by specifying the option –legacy-output (-l), but this is considered deprecated and may be removed in a future version.
The key features of the new output format is as follows.
Consistent look for all messages, as formatting is taken care of by the logger. Separate formatting for terminal, syslog, and (eventually) file. Attempts to follow conventions for formatting to separate sinks. ISO 8601 timestamps to terminal. Every statement is single line. No banners and decorations within messages. Conventions for how to write messages. Logging levels (e.g. specifying –verbose always implies –inform), aligning with syslog levels. Logging system knows about evaluation state and may format messages conditioned on what the CFEngine is currently trying to do. This is perhaps best illustrated by an example (in this case, written to terminal).
IT-organizations around the world face constant pressure to do more, do it faster and with fewer resources. They are seen as cost centers and as such benchmarked against the performance of nimbler competitors and the public cloud providers.
IT-organizations feel that pressure from multiple sources at the same time. The CFO compares his internal IT-budgets with the costs of public cloud offerings and demands comparable savings. The lines of business know they can get the latest applications and platforms within minutes in the public cloud and complain about the slowness of their internal IT department. And the end-users expect continuous availability of all IT-services. Add Moore’s law to describe the growth in scale and complexity of the IT infrastructure, and it becomes understandable why CIOs have the shortest tenure of all C-level executives.
Over the past month we have removed a bit of functionality for CFEngine. These were features that were useful (cf-report) and good ideas (knowledge management), but the implementation was either in an unfinished state or the design had unclear semantics (outputs promise type).
In order to get a smoother transition for existing policy, we have introduced GCC-style warnings for cf-promises, initially to warn users about removed or deprecated syntax. Deprecated syntax warnings signal that the feature will be removed in a future version, but is still functional with the current version. Removed syntax warnings signal that the feature has been removed.
Authored by Brian Bennett of Digital Elf
I’ve been working a lot with CFEngine newbies. CFEngine has been described as flour, eggs, milk and butter. All the ingredients needed to make a cake. Getting the new CFEngine user to recognize, then become excited about the possibilities that CFEngine provides they are now faced with the question of “What next?”
Indeed, anybody can throw some flour, eggs, milk and butter into a bowl, mix and bake it. But will it taste good?
