Projet Tuteure : Configuration automatique d un cluster de calcul avec Puppet

Projet Tuteure : Configuration automatique d un cluster de calcul avec Puppet Andre Dimitri Quentin Dexheimer Riwan Blonde 26 mars 2012

Table des matières Remerciements.................................... 3 Introduction au Projet Tuteuré........................... 4 1 Le Grid 5000 5 1.1 Présentation du Grid 5000........................... 5 1.2 Les outils du Grid 5000............................. 6 1.2.1 OAR2.................................. 7 1.2.2 Kadeploy................................ 8 1.2.3 Taktuk.................................. 9 1.2.4 KaVLAN................................ 9 1.2.5 Les autres outils............................ 10 2 Puppet Labs 11 2.1 Introduction à Puppet............................. 11 2.1.1 Qu est ce que Puppet Labs?...................... 11 2.1.2 Contexte d utilisation.......................... 12 2.1.3 Fonction principale........................... 12 2.2 Commencer avec Puppet............................ 14 2.2.1 Installation............................... 14 2.2.2 Configuration.............................. 15 2.2.3 Synchronisation............................. 15 2.3 Manifests.................................... 16 2.3.1 Qu est ce qu un manifest?....................... 16 2.3.2 Ressources................................ 17 2.4 Modules..................................... 17 2.4.1 Qu est ce qu un module?........................ 17 2.4.2 Structure d un module......................... 18 2.4.3 Exemple concret de module : MySQL................. 19 2.5 Complément à Puppet............................. 20 2.5.1 Puppet Dashboard........................... 20 3 Scripts et modules développés 22 3.1 Les Scripts.................................... 22 3.1.1 Script de réservation.......................... 22 3.1.2 Script d installation........................... 22 3.1.3 Le script de configuration du serveur.................. 24 3.1.4 Le script de configuration des clients.................. 25 3.2 Les modules Puppet.............................. 25 3.2.1 Les modules OAR............................ 25 1

TABLE DES MATIÈRES 3.2.2 Le module Kadeploy.......................... 26 3.2.3 Le module Dashboard......................... 27 3.2.4 Les autres modules........................... 27 Conclusion et Bibliographie 28 Conclusion....................................... 28 Bibliographie..................................... 29 Annexes 30 Les Scripts....................................... 30 Reserv.sh.................................... 30 tunnel.sh..................................... 30 clients config.sh................................. 31 master config.sh................................. 31 install.sh..................................... 34 Les Modules Puppet................................. 39 Module apache 2................................ 39 Module NFS................................... 39 Module DHCP................................. 40 Module Dashboard............................... 40 Module DNS.................................. 42 Module MySQL................................. 43 Module Kadeploy................................ 44 Module Oar-base................................ 46 Module Oar-server............................... 47 Module Oar-frontend.............................. 48 2

Nous aimerions remercier Monsieur Lucas Nussbaum et le LORIA de nous avoir permis d utiliser le GRID 5000 et particulièrement Monsieur Sébastien Badia, notre tuteur de projet, pour sa gentillesse et sa disponibilité.

Introduction au Projet Tuteuré Notre projet tuteuré, dans le cadre de la Licence Professionnelle ASRALL, concerne la Configuration Automatique d un Cluster de Calcul avec Puppet. Ce projet nous a été proposé par Lucas Nussbaum et Sébastien Badia du LORIA, Laboratoire LOrrain de Recherche en Informatique et ses Applications, Unité Mixte de Recherche (UMR 7503), commune à plusieurs établissements, le CNRS, l Université de Lorraine et l INRIA. Le département Réseaux, Systèmes et Services, du LORIA s attache aux problèmes issus des systèmes distribués et parallèles ainsi que sur la capacité qu ils ont, à une echelle jusque là inconnue, à travailler, gérer et calculer en toute transparence. L objectif de ce projet est de réaliser une série de modules Puppet permettant de configurer un cluster de calcul, les tests et validations des développements se faisant sur la plateforme GRID 5000. Pour notre travail nous nous sommes en premier intéressés au GRID 5000 que nous présentons dans le premier chapitre de ce rapport. La compréhension, la prise en main et l utilisation de Puppet Lab, logiciel open source comportant les outils nécessaires à la configuration des systèmes informatiques, fait l objet du deuxième chapitre. Nous présenterons ensuite les différents développements que nous avons été amenés à réaliser avant de conclure sur les résultats obtenus, les difficultés rencontrées et les travaux restant à faire.

Chapitre 1 Le Grid 5000 1.1 Présentation du Grid 5000 Le Grid 5000 est une grille informatique ou grille de calcul 1 destinée à la recherche scientifique. Cette plateforme fait partie de l action de développement technique Aladin. Elle a vu le jour en 2003 et a pour but de promouvoir la recherche sur les grilles informatiques en France. Le Grid 5000 est aujourd hui composé de 1540 noeuds répartis sur 11 sites différents situés en France et au Luxembourg et interconnectés avec le Réseau National de Télécommunications pour la Technologie l Enseignement et la Recherche (RENATER). L objectif du Grid 5000 est de permettre aux scientifiques d effectuer des expériences dans le domaine des systèmes informatiques et des réseaux distribués dans un environnement hétérogène aussi proche de la réalite que possible. Figure 1.1 Localisation des différents sites du Grid5000 1. Grille de calcul infrastructure logicielle et matérielle qui procure à un utilisateur final un accès à des capacités de calcul et de stockage de masse hautement distribuées. 5

CHAPITRE 1. LE GRID 5000 Le Grid 5000 est composé de plusieurs sites distincts, où l organisation est la même. Chaque site est composé d un ou plusieurs clusters 2. Par exemple, le site de Nancy héberge deux clusters nommés Griffon et Graphene. Cependant, tous les sites ne disposent pas du même nombre de machine : Bordeaux Grenoble Lille Luxembourg 154 116 100 22 Lyon Nancy Orsay Reims 135 236 340 44 Rennes Sophia Toulouse Total 162 151 88 1540 De plus, tous les sites ne proposent pas les mêmes services. Par exemple, le service Kavlan n est disponible que sur 5 des 11 sites : Lille, Lyon, Nancy, Rennes, Sophia A l intérieur de chaque cluster se trouvent des ordinateurs appelés nodes ou noeuds. Il en existe deux types, les noeuds de service et les noeuds de travail : Les noeuds de service servent à l administration des machines situées dans les clusters et à l accès aux hôtes virtuels pour les administrateurs. Les machines de service sont communes aux différents clusters situés sur les sites. Certains noeuds de service appelés frontend sont utilisés par les utilisateurs pour accéder aux différents sites via le protocole ssh, la réservation de noeuds et le déploiement. Les noeuds dit de travail sont les ordinateurs où sont effectuées les expériences. L administration de la plateforme est centralisée et est assurée par 8 personnes, certaines y sont affectées à plein temps d autres non. 1.2 Les outils du Grid 5000 Le Grid 5000 est composé de plusieurs services. Une partie de ces services a été développé uniquement pour cette plateforme comme par exemple Kadeploy qui a été développé par l INRIA Nancy - Grand Est. D autres sont des services standard déjà utilisés sur les systèmes Unix. 2. Cluster, ensemble de machines homogènes 6

