GNU/cfengine

Sommaire

• Sources
• A propos de Mark Burgess
• Définition
• Principes Fondamentaux
• Présentation Détaillée
  • Les exécutables
  • Les classes
  • Les fichiers logs
  • Le langage
• Environnement de Tests
  • Préambule
  • Nommage et adressage des machines
  • Systèmes d'exploitation
  • En résumé
• Installation & Configuration
  • Stratégie
  • Pré-requis
  • Installation
  • Configuration
  • Post-Installation
• Les fichiers .conf
  • cfagent.conf
  • update.conf
  • cfservd.conf
  • Résumé
• Simulation de Déploiement
  • Préliminaires
  • Vif du sujet
• Explorations
  • Prélude
  • Fugue
• Epilogue
• Remerciements
• Références - Liens

Sources

• plusieurs articles de l'auteur, Mark Burgess, traitant (ou non !) de son approche de l'administration système en général, et de cfengine en particulier ;
• une étude de cas, passionnante à tous points de vue, réalisée depuis l'Université de Chicago par David Ressman & John Valdes. Un papier dont je ne saurais trop recommander la lecture : un modèle du genre ;
• un seul et unique article en français, dû à Ronan Keryell, de l'Enst-Bretagne. Intéressant, mais trop peu convivial à mon goût... et pour mes compétences :-[]

A propos de Mark Burgess

Définition

Principes Fondamentaux

Présentation Détaillée

• Les exécutables
• Les classes
• Les fichiers logs
• Le langage

Les exécutables

• cfagent
  indispensable. Sa mission consiste en premier lieu à lire un fichier nommé 'update.conf' sur la machine locale. Ce fichier sert essentiellement à mettre à jour le fichier 'cfagent.conf' de la machine locale à partir de celui présent sur la machine désignée comme serveur de stratégie ('policyhost'). Cela fait (ou en l’absence du fichier 'update.conf'), 'cfagent' lira le fichier 'cfagent.conf' local, et les instructions (actions) qu'il contient seront exécutées. Comme pour tout exécutable sous Unix, on fait appel à 'cfagent' en invoquant son nom, éventuellement suivi d'arguments. Exemple :
  
  [localhost] $ cfagent -pv
  
  collectera et renverra un certain nombre de renseignements, dont la liste exhaustive des classes "dures" auxquelles appartient 'localhost'.
  
  
• cfkey
  indispensable. Son rôle consiste à générer une paire de clés publique/privée. S'appuie pour cela sur /dev/random s'il est présent (Linux, BSD), ou bien sur 'cfenvd' décrit plus bas.
  Sa mise en œuvre est semblable au 'keygen' de ssh :

  [localhost] # cfkey
  Making a key for cfengine, please wait, this could take a minute...
  Writing private key to /var/cfengine/ppkeys/localhost.priv
  Writing private key to /var/cfengine/ppkeys/localhost.pub
  [localhost] #
  

