Installation et Configuration Centralisées et Automatisées · CERN-THESIS-2012-127 07/09/2012 Installation et Configuration Centralisées et Automatisées d’une Ferme de Serveur

CER

N-T

HES

IS-2

012-

127

07/0

9/20

12

Installation et Configuration

Centralisées et Automatisées

d’une Ferme de Serveur sous SLC6

Institut Supérieur

d’Informatique,

de Modélisation

et de leurs Applications

BP 10125

63173 Aubière Cedex

Stéphane Tourneyre Rapport de Stage de 2eme Année Filière Réseau et Télécommunication 2 Avril – 31 Aout 2012

Tuteur CERN : Niko Neufeld Tuteur ISIMA : Emmanuel Mesnard

Organisation Européenne

pour la Recherche Nucléaire

F-01631 CERN Cedex

Remerciements

Je tiens à remercier :

Niko Neufeld, mon tuteur, pour la confiance qu’il a placé en moi, sa

bonne humeur et sa disponibilité malgré son emploi du temps

chargé.

Loïc Brardra pour le temps qu’il m’a accordé pour répondre à mes

(trop ?) nombreuses questions

L’équipe du LHCb qui m’a permis de mieux comprendre le

fonctionnement du CERN et du LHCb en particulier

Monsieur Menard qui a permis d’ouvrir la brèche et de donner la

chance à des stagiaires de l’ISIMA de pouvoir effectuer leur stage au

sein du CERN

Résumé

Ce rapport a pour but de présenter une étude du changement du système

d’installation et de configuration de serveurs Linux équipés de la distribution

Scientific Linux CERN (SLC) au sein de l’expérience LHCb du CERN. Ces serveurs

servent essentiellement à trier les données en sortie des différents capteurs des

détecteurs de collisions de protons.

Il était prévu d’étudier une solution à base des logiciels Cobbler/Puppet

pour remplacer le logiciel existant, Quattor, pour permettre d’installer et de

configurer de façon automatique. Tout d’abord, ces tests devaient se faire sur

des machines virtuelles puis mettre ces outils en condition réelle avec des

machines sans disque dur, comme celles en production.

À l’heure actuelle, l’utilisation du logiciel pour permettre la configuration

automatise Puppet fonctionne et correspond aux attentes du responsable du

projet, Niko Neufeld. Concernant Cobbler, après différents tests, il ne parvient

pas à combler totalement nos attentes. C’est pourquoi une étude approfondie

doit être continuée soit en trouvant un autre logiciel, soit en adaptant Cobbler.

Pour la partie des machines sans disque dur, elle devrait pouvoir être finie

avant la fin du stage.

Mot clé : installation et configuration automatisée, Cobbler, Puppet,

Quattor, sans disque dur.

Abstract

This report aims to present a study of the change of system installation

and configuration of Linux servers with the distribution of Scientific Linux CERN

(SLC) within the LHCb experiment at CERN. These servers are primarily used to

sort the output data of various sensors detectors proton collisions.

It was planned to explore a solution based software Cobbler / Puppet to

replace the existing software, Quattor, to help install and configure

automatically. First, these tests should be done on virtual machines and then

putting these tools in real conditions with machines without hard disk, such as

those in production.

Currently, the use of software to allow configuration automates Puppet

works and meets the expectations of the project manager, Niko Neufeld. Cobbler

on, after various tests, it fails to meet our expectations fully. Therefore a

thorough study should be continued or finding another software or by adapting

Cobbler.

For the part of the machines without hard disk, it should be done before

the end of the course.

Keyword: automated installation and configuration, Cobbler, Puppet,

Quattor, diskless.

Tables des matières

REMERCIEMENTS ....................................................................................III

RESUME .................................................................................................. IV

ABSTRACT ................................................................................................. V

TABLES DES MATIERES ........................................................................... VI

TABLE DES FIGURES .............................................................................. VII

GLOSSAIRE ............................................................................................. IX

INTRODUCTION ...................................................................................... 11

I. LE CONTEXTE ................................................................................... 12

1) Le CERN ............................................................................................... 12

2) Le LHC ................................................................................................. 13

3) LHCb .................................................................................................... 14

4) L’avenir de l’informatique au CERN ...................................................... 16

5) Le projet .............................................................................................. 17

II. CONFIGURATION AUTOMATISEE AVEC PUPPET ............................ 19

1) Définition de Puppet ............................................................................ 19

2) Principe de Puppet ............................................................................... 20

3) Configuration au LHCb : ....................................................................... 33

III. INSTALLATION AUTOMATISEE AVEC COBBLER ............................. 38

1) Définition de Cobbler ........................................................................... 38

2) Principe de Cobbler .............................................................................. 39

IV. INTERCONNEXION PUPPET – COBBLER ........................................ 49

1) Lien entre Puppet et Cobbler ............................................................... 49

2) Remplacement de Cobbler ? ................................................................. 50

3) Razor ................................................................................................... 50

4) La solution ........................................................................................... 56

V. MACHINE DISKLESS ......................................................................... 60

1) Principe ............................................................................................... 60

2) Problèmes ............................................................................................ 62

3) Diskless avec Cobbler .......................................................................... 63

CONCLUSION .......................................................................................... 64

REFERENCES BIBLIOGRAPHIQUES .......................................................LXVI

Table des figures

FIGURE 1 : LE LHC DANS LE PAYS DE GEX ............................................................................ 13 FIGURE 2 : LE DETECTEUR ET UNE PARTIE DE L'EQUIPE DU LHCB ........................................... 14 FIGURE 3 : SERVEURS FAISANT PARTIE DE LA FERME ............................................................ 15 FIGURE 4 : EXEMPLE DE LANGAGE PAN DE QUATTOR ............................................................. 16 FIGURE 5 : PLANNING PREVISIONNEL .................................................................................. 18 FIGURE 6 : EXEMPLE D'ENTREPRISE UTILISANT PUPPET ......................................................... 20 FIGURE 7 : INSTALLATION DU PACKAGE PUPPET-SERVER ....................................................... 20 FIGURE 8 : INSTALLATION DU PACKAGE CLIENT .................................................................... 20 FIGURE 9 : STRUCTURE DE PUPPET ...................................................................................... 21 FIGURE 10 : FICHIER PUPPET.CONF ..................................................................................... 21 FIGURE 11 : FICHIER NODE.PP ............................................................................................ 22 FIGURE 12 : CHOIX DU MODULE EN FONCTION DU NŒUD ...................................................... 23 FIGURE 13 : PREMIERE CONNEXION D'UN CLIENT VU PAR LE SERVEUR .................................... 24 FIGURE 14 : PREMIERE CONNEXION D’UN CLIENT VU PAR LE CLIENT ....................................... 24 FIGURE 15 : FONCTIONNEMENT DE PUPPET .......................................................................... 25 FIGURE 16 : STRUCTURE D'UNE RESSOURCE ........................................................................ 26 FIGURE 17 : CONFIGURATION DE YUM ................................................................................. 26 FIGURE 18 : STRUCTURE MODULE PUPPET ............................................................................ 27 FIGURE 19 : FICHIER INIT.PP DU MODULE PUPPET ................................................................. 27 FIGURE 20 : FICHIER INSTALL DU MODULE PUPPET ............................................................... 27 FIGURE 21 : FICHIER SERVICE DU MODULE PUPPET ............................................................... 28 FIGURE 22 : UTILISATION DE VARIABLE DANS PUPPET .......................................................... 28 FIGURE 23 : RESULTAT DE LA COMMANDE FACTER ................................................................ 28 FIGURE 24 : CHOIX D'UNE CLASSE EN FONCTION DE L'OS ..................................................... 29 FIGURE 25 : EXEMPLE DE FICHIER TEMPLATE ........................................................................ 29 FIGURE 26 : FICHIER TEMPLATE MACHINE A ......................................................................... 29 FIGURE 27 : FICHIER TEMPLATE MACHINE B ......................................................................... 29 FIGURE 28 : STRUCTURE DE PUPPET AVEC TROIS ENVIRONNEMENTS ...................................... 30 FIGURE 29 : ENVIRONNEMENTS DANS LE FICHIER PUPPET.CONF ............................................ 30 FIGURE 30 : EXECUTION DE PUPPET DANS UN ENVIRONNEMENT PARTICULIER ......................... 30 FIGURE 31 : EXECUTION DE PUPPETMASTER ......................................................................... 31 FIGURE 32 : EXECUTION DE PUPPET CLIENT ......................................................................... 32 FIGURE 33 : EXECUTION DU SCRIPT SITE.PP ........................................................................ 32 FIGURE 34 : EXEMPLE DE MODULE DISPONIBLE SUR LE SITE PUPPET FORGE ........................... 33 FIGURE 35 : LIGNE DE COMMANDE PARAMETRANT LE PROXY .................................................. 35 FIGURE 36 : FICHIER /ETC/BASHRC ..................................................................................... 35 FIGURE 37 : STRUCTURE DU FICHIER NODE.PP ..................................................................... 35 FIGURE 38 : ARBORESCENCE DU MODULE PROXY .................................................................. 36 FIGURE 39 : STRUCTURE DU FICHIER INIT.PP DU MODULE PROXY ........................................... 36 FIGURE 40 : STRUCTURE DU SCRIPT DU MODULE PROXY ....................................................... 37 FIGURE 41 : SEQUENCE DE DEMARRAGE D'UN CLIENT ........................................................... 39 FIGURE 42: CONFIGURATION DHCP DU POSTE CLIENT1 ......................................................... 40 FIGURE 43 : TENTATIVE DE RECUPERATION DU FICHIER PXELINUX.CFG .................................. 40 FIGURE 44 : COBBLER ........................................................................................................ 41 FIGURE 45 : INSTALLATION DE COBBLER ............................................................................. 42 FIGURE 46 : FICHIER SEETINGS DE COBBLER ....................................................................... 43 FIGURE 47 : GESTION DU DHCP PAR COBBLER ...................................................................... 43 FIGURE 48 : CHOIX DU SERVEUR DHCP DANS MODULE.CONF ................................................. 43 FIGURE 49 : TEMPLATE DU FICHIER DHCPD.CONF ................................................................. 44 FIGURE 50 : FICHIER KICKSTART ......................................................................................... 45 FIGURE 51 : IMPORT D'UN REPOSITORY SOUS COBBLER ........................................................ 45 FIGURE 52 : SYNCHRONISATION DES REPOSITORY ............................................................... 46