CHAPITRE 1. LE GRID 5000 Figure 1.2 Un des clusters de Nancy : Griffon 1.2.1 OAR2 OAR est un gestionnaire de ressources pour de grandes grilles informatiques. Il est e crit en PERL et s appuie sur une base SQL (PostgreSQL ou MySQL). OAR permet le de ploiement, la re servation et le management des noeuds et des jobs 3. Figure 1.3 Le logo du projet OAR Les principales fonctionnalite s d OAR sont les suivantes : Soumission : Le syste me de cide du moment ou votre travail commence afin d optimiser l ordonnancement global de la plateforme. S il n y a pas de noeud disponible, le travail est mis en attente. (correspond a oarsub -I ou oarsub scriptname ) Re servation pre alable : On de cide quand le travail doit commencer, les ressources devant e tre disponibles a la date spe cifie e. Si les ressources demande es sont disponibles au moment du de but du job, la re servation s effectue, sinon la re servation e choue et il faut alors modifier les parame tres de la re servation. (correspond a oarsub -r date ou oarsub-r Date scriptname) Mode inte ractif : On n exe cute pas de script lors de la soumission ou lors de la re servation mais on choisit de travailler de fac on inte ractive. (correspond a oarsub-i pour la soumission ou oarsub -r jour et oarsub -C jobid pour la re servation) 3. un job correspond a une ta che affecte e a une re servation 7

CHAPITRE 1. LE GRID 5000 Mode passif : On choisit d exécuter directement un script sur les noeuds réservés. Il n est alors pas obligatoire de se connecter sur les noeuds mais cela est toujours possible en utilisant oarsub -C jobid). (correspond à oarsub scriptname pour la soumission ou oarsub -r date scriptname pour la réservation) Types de job possible : défaut : on utilise juste l environnement par défaut des noeuds. déploiement : on déploie un système d exploitation défini lors de la réservation. Cette méthode utilise l outil Kadeploy. Il existe un autre type de job, destiné aux utilisateurs avancés. 1.2.2 Kadeploy Kadeploy est un outil qui permet le déploiement des différents systèmes d exploitation sur les noeuds de la plateforme. Il permet aussi de configurer les noeuds, de les cloner et de les manager. Il permet le déploiement des systèmes d exploitation : Linux, BSD, Windows et Solaris. Kadeploy3 est composé de 8 outils : Figure 1.4 Le logo du projet Kadeploy kadeploy client : l interface utilisateur pour Kadeploy, kaenv : fournit les informations concernant l environnement des noeuds, kareboot : permet de redémarrer les noeuds et de définir les paramètres à utiliser lors du redémarrage, kastat : affiche les performances des noeuds, kaconsole : ouvre une console sur un noeud distant, kanodes : donne des informations sur les noeuds, kapower : permet d allumer et d éteindre des noeuds et de connaître le statut des noeuds (allumé/éteint), karights : modifie les droits des utilisateurs sur les noeuds. 8

CHAPITRE 1. LE GRID 5000 1.2.3 Taktuk Figure 1.5 Le logo du projet TakTuk TakTuk est un outil complémentaire à OAR2. TakTuk autorise l exécution de commandes à distance sur un grand nombre de noeuds hétérogènes. Il met en place une liaison entre le frontend et les noeuds concernés par la commande et s adapte à l environnement de la machine. Exemple d une commande TakTuk : taktuk -l root -s -f OAR_FILE_NODES broadcast exec [ apt-get update ] L option -l permet d utiliser le compte root pour l installation. L option -s installe Taktuk sur la machine s il ne l est pas déjà. L option -m déploie sur une seule machine tandis que l option -f permet de déployer sur toutes les machines listées dans un fichier. Cette commande permet donc de déployer les paquets puppet, facter et puppetmaster sur les machines définies dans le fichier OAR FILE NODES. 1.2.4 KaVLAN KaVLAN est un outil qui permet la mise en place d un VLAN sur des noeuds du Grid5000. Plusieurs types de VLAN sont possibles : local, router et global. KaVLAN peut être utilisé en complément de Kadeploy et de OAR pour certains types d expérimentation. Un KaVLAN local est un VLAN complètement isolé du reste de la plateforme Grid5000. Il est alors obligatoire d utiliser une passerelle pour accéder aux noeuds se trouvant à l intérieur de VLAN. Un KaVLAN router permet l accès à tous les noeuds du VLAN depuis le reste du Grid5000 sans utiliser de passerelle. Un KaVLAN global est un VLAN qui est disponible sur tous les sites du Grid5000. Un routeur est alors configuré sur le site où le VLAN a été configuré. La commande suivante réserve un nombre donné, ici 10, de noeuds en utilisant un VLAN local : oarsub -I -t deploy -l {"type= kavlan-local "}/vlan=1+/nodes=10,walltime=1:30:00 9

CHAPITRE 1. LE GRID 5000 Kavlan dispose d autres commandes utiles. Par example, la commande donnant la liste des machines qui se trouvent à l intérieur d un VLAN pour un job donné : kavlan -V -j JOBID Celle qui permet d activer le dhcp interne a KaVLAN est : kavlan -e La commande qui permet de désactiver le dhcp est : kavlan -d 1.2.5 Les autres outils Le Grid5000 utilise pour son fonctionnement d autres outils : une base de données MySQL. Cette base de données est utilisée par Kadeploy et OAR. un serveur DNS (Domaine Name Server) qui permet de faire la correspondance entre les adresses ip et les noms de domaine. un serveur DHCP (Dynamic Host Configuration Protocol) pour la configuration automatique des paramètres IP des machines. un serveur NFS (Network File System) pour permettre aux utilisateurs de stocker des informations dans leur /home sur les différents sites. des outils de supervision : Nagios : surveille les hôtes et services spécifiés, avec des alertes en cas de problème. Ganglia : permet de superviser des clusters et des grilles informatiques. Munin : présente les résultats sous forme de graphiques disponibles via une interface web. Cacti : mesure les performances réseau et serveur. un serveur weathermap : qui visualise le réseau sous forme d une carte. un serveur syslog : qui collecte les événements et crée les journaux correspondants. un annuaire LDAP ( Lightweight Directory Access Protocol). un serveur web Apache. un serveur Squid : un proxy/proxy reverse. un serveur NAT (Network Address Translation) : pour faire correspondre une seule adresse externe publique visible sur Internet à toutes les adresses d un réseau privé. un serveur mail. un dépôt de paquets et de logiciels. API Rest g5k : utilisé par KaVLAN, Kadeploy et UMS (User Management System). Il permet d utiliser toutes les fonctions du Grid 5000 et de les automatiser. une infrastructure de virtualisation XEN comportant de 2 a 5 dom0 et environ 30 domu avec un service par domu. 10