• cfservd
  indispensable. Ce démon doit tourner sur chaque hôte afin d'exploiter les (nombreuses) fonctionnalités réseau de cfengine. Se configure à l'aide de 'cfservd.conf', dont la syntaxe est semblable à celle de 'cfagent.conf'. Pour autant, ce sont deux fichiers de conf différents. Dans 'cfservd.conf', nous ne spécifierons pas d'actions à entreprendre, mais nous définirons certaines règles d'authentification, d'encryptage, de vérification d'intégrité, etc.
  Comme il doit tourner en permanence, on le placera avantageusement dans un script de démarrage, style /etc/rc.d/init.d/cfengine (le fichier /etc/rc.local est à éviter, d'une façon générale).
  
  
• cfexecd
  optionnel, pratique, mais trop peu documenté. Aussi nommé 'scheduler' (programmateur). En théorie, un petit démon 'à la cron', chargé de lancer 'cfagent' périodiquement, et localement. Il a également pour tâche de vérifier les permissions d'accès (700) des sous-répertoires clefs de /var/cfengine, corriger les erreurs et faire son petit rapport. Les sorties ainsi générées se logent dans /var/cfengine/outputs, mais, comme nous le verrons plus loin, également dans /var/log/.
  
  > Deux solutions pour qu'il se lance, par exemple, toutes les heures :
  
  • Soit le placer dans /etc/crontab :
    

    01 * * * *      /usr/local/sbin/cfexecd -F
    # L'option -F l'empêchera de "forker" et donc de se "démoniser".
    

  • Soit le mettre lui aussi dans le script que nous avons créé /etc/rc.d/init.d/cfengine. Par défaut, il s'exécutera horairement.
    Pour qu'il se lance, mettons, chaque demi-heure, on attendra de savoir comment faire :-D
  
  > À déplorer l'absence d'un fichier de configuration pour cet exécutable.
  
  > Petite facétie : 'cfexecd' recherche l'exécutable 'cfagent' dans /var/cfengine/ où il ne se trouve pas, bien évidemment.
  Pour y remédier, soit on crée sur chacun des hôtes (cfengine sait très bien faire ça !) un lien symbolique pointant vers le bon emplacement (/usr/local/sbin/cfagent) ; ou bien encore on l'invoquera de la façon suivante :
  
  [localhost] # cfexecd -F -f /usr/local/sbin/cfagent
  
  
• cfrun
  optionnel, mais bien pratique. Ce petit programme sert à exécuter 'cfagent' sur un ou plusieurs hôtes distants, au cas où cet (ces) hôte(s) ne pourrai(en)t pas, ou plus, exécuter eux-même leur 'cfagent' local — ou encore en cas de modification urgente à propager. On spécifie une ou plusieurs classes d'hôtes comme argument. Si aucune classe n'est spécifiée, tous les hôtes présents dans le fichier 'cfrun.hosts' seront contactés. Dans ce fichier sont listés en effet tous les hôtes susceptibles d'être contactés de cette manière.
  
  
• cfenvd
  optionnel, mais discret... Ce démon a pour tâche de collecter des données statistiques sur le comportement de l'hôte ; des renseignements qui pourront être exploités ensuite par 'cfagent'. Pour cela, il lui faut tourner plusieurs semaines sur l'hôte. Son auteur l'appelle un 'détecteur d'anomalies'.
  
  > Dans un premier temps, il remplacera surtout /dev/random pour la génération de nombres aléatoires (utiles à la création de la paire de clés publique/privée) sur les systèmes qui en sont dépourvus.
  
  > À placer, lui aussi, dans notre script de démarrage /etc/rc.d/init.d/cfengine, où il sera en bonne compagnie.
  
  
• cfenvgraph
  très optionnel. Tellement optionnel à vrai dire que je ne le mentionne ici qu'à titre purement indicatif.
  Pour plus de détails :-) la page qui lui est consacrée

Les classes

• son architecture matérielle (linux_i686, 32bits) ;
• son système d'exploitation (redhat_linux) ;
• la version du noyau de l'OS (2_4_18_3) ;
• son adresse IP (192.168.0.12) ;
• le nom du domaine auquel il appartient (labri.fr) ;
• son nom DNS, non qualifié (stage2) ;
• le même, pleinement qualifié (stage2.labri.fr) ;
• une classe 'any', à laquelle toute machine appartient ;
• les minutes et heures du jour (Min15, Hr09...), le jour de la semaine (Thursday), le jour du mois (Day25), le mois (July), l'année (Yr2002), etc.

classes:

    shadowers = ( FileExists(/etc/shadow) )

• Soit en la soumettant à un script ou une commande shell ; exemple (pour le même résultat que précédemment) :

  groups:
  
      shadowers = ( "/bin/test -f /etc/shadow" )
  

• Soit en nous appuyant sur des classes prédéfinies, exemple :

  groups:
  
      mongroupamoi = ( stage2 stage3 stage4 stage5 stage6 )
  

groups:

    mongrouparfait = ( +mongroupamoi -stage5 )

Les fichiers logs

[stage2] $ ls /var/cfengine | grep log
cfagent..log
cfengine.localhost.runlog
cfengine.stage2.labri.fr.runlog
cfengine.stage2.runlog

Le langage

section:

   classes::

      variable = ( valeur ou liste de valeurs )

###################################################################
#
# 'cfagent.conf' basique, tout juste fonctionnel,
# que nous retrouverons d'ailleurs pratiquement à l'identique
# au chapitre "INSTALLATION & CONFIGURATION".
#
###################################################################

control:
# Pas d'espace avant les deux-points, sinon ça ne marche pas.
# Nous venons de définir une section. Les sections sont prédéfinies,
# il n'est pas possible d'en créer de nouvelles.
# La section 'control' est la plus importante de toutes. Sans elle,
# aucune action ne pourra être entreprise.

   domain = ( labri.fr )
   actionsequence = ( shellcommands )
