GNU/Cfengine. Administration Automatique Linux. Sébastien Bègue. : Jean-Claude Giese

Transcription

1 GNU/Cfengine Administration Automatique Linux Sébastien Bègue Encadrant Cellule Membre : Benjamin Dexheimer : SysLog : Jean-Claude Giese LORIA CAMPUS Scientifique BP 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 2 GNU/Cfengine. Volume 2 n 2/2004 SOMMAIRE 1. INTRODUCTION PRESENTATION LORIA Le service des Moyens Informatiques (MI) Place occupée au sein du service LA MISSION DE STAGE L ADMINISTRATION AUTOMATIQUE DEFINITION ET ENJEUX L EXISTANT Majax Mode de fonctionnement Fonctionnalités Exemples d applications L EVOLUTION Cfengine Mode de fonctionnement Les binaires Les fichiers de configuration Le langage Fonctionnalités Exemples d applications Modification du mot de passe «root» du site Déploiement de nouveaux outils MISE EN PRODUCTION DEPLOIEMENT Installation sur le parc actuel Les nouvelles machines : post-installation LES CONFIGURATIONS «CFENGINE» La configuration «client» La configuration «serveur» Les configurations de tests La configuration de post-installation AMELIORATIONS ET FIABILISATIONS TRANSMISSION DES CONNAISSANCES DOCUMENTATION DES MOYENS INFORMATIQUES (DOCMI) INITIATION DES PERSONNELS PERMANENTS CONCLUSION BIBLIOGRAPHIE....29

3 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 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 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 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 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 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

5 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 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 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 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 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é Majax. «Majax» (Mise A Jour AutomatiX) est un système développé par les Moyens Informatiques eux-mêmes en 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 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 à

7 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 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 8 GNU/Cfengine. Volume 2 n 2/ 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» 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 à

9 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» 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 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 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 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»

11 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 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 «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 12 GNU/Cfengine. Volume 2 n 2/ «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

13 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 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 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 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 ). 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 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 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

15 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 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 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

17 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 Exemples d applications 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 18 GNU/Cfengine. Volume 2 n 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

19 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 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) 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 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».

21 Les nouvelles machines : post-installation. Administration Automatique Linux 21 Le service des Moyens Informatiques prend en charge l installation des systèmes d exploitation sur les machines. Ainsi un utilisateur peut se présenter au service et demander de disposer d une distribution «Linux» sur son ordinateur. Les MIs proposent alors à l utilisateur de lui faire bénéficier d une distribution «Mandrake». Actuellement la version installée est la 9.2, mais très prochainement cela va évoluer vers la nouvelle distribution officielle : 10.0 (dont bénéficie dès à présent le serveur «Cfengine»). Le service des Moyens Informatiques supporte alors un certain nombre de machines, lesquelles se voient installées d une manière spécifique. Cela commence par la mise à jour de la base de données des Moyens Informatiques (BDMI) afin d y faire figurer la nouvelle machine et de lui permettre d accéder au réseau du LORIA. Ensuite L installation de la machine débute par un boot de cette dernière sur le réseau. La machine obtient alors en premier lieu son IPv4 par l intermédiaire du DHCP et utilise ensuite le système «PXE Linux» pour rechercher un fichier de boot. Ce fichier de boot est rapatrié sur la machine via TFTP, et contient l ensemble des options de boot permettant ainsi à l installateur de choisir quelles sont les caractéristiques réseau à prendre en compte. En effet le système impose de dissocier la machine possédant une carte 100 mbits de la machine dotée d une carte gigabit. Il est également possible de choisir une installation interactive permettant à l utilisateur de partitionner son système comme il le souhaite. Cette étape comporte à présent plus d options pour permettre une phase de postinstallation de la machine totalement gérée par «Cfengine». Une fois une option choisie, le système «Kickstart» est alors utilisé pour installer la distribution «Linux Mandrake». Cette installation automatique permet une fois lancée de quitter le pc, et de n avoir aucune intervention spécifique à réaliser, jusqu à la phase de postinstallation spécifique aux machines gérées par les Mis. Le système «Kickstart» après avoir installés tour à tour les différents packages de la distribution, possède une section post-installation. Cette section permet à l administrateur de spécifier un certain nombre d actions à effectuer en fin d installation. Nous utilisons alors cette possibilité pour installer «Cfengine» sur la machine. Cette installation passe par les mêmes scripts que ceux utilisés pour le déploiement par «Majax» mis à par le lanceur qui est adapté au besoin d une installation en phase de post-installation «Kickstart». Auparavant durant cette phase c est le script de post-installation des machines «Linux» qui était lancé. Le but est d à présent ne réaliser que l installation de «Cfengine» durant la phase de post-installation «Kickstart». Ainsi les tâches réalisées auparavant par le script de post-installation seront intégralement assurées via les nouvelles possibilités offertes par l outil d administration automatique. En fin d installation de «Cfengine» le «cfagent» du client dispose du premier fichier de configuration «update.conf» adapté à une phase de post-installation, c'està-dire qu il permet de localiser sur le serveur «Cfengine» les configurations spécifiques nécessaires à la modification du système installé pour rendre le système conforme aux exigences des Moyens Informatiques. Le «cfagent» est alors exécuté et va rapatrier par l intermédiaire des instructions contenues dans l «update.conf»