Chapitre 2 Puppet Labs 2.1 Introduction à Puppet 2.1.1 Qu est ce que Puppet Labs? Puppet est un logiciel open source comportant les outils nécessaires à la configuration de systèmes informatiques. Il est basé sur le langage de programmation Ruby, et est sous licence GPL v2. Puppet a principalement été développé par Luke Kanies et son entreprise Puppet Labs. Kanies a développé puppet grâce à son expérience dans les systèmes Unix et les systèmes d administration depuis 1997. Non satisfait des outils de configuration existants, il a commencé à travailler avec des outils de développement en 2001, et a fondé Puppet Labs en 2005, une entreprise de développement open source basée sur les outils d automatisation. Peu de temps après, Puppet Labs sort son nouveau produit phare : Puppet. Il peut être utilisé pour gérer la configuration d application sous Unix et OSX, ainsi que Linux et Windows depuis peu de temps. Figure 2.1 Principe d utilisation de Puppet 11

CHAPITRE 2. PUPPET LABS Son modèle est basé sur 3 piliers : Le déploiement Un langage de configuration et une couche d abstraction Sa couche transactionnelle 2.1.2 Contexte d utilisation La gestion au quotidien des configurations systèmes et applicatives d une entreprise représente un travail très fastidieux. Puppet simplifie grandement la vie des administrateurs : plus de contrôles et d interventions à réaliser régulièrement. Puppet se charge d imposer sur les machines des utilisateurs les configurations modèles définies par l administrateur. Puppet est un outil de déploiement et de gestion centralisée de configurations pour les environnements Linux, Unix et Windows ; les machines gérées pouvant être physiques ou virtualisées. 2.1.3 Fonction principale Puppet est un outil de déploiement et de gestion automatisés de configurations et de systèmes informatiques (serveurs, postes de travail..). Il repose sur un modèle client/serveur : un serveur central sert de dépôt de configurations, les systèmes clients (nœuds) se mettant à jour de manière manuelle ou automatique. Avec Puppet, l administrateur n écrit pas un ensemble d opérations à exécuter sur les différents nœuds sous la forme d un script, l administrateur décrit l état final de la machine dans un Manifest, ce qui l affranchit de la connaissance des commandes propres à chaque système d exploitation pour arriver à cet état. Le client Puppet peut être exécuté plusieurs fois, les changements seront opérés seulement si l état de la machine ne correspond pas à celui désiré. Figure 2.2 Fonction principale de Puppet Deploiement Puppet est habituellement déployé sur un simple modèle client/serveur. Le serveur est appelé Puppet Master, le logiciel client est appelé un agent, et l hôte lui-même ainsi que les agents sont définit comme des noeuds. Le Master s exécute comme un 12

CHAPITRE 2. PUPPET LABS démon sur un hôte et contient la configuration requise pour l environnement. Les agents se connectent au Master via une connexion cryptée qui utilise le standard SSL. Il est important de préciser que si l agent a déjà la configuration requise, puppet ne fera rien. Cela signifie que puppet appliquera seulement les changements sur l environnement s ils sont nécessaires. L ensemble de ces processus est appelé une exeécution de configuration. Par défaut, l agent puppet vérifie toutes les 30 minutes le Master afin de voir si des modifications doivent êtres effectuées. Cet interval de temps est bien sûr paramétrable. Configuration Lang/Rsrc Puppet utilise son propre langage de déclaration pour définir les points de configuration qui sont écrits dans une Ressource. Ce qui permet de distinguer puppet de beaucoup d autres outils de configuration. Ce langage permet de déclarer si un package doit être installé ou si un service doit être lancé par exemple. La plupart des outils de configuration (scripts shell ou pearl par exemple) sont procéduraux. Ils décrivent comment les choses doivent êtres faites plutôt que de se focaliser sur l état final attendu. Les utilisateurs de puppet ont juste besoin de déclarer l état final voulu de ses hôtes : les packages à installer, les services à executer etc. Avec puppet, l administrateur système n attache pas d importance sur comment ces actions vont être faites. Transaction Layer Le moteur de puppet est sa couche transactionnelle. Une transaction puppet : Interprète et compile la configuration, Communique la configuration compilée à l agent, Applique la configuration sur l agent, Rapporte le résultat de cette application au Master. La 1ère étape de puppet est d analyser la configuration et de calculer comment l appliquer sur l agent. Pour cela, puppet crée un graphique représentant toutes les ressources, ainsi que leurs relations entre elles et chaque agents. Puis puppet applique chaque ressource sur un hôte. Ce qui en fait une des caracteristiques les plus puissantes de puppet. Ensuite puppet se sert des ressources et les compile dans un catalogue pour chaque agent. Le catalogue est envoyé à l hôte et appliqué par l agent puppet. Les résultats de cette application sont renvoyés au Master sous forme de rapport. La couche transactionnelle permet aux configurations d être créées et appliquées indéfiniment sur un hôte. Ceci est appelé idempotent, cela signifie que de multiples applications de la même opération donneront le même résultat. Une configuration de puppet peut être 13