FIGURE 53 : IMPORTATION DE LA DISTRIBUTION SLC6 DEPUIS LE FICHIER BOOT.ISO .............. 46 FIGURE 54 : STRUCTURE D'UN PROFIL ................................................................................. 46 FIGURE 55 : AJOUT D'UN SYSTEM ........................................................................................ 47 FIGURE 56 : RESULTAT DE LA COMMANDE COBBLER SYNC ..................................................... 47 FIGURE 57 : CLIENT RECUPERANT DES FICHIERS SUR LE SERVEUR PXE .................................. 48 FIGURE 58 : MANAGEMENT CLASSES AU SEIN DE COBBLER .................................................... 49 FIGURE 59 : REPONSE DU SCRIPT EN FONCTION D'UN CLIENT ................................................ 49 FIGURE 60 : CONFIGURATION DU FICHIER PUPPET.CONF ....................................................... 49 FIGURE 61 : SCRIPT EXTERNAL ........................................................................................... 50 FIGURE 62 : RAZOR DISCOVERY .......................................................................................... 51 FIGURE 63 : LISTE DES NŒUDS SUR RAZOR ......................................................................... 52 FIGURE 64 : ATTRIBUT D'UN NODE SUR RAZOR .................................................................... 52 FIGURE 65 : RAZOR TAGGING ............................................................................................. 53 FIGURE 66 : RAZOR POLICY ................................................................................................ 54 FIGURE 67 : RAZOR POLICY ................................................................................................ 54 FIGURE 68 : RAZOR BROKER ............................................................................................... 55 FIGURE 69 : LISTE DES BROKER .......................................................................................... 55 FIGURE 70 : POLITIQUES SUR RAZOR AVEC "BROKER" ........................................................... 55 FIGURE 71 : AJOUT D'UNE MACHINE SUR COBBLER ............................................................... 56 FIGURE 72 : FICHIER SITE.PP .............................................................................................. 57 FIGURE 73 : FICHIER CLIENT1.LBDAQ.CERN.CH.PP ................................................................ 57 FIGURE 74 : FICHIER KICKSTART AVEC SCRIPT PHP .............................................................. 58 FIGURE 75 : SCRIPT PHP POUR CREER LE FICHIER HOSTNAME.PP ........................................... 58 FIGURE 76 : SERVEUR CENTRAL ET CLIENT DISKLESS ........................................................... 60 FIGURE 77 : LISTE DES DOSSIERS DU SERVEUR CENTRAL DISKLESS ...................................... 61 FIGURE 78 : LISTE DES DOSSIERS SPECIFIQUE MACHINE DISKLESS ....................................... 62 FIGURE 79 : DIAGRAMME DE GANT FINAL ............................................................................. 65

Glossaire

Annuaire: Système de stockage de données

Antimatière: Particule en opposition de la matière qui devrait être

en égal quantité en théorie mais qui se révèle en total asymétrie

dans l’univers. Le LHCb devrait réussir à répondre a cette question

Cloud Computing: Concept de déportation sur des serveurs

distants les serveurs ou postes clients locaux

Cobbler: Logiciel d’installation automatisée et centralisée

DHCP: Logiciel fournissant automatiquement une adresse IP aux

machines qui le demande

Diskless: Machine sans disque dur

DNS: Protocole permettant de relier une adresse IP d’une machine à

son nom

HTTP: Langage des sites web. Souvent utilisé pour un logiciel de

serveur web ( exemple : Apache, IIS, WEBrick )

IP: Adresse unique sur un réseau d’une machine permettant la

communication avec les autres machines

Kickstart: Fichier de réponse automatique lors de l’installation des

distributions RedHat/Fedora

Ldap: Protocole utilisé pour l’interrogation et la modification

d’annuaire. Les plus connus sont Active Directory et OpenLDAP

Linux: Système d’exploitation (OS pour Operating System ) très

prisé des laboratoires de recherche de par sa gratuité et son

ouverture. Deux distributions en sont dérivées : RedHat / Fedora et

associé ( CentOS, Scientific Linux) et Debian/Ubuntu

OpenStack: Solution logiciel permettant de gérer un Cloud

Computing

Packages: Archive comprenant les fichiers nécessaires à

l’installation d’un logiciel

Puppet: Logiciel de configuration automatisée et centralisée

Quattor: Logiciel d’installation et de configuration automatisées et

centralisées

Repository: Stockage centralisé de package

Serveur web : machine permettant à des clients d’afficher un site

web via des requêtes HTTP

Template: Utilisation d’un fichier générique pour la création d’un

fichier spécifique grâce à des variables

TFTP: Protocole de serveur de fichier

Virtualbox: logiciel de virtualisation de poste client

Virtualisation: Concept permettant de simuler un système

d’exploitation sur une machine physique

VMware: Solution logiciel de virtualisation

Yum: Gestionnaire de paquets Linux pour les distributions

RedHat/Fedora

Introduction

Page 11

Introduction

Afin de traiter tous les résultats obtenus des nombreux capteurs lors des

collisions au sein du LHC, l’expérience LHCb du CERN a besoin d’une puissance

de calcul phénoménal : une ferme de serveurs de plus de deux mille machines.

Pour administrer toutes ces machines, il est indispensable d’avoir des

outils adaptés et surtout qui permettent une automatisation la plus poussée

possible.

Pour installer et configurer les machines de façon centralisée et

automatisée, les administrateurs système utilisent le logiciel Quattor. Malgré de

nombreux atouts, il n’est plus adapté aux besoins futurs du CERN et en

particulier de l’expérience LHCb. C’est pourquoi il est important d’anticiper et de

trouver une solution équivalente. C’est le sujet de mon stage.

Ce rapport comporte quatre parties :

Avant de changer quoi que ce soit, il est très important de connaitre

l’existant. C’est pourquoi une présentation détaillée du contexte est effectuée

avec les différentes solutions possibles.

Puis une étude du logiciel Puppet qui sert à automatiser et centraliser les

configurations des différents serveurs.

Enfin, je vais mettre en place le logiciel Cobbler pour l’installation des

machines et voir s’il arrive bien à s’interconnecter avec Puppet.

Ceci est une première version du rapport de stage : la version finale

définitive devrait comporter une partie sur les machines sans disque dur.

Le Contexte

Page 12

I. Le Contexte

1) Le CERN

Question : Quel est l’endroit le plus chaud et à la fois le plus froid sur

terre?

Réponse : au LHC du CERN

Avec une température de -271degrés pour pouvoir utiliser des

supraconducteurs et une autre de plus de 10 millions de degrés lors des

collisions des protons, le LHC du CERN nous prouve encore une fois que c’est une

merveille de technologie.

Crée en 1954 à la suite de la 2eme guerre mondiale, l’Organisation

Européenne pour la Recherche Nucléaire (l’acronyme CERN vient du 1er nom

Conseil Européen pour la recherche nucléaire) est le plus grand centre de

physique du monde. Situé sur la frontière entre la France et la Suisse, près de

Genève, c’est la plus grande concentration de physiciens du monde avec plus de

quatorze mille personnes sur le site lors des grandes affluences.

Le CERN a quatre buts principaux :

Recherche fondamentale de physique :

Grâce à l’accélérateur de particules Large Hadron Collider (Grand

Collisionneur de Hadron - LHC), des collisions entre différentes particules

permettent de recréer les instants qui ont succédé au Bigbang et ainsi mieux

connaitre la physique. La conférence sur la découverte du Boson de Higgs du 4

juillet 2012 est le parfait exemple.

Faire avancer la science

Toutes les découvertes du CERN sont publiques et gratuites. C’est ainsi

que le protocole HTTP inventé en 1989 par Tim Berners Lee a permis à Internet

de se démocratiser. Mais aussi le système de grille de calcul qui permet de

répartir des calculs informatiques lourds entre plusieurs dizaines, centaines ou

même milliers de machines.

Former les scientifiques de demain

En permettant à des stagiaires ou des étudiants de pouvoir continuer leurs

apprentissages ici, le CERN s’assure de former les générations futures.

Le Contexte

Page 13

Collaboration entre les différents pays

À sa façon le CERN, collabore pour la paix dans le monde. En effet, les

différents scientifiques travaillent ensemble et mettent de côté leurs différents

pour faire avancer la science.

Le financement du CERN provient essentiellement des douze états

fondateurs (Allemagne, France, Danemark, Italie, Norvège etc....), des douze

autres états membres qui les ont rejoints au fil du temps (Pologne, Bulgarie,

Portugal etc....) mais aussi d’autres états observateurs (Inde, Japon, Turquie

etc...).

2) Le LHC

Basé sur la structure de l’ancien Grand collisionneur de positons et

d’électrons (le LEP), le LHC est le plus puissant accélérateur de particules du

monde et cela devrait encore s’accroitre avec la montée en puissance prévue

pour l’année 2013.

Le principe du LHC est très simple : envoyer des protons dans un anneau

large de vingt-sept kilomètres à une vitesse proche de celle de la lumière et

examiner les collisions des particules au sein de différents détecteurs. Le but est

de confirmer ou non certaines théories et de comprendre la naissance de la

physique fondamentale.

On peut trouver quatre grandes expériences qui correspondent chacune à

un détecteur différent : ATLAS, CMS, ALICE et LHCb.

Figure 1 : Le LHC dans le pays de Gex

