Cfengine, cet outil qui facilite la vie des ASR…

Une grande partie de l’activité d’un Administrateur Système consiste à suivre, à bichonner, à soigner et à updater ses serveurs.

Certains ont choisi de le faire manuellement, comme sur une bonne vieille architecture constituée d’une poignée de serveurs.

Sachez qu’il existe plusieurs moyens de s’en dispenser, pas totalement, mais suffisamment pour pouvoir se dégager du temps libre et donc attaquer des activités à plus forte plus-value et plus intéressantes.

Cfengine est un puissant outil qui permet de s’affranchir des contraintes machinales dues à un parc de serveurs dépassant en nombre notre enjouement à passer tout bien tout comme il faut manuellement et unitairement. Le but du jeu étant de centraliser et d’organiser les traitements selon des classes d’objet.

Cfengine fonctionne en utilisant TCP/IP (port 5308 tcp/udp) et les outils libres, en mode client / serveur, et dont les principaux acteurs sont :

• Sur le client :
  • cf-agent, process client, qui va analyser et traiter les différentes configurations, on peut l’apparenter à un interpréteur,
  • cf-execd, un process scheduler,
  • cf-runagent, un outil qui permet de déclencher manuellement les traitements et de solliciter des hosts précis,
• Sur le serveur :
  • cf-servd, process serveur, qui a la responsabilité du partage des fichiers,
  • cf-key, le process permettant de sécuriser un minimum les flus de données, qui fonctionne à la manière du keygen d’OpenSSH.

La version 3 est implémentée à l’heure où j’écris ces lignes, c’est donc sur elle que je vais baser mon article.

Mais avant cela, pourquoi dois-je choisir entre les versions ? Et bien parce que la dernière version amène un schisme au niveau du langage utilisé par Cfengine. Malgré tout, la Communauté a fait les choses intelligemment en faisant collaborer les binaires de Cfengine 2 et ceux de Cfengine 3.

On peut donc sans soucis utiliser la version 2 de cfservd avec les versions 3 de cf-agent. C’est ce qu’on appelle être run-time compatible.

Pour analyser la version 3, il est donc nécessaire de détailler un peu le fonctionnement sous la version 2, et c’est ce que nous allons faire.

En version 2, ça se passait comment déjà ?

En version 2, l’installation construit l’outil, génère un couple de clés grâce à cfkey, et stocke tout ça dans /var/cfengine/ppkeys. Notez bien au passage que le répertoire important qui contient pratiquement tout ce qui est intéressant est justement situé sous /var/cfengine/.

Notamment concernant /var/cfengine/inputs/, qui contient tous les fichiers de configuration, par défaut et customisés, que vous serez amené à éditer. On y trouve donc :

• cfagent.conf, le fichier de conf de l’agent,
• update.conf, lu avant cfagent.conf et chargé, comme son nom l’indique, de rapatrier les mises à jour de configuration,
• cfservd.conf, notre configuration de serveur. Utile surtout pour encadrer correctement les droits d’accès de certains serveurs sur certains répertoires,
• cfrun.conf, un listing des serveurs à joindre en cas d’utilisation de cfrun.

Ce qu’il est important de savoir, c’est que vous n’êtes pas tenu de bourrer de suite toutes vos règles dans cfagent.conf, mais vous pouvez, à volonté, utiliser autant de fichier de configuration que vous le voulez, grouper certaines règles en fonction de vos critères. Au contraire cela ne fera que vous faciliter un peu plus le boulot.

Il est également intéressant de préciser que Cfengine adopte un comportement de non surcharge des ressources. Ainsi, les boucles infernales de commandes sont évitées, et un délai aléatoire est introduit pour éviter que toutes les requêtes ne convergent et viennent s’étrangler sur notre serveur.

Les fichiers de configuration sont donc au cœur de Cfengine et leur skeleton n’est pas crée par défaut à l’installation. Un fichier de configuration typique est structuré tel quel :

section1 :
classe1::
directives11
section2 :
classe1::
directives21
classe2::
directives22

Il peut contenir en lui-même plusieurs sections distinctes.

Les sections.

Les sections constituent le moteur même de Cfengine. On peut diviser les sections en 2 catégories : celles qui vont moduler le comportement de Cfengine, et celles qui, à proprement parler, vont faire tout le boulot.

Les classes.

Elles servent à cibler les conditions qui déclencheront les actions à entreprendre. La plupart des classes sont prédéfinies mais il est possible d’en créer de nouvelles. Elles peuvent concerner très spécifiquement une configuration donnée, à un temps t, comme l’OS, la date, la distribution, l’architecture (32 bits, 64bits), on parle alors de hard classes, ou être beaucoup plus abstraites, ce sont alors des evaluated classes. La troisième catégorie contient les classes que nous, administrateurs, nous allons définir. Notez également l’existence d’une hard classe any, qui regroupe toute machine, quel qu’elle soit.

