Description et principes de fonctionnement

Présentation de l'architecture

La liste des programmes

cfengine s'appuie essentiellement sur 4 programmes : cfkey, cfagent, cfservd et cfrun. D'autres existent (cfgetenv, ...), mais qui n'ont d'intérêt que dans une utilisation avancée et sortent du cadre de cet article.

cfagent est le programme qui va analyser et exécuter les fichiers de configuration. Il se configure avec les fichiers update.conf et cfagent.conf qu'il va chercher, par défaut, dans le répertoire de configuration défini plus bas. On peut lui en spécifier un autre fichier avec l'option -f.

cfagent peut être vu comme un interpréteur au même titre que Perl ;
cfrun est le programme qui va permettre de lancer les cfagent à distance ;
cfservd est un « daemon ». Il fait office de serveur de fichiers intégré à cfengine. Il permet également de lancer cfagent sur une sollicitation réseau ;
cfkey génère un bi-clé utilisé pour sécuriser la connexion entre cfagent/cfrun et cfservd ;

Les répertoires de cfengine

Depuis la version 2 de cfengine sortie autour de 2002, tous les fichiers importants sont réunis dans /var/cfengine. Si votre distribution les met ailleurs (/var/lib/cfengine2 pour debian par exemple), je ne saurais trop vous conseiller de faire un lien vers ce répertoire afin d'harmoniser toutes vos configurations. Nous verrons plus loin dans cet article un script pour le faire sur les clients mais pour le serveur faites-le dès maintenant.

Dans le cadre de cet article nous ne verrons que trois répertoires :

/var/cfengine/bin contient les fichiers exécutables
/var/cfengine/inputs contient les fichiers de configuration
/var/cfengine/ppkeys contient les bi-clés utilisés pour sécuriser les communications client/serveur

Si vous utilisez cfengine sous un autre compte que root, le répertoire de base sera ~/.cfagent dans lequel vous retrouverez les répertoires ci-dessus.

Les fichiers de configuration

Les fichiers de configuration se trouvent donc normalement dans /var/cfengine/inputs. Voici les principaux :

cfagent.conf est le fichier de configuration de... cfagent ;
update.conf est également utilisé par cfagent. C'est un fichier minimum permettant d'amorcer le démarrage de cfagent (récupération d'une configuration récente et exempte de bug par exemple). Il est lancé avant cfagent.conf ;
cfservd.conf est le fichier de configuration de cfserv. On va y indiquer par exemple quels sont les serveurs ayant le droit de se connecter et quels répertoires ils pourront récupérer ;
cfrun.conf permet de définir la liste des serveurs à contacter quand on utilise cfrun.

Un fichier de configuration très simple

Dans la suite de cet article vous essayerez de nombreux fichiers de configuration, cfengine est conçu de façon à ne pas lancer en boucle les commandes afin de ne pas saturer le système. En phase de test, vous pouvez utilisez l'option -K de cfagent qui désactive cette sécurité. Toujours pour éviter de surcharger le système, cfengine permet d'introduire un délai aléatoire avant le lancement réel, de cette façon, même si tous vos serveurs lancent cfengine à heure fixe toutes les heures, ils ne se connecteront pas tous au serveur centrale au même instant. Pour désactiver ce délai vous devrez utiliser utiliser l'option -q.

Attention à bien respecter les espacements (présents ou absents) autour des caractères ':()' ;-)

  # cat /var/cfengine/inputs/cfagent.conf 
  control:
     actionsequence = ( shellcommands tidy )

  shellcommands:
     "/usr/bin/id"

  tidy:
     /tmp pattern=*~ recurse=inf age=2

