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.
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.
