We’re happy to announce that CFEngine 3.8.0 non-LTS now is released! A big thanks to everyone testing the 3.8.0 beta release! During the month it has been available, the 3.8.0 beta has seen hundreds of downloads widely distributed across platforms, both in Community and Enterprise editions. This testing helps ensure high quality of the final release. Of course, bugfixes in recently released 3.7.2 are also incorporated into 3.8.0. Please note that this is a non-LTS release, which means that it is maintained for 6 months from the release date and not supported for CFEngine Enterprise customers (but packages are available for testing). The established CFEngine release schedule gives an overview over the release timelines for all releases.
We’re happy to announce that CFEngine 3.7.2 is released! With 3.7 being a stable LTS branch, 3.7.2 brings numerous stability enhancements and bugfixes to the CFEngine customers and community. The main focus area for 3.7.2 is to improve fault-tolerance and performance of policy distribution in unreliable networks.
Enhanced reliability of policy distribution The ability to distribute policy from the Policy Server to clients is a critical function of CFEngine, which also must work well in unreliable networks. CFEngine already has protection against corruption of the main policy (promises.cf) with the separate update policy (update.cf). In turn, if the update policy fails validation, failsafe.cf is run. In 3.7.2 failsafe.cf is also re-generated if it does not exist (but not overwritten since users may have a custom failsafe.cf in some cases) – basically simulating a fresh bootstrap. So this means that CFEngine will now be able to recover from corruption of any policy and wipe of the entire inputs directory! In addition, we have been chasing an intermittent issue that in some extremely rare cases results in a directory be turned into a file for some time, and we now have evidence that this is completely fixed in 3.7.2! Performance of policy distribution with cf-serverd at scale (4000+ clients) has been significantly improved by reducing lock contention of malloc() as well as lock contention of getpwnam(). Finally, for CFEngine Enterprise installations using call collect (client-initiated reporting), the default collect_window has been increased from 10 to 30 seconds. This ensures call-collect works reliably in scaled environments (thousands of clients) with default configuration. In sum these changes will lead to much more reliable policy distribution – and hopefully provide users with some additional peace of mind!
We’re happy to announce that CFEngine 3.7.1 is now ready! Given that this is the first maintenance release in the 3.7 branch, the focus is primarily on stability and reliability of new features added in 3.7.0. For improved resiliency of Enterprise High Availability in environments that need it, we also added support for an offsite replication node.
Offsite replication support for Enterprise High Availability The High Availability cluster has until now consisted of 2 nodes; an active and passive. If the active goes down, the clients would fail over to the passive. However, some environments require the CFEngine Server to continue to operate even during a complete datacenter failure. In 3.7.1, support for a third HA node has been added: an offisite replication node. This node will replicate data from the active node, and can be manually promoted to an active node in case both the two other nodes goes down. You can read more in the new section of the High Availability installation documentation.
Now that CFEngine 3.7.0 is released, introducing simplified package management, change management, dashboard sharing and enhanced network security, it’s time to look forward. The CFEngine 3.7 and 3.6 releases will mainly include stability and security enhancements as they are now stable branches. A blog-post on the release schedule going forward explains this in more detail. The next feature-release up is 3.8 (non-LTS), due for December 2015, and we’d like to share that performance will be the main release theme for 3.8! Secondly, we also plan to include support for phased rollout in 3.8.
We’re happy to announce that CFEngine 3.6.6 is now ready! The new release has improved performance and reliability, especially on the CFEngine Enterprise backend, as well a stability and performance improvements across Unix and Windows agent platforms! Given that this is the sixth maintenance release in the 3.6 branch, the focus is primarily on stability and performance enhancements.
Enterprise report collection enhancements CFEngine 3.6.6 significantly improves the performance and reliability of the Enterprise reporting backend in several ways. A known issue causing higher CPU usage of PostgreSQL has been resolved. Secondly, the PostgreSQL maintenance settings (known as “vacuuming”) have been optimized to reduce the disk fragmentation and thus supporting policies with frequently changing promises much better. For example, if there are frequent uses of if_elapsed in the policy, this optimization will make a significant difference. In some instances, the Enterprise hub would log errors about “status_pkey” to syslog, due to duplicate reports coming from clients. This has also been resolved in 3.6.6. Finally, environments where client-initiated reporting is enabled (known as “call collect”) will see big scalability enhancements. Call collect has been scale tested to several thousand clients over a long period of time.
We’re happy to announce that CFEngine 3.7.0 is now ready! The 3.7.0 release contains a brand new packages promise, expanded platform support, enhanced network security, improved Enterprise reporting capabilities and much more!
New packages promise A new packages promise has been developed in collaboration the CFEngine community and users. It is designed to be reliable, simple and easy to use. We hope you enjoy the experience! 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 new package modules. Package modules are essentially wrappers for the package managers that implement the CFEngine package module protocol. As an example, you can use the following promise in 3.7 to track the latest package of apache on Red Hat systems: packages: "httpd" policy => "present", version => "latest", package_module => yum; You can read more about the new packages promise type in the packages reference documentation.
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.
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.
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.
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.