22 22 GNU/Cfengine. Volume 2 n 2/2004 l ensemble des fichiers de configuration nécessaires sur la machine locale. Ensuite le «cfagent» exécute les directives données dans ces fichiers. Mais avant d aller plus loin l installateur doit sélectionner par l intermédiaire de plusieurs petits menus, un ensemble de caractéristiques permettant de tenir compte de plusieurs caractéristiques non détectables de manière automatique (ordianteur portable ou de bureau, modèle d ordinateur, ). Ensuite «Cfengine» prend en compte ces caractéristiques à travers un ensemble de classes construites grâce à ces menus, effectue les tâches demandées, et permet d obtenir au final une post-installation se terminant par un reboot de la machine. Après vérification par l installateur du fonctionnement de la machine, cette dernière est prête à être livrée à son utilisateur et est administrée par «Cfengine»! Le suivi des machines correctement installées est assuré, tout comme l installation par «Majax», grâce à un système de listes sur le serveur, qui sont mise à jour par l intermédiaire d un «remote shell». Ces deux modes d installation de «Cfengine» nous permettent dès à présent de toucher 261 machines sur le réseau du LORIA. Cela représente un bon résultat au vu de la liste de machines potentiellement atteignables, qui nous donne un chiffre de 278 machines gérées par les Moyens Informatiques et fonctionnant sous une des distributions «Linux» maintenue par le service. Cela représente un taux de déploiement proche de 94%. Ainsi seules 17 machines ne sont encore pas passées sous le système d administration automatique «Cfengine». Cela peut s expliquer de différentes manières : - Utilisateurs absents. - Changement de système d exploitation : Windows. - Ordinateur débranché du réseau. La mise en production de l outil «Cfengine» a débuté au mois de mai et se poursuit toujours. L outil est actuellement utilisé pour réaliser les nouvelles tâches d administration. Pour exécuter ces dernières, et fiabiliser le fonctionnement de l ensemble des clients, la configuration «Cfengine» du même nom a été mise en place Les configurations «Cfengine». On a vu tout au long de la partie consacrée à l étude de l évolution, que «Cfengine» utilise un ensemble de fichier de configuration pour réaliser les tâches d administration. Ces fichiers de configuration peuvent alors être structurés par l intermédiaire de l «action-type import» permettant d imbriquer les fichiers et d ainsi obtenir une configuration plus claire. Cela nous a également permis de créer différentes configurations. Toutes ces configurations sont stockées de manière centralisée sur le serveur «Cfengine» sous le répertoire «/var/cfengine/inptus/nom_de_la_configuration».