# Variables internes (builtin).
# Ici les espaces sont chaudement recommandés.
# Avant d'entreprendre une action, il faut prévenir !
# Autrement dit, si pas d''actionsequence' (ou si aucune
# action n'est spécifiée), il ne se passera rien du tout.

shellcommands:

   any::
# Voici une classe, reconnaissable à ses doubles deux-points.
# On ne la déclare bien sûr qu'APRES avoir déclaré l'action à entreprendre.
# La classe "any" est générique. N'en spécifier aucune revient au même.

      "/bin/echo cfagent en sait assez !"
# Le chemin de la commande à exécuter se doit d'être absolu.
# Toute 'shellcommand' doit être placée entre guillemets.

#
#
# fin de cfagent.conf basique, tout juste fonctionnel.

Environnement de Tests

• Préambule
• Nommage et adressage des machines
• Systèmes d'exploitation
• En résumé

Préambule

• d'une salle de cours, claire, et divinement silencieuse :-)
• de six machines de type PC i686 en parfait état de fonctionnement
• de l'aide et du soutien de Patrick (ingénieur système au Labri, de mon stage le tuteur)

Nommage et adressage des machines

Systèmes d'exploitation

En résumé

# fichier /etc/hosts suivant

127.0.0.1       stage2.labri.fr     stage2      # important pour 'cfagent'!

192.168.0.12    stage2.labri.fr     stage2      # RedHat 7.3
192.168.0.13    stage3.labri.fr     stage3      # Mandrake 8.2
192.168.0.14    stage4.labri.fr     stage4      # FreeBSD 4.5
192.168.0.15    stage5.labri.fr     stage5      # Ouine_Dose_2k
192.168.0.16    stage6.labri.fr     stage6      # Turbolinux 6.5
192.168.0.17    stage7.labri.fr     stage7      # Slackware 8.0

192.168.0.1     gateway   dns

Installation & Configuration

• Stratégie
• Pré-requis
• Installation
• Configuration
• Post-Installation

Stratégie

• Téléchargement des différentes sources — puis installation, configuration, et test de cfengine sur une machine, ici baptisée 'stage2'.
• Copie des différentes sources nécessaires (via ssh) depuis 'stage2' vers chacun des hôtes. Installation de cfengine sur ceux-ci. Puis pollenisation des différents fichiers de configuration, de 'stage2' vers chacun des hôtes (cf Simulation de Déploiement).
• Étudier un certain nombre de fonctionnalités de cfengine, à travers l'écriture d'un fichier 'cfagent.conf' un peu plus élaboré (cf Explorations).

Pré-requis

• OpenSSL
• Berkeley DB version 3.2, ou supérieure

[stage2] $ tar xzf openssl-0.96c.tar.gz
[stage2] $ cd openssl-0.96c && ./config
[stage2] $ make 
[stage2] # make install 
[stage2] $ make clean # (optionnel) 

[stage2] $ tar xzf db-3.2.9.tar.gz
[stage2] $ cd db-3.2.9/build_unix
[stage2] $ ../dist/configure
[stage2] $ make
[stage2] # make install
[stage2] $ make clean # (optionnel)

Installation

[stage2] $ tar xzf cfengine-2.0.3.tar.gz
[stage2] $ cd cfengine-2.0.3 && ./configure
[stage2] $ make
[stage2] $ make check # (optionnel)
[stage2] # make install
[stage2] $ make clean # (optionnel)

Post-Installation

[stage2] $ less /etc/services | grep cfengine
cfengine      5308/tcp
cfengine      5308/udp

/usr/local/sbin/cfagent
/usr/local/sbin/cfenvd
/usr/local/sbin/cfexecd
/usr/local/sbin/cfkey
/usr/local/sbin/cfrun
/usr/local/sbin/cfservd

/usr/local/share/cfengine/html/cfengine-Reference.html
/usr/local/share/cfengine/html/cfengine-Tutorial.html

Configuration

/var/cfengine/ppkeys/localhost.priv
/var/cfengine/ppkeys/localhost.pub

/var/cfengine/inputs
/var/cfengine/outputs
/var/cfengine/bin

Les fichiers .conf

• cfagent.conf
• update.conf
• cfservd.conf
• Résumé

cfagent.conf

################################################################
#
# cfagent.conf basique, tout juste fonctionnel.
# Le même qui nous a servi à étudier la syntaxe de cfengine.
#
################################################################

