Over the last year we have changed the way we test our software from a manual process to a highly automated process. This new system is capable of taking a change from our source code repository and follow it all the way up to where we update our internal staging servers, thus giving us incredibly valuable information while keeping manual intervention to a minimum.
Overview Our test system consist of the following pieces:
If you are a programmer, you probably know and maybe even love the sprintf family of functions, which format output based on a format specification and on some input data. Here’s a description of the formats available in the GNU libc implementation.
I wrote an implementation called format() which will be in the upcoming 3.5.0 release. The format() function offers string and number formatting. To reduce the chance of security compromises, you can’t print pointer offsets or single characters for instance. The available specifiers are:
Last week, we revamped the way CFEngine formats output. You can continue to use the old output format by specifying the option –legacy-output (-l), but this is considered deprecated and may be removed in a future version.
The key features of the new output format is as follows.
Consistent look for all messages, as formatting is taken care of by the logger. Separate formatting for terminal, syslog, and (eventually) file. Attempts to follow conventions for formatting to separate sinks. ISO 8601 timestamps to terminal. Every statement is single line. No banners and decorations within messages. Conventions for how to write messages. Logging levels (e.g. specifying –verbose always implies –inform), aligning with syslog levels. Logging system knows about evaluation state and may format messages conditioned on what the CFEngine is currently trying to do. This is perhaps best illustrated by an example (in this case, written to terminal).
Over the past month we have removed a bit of functionality for CFEngine. These were features that were useful (cf-report) and good ideas (knowledge management), but the implementation was either in an unfinished state or the design had unclear semantics (outputs promise type).
In order to get a smoother transition for existing policy, we have introduced GCC-style warnings for cf-promises, initially to warn users about removed or deprecated syntax. Deprecated syntax warnings signal that the feature will be removed in a future version, but is still functional with the current version. Removed syntax warnings signal that the feature has been removed.
Authored by Brian Bennett of Digital Elf
I’ve been working a lot with CFEngine newbies. CFEngine has been described as flour, eggs, milk and butter. All the ingredients needed to make a cake. Getting the new CFEngine user to recognize, then become excited about the possibilities that CFEngine provides they are now faced with the question of “What next?”
Indeed, anybody can throw some flour, eggs, milk and butter into a bowl, mix and bake it. But will it taste good?
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.
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.