CHAPITRE 2. PUPPET LABS exécutée plusieurs fois sur un hôte en toute sécurité avec le même résultat, assurant ainsi à la configuration de rester compatible. 2.2 Commencer avec Puppet 2.2.1 Installation Nous allons à present passer à l installation de Puppet sur une machine serveur et sur une machine cliente. Nous utiliserons le système d exploitation Debian Squeeze, puisque c est celui que nous utiliserons plus tard lors du travail effectué. Cependant, il faut savoir que Puppet est disponible sur toutes les distributions Linux et Unix (OpenSolaris, BSD, RedHat, Debian et Ubuntu) ainsi que sur Windows Server 2008. Côté Serveur Les pré-requis pour installer Puppet sont les packages ruby et libshadow-ruby1.8. Nous allons utiliser le package Puppetmaster disponible dans l APT, nous n aurons donc pas à devoir gérer les dépendances liées à l utilisation de Puppet. Ainsi pour installer Puppet, nous entrons la commande suivante : sudo apt-get install puppet puppetmaster facter En installant le paquet Puppet sur la machine serveur, nous lui permettons de s autogérer. Pour les machines clientes, il suffit d installer les mêmes paquets à l exception du Puppetmaster. Les packages installés Liste des différents paquets installés et leurs utilités : Package puppet : Ce paquet contient le script de démarrage et les scripts de compatibilité pour l agent puppet, qui est le processus responsable de la configuration du nœud local. Package puppetmaster : Ce paquet contient le script de démarrage et les scripts de compatibilité pour le processus maître puppet, qui est le serveur hébergeant les manifests et les fichiers pour les nœuds puppet. Package facter : Bibliothèque dite cross-plateform, qui permet de collecter des informations sur le système. Particulièrement utile dans la collecte d un nom de système, d adresses IP et/ou MAC, clés SSH. 14

CHAPITRE 2. PUPPET LABS 2.2.2 Configuration Côté Serveur Pour configurer le serveur, il faudra éditer le fichier de configuration puppet.conf, ainsi que le fichier de hosts : 1. Dans le fichier /etc/puppet/puppet.conf, on y ajoute les lignes suivantes : 1 s e r v e r=nom machine serveur 2 [ master ] 3 certname=nom machin serveur L option serveur= permet d indiquer à l agent Puppetd quelle est la machine serveur. On la rajoute pour lui permettre de s auto-gérer. L option certname= définie le nom de la machine serveur au Puppetmasterd. 2. Dans le deuxième fichier, /etc/hosts, on y ajoute les adresses IP des machines clientes ainsi que sa propre adresse : Par exemple : 1 1 2 7. 0. 0. 1 l o c a l h o s t 2 1 9 2. 1 6 8. x. x puppet. ptut grid5000. lan puppetmaster 3 1 9 2. 1 6 8. x. x dns. ptut grid5000. lan dns 4 1 9 2. 1 6 8. x. x dhcp. ptut grid5000. lan dhcp 5... Côté Client Comme pour le serveur il faudra éditer les fichiers puppet.conf et hosts mais cette fois sans l option certname. 2.2.3 Synchronisation Une fois l installation et les configurations terminées, on lance le serveur maître via la commande : sudo /etc/init.d/puppetmaster {start stop restart} Lors de la première installation le serveur est déjà démarré. Sur la machine cliente, on lance une deuxième commande : sudo puppet agent --test 15

CHAPITRE 2. PUPPET LABS On obtient alors une demande de validation de certificat : info: Creating a new certificate request for puppetclient info: Creating a new SSL key at /var/lib/puppet/ssl/private_keys/puppetclient.pem warning: peer certificate won t be verified in this SSL session notice: Did not receive certificate Sur le serveur il faut alors délivrer le certificat pour la machine client : sudo puppet cert --list sudo puppet cert --sign puppetclient Pour avoir la liste complète des commandes : puppet help. Une fois le certificat distribué, on relance la commande précédente et cette fois apparait un nouveau message : notice: Got signed certificate notice Stating Puppet client err: Could not retrieve catalog: Could not find default node or by name with puppetclient on node puppetclient. L agent du client a bien été connecté avec le serveur mais n a pas pu trouver un catalogue pour le dit client. 2.3 Manifests Pour que Puppet fonctionne nous devons lui dire quoi faire. Ceci se fait grâce aux manifests. 2.3.1 Qu est ce qu un manifest? Les programmes de Puppet sont appelés manifest, et ils utilisent l extension de fichier.pp. Le coeur du language Puppet est la déclaration de ressources, qui représente l état désiré d une ressource. Les Manifests peuvent également utiliser des instructions conditionnelles, un groupe de ressources dans des collections, générer du texte avec des fonctions, référencer du code dans d autres manifests, et bien d autres choses, mais tout revient en dernière analyse à faire en sorte que les bonnes ressources soient gérées de la bonne façon. Avant d être appliqués, les manifests sont compilés dans le catalogue, qui est un graphe acyclique dirigé qui ne représente que les ressources et l ordre dans lequel elles doivent être synchronisées. Toute la logique conditionnelle, la recherche de données, l interpolation de variables, et le regroupement de ressources calculent l écart lors de la compilation. Parmis les manifests deux sont importants. Lorsque le client consultera le Puppet Master, l agent lira les fichiers dans un certain ordre : 16

CHAPITRE 2. PUPPET LABS le fichier /etc/puppet/manifests/site.pp qui dit à Puppet où et quelle configuration charger pour les clients. C est dans ce fichier que nous ferons la déclaration des ressources, on spécifiera également d importer les nodes. 1 import nodes. pp le fichier /etc/puppet/manifest/node.pp est lu lors de l import. Dans ce fichier, nous renseignons les FQDN des clients ainsi que les modules qui leur sont associés. 1 node oar s e r v e r. ptut grid5000. lan { i n c l u d e oar s erver, apache, mysql } 2.3.2 Ressources Une ressource est un élément que Puppet sait configurer : file (contenu, permissions, propriétaire) package (présence ou absence) service (activation/désactivation, démarrage/arrêt) exec(exécution commande) cron, group, host, user etc... Dans Puppet chaque ressource est identifiée par un nom, elle est composée d un certain nombre d attributs qui ont chacun une valeur. Le language de Puppet représente une ressource comme ceci : 1 user { dave : 2 ensure => present, 3 uid => 507, 4 gid => admin, 5 s h e l l => / bin / zsh, 6 home => /home/ dave, 7 managehome => true, 8 } 2.4 Modules 2.4.1 Qu est ce qu un module? Un module est une collection de manifests, ressources, fichiers, templates, class et définitions. Un simple module contiendra tout ce qui est requis pour configurer une application particulière. Par exemple il pourra contenir toutes les ressources spécifiées dans le manifest, fichiers et configuration associée pour Apache. Chaque module a besoin d une 17