23 Administration Automatique Linux La configuration «client». La configuration «client» représente l ensemble des fichiers utilisés afin de réaliser les tâches d administration sur les stations clientes. Cette configuration se doit d être une configuration claire, fonctionnelle et ne présentant aucun dysfonctionnement. Tout comme les autres configurations citées ci-dessous, la configuration cliente est structurée autour de trois éléments : - «./cfagent.conf» : le fichier de configuration central d une configuration «Cfengine». - «./base» : représente l arborescence des fichiers de configuration système devant être mis à jour par le «cfagent». Le «cfagent» client recherche le fichier qui lui convient au sein de ce répertoire. - «./scripts» : ce répertoire contient l ensemble des fichiers de configuration nécessaires à «Cfengine» pour une exécution cliente. Tous les fichiers dictant les tâches à réaliser sur le client sont centralisés sous ce répertoire, selon une structure spécifique, permettant une navigation rapide au sein de ces fichiers. De cette manière l on obtient une configuration «client» structurée autour du fichier «cfagent.conf», lequel a pour rôles essentiels de définir des variables systèmes et utilisateurs et d inclure les fichiers de configuration situés au sein de l arborescence «scripts». Au sein de ces nombreux fichiers des actions de copie peuvent être réalisées afin d effectuer des mises à jour. Dans ce cas, ces actions réalisent une connexion au serveur afin de récupérer les fichiers souhaités au sein de l arborescence «base». Typiquement ce mode de fonctionnement est utilisé pour mettre à jour le fichier «update.conf», par exemple lors de la migration de serveur «Cfengine» La configuration «serveur». Cette configuration fonctionne selon le même principe que celle dédiée aux clients. Cependant, tout comme son nom le laisse penser, la configuration serveur est dédiée au serveur «Cfengine». Ainsi le serveur «Cfengine» s administre luimême! Parmi les tâches d administration que le serveur doit réaliser, on peut citer le monitoring sur le service «cfservd» afin de s assurer du fonctionnement permanent de ce dernier. Pour se faire l «action-type processes» est utilisé afin de détecter les éventuels problèmes pouvant engendrer un dysfonctionnement de ce service Les configurations de tests. Bien entendu, avant d insérer de nouveaux fichiers au sein de la configuration «client», il est très fortement recommandé de tester ces derniers sur un petit échantillon de machines. Pour ce faire, un type de configuration particulier a été créé et prend place au sein de «/var/cfengine/inputs/tp_formation/login» sur le serveur «Cfengine». Ainsi chaque membre des Moyens Informatiques dispose d un répertoire étant l exact reflet d une configuration «client» mais dans lequel

24 24 GNU/Cfengine. Volume 2 n 2/2004 l utilisateur va pouvoir effectuer des modifications afin de tester, sur sa machine, ces dernières avant de les propager sur l ensemble des clients La configuration de post-installation. Cette configuration possède une structure légèrement différente de part les fonctions qui lui sont demandées. Cependant fondamentalement le fonctionnement concernant «Cfengine» est identique. La configuration de post-installation est utilisée en phase de post-installation «Kickstart» après l installation de «Cfengine», afin de configurer la station de manière à la rendre conforme aux exigences du réseau LORIA. Actuellement mis en production et utilisé, l outil «Cfengine» représente une forte évolution en terme de fonctionnalités. Cependant au terme de ce stage un certain nombre d évolutions peuvent encore être réalisées Améliorations et fiabilisations. Tout au long de la période de mise en production, l objectif principal a été d obtenir un fonctionnement stable et structuré du nouvel outil, tout en retrouvant quelques aspects pratiques commun avec «Majax». Dans cette optique, les différentes configurations «Cfengine» citées ci-dessus ont été mises en place. Un souci également commun avec «Majax» réside au niveau du système de «log». On l a vu au cours de l analyse de l ancien outil, plus aucun «log» n est généré par ce dernier du fait de la trop grande quantité d informations retenues. Ainsi le système utilisé pour générés les «logs» de «Cfengine» est le suivant : La «crontab root» ainsi que le fichier «/etc/rc.d/rc.local» se voient programmés de manière à rediriger le flux issu de l exécution du «cfagent» vers un fichier de «log» qui est stocké en local et est nommé en fonction du nom d hôte, de l heure et de la date. Cependant ce système se révèle insuffisant puisqu il stocke les «logs» en local. On se retrouve alors dans une impasse lorsqu il faut consulter les «logs». Il est bien entendu hors de question d aller voir sur chaque machine les tâches qui ont été effectuées. Ainsi une évolution a été décidée vers une re-direction des «logs» sur le serveur «Cfengine» lui-même. Pour ce faire on utilise les possibilités offertes par le service «syslog» à travers le démon «syslogd» et le fichier de configuration «/etc/syslog.conf». Cependant le système précédemment cité de «logs» en local est préservé. Pour mener à bien cette évolution, une configuration «Cfengine» a été mise en place pour ajouter cette fonctionnalité à tous les clients. Désormais les clients envoient les informations sur les tâches qu ils réalisent dans le fichier «/var/log/cfengine.log» stocké sur le serveur «Cfengine». Une seconde grande évolution a été apportée : le changement de serveur! En effet jusqu à mi-août le serveur «Cfengine» était hébergé sur une station de travail vieillissante exécutant une «Linux Mandrake 9.0» disposant d un processeur «Pentium III» cadencé à 500 MHz et doté de 256 Mo de RAM. Cela était