Le Contexte

Page 14

3) LHCb

LHCb pour Large Hadron Collider beauty

Le but de l’expérience LHCb est d’étudier la particule de Beauté qui

permettrait d’expliquer pourquoi il y a une dissymétrie entre la matière et

l’antimatière dans l’Univers. L’expérience regroupe près de sept cents physiciens

et autres issus de quinze pays.

Figure 2 : le Détecteur et une partie de l'équipe du LHCb

Le détecteur est en réalité constitué de plusieurs sous détecteurs

permettant chacun de capturer des informations sur une particule (Calorimètre,

Rich etc...) et le flux de données en sortie est très important : 50mo/s pour

chaque collision. Etant donné qu’il y a quatre millions de collisions par seconde, il

est impératif de pouvoir trier ces informations avant que les physiciens puissent

travailler sur les résultats.

Ce tri s’effectue via deux niveaux (le niveau zéro et le niveau un) et

permet de séparer le bruit des données intéressantes.

Le niveau zéro (Level 0 Trigger) est constitué de cartes électroniques

spécialisées qui permettent de passer de quatre millions d’événements à 2

millions.

Le niveau un (HLT pour Hight Level Trigger) est constitué d’une ferme de

plus de deux mille serveurs. La particularité de ces serveurs est d’être diskless

(sans disque) et ils utilisent des stockages réseaux pour fonctionner. Cinquante

de ces serveurs sont utilisés pour gérer jusqu’à vingt-sept nœuds (serveurs

clients)

Le Contexte

Page 15

Figure 3 : Serveurs faisant partie de la ferme

Ce triage permet de passer de quatre Millions d’évènements à deux mille.

Ces données sont traitées par les physiciens ensuite.

À l’heure actuelle, ces serveurs sont sous la distribution Linux SLC 5

(Scientifique Linux CERN version 5) dérivée de RHEL 5 (Red Hat Entreprise Linux

version 5).

Avec une équipe d’administration réduite, il est indispensable d’avoir des

outils permettant une automatisation d’installations et de configurations des

machines Linux. Le choix du CERN et du LHCb en particulier s’est porté sur

Quattor.

Quattor est un logiciel Open Source fonctionnant sous Linux basé sur un

langage descriptif spécifique, le Pan. C’est un langage compilé : avant de

déployer une machine, un fichier XML est créé contenant l’ensemble des

configurations à mettre en place.

Il existe peu d’entités utilisant Quattor : principalement le CERN et la

banque Margan Stanley. De par ce fait, la communauté autour de Quattor n’est

pas très importante.

Le Contexte

Page 16

Figure 4 : Exemple de langage PAN de Quattor

Avantages de Quattor :

Langage facile à prendre en main

Modularité des composants

Code ouvert

Inconvénients :

Communauté restreinte

Gestion des packages (l’installation de packages se fait via un fichier

RPM et il faut gérer manuellement ses dépendances).

Malgré le fait que Quattor soit plutôt bien adapté au système d’information

du CERN, il reste néanmoins perfectible.

4) L’avenir de l’informatique au CERN

Les différentes expériences sont des services informatiques indépendants

les uns des autres, mais aussi du service informatique général du CERN

(généralement appelle IT pour Information Technologique). Malgré leur

indépendance, chacun s’inspire des autres et ainsi tout le monde marche plus ou

moins dans le même sens, ou au moins, essaye les technologies sans forcément

y adhérer.

C’est dans cette optique que le LHCb a commencé une réflexion sur le

changement du système d’information :

Le Contexte

Page 17

Les besoins techniques de l’IT et des expériences sont en constantes

évolution en terme de puissance de calcul sans devoir augmenter le personnel

dédié. La solution retenue est de délocaliser un certain nombre de serveurs dans

un Datacenter à Budapest en Hongrie. La gestion physique sera faite par une

équipe sur place quand la gestion des logiciels (administration des serveurs) sera

toujours effectuée par les équipes du CERN. De plus, cela permet de passer tous

les serveurs en virtualisation ce qui ajoute en flexibilité et réduit les coûts. Ce

système d’infrastructure déportée est ce qu’on appelle de nos jours le “Cloud

computing“.

Malheureusement, en plus des inconvénients précédemment cités, Quattor

gère très mal les machines virtuelles. C’est pourquoi une réflexion s’est portée

sur un outil permettant la configuration mais aussi sur un outil de service

d’infrastructure.

De plus, la migration de SLC à SLC6 à court et moyen terme est un facteur

déclenchant pour le changement d’infrastructure.

Même si les besoins de virtualisation sont moindres voir quasi nuls au sein

du LHCb, il est quand même intéressant de se faire la même réflexion afin de

faire évoluer leur système.

5) Le projet

Le but du projet est de tester un des outils d’installation de serveurs et un

outil de gestion de configuration ainsi que d’étudier leurs intégrations au sein de

la ferme de calculs.

Il est prévu que ces outils soient mis en production suite à ce projet.

a) Le choix des outils

Il n’existe pas des millions d’outils pour gérer un Cloud comme celui du

CERN. De plus, de par sa nature de service public, d’ouverture et de coûts, cet

outil doit être un logiciel libre.

OpenStack est naturellement imposé de par sa pérennité (de nombreux

organisations/entreprises ont choisi OpenStack : la NASA à l’ origine du projet

mais aussi AT&T, Korea Telecom, HP Public Cloud etc...) mais aussi pour sa

modularité (l’ensemble des outils sont interopérable avec les grandes solutions

de virtualisation du marché : VM Ware, HV de Microsoft etc...). OpenStack

commence à s’imposer de plus en plus dans le Cloud.

Concernant la gestion de configuration, étant donné que cela devait

remplacer Quattor, il était judicieux de trouver un logiciel ayant la même

philosophie : déclaratif, etc... Tout en comblant ses inconvénients : gestion des

packages avancée, communautés actives etc...

Le Contexte

Page 18

Tout comme OpenStack, un logiciel s’est plus ou moins imposé, surtout

pour sa complémentarité avec OpenStack : Puppet de PuppetLabs. Il existe

d’autres logiciel comme Chef ou CFEngine mais ils sont soit trop jeunes soit dans

une autre approche que Quattor, mais au cas où Puppet ne convienne pas, il

serait intéressant de les regarder de plus près.

Pour l’installation des serveurs, aucun outil n n’a été privilégié par rapport

à un autre. Il m’incombe de trouver la solution s’intégrant le plus possible avec

Puppet. Mon tuteur m’a conseillé d’étudier en premier le logiciel Cobbler. Si celui-

ci ne convenait pas, je devrais étudier les différentes solutions.

L’ensemble de mes tests se sont effectués soit sur des machines virtuelles

locales sous VirtualBox, soit sur des machines virtuelles RedHat : RedHat

Entreprise Virtualization (c’est un hyperviseur permettant de manager ces

machines virtuelles).

Le plus gros du travail n’est finalement pas la mise en place de ces outils

mais surtout de comprendre leurs fonctionnements.

b) Diagramme de Gantt :

Figure 5 : Planning prévisionnel

Ce planning se décompose en 4 grandes parties avec chacune une partie

découverte du produit, test sur une machine virtuel local et test sur une machine

virtuel de production :

Puppet

Cobbler

Machine Diskless

Résultats Finaux

Configuration automatisée avec Puppet

Page 19

II. Configuration automatisée avec

Puppet

Un dicton dans l’administration système et réseau dit “ Plus tu ruses,

moins tu t’uses”.

1) Définition de Puppet

C’est exactement cela que permet Puppet : ruser pour éviter les tâches

répétitives grâce à un outil d’administration centralisé de parc de machines pour

automatiser, harmoniser et homogénéiser les configurations pour gagner du

temps, de la flexibilité et des performances. Certes au départ cela demande un

travail supplémentaire pour déclarer l’ensemble des machines. Mais une fois ce

travail fait, l’ajout d’une nouvelle machine est plus beaucoup plus rapide et

surtout, on est sûr que chaque machine a la bonne configuration.

L’inconvénient d’un tel système est que lorsque la configuration est bonne,

cela marche très bien mais lors d’une erreur, ce n’est plus une machine mais

potentiellement l’ensemble du parc qui peut être impacté. C’est pourquoi c’est un

outil à magner avec délicatesse.

Ecrit en langage RUBY sous licence GPLv2, la version actuelle est la 2.7 et

est diffusée/écrite par PuppetLabs depuis 2005. Le serveur et le client

fonctionnent avec Linux mais Puppet n’est pas seulement limité au monde linux

(Debian / RedHat) : il existe un client pour les machines MacOs et, fait très

intéressant, Windows. L’ensemble de la documentation et des ressources se

trouvent sur le site officiel de Puppet [1]. De plus, un ouvrage m’a grandement

aidé : ProPuppet [2].

De nombreuses sociétés, dont certaines parmi les plus grandes du monde

internet, utilisent Puppet et en font la promotion ce qui lui garantit une durée de

vie confortable.


Page 20

Figure 6 : Exemple d'entreprise utilisant Puppet

2) Principe de Puppet

Philosophie : Ne pas dire comment, dire quoi faire.

a) Installation de Puppet

Sur une distribution SLC, une ligne de commande permet d’installer le

PuppetMaster ou l’agent avec toutes ses dépendances :

Figure 7 : Installation du package puppet-server

Figure 8 : Installation du package client

Parmi ses dépendances, on retrouve les packages Ruby qui permettent

d’interpréter Puppet mais aussi un package Facter qui fournira les « facts » du

client (expliqué après)


Page 21

b) Structure de Puppet

Figure 9 : Structure de Puppet

Ci-dessus, on trouve la structure de base de Puppet en incorporant un

module Yum.

Les fichiers de configuration se trouvent à la racine de puppet dans

/etc/puppet : puppet.conf, auth.conf et autosign.conf.

Le fichier puppet.conf contient la configuration utilisée par Puppet, que ce