CHAPITRE 2. PUPPET LABS structure de répertoire spécifique et d un fichier appelé init.pp. Cette structure autorise Puppet à charger automatiquement les modules. Pour accomplir ce chargement automatique Puppet vérifie une série de répertoires appelée le chemin du module (the module path en anglais). Ce chemin est configuré avec l option de configuration du module path dans la section [main] de puppet.conf. Par défault, Puppet recherche des modules dans /etc/puppet/modules et /var/lib/puppet/modules. Si nécessaire on peut rajouter d autres chemins. 2.4.2 Structure d un module Un module est définit de la façon suivante : 1. /etc/puppet/nom-du-module/manifests/ : Le répertoire manifests contiendra notre fichier init.pp et tout autre configuration. Le fichier init.pp est le coeur de notre module et chaque module doit en avoir un. Dans le fichier init.pp nous allons retrouver des classes qui seront instanciées lors de l appel d un agent. Dans ces classes on retrouve les configurations de réference. 2. /etc/puppet/nom-du-module/files/ : Le répertoire files contiendra tous les fichiers que nous souhaitons utiliser comme une partie de notre module, par exemple des fichiers à uploader. 3. /etc/puppet/nom-du-module/templates/ : Le répertoire templates contiendra tous les templates que notre module pourrait utiliser. 18

CHAPITRE 2. PUPPET LABS 2.4.3 Exemple concret de module : MySQL Premièrement création de l arborescence : mkdir p /etc/puppet/modules/mysql/{files,templates,manifests} Ensuite nous allons créer le fichier init.pp avec la commande suivante : touch /etc/puppet/modules/mysql/manifests/init.pp Une fois l arborescence créée nous devons configurer le fichier init.pp comme ceci : 1 import i n s t a l l. pp 2 import c o n f i g. pp 3 import s e r v i c e. pp 4 5 c l a s s mysql { 6 i n c l u d e mysql : : i n s t a l l, mysql : : c o n f i g, mysql : : s e r v i c e 7 } Notre init.pp contient une seule class appelée mysql. A cela, on y ajoute trois fichiers install.pp, config.pp et service.pp contenant respectivement les class mysql : :install, mysql : :config et mysql : :service. La class mysql dit au puppetmaster d aller exécuter les class inclusent. Les trois fichiers doivent se trouver dans le même répertoire que le fichier init.pp. Le premier fichier, install.pp, s assure que les paquets MySQL-server, MySQL-client et Phpmyadmin sont bien installés. 1 c l a s s mysql : : i n s t a l l { 2 package { [ mysql s e r v e r, mysql c l i e n t, phpmyadmin ] : 3 ensure => present, 4 r e q u i r e => User [ mysql ], 5 } 6 user { 7 mysql : 8 ensure => present, 9 comment => MySQL user, 10 gid => mysql, 11 s h e l l => / bin / f a l s e, 12 r e q u i r e => Group [ mysql ], 13 } 14 group { 15 mysql : 16 ensure => present, 17 } 18 } Il permet aussi de créer un utilisateur MySQL et un groupe MySQL auquel on donne les droits administrateur sur MySQL. 19