Ce fichier de configuration est composé de trois sections : control, shellcommands et tidy. La première permet de configurer le comportement de cfagent et en l'occurrence de fixer l'ordre d'exécution des actions : shellcommands puis tidy. La deuxième section indique qu'il faut lancer la shellcommands (commande externe à cfengine, à la manière de "system" en Perl) /usr/bin/id. La troisième section, qu'il faut lancer l'action tidy (suppression) sur le répertoire /tmp sur les fichiers dont le nom se termine par '~' (pattern=*~), vieux de plus de deux jours (age=2), et en analysant également les sous-répertoires (recurse=inf) Pour exécuter ce fichier, il suffit de faire :

  # cfagent -q -K 
  cfengine::usr/bin/id: uid=0(root) gid=0(root) groups=0(root)

Comme on le voit, cfagent exécute la commande id. Si d'aventure vous aviez des fichiers correspondant au motif recherché dans le répertoire /tmp, ils auront été supprimés.

Ce simple fichier montre déjà une partie de la puissance de cfengine : en très peu de lignes, nous avons pu exprimer des tâches de très haut niveau.

La notion de classes

cfengine est utilisé pour gérer des parcs informatiques de plusieurs dizaines à plusieurs centaines de serveurs hétérogènes. Si chaque serveur devait avoir son fichier de configuration spécifique, le système deviendrait vite inmaintenable.

Pour résoudre ce problème et permettre l'utilisation d'un fichier de configuration pour plusieurs systèmes, cfengine implante la notion de classes. Celles-ci permettent d'exécuter certaines parties des scripts sous certaines conditions définies par l'environnement ou par l'utilisateur, à la manière du 'if' des langages de programmation :

  si (la classe CCCC est définie) alors ...
  si (la classe DDD est définie et la classe EEE ne l'est pas) alors ...

Quelques classes dites « dures » (car dépendantes du système) sont le type de système (AIX, Debian, Red Hat, etc.), l'architecture (i386, i686, ppc, etc.) tandis que d'autres le sont moins comme par exemple la classe horaire (Hr13 pour indiquer que nous sommes dans la 13ème heure), l'année (Yr2007), l'adresse IP d'une interface, etc.

Il existe enfin une classe générique any qui, comme son nom l'indique, est tout le temps vraie. Elle est utilisée implicitement si vous ne spécifiez pas de classe et vous pouvez bien sur l'utiliser explicitement.

On peut voir toutes les classes prédefinies en lançant la commande :

  # cfagent -v -p

Sur mon serveur cela donne :

  Defined Classes = ( 10_74_0 10_74_0_1 172_16_235 172_16_235_1
  192_168_0 192_168_0_2 192_168_111 192_168_111_1 32_bit Day1 Hr15
  Hr15_Q4 May Min55_00 Min58 Q4 Tuesday Ubuntu_7_04__n__l_ VMware Yr2007
  addr_ any cfengine_2 cfengine_2_1 cfengine_2_1_20
  compiled_on_linux_gnu debian debian_4 debian_4_0
  fe80__202_e3ff_fe04_44f8 fe80__211_2fff_fe0d_b6f9
  fe80__250_56ff_fec0_1 fe80__250_56ff_fec0_8 gaspard gaspard_local
  [...]
  net_iface_vmnet8 undefined_domain )

Ces classes s'utilisent en ajoutant le nom de la classe désirée, immédiatement suivi de :: (attention à ne pas mettre d'espaces) juste avant l'action à réaliser ou à ne pas réaliser :

  control:

    actionsequence = ( shellcommands )

  shellcommands:

    linux:: 
      "/usr/local/bin/backup"

Cette séquence permet de lancer backup uniquement sur les serveurs où la classe linux est définie. Si, comme cela devrait être le cas, cfagent est lancé régulièrement (par exemple toutes les heures), backup sera lancé à chaque fois, ce qui n'est pas forcément l'effet désiré. Heureusement, il est possible de combiner les classes grâce aux opérateurs « et » (.) et « ou » (| ou || pour ceux qui sont habitués à cette syntaxe dans leur langage de programmation). Le « et » est prioritaire sur le « ou » mais les parenthèses () peuvent être utilisées pour changer les priorités. La négation d'une classe est faite avec « ! » qui a la plus forte précédence. Enfin, une portion "conditionnelle" se termine avec la prochaine condition, ou la fin de la section cfengine dans laquelle elle apparaît. En voici une illustration :

  control:

    actionsequence = ( shellcommands )

  shellcommands:

    redhat.Hr01:: 
      "/usr/local/bin/backup"

    linux.!redhat.Hr23:: 
      "/usr/local/bin/backup"

    (aix|sun).Hr02::
      "/usr/local/bin/backup"

