During the CFEngine training session in Montreal two weeks ago, Normation and CFEngine organized a community event, to reach CFEngine users in the French speaking Canada. The event was a success, and we even met some potential CFEngineers there, eager to join the community.

Late picture from the event (most beers hidden)

This event was fully sponsored by CFEngine, who we thank extensively for the great beers we enjoyed!

After a hard couple of days trying to get it done with our friends from Genymobile, we finally managed to craft a lovely Android compatible Rudder prototype !

Thanks to CFEngine flexibility, we are now able to manage Android-based systems from a standard Rudder server.

Thus, we are currently the only user-friendly oriented configuration management tool able to manage Android-based appliances, and we are looking forward to extend this basic support to a full-fledged one using Rudder’s Technique library.

Stay tuned !

P.S.: “Android 2.4 Ice Cream Sandwich” means “Android ICS running on a Rudder 2.4 agent”, Android 2.4 does obviously not exist.

Yesterday, we held a seminar in our offices titled IT infrastructure: Balancing best practices and everyday constraints. Mark Burgess, pioneer of software configuration management and founding CTO of CFEngine AS, was our guest star, and gave a very interesting talk about the Third Wave of IT Management.

We took the opportunity to introduce Normation, presenting our mission, our strategic partnership with CFEngine AS, and the aims of Rudder. For those who weren’t there, we thought we’d share an extract of this presentation:

It was a great event, with many interesting questions and discussions, and we’d like to thank everyone who attended, and of course Mark for coming all the way to Paris for this, and his warm comments about Normation.

If you’re curious about Normation or Rudder, we’d love to hear from you – contact us by email, Twitter (@Normation and @RudderProject) or IRC (#rudder on FreeNode)!

Cette semaine, de mercredi à mercredi (du 22 au 29 février donc), Normation va faire son premier Barcamp Rudder !

Mais qu’est-ce qu’un barcamp ? D’après Wikipedia :

Un BarCamp est une rencontre, une non-conférence ouverte qui prend la forme d’ateliers-événements participatifs où le contenu est fourni par les participants qui doivent tous, à un titre ou à un autre, apporter quelque chose au Barcamp. C’est le principe pas de spectateur, tous participants.

(Source et plus d’infos : http://fr.wikipedia.org/wiki/BarCamp)

L’objectif de cette semaine c’est d’améliorer Rudder, de faire qu’il nous plaît à tous, avant la sortie de la version 2.4.0 début mars, et travailler sur les sujets qu’on néglige parfois : communication, communauté, documentation, tests, qualité, ergonomie…

On profite de l’occasion pour faire une opération portes ouvertes : vous êtes les bienvenus chez nous tous les jours de 9h jusqu’à tard… Passez-nous faire un petit coucou, tester la dernière version de Rudder, nous donner votre avis, grignoter un morceau… Promis, on ne vous demandera pas vraiment de travailler

L’équipe de Normation au grand complet (9 personnes) vous donne donc rendez-vous tous les jours au 87 rue de Turbigo, 75003 Paris ! C’est au métro Temple sur la ligne 3 ou République sur les lignes 5, 8, 9 ou 11.

En particulier, un évènement communautaire autour de Rudder / CFEngine aura lieu jeudi soir pour se rencontrer et discuter (ou troller) autour d’un verre (ou deux).

Ca nous ferait très plaisir de vous voir ici alors n’hésitez pas à passer ! Si vous ne pouvez pas venir, rejoignez-nous sur IRC (#rudder sur FreeNode) ou suivez-nous sur Twitter (@normation et @RudderProject).

Here at Normation, we use CFEngine 3 extensively for configuration management across Linux and Windows servers.

CFEngine 3 is a very secure tool, that relies on keys to identify hosts and authorize connections. To set up a secure CFEngine infrastructure, you ought to exchange keys between hosts (note that if you don’t have confidential data on your promises, you can skip the security offered by the public key system).

Key exchange

The client-server communication is based on keys (very much like ssl). Each node must have a copy of the other public keys, obtained either via a remote copy (with scp), by trusting keys automatically, or using the bootstrap system introduced in Cfengine 3.2.0 (that would still require the server to accept automatically keys).

If you don’t want to accept keys based on automatic trust, you need to manually exchange them to set up the system. This article will show you how to do this using the cf-runagent tool, by connecting to each host from the main CFEngine server.

Assume a server with the following ip : 192.168.56.150
Assume a client with the following ip : 192.168.56.152

Client side

The initial promises on the client will need to configure the cf-serverd to run on it, and try to fetch its real promises from the policy server :

Note that the client trusts keys from the server

Server side

On the server, you’d have the following promise for the server component, authorizing hosts to connect, but not trusting their keys

Note: only the server itself is accepted on trust, hosts from the subnetwork 192.168.56.* can connect but their keys are not automatically trusted, and their DNS name is not deemed as reliable.

First execution (without prior key exchange)

If the agent on the client tries to connect to the server, without previous key exchange, you’ll have the following output on the server :

To relieve the burden of copying keys with scp, or the risk of trusking keys of every hosts, you can do a manual key exchange, from the server, using the cf-runagent interactive mode

Interactive key exchange

The interactive key exchange will happen from the server to the client. It will ask for the user to trust the key, and execute the remote promises of the client (in this case, the initial promises fetch the real promises from the server)

Here we accepted the key of 192.168.56.152 on the server, and the client could connect to download its new promises, and then apply them

Note: To prevent any risks, the new promises should not have 192.168.56.150 in the trustkeyfrom

Note 2: Since the version 3.2.0, if you are willing to automatically accept keys from the clients on the servers, you don’t need to copy any promises on the client, the bootstrap procedure from the Nova edition has been backported in the community edition; and it uses its own embedded promises