CHAPITRE 2. PUPPET LABS Le second fichier, config.pp, utilise la class mysql : :config. Elle est une class de type ressource fichier. Elle permet de copier un fichier de configuration de MySQL prédéfinie. 1 c l a s s mysql : : c o n f i g { 2 f i l e { 3 / e t c /mysql/my. cnf : 4 source => puppet :/// mysql/mysql conf, 5 ensure => f i l e, 6 owner => root, 7 group => root, 8 mode => 644, 9 n o t i f y => S e r v i c e [ mysql ], 10 r e q u i r e => Class [ mysql : : i n s t a l l ] ; 11 } 12 } L option source indique à Puppet où se situe le fichier. Généralement, il se trouve dans le dossier files du module. Cependant, on ne spécifie pas tout le chemin d accès. Juste le nom du module et le nom du fichier. Puppet cherchera directement dans le dossier files. Les autres options permettent de définir le propriétaire, le groupe et les permissions du fichier. Le troisième fichier importé, service.pp, sert à vérifier que le service récemment installé fonctionne ou est démarré. 1 c l a s s mysql : : s e r v i c e { 2 s e r v i c e { mysql : 3 ensure => running, 4 h a s s t a t u s => true, 5 h a s r e s t a r t => true, 6 enable => true, 7 r e q u i r e => Class [ mysql : : i n s t a l l ], 8 } 9 } 2.5 Complément à Puppet 2.5.1 Puppet Dashboard Aperçu Puppet Dashboard est une application avec interface web permettant d afficher des informations sur le serveur Puppet et son environnement (Master et Agents). Il permet de voir sur des graphes, les données répertoriées d un serveur Puppet ou de plusieurs serveurs (multi-puppet). Il fait aussi l inventaire de données à partir des agents (à la façon d un OCS inventory). 20

CHAPITRE 2. PUPPET LABS Enfin, il peut être utilisé comme console de configuration pour le serveur Puppet et de ses nodes (désignation des class et/ou paramètres, etc...). Installation Comme tout Puppet, son installation est relativement simple puisqu une ligne de commande via l APT est requise. Cependant le dépôt Puppet Labs APT doit être ajouté dans le fichier sources.list : #/etc/apt/sources.list deb http://apt.puppetlabs.com/debian squeeze main deb-src http://apt.puppetlabs.com/debian squeeze main A fortiori, la clé GPG doit aussi être ajoutée : sudo gpf --recv-key 4BD6EC30 sudo gpg -a --export 4BD6EC30 > /tmp/key sudo apt-key add /tmp/key Finalement, la commande pour l installer via l APT est : sudo apt-get install puppet-dashboard Pour se connecter à l interface web on exécute la commande suivante puis dans la barre navigation de son navigateur web, l url qui suit : sudo /etc/init.d/puppet-dashboard start http://machine_serveur:3000/ 21

Chapitre 3 Scripts et modules développés 3.1 Les Scripts 3.1.1 Script de réservation Nous avons réalisé un script qui nous permet de réserver des machines sans avoir à renseigner les commandes de l outil OAR. Nous demandons à la personne souhaitant réserver des machines de rentrer le nom de la réservation, le nombre de machines et le temps de réservation de celles-ci. Nous passons ensuite ces arguments à oarsub avec les options requises. 1 oarsub I t deploy l { type = kavlan l o c a l }/ vlan=1+/nodes=$nbr nodes, walltime=$tmps n $nom 3.1.2 Script d installation Le script d installation, install.sh, nous permet d automatiser le déploiement de notre cluster une fois les machines réservées. Nous commençons l installation de notre cluster par l activation du DHCP de Grid5000. Il sera désactivé une fois notre serveur DHCP mis en place. Nous générons ensuite le fichier de configuration dhcpd.conf en fonction du site et du numéro du VLAN associé. Nous le déplaçons ensuite dans le dossier files du module DHCP de puppet. 1 // A c t i v a t i o n du DHCP i n t e r n e 2 kavlan e 3 4 // Generation du f i c h i e r de c o n f i g u r a t i o n 5 j o b i d = o a r s t a t grep $USER cut d f1 6 vlan = kavlan V j $ j o b i d 7 s i t e = uname n cut d. f2 8 export GEMHOME=/home/$USER/. gem/ruby /1.8/ 9 gem i n s t a l l ruby ip no r i no rdoc user i n s t a l l 10 chmod +x. / p r o j e t / i n s t a l l / gen dhcpd conf. rb 11. / p r o j e t / i n s t a l l / gen dhcpd conf. rb s i t e $ s i t e vlan id $vlan 12 mv dhcpd kavlan $vlan $ s i t e. conf $puppet modules /dhcp/ f i l e s /dhcpd. conf 22

CHAPITRE 3. SCRIPTS ET MODULES DÉVELOPPÉS Nous allons ensuite déployer l image ISO de Debian Squeeze que nous fournit le Grid5000 pour installer les différents services sur les noeuds. Nous affichons auparavant la liste des noeuds que nous avons réservés. 1 echo Deploiement de l environnement Linux, Debian Squeeze 64 b i t, 2 sur t o u t e s l e s machines r e s e r v e e s ( Peut prendre p l u s i e u r s minutes ). 3 // Deploiement de l image ISO Debian Squeeze x64 b a s e 4 kadeploy3 e squeeze x64 base f $OAR FILE NODES vlan $vlan d V4 k $HOME/. ssh / i d d s a. pub Nous mettons en place les différents fichiers exploités par le script : list nodes, contient la liste de toutes les machines réservées list users, contient toutes les machines utilisateurs. puppet clients, contient toutes les machines services installées via Puppet : MySQL, DNS, DHCP, Kadeploy, OAR, NFS. puppet master, contient le FQDN de la machine puppet serveur Vient ensuite l ensemble des tests sur la configuration SSH du client qui a lancé le déploiement. Cela consiste en une vérification sur le fichier de configuration (.ssh/config) et le fichier d authorisation (.ssh/authorized keys), puis en une copie des clés de l utilisateur sur toutes les machines concernées par le déploiement du cluster. Cela nous permet de nous connecter aux différentes machines réservées sans avoir à entrer nos mots de passe à chaque fois et d utiliser TakTuk. 1 taktuk l root s m $node broadcast exec [ cat /. ssh / i d d s a. pub >> /. ssh / a u t h o r i z e d k e y s ] Nous créons ensuite les tunnels SSH grâce au script tunnel.sh. Via la commande SCP nous transmettons sur toutes les machines réservées le script tunnel.sh. Avec la commande Taktuk nous l exécutons. 23

CHAPITRE 3. SCRIPTS ET MODULES DÉVELOPPÉS Nous passons ensuite à l installation du serveur Puppet et des clients puppets. Ainsi qu au rappatriement des modules du frontend vers la machine serveur. 1 // I n s t a l l a t i o n des paquets s e r v e u r s 2 taktuk l root s m $puppet master broadcast exec [ apt get q y i n s t a l l puppet f a c t e r puppetmaster ] 3 // I n s t a l l a t i o n des paquets c l i e n t s 4 taktuk l root s m $ p u p p e t c l i e n t s broadcast exec [ apt get q y i n s t a l l puppet f a c t e r ] 5 // rappatriement des c a t a l o g u e s / modules / m a n i f e s t s sur l e master 6 scp r $puppet modules / root@$puppet master : / e t c / puppet / Une fois installés, nous configurons le Puppetmaster grâce au script master config.sh qu on transmet sur la machine via un scp aussi. Une fois le maître configuré, nous configurons tous nos clients de telle sorte que chaque machine puisse recevoir la configuration qui lui est attribuée depuis le master. Enfin, nous terminons l installation par la désactivation du vlan fourni par Grid5000 pour utiliser notre propre serveur DHCP, puis par la suppression du fichier temporaire utilisé. 1 taktuk l root s f $ p u p p e t c l i e n t s broadcast exec [ d h c l i e n t ] 2 taktuk l root s f $ l i s t u s e r s broadcast exec [ d h c l i e n t ] 3.1.3 Le script de configuration du serveur. Ce script permet d écrire toute la configuration du maître Puppet en se basant sur tous les services à installer. Pour commencer, nous configurons le fichier /etc/hostname pour établir le nom du réseau et nous redémarrons le service hostname. Ensuite nous établissons le fichier puppet.conf comme vu précédemment. Ainsi que le fichier /etc/hosts. Nous avons également besoin de configurer les adresses ou les noms de nos machines clientes pour que Puppet puisse les retrouver. 1 y=1 2 f o r r o l e in puppet dhcp dns mysql n f s oar frontend oar s e r v e r kadeploy 3 do 4 node= sed n $y p p u p p e t c l i e n t s 5 ip node = arp $node cut d f 2 cut d ( f 2 cut d ) f1 6 echo $ip node $ r o l e. ptut grid5000. lan >> / e t c / h o s t s 7 y=$ ( ( $y+1) ) 8 done 24

CHAPITRE 3. SCRIPTS ET MODULES DÉVELOPPÉS Nous utilisons le même type de boucle pour définir les noeuds dans le fichier nodes.pp. Enfin, nous terminons la configuration du master Puppet par la configuration du service de noms de domaine. 1 f o r machine in $ ( cat l i s t u s e r s ) 2 do 3 ip machine = arp $machine cut d f 2 cut d ( f 2 cut d ) f1 4 echo machine$i IN A $ip machine >> 5 / e t c / puppet / modules / bind / f i l e s /db. ptut grid5000. lan 6 i p o c t 4 = echo $ip machine cut d. f 4 7 echo $ i p o c t 4 IN PTR machine$i. ptut grid5000. lan. >> 8 / e t c / puppet / modules / bind / f i l e s /db. r e v e r s 9 echo marocco $ i. ptut. grid5000. f r $ip machines marocco >> 10 / e t c / puppet / modules / kadeploy / f i l e s / c o n f s / nodes 11 i=$ ( ( $ i +1) ) 12 done La fin du programme permet de préparer l installation de kadeploy en modifiant le fichier de configuration. 3.1.4 Le script de configuration des clients. Contrairement au master, le client puppet n a besoin de connaître que deux adresses : celle du master puppet, et celle de son propre client. 3.2 Les modules Puppet Le sujet principal du projet était de déployer l intégralité du cluster au travers de Puppet. Une fois que l infrastructure est installée, nous allons maintenant déployer les différents services à l aide des modules que nous avons crées. Pour éviter les répétitions, nous nous contenterons d étudier les modules des outils spécifiques à Grid5000 et ceux qui ont une importance capitale. Tous les modules sont dans l annexe. 3.2.1 Les modules OAR OAR se décompose en deux parties : le serveur et le frontend. Figure 3.1 Deux modules pour OAR : Le serveur, et le frontend. 25

CHAPITRE 3. SCRIPTS ET MODULES DÉVELOPPÉS Ces deux modules nécessitent un certain nombre de paramètres qui lui permettent de fonctionner : Une communication SSH qui permettent au frontend de se connecter directement sur le serveur et inversement ; Le fichier de depôt de logiciels d OAR. Nous copions donc l intégralité des clés SSH créées pour l occasion, ainsi que le fichier de configuration de notre utilisateur et le fichier de configuration du démon SSH. L ensemble de cette configuration, déployée à l identique sur le frontend et le serveur, est définie par une class située dans le fichier install.pp de chaque module OAR. Le module OAR-frontend. Il est configuré par deux programmes : les fichiers prologue et épilogue. Ils nécessitent absolument une configuration manuelle car vierges par défaut. Tout comme le serveur OAR, le frontend est configuré par deux scripts puppet, l un permettant d initialiser le module, l autre se contentant de vérifier et d adapter la configuration sur le client Puppet. Figure 3.2 Deux scripts d installation pour chaque module OAR Le module OAR-server. Le serveur OAR dépend activement d une base de données, en l occurence ici une base mysql, afin de gérer les noeuds. Cette base est localisée et configurée dans le fichier oar.conf, que nous allons copier depuis le maître Puppet vers le client. Deux autres fichiers de configuration sont nécessaires pour le serveur OAR. Il s agit de : Monika.conf, qui permet de montrer les jobs soumis par le frontend au serveur ainsi que l état de chaque noeud ; drawgantt.conf, qui permet de présenter les différentes tâches dans le temps suivant un Diagramme de Gantt. Le serveur OAR nécessite également plusieurs autres services : un serveur Web du type apache2 sur la machine déployée ; une base de données de type mysql ou postgre qui peut être sur une autre machine. 3.2.2 Le module Kadeploy Ce module est installé par Puppet à l aide de 5 fichiers de scripts Puppet. Cela permet de définir simplement ce qu un client et un serveur doivent récupérer. Kadeploy possède son propre depôt qu il faut ajouter pour pouvoir l installer. Il utilise également une base de données créee et configurée par Puppet à l aide des fichiers db creation.sql et init deploy3-db. Nous rajoutons également le fichier authorized keys de 26

CHAPITRE 3. SCRIPTS ET MODULES DÉVELOPPÉS Figure 3.3 Module Kadeploy manière à permettre une communication SSH. Dans le dossier confs des fichers utiles à la configuration de kadeploy par Puppet, nous retrouvons les fichiers qui permettent d indiquer le nom du cluster, les partitions à appliquer, les commandes spécifiques pour certains noeuds, etc. 3.2.3 Le module Dashboard C est une fonctionnalité qui n était pas prévue initialement dans le projet. Elle nécessite d installer la clé publique pour le dépôt du Dashboard, qui n est pas inclus par défaut dans les dépôts logiciels du Grid5000. Nous nous assurons le bon fonctionnement du module sur le noeud au travers de 4 scripts Puppet, qui permettent d installer, de configurer et de lancer le puppet dashboard. 3.2.4 Les autres modules D autres modules ont dû être définis pour assurer le bon fonctionnement des outils utilisés. Nous avons donc réalisé ces modules en se basant sur des exemples fournis sur le site de Puppet, que nous avons réadapté avec une configuration adaptée à nos besoins. Cela nous a permis d installer ces services très rapidement, avec la souplesse d utilisation de ces modules. 27

Conclusion et Bibliographie Conclusion Pour conclure ce rapport, nous pouvons dire que ce travail fut vraiment très intéressant à mener et que l environnement du LORIA, la découverte du GRID 5000 et de Puppet ont été très formateur et nous ont beaucoup apporté. Nous avons ainsi réussi à mener à bien les items suivants : réservation automatique des machines installation sans image ISO installation du serveur Puppet avec configuration et déploiement avec configuration des agents sur les machines clientes récupération sans problème des modules DNS, DHCP, NFS, MySQL, Apache2, Dashboard, les services associés fonctionnent rapatriement sans soucis des modules OAR et KADEPLOY, des difficultés cependant ont été rencontrées pour leur fonctionnement Nous n avons par contre pas eu le temps de nous intéresser à d autres solutions de configuration automatique que Puppet. Un des problèmes majeurs que nous avons rencontré et que nous n avons pas réussi à résoudre concerne les hostnames des machines clientes. Ainsi quand on les change pour les faire correspondre à nos attentes (du genre : puppet.ptut-grid5000.lan au lieu de griffon-xx-kavlan-x.nancy.grid5000.fr), puppet crée un certificat sous le nom puppet.ptutgrid5000.lan mais lorsqu on lance une récupération des catalogues, il nous informe que les hostnames et le certificat ne correspondent pas. Pourtant, le serveur Puppet arrive à entrer en contact avec toutes les machines clientes puisque définies dans le /etc/hosts. De plus la demande de certificat est prise en compte. Donc le contact entre le serveur et la machine a bien été établi. Pour contourner cette difficulté et pouvoir continuer notre projet nous avons créé des scripts où les hostnames des machines clientes restent inchangés. Pour finaliser ce travail il reste à tester une réservation, à déployer notre mini Grid 5000 et à rechercher et valider des solutions alternatives à Puppet. 28

CHAPITRE 3. SCRIPTS ET MODULES DÉVELOPPÉS Bibliographie https ://www.grid5000.fr/mediawiki/index.php/grid5000 :Home http ://kadeploy3.gforge.inria.fr/ http ://oar.imag.fr/ http ://taktuk.gforge.inria.fr/ http ://puppetlabs.com/ Pro Puppet de James Turnbull, Jeffrey McCune édition Apress 2011. 29

Annexes Les Scripts Reserv.sh 1 #! / bin / bash 2 # = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 3 #Formulaire 4 # = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 5 echo n Nom de l a r e s e r v a t i o n : 6 read nom 7 echo n Nombre de machine a r e s e r v e r : 8 read nbr\ nodes 9 echo n Temps de l a r e s e r v a t i o n ( h :mm: s s ) : 10 read tmps 11 12 # = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 13 #Reservation des machines 14 # = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 15 echo Reservation de $nbr nodes machine ( s ) pour $tmps heure ( s ). 16 oarsub I t deploy l { type = kavlan l o c a l }/ vlan=1+/nodes=$nbr \ nodes, walltime=$tmps n $nom tunnel.sh 1 #! / bin / bash 2 user = cat username 3 gateway = / sbin / ip route awk / d e f a u l t /{ p r i n t $3 } 4 5 ssh q o StrictHostKeyChecking=no o UserKnownHostsFile=/dev/ n u l l o P r e f e r r e d A u t h e n t i c a t i o n s=publickey o BatchMode=yes NL 8080: proxy :3128 $user@$gateway &>/dev/ n u l l & 6 7 rm / e t c / apt / apt. conf. d/ proxy 8 echo Acquire : : http : : Proxy http : / / 1 2 7. 0. 0. 1 : 8 0 8 0 ; > / e t c / apt / apt. conf. d/ proxy 30

CHAPITRE 3. SCRIPTS ET MODULES DÉVELOPPÉS clients config.sh 1 #! / bin / bash 2 # = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 3 #C o n f i g u r a t i o n des machines c l i e n t e s 4 # = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 5 gateway = / sbin / ip route awk / d e f a u l t /{ p r i n t $3 } 6 puppetmaster = sed n 1 p couple 7 ip puppetmaster = arp $puppetmaster cut d f 2 cut d ( f 2 cut d ) f1 8 p u p p e t c l i e n t = sed n 2 p couple 9 i p p u p p e t c l i e n t = hostname i 10 num= sed n 3 p couple 11 r o l e = sed n $num p r o l e s 12 13 echo s e r v e r=puppet. ptut grid5000. lan >> / e t c / puppet / puppet. conf 14 15 echo >> / e t c / h o s t s 16 echo #ajout IP puppet >> / e t c / h o s t s 17 echo $ip puppetmaster puppet puppet. ptut grid5000. lan >> / e t c / h o s t s 18 echo $ i p p u p p e t c l i e n t $ r o l e $ r o l e. ptut grid5000. lan >> / e t c / h o s t s 19 20 dns= sed n 2 p p u p p e t c l i e n t s 21 i p d n s = arp $dns cut d f 2 cut d ( f 2 cut d ) f1 22 23 echo nameserver $ i p d n s > / e t c / r e s o l v. conf 24 echo nameserver $gateway >> / e t c / r e s o l v. conf 25 26 echo $ r o l e. ptut grid5000. lan > / e t c /hostname 27 / e t c / i n i t. d/hostname. sh s t a r t 28 29 30 e x i t 0 master config.sh 1 #! / bin / bash 2 # = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 3 #C o n f i g u r a t i o n du s e r v e u r puppet maitre 4 # = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 5 puppetmaster = sed n 1p p u p p e t c l i e n t s 6 echo s e r v e r=puppet. ptut grid5000. lan >> / e t c / puppet / puppet. conf 7 echo [ master ] >> / e t c / puppet / puppet. conf 8 echo certname=puppet. ptut grid5000. lan >> / e t c / puppet / puppet. conf 9 echo >> / e t c / h o s t s 10 echo #ajout IP puppet >> / e t c / h o s t s 11 12 #ajout des h o s t s c l i e n t s 13 y=1 14 f o r r o l e in puppet dhcp dns mysql n f s oar s e r v e r oar frontend kadeploy 15 do 16 node= sed n $y p p u p p e t c l i e n t s 17 ip node = arp $node cut d f 2 cut d ( f 2 cut d ) f1 18 echo $ip node $ r o l e $ r o l e. ptut grid5000. lan >> / e t c / h o s t s 31

CHAPITRE 3. SCRIPTS ET MODULES DÉVELOPPÉS 19 y=$ ( ( $y+1) ) 20 done 21 22 #a t t r i b u t i o n des r o l e s aux c l i e n t s et ajout des c l i e n t s dans nodes. pp 23 echo node puppet. ptut grid5000. lan { i n c l u d e apache } >> / e t c / puppet / m a n i f e s t s / nodes. pp 24 j=2 25 f o r r o l e in dhcp dns mysql n f s oar s e r v e r oar frontend kadeploy 26 do 27 node= sed n $ j p p u p p e t c l i e n t s 28 echo node $ r o l e. ptut grid5000. lan { i n c l u d e $ r o l e } >> / e t c / puppet / m a n i f e s t s / nodes. pp 29 j=$ ( ( $ j +1) ) 30 done 31 echo import nodes. pp >> / e t c / puppet / m a n i f e s t s / s i t e. pp 32 33 # = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 34 #C o n f i g u r a t i o n des f i c h i e r s pour l e module DHCP 35 # = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 36 y=1 37 f o r r o l e in puppet dhcp dns mysql n f s oar s e r v e r oar frontend kadeploy 38 do 39 node= sed n $y p p u p p e t c l i e n t s 40 host name= echo $node cut d. f1 41 sed i s / $host name / $ r o l e /g / e t c / puppet / modules /dhcp/ f i l e s /dhcpd. conf 42 y=$ ( ( $y+1) ) 43 done 44 45 sed i s /nancy. grid5000. f r / ptut grid5000. lan /g / e t c / puppet / modules /dhcp/ f i l e s /dhcpd. conf 46 47 # = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 48 #C o n f i g u r a t i o n des f i c h i e r s pour l e module DNS 49 # = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 50 gateway = / sbin / ip route awk / d e f a u l t /{ p r i n t $3 } 51 puppet= sed n 1p p u p p e t c l i e n t s 52 i p c o m p l e t e = arp $puppet cut d f 2 cut d ( f 2 cut d ) f1 53 54 dns= sed n 3 p p u p p e t c l i e n t s 55 i p d n s = arp $dns cut d f 2 cut d ( f 2 cut d ) f1 56 57 echo nameserver $ i p d n s > / e t c / r e s o l v. conf 58 echo nameserver $gateway >> / e t c / r e s o l v. conf 59 sed i s / 1 3 1. 2 5 4. 2 0 3. 2 3 5 / $gateway /g / e t c / puppet / modules /dns/ f i l e s /named. conf. o p t i o n s 60 61 echo zone echo $ ip c omplete cut d. f3. echo $ip complete cut d. f2. echo $ip complete cut d. f1. in addr. arpa { >> / e t c / puppet / modules /dns/ f i l e s /named. conf. l o c a l 62 echo type master ; >> / e t c / puppet / modules /dns/ f i l e s /named. conf. l o c a l 63 echo n o t i f y no ; >> / e t c / puppet / modules /dns/ f i l e s /named. conf. l o c a l 64 echo f i l e / e t c / bind /db. r e v e r s ; >> / e t c / puppet / modules /dns/ f i l e s / named. conf. l o c a l 65 echo } ; >> / e t c / puppet / modules /dns/ f i l e s /named. conf. l o c a l 66 32