lancera :

/usr/local/bin/backup sur toutes les Red Hat (classe redhat) pendant la première heure de la journée (donc entre minuit et 0h59).
/usr/local/bin/backup sur tous les Linux non Red Hat entre 23h et 23h59.
/usr/local/bin/backup sur les AIX et les Sun entre 1h et 1h59.

Notez bien que cfagent réalisera l'action à chaque fois qu'il sera lancé dans le bon créneau horaire...

On peut également ajouter des classes utilisateurs :

  control:
    actionsequence = ( files )
  
  classes:
    oracle = ( FileExists(/etc/oratab) )
  
  alerts:
    oracle::
      "oracle est defini"

  # cfagent 
  cfengine:: oracle est defini

Comme vous l'avez sans doute déjà compris, la classe oracle sera définie si et seulement si le fichier /etc/oratab existe.

Un certain nombre de commandes du type IsDir, IsLink, IsPlain et d'autres étendent ces possibilités. Vous pouvez les trouver dans la documentation de cfengine[5]

Syntaxe des fichiers de configuration

Comme vu précédemment, la syntaxe générale des fichiers de configuration est donc :

  section:

    classe::
      directive

Les sections peuvent être découpées en petit bout et s'entrelacer entre elles :

  section1:

    classe1::
      directive

  section2:

    classe2::
      directive

  section1:

    classe2::
      directive

Néanmoins, même si cela peut s'avérer plus lisible, l'intégralité de chaque section sera exécutée en une seul fois au moment défini dans actionsequence et non en respectant l'entrelacement.

Listes des sections utilisables

Les sections sont tout ce que cfengine sait faire. Elles se regroupent en deux sortes, les sections implicites qui permettent de contrôler et modifier le fonctionnement de cfengine (en créant des classes par exemple) et les sections explicites qui exécutent effectivement quelque chose et modifient l'état du système. Les sections explicites doivent être déclarées dans une directive actionsequence pour être exécutées. L'ordre d'exécution sera celui de cette même directive.

Les sections implicites

alerts permet de remonter des messages quand une classe est active.
classes permet de définir des classes de serveurs (groups est un synonyme mais n'utilisez qu'un seul des deux).
control, comme son nom l'indique, contrôle le comportement de cfengine. Cette action sert à fixer les valeurs par défaut ainsi que des variables.
filters permet de définir des filtres utilisables dans la copie, l'édition de fichiers, la recherche de processus...
ignore permet d'ignorer des répertoires dans les commandes qui normalement les traverseraient (par exemple tidy, file et copy que nous verrons ci-dessous).
import importe le contenu des fichiers de configuration dans le fichier courant. Attention : ce n'est pas « include » comme dans les langages dont vous avez l'habitude, ou alors voyez-le comme un include réalisé après la dernière ligne du fichier où vous l'avez programmé. Ces imports sont réalisés dans l'ordre.

Un conséquence direct de ce que nous venons de dire est que si quelque chose est défini dans un des fichiers importés, elle n'est pas disponible dans le fichier qui importe (c'est vrai entre autre pour les classes que nous avons vu précédemment) mais sera disponible dans les fichiers importés après.

Les sections explicites

Comme déjà évoqué, ce sont ces actions qui agissent effectivement sur le système. L'ordre d'exécution est défini par la directive actionsequence.