Le fonctionnement est simple. Cfagent détecte que c’est l’heure à laquelle il doit déclencher un traitement. Avant toute chose, il va chercher sur notre serveur -le policy host- via update.conf la version à jour, s’il y en a une, de cfagent.conf. En cas d’impossibilité de joindre le serveur, il se basera alors sur celui dont il dispose en local. Les traitements seront alors fait selon ce qui est écrit dans ce cfagent.conf. C’est une stratégie de pull, c’est-à-dire que le client est autonome et c’est lui qui sollicite le serveur. Et, bien sûr, pour plus de fun, tout cela est à votre charge !

Petit exemple de cfservd.conf :

################################################################
#
# cfservd.conf
#
################################################################
control:
   domain = ( k-tux.com )
   AllowConnectionsFrom = ( 192.168.0 )
   TrustKeysFrom = ( 192.168.0 )
   Access = ( root kbux )

# Variables internes, pour faciliter les choses.
   cfrunCommand = ( "/usr/local/sbin/cfagent" )

# Utile pour que 'cfrun' sache ce qu'il a à faire...
grant:
   any::
      /usr/local/sbin   $(policyhost)

   policyhost::
      /var/cfengine/inputs   *.k-tux.com

# Sans cette spécification-là, c'est l'action 'copy' de 'update.conf'
# qui ferait une erreur
# EOF cfservd.conf.

Petit exemple de cfagent.conf.

################################################################
#
# cfagent.conf basique, tout juste fonctionnel.
#
################################################################
control:
   domain  = ( k-tux.com )
   actionsequence = ( shellcommands )

shellcommands:
   "/bin/echo cfagent OK"

# Dans un premier temps, cela suffit !
# En effet, cfagent requiert essentiellement la présence d'une
# 'actionsequence' dans son fichier de conf'.
#
# EOF cfagent.conf.

Petit exemple d’update.conf.

##############################################################
#
# Ceci est le fichier update.conf, simple et fonctionnel,
# servant à tenir à jour tous les fichiers de conf,
# (soit l'intégralité du répertoire /var/cfengine/inputs)
# sur les machines locales.
# En tout état de cause, le garder simple et fonctionnel !
#
##############################################################
control:
   domain = ( k-tux.com )
   actionsequence = ( copy )

# En fait, l'action 'copy' sera utilisé ici pour 'update',
# mais comme cette dernière n'existe pas...
# De toute façon, basiquement, c'est bien une copie de fichiers que l'on demande.
   policyhost = ( policyhost )
   masterdir = ( /var/cfengine/inputs )
   localdir = ( /var/cfengine )

# Bien entendu, 'policyhost' existe dans le fichier /etc/hosts de la machine locale.
# En-dehors de ça, nous venons de déclarer nos propres variables.
# Elles ne tarderons pas à servir...
copy:
   !policyhost::

# Inutile de spécifier une classe, 'any' ou autre,
# car nous voulons que TOUS les hôtes soient à jour de leurs fichiers de conf...
# Tous, sauf le ‘policyhost’, bien sûr
# Précédée du signe '!', toute machine ou classe de machine sera
# exclue de l'action entreprise.
      $(masterdir)   dest=$(localdir)/inputs

# L'action 'copy' est structurée de cette façon.
# L'usage de l'espace autour de la source et de la destination est libre,
# mais pas d'espace à l'intérieur de celles-ci.
# Règle d'or : si la source est un fichier, la destination doit être un fichier.
# Ici, la source est un répertoire, la destination doit en être un aussi.
# Tout ce que contient l'un sera copié dans l'autre.
                     server=$(policyhost)
                     r=inf

# Option obligatoire car copie de répertoire.'r' pour récursif
# (peut également s'écrire 'recurse'). 'inf' pour niveau maximum de récursivité,
                     purge=true

# Sans cette option, 'copy' générerait des fichiers *.cfsaved
# dans le répertoire de destination.
# Ici, nous obtiendrons une réplication exacte et fidèle du répertoire source, sans plus.
                     type=binary

# Le fichier 'dest' sera comparé bit à bit à son homologue source.
                     mode=644

# Là, 'copy' se "contente" de vérifier les permissions d'accès des fichiers
# présents dans $(localdir)/inputs, et de corriger le tir en cas de besoin.
                     trustkey=true

# Le point sensible.
# Ici, nous voulons que $(policyhost) fasse confiance à la machine locale,
# et accepte sa clef publique lors du premier contact entre les deux hôtes.
# Cela nous évitera d'avoir à faire cette échange de clefs manuellement,
# mais bien évidemment nous créons ainsi une petite faille de sécurité...
#
# EOF update.conf.