control:

   domain  = ( labri.fr )
   actionsequence = ( shellcommands )

shellcommands:

   "/bin/echo cfagent en sait assez !"
# Dans un premier temps, cela suffit !
# En effet, cfagent requiert essentiellement la présence d'une
# 'actionsequence' dans son fichier de conf'.

#
#
# fin de cfagent.conf, basique tout juste fonctionnel.

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 = ( labri.fr )
   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 = ( stage2 )
   masterdir = ( /var/cfengine/inputs )
   localdir = ( /var/cfengine )
# Bien entendu, 'stage2' 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:

   !stage2::
# 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)
# Soit le répertoire /var/cfengine/inputsde 'stage2', notre 'policyhost',
# pas la peine de préciser ;-)

                     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é,
# ici pas vraiment nécessaire, mais bon.

                     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.
# Il existe d'autres moyens de comparaison (cf 'ref.man.').

                     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 p’tite faille de sécurité...

#
#
# Fin du fichier update.conf, simple et fonctionnel.

cfservd.conf

################################################################
#
# cfservd.conf
# La présence de ce fichier, et du démon qui s'y réfère,
# sont indispensables au bon fonctionnement de cfengine.
#
################################################################

control:

   domain = ( labri.fr )
   AllowConnectionsFrom = ( 192.168.0 )
   TrustKeysFrom = ( 192.168.0 )
   Access = ( root moi )
# Variables internes, pour faciliter les choses.

   cfrunCommand = ( "/usr/local/sbin/cfagent" )
# Utile pour que 'cfrun' sache ce qu'il a à faire...

grant:
# Peut aussi s'appeler 'admit'. Une section très importante,
# car c'est ici que nous allons spécifier quels hôtes ont droit d'accès
# à quels fichiers, voire sytèmes de fichiers...
# Je ne cache pas que la plupart des messages d'erreur que j'ai essuyé venaient de là !

   any::

      /usr/local/sbin   $(policyhost)
# Requis par 'cfrun' (lancé depuis 'stage2', bien sûr).
# Notons que les variables déclarées dans 'update.conf' restent valables ici :-).

   stage2::

      /var/cfengine/inputs   stage*.labri.fr
# Sans cette spécification-là, c'est l'action 'copy' de 'update.conf'
# qui échouerait lamentablement. 

#
#
# fin de cfservd.conf.

Résumé

[stage2] # ls -l /var/cfengine/inputs
total 12
-rw-r--r--  1 root      root       168 Aug 12 10:13  cfagent.conf
-rw-r--r--  1 root      root       237 Aug  9 13:36  cfservd.conf
-rw-r--r--  1 root      root       750 Aug  8 18:02  update.conf

Simulation de Déploiement

• Préliminaires
• Vif du sujet

Préliminaires

1. pour mémoire, notre serveur de stratégie ('policyhost') est la machine baptisée 'stage2', son invite étant sobrement [stage2].
   Dans un souci de clarté (préoccupation majeure, voire obsessionnelle du rédacteur de documentation), 'stage3' représentera par convention tous les autres hôtes, et son invite ([stage3], donc) apparaîtra chaque fois qu'une commande sera lancée depuis n'importe lequel d'entre eux.
   
   