copy copie des fichiers entre systèmes de fichiers locaux ou à travers le réseau en utilisant cfservd.
disable désactive des fichiers en les déplaçant (renommage).
disks vérifie qu'un système de fichiers existe et contient assez d'espace disponible.
directories crée des répertoires.
editfiles modifie des fichiers.
files crée, vérifie l'existence, change les droits de fichiers.
links crée des liens.
packages vérifie qu'un paquetage est installé.
processes gère les processus.
shellcommands exécute des commandes externes, scripts, etc.
tidy supprime des fichiers respectant certaines conditions (motifs dans le nom du fichier, âge, etc.)

Cette liste n'est pas exhaustive. Vous trouverez également dans la documentation[4] des commandes comme homeservers, binservers, miscmounts, resolve et quelques autres. Je vous déconseille de les utiliser, au moins dans un premier temps. Tout peut être fait sans ces commandes.

Configuration du réseau

Dans cette partie, il nous faudra au moins deux machines, l'une faisant office de serveur et la seconde de client. Nous avons également besoin d'un nom de domaine, même fictif (mon.tld fera l'affaire), et d'une plage d'adresses IP privées (172.16.235.0/24 dans le cas présent). Le serveur s'appelle maitre.mon.tld et a pour adresse 172.16.235.1 et le client 172.16.235.128 (les hasards du DHCP).

Comme nous l'avons vu précédemment, cfservd est la partie serveur de cfengine. Deux programmes peuvent communiquer avec ce dernier : cfagent pour échanger des fichiers et cfrun pour lancer un cfagent sur un ou des serveurs distants.

Afin de sécuriser les échanges, cfengine v2 utilise un bi-clé. En fait, comme pour SSH, ce bi-clé ne sert qu'à vérifier l'identité du correspondant et à échanger une clé de session, le reste de la communication étant chiffrée avec cette clé de session par l'algorithme de chiffrement symétrique Blowfish. Le bi-clé est généré par cfkey et stocké par défaut dans le répertoire /var/cfengine/ppkeys, il est composé de deux fichiers localhost.priv et localhost.pub. Toute la difficulté réside dans sa diffusion sur l'ensemble des serveurs concernés qui peut être manuelle ou automatisée par cfengine.

Pour la diffusion manuelle, il suffit de copier le fichier localhost.pub du serveur maître dans le répertoire /var/cfengine/ppkeys de chaque serveur client sous le nom root-IP.pub, soit dans notre cas root-172.16.235.1.pub et de copier les fichiers localhost.pub de chaque serveur client dans le répertoire /var/cfengine/ppkeys sous le nom root-IP.pub soit dans notre cas root-172.16.235.128.pub.

Cette première méthode est simple à mettre en œuvre mais pose certains problèmes quand il s'agit de répliquer les clés sur un grand nombre de serveurs. cfengine permet de désactiver le mécanisme de vérification du bi-clé, soit un bref moment, le temps d'échanger ce fameux bi-clé, soit définitivement, ce qui n'est pas recommandé sauf si vous êtes dans un environnement sûr.

Configuration de `cfservd`

La syntaxe de cfservd.conf se rapproche de celle de cfagent.conf sans toutefois être exactement la même :

  # cat /var/cfengine/inputs/cfservd.conf
  control:

    # le domaine utilisé
    domain = ( mon.tld )

    # les clés des agents de ce domaine sont acceptées
    # cette ligne permet d'autoriser la connexion de nouveaux agents
    TrustKeysFrom = ( 172.16.235.0/24 )

    # seul root est autorisé à se connecter
    AllowUsers = ( root )

    # définit le temps en minutes avant qu'une action puisse à nouveau
    # avoir lieu
    IfElapsed = ( 5 )

    # le temps en minutes alloué à une action avant qu'elle ne soit considérée
    # comme bloquée par cfengine. Au-delà de ce temps cfengine est tué
    ExpireAfter = ( 15 )

    # le nombre maximum de connexions autorisées sur le serveur
    MaxConnections = ( 10 )

    # un client a-t-il le droit de se connecter plusieurs fois simultanément
    MultipleConnections = ( true )

  grant:

    /var/cfengine/inputs/     172.16.235.0/24

    # attention, si /var/cfengine/inputs est un lien, il faut
    # autoriser le répertoire sur lequel il pointe. Sur
    # debian/ubuntu, il faudra donc quelque chose de la forme :
    /etc/cfengine/           172.16.235.0/24

    # et sur mandriva quelque chose comme ça :
    /var/lib/cfengine/inputs 172.16.235.0/24

La commande TrustKeysFrom permet à l'agent encore inconnu du serveur de s'authentifier. Le serveur récupère la clé publique de cet agent et la stocke dans le répertoire défini ci-dessus. Attention, si l'agent a changé de clé, le serveur ne l'acceptera pas, il faudra alors manuellement supprimer l'ancienne clé de cet agent sur le serveur.

L'action grant liste les répertoires auxquels les serveurs ont le droit d'accéder. Dans le cas présent, tous les serveurs du sous-réseau 172.16.235.0/24 ont le droit d'accéder à /var/cfengine/inputs pour récupérer leur configuration. Il est normalement préférable d'utiliser un nom de domaine dans la section grant :

  grant:
    /var/cfengine/inputs/   *.mon.tld

Mais pour simplifier un peu nous allons utiliser les sous-réseau.

Ca y est, vous pouvez lancer le daemon cfservd en lançant tout simplement cfservd sous root.

Configuration de l'agent

Nous allons bien sûr nous servir de cfengine pour diffuser ses propres fichiers de configuration. Comme nous l'avons vu au début de cet article, cfagent va lire dans l'ordre les fichiers update.conf puis cfagent.conf. Le premier fichier sert à initialiser cfengine (récupération des fichiers de configuration récents) et doit rester le plus simple et robuste possible. En voici un qui devrait convenir pour commencer. Placez-le sur le serveur toujours au même endroit :

  # cat /var/cfengine/inputs/update.conf
  control:
    actionsequence = ( copy )
    domain = ( mon.tld )
    policyhost = ( 172.16.235.1 )

  copy:

    # attention, les "/" finaux sont importants si vous avez des liens
    /var/cfengine/inputs/ dest=/var/cfengine/inputs/
        r=inf
        exclude=*~
        server=$(policyhost)
        trustkey=true

Le paramètre trustkey autorise l'agent à accepter la clé d'un serveur s'il ne le connaît pas encore. Comme pour la commande TrustKeyFrom, elle ne permet pas d'écraser une clé déjà existante : il faut d'abord la supprimer à la main

L'action copy décrit que le client doit copier récursivement le répertoire /etc/cfengine sur le serveur déclaré dans la variable policyhost en excluant les fichiers respectant le motif *~ (qui sont des fichiers utilisés par un certain nombre d'éditeurs pour conserver les dernières modifications).

