GNU/Cfengine Administration Automatique Linux Sébastien Bègue Encadrant Cellule Membre : Benjamin Dexheimer : SysLog : Jean-Claude Giese LORIA CAMPUS Scientifique BP 239 54 506 VANDOEUVRE-lès-NANCY Cedex RÉSUMÉ. L administration automatique de postes clients représente, pour l administrateur système, un gain de temps très appréciable notamment actuellement du fait de la diffusion massive de virus sur les postes WINDOWS. Le parc informatique du Loria est constitué d un ensemble de machines hétérogènes reposant sur des systèmes UNIX (Linux Mandrake 8.1, 9.0, 9.2, Red Hat 6.2) et WINDOWS. Ce rapport expose un outil, à présent utilisé par le service des Moyens Informatiques (MI) du Loria, permettant une administration automatique et centralisée du parc de machines Linux gérées par ce service. ABSTRACT. Client desktops automated administration represents today, for the system administrator, a valuable time gain, especially in those times where massive virus attacks occur against Windows machines. Loria s assets consist of heterogeneous machines relying on different flavours of Unix (Linux Mandrake 8.1, 9.0 & 9.2, RedHat 6.2) and Windows. This report presents a tool, now in use within Loria s Information System Department, allowing for a centralized and automated management of all Linux machines. MOTS-CLÉS : Cfengine, administration, linux. KEYWORDS: Cfengine, administration, linux. GNU/Cfengine. Volume 2 n 2/2004, pages 1 à 29
2 GNU/Cfengine. Volume 2 n 2/2004 SOMMAIRE 1. INTRODUCTION...3 2. PRESENTATION...3 2.1. LORIA...3 2.1.1. Le service des Moyens Informatiques (MI)...4 2.1.2. Place occupée au sein du service....4 2.2. LA MISSION DE STAGE...4 3. L ADMINISTRATION AUTOMATIQUE....5 3.1. DEFINITION ET ENJEUX...5 3.2. L EXISTANT....6 3.2.1. Majax...6 3.2.2. Mode de fonctionnement...6 3.2.3. Fonctionnalités...7 3.2.4. Exemples d applications...8 3.3. L EVOLUTION....8 3.3.1. Cfengine...9 3.3.2. Mode de fonctionnement...9 3.3.2.1. Les binaires...9 3.3.2.2. Les fichiers de configuration...11 3.3.2.3. Le langage...13 3.3.3. Fonctionnalités...14 3.3.4. Exemples d applications...17 3.3.4.1. Modification du mot de passe «root» du site....17 3.3.4.2. Déploiement de nouveaux outils...18 4. MISE EN PRODUCTION....18 4.1. DEPLOIEMENT...19 4.1.1. Installation sur le parc actuel...19 4.1.2. Les nouvelles machines : post-installation....21 4.2. LES CONFIGURATIONS «CFENGINE»....22 4.2.1. La configuration «client»....23 4.2.2. La configuration «serveur»....23 4.2.3. Les configurations de tests...23 4.2.4. La configuration de post-installation....24 4.3. AMELIORATIONS ET FIABILISATIONS....24 5. TRANSMISSION DES CONNAISSANCES...26 5.1. DOCUMENTATION DES MOYENS INFORMATIQUES (DOCMI)...26 5.2. INITIATION DES PERSONNELS PERMANENTS....27 6. CONCLUSION....28 7. BIBLIOGRAPHIE....29
Administration Automatique Linux 3 1. Introduction Le stage universitaire obligatoire inscrit à la formation en Réseaux Numériques de Communication de l Institut Universitaire Professionnel de la faculté scientifique de Nancy, représente une opportunité pour la réalisation de missions d ingénieries. Ce document présente la mission qui m a été confiée, au cours des six mois passés au sein du service des Moyens Informatiques du LORIA, à travers les différentes étapes du projet «Cfengine» encadré par Monsieur Benjamin DEXHEIMER (Ingénieur Système et Sécurité). Ainsi après une présentation du laboratoire et de la mission de stage, j exposerai ce qu est l administration automatique et quel est l outil permettant sa réalisation dans le contexte technologique imposé par l architecture du système informatique du LORIA. Dans un troisième temps, la mise en production de l outil détaillé précédemment sera élucidée, avant de finir par les étapes de transmission des connaissances à l équipe des Moyens Informatiques afin d assurer le suivi du système, son évolution et bien entendu son utilisation. 2. Présentation Cette phase de présentation est scindée en deux objectifs afin de correctement poser les bases nécessaires à la compréhension des parties suivantes. Ainsi après une courte introduction du LORIA, la présentation de la structure du service des Moyens Informatiques permettra de comprendre le cadre dans lequel j ai réalisé ma mission de stage. 2.1. LORIA Le LORIA, Laboratoire Lorrain de Recherche en Informatique est ses Applications, est une Unité Mixte de Recherche UMR 7503 commune aux organismes suivants : - Centre National de la Recherche Scientifique (CNRS) ; - Institut National Polytechnique de Lorraine (INPL) ; - Institut National de Recherche en Informatique et en Automatique (INRIA) ; - Université Henri Poincaré, Nancy 1 (UHP, Nancy 1) ; - Université Nancy 2. Cette unité, dont la création a été officialisée le 19 décembre 1997 par la signature d un contrat quadriennal avec le Ministère de l Education Nationale, de la Recherche et de la Technologie et par une convention entre les cinq partenaires, succède ainsi au centre de Recherche en Informatique de Nancy (CRIN), et aux équipes communes entre celui-ci et l Unité de Recherche INRIA-Lorraine.
4 GNU/Cfengine. Volume 2 n 2/2004 Depuis le 1 er janvier 2001, c est Hélène KIRCHNER qui dirige le LORIA. Actuellement plus de 450 personnes travaillent dans le laboratoire : - doctorants ; - enseignants chercheurs ; - chercheurs ; - personnels administratifs. 2.1.1. Le service des Moyens Informatiques (MI). Les Moyens Informatiques sont une équipe de 4 techniciens, une assistante et 10 ingénieurs. Cette grande équipe assure beaucoup de services et élabore beaucoup de projets dans des domaines très variés. Afin de couvrir l ensemble de ces activités de la manière la plus structurée possible, le service est découpé en différentes cellules, chacune étant sous la direction d un agent des MIs. Ainsi on retrouve : - la cellule NST (Network Security Telephony) qui a en charge le réseau (gestion des couches basses), la téléphonie (sur IP), et la sécurité orientée réseau (sécurisation des accès, des machines et des applications). - la cellule SI (Système d Information) pour le développement et le déploiement d outils et gestion des bases de données, et fourni une expertise au niveau flux de données au LORIA. - la cellule SysLog (Systèmes et Logiciels) a pour mission l étude et la mise en place de solutions systèmes et logicielles en rapport avec les besoins spécifiques des utilisateurs du LORIA. Le service est sous la responsabilité de Monsieur Bertrand WALLRICH (RMI) qui a pour fonction d assister le directeur dans la définition de la politique générale du laboratoire et de la mettre en œuvre. Il élabore la politique informatique, propose les orientations en matière d'investissements, assure le suivi des marchés et gère le budget du service. Dans la gestion de l'équipe, il a un rôle d'animation de l'équipe et de gestion des ressources humaines. Il pilote les changements d'organisation nécessaires. 2.1.2. Place occupée au sein du service. Intégré au sein de l équipe des Moyens Informatiques dans le cadre du projet «Cfengine» initié par Monsieur Benjamin DEXHEIMER, je suis membre de la cellule SysLog dans le cadre d un stage conventionné de six mois. Au cours de ce stage j ai exercé des activités d ingénieur système dont le document présent reflète la substance. 2.2. La mission de stage. Le site du LORIA est composé d'un parc informatique hétérogène. On peut y trouver des machines, Unix et Windows. Le projet «Cfengine» touche les machines
Administration Automatique Linux 5 «Unix» gérées par les Moyens Informatiques à savoir, les distributions «Linux» suivantes : - Mandrake 8.1, 9.0, 9.2 et bientôt 10.0. - Red Hat 6.2. L'objectif du projet est d'étudier la faisabilité du remplacement de l'outil «Majax» par «Cfengine». Ainsi il est nécessaire dans une première période d analyser le champ d action de l outil «Cfengine» afin d en étudier l adéquation avec les besoins d administration du service. Ensuite, après argumentation sur les atouts d un tel outil, la mise en production de ce dernier doit être réalisée de la manière la plus globale possible sur l ensemble des machines gérées. Enfin, et afin d assurer l utilisation de ce nouveau système, la transmission des connaissances acquises sera assurée par différents supports permettant aux ingénieurs permanents de comprendre et de prendre en main le nouveau système d administration automatique des stations «Linux». 3. L administration automatique. Comme expliqué ci-dessus, la mission de stage à pour thème l administration automatique de poste «Linux», et ce, dans un environnement hétérogène de machines. Au cours de cette partie traitant l étude de l existant et du nouvel outil «Cfengine», je vais exposer les différents arguments qui ont permis de convaincre l ensemble de l équipe des atouts majeurs proposés par le nouveau système. 3.1. Définition et enjeux. Par administration il faut entendre administration système, logicielle et réseau. En effet la seule administration réseau, essentiellement composée par le paramétrage des équipements réseau et par la configuration réseau des machines, n est pas suffisante pour le maintient du parc «Linux» du LORIA. Ainsi l administration logicielle représente les tâches de configuration de logiciels, de déploiement de nouveaux outils, tandis que l administration système est constituée essentiellement par la configuration du système en lui-même ainsi que par la gestion des différents services utilisés dans le contexte du LORIA. A titre d exemple on peut citer le déploiement d outils de sécurisation des échanges tel que «SSH» ou l édition de configuration pour différents démons et le monitoring de ces derniers. On devine à travers ces deux exemples, la tâche frustrante d un administrateur qui se verrait confié de tels objectifs sans disposer d un outil réalisant ces opérations de manière automatique, et ce lorsque le parc machine visé comporte plusieurs centaines de stations (serveurs et clientes confondues).
6 GNU/Cfengine. Volume 2 n 2/2004 Ainsi l administration automatique se propose de centraliser les différentes tâches à réaliser et de les distribuer ensuite aux stations par l intermédiaire du réseau, afin que ces dernières mettent à jour leur configuration. L enjeu est conséquent puisqu il représente un gain de temps pour l administrateur qui peut alors se concentrer sur d autres aspects plus évolués, plutôt que de passer sur chacune des machines afin d effectuer les changements nécessaires. Le temps n est pas le seul facteur qui doit rentrer en ligne de compte pour le passage à un tel système. En effet la centralisation des configurations permet une homogénéisation de ces dernières et, par la même, un gain de sécurité, puisque l état des machines gérées est l exact reflet des configurations distribuées. Le système d administration automatique, on le verra plus loin dans ce document, peut également être utilisé dans l installation automatique des stations. On parle alors de «boot-strapper» l installation du système d administration automatique. Cette phase repose sur des techniques spécifiques d installation automatique des stations à partir de serveurs de distributions. 3.2. L existant. Lors de mon arrivée au sein de l équipe des Moyens Informatiques, un outil d administration automatique des machines Linux était déjà en place. Ce dernier nommé «Majax» était toujours utilisé, mais son maintient n était, lui, plus assuré. 3.2.1. Majax. «Majax» (Mise A Jour AutomatiX) est un système développé par les Moyens Informatiques eux-mêmes en 1994. A cette époque le parc machine était composé uniquement par des stations «Unix». Le but principal de cet outil est de mettre à jour automatiquement des fichiers sur les stations du réseau. 3.2.2. Mode de fonctionnement. «Majax» repose sur un ensemble de scripts «Perl» et utilise le service «NFS» (Network File System) pour le transfert de fichiers depuis une source (un montage) commune à toutes les stations. Afin de procéder à sa mise à jour, une station lance l exécution du script «majax.pl» par l intermédiaire de la «crontab» du super utilisateur («root»). Ainsi c est la station elle-même qui demande les mises à jour. La diffusion de ces dernières se fait donc par une méthode de type «traps». Cela confère beaucoup de souplesse au système puisqu il permet d ignorer les machines débranchées du réseau. La limitation de ce mode de fonctionnement tient à l utilisation systématique du service «NFS». En effet si ce dernier venait à tomber, aucune machine ne pourrait alors effectuer des mises à jour. La configuration des actions à réaliser par «Majax» se fait au sein d un fichier («.majaxrc»), écrit dans une syntaxe propre au «parser» de «Majax». Au sein de ce fichier, à une ligne correspond une action, et chaque ligne est découpée en plusieurs champs délimités par «:». Au total cinq champs sont nécessaires à
Administration Automatique Linux 7 l écriture d une action. Le premier champ donne le nom du fichier local à tenir à jour. Le second champ indique le nom du fichier central avec lequel sera comparé le fichier local. Afin d effectuer la comparaison le troisième champ indique le choix de la méthode de comparaison. Le quatrième champ, quant à lui, permet de spécifier quel type de machine devra réaliser cette action. Il est ainsi possible de définir les machines par leur nom ou par leur type de système d exploitation, etc Enfin le cinquième et dernier champ, est utilisé pour spécifier le nom du script qui sera lancé par «Majax» pour réaliser l action désirée. Cela donne par exemple dans le cas d une mise à jour du fichier /etc/syslog.conf la syntaxe suivante : /etc/syslog.conf:/etc/syslog.conf:date:ostype=linux:copy.pl 3.2.3. Fonctionnalités. Comme dit précédemment, «Majax» fonctionne grâce à un ensemble de scripts écrits en «Perl». On a noté également qu il était possible d exécuter un script dans une action. Ainsi un certain nombre de scripts sont nécessaires afin de réaliser les tâches d administration actuelles tels que : - «copy.pl» : pour la gestion de la copie de fichiers. - «majaxbdmi.pl» : script effectuant une remontée d informations depuis une machine cliente afin de remplir une base de données interne au service (BDMI). - «passwd.pl» : script de la gestion de la modification du mot passe de l utilisateur «root» sur le site. Ces trois scripts ne sont que des exemples, puisque l actuel outil «Majax» compte environ une centaine de scripts. Cela lui permet de réaliser l essentiel des tâches d administration souhaitées par les Moyens Informatiques à savoir la copie, la suppression de fichiers, la gestion des droits utilisateur, le déploiement de nouveaux outils, la gestion de liens symboliques, la gestion de processus particuliers, Cette structure en scripts donnée à «Majax» lui confère une certaine souplesse en terme de fonctionnalités, dans la mesure où il est toujours possible de développer de nouveaux scripts pour exécuter des actions jusqu alors impossibles. Malheureusement le développement de scripts n est plus en cours, et l outil, de ce fait, arrive en fin de vie. Une autre fonctionnalité de «Majax», nommée «Ramene_majax» consiste à inverser le fonctionnement de l outil d administration automatique. «Ramene_majax», tout comme «Majax» fonctionne à partir de scripts «Perl», et permet de sauvegarder la configuration (fichiers de configuration) d une station dans un répertoire cible organisé selon le type de système d exploitation, l architecture système, la version de noyau et le nom de machine. Cela permet en cas de crash d une machine ou d un serveur, de restaurer la configuration de la machine rapidement. Enfin «Majax» dispose d un système de log permettant un suivi des actions entreprises par l outil. Cependant ce dernier est à présent désactivé de part la complexité des fichiers générés. Ces derniers n étaient plus consultés.
8 GNU/Cfengine. Volume 2 n 2/2004 3.2.4. Exemples d applications. Une première application possible de «Majax» est décrite par la ligne suivante au sein du fichier «.majaxrc» : - *:::ostype=linux :majaxbdmi.pl Cette ligne aura pour effet chez un client de lancer l exécution du script majaxbdmi.pl et ce uniquement sur les systèmes d exploitation de type «Linux». Cette ligne est utilisée afin de remonter un ensemble d informations relatives à la machine cliente et qui peuvent être utilisées afin de compléter la base de données des Moyens Informatiques (BDMI). - /usr/bin/passwd::existe:ostype=linux:rm.pl L analyse des différents champs construisant cette ligne nous montre qu elle est utilisée afin de supprimer la possibilité à un utilisateur de modifier son mot de passe sur sa machine. En effet la modification de mot de passe, est possible par l exécution du binaire «passwd». Or la ligne de configuration ci-dessus supprime le binaire considéré lorsqu il existe, sur les machines de type «Linux», par l intermédiaire du script «rm.pl» qui prends en paramètre le nom complet du fichier à supprimer. - /etc/passwd::droits:host!:setdroits.pl Le script «setdroit.pl» est utilisé par «Majax» dans le cadre du maintient des droits sur certains fichiers. Par exemple la ligne de configuration ci-dessus permet de maîtriser les droits du fichier «/etc/passwd», gérant les comptes utilisateurs. Ces différentes lignes de configuration représentent les actions majeures demandées à «Majax». L action de copie de fichier est également très utilisée à travers le script «copy.pl». Ce système d administration automatique est toujours utilisé actuellement afin de maintenir les actions déjà programmées (environ 180) et de permettre on va le voir plus tard le déploiement d un nouvel outil d administration automatique des postes «Linux» : «Cfengine». Cette analyse de l outil actuel, nous a permis de dégager les conditions de fonctionnalités que doit remplir «Cfengine» pour réussir à succéder à «Majax», mais nous a également montré la souplesse de fonctionnement apportée par ce dernier à travers l utilisation de scripts. Le gros point noir au sein de ce système vieillissant réside au niveau de son architecture de fonctionnement. En effet cette dernière repose intégralement sur le service «NFS» et fait appel à un ensemble de scripts qui ne sont actuellement plus maintenus. On perd alors l avantage de la souplesse, puisque l évolution de l outil est stoppée. En partant de ce constat, voyons à présent quels sont les arguments avancés par «Cfengine» pour combler les faiblesses de «Majax». 3.3. L évolution. On l a vu au cours de l analyse de l existant, l outil d administration automatique «Majax» est en fin de vie. Son développement stoppé ainsi que sa dépendance vis à
Administration Automatique Linux 9 vis du service NFS pousse l équipe à rechercher une nouvelle solution afin de poursuivre la politique de gestion des stations «Linux». 3.3.1. Cfengine. Le logiciel GNU/cfengine («Cfengine») est un logiciel libre développé par Mark Burgess (chercheur et professeur associé à l'university College d'oslo). Ce logiciel est écrit en C et est utilisé pour l'administration de parc hétérogène de machines. Les OS concernés par ce logiciel, sont les «OS Unix» : «Linux», «BSD», Théoriquement «Cfengine» peut être utilisé avec des stations Windows. Cependant les possibilités de «Cfengine» se voient alors réduites à un minimum qui est la copie de fichiers. Ainsi l étude du système «Cfengine» se limite aux seuls «OS Unix» et plus spécialement les systèmes «Linux» à travers les distributions «Mandrake» et «Red Hat» supportées. 3.3.2. Mode de fonctionnement. Le système Cfengine repose sur une architecture client-serveur, c est à dire un serveur qui va stocker les configurations et des clients qui s adressent au serveur afin d obtenir les configurations qui vont leur permettre de mettre à jour leur système. Ainsi «Cfengine» permet, tout comme le permettait «Majax», une centralisation des configurations, et efface une faiblesse de «Majax» : la dépendance au service «NFS». En effet, «Cfengine» utilise la pile TCP/IP afin d assurer les communications entre les clients et le serveur qui, nous le verrons plus loin, exécute un binaire spécifique pour recevoir et répondre aux requêtes issues des clients. 3.3.2.1. Les binaires. Contrairement à «Majax» qui utilise des scripts «Perl» pour son exécution, «Cfengine» nécessite une phase de compilation de son code source pour être exploitable sous la forme de binaires. Ainsi on retrouve en fin de compilation un certain nombre de binaires dont je ne détaillerai que le fonctionnement des principaux. Ces derniers sont présents, selon les distributions, dans les répertoires «/usr/local/sbin» ou «/usr/cfengine/sbin». - «cfagent» : C est le binaire de la partie cliente. Il est indispensable puisque c est lui qui est chargé de lire les différents fichiers de configuration et d ensuite exécuter les tâches qui y sont dictées. Dans un premier temps, le binaire «cfagent» lit le fichier de configuration «update.conf», et exécute les tâches programmées. Ensuite «cfagent» recherche le fichier «cfagent.conf» afin d exécuter les tâches de mise à jour du système. Plus loin dans ce document seront expliqués les différents fichiers de configuration utilisés. L autre avantage vis-à-vis de l utilisation de binaires, évoquée plus haut, réside au niveau des options fournies pour l exécution de ces derniers. En effet au total plus d une vingtaine d options sont disponibles pour «cfagent» dont les options de «debug» (-d1 à 4) permettant de comprendre l origine d une erreur au sein d une action avec un niveau de détails réglable. L option «-p» permet, quant à elle, de n exécuter aucune action et d uniquement
10 GNU/Cfengine. Volume 2 n 2/2004 «parser» les fichiers de configuration. Cette dernière option est très utile pour par exemple comprendre quelles sont les actions qui peuvent être exécutées et cela de manière beaucoup plus rapide que lors du passage par le mode «debug». Bien entendu toutes les options sont utilisables simultanément. - «cfservd» : C est le binaire constitutif de la partie serveur. Ce dernier est le serveur sur lequel les clients se connectent lors de la phase de récupération des fichiers de configuration. Son comportement est dicté par le fichier de configuration «cfservd.conf». Pour la communication «Cfengine» utilise le port 5308, comme spécifié dans le fichier «/etc/services». Tout comme le binaire «cfagent» ce binaire serveur possède un certain nombre d options, dont toujours le mode «debug» très utile pour comprendre les raisons de l échec d une connexion. - «cfkey» : Le binaire «cfkey», est utilisé lors de l initialisation de «Cfengine» pour générer le couple de clés (privé/publique) nécessaire à l authentification des machines vers le serveur lors des phases de communication. Le mécanisme de sécurité employé dans «Cfengine» est la cryptographie à clé publique RSA. Dans ce système, la clé publique est utilisée pour chiffrer les données transmises tandis que la clé privée a pour rôle de permettre le déchiffrement des informations reçues. Les clés utilisées par «Cfengine» sont stockées sous «/var/cfengine/ppkeys/». - «cfrun» : Le binaire «cfrun» permet un mode particulier d exécution du binaire «cfagent». Typiquement le binaire «cfagent» est lancé périodiquement. «Cfrun» se propose quant à lui de permettre à un administrateur de lancer le binaire «cfagent» à la demande pour, par exemple, effectuer une mise à jour urgente sur un poste client particulier. Pour se faire le binaire «cfrun» doit être présent sur une station pilote, laquelle va alors s adresser à la station cliente par l intermédiaire du binaire «cfservd» exécuté sur cette dernière. Ce binaire «cfservd» est configuré de telle sorte à comprendre la requête qu il reçoit du «cfrun» afin d exécuter le «cfagent». La force supplémentaire du binaire «cfrun» réside au niveau du retour d information. En effet la sortie générée par l exécution du «cfagent» de la machine cliente apparaît directement sur la console de la machine pilote. Ainsi «cfrun» permet l exécution de «cfagents» distants tout en redirigeant la sortie de ces derniers sur la machine pilote. - Les autres binaires : Les binaires exposés précédemment sont les outils permettant de réaliser les tâches d administration, excepté «cfkey». Autour de ces binaires ont été développés des outils tel que «cfexecd». Ce binaire est en fait une sorte de superviseur. Il est chargé de lancer périodiquement le «cfagent» conformément aux paramètres systèmes spécifiés au sein des fichiers de configuration «update.conf» ou «cfagent.conf». Il permet également l envoie de mails automatiques à l administrateur du site (reflété par la variable «sysadm»). Au côté de ce binaire de «scheduling», on trouve l outil statistique «cfenvd» qui va permettre la, théorique, détection d anomalies. Ce dernier est accompagné du binaire «cfenvgraph»
Administration Automatique Linux 11 permettant la réalisation de graphiques à partir des données générées par «cfenvd». Cependant le manque de documentation sur ces deux derniers outils est totalement préjudiciable à leur utilisation dans un environnement de production. Tous ces binaires confèrent à l outil «Cfengine» une force de fonctionnement et une fiabilité importante. Cela est d autant plus vrai au vu du suivi important apporté par Mark Burgess. En effet ce dernier est très présent au sein de la liste d aide dédié au système et effectue de nombreuses mises à jour, pas seulement pour combler d éventuels bugs de fonctionnement (très rares), mais aussi pour procéder à l ajout de nouvelles fonctionnalités. Ces dernières sont essentiellement de nouvelles possibilités d actions qui vont pouvoir être ajoutées au sein des fichiers de configuration. 3.3.2.2. Les fichiers de configuration. Les binaires exposés ci-dessus nécessitent des configurations afin de pouvoir être exécutés. Ces configurations se retrouvent sous forme de fichiers dans les systèmes «Linux» et sont stockées au niveau du répertoire «/var/cfengine/inputs». - «update.conf» : Ce fichier est utilisé par le «cfagent». «update.conf» possède comme son nom l indique un rôle de mise à jour, mais ce rôle est dévolu à «Cfengine» lui-même. En effet «update.conf» est le premier fichier de configuration qui est lu par «cfagent». Afin d utiliser l architecture client-serveur de «Cfengine», «update.conf» est utilisé pour rapatrier, depuis le serveur de configuration, les fichiers de configuration qui conviennent à la station cliente qui exécute le «cfagent». Ainsi au sein de ce fichier on retrouve les actions suivantes : - mise à jour du fichier de configuration «cfagent.conf». - rapatriement de la configuration «Cfengine» adaptée (cf. 4.2). - vérification des permissions sur les répertoires de travail de «Cfengine». De cette manière, le fichier «update.conf» est le seul fichier nécessaire pour initier le fonctionnement de la partie client de «Cfengine». En effet ce fichier de configuration permet de récupérer tous les fichiers qui seront nécessaires à l exécution des tâches d administration. De part cette fonction, il est impératif de conserver un «update.conf» simple et fonctionnel. En effet, la distribution d un tel fichier, avec des erreurs de programmation peut entraîner la perte de la main sur la ou les machine(s) cliente(s) affectée(s). - «cfagent.conf» : C est le second fichier qui est utilisé par «cfagent». On l a compris à travers l explication du rôle de l «update.conf», ce fichier de configuration est téléchargé depuis le serveur de configuration. Ce fichier a pour rôle de dicter au «cfagent» les tâches qu il va devoir réaliser. Ainsi de manière plus ou moins directe (cf. 3.3.3 «import»), on va retrouver dans ce fichier les actions typiques d administration réalisées par «Majax» telles que les copies, les suppressions de fichiers, etc. Les fonctionnalités de «Cfengine» sont évoquées plus loin dans ce document.
12 GNU/Cfengine. Volume 2 n 2/2004 - «cfservd.conf» : Ce fichier représente la configuration du serveur «Cfengine». On va ainsi y spécifier les hôtes autorisés, les hôtes pouvant distribuer les clés, on y déclare également les droits d accès aux différents répertoires. Par exemple une machine cliente doit pouvoir accéder au répertoire «/var/cfengine/inputs/» du serveur de configuration afin d y récupérer ses fichiers de configuration conformément aux instructions qui sont décrites au sein du fichier «update.conf» de la machine cliente. - «cfrun.hosts» : Ce fichier de configuration est uniquement présent sur la machine pilote, c est à dire celle qui exécute le binaire «cfrun» pour obtenir une exécution distante et à la demande d un «cfagent» sur une machine cliente. Au sein de ce fichier sont listées les machines visées par l exécution à la demande. Ce fichier est également utilisé pour savoir ce que la station pilote doit faire de la sortie qu elle récupère à partir de l exécution d un «cfagent» distant. Ainsi il est possible de placer la sortie soit directement sur la console, soit de «logger» tous les retours d informations au niveau d un fichier qui sera alors nommé en fonction du nom de la machine ayant été contactée. Ce fichier de «log» est donc stocké sur la machine pilote. Figure 1. Mode de fonctionnement de "Cfengine". Tous ces fichiers de configuration confèrent à «Cfengine» une totale adaptation aux exigences fonctionnelles imposées par l architecture système du LORIA. Le meilleur exemple de cette adaptation est représentée par le paramètre système «hostnamekeys». En effet, tous les clients connectés au domaine «loria.fr» obtiennent de façon dynamique une adresse Ipv4. Or on la vu plus tôt dans ce document, le système client-serveur impose à «Cfengine» l utilisation de clés
Administration Automatique Linux 13 (privé/publique) afin d authentifier les clients. Par défaut les clés publiques sont échangées entre le client et le serveur, et sont stockées sur chacun avec un nom basé sur les adresses Ipv4. Cela pose alors un problème lors d une éventuelle nouvelle affectation d adresse Ipv4 par le DHCP. Le paramètre «hostnamekeys» se propose alors de nommer les clés publiques échangées en fonction du nom d hôte complet de la machine représentant cette clé. Ainsi au lieu de posséder une clé publique cliente nommée «root-152.81.8.173.pub» cette dernière se nommera «rootarcey.loria.fr.pub». Bien entendu Le protocole Ipv4 n est pas le seul supporté par «Cfengine». Ainsi cet outil d administration automatique est tout à fait capable de s adapter à un environnement réseau à base d Ipv6 gage d une pérennité dans le temps. 3.3.2.3. Le langage. L autre avantage très important de «Cfengine» se situe dans le langage utilisé pour déclarer les actions que l administrateur doit réaliser. En effet «Cfengine» repose sur un langage déclaratif de haut niveau possédant, à travers un système de classes, une orientation objet très appréciée actuellement. Tous les fichiers de configuration cités ci-dessus à l exception de «cfrun.hosts», qui se résume à une liste de machines, reposent sur ce langage déclaratif. Ainsi un fichier de configuration du type «cfagent.conf» se voit tout d abord découpé en différents «action-types». Ces «action-types» sont en fait les différents types d actions que «Cfengine» peut réaliser. Un inventaire des principales fonctions est documenté plus loin dans cet exposé. Au sein de chaque «action-type» l on retrouve des actions organisées autour d un système de classe. Une classe est en fait une variable système interne à «Cfengine» qui est vrai ou fausse sous certaines conditions. Ainsi la classe «cfengine_2_1_9» est positionnée à vrai si la version du binaire «cfagent» est la 2.1.9. On préférera parler alors de classe activée ou définie. Il existe plusieurs types de classes. On trouve ainsi des classes systèmes qui sont définies par le cfagent lui-même avant d avoir lu le premier fichier «update.conf». Ces classes systèmes sont ici appelées des classes matérielles puisqu elles reposent essentiellement sur les caractéristiques matérielles et systèmes. Ces classes matérielles sont composées par les classes relatives à la date et l heure, les classes issues des caractéristiques réseau (IP, nom d hôte, ), ainsi que des classes permettant d identifier quel est le système d exploitation exécuté localement (depuis la version 2.1.10). En quelque sorte, les classes matérielles représentent des classes par défaut. Au coté de ces dernières, l administrateur peut définir des classes utilisateurs et ce de plusieurs manières différentes : - par combinaison des classes matérielles. Typiquement ce système est utilisé pour identifier les serveurs au sein des configurations «Cfengine» du LORIA. serveur = ( loria1 loria2 ) ce qui signifie que pour que la classe serveur soit définie, il faut que le «cfagent» soit exécuté soit sur la machine loria1 soit sur la seconde machine loria2. - par déclaration explicite, en indiquant l appartenance de telle machine à telle classe. Cela est rendu possible par la variable système «AddClasses».
14 GNU/Cfengine. Volume 2 n 2/2004 AddClasses = MA_CLASSE - les classes utilisateurs peuvent également résulter de l exécution de commandes «shell». Pour valider une telle classe, «cfengine» se base sur le statut de retour consultable après n importe quelle commande «shell» par «echo $?». Ainsi si le statut de retour est égal à 0, cela signifie que la réponse à la commande «shell» exécutée est positive, et engendre la validation de la classe ainsi déclarée. Dans tous les autres cas la classe n est pas validée. Ce système d affectation de classe est très utile pour définir si par exemple un fichier spécifique est présent sur le système. SHADOW = ( "/usr/bin/test -f /etc/shadow" ) Ainsi la classe SHADOW se verra activée si le fichier «/etc/shadow» est présent sur le système. - enfin il est possible de définir des classes utilisateurs par retour d action, c est à dire que si une action se déroule correctement alors la classe spécifiée au sein d un paramètre approprié (généralement «define») se voit alors validée. L inverse est également possible, c est à dire que si l action entreprise ne se déroule pas correctement alors le paramètre «elsedefine» permet de valider une classe utilisateur identifiant ainsi l action n ayant pas été réalisée correctement. Toutes ces possibilités offertes par le langage déclaratif de «Cfengine» associées au nombre important d «action-types», donne une puissance de traitement importante à ce système d administration. 3.3.3. Fonctionnalités. On l a vu précédemment le langage employé par «Cfengine» permet à travers le système de classes de programmer très finement les actions à exécuter. Ces actions représentées par les «action-types» sont nombreuses : au total 33 «action-types» différents. Faisons un tour d horizon des actions les plus importantes pouvant être entreprises au sein des fichiers de configuration de «Cfengine». - «groups» : A l exécution de «cfagent», des classes matérielles sont déclarées. Or on a vu, dans le paragraphe concernant le langage, que l administrateur avait le loisir de créer des classes utilisateurs. A travers l «action-type groups», l administrateur va pouvoir déclarer ces nouvelles classes soit par la combinaison de classes matérielles, soit par l exécution de commandes «shell». Ces classes seront alors construites après la lecture des fichiers de configuration par le «cfagent» avant d exécuter les autres actions. - «control» : Cet «action-type» est utilisé pour définir des variables. Les variables déclarées peuvent être de type système ou alors de type utilisateur. Une variable système modifiera le comportement lors de l exécution du «cfagent». Le meilleur exemple en est la variable «actionsequence» qui défini l ordre dans lequel le différents «action-types» doivent être réalisés. Une variable utilisateur peut être par exemple un path ou plus généralement une chaîne de caractère utilisée par la suite dans les différentes actions. De plus, une variable utilisateur est définie automatiquement par
Administration Automatique Linux 15 «Cfengine» dans un contexte. Ainsi une variable décrite dans le fichier «update.conf» appartient au contexte «update». Une variable décrite au sein du fichier «cfagent.conf» appartient au contexte «main». Enfin les variables systèmes appartiennent toutes au contexte «global». L utilisation de contexte permet la redéfinition de variable entre la phase de mise à jour des configurations de «Cfengine» sur le client, et la phase d exécution des tâches d administration. - «shellcommands» : L «action-type shellcommands» va permettre d exécuter des commandes «shell» sur la machine locale. Par l intermédiaire de cette action, l exécution de scripts est possible. - «copy» : L «action-type copy» va permettre la copie de fichiers. C est cette action qui permet de récupérer le fichier «cfagent.conf» sur le serveur de configuration à partir de l exécution des instructions du fichier «update.conf» local. Une option importante dans le cas de copie distante est l option «trustkey» qui va permettre de partager les clés publiques des machines et d ainsi éviter leur copie manuelle sur le serveur et la copie de la clé publique du serveur sur chaque machine cliente. Au cours d une copie il est possible de spécifier les permissions, le propriétaire, le groupe, sur le fichier transporté. Le paramètre «type» va quant à lui permettre de spécifier s il faut copier le fichier. Pour se faire il peut se baser sur différents critères : date, checksum (MD5), comparaison bit à bit. Beaucoup d autres paramètres sont disponibles afin d affiner cette action de copie : au total 36 options. - «editfiles» : Cette action est parmi les plus puissante proposée par «Cfengine». En effet souvent l édition de fichier est synonyme de scripts lourds pour arriver au résultat désiré. Ici tout est géré par des options qu il suffit de choisir et de configurer. Par exemple il est possible de supprimer des lignes selon leur contenu. On peut également depuis la version 2.1.7 de «Cfengine» remplacer uniquement la première occurrence d une chaîne au sein d une ligne, par une autre chaîne. Au total, l action «editfiles» regroupe plus d une centaine d options ce qui permet de réaliser la totalité des modifications de fichiers de configuration (/etc, ) dans un environnement «Unix». - «files» et «directories»: L «action-type files» est utilisé dans le cadre de la création de fichiers. Il permet ainsi de créer un fichier en lui appliquant les permissions et autres propriétés systèmes utiles sur un «OS Unix». Cette action peut également être utilisée afin de vérifier les propriétés des fichiers, et d ainsi maintenir ces dernières. On peut par exemple citer une utilisation sur le fichier «/etc/passwd» qui ne doit bien entendu ne pas être modifié par tout à chacun. Ainsi Cfengine réalise l équivalent du script «setdroit.pl» qui était utilisé sous «Majax» pour réaliser cette tâche, mais y ajoute beaucoup d option : notamment la possibilité d appliquer des filtres afin de correctement situer les fichiers. Cela permet d éviter d avoir à spécifier une longue liste de fichiers dans cette action. L «action-type directories» est un dérivé de
16 GNU/Cfengine. Volume 2 n 2/2004 «files» qui ne s applique qu aux répertoires alors que «files» s applique à la fois aux fichiers et aux répertoires. - «links» : Cet «action-type» va permettre la création de liens symboliques. «Links» se propose de créer des liens simples, mais aussi des liens multiples (tous les fichiers d un directory donné sont liés) - «tidy» : Comme il est possible de créer des fichiers et des répertoires, il est également possible d en supprimer grâce à cet «action-type». - «processes» : Cet «action-type» se propose d effectuer des opérations sur les processus. Ainsi un processus peut être stoppé. Une fois stoppé il est redémarré par le biais de l option «restart». Le paramètre passé à «restart» est une commande «shell». Cependant une option de sécurité de «processes» vise à éviter l utilisation du «shell» pour redémarrer un processus. Il est alors impossible de démarrer un processus par une commande «shell» comportant des options puisque ces dernières ne seront pas prises en compte. - «filters» : Comme son nom l indique, «filters» est un «action-type» qui va permettre la création de filtres. Les filtres ainsi créés pourront être utilisés dans des actions de copies pour isoler certains fichiers Les filtres peuvent être basés, sur le propriétaire, le groupe, les permissions, mais aussi des intervalles de dates, de tailles de fichiers Les filtres peuvent être utilisés dans les «action-types» suivants : «copy, editfiles, files, tidy, processes». - «disable» : Cet avant dernière action représente pour «Cfengine» l opportunité de renommer les fichiers. - «import» : Cet «action-type» représente la meilleure façon de structurer une configuration «Cfengine» à travers différents fichiers. En effet «import» permet d ajouter des fichiers de configuration à un premier fichier «cfagent.conf» ou plus généralement à un fichier de configuration «Cfengine». C est en quelque sorte une action qui permet d imbriquer des fichiers. Les fichiers de configuration ajoutés reposent sur la même structure que «cfagent.conf» ou «update.conf». Ainsi la configuration «Cfengine» d un poste client, gagne beaucoup en clarté, et sera d autant plus simple à comprendre et à faire évoluer. On le voit à travers ce bref inventaire des principales actions possibles au sein de «Cfengine», cet outil d administration va beaucoup plus loin que «Majax» en matière d exécution de tâches, et ce même pour une simple action de copie (au vu du nombre impressionnant de paramètres disponibles pour régler cette dernière). La puissance fonctionnelle de «Cfengine» n est pas uniquement due au nombre important d actions disponibles mais aussi au mécanisme de classes conférant une
Administration Automatique Linux 17 orientation objet au système, ce qui permet une souplesse de fonctionnement à travers la multitude de cas pouvant être gérés. 3.3.4. Exemples d applications. 3.3.4.1. Modification du mot de passe «root» du site. La modification de mot de passe «root» est une opération précédemment réalisée à travers le script «passwd.pl» sous «Majax». Je propose ici de réaliser cette action par l intermédiaire de «Cfengine» et d ainsi présenter la méthode d analyse conduisant à l écriture du fichier de configuration «Cfengine» qui réalisera cette modification. Sous les systèmes «Linux» («Mandrake» et «Red Hat»), la gestion des mots de passe utilisateur se fait par le fichier «/etc/passwd» mais également par «/etc/shadow» dans le cas de l emploi du «shadowing». Cette technique est utilisée afin de combler une lacune de sécurité des systèmes «Linux». En effet sur ces derniers, le fichier «/etc/passwd» est disponible en lecture pour tous les utilisateurs. Ainsi n importe qui peut se procurer les «hashs» des mots de passe des utilisateurs contenus dans ce fichier. Le «shadowing» est une technique permettant de palier cette faiblesse afin de ne plus stocker les «hashs» des mots de passe dans «/etc/passwd» mais dans «/etc/shadow» qui lui est un fichier uniquement lisible par l utilisateur «root». Ainsi la procédure du changement de mot de passe devra prendre en compte les deux fichiers, et savoir faire la distinction entre les systèmes possédant du «shadowing» et ceux en étant dépourvus. La première action à réaliser est de créer un fichier de configuration «Cfengine» qui sera spécifique à cette procédure. La configuration ainsi créée sera ensuite ajoutée à la configuration «Cfengine» à travers l «action-type import» au sein du fichier «cfagent.conf». La procédure de changement de mot de passe root, comporte pour sa part dans un premier temps quelques définitions de classes : l appartenance à un système utilisant du «shadowing», l identification des systèmes ayant déjà subi la modification de mot de passe root et enfin une classe étant définie lorsqu une machine possède un compte root local (rootl) c est à dire un deuxième compte root lorsque l utilisateur de la machine demande au service des Moyens Informatiques de pouvoir administrer lui-même sa machine. Ensuite l «action-type control» va nous permettre de déclarer deux variables : l ancien «hash» et le nouveau «hash» du mot de passe root. La modification du hash du mot de passe root consiste à éditer les fichiers concernés pour y modifier le «hash» du compte «root». L «action-type editfiles» est tout à fait approprié pour réaliser de telles actions. Enfin et afin de s assurer que les modifications ont correctement été effectuées, l utilisation de la définition de classes utilisateur par le retour d action au niveau des différentes actions d édition permet d activer des classes en cours d exécution. Ces dernières seront ensuite utilisées au niveau de l «action-type shellcommands» afin de générer une sortie claire à partir de commandes «/bin/echo». Ainsi la procédure de changement de mot de passe root, prends à la fois en considération les machines possédant du «shadowing» et celle en étant dépourvues tout en tenant compte des différents comptes «root» étant disponibles sur la machine cliente.
18 GNU/Cfengine. Volume 2 n 2/2004 3.3.4.2. Déploiement de nouveaux outils. A la suite d une panne réseau survenu dans la nuit du mardi 3 août, il m a été demandé d étudier la faisabilité du déploiement d outils de capture réseau, tels que «ethereal» et «tcpdump», sur l ensemble des machines Linux gérées par les Moyens Informatiques. «Cfengine» est tout à fait capable de réaliser ce type de tâches. Ainsi les systèmes n étant pas pourvus de ces utilitaires se voient fournir les packages RPM adaptés à la distribution de la machine cliente (Mandrake 8.1, 9.0, 9.2 uniquement) et ce grâce à l action «copy». Ces packages sont copiés dans un coin de la partition «root» et sont ensuite installés par l intermédiaire de commandes «shell» sous l «action-type shellcommands». Enfin lorsque les packages sont correctement installés, «Cfengine» se charge de nettoyer les packages, qui ont été copiés sur le système, par l intermédiaire de l «action-type tidy». De la même manière que la modification du mot de passe «root», le déploiement de ces outils fait l objet d un fichier de configuration particulier qui est inclus à la configuration «Cfengine» par l intermédiaire de l «action-type import» sous le fichier «cfagent.conf». «Cfengine» montre ici l étendue de ces possibilités, et représente une formidable plate-forme de déploiement pour les futures évolutions systèmes au LORIA. On l a vu tout au long de cette partie le champ d action de «Cfengine» couvre tous les domaines de l administration et offre un panel d actions conséquent pouvant être configurées très finement à travers le mécanisme des classes fourni par l outil. En cela «Cfengine» remplace «Majax» très avantageusement en apportant une sûreté de fonctionnement et une totale indépendance vis à vis du service «NFS». Bien entendu une panne au niveau du serveur de configuration n est pas impossible même si ce dernier est également administré par «Cfengine» et qu il est configuré afin de détecter d éventuelles pannes et de réagir en conséquence. Cependant une panne au niveau du serveur entraînera tout au plus l impossibilité pour les clients de mettre à jour leur configuration «Cfengine» stockées en local. Ainsi les tâches dictées au sein des configurations «Cfengine», locales, seront toujours réalisées! Ce mode de fonctionnement comparé à celui de «Majax» montre la force de l architecture client-serveur choisie. Cette étude réalisée au cours des deux premiers mois de stage, a donné lieu à un premier exposé technique devant tous les membres du service des Moyens Informatiques (techniciens et ingénieurs confondus), afin de convaincre l équipe de la puissance de ce nouvel outil. A la suite de cet exposé il a été décidé de déclencher le déploiement de «Cfengine» et d ainsi commencer la mise en production de l outil. 4. Mise en production. La question de la mise en production de «Cfengine» pose de nombreux problèmes. Comment déployer l outil de façon à toucher l ensemble des machines gérées? Comment prendre en compte dans ce déploiement les différentes distributions présentes sur le parc machine du LORIA? Comment contrôler
Administration Automatique Linux 19 l évolution de ce déploiement? Cette partie va répondre à l ensemble de ces questions, et présentera les configurations Cfengine actuellement mises en place au LORIA. Enfin j évoquerai les étapes d améliorations et de fiabilisation passées et futures. 4.1. Déploiement. Comment déployer un nouvel outil sur un parc hétérogène de machines lorsque que l on ne dispose pas d un outil de déploiement tel que «Cfengine»? Deux cas doivent être pris en considération : tout d abord les machines déjà installées, et ensuite les machines nouvellement installées (en terme de systèmes d exploitation). 4.1.1. Installation sur le parc actuel. Tout d abord il a été nécessaire de scripter l installation de «Cfengine» sur un poste «Linux». Pour ce faire différents scripts ont été écrits afin de prendre en compte les cas présents sur le site, mais aussi afin de réaliser les tâches nécessaires à l activation du fonctionnement de la partie cliente de «Cfengine», puisque seule cette dernière est déployée sur l ensemble des clients. Ainsi le minimum nécessaire au fonctionnement du système est déployé, afin d obtenir une procédure de déploiement rapide à exécuter et ne présentant pas d obstacles majeurs. Si par la suite de nouveaux outils tel que «cfrun» devaient être déployés, il suffirait alors d écrire les configurations «Cfengine» adaptées afin de procéder à ces évolutions. Ainsi les scripts d installation de «Cfengine» réalisent les étapes suivantes : - installation des outils et librairies nécessaires à l exécution du «cfagent» à savoir le logiciel OpenSSL, et la librairie Berkeley «libdb-4.2.so». - modification du fichier «/etc/ld.so.conf» afin d assurer la prise en compte des nouvelles librairies installées. - installation des binaires «cfagent» et «cfkey». Les binaires sont préalablement générés par la compilation des sources sur les différentes distributions, ce qui évite de compiler les sources sur chaque machine nouvellement installée. - génération de la paire de clés (prive/publique) nécessaires pour l authentification du client sur le serveur. - copie du premier fichier «update.conf» sous le répertoire «/var/cfengine/intputs». - programmation de la «crontab» de l utilisateur «root» afin d obtenir une exécution récurrente du «cfagent». Cette dernière est programmée toute les demiheure. Une question se pose alors au niveau de la charge générée sur le serveur, puisque tous les clients se déclenchent en même temps. La réponse réside au niveau de la variable système de «Cfengine» : «SplayTime». Une fois spécifiée au sein du premier fichier lu par le «cfagent» à savoir «update.conf», cette variable va
20 GNU/Cfengine. Volume 2 n 2/2004 générer un temps d attente aléatoire basé sur un «hash» calculé à partir du nom d hôte de la machine. Ainsi aucun client ne se lance en même temps. De plus cette variable se paramètre à l aide d un entier correspondant au temps d attente maximum en minutes. Cette variable permet donc d étaler la charge du serveur sur cet intervalle de temps. - Programmation de l exécution du «cfagent» au boot de la machine à travers le fichier «/etc/rc.d/rc.local». Cela permet d exécuter un «cfagent» dès le démarrage de la machine afin d assurer une mise à jour des clients ne s étant pas connectés au domaine «loria.fr» depuis quelques temps. Le lancement de ce «cfagent» se fait en utilisant une option spécifique permettant de ne pas prendre en compte la variable «SplayTime» afin de ne pas bloquer la machine au boot et ce pour un temps certes défini mais pouvant aller jusqu à 24 minutes dans l état actuel. Après l exécution de ces différentes étapes, le binaire «cfagent» peut être lancé. La machine est alors administrée par «Cfengine»! Cependant il est bien entendu hors de question de passé manuellement sur toutes les machines afin d y exécuter un quelconque script. Ce déploiement doit se faire de manière automatique, et transparente pour l utilisateur de la machine visée. Ainsi il a été décidé d utiliser une possibilité offerte par l outil d administration automatique en place : «Majax». Le nouvel outil utilise alors l ancien pour le remplacer! En effet parmi les actions possibles au sein de «Majax» figure l exécution de script. Ainsi il suffit de configurer le fichier «.majaxrc» de «Majax» afin d assurer l exécution de notre script de déploiement. * :::ostype=linux :install_cfengine De multiples tâches de contrôle ont été ajoutées au script d installation de «Cfengine». De plus la structure scriptée de l installation n est pas constituée d un seul script mais de plusieurs petits scripts facilitant d autant la tâche de l administrateur lors de la modification de cette procédure. Ainsi on retrouve le script lancé par «Majax» qui contrôle la présence sur la machine de «Cfengine» et qui lance, si besoin est, l installation de ce dernier par l appel à d autres scripts gérant entre autre les différentes distributions. En fin d installation, le script lancée par «Majax» effectue une vérification de fonctionnement du «cfagent» local par l intermédiaire du statut de retour de la commande «cfagent p» (mode parse only). Cette vérification donne lieu à l établissement de listes créées sur le serveur «Cfengine» par l intermédiaire d un «remote shell». On retrouve ainsi une liste comprenant les machines correctement installées et fonctionnelles ainsi qu une liste de machines dont l installation a échoué. Ce mode de fonctionnement utilisé pour le déploiement de «Cfengine» nous a permis de rapidement toucher plus de 200 machines «Linux» sur le réseau. Cependant le déploiement de «Cfengine» ne se fait pas uniquement à travers les machines déjà en place mais aussi sur les machines nouvellement installées. Le paragraphe suivant va détailler le fonctionnement de cette installation, particulière, des machines «Linux Mandrake».