2. il a été décidé (à l'unanimité puisque j'étais d'accord) que, pour simplifier les échanges entre les machines, chacune d'elles serait à la fois cliente et serveur SSH (pour Secure SHell, www.Openssh.org)
   
   Exemple, avec le 'tarball' de cfengine que l'on a conservé dans notre répertoire utilisateur sur 'stage2' :

   [stage2] $ cd /home/moi
   [stage2] $ scp cfengine-2.0.3.tar.gz moi@stage3:~/cfengine-2.0.3.tar.gz
   moi@stage3's password:
   cfengine-2.0.3.tar.gz      100% |******************| 1114 KB   00:00
   [stage2] $
   

   > il en ira de même pour les sources d'OpenSSL et de BerkeleyDB, lorsque ces derniers ne seront pas présents sur les hôtes.
   
   
3. comme certains fichiers nécessitant d'être copiés à distance appartiennent à 'root', j'ai dû décommenter la ligne suivante du fichier /etc/ssh/sshd_config de chacun des hôtes :
   
   PermitRootLogin yes
   
   Je vous sens nerveux, mais pas d'inquiétude : nous boucherons ce vilain trou de sécurité, à la section Explorations, promis ;-)

Vif du sujet

[stage2] # cd /var/cfengine/inputs
[stage2] # scp update.conf root@stage3:/var/cfengine/inputs/update.conf
root@stage3's password:
update.conf      100% |***************************| 750   00:00
[stage2] #

[stage3] # cd /var/cfengine/ppkeys
[stage3] # scp localhost.pub root@stage2:/var/cfengine/ppkeys/root-192.168.0.13.pub
root@stage2's password:
localhost.pub    100% |***************************| 426   00:00
[stage3] #

[stage3] # ls -l /var/cfengine/ppkeys
total 8
-rw-------  1 root      root      1743 Aug  12 10:01  localhost.priv
-rw-------  1 root      root      0426 Aug  12 10:01  localhost.pub

[stage3] # ls -l /var/cfengine/inputs
total 4
-rw-r--r--  1 root      root       750 Aug  12 11:01  update.conf

[stage3] # ls -l /var/cfengine/ppkeys
total 12
-rw-------  1 root      root      1743 Aug  12 10:01  localhost.priv
-rw-------  1 root      root      0426 Aug  12 10:01  localhost.pub
-rw-r--r--  1 root      root      0426 Aug  12 12:01  root-192.168.0.12.pub

[stage3] # ls -l /var/cfengine/inputs
total 12
-rw-r--r--  1 root      root       968 Aug  12 12:01  cfagent.conf
-rw-r--r--  1 root      root       237 Aug  12 12:01  cfservd.conf
-rw-r--r--  1 root      root       750 Aug  12 11:01  update.conf

[stage2] # ls -l /var/cfengine/ppkeys
total 12
-rw-------  1 root      root      1743 Jul  19 13:01  localhost.priv
-rw-------  1 root      root      0426 Jul  19 13:01  localhost.pub
-rw-r--r--  1 root      root      0426 Aug  12 12:01  root-192.168.0.13.pub
-rw-r--r--  1 root      root      0426 Aug  12 12:11  root-192.168.0.14.pub
-rw-------  1 root      root      0426 Aug  12 12:21  root-192.168.0.16.pub

*.info;mail.none;cron.none                @stage7

*.=info;*.=notice                         /dev/tty5           # par exemple

Explorations

• Prélude
• Fugue

Prélude

#############################################################
#
# cfrun.hosts
# Voici les hôtes qui pourront être contactés à distance
#
#############################################################

   domain=labri.fr
   access=root
# simple mesure de précaution.

stage3
stage4
stage6

#
#
#
# C'est tout (mais il fallait bien le faire quand même :-)

Fugue

#############################################################
# 
# cfagent.conf.
# à tester sans modération !
# 
#############################################################

control:

   domain  = ( labri.fr )
   Syslog = ( on )
   Inform = ( on )
# Si on veut se tenir au courant...

   smtpserver = ( stage2 )
   sysadm = ( root@stage2 )
# 'cfexecd', grand épistolier, exige ceci.

   schedule = ( Min00_05 Min30_35 )
# pour que 'cfexecd' s'exécute chaque demi-heure.

   SplayTime = ( 2 )
# Une variable interne pour dire aux hôtes d'attendre un laps de temps
# (nombre aléatoire généré par cfengine, et différent pour chaque hôte),
# ici compris entre 0 et 2 minutes, avant d'exécuter 'cfagent'.
# Ceci afin d'éviter une surcharge du $(policyhost)
# si de trop nombreux hôtes le sollicitent au même moment.
# note : Pour exécuter 'cfagent' avec le SplayTime à zéro
# (i.e. sans attendre jusqu'à deux minutes qu'il veuille bien se décider),
# il conviendra de lui passer l'option '-q' (équivalent à '--no-splay').

   IfElapsed = ( 2 )
# Option anti-spam. L'intervalle de temps entre deux exécutions de 'cfagent'
# ne pourra être inférieur à 2 minutes.
# Par défaut, elle est d'une minute — ce qui suffirait amplement ici.

   ChecksumDatabase = ( /var/cfengine/cf.db )
# Créera un fichier contenant les 'checksums' des différents fichiers (ou répertoires)
# dont nous demanderons à 'cfagent' de vérifier l'intégrité.
# Cf l'action 'files', un peu plus bas.

import:

   stage5::

      cf.stage5.conf
# Imaginons que nous ayons un hôte TRÈS particulier (ou plusieurs :-{
# auquel cas on en ferait un 'group' et ça reviendrait au même) ;
# un hôte si particulier,
# qu'aucune des actions entreprises ici ne le concerneraient vraiment,
# et que les actions qui le concerneraient ne concerneraient que lui...
# Eh bien, à supposer qu’un tel hôte existe, le mieux serait encore d'écrire
# un fichier de conf' rien que pour lui, et de spécifier à 'cfagent',
# grâce à la section 'import', d'aller lire le fichier de conf' en question.
# Accessoirement, ça nous évite d'avoir des fichier de conf' sambaïques
# (qui n'en finissent pas).

   actionsequence = ( links files editfiles disable )
# important : les actions spécifiées seront exécutées
# DANS CET ORDRE-LÀ.

links:

   any::

      /var/cfengine/bin/cfagent -> /usr/local/sbin/cfagent
# Histoire de rafraîchir la mémoire défaillante de 'cfexecd'.
# L'action 'links' est l'équivalent de la commande 'ln -s'.
# La structure : fichier_dest -> fichier_source est, quant à elle,
# identique à ce que retourne la commande 'ls -l'.

files:

   linux::

      /etc/shadow mode=400 owner=root action=fixall     
# L'action 'files' est un bon moyen de préserver l'intégrité
# de certains fichiers sensibles...

   any::

      /var/cfengine/inputs mode=755 action=fixall
      /var/cfengine/outputs mode=755 action=fixall
# ... et de contrôler les effets incontrôlables du même 'cfexecd' !
# En l'occurence, 'cfexecd' colle 700 à ces deux répertoires.
# Moi, je trouve pratique de pouvoir les consulter en tant que simple user.

      /sbin checksum=md5 recurse=inf
# Si quelque chose change dans ce répertoire, à chaque exécution de 'cfagent'
# un message d'alerte nous en préviendra, jusqu'à ce que nous ayons fixé le problème,
# reconstruit la base (i.e. supprimé le fichier /var/cfengine/cf.db,
# lequel se recréera tout seul à la prochaine exécution de 'cfagent'), etc.

editfiles:
# Cette action permet d'éditer des fichiers ASCII,
# et possède de nombreuses options, dont celle-ci,
# qui va nous permettre de boucher le vilain trou de sécurité
# que nous avons 'volontairement' créé plus haut :

      { /etc/ssh/sshd_config

        CommentLinesStarting "PermitRootLogin"
      }
# Et la ligne commençant par la chaîne placée entre guillemets sera (à nouveau) commentée.
# Mieux : 'cfagent' veillera désormais à ce qu'elle le reste !
# Par défaut, les commentaires sont les mêmes que ceux employés ici ('#'),
# mais il est possible d'en spécifier d'autres (cf 'ref.man.', comme d'hab').

      { /etc/rc.d/init.d/cfengine
      
        AppendIfNoSuchLine "# start cfservd"
        AppendIfNoSuchLine "/usr/local/sbin/cfservd"
        AppendIfNoSuchLine "# start cfexecd"
        AppendIfNoSuchLine "/usr/local/sbin/cfexecd"
        AppendIfNoSuchLine "# start cfenvd"
        AppendIfNoSuchLine "/usr/local/sbin/cfenvd"
      }
# Sans commentaires, si j'ose dire :-)
# Si l'on change d'avis, par exemple pour 'cfexecd', un simple :

      { /etc/rc.d/init.d/cfengine

        DeleteLinesContaining "cfexecd"
      }
# devrait suffire.

      { /etc/hosts

        AppendIfNoSuchLine "192.168.0.17        stage7.labri.fr stage7"
      }
# Bienvenue au nouvel hôte !

# Allons, un jour ou l'autre, il faudra se faire une raison :

disable:
# rajoutera l'extension .cfdisabled...

   any::

      /usr/bin/sudo   syslog=on   inform=true
# ...à ce fichier, en conséquence de quoi il deviendra inopérant :-(

#
#
#
# fin (toute provisoire) de cfagent.conf.

Epilogue

• Ce que j'ai apprécié avec cfengine
• Ce que j'ai moins apprecié
• Ce dont je n'ai pas parlé dans ce papier

• l'éventail de fonctionnalités offertes par le logiciel, éventail que je n'ai fait qu'entrouvrir ici, et qui me paraît pouvoir s'élargir presque à l'infini. Ceci est dû non pas tant à la quantité d'actions possibles, qu'à la possibilité de les combiner afin de répondre au plus près aux besoins de l'administrateur.
  
  
• son efficacité. Associé à des outils comme Openssh, xinetd, nmap et quelques autres, il rendra d'immenses services en centralisant, rationnalisant et simplifiant les multiples tâches quotidiennes à accomplir, en rendra de nouvelles possibles — et contribuera ainsi à améliorer l'efficience, voire la sécurité du système.
  
  
• sa relative simplicité d'utilisation. Même un sysadmin débutant, à condition de posséder quelques notions de base d'un système unix, peut tirer grand profit de cfengine. Personnellement, il m'a beaucoup apporté dans l'approfondissement de mes connaissances.
  
  
• sa fiabilité. Je n'ai eu aucune mauvaise surprise de ce côté-là ; aucun bug à déplorer. Mais bien sûr je n'ai pas poussé son étude très loin. Surtout je ne l'ai pas utilisé en situation 'réelle'...

• l'absence d'un papier comme celui que vous avez entre les mains :-).
  Si les deux principaux fichiers fournis, le 'Tutorial' et le 'Reference Manual', font à eux deux le tour de la question, on ne peut pas vraiment parler de visite guidée ! Bon, mais j'étais là aussi un peu pour ça...
  
  