Pourquoi passer par une variable policyhost et ne pas mettre directement :

        server=maitre.mon.tld

Parce que cacher au milieu d'un programme une donnée aussi importante est rarement une bonne idée que cela soit dans des scripts cfengine ou dans tout autre langage de programmation. Pensez aux personnes qui devront assurer la maintenance de votre cfengine.

Une fois ce fichier mis en place, modifiez-le le moins possible et vérifiez scrupuleusement ces modifications sous peine de devoir « pousser » à la main une configuration saine sur chacun de vos serveurs (ce qui peut être long et douloureux).

Comment initialiser la procédure

Maintenant que le serveur est complétement configuré, nous arrivons à un classique problème d'oeuf et de poule, nous avons besoin du update.conf pour récupérer la configuration qui contient le fichier update.conf. Il faudra donc pour la première fois le copier à la main sur le client dans le répertoire /var/cfengine/inputs/ et lancer cfagent :

  # cfagent -K -q -v

Et miracle de l'informatique :

  [...]
  Checking copy from 172.16.235.1:/var/cfengine/inputs/ to /var/cfengine/inputs
  Connect to 172.16.235.1 = 172.16.235.1 on port 5308
  Updating last-seen time for 172.16.235.1
  Loaded /var/lib/cfengine2/ppkeys/root-172.16.235.1.pub

  ...............................................................
  cfengine:cfclient: Strong authentication of server=172.16.235.1 connection confirmed
  cfengine:cfclient: INFO: /var/cfengine/inputs is a symbolic link, not a true directory!
  cfengine:cfclient: /var/cfengine/inputs/cfagent.conf wasn't at destination (copying)
  cfengine:cfclient: Copying from 172.16.235.1:/var/cfengine/inputs/cfagent.conf
  cfengine:cfclient: Object /var/cfengine/inputs/cfagent.conf had permission 600, changed it to 640
  cfengine:cfclient: Update of image /var/cfengine/inputs/update.conf from master /var/cfengine/inputs/update.conf on 172.16.235.1
  [...]