soit le client (partie [agent]), le serveur (partie [master]) ou pour les deux

(partie [main]). C’est ici qu’est spécifié, s’il y a besoin, le nom du serveur,

l’intervalle entre chaque demande du client au serveur, etc..... . Dans notre cas,

la configuration par défaut nous convient.

Figure 10 : Fichier puppet.conf

Le fichier auth.conf permet de spécifier quel client (appelé Nœud) aura

accès à quel module. Dans notre cas, on laisse les paramètres par défaut : tous

les nœuds auront accès à tous les modules.


Page 22

Le fichier autosign.conf gère l’auto signature de certificat pour la 1ere

connexion des clients. Il est possible de laisser ce fichier vide et ainsi, pour

chaque nœud, l’administrateur devra accepter manuellement le certificat. Dans

notre cas, nous allons auto signer toutes les machines ayant un hostname

*.lbdaq.cern.ch.

Les différentes configurations sont appelées Ressource, elles sont

regroupées en Class et sont écrites dans des Manifests (fichiers une extension

.pp)

Les deux principaux manifests sont dans /etc/puppet/manifests : site.pp et

node.pp.

Site.pp : Premier fichier à être lu par le serveur lors d’une demande

de configuration d’un client. Souvent utilisé pour mettre une

configuration de base.

Node.pp : Afin de savoir quelle configuration doit être appliquée tel

Nœud, on utilise le fichier node.pp ou est répertorié l’ensemble des

Noeuds du systeme. Un nœud peut hériter d’un autre nœud.

Figure 11 : Fichier node.pp

Ici notre nœud « virttest1006.lbdaq.cern.ch » va appliquer la classe razor

avec en paramètre « ruby_version » et va hériter du nœud « base » qui

appliquera le module Yum.

Les modules sont des classes qui peuvent être utilisées par les nœuds.

L’avantage d’utiliser les modules est que, en fonction du nœud, on peut appliquer

une configuration particulière en ayant une seule classe : la class razor sera

utilisé avec le paramètres « ruby_version = 1.8.7 ».On peut imaginer un autre

nœud avec un autre paramètre « ruby_version = 1.9.3 ».


Page 23

Figure 12 : Choix du module en fonction du nœud

PS : Il est important de configurer le pare-feu du client et du serveur pour

laisser passer les trames Puppet. Etant donné que les pare-feu des machines du

LHCb sont désactivés par défaut, il n’y a rien à changer. Si on veut garder le

pare feu activé, il faut autoriser le port 8240.

c) Déploiement

Sur un fonctionnement Client/Serveur, un agent installé sur le client

(appelé Nœud) va demander quelle configuration a adopté le serveur maitre

(appelé PuppetMaster). Une possibilité d’utiliser le client seul existe en utilisant

un script mais cela reste marginal et n’est pas approprié à notre besoin. Les

échanges se font grâce à une connexion HTTPS via un échange de clé SSL lors de

la première connexion du client. Cette première connexion demande une

autorisation du client sur le serveur (de façon automatique ou manuelle). Une

fois acceptée, le serveur ne fait plus cette demande.


Page 24

Figure 13 : Première connexion d'un client vu par le serveur

Figure 14 : Première connexion d’un client vu par le client

d) Traitement d’une configuration :

Plutôt que diffuser la configuration du serveur au client, ce sont les clients

qui viennent réclamer cette configuration. Cela peut porter sur un fichier, un

package, un service, etc... et sur son état : présent, absent, version pour les

packages etc... Il est possible de spécifier les intervalles entre les différentes

demandes de chaque client ou alors, passer par une tâche planifiée sur le client

afin de mieux anticiper les possibles montées en charge : avoir deux mille

demandes en même temps est diffèrent d’avoir deux mille clients répartis sur

deux heures pour le serveur.


Page 25

Une fois la demande autorisée par le serveur, ce dernier envoi la

configuration à l’agent et celui-ci l’applique: si la configuration du serveur est

identique à celle du client, aucune action n’est effectuée (exemple : un logiciel

déjà installé sur le client ne sera pas réinstallé). Par contre, si la configuration du

client est différente de celle du serveur, celui-ci appliquera la nouvelle

configuration. Ainsi, si on applique la même configuration à cinq minutes

d’intervalle à un client, son état restera le même : un package installé ne sera

pas ré installé si la version correspond à celle spécifiée par le serveur.

Voici le processus de configuration de chaque client :

1) Demande de configuration du client au serveur. Envoi de ses

« facts » en même temps

2) En fonction des informations du client, les ressources sont

interprétées et compilées

3) Envoi de la configuration compilée au client

4) Mise en place de cette configuration par le client avec appel aux

fichiers/Template au serveur si besoin

5) Envoi d’un rapport au PuppetMaster

Figure 15 : fonctionnement de Puppet


Page 26

e) Langage de configuration

Puppet utilise un langage déclaratif simple pour définir les Ressources. Le

fait que ce soit du déclaratif distingue Puppet des autres logiciels de

configuration. Par exemple, pour installer un package, plutôt que d’indiquer la

marche à suivre, on va seulement déclarer le logiciel que l’on veut installer et

Puppet va, en fonction de l’OS ou de la distribution, installer la bonne version

avec le bon installateur. Ainsi, on peut avoir une seule ressource pour plusieurs

OS. L’administrateur s’occupe seulement du “quoi” et plus du “comment”.

Figure 16 : Structure d'une ressource

Exemple de code de configuration :

Figure 17 : Configuration de Yum

Ici, on souhaite configurer Yum avec un fichier yum.conf et des Repository

spécifiques. Pour le fichier yum.conf, on remplace le fichier/etc/yum.conf par le

fichier se trouvant dans/etc/puppet/module/yum/files/yum.conf

Voici une liste des principaux types de Ressource, qui peuvent être

regroupés en classes, eux même regroupés en modules (qui regroupe les

différentes ressources et fichiers utilisés par les ressources si besoin) :

Fichier

Package


Page 27

Cron (tache planifié)

Exec (exécution d’une ligne de commande)

User (tout ce qui touche un utilisateur)

Group (tout ce qui touche un groupe)

Service

Nagios (pour la configuration du logiciel de monitoring Nagios)

Mount

Host (gère le fichier /etc/hosts)

Router (gère une interface d’un routeur ou un switch)

Etc…

Voici l’exemple d’un module Puppet avec plusieurs types de ressources :

Figure 18 : Structure module Puppet

Figure 19 : Fichier init.pp du module puppet

Le fichier init.pp sera le premier fichier lu lors de l’import du module

puppet. Ce manifests inclus le fichier install.pp (puppet ::install) et le fichier

service.pp (puppet ::service).

Figure 20 : Fichier install du module puppet

Le manifest puppet ::install utilise le type « package » pour installer le

client Puppet. Il n’y a pas besoin de spécifier l’installateur (Yum, Apt …), Puppet

s’occupe d’exécuter le code en fonction de l’OS.


Page 28

Figure 21 : Fichier service du module puppet

Il est possible de spécifier des variables qui seront utilisés dans les

ressources :

Figure 22 : Utilisation de variable dans Puppet

La variable $longthing est utilisée par la ressource file « authorized_keys »

afin de renseigner le fichier ssh. Cette variable peut très bien être déclarée

ailleurs, comme par exemple dans le fichier node.pp. Ainsi, chaque nœud peut

avoir une clé ssh autorisée particulière.

f) Utilisation des facts

Le package de PuppetLabs Facter est un outil d’inventaire system : il

retourne des “facts” ; des variables globales, du client telle que son adresse ip,

son hostname, son os et sa version etc... Ces “facts” peuvent être utilisés par

Puppet afin de servir de variable :

Figure 23 : Résultat de la commande Facter


Page 29

Exemple de code avec operating-system :

Figure 24 : Choix d'une classe en fonction de l'OS

Ici, en fonction de la distribution, on va appliquer la class apache-RedHat

ou apache-Debian.

g) Les fichiers Template

Nous avons vu que nous pouvons copier des fichiers depuis le serveur

Puppet. Ces fichiers sont figés et ne sont pas modifiables par Puppet.

Néanmoins, certains fichiers doivent être différents sur chaque machine, même

si une seule ligne les diffère. Plutôt que d’avoir un fichier par machine, il est

possible d’utiliser les Template.

Ces Template sont des fichiers qu’il y possible de modifier avec des

variables dans des manifests et des « facts ».

Figure 25 : Exemple de fichier Template

Notre exemple de fichier Template permet de créer un fichier sur chaque

nœud avec l’adresse ip du nœud en question.

Si l’IP de la machine A est 10.20.1.15, le fichier sera :

Figure 26 : Fichier Template machine A

Si l’IP de la machine B est 10.20.1.15, le fichier sera :

Figure 27 : Fichier Template machine B

h) Environnement :

Il est possible de séparer des environnements afin que ceux-ci s’adaptent

à nos besoins. Le meilleur exemple est un environnement de production, un de

test et un de développement. Ainsi, les changements de configuration dans

l’environnement de test n’impacte pas les autres environnements.


Page 30

Pour cela, il faut mettre en place une arborescence avec un dossier par

environnement diffèrent.

Figure 28 : Structure de Puppet avec trois environnements

Puis il faut spécifier dans le fichier puppet.conf l’emplacement des

environnements. :

Figure 29 : Environnements dans le fichier puppet.conf

Lors du lancement de l’agent, il faut spécifier l’environnement :

Figure 30 : Exécution de Puppet dans un environnement particulier


Page 31

Le cheminement dans la mise en place d’une nouvelle configuration :

1. Mise en place d’une nouvelle configuration dans l’environnement

« dev ».

2. Si la configuration convient pour une machine, on peut la copier

dans l’environnement « test » afin de faire des tests à plus grande

échelle.

3. Si ces tests sont concluants, on peut mettre en place la mise en

production sur l’ensemble des machines en copiant le contenu de