25 Administration Automatique Linux 25 insuffisant pour assurer un fonctionnement fiable et durable. A présent les clients s adressent à un serveur digne de ce nom : rack Dell, disposant d un «Intel Xeon» cadencé à 2,8 GHz et doté de 896 Mo de RAM. Ce serveur hébergera prochainement au coté du serveur «Cfengine» le serveur de distribution «Linux» permettant les installations automatiques des postes clients. Enfin le nouveau serveur exécute dès à présent la dernière distribution «Mandrake» officielle : Afin de mener à bien l installation de ce serveur «Cfengine», un script d installation de ce dernier à été réalisé afin de faciliter au maximum la tâche de l administrateur. Ainsi à partir d une sauvegarde du serveur, et des sources des différents logiciels nécessaires, il est possible de restaurer un serveur «Cfengine» fonctionnel en très peu de temps. La migration des clients d un serveur à l autre est réalisée par la mise à jour du fichier «update.conf» des clients. Ainsi rapidement plus de 180 machines ont été migrées vers le nouveau serveur. Ce chiffre n est cependant pas tout à fait satisfaisant puisqu un peu moins de 80 machines n ont toujours pas effectué la migration. Cela est du aux absences actuelles, mais aussi aux départs et autres changements de systèmes. Ce constat impose donc à l administrateur de laisser en fonction l ancien serveur pendant une longue durée afin de s assurer que toutes les machines ont correctement migré. Enfin une dernière opération de fiabilisation du fonctionnement de «Cfengine» a été apportée. Cette dernière a pour but de rendre la mise à jour du fichier «update.conf» d un client volontaire et contrôlée par l administrateur. Ainsi au départ du déploiement ce fichier était mis à jour constamment dès qu une modification y était apportée. Un problème se pose alors lorsque la modification apportée engendre des erreurs d exécution. A présent la mise à jour de l «update.conf» d un client est déclenchée par l administrateur par l activation d un fichier de configuration spécifique au sein du «cfagent.conf». En terme d améliorations futures, un certain nombre de points méritent d être étudiés : - amélioration de la gestion du serveur «Cfengine» : sauvegarde automatique avec stockage sur ressources «NFS», rotation des logs («logrotate»), système d alerte à l administrateur lorsqu une erreur apparaît dans les «logs». - suivi évolué des postes administrés. Actuellement seules des listes basées sur les clés stockées sur le serveur sont réalisées à la demande. Un suivi des clients permettrait également de voir lorsqu une configuration a touché toutes les stations administrées. - utilisation d un logiciel d analyse des «logs» afin de parcourir rapidement et efficacement ces derniers. - déploiement des fonctionnalités apportées par «cfrun». Cela engendre le déploiement sur l ensemble des clients d un binaire «cfservd» configuré de telle sorte à permettre l exécution distante du «cfagent» locale. Il faut également ajouter le monitoring du «cfservd» client dans cette phase. - des modifications structurelles peuvent également être apportées au niveau des configurations «Cfengine». Actuellement les fichiers à inclure sont déclarés au sein

