Each year we like to take a moment to recognize outstanding community members for their contributions. Contributions come in the form of code contributions to core, organizing community meet-ups, giving talks about CFEngine at conferences, sharing policy, to helping other users on the mailing list and on IRC. This year the Community Advisory Board was responsible for selecting champions from the nominations, and it is my honor to announce the 2015 CFEngine Champion Hall of Fame inductees. Congratulations, and thanks for all of your efforts!
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.8.0 non-LTS beta is now ready for testing! The established CFEngine release schedule shows that the 3.8.0 final version is due before January 2016, so it’s time to test and fix any remaining issues. 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.
There is a lot of value to be gained from CFEngine’s reporting features, so we’ve put together a slideshow to showcase 15 of the top reports that give you the best information and control over your infrastructure. If you like what you see, please contact us for any assistance in creating these reports yourself.
https://www.slideshare.net/slideshow/embed_code/key/NEiaPxUfGWdsdw
15 most valuable reports with CFEngine from CFEngine
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.
1, 2, 3.7 GO! CFEngine 3.7 was released just over a week ago and one of the neat things with 3.7 is the new augments_file also known as def.json or overrides. What’s so neat about it? It’s going to make your future policy upgrades easier! I will be using the CFEngine Enterprise Vagrant Environment because it’s a really quick and easy way to stand up a test environment. Here is my fresh 3.7.1 environment.
Looks like my instances are ready to go
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.
