The March snapshot release of CFEngine Community and Enterprise has just hit our webservers. The releases are called 3.5 Beta1 and 3.1 Beta1, respectively, and just as last month: this is work in progress.
Community Some low level changes have been introduced. It is now possible to have empty lists in policies, there is no need to use “cf_null” anymore.
We have continued our architectural work and we have changed FatalError for other less problematics error conditions along the code. This allows us to have a better error handling than what we used to have.
CFEngine is very easy to install – just one package per operating system if you are using one of the pre-compiled packages we provide for the Community or for Enterprise editions.
We wanted to bring an equally effortless experience to the task of starting CFEngine; bootstrapping a client to a policy server.
Previously, this has been done by running
/var/cfengine/bin/cf-agent --bootstrap --policy-server <IP> which looks simple enough. However, the problem is that bootstrap and policy server are tightly connected - it does not make much sense to run them independently (bootstrap was actually just a shorthand for -f failsafe.cf).
The February snapshot release of CFEngine Community and Enterprise has just hit our webservers. The releases are called 3.5 Alpha2 and 3.1 Alpha2, respectively, and just as last month: this is work in progress.
Community Those of you who keep track of the commits in our github repository or follow us on twitter will have noticed that the code refactoring has continued this month, and that some good things have happend in the wake of this:
Hi everyone,
Recently we have been thinking about how to make initial steps with setting up CFEngine easier. One way of making CFEngine easier to set up is to remove the need to manually specify the IP address of the policy hub for bootstrapping a client. We decided to use Zeroconf service discovery implemented in Avahi library. This post will explain how this works.
Registering the Policy Server
First step after after setting up a Policy Server is to register it as a remote service using Avahi. All the user have to do is simply to execute cf-serverd with -A/–generate-avahi-config option. This will generate config file cfengine-hub.service in /etc/avahi/services and restart avahi-daemon to make the service visible in the network.
Hello everybody!
For those of you following our development, you might have noticed that after our code split there is a new friend in town: libutils.
The aim of libutils is to be a toolbox of commonly used data structures, algorithms and other handy stuff. Historically we had several implementations of some data structures all over our code, so we decided it was time to start putting all together and make sure we always used the same structures.
Over the past week in CFEngine core dev, some results of refactoring work have come to fruition. We want to make cf-promises a flexible tool for analyzing policy code. Previously, cf-promises required a runnable policy, i.e. a policy that includes a body common control. This made it impractical to use for other policy files than the main file (typically promises.cf), as well as for policy still in development. We want to make it easier for people to use cf-promises while they are developing policy, and to enable the community to integrate with the tool.
Upgrading from CFEngine 2 to CFEngine 3 is easier than you think!
In this Webinar, we will go through the steps required to successfully upgrade your CFEngine 2 environment to CFEngine 3. Topics covered in this Webinar will include:
Promise Theory and Convergence - How they are utilized in CFEngine 3 New features of the CFEngine 3 Language Migration strategies Policy translation - From Files to Bundles and beyond Validation, Testing and Rollout methods Q&A Session So, if you are currently running CFEngine 2 in your environment and are considering a move to CFEngine 3, please view this Webinar. (Recorded on Wednesday, February 13, 2013)
At CFEngine we frequently meet companies that save millions of dollars annually as result of working with our tools.
In addition to improved productivity and increased quality of service, automation will make your IT-operations more cost effective. Actually, in order to stay competitive, I would argue that highly automated IT-operations is the only way for IT-organizations to meet the agility and cost requirements of today.
Automate or die
IT-operations that are not highly automated will not be able to keep up with expected productivity, quality of service and costs.
We’re just back from FOSDEM, the Free and Open source Software Developer’s Europe Meeting in Brussels. For the second year in a row there was a DevRoom for Configuration Systems Management, with room for about 80 people, and long queues outside the door during every talk. Five of us (Alexandra, Geir, Mark, Sigurd and I) went down to the continent to listen to inspiring talks, meet with the infrastructure engineering community and enjoy strong, Belgian beer. Big shout-out to the organizers of FOSDEM in general and the DevRoom in particular, and to the folks at Puppet Labs and Opscode for co-sponsoring the Saturday evening dinner together with us!
Today we released our first monthly release! The January edition of CFEngine Enterprise and Community is now available to those who want to see what we are currently working on. The releases are called 3.1 alpha1 and 3.5 alpha1, respectively - and as the name suggests, this is work in progress. We have built packages for Enterprise and tested a small set of platforms: CentOS 5/6, RHEL 5/6, Ubuntu 10.04. Customers find the packages in a subdirectory “alpha_releases(unstable)” in their download area on cfengine.com.