26 26 GNU/Cfengine. Volume 2 n 2/2004 du fichier «cfagent.conf». A court terme beaucoup de fichiers seront sûrement présents au sein de ce fichier. Il serait donc peut-être judicieux de créer un fichier de configuration «Cfengine» intermédiaire entre le «cfagent.conf» et les autres fichiers. - enfin les scripts de déploiement de «Cfengine» peuvent être simplifié pour effacer la gestion actuelle des différents «paths» d installation et ainsi fixer ces derniers au niveau de «/usr». L outil «Cfengine» est donc à présent utilisé par les Moyens Informatiques afin de réaliser les tâches d administration souhaitées. Cependant avant d arriver à ce stade de mise en production et d utilisation, une étape très importante du projet à du être réalisée : la transmission de connaissances aux personnels permanents. 5. Transmission des connaissances. Travaillant de manière totalement autonome durant toute la phase d étude de «Cfengine» puis par la suite au niveau des moyens de déploiement et d évolution du système, il est important d assurer la transmission des connaissances acquises tout au long de cette période de stage. Afin de garantir la réussite de ce transfert deux moyens de communication ont été mis en place entre les ingénieurs et moi-même Documentation des Moyens Informatiques (DocMI). La documentation interne représente le premier support mis en place pour transcrire les différentes étapes du projet dans un format clair et technique. La «DocMI» est en fait un ensemble de pages web, le plus souvent écrites en «HTML» et «PHP» qui permettent aux utilisateurs de disposer d un support d informations touchant tous les domaines couverts par les Moyens Informatiques. Cette documentation possède deux orientations. La première concerne les utilisateurs des services informatiques, à travers les pages «users». Au sein de ces pages l on retrouve tout ce dont l utilisateur a besoin pour utiliser les services fournis par les MIs. Les pages «admin» sont, pour leur part, plus destinée au domaine technique. Ainsi les configurations, les fonctionnements des différents services y sont expliqués à travers une arborescence claire identifiant de multiples domaines. La documentation destinée à «Cfengine» a été créée au sein des pages «admin» sous la rubrique «Linux». Le but de ces pages de la «DocMI» est de présenter les différents aspects touchant au fonctionnement de «Cfengine». Ainsi les thèmes suivants sont abordés : - présentation : «Cfengine», qu est-ce que c est? Qu est-ce que ça fait? Comment c est fait? - installation : comment «Cfengine» est-il déployer sur l ensemble des postes «Linux» gérés par les MIs?

27 Administration Automatique Linux 27 - post-installation : comment arrive t on à gérer la post-installation des distributions «Linux Mandrake» grâce aux fonctionnalités de «Cfengine»? - faire sa configuration : tutorial d explication pour savoir comment faire une configuration «Cfengine», comment la tester, et comment la mettre en place. - passer de «Majax» à «Cfengine» : inventaire des différentes actions réalisées via «Majax» et de leur équivalent traduit dans le langage déclaratif de «Cfengine». - serveur : pour comprendre et savoir modifier l installation d un serveur «Cfengine». - actions : description des principaux «action-types» utilisés. - initiation : cf 5.2. initiation du personnel ingénieur. - package : cette page dynamique permet de visualiser le contenu du package «Cfengine» mis en place. Ainsi il est facile de consulter les différents fichiers qui y sont situé. Toutes ces pages sont organisées autour d un index les présentant, et fournissant un certain nombre de liens vers des informations complémentaires relatives à «Cfengine». A travers toutes ces pages, les ingénieurs permanents pourront trouver toutes les réponses à leurs questions, et pourront ainsi faire évoluer le système à partir d une base solide et correctement configurée. Cependant pour marquer encore davantage les esprits il a été décidé de former directement les ingénieurs Initiation des personnels permanents. L initiation des ingénieurs permanents de l équipe est une phase originale encore jamais tentée au sein du service. «Cfengine» représentant un système couvrant plusieurs domaines de l administration, il était important de sensibiliser tout le monde à ce nouvel outil et à son mode de fonctionnement. Ainsi une première séance de formation a été programmée afin d expliquer à nouveau les fonctionnalités de l outil, son architecture et son fonctionnement, tout en présentant les bases de travail déjà établies. Au cours de cette séance une démonstration de l utilisation de «Cfengine» a été réalisée à travers le déploiement du protocole de connexion réseau «SSH» et de ces outils. Au terme de cette séance, il a été proposé aux ingénieurs de réaliser chacun un petit exercice durant leur temps de travail. Plusieurs sujets avaient ainsi été préparés et mis à disposition au sein de la «DocMI» sur la page Initiation du projet «Cfengine». Au total 13 sujets ont été proposés. Deux semaines plus tard une seconde séance de formation était organisée afin de proposer des corrections, et répondre aux différentes questions qui auraient pu être posées. Malheureusement seul trois ingénieurs ont assisté à cette dernière séance, et seul un ingénieur avait préparé une configuration «Cfengine» en réponse au sujet que lui-même avait choisi. Au final, et quelques semaines plus tard, une seule personne sait exactement comment fonctionne «Cfengine» et quelles sont les étapes ayant permis de