• personnellement, j'aimerais bien que l'édition de fichiers soit plus élaborée, notamment en ce qui concerne les interventions possibles sur les champs. En fait, j'aimerais bien que l'action 'editfiles' devienne une sorte de front-end pour 'gawk' :-)

• NT ! Je n'ai pas eu le temps de m'occuper de lui :----- o
  De toute manière, comme nous l'apprend la page qui lui est consacrée, seule l'action 'copy' est actuellement supportée (ça c'est la vérité !).
  Si vous voulez malgré tout tenter l'aventure, celle-ci commence avec le téléchargement, puis l'installation de cygwin ("GNU + Cygnus + Windows") disponible ici : www.cygwin.com.
  Ce dernier vous installe un shell et tous les outils de base, après quoi vous téléchargez les différentes sources et vous les installez comme si vous étiez sous unix. Ensuite... je ne sais pas.
  
  
• De nombreuses fonctionnalités de cfengine concernent l'utilisation de NFS (Network File System), ou système de fichiers distribués. Préférant concentrer mes efforts sur d'autres fonctionnalités, il ne m'a pas paru essentiel de le mettre en œuvre...
  Jusqu’à ce que j’apprenne (à la dernière minute !) que c'est précisément sur NFS que repose tout le système mis en place au Labri :-[].
  Cela dit, Patrick m'a dispensé de creuser plus avant la question, se réservant, entre deux appels (à l'aide), l'étude de la chose (en question).
  
  