Vous avez diffusé votre première configuration cfengine.

Comme l'indique le début de la sortie de cfagent, le client et le serveur ont échangé leur clé publique. Si vous êtes sur un réseau pas ou peu sur vous pouvez maintenant commenter, sur le serveur, les lignes TrustKeysFrom dans cfservd.conf et trustkey dans update.conf sur le serveur. La prise en compte par cfservd est immédiate. Le client sera mis à jour à la prochaine synchronisation. Quand vous voudrez ajouter un nouveau client, vous devrez décommenter ces lignes le temps de la première synchronisation.

Une fois cela fait, il ne vous restera plus qu'à ajouter une tâche dans /etc/crontab pour lancer cfagent périodiquement. Dans un premier temps, vous pouvez le lancer en mode verbeux pour étudier ce qu'il fait :

  # cat /etc/crontab
  11 * * * *   root    /var/cfengine/bin/cfagent -v >> /tmp/cfagent.log 2>&1

Nous n'en parlerons pas plus avant mais Cfengine inclus un programme spécial cfexecd qui encapsule cfagent et permet d'envoyer un mail avec la sortie de cfagent. Vous pouvez l'utiliser à la place de cfagent dans votre crontab.

cfengine - un outil pour l'administrateur système

Introduction

Cfengine - un outil pour l'administrateur système

Installation de Cfengine

Les systèmes de packages

Compilation

Description et principes de fonctionnement

Présentation de l'architecture

La liste des programmes

Les répertoires de cfengine

Les fichiers de configuration

Un fichier de configuration très simple

La notion de classes

Syntaxe des fichiers de configuration

Listes des sections utilisables

Les sections implicites

Les sections explicites

Configuration du réseau

Configuration de `cfservd`

Configuration de l'agent

Comment initialiser la procédure

Quelques exemples d'utilisation

achever l'installation de Cfengine

Un script s'occupant des tâches ménagères

Un exemple d'utilisation de la directive `editfiles`

Un script s'occupant de sécuriser un minimum les serveurs en DMZ

Un script s'occupant de déployer Apache 2

Diffusion de modules Perl multi-architecture.

Un peu de méthodologie

Conclusion

Liens et livres

Ours

cfengine - un outil pour l'administrateur système

Introduction

Cfengine - un outil pour l'administrateur système

Installation de Cfengine

Les systèmes de packages

Compilation

Description et principes de fonctionnement

Présentation de l'architecture

La liste des programmes

Les répertoires de cfengine

Les fichiers de configuration

Un fichier de configuration très simple

La notion de classes

Syntaxe des fichiers de configuration

Listes des sections utilisables

Les sections implicites

Les sections explicites

Configuration du réseau

Configuration de cfservd

Configuration de l'agent

Comment initialiser la procédure

Quelques exemples d'utilisation

achever l'installation de Cfengine

Un script s'occupant des tâches ménagères

Un exemple d'utilisation de la directive editfiles

Un script s'occupant de sécuriser un minimum les serveurs en DMZ

Un script s'occupant de déployer Apache 2

Diffusion de modules Perl multi-architecture.

Un peu de méthodologie

Conclusion

Liens et livres

Ours

Configuration de `cfservd`

Un exemple d'utilisation de la directive `editfiles`