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.
The CFEngine lab has been brewing on 3.6.4 over Christmas and is finally ready to release it to the world! With 3.6.4 being a patch release, it has a focus on stability and reliability of both the server and agent side. This is also the first release where user input has been incorporated in form of casting a vote for what to be improved - so make your voice heard!
Enterprise hub self-protection A major stability enhancement for report collection in CFEngine Enterprise hubs has been added to 3.6.4. The Enterprise hub collects reports from clients every 5 minutes by default, but in cases where it can not collect a round of reports from a client it will try to get what is missed the next time from that client; after another 5 minutes. This could happen for several reasons, for example that the client is temporarily offline. The amount of data that needs to be collected once the report collection succeeds again is proportional to the amount of time has passed since the last success. However, if the hub as been unsuccessful at collecting reports from a large amount of clients over a longer period of time, this can cause a high load on the hub once it succeeds again; potentially making the hub unstable and unresponsive until the collection is done. CFEngine 3.6.4 addresses this potential stability problem by introducing a maximum threshold on how long history the hub will try to collect from clients that have been offline; through the body hub control attribute client_history_timeout. By default the hub will discard the missed history (known as issuing a “rebase” collection query) from clients if more than 6 hours have passed since last successful collection in order to protect itself. If a client comes back after 6 hours, the load on the hub for discarding these last 6 hours versus collecting them are about the same – thus the 6 hour default. However, you can adjust this threshold if you expect your clients to be offline for longer amounts of time during normal operations. Note that in either case, history that already exists about the client in the hub’s database is not discarded.
Young and fearless, Born Digital Organizations (BDOs) now seriously challenge incumbent businesses, business models and value chains across industries. These digital organizations set new standards when it comes to frequency of new product features, cross channel compatibility, 24/7-365 availability, customer customization, user-interface friendliness and price points. Attributes of Born Digital Products:
Frequent (daily) product updates Work across all channels Always on Aware of its user(s) Friendly user-interface More affordable (often product-as-a-service) Clunky products with infrequent updates that is not fully compatible across various channels or always available for consumption face a dark future in a world of less loyal customers. For many incumbents, it is going to be a painful road to the digital economy.
Configuration Management Camp in Ghent, Belgium is coming up, and CFEngine is of course going there! This year we’ll be sending two of CFEngine’s core developers, Dimitrios Apostolou and myself, Kristian Amlie. Our currently planned talks for the event are:
How to securely deploy CFEngine in the open Internet: manage trust, provide selective access to policies, securely bootstrap new hosts and revoke old ones. CFEngine releases, how do they happen? Learn how bug fixes, optimizations and features are scheduled for releases. Also a sneak peek at upcoming developments for CFEngine 3.7, and some time for discussion. Finding the problem: Learn how to triage bugs in CFEngine. Also learn how to write an acceptance test. There will of course be plenty of other talks as well and a good chance to meet the guys that make CFEngine happen! And of course you’ll be able to catch talks from other Configuration Management providers as well.
It’s sometimes difficult to maintain an overview over what issues matter most to the CFEngine community. Unfortunately our bug tracker, Redmine, has very poor support for letting the developers know what issues are important to the users, and prioritize according to this. So lately we have been looking into using the watcher count as a way to measure interest in issues. For clarity the watcher count is the number of people who have pressed the “Watch” button on a Redmine issue. Redmine doesn’t have built in support for filtering according to watcher count, but we have built our own custom query tool to get this information. So we hereby encourage the community to press “Watch” on all the issues that are important to them! We can of course not guarantee that all issues with many watchers will be resolved, but it certainly increases the odds that the particular issue makes it towards the top of the list. For technical reasons we can’t publish our query, but below is a sneak peek at the current list: The top 25 issues as of right now, according to watcher count. Merry Christmas!
CFEngine 3.6.3 is released! The new version brings broader platform support, UI performance and usability enhancements as well as bugfixes. It has again been about 8 weeks since the last release, and we are planning to further shorten the release intervals going forward to bring you enhancements faster. What you will also notice is that the focus is on stability and performance for 3.6.x releases, in order to make upgrades as safe as possible. Features and larger changes will be provided in the 3.7 branch.
Hearing a user speak is worth more than self-glorification! As we come up to year-end, it is time to start thinking about turkeys (well if you celebrate Thanksgiving like they do out here), and of course Christmas and the festive season it heralds. In this blog post I would like to thank a particular automation tool (no points for guessing which one), but really do so from the vantage point of a user and the progress they made with the tool. “Today I started learning CFEngine 3”. This was the title of an innocuous looking post from Remi on June 13’th 2013. In here he detailed his early experience attending a training session on CFEngine delivered by Diego Zamboni the author of Learning CFEngine 3. What stood out even back then and at first glance was that CFEngine is a pretty darn good monitoring tool. It is capable of fixing issues or reporting to the user.