« test » dans « prod ».

Pour cela, le plus pratique est de mettre en place une solution avec GIT :

en plus de pouvoir gérer les versions des scripts, il pourra nous aider à utiliser

les environnements via des dossiers séparés.

i) Montée en puissance

En ayant un serveur et un client il est évident que nous n’avons pas de

problème de charge. Néanmoins, dans un domaine de production, il n y’a plus un

client mais plusieurs milliers et un seul serveur ne pourrait supporter la charge.

Pour gérer cela, nous avons différentes possibilités :

changer le serveur HTTP utilisé (WEBrick) par un serveur Apache

multiplier les PuppetMaster.

utiliser un ou plusieurs serveurs pour isoler la fonction PuppetCA qui

authentifie les clients

Nous savons que cela est possible et que c’est utilisé par de nombreux

utilisateurs. C’est pourquoi un tel dispositif ne fera pas partie du stage,

sauf si le temps me le permet.

j) Exécution de Puppet

Afin de procéder aux différents tests, nous voulons que les processus

PuppetMaster et Agent ne soient pas utilisés en tant que démon et aussi que la

sortie soit détaillée, nous utilisons la commande suivante :

D’abord le PuppetMaster :

Figure 31 : Exécution de PuppetMaster


Page 32

Figure 32 : Exécution de Puppet Client

Notre client s’est connecté sur le serveur maitre et a exécuté la

configuration spécifiée par le fichier/etc/puppet/site.pp. Etant donné que ce

fichier est vide, la configuration n’a rien changé. Si on voulait lancer le script

directement sur le client sans devoir se connecter d’abord au serveur, on

utiliserait la commande suivante en spécifiant le script à utiliser :

Figure 33 : Exécution du script site.pp

k) Communauté Puppet

L’une des grandes forces de Puppet est sa communauté extrêmement

active.

Par active, il faut comprendre avec une entraide solide, du partage de

codes via des modules à installer ou des conférences comme lors des 13emes

Rencontre Mondiales du Logiciel Libre à Genève du 7 au 12 Juillet 2012

(conférences concernant Puppet faites par la société PuppetLabs mais aussi par

des utilisateurs donnant leur point de vue basé sur une expérience de plusieurs

années de Puppet).

Ces rencontres sur internet ou en vrai permettent de s’enrichir et en

retour, d’aider d’autres personnes.

Le site PuppetForge [3] rassemble les modules de la communauté.


Page 33

Figure 34 : Exemple de module disponible sur le site Puppet Forge

Concernant les modules, il existe même un outil de PuppetLabs pour

faciliter leur mise en place.

L’outil va se connecter sur le site PuppetForge regroupant tous les modules

mis à disposition et va récupérer les fichiers correspondants.

3) Configuration au LHCb :

Pour endommager une machine, une seule personne suffit. Pour

endommager une ferme de serveur, il faut passer par un outil de configuration

automatisé.

Un des buts du stage est de répondre à la question :

Est-ce que Puppet peut configurer les machines de la ferme pour obtenir le

même résultat que Quattor en apportant ses avantages ?

Pour répondre à cela, mon tuteur m’a donné un cahier des charges et en

fonction des résultats, nous aurons une réponse à cette question.

a) Configuration minimum

En fait, un serveur de la ferme n’a pas besoin de beaucoup de

configuration. Cela consiste en une installation de quelques package et de leur

paramétrage, de faire en sorte que l’on puisse se connecter en SSH et de monter

des dossiers.

Liste de packages à installer :

Openldap : implémentation libre du protocole LDAP

Autofs : contrôle les opérations des démons d’automount

Nss-pam-ldapd : permet de fournir des services de correspondance

entre hostname de toute sorte


Page 34

Cyrus-sasl-gssapi : contient les plugins Cyrus SASL supportant

l'authentification GSSAPI. GSSAPI est fréquemment utilisé pour

l'authentification Kerberos (protocole d’authenfication réseau)

Liste des configurations à implémenter :

Clé SSH

Paramétrage du proxy netgw01

Configuration du cache ldap

Configuration Kerberos pour LDAP

Configuration des recherches LDAP

Montage de deux dossiers réseau

Configuration du client NFS

Dans le monde linux, tout est fichier. Donc, on peut mettre en place ces

configurations en modifiant des fichiers ou en utilisant des types de ressources

de Puppet pour y arriver.

La façon la plus simple serait de copier les fichiers depuis une machine en

fonctionnement et les mettre au bon endroit. Mais, pour le faire dans les règles

de l’art, il serait préférable de récupérer les différents paramètres depuis les

fichiers de configuration de Quattor, en déduire les variables et créer des fichiers

génériques en utilisant les variables de Quattor comme des variables sur Puppet.

b) Exemple de configuration :

Configuration des tests :

Un serveur PuppetMaster sous SLC6

Deux clients sous SLC6

Avec un serveur et deux clients, il était simple de comparer la mise en

place d’une configuration.

Vous pourrez trouver ci-dessous un exemple de configuration que j’ai

appliqué.

Paramétrage du proxy Netgw01 :8080 :

Ce proxy permet d’avoir une porte ouverte sur Internet si on passe par lui.

Cela permet de restreindre certains accès si besoin. Pour cela, il existe plusieurs

façons de faire :


Page 35

Via une ligne de commande :

Figure 35 : ligne de commande paramétrant le proxy

Via le fichier /etc/bashrc

Figure 36 : fichier /etc/bashrc

Encore une fois, pour bien prendre en main Puppet, il faut penser

fichier/action générique avec des variables définies à côté. Ainsi, si le proxy vient

à changer, plutôt que changer le fichier, il suffira de changer la variable dans un

fichier. De même, si un deuxième proxy vient à exister, un changement de

variable résout le problème.

C’est pour cela qu’il a été préféré la deuxième méthode. Pour se faire,

plutôt que remplacer le fichier, il est préférable de rajouter une ligne dans le

fichier.

Notre problème est que Puppet ne gère pas l’ajout de texte avec

vérification si le texte est déjà présent et si c’est le cas, ne pas le rajouter.

C’est pourquoi j’ai dû passer par un script qui va « parser »le fichier

/etc/bashrc et rajouter les paramètres en conséquence.

Figure 37 : Structure du fichier node.pp

Le fichier node.pp permet de spécifier la configuration pour chaque nœud.

Dans notre cas, le nœud « client1.lbdaq.cern.ch » n’a pas besoin d’autre

configuration que celle de base (juste le module proxy ici).


Page 36

Pour inclure un module, il suffit de mettre « include ‘nom_du_module’ »

et Puppet ira chercher le module /etc/puppet/module (possibilité de changer le

chemin avec le fichier « puppet.conf »).Bien entendu, il est possible de spécifier

des paramètres sont seront repris dans le module. Cela pourrait, si on le

souhaitait, permettre d’avoir un proxy diffèrent sur certaine machine tout en

gardant des fichiers génériques.

Figure 38 : Arborescence du module proxy

Le fichier « init.pp » est le premier fichier lu lors de l’appel d’un module.

Ce fichier est le « chef d’orchestre » et son rôle est de faire appel aux autres

fichiers du module. Bien entendu, tout le module peut tenir dans ce fichier mais,

encore une fois, il est préférable de séparer le code.

Figure 39 : Structure du fichier init.pp du module proxy

Le fichier « init.pp » est composé de deux ressources :

La première qui va copier un fichier « script_proxy »dans le

dossier/tmp/du client avec certains droits.

La deuxième qui va exécuter ce script.

Vous pouvez remarquer qu’il est possible d’ordonnancer l’exécution de la

configuration. En effet, par défaut, Puppet ne va lire les fichiers que dans l’ordre

que l’on veut. Cela se fait de manière plus ou moins aléatoire : deux exécutions

de la même configuration pourront ne pas avoir le même enchaînement de

Ressource. Pour pallier à cela, il est possible d’utiliser des mots clé : Before,

Require, Notify et Subscribe. Ainsi, la deuxième Ressource sera appelée si et

seulement si la première ressource a déjà été utilisée. Il est logique d’exécuter

un script seulement s’il est bien présent à l’emplacement prévu.


Page 37

Figure 40 : Structure du script du module proxy

Le script va « parser » le fichier /etc/bashrc et agir en fonction : si la ligne

« export http_proxy=netgw01 :8080 » n’existe pas, il va la rajouter.

Ce module est assez simple mais permet d’apercevoir la puissance de

Puppet avec les types de ressources.

Et même quand une fonctionnalité n’est pas native dans Puppet, il existe

certainement un module pour le faire (ce qui n’est pas le cas pour notre module

proxy).

c) Conclusion

La configuration de base des machines de la ferme est très bien gérée par

Puppet. Une fois ce travail achevé et validé par mon tuteur, nous en avons

conclu que Puppet correspondait à nos attentes et qu’il pourra remplacer Quattor

dans un futur proche.

Mais la vraie question est : peut-on optimiser cela ?

La seule réponse est : oui mais avec de l’expérience. En effet, comme dit

plus haut, il n’existe pas qu’une seule manière d’utiliser Puppet. Reste à trouver

la méthode la plus adaptée et la plus fonctionnelle possible.

Quattor comprend la gestion des configurations mais aussi une partie

d’installation automatisée. Puppet remplie la première fonction. Il nous reste à

trouver le logiciel pour la deuxième partie.

Installation automatisée avec Cobbler

Page 38

III. Installation automatisée avec

Cobbler

On sait que Puppet est l’outil que l’on veut pour configurer les différentes

machines. Mais avant de configurer ces serveurs, il faut les installer.

Il existe la méthode « à l’ancienne » : insérer un dvd dans chaque

machine et valider manuellement le paramétrage. Ça fonctionne pour un seul

serveur mais quand il y en a plus de deux mille, à moins de prendre un stagiaire

pendant cinq mois pour cette seule tâche et ne faisant que ça, c’est mission