28 28 GNU/Cfengine. Volume 2 n 2/2004 bénéficier d un tel outil sur le réseau LORIA. Cela peut sembler peu, mais comparé à «Majax», l objectif est atteint puisque ce dernier n était plus utilisé ou mal utilisé. Cependant, et malgré l échec constitué par la transmission de connaissances à travers des séances de «cours», le support écrit que constitue la «DocMI» représente la principale source d informations pour le service. Ainsi avant même de consulter le site officiel de «Cfengine», une rapide lecture de ces pages permet à l administrateur de comprendre les rouages de ce nouvel outil d administration automatique. 6. Conclusion. L administration automatique des stations «Linux» des Moyens Informatiques a connu au cours de ces six derniers mois une évolution majeure : la quasi disparition de l outil «Majax» qui avait été développé par l équipe il y a une dizaine d années. Ce choix a été justifié par le nombre important de fonctionnalités apportées par «Cfengine» ainsi que par son mécanisme de classes permettant une orientation objet et par conséquent une facilité de programmation accrue. L autre point sur lequel «Cfengine» surclasse «Majax» est l utilisation du modèle «client-serveur». Ce dernier permet à «Cfengine» d être totalement indépendant vis-à-vis du service «NFS» et d ainsi être plus tolérant face aux pannes du serveur. En effet une station n arrivant pas à joindre le serveur pourra toujours exécuter les tâches d administration dictées au sein de ses fichiers de configuration locaux. Cela faisait défaut à «Majax» qui lui ne pouvait plus fonctionner en cas d arrêt du service «NFS». En terme d évolutivité, «Cfengine» n en est qu au début de sa mise en production. Ainsi il a été décidé récemment d utiliser «Cfengine» afin d effectuer la modification du mot de passe «root» du site, plutôt que de passer par «Majax» qui est pourtant tout à fait capable de remplir cette tâche. Ensuite plusieurs évolutions ont déjà été apportées au système, durant ces six mois, et chacune de ces évolutions a été réalisée par la création et l utilisation de configurations «Cfengine». «Cfengine» a donc montré ici, sa faculté d évolution à travers les très nombreuses fonctionnalités offertes à l administrateur. La prochaine étape, va consister à totalement se passer des services de «Majax» pour à présent ne travailler qu avec un seul et même système d administration automatique des postes «Linux» : «Cfengine»! Je tiens à remercier Monsieur Bertrand WALLRICH, pour la confiance qu il m a accordé suite à notre entretien pour me confier cette mission de stage très enrichissante. Je souhaite également à remercier Monsieur Jean-Claude GIESE, responsable de la cellule «SysLog», pour sa connaissance du système «Majax», et pour cause il en est le principal instigateur. J adresse également mes sincères

29 Administration Automatique Linux 29 remerciements à Monsieur Benjamin DEXHEIMER, initiateur du projet, et qui a été mon responsable tout au long de ces six mois. Ses conseils ont été une aide précieuse dans la réalisation des différentes étapes du projet et m ont permis de mener à bien ce dernier en franchissant l ensemble des difficultés dont il était jalonné. Je remercie l intégralité de l équipe des Moyens Informatiques pour leur accueil, et leurs témoignages de sympathie. Enfin je remercie, Monsieur Charaf ECH-CHATBI, ingénieur associé dans la sécurité systèmes et réseaux, pour son aide à la compréhension des systèmes «Linux». 7. Bibliographie. Thierryr Lhomme., GNU/cfengine : Un logiciel (libre) pour l administration de parcs hétérogènes de machines, Mark Burgess., Tutorial et Refernces, Technique et Science Informatiques,