• Une autre fonctionnalité de cfengine, de relative importance, dont je n'ai pas touché un mot ici, concerne les Access Control Lists (Solaris, DFS, NT).
  Par bonheur, celles-ci n'ont pas cours ici, au Labri. Je renverrai donc le lecteur (non sans un certain soulagement), une ultime fois, à l'incontournable 'Reference Manual'.

Remerciements

• En premier lieu, je tiens à remercier mon formateur principal, Gérard Massol.
  Celui-ci, en effet, au-delà de nos approches, disons, différentes de la chose informatique, a fait tout son possible pour m'aider dans ma démarche — même lorsque celle-ci ne se conformait plus guère au programme initial de la formation. Il a en outre obtenu auprès de la direction qu'un intervenant extérieur (Nicolas Dubrocas, que je profite pour remercier également ici) vienne m'instruire personnellement de quelques aspects fondamentaux d'un système Unix / Linux.
  
  
• Je remercie aussi bien sûr Patrick, ingénieur système au Labri, pour la confiance et l'écoute qu'il a su m'accorder, ainsi que pour les encouragements qu'il m'a adressé — toutes choses qui ont contribué au bon, voire à l'excellent déroulement de mon stage.
  
  
• Merci enfin à l'ensemble de la communauté si vivante et si riche du logiciel libre, sans qui mon engouement pour l'informatique ne serait pas ce qu'il est. Sans qui l'informatique, disons le tout net, ne serait QUE ce qu'elle est encore, hélas, trop souvent : une chose ennuyeuse et sans âme, entre des mains cupides...

Références - Liens