impossible.

C’est là qu’intervient Cobbler.

1) Définition de Cobbler

Cobbler est un serveur d’installation par réseau d’OS Linux permettant un

paramétrage rapide des environnements d’installations. Il relie et automatise

plusieurs fonctions comme un serveur web, un serveur TFP etc… et ainsi n’a

qu’une seule interface pour gérer une nouvelle machine. Il relie dans le sens où il

peut utiliser des services externes ou bien fournir ces services par lui-même.

Projet de la distribution Fedora, il gère de plus en plus d’autres distributions :

bien entendu Fedora/RedHat et ses dérivés (CentOS et Scientific Linux) mais

aussi Debian/Ubuntu, Suse et FreeBsd. Le serveur ne fonctionne par contre que

pour la famille Fedora/RedHat. La version actuelle est la 2.2.3 et la

documentation et les sources peuvent se trouver sur le site officiel [4].

Avantage :

Rapidité

Simplification et automatisation

Installation de plusieurs clients à la fois

Installation homogène

Abstraction d’un support physique tel que Dvd ou clé USB

Inconvénients :

Utilisation des ressources réseaux


Page 39

2) Principe de Cobbler

Cobbler utilise le protocole PXE (Pre-boot eXecution Environment) qui

permet à un client d’utiliser le réseau pour récupérer une image d’un OS. Cette

image peut être utilisée pour permettre le diagnostic d’un mini OS pour des

clients légers, d’un vrai OS dans le cas de machine diskless où le système

d’exploitation sera entièrement utilisé via le réseau, ou un mini système

d’exploitation qui permet d’installer un OS sur le disque dur local de la machine.

C’est cette dernière possibilité qui nous intéresse.

De nombreuses sociétés utilisent Cobbler (Dell, Sony, LinkShare, TomTom

etc…) et donc, sa pérennité ne peut pas être remise en question.

a) Serveur Pxe

Figure 41 : Séquence de démarrage d'un client

Tout d’abord, le client doit avoir une carte réseau compatible PXE (ce qui

est vrai pour la plupart des machines actuelles) et spécifier qu’il doit démarrer

sur le réseau au lieu d’utiliser le disque dur local. Afin de savoir où le client doit

aller chercher le serveur PXE, on utilise le serveur DHCP (1er composant

indispensable à Cobbler). En effet, la première information que le client va

chercher est une adresse IP. Dans la configuration du serveur DHCP est indiquée

l’adresse du serveur TFT PXE et le nom du fichier d’amorce. Ce fichier d’amorce

se nomme « pxelinux.0 » et c’est ce fichier qui indiquera où récupérer la

configuration PXE en utilisant le format suivant :


Page 40

Figure 42: Configuration DHCP du poste client1

Le client va chercher sa configuration dans un dossier en commençant par

un dossier portant le nom de son adresse MAC (numéro unique), puis cette

adresse convertit en hexadécimal en retranchant un digit à chaque essai pour

finir par le fichier par default. Si malgré cela le client n’a rien trouvé lui

correspondant alors l’installation se solde par un échec.

Figure 43 : Tentative de récupération du fichier pxelinux.cfg

Dans le cas où un fichier de configuration est trouvé, ce fichier est analysé

et exploité : requête PXE au serveur TFTP PXE pour les paramètres de

démarrage.

Si la machine est vierge, on souhaite installer un OS. Si l’OS est déjà

installé, on va booter sur le disque dur local. Tous ces fichiers sont hébergés sur

un serveur TFTP (deuxième composant indispensable à Cobbler).

Ainsi, en fonction de l’adresse MAC, Cobbler pourra indiquer quel OS

installer avec quelle configuration.

C’est à partir de ce moment que la machine peut commencer à s’installer.

Afin d’automatiser cela, un fichier de réponse appelé fichier « Kickstart » est

fourni au client. Ce fichier va automatiquement fournir des réponses que

l’installateur pourrait poser comme le choix de la langue, du clavier, des

packages à installer etc…


Page 41

Une variable sur Cobbler indique si une machine doit être installée ou si

elle doit démarrer sur le disque dur local. Par défaut, cette variable indique qu’un

nouveau system doit être installé. Pour la modifier, on peut le faire

manuellement ou bien une routine est utilisée à la fin du fichier Kickstart dans le

script de post-install. Ainsi, si l’installation doit s’interrompre avant la fin, au

prochain démarrage la machine recommencera le processus d’installation. Si

l’installation s’est bien déroulée, le prochain démarrage se fera sur le disque dur

local.

Figure 44 : Cobbler

Ce schéma montre bien comment Cobbler agit comme un couteau suisse :

utiliser des services externes (DHCP, DNS, HTTP, TFTP) pour des ressources

internes (System, Profile, Distro, Repository, Kickstart). Pour configurer une

nouvelle machine, on va créer un nouveau « System » avec son adresse MAC

(adresse IP en option) que l’on va rattacher à un « Profil » (ex : serveur web),

qui ira puiser ses fichiers de base dans une « Distribution » en utilisant des

« Repository » pour l’installation de packages définis dans un fichier

« Kickstart »(les Mgmt-Class pour Management Class est un peu à part : cela

sera utilisé pour créer un lien avec Puppet).

Notre but est d’avoir une configuration minimum, la plus générique

possible avec juste le package Puppet installé et que ce soit Puppet qui gère

vraiment toute la configuration de la machine.


Page 42

b) Installation de Cobbler

Sur une distribution SLC, une ligne de commande permet d’installer

Cobbler et ses dépendances :

Figure 45 : Installation de Cobbler

Parmi ces dépendances, on retrouve « httpd » (serveur web), « tftp-

server » (serveur tftp), « xinetd » (gère les connexions basé sur Internet).

c) Structure de Cobbler

Liste des dossiers créés durant l’installation de Cobbler :

/etc/cobbler :

Regroupe la configuration propre à Cobbler

/var/www/cobbler

Ensemble des données utiles aux clients pour s’installer

(exemple : distribution, packages etc…)

/var/lib/cobbler

Dossier des données propre à Cobbler

/var/log/cobbler

Journaux de Cobbler


Page 43

d) Configuration de Cobbler

Avant de paramétrer les services externes, on va le faire via Cobbler au

fichier/etc/cobbler/seetings. Exemples :

Adresse du serveur PXE (Serveur hébergeant Cobbler dans notre cas)

Figure 46 : Fichier seetings de Cobbler

Gestion du DHCP par Cobbler

Figure 47 : Gestion du DHCP par Cobbler

Le choix des outils DHCP ou http par exemple se fait dans le fichier

/etc/cobbler/module.conf.

Figure 48 : Choix du serveur DHCP dans module.conf

Cobbler est un outil permettant de centraliser les configurations des autres

services qui lui sont utiles. Ainsi, il n’existe qu’une seule interface pour gérer les

données et les serveurs externes. Pour se faire, des Template existent et Cobbler

va modifier les fichiers de config de ces serveurs grâce au variable fournit par

l’administrateur dans la configuration de Cobbler.


Page 44

Figure 49 : Template du fichier dhcpd.conf

Une fois l’installation terminée et la configuration de Cobbler finit, une

commande (cobbler check) va confirmer que la configuration est conforme et on

saura si on peut commencer l’importation des données.

e) Fichier Kickstart

Un fichier Kickstart est composé de quatre parties :

La configuration de base

Répond aux questions de base : langue, time zone,

partitionnement des disques durs etc...

Liste des packages

Dans notre cas, seul le package Puppet sera installé mais on

peut aussi spécifier des packages simples ou des groupes de

packages, voire d’enlever un package d’un groupe

Script de Pré Install

Liste des commandes à exécuter avant l’installation. Vide

dans notre cas.

Script de Post Install

Liste des commandes à exécuter après l’installation. On va

effacer les listes d’origines des Repository de Yum qui pointent sur

l’extérieur et faire en sorte que Puppet se lance à chaque démarrage

du client. On va aussi utiliser un Template de Cobbler appelé

SNIPPET pour modifier la variable qui désactive l’installation du

client à son prochain démarrage.


Page 45

Figure 50 : Fichier Kickstart

f) Import des Repository

La première chose à faire est d’importer des Repository qui seront utilisés

lors de l’installation des packages pendant l’installation de l’OS. Il est possible

d’utiliser des Repository externe à Cobbler (sur Internet par exemple pour avoir

les dernières versions des packages) mais étant donné que l’on souhaite qu’il n’y

ait aucune donnée venant de l’autre part du serveur Cobbler afin de pouvoir

garantir leur bonne intégrité, nous allons devoir importer leur contenu. Le

Repository le plus important est celui hébergeant Puppet. Malheureusement, le

package Puppet (et certaines de ses dépendances) ne fait pas partie des

packages d’origine des Repository de SLC6. C’est pourquoi j’ai créé un Repository

local spécialement pour cela.

L’importation des données se fait en deux étapes : configuration d’un

Repository et synchronisation des données.

Figure 51 : Import d'un Repository sous Cobbler


Page 46

Par la suite, il est possible de resynchroniser nos Repository locaux avec

les originaux.

Figure 52 : Synchronisation des Repository

Les Repository se trouvent dans le dossier /var/www/cobbler/repo_mirror/

g) Import des OS

Dans ce projet, seul l’OS SLC6 sera utilisé pour l’installation des clients

mais il est possible d’importer plusieurs OS. Il suffit de spécifier le nom que l’on

souhaite donner à cet OS et son emplacement d’origine (Dvd, Fichier ISO etc…)

Figure 53 : Importation de la distribution SLC6 depuis le fichier boot.iso

Les distributions se trouvent dans le dossier /var/www/cobbler/ks_mirror/.

h) Création d’un profil

Lors de l’importation d’une distribution, un profil est automatiquement

créé avec comme seul paramètre la distribution qui lui est lié. Nous devons lui

ajouter les Repository que l’on a créés juste avant, ainsi que l’emplacement du

