Originally posted by Nick on cmdln.org
You never know when the Zombie or Cloud Apocalypse is coming. It’s good to be able to locate those buried bodies quickly and easily. OK, enough bad jokes, but haven’t you ever looked at some CFEngine policy and wondered to yourself, exactly what does “delete => tidy” or some other body or bundle do?
I have. I even wrote a little perl script to locate the files that contained a specific body or bundle and then print out the single body or bundle. This past week my old script got some love. Ted Zlatanov and Bishwa Shrestha reworked it a bit so that it is no longer a hackjob, and it’s now included in contrib of the CFEngine core repository.
We’re proud to release the first Beta package of CFEngine 3.6 to the Community for testing. The new version of CFEngine introduces a huge number of new features to the CFEngine language and a lot of improvements behind the scene. Some highlights from the ChangeLog file: - New promise type “users” for managing local user accounts. - TLS authentication and fully encrypted network protocol - New attributes in ‘bundle server access_rules’ - New variable type ‘data’ for handling of structured data - Tagging of classes and variables with meta data - Many new built-in variables - Many new functions You can download the beta packages for Debian and RedHat based Linux distributions from https://cfengine.com/inside/myspace. The documentation for CFEngine 3.6 lives at https://cfengine.com/docs/master/index.html and is work in progress. We’d like to invite everybody to help us improve CFEngine 3.6 by giving this first beta a trial run. However, this version of CFEngine is not yet ready for production environments, so do not upgrade your existing installation to these packages. Due to the network protocol and authentication changes, compatibility between 3.6 and previous CFEngine versions is limited at this point, and will be improved over the coming weeks as we get closer to the release. To report bugs, use our bug tracker at https://cfengine.com/dev. Contributions in form of pull requests can be made on GitHub at https://github.com/cfengine/core. A big shout-out to all the contributors in the community that have supported our work with feedback, bug reports, input to design discussions and code contributions!
Another year has passed and we would like to take a moment to thank the community members for their contributions. From speaking at conferences, epic blog posts, community meet-ups, to support on the CFEngine help list and in the IRC channel, new and veteran users alike don’t have to look far to find inspiration or a helping hand. Each year we like to reflect on our many community contributors and honor those that have significantly enhanced the CFEngine Community. This year it is my great honor to announce this year’s CFEngine Champion Hall of Fame inductees.
Having joined CFEngine only a few months ago (and being new to the Open Source movement and culture), attending our Bay Area meetup allowed me to come face to face with our community and hear about CFEngine deployment from the people who use it as their main tool. And let me tell you, there are some serious CFEngine warriors out there! In this blog post I will feature two of them. By pure chance both of them are called Bruce, but don’t worry, it’s not a prerequisite to be called that to join our community!
Many users have been asking for ways to limit the amount of some function invocations in CFEngine, inparticular functions such as execresult and returnszero. First, let me try to explain why functions were called so many times to begin with, and how we have approached this for version 3.6.
Functions may be executed during checking with cf-promises, or during normal evaluation.
When cf-agent executes a policy, it first runs it through checking with cf-promises. Many policy checks are static in nature (types, keywords, etc.), but since CFEngine is a fairly dynamic language, certain problems may only arise at run-time. Therefore, cf-promises has traditionally attempted to find these problems by executing all functions. For 3.6, we have turned off function evaluation for cf-promises, but retained the old behavior optionally using the flag –eval-functions.
CFEngine 3.5.3 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.
Changes in the CFEngine Core: Improved security checks of symlink ownership. A symlink created by a user pointing to resources owned by a different user will no longer be followed.
Changed the way package versions are compared in package promises. (Redmine #3314) In previous versions the comparison was inconsistent. This has been fixed, but may also lead to behavior changes in certain cases. In CFEngine 3.5.3, the comparison works as follows: <package-being-considered> <package_select> <package_version> For instance: apache-2.2.31 “>=” “2.2.0” will result in the package being installed. Bug fixes:
sigurd.teigen@cfengine.com R&D, CFEngine CFEngine has previously had multiple ways of loading data from an external file into a policy. This has been useful for basing policy on tablular data. For example, importing a CSV file to create accounts. Once data has been imported, it may be used using the existing CFEngine scalar and list data types. In order to make this more flexible, we are introducing a new data type ‘data’ for version 3.6 of CFEngine. A data container variable is an arbitrarly nested data structure of CFEngine primitives. You may think of a data container as a JSON document, because initially we are only supporting importing from JSON. However, this may change in the future allowing for importing data from YAML, XML and other files. Let us examine the flexibility and ease of use of this data type by way of an example. bundle agent test { vars: “doc” data => parsejson(’{ “a”: [ 1, 2 ], “b”: true }’); reports: “Hello $(doc[a]) $(doc[b])”; } This will output the following. $ cf-agent/cf-agent test.cf 2013-11-25T15:18:32-0500 notice: /main: R: Hello 1 true 2013-11-25T15:18:32-0500 notice: /main: R: Hello 2 true In this example, we use the function parsejson to assign a new data container. A data container may either be iterated as a list or as a scalar, depending on how it’s indexed. Above, we see that we index into a list ‘a’ in ‘doc’. Meanwhile, ‘b’ in ‘doc’ refers to a scalar. A list may contain other container types (list or maps), but only sibling scalars will be iterated over. Indexing works as in JavaScript, for example $(doc[a][1]) would refer to the second element in the list ‘a’ in ‘doc’. Currently, there is no inline syntax for data containers, although this is being planned for. A function readjson is available to import file, while function mergedata may be used to join existing data container variables into a new variable. We hope that data containers will be a practical way of working with structured data in policy, replacing current uses of arrays. Data containers are also used with the new Mustache template feature also in version 3.6. Learn more about CFEngine by visiting our website Evaluate CFEngine for free (upto 25 licenses, unlimited usage)
eystein.maloy.stenberg@cfengine.com Product Management, CFEngine Introduction The beauty and power of Docker comes from its ability to containerize any application into a portable self-sufficient entity, one that can run anywhere. This enables developers to deliver an application with all dependencies in a layered image structure. As if that was not enough, the images can be shared in an image repository (known as the Docker index) and deployed to and run on any Docker host. CFEngine, a pioneer in IT automation, enables organizations to become more agile by radically simplifying, automating and transforming the way they build, deliver and consume IT infrastructure and applications. With CFEngine, some of the largest IT organizations provision resources and deploy new applications orders of magnitude faster, while ensuring continuous availability, security and compliance in large-scale, very dynamic and highly complex environments. After applications are deployed, maintenance tasks such as process management and signaling, log management, and managing run-time configuration consistency and compliance become important. CFEngine is designed to be very lightweight, distributed and fault-tolerant. These attributes make it very well suited for managing containerized Docker applications. CFEngine is an extremely versatile technology and a good complement to Docker, which is very strong at getting code containerized, shipped and deployed. Advancing Process Management in Docker Docker monitors one process in each running container and the container lives or dies with that process. By introducing CFEngine inside Docker containers, we can alleviate a few of the issues that may arise:
William Gibson once said: “The future is here, but it is not evenly distributed”. Within the space of IT-operations and automation we see clear evidence of this. Last week at LISA, System Engineer Mike Svoboda from LinkedIn gave us a glimpse of insight into the future of infrastructure operations.
The lucky audience got to learn how LinkedIn automates IT-operations at one of the largest websites in the world. What LinkedIn has achieved with less than a handful of engineers the last couple of years is truly bleeding edge.
Mahesh Kumar, VP Marketing CFEngine
mahesh.kumar@cfengine.com
This month (literally tomorrow) at Velocity 2013 London Khushil Dep of the MailOnline will address the conference and present how his firm leverages CFEngine for their infrastructure management needs. As Khushil puts it “At the MailOnline we use CFEngine as the core of our configuration management. A way in which we describe our intentions in clear, precise and workable logic patterns which the Machine can understand without ambiguity.”
