California, CA (Jul 17, 2015) - CFEngine, Inc., IT Automation pioneer and leader in infrastructure management software, today announced the general availability of its flagship product CFEngine Enterprise and CFEngine Community, version 3.7
Easier application deployment The 3.7.0 release contains a brand new technology for application deployments. According to Marcin Pasinski, a new packages deployment mechanism has been developed in collaboration the CFEngine community and users. It is designed to be more reliable, simple and easy to use. The new technology co-exists and is compatible with the previous version of the packages promise type in CFEngine. This mean it will be fully backward-compatible, so any packages promises that you have from 3.6 or earlier versions should still work with 3.7.
There has been a lot of discussions lately about changing how the CFEngine releases work, and what we want is to have something that is more systematic and predictable. There are many points that need to be considered, for instance:
How often should we release a new feature release?
How often will people actually upgrade? How often would contributors like to see new releases (with their fixes in)? How long should feature releases be supported?
We’re happy to announce that CFEngine 3.7.0 beta is now ready for testing! The 3.7.0 beta contains a brand new packages promise, enhanced network security, improved Enterprise reporting capabilities and much more!
New packages promise A new packages promise has been developed; it reuses the same promise type as the previous packages promise (packages:), but CFEngine will determine which one to use based on the attributes that are used in the promise type. The packages: promise type is fully backward-compatible, so any packages promises that you have from 3.6 or earlier versions should still work with 3.7. Currently supported platforms for the new packages promise include those based on yum/rpm (using package_module => yum) and apt/deb (using package_module => apt_get), but it can easily be extended by adding a new package_module. As an example, you can use the following promise to track the latest package of apache on Red Hat systems: packages: "httpd" policy => "present", version => "latest", package_module => yum; The development ticket for the new package promise contains more details about the promise and how to extend it.
Thanks to Nick Anderson and Aleksey Tsalolikhin for feedback and valuable insight.
Purpose In this document I will show you how autorun and meta tags will simplify your daily work with CFEngine. There will be no more hard coding of bundles in bundlesequence and you may still run bundles in order by name.
Prerequisite This document assumes that you have installed a binary package from CFEngine’s official site cfengine.com. The code in this document is tested with CFEngine community version 3.6.5. All paths are relative to /var/cfengine/inputs unless stated otherwise. For an introduction to CFEngine please see here. All files created in this post shall be put in services/autorun.
As CFEngine continues its evolution and adds to the large number of users with a stake in the future of the project, we have established a Community Advisory Board. The aim of the Community Advisory Board is to advise CFEngine AS and the CFEngine project core committers and team leadership on matters relating to supporting the long-term governance, structure, and roadmap of the CFEngine open source project. The Community Advisory Board is not intended to replace existing mechanisms for community input but instead augment it and provide a consolidated opinion from the broader CFEngine community. Feel free to discuss your hopes, dreams, and concerns with any board member. Any outside party may bring an issue before the CFEngine Community Advisory Board by emailing communityadvisoryboard@cfengine.com. The following candidates were selected based on past contributions:
CFEngine’s trust model is based on the secure exchange of keys. This exchange of keys between client and hub, can either happen manually or automatically. Usually this step is automated as a dead-simple “bootstrap” procedure:
cf-agent --bootstrap $HUB_IP It is presumed that during this first key exchange, the network is trusted, and no attacker will hijack the connection. After “bootstrapping” is complete, the node can be deployed in the open internet, and all connections are considered secure. However there are cases where initial CFEngine deployment is happening over an insecure network, for example the Internet. In such cases we already have a secure channel to the clients, usually ssh, and we use this channel to manually establish trust from the hub to the clients and vice-versa.
If you are working for a Fortune 2,000, and hold P&L, or in other ways are responsible for the compensation levels of your SA team and have doubts answering this question, I will argue your operations are not automated, nor will it be competitive in tomorrow’s IT-operations market. The industry unites around the belief that automation is the only way to stay on top of IT Operations. Automation has become a prerequisite for supporting the business in their growing demands. However, few are willing or capable of adjusting their outdated view when it comes to the competence mix needed and new cost allocations associated with the transition to automation. Most of the times we meet dreamers with Winnie the Pooh attitudes wanting both. Highly automated operations, and cheap labor. Well, the sad truth is you can’t. You cannot end up with a highly automated IT infrastructure run by fewer, very competent engineers and keep paying traditional average SA salaries.
We’re happy to announce that CFEngine 3.6.5 is now ready! The new release has improved support for Red Hat Enterprise Linux 7 and CentOS 7, as well as other distributions using systemd. In addition, performance of the agent in the Enterprise edition has been greatly improved.
Red Hat Enterprise Linux 7 support As CFEngine 3.6.3 introduced experimental support for Red Hat Enterprise Linux 7, the main outstanding issue was proper management of CFEngine processes with systemd. Systemd support is now integrated into the packages and a systemd class is defined on systemd-enabled platforms. Also note that services promises already detects and supports systemd. For 3.6 there are new packages for Red Hat 7, so make sure you pick those for this OS family version (only). These packages will only work properly on Red Hat 7, CentOS 7 and similar, but not on previous versions of the operating systems. The Enterprise hub does not yet support Red Hat 7, but the Enterprise agent and the community edition does. We plan to unify these packages in 3.7, so that there is one package for each OS type. If you’re interested in the details, you can find the CFEngine buildscripts on on GitHub. Also see the Known issues documentation page for platform-specific sections and please report any other issues you find in the issue tracker.
We were pleased to once again be present at this year’s Config Management Camp in Gent, Belgium. Our two representatives, Jimis and Kristian, spent a very informative and rewarding couple of days in the company of many of our community members. The first of our two talks provided some information about our release process at CFEngine. Our recent focus has been on stability and hardening of our 3.6 series. Lately we have adapted to a nice rhythm of time-based maintenance releases and the feedback from our community has been overwhelmingly positive on this point. Our first presentation outlined our reasoning for this choice, as well as a sneak peek of some features we have planned for the next feature release - 3.7.0. You can read the presentation slides below.
Sometimes you need to collect some small amount of data from your hosts and aggregate it to a central location for reporting. For example, you could have a command that returns the status of a hardware check that you run regularly to detect hardware faults. Or you could want a report of all the hosts’ DNS configuration. In either case, you can use the CFEngine Enterprise inventory collection and reporting mechanism. This is based on a variable or class from the CFEngine language, but with a specific meta tag attached to it. For example, to get the System UUID from your hosts you could integrate the following to your policy: vars: "system_uuid" string => execresult("/usr/sbin/dmidecode/dmidecode -s system-uuid", "useshell"), meta => { "inventory", "attribute_name=System UUID" }; After 15 minutes you can see this as a new inventory attribute in the CFEngine Enterprise Mission Portal UI, under Reports -> Inventory: The inventory reporting interface is very easy to use, so anyone can be allowed to generate reports - saving the system administrator from requests to make “special reports”. You can learn more about creating custom inventory in the learn section.