fichier Kickstart.

Figure 54 : Structure d'un profil

Il est tout à fait possible de créer d’autres profiles que ceux d’origine pour

spécifier d’autres fichiers Kickstart par exemple.

i) Ajout d’un système

Maintenant que tout est mis en place pour permettre l’installation d’une

nouvelle machine, il suffit de la rajouter dans Cobbler.


Page 47

Pour cela, on a besoin de son nom pour l’identifier sur Cobbler, du profil

utilisé, de son adresse MAC et interface réseau, son config réseau (adresse IP,

DNS etc…). Ces informations iront renseigner le fichier de configuration du

serveur DHCP (dhcpd.conf). Une seule interface de configuration : Cobbler.

Figure 55 : Ajout d'un system

j) Installation d’une machine

Avant de lancer une nouvelle installation d’un client, il faut synchroniser

Cobbler pour qu’il puisse modifier les fichiers de configuration et relancer les

services.

Figure 56 : Résultat de la commande cobbler sync


Page 48

Une fois cette étape validée, on peut démarrer le client. Aucune action de

notre part n’est nécessaire.

Figure 57 : Client récuperant des fichiers sur le serveur PXE

Interconnexion Puppet – Cobbler

Page 49

IV. Interconnexion Puppet – Cobbler

1) Lien entre Puppet et Cobbler

C’est parfait. Cobbler installe les clients et Puppet les configure. Mais

il reste un problème à résoudre : chaque machine est déclarée sous

Cobbler et sous Puppet à la fois. Il y a des outils pour éviter ce double

travail.

Pour pallier à cela, il est possible de configurer Puppet pour que, au lieu

d’utiliser le fichier « node.pp » pour connaitre la configuration à appliquer à

chaque client, il aille chercher ces informations à l’extérieur : c’est la notion de

configuration de node externe (ENC pour External Node Configuration).

Mais cela est un peu plus subtil avec Cobbler qu’avec le fichier

« node.pp » : un paramètre dans Cobbler, que l’on retrouve sur les distributions

les profiles et les systèmes, est appelé « Management Classes » et on peut y

spécifier plusieurs variables. On va y mettre des noms de class de Puppet

(exemple : la class yum ou la class puppet qui se trouve chacune dans un

module).

Figure 58 : Management Classes au sein de Cobbler

Mais comment retourner ces variables en fonction de l’hostname d’un

client et les utiliser dans Puppet ?

Cobbler fournit un script qui retourne ces valeurs via le serveur web.

Figure 59 : Réponse du script en fonction d'un client

Et justement, la notion de node externe peut se paramétrer dans

/etc/puppet/puppet.conf grâce à un script (ici, une copie du script d’origine

renommé dans /etc/puppet/external).

Figure 60 : Configuration du fichier puppet.conf


Page 50

Figure 61 : Script external

Ainsi, Puppet peut interroger Cobbler pour connaitre les class à utiliser

pour tel ou tel client. L’interconnexion fonctionne parfaitement mais…

Mais ce n’est pas l’utilisation souhaitée. Ce que nous recherchons, c’est de

définir les distributions, les profiles et les Repository sous Cobbler et tout ce qui

touche les systèmes, de les définir sous Puppet. Dans le meilleur des cas, c’est

Puppet qui va renseigner Cobbler sur les clients et non pas Cobbler qui indique à

Puppet ce qu’il doit faire.

À l’heure actuelle, malgré tous ces atouts, Cobbler ne correspond pas à

l’outil souhaité par le LHCb et par Niko Neufeld en particulier. Mais, il est faut pas

enterrer Cobbler trop vite.

2) Remplacement de Cobbler ?

Quelle est finalement la solution ?

Lors des conférences des Rencontres du Monde du Logiciel Libre le 11

Juillet 2012, PuppetLabs a parlé d’une nouvelle solution qui pourrait nous

convenir : Razor. Etant donné qu’il est développé par PuppetLabs justement, on

est en droit d’espérer une complète imbrication dans Puppet.

3) Razor

« La solution la plus simple est la plus élégante » Luke Kanies, Fondateur

de PuppetLabs


Page 51

Razor [5] utilise 4 composants ayant chacun une fonctionnalité bien

définie :

a) Discovery

Figure 62 : Razor Discovery

Alors qu’avec Cobbler chaque machine doit être déclarée manuellement,

Razor intègre un outil permettant de connaitre exactement les composants

matériels et logiciels de chaque nœud avant même leur installation et ainsi si une

machine fait partie d’un lot de même type, Razor saura déjà quel OS installer.

Fonctionnant aussi avec un serveur DHCP et un serveur PXE, le serveur

Razor va fournir une adresse IP via le serveur DHCP. En plus de l’adresse, le

client va récupérer l’adresse du « next-server » qui correspond au serveur PXE

Razor.

Ce serveur PXE va fournir un MicroKernel de 20mo à peu près. Ce

MicroKernel est un système d’exploitation extrêmement simplifié basé sur Linux

et fournissant une certaine fonctionnalité de base au client. Son but est de faire

en sorte que le client puisse faire un inventaire, de contacter le serveur Razor et

s’enregistrer sur celui-ci.

En s’enregistrant, il fournit grâce au logiciel Facter de PuppetLabs des

informations sur son matériel et sa configuration réseau ( Adresse IP, Mac etc…).

Parmi ces informations, on trouve le nombre de processeur, le fabriquant de

l’ordinateur, le nombre de disque dur et bien plus.


Page 52

Grace à cela, Razor est capable de découvrir et répertorier des centaines

de nœud automatiquement.

Figure 63 : Liste des nœuds sur Razor

Figure 64 : Attribut d'un node sur Razor


Page 53

b) Tagging

Figure 65 : Razor Tagging

Une fois le client et ses informations découverts, il faut utiliser des

modèles permettant une classification et ainsi traiter un ensemble de serveur

plutôt que chaque machine individuellement.

Pour se faire, Razor utilise des règles de « tags » à appliquer sur les

nœuds en fonction de ce que Facter a découvert.

Exemple : on a 50 serveurs avec 25 de la marque Cisco UCS et 25 de la

marque Dell. On souhaite utiliser chaque groupe de serveurs dans un rôle bien

spécifique : les Cisco pour faire une ferme de serveur et les Dell pour faire de la

virtualisation.

On peut connaitre toutes les informations dont on a besoin pour les classer

grâce à la partie Discovery et on peut les grouper en appliquant un « tag »

commun. Exemple : si l’information « constructeur » est ‘Cisco’ alors on applique

le « tag » Cisco. On peut aussi avoir des tags ‘big_server’, ‘medium_server’ et

‘small_server’ en fonction du nombre de processeur. Il est aussi possible de

spécifier plusieurs tag à la fois : [‘Dell’, ‘small_server’].

Par défaut, Razor utilise les tags [‘Nombre_de_CPU’, ’Type_de_CPU’,

’Nombre_de_Carte_Reseau’, ‘Type_de_machine’].


Page 54

c) Policy

Figure 66 : Razor Policy

Maintenant, il faut appliquer un modèle commun à chaque tags ou groupe

de tags pour l’installation des systèmes d’exploitation : si les tags sont

[‘web_farm’, ‘small_server’] alors on applique le model « Ubuntu » (du nom de la

distribution Ubuntu). Ces modèles sont déclarés préalablement sur Razor en

important le système d’exploitation.

Ainsi, le système d’exploitation SLC6 sera installé sur les machines ayant

les mêmes « tags » que ceux déclarés.

Figure 67 : Razor Policy

Ci-dessous, on retrouve la liste des politiques déclarés sur Razor avec la

liste des tags associé et le nombre de clients existants.


Page 55

d) Brokers

Figure 68 : Razor Broker

On se retrouve avec des machines installées avec le système d’exploitation

souhaité. Mais il n’y a pas de lien encore avec Puppet. Etant donné que Razor et

Puppet viennent de la même entreprise, PuppetLabs, il est très facile d’intégrer

Puppet lors de l’installation des clients. Pour se faire, il faut spécifier via une ligne

de commande un lien entre le serveur Razor et le serveur Puppet : un

« Broker » (agent de change).

Figure 69 : Liste des Broker

Il faut ensuite associer ce « Broker » a une politique existante.

Figure 70 : Politiques sur Razor avec "Broker"


Page 56

e) Avantages / Inconvénients

On a un outil permettant l’automatisation à outrance : contrairement à

Cobbler, il n’est plus utile de déclarer chaque machine pour permettre leur

installation : un modèle unique pour un groupe de machine suffit.

Mais Razor n’est pas dénué d’inconvénients :

Pour l’instant, seules les distributions Debian/Ubuntu sont supportées. Il

faut adapter une partie du code de Razor pour le rendre compatibles avec SLC6.

Si certaines parties sont plutôt simples, d’autres sont plus compliquées : Razor

utilise des packages Ruby appelés Gems dont certains n’existent que pour

Debian/Ubuntu. Une réécriture complète de ces Gems est donc indispensable.

De plus, Razor est un outil extrêmement jeune : début Juillet 2012, l’outil

venait tout juste d’être publié par PuppetLabs, soit à peine quelques mois

d’existence contrairement à Cobbler qui existe depuis plus de quatre ans et a de

nombreux clients. Il est donc difficile de trouver de la documentation de

nombreux cas ne sont pas pris en compte ( exemple de SLC6 reconnu comme un

OS SLC et non pas RedHat ).

C’est pourquoi, malgré ses avantages, Razor n’est pas une solution

retenue.

4) La solution

Finalement, pour la solution de lien entre Puppet et le logiciel

d’installation, il est envisagé de revenir à Cobbler avec le développement de

script : séparer la partie matérielle avec Cobbler de la partie logiciel avec Puppet.

a) Partie Matériel

La première partie consiste à déclarer chaque machine sur Cobbler avec

comme information : Hostname, Adresse Mac et Adresse IP. Ces seules

informations sont indispensables pour l’installation du client avec, bien sûr , le

choix d’un Profil existant dans Cobbler.

Figure 71 : Ajout d'une machine sur Cobbler


Page 57

b) Partie Logiciel

L’enregistrement sous Puppet est extrêmement simple : cela consiste à

avoir un fichier ayant pour nom l’hostname du nœud avec l’extension

« :pp »dans le dossier /etc/puppet/manifests/nodes/ avec comme contenu

« node hostname ». En paramétrant le fichier /etc/puppet/manifests/site.pp, il

ira directement chercher la définition des nœuds dans ce dossier.

Figure 72 : Fichier site.pp

Figure 73 : Fichier client1.lbdaq.cern.ch.pp

c) Lien entre les deux

Une solution est d’enregistrer chaque machine sur Puppet grâce à Cobbler

et au fichier Kickstart.

A la fin de l’installation avec un fichier Kickstart, il est possible d’exécuter

des commandes. Ces commandes peuvent servir à modifier le champ «Netboot

Enable » des machines sous Cobbler pour éviter que l’installation se fasse en

boucle si elle est réussie. Nous pouvons nous servir de ce modèle en utilisant un

serveur web fonctionnant sous la technologie Web PHP pour créer le fichier

« hostname .pp » dans le serveur Puppet.

En utlisant une addresse web avec l’hostname du client en paramettre, le

serveur va créer le fichier .pp.


Page 58

Figure 74 : Fichier Kickstart avec script PHP

Figure 75 : Script PHP pour créer le fichier hostname.pp

Ce fichier .pp pourra être modifié par la suite au besoin et ainsi modifier la

configuration du client.


Page 59

Même si cette solution n’est pas parfaite (utilisation d’outil externe avec le

serveur web en PHP plutôt que des outils internes à Cobbler) l’avantage d’un tel

système est de séparer la partie logiciel et la partie matériel. Si une machine a

un problème de carte réseau et qu’elle doit être changée, l’adresse MAC du nœud

changera. Seule la modification sous Cobbler est nécessaire et rien ne change

pour Puppet.

Machine Diskless

Page 60

V. Machine Diskless

Une fois la solution pour interconnecter Puppet et le logiciel d’installation

trouvé, il faut pouvoir la mettre en production.

Seulement, la production, c’est la ferme de serveur. Et cette ferme de

serveur est composée de machines Diskless (sans disque dur local : l’OS est sur

un disque dur d’un serveur central et envoyé au client via le réseau).

1) Principe

Comme indiqué, une machine Diskless ne possède pas de disque dur. Son

espace de stockage est centralisé avec les espaces de stockage des autres clients

sur un serveur central. Au LHCb, un serveur central administre 27 nœuds client

Figure 76 : Serveur Central et Client Diskless

Il existe deux fonctionnements de serveur Diskless :

Chaque client possède son propre espace

Tous les clients partagent le même espace (fichiers communs pour

tous les clients, appelé root ), sauf quelques dossiers sélectionnés

où chaque client possède son propre espace (appelé snapshot).

Le deuxième système est celui sélectionné par le LHCb. Deux raisons à

cela :

Gain de place : l’ensemble des données d’un client font 4,5 Giga et

avec ce système, on a 500 mo de données spécifiques et les

données partagées font 4 Giga. Au lieu d’avoir 27x 4,5 Giga =120

Giga par serveur), on a 27x500mo + 4 Giga= 17,5 Giga.

Machine Diskless

Page 61

Gain d’administration : les fichiers administrés sur les clients sont

souvent des fichiers communs à tous les clients. Ainsi, plutôt que de

modifier 27 fichiers pour l’ensemble des clients, on modifie juste le

fichier commun. Cela représente un gain de vitesse, de ressource

(réseau et machine ) etc…

Figure 77 : Liste des dossiers du serveur central Diskless

Ci-dessus, on peut voir l’arborescence sur le serveur central des dossiers

avec le dossier « root » commun à tous les clients et le dossier snapshot où

chaque client a son propre dossier.

L’ensemble des fichiers spécifiques à chaque client sont déclaré dans le

fichier /diskless/snapshot/files.custom.

Machine Diskless

Page 62

Figure 78 : Liste des dossiers spécifique machine Diskless

2) Problèmes

Ce système de machine Diskless au sein du LHCb fonctionne très bien.

Toutefois, le passage à SLC6 peut être compromis : alors que SLC5 gère très

bien les snapshot, SLC6 n’a plus cette fonctionnalité de base (seule la possibilité

d’avoir des espaces spécifiques existe). Il faut adapter l’OS.

De plus, Cobbler ne gère pas ce système de machine Diskless avec dossier

snapshot : seul celui où les clients ne possèdent que des données spécifique est

possible. Donc même avec SLC5, les snapshots ne sont pas disponible avec

Cobbler

Le premier problème sera résolu par Pierre Schweitzer ( Etudiant ISIMA

ZZ3 promo 12 ) lors de la fin de son stage au CERN. Sa solution passe par la

création d’un nouveau système de fichier permettant une utilisation transparente

des snapshot.

Le deuxième problème ne peut être résolu à moins de revoir en grande

partie le code de Cobbler. Ce n’est pas le but de ce stage.

Mais au lieu de trouver une solution à ce problème, il peut être envisagé

de le contourner. Aujourd’hui les disques durs ne sont plus aussi onéreux

qu’avant. La taille des disques durs a considérablement augmenté alors que les

prix ont chuté. De même, les ressources telles que le réseau ou les processeurs

ont eux aussi gagné en performances.

Machine Diskless

Page 63

De ce fait, il peut être envisagé de changer de système de machine

diskless et faire en sorte que chaque client ait son propre espace.

Un tel choix ne fait pas partie du sujet du stage. C’est pourquoi nous allons

rester sur la solution avec toutes les données qui sont spécifique à chaque

clients.

3) Diskless avec Cobbler

A l’heure actuelle, je n’ai pas pu tester encore les machines Diskless avec

Cobbler.

Cela devrait être fait avant la fin du stage.

Conclusion

Page 64

Conclusion

Un grand changement est en train de s’opérer dans le système

d’information au CERN et plus particulièrement au sein de l’expérience du LHCb :

un changement d’infrastructure ou plus simplement une remise en cause de

certains outils devenus plus ou moins obsolètes.

Les objectifs de ce stage étaient multiples et devaient s’inscrire dans ce

changement :

Confirmer que Puppet est conforme à nos besoins

Trouver un outil d’installation de client adapté

Les mettre en relation de façon satisfaisante

Configurer les machines Diskless

Deux de ces objectifs sont remplis et confirment le potentiel de Puppet. Ce

n’est pas étonnant que des grands noms comme Google ou autres l’utilisent.

En plus d’être simple, Puppet est extrêmement complet surtout très

ouvert. Je pense que c’est un outil qui sera une référence dans ce domaine, si ce

n’est pas déjà fait.

Concernant Cobbler, malgré ses qualités et qu’il soit tout à fait adapté à

nos besoins, son interconnexion avec Puppet nous pose problème…

Comment résoudre cela ?

Garder Cobbler et trouver une autre solution que Puppet ? Il n’existe

pas vraiment d’alternatives possibles…

Garder Puppet et prendre un autre logiciel d’installation de client ?

La solution Razor ne nous convient pas

Adapter l’interconnexion entre Puppet et Cobbler ? C’est peut-être la

dernière solution

Nous allons garder la dernière solution même si d’autres outils auraient

mérité d’être testé comme par exemple Foreman même si les premiers

renseignements nous permettent de penser que l’interconnexion avec Puppet est

exactement la même qu’avec Cobbler.

Concernant les machines Diskless, là aussi il n’y a pas de solution

parfaite : soit la création de nouveau outils ( système de fichier de Pierre

Schweizer ) et l’adaptation de ceux existant ( Cobbler ) , soit une remise en

question du système de machine Diskless du LHCb. Cette décision appartient au

service informatique du LHCb.

Conclusion

Page 65

Figure 79 : Diagramme de Gant Final

Comme le démontre ce planning en comparaison du planning prévisionnel,

j’ai un peu de retard. Cela est dû à mon apprentissage du système Linux (pour

une personne aguerrie, le planning aurait pu être respecté) mais aussi à la

mauvaise imbrication entre Puppet et Cobbler, ce qui m’a obligé à voir d’autres

solutions. L’installation d’une machine Diskless avec Cobbler devrait être faite

avant la fin du stage.

Personnellement, ce stage m’a beaucoup apporté :

Connaitre un lieu comme le CERN est tout simplement magique. Autant de

scientifiques, autant de technologies différentes souvent dans des proportions

démesurées, font du CERN un lieu unique.

Avant de venir en stage ici, j’étais peu habitué au monde Linux malgré

l’enseignement à l’ISIMA (certainement dû à mon background basé

essentiellement sur l’univers MICROSOFT) et après cinq mois ici, mes

connaissances se sont développées et cela a confirmé mon envie de continuer

dans l’administration système en m’orientant pourquoi pas sur des machines

Linux, ce qui était chose impensable avant.

Références bibliographiques

[1] Documentation Puppet : http://doc.puppetlabs.com

[2] James Turnbull et Jeffrey McCune , “Pro Puppet , Maximize and

customize Puppet’s capabilities for your environment” , 2011 , Edition

Apress

[3] Documentation Communauté Puppet : http://forge.puppetlabs.com

[4] Documentation Cobbler : http://cobbler.github.com

[5] Documentation Razor : https://github.com/puppetlabs/Razor

http://doc.puppetlabs.com/

http://forge.puppetlabs.com/

http://cobbler.github.com/

https://github.com/puppetlabs/Razor

Documents

Installation et Configuration Centralisées et Automatisées · CERN-THESIS-2012-127 07/09/2012 Installation et Configuration Centralisées et Automatisées d’une Ferme de Serveur