M2 Stage Rapport Irsapoulle Patrick 2014

Département de Mathématiques et Informatique
Université de la Le Conseil Général

Réunion de la Réunion
Rapport de Stage de Master M2

INFORMATIQUE
Mise en place d'un outil de supervision

et de contrôle distant
réalisé par
Patrick IRSAPOULLE 28000541
Entité Académique : Université de la Réunion

Responsable Pédagogique : Fred Mesnard
Nom de la Société : Le Conseil Général de la Réunion

Tuteur de Stage : François Boyer
Dates du stage : 6 Janvier au 7 Juillet 2014
<patrick.irsapoulle@gmail.com>
Saint Denis, île de la Réunion, 20 juin 2014
Université de la Réunion
15, avenue René Cassin B.P. 7151 97715 Saint-Denis Messag CEDEX 9
2
Présentation du Stage de M2
Informatique
Contexte
Ce stage se déroule dans le contexte de la n du cycle d'études du Master Informatique au
sein de l'Université de la Réunion. Il s'insère directement à notre cursus pédagogique (à savoir
le second semestre de notre cinquième année d'études supérieures).
Chaque étudiant doit se mettre à la recherche d'une entreprise au plus tôt, rappelons que ce stage
est à temps plein pour une durée de six mois. Un sujet pertinent doit être choisi par l'entreprise
d'accueil, proposé à l'étudiant, puis validé par l'équipe pédagogique. Une convention est alors
signée, liant l'étudiant, l'entreprise d'accueil et l'entité pédagogique.
Objectifs
Son objectif principal est de permettre de bénécier d'une véritable expérience de profes-
sionnalisation et ainsi de faciliter notre insertion vers le monde du travail. Découvrir l'univers
professionnel, un secteur d'activité, participer à la vie de l'entreprise et surtout s'adapter à ses
exigences font partie intégrantes de nos objectifs en tant que stagiaire.
Concrétisant les savoirs acquis durant le parcours scolaire, il est nécessaire d'accomplir ce stage
dans une secteur présentant des intérêts personnels, an de se spécialiser dans le domaine sou-
haité.
3
Résumé
L'architecture représente la structure générale inhérente à un système informatique, et plus
particulièrement l'organisation des diérents éléments, que ceux-ci soient de type matériel ou
logiciel.
Le principe de la supervision est de s'assurer du bon fonctionnement d'un système, sa mise en

place permet d'eectuer des actions pro-actives et ainsi de détecter d'éventuels problèmes, avant
que ceux-ci n'interviennent.
Outre les éléments classiques à superviser, tels que les serveurs, switchs... Un nouveau type
d'élément fait son apparition : L'imprimante (ou Multifonction) en Réseau. La politique actuelle
visant à mutualiser ce type de périphérique, il devient plus qu'essentiel de garder un contrôle
permanent sur celui-ci an d'éviter tout problème au sein des services concernés.
Les postes de travail (environ 3500) sont les éléments les plus sensibles étant donné qu'ils sont
dotés aux utilisateurs. Ils restent donc actuellement le type de matériel qui nécessite le plus
d'interventions de la part des techniciens.
C'est dans ce contexte que se situe l'objectif de ce stage qui est de coupler la puissance d'un
outil de supervision à diérents outils d'administration, au travers d'une interface web simpliée,
an de permettre aux techniciens d'eectuer un Diagnostic de premier niveau à distance, sur les
imprimantes/multifonctions en réseau ainsi que les postes de travail avant toute intervention sur
site.
[Mots-clés : Microsoft, Linux, requêtes, programmation, SNMP, imprimante, poste

de travail, réseau]
Abstract
The architecture represents the overall structure inherent in an IT system, especially the
organization of the dierent elements that they are hardware or software based.
The aim of monitoring is to ensure the correct functioning of a system, its implementation can
perform proactive actions and thus to detect potential problems before these do occur.
In addition to the conventional elements to monitor, such as servers, switches ... A new type of
element is introduced : Network Printer (or Multifunction). The current policy aimed at pooling
this type of device, it's more than essential to keep a permanent check on it to avoid any problems
in the services concerned.
Desktop computers (3500) are the most sensitive since they are elements equipped to users. They
are currently the type of hardware that requires more intervention by technicians.
It's in this context that is located the goal of this internship, which is to combine the power of
a monitoring tool with dierent administration tools, through a simple web interface, to allow
technicians to make a remotely rst-level diagnosis of network printer/multifunction and desktop
computers before proceeding.
[Keywords : Microsoft, Linux, queries, programming, SNMP, printer, desktop com-

puter, network]
4
Remerciements
Merci à toutes les personnes qui ont su contribuer au bon déroulement de ce stage de Master
de deuxième année.
J'adresse mes remerciements à Laurent PRUNELLA, pour m'avoir permis d'eectuer ce stage
au SSU.
J'exprime ma reconnaissance à mon responsable pédagogique, Fred MESNARD, pour sa dispo-

nibilité et ses conseils qui m'ont guidé tout au long de mon cursus universitaire.
Je remercie François BOYER, mon tuteur de stage, pour ses qualités en tant qu'encadrant à la
DEMS.
Merci à Vincent Beauval, administrateur systèmes et réseaux du SAR, qui de part son expérience
dans le domaine de la supervision, a réussi à me pousser à toujours eectuer les bons choix, tout
en respectant l'architecture en place.
Merci également à Florent PAYET qui m'a permis de développer mes connaissances dans le
domaine de la virtualisation.
Je tiens à exprimer ma gratitude envers toutes les personnes qui m'ont suivi et soutenu tout le
long de mon parcours, une pensée particulière à mon collègue et ami Kévin TAOCHY, sans qui
ce travail d'équipe n'aurait pas pu aboutir.
5
Table des matières
1 Introduction 9
1.1 Présentation de l'organisme d'accueil . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.1 Le Conseil Général de la Réunion . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.2 La Direction de l'E-administration et Modernisation des Services . . . . . 10
1.1.2. A Service Ressources et Méthodes . . . . . . . . . . . . . . . . . . 10
1.1.2. B Service Architecture et Réseaux . . . . . . . . . . . . . . . . . . 11
1.1.2. C Service APplications . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1.2. D Service Support Utilisateur . . . . . . . . . . . . . . . . . . . . . 12
1.2 Objectifs du stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 Présentation du Rapport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 Analyse des besoins et spécications 14

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Les enjeux du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Les informations pertinentes pour le technicien . . . . . . . . . . . . . . . . . . . 15
2.4 Étude de l'existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1 Architecture du SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1. A Le serveur DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.1. B Le serveur DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.1. C Le contrôleur de domaine Active Directory . . . . . . . . . . . . 18
2.4.2 Easy Vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.3 Le parc Imprimantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.3. A Panel Top Access . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.4 Convention de nommage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5 Gestion de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.1 Équipe Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.2 Planning Prévisionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5.3 Cycle de vie du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5.4 Spécication des exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.5 Exemple d'un scénario et d'un cas d'utilisation . . . . . . . . . . . . . . . 23
3 État de l'art 24
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 L'aspect Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1 Que peut-on superviser ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.2 Méthodes de Supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.3 Les diérentes solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.3. A Les solutions propriétaires . . . . . . . . . . . . . . . . . . . . . . 27
3.2.3. B Les solutions Open Source . . . . . . . . . . . . . . . . . . . . . 28
3.2.3. C Comparatif général des solutions Open Source . . . . . . . . . . 29
3.2.4 La solution retenue : Centreon Enterprise Server . . . . . . . . . . . . . . 30
6
3.2.5 Le protocole de supervision . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4 Le protocole solution pour la supervision en réseau 32

4.1 Présentation de Simple Network Management Protocol . . . . . . . . . . . . . . . 32
4.2 Les principaux éléments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.1 Le Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.2 Agent SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Des informations structurées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.1 Management Information Base . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.2 Structure d'une MIB et Object IDentier . . . . . . . . . . . . . . . . . . 35
4.4 Les paramètres d'interrogations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.1 Les paquets à installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.2 Les diérentes versions de SNMP . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.3 Les communautés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.5 Les requêtes SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.5.1 Les formats de requêtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.5.2 SnmpWalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.5.3 SnmpGet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5 Réalisation 39
5.1 Les outils utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2 De la supervision des imprimantes... . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.1 Notion d'hôte/de groupe d'hôtes . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.2 Dénition de commande . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.3 Dénition de service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.4 Installation de plugins pour Nagios . . . . . . . . . . . . . . . . . . . . . . 41
5.2.5 Architecture de CES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2.6 Le combo Nagios et ndOutils . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3 ... Au diagnostic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3.1 La remontée d'informations dans la base de données . . . . . . . . . . . . 42
5.4 En passant par la découverte réseau . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.5 Du serveur de développement au serveur de Production . . . . . . . . . . . . . . 45
5.6 Les dicultés rencontrées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.6.1 Protection du réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.6.2 Respect des conventions de nommage . . . . . . . . . . . . . . . . . . . . . 47
5.6.3 Livrables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.6.3. A Architecture générale de l'outil . . . . . . . . . . . . . . . . . . . 47
5.6.3. B Machines virtuelles . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.6.3. C Documentations . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6 Conclusion 49
6.1 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2 Apport personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.3 Perspectives futures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
A Webographie 54
A.1 Tableau de Bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
B Annexes techniques 57
B.1 Création d'une machine virtuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
B.2 Installation de CES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
B.3 Suite de l'installation de CES via navigateur Web . . . . . . . . . . . . . . . . . . 66
B.4 Les diérents éléments de Centreon . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7
TABLE DES MATIÈRES
B.5 Migration de la machine virtuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

B.6 V1 de l'interface Web de notre application . . . . . . . . . . . . . . . . . . . . . . 70
8
Chapitre 1
Introduction
1.1 Présentation de l'organisme d'accueil

Ce premier chapitre est dédié à la présentation globale de l'organisme d'accueil. Des organi-
grammes illustreront les diérentes hiérarchies établies au sein des directions et services présents.
Suite à la description du service auquel j'ai été aecté, seront introduits les objectifs de mon stage,
la problématique xée et une présentation assez sommaire du rapport en lui-même.
1.1.1 Le Conseil Général de la Réunion

Le Conseil Général est l'Assemblée Délibérante d'un Département, composée d'un ensemble
de conseillers généraux.
Ses membres, les Conseillers Généraux, sont élus au Surage Universel Direct uninominal à deux
tours et chaque Canton dispose de son propre conseiller. Leur mandat est de 6 ans, avec renou-
vellement par moitié tous les 3 ans.
Le Conseil Général est une collectivité qui agit pour le développement du Département et pour
le bien-être de ses habitants. Il exerce des missions qui touchent tous les aspects de la vie des
habitants de son Département. C'est par exemple, la construction et la rénovation de collèges
publics... Ce sont également les politiques menées en faveur de l'insertion des personnes sans
emploi, l'aide sociale en faveur de l'enfance, de la famille, des personnes âgées et des personnes
handicapées.
Son siège social est situé à l'hôtel du Département (2 Rue de la Source à Saint-Denis), le Conseil
Général de la Réunion est composé de 49 conseillers généraux. Le quotidien et l'organisation des
travaux du Conseil Général sont gérés par la Commission Permanente, qui se réunit chaque se-
maine. Sont présents : La présidente du Conseil Général, les 14 vice-présidents et les 16 membres
permanents.
Ses principaux domaines de compétence :
Social
Insertion
Santé
Enfance
Éducation
Environnement et Énergie
Culture
Sport
Laboratoires
Aménagement
9
1.1. PRÉSENTATION DE L'ORGANISME D'ACCUEIL
Coopération
Agriculture
Transports et Routes
Figure 1.1 Organigramme du Conseil Général de la Réunion
1.1.2 La Direction de l'E-administration et Modernisation des Services

La DEMS (anciennement appelée "Direction Informatique") est la Direction dont la mis-
sion est d'assurer la maintenance évolutive, préventive et corrective du Système d'information
et Télécommunications des services du Conseil Général, ainsi que de développer l'administration
électronique et l'ouverture du Système d'information aux partenaires et usagers.
En plus de sa Direction (composée du Directeur et de la cellule Animation/Formation), la DEMS

regroupe 4 grands services :
SRM
SAR
SAP
SSU
1.1.2. A Service Ressources et Méthodes
Le Service Ressources et Méthodes a pour vocation de faciliter le travail des services opéra-
tionnels en mettant à leur disposition les moyens nécessaires à la conduite de leurs missions et
en assurant la gestion des ressources transversales.
10
1.1. PRÉSENTATION DE L'ORGANISME D'ACCUEIL
Figure 1.2 Organigramme DEMS fonctionnel et nominatif
Les principales missions :
assurer le suivi des marchés de la direction

gestion comptable et nancière
gestion logistique : moyens
gestion du courrier de la direction
accueil physique et téléphonique
suivi et coordination des projets transversaux
1.1.2. B Service Architecture et Réseaux
Le service Architecture Réseaux a pour vocation de construire l'infrastructure du Système

d'information.
Ses missions :
concevoir,maintenir et moderniser l'architecture du SI

administrer et exploiter les équipements
conduire les projets techniques
fournir une assistance technique aux autres services
veille technologique an d'anticiper les évolutions technologiques
11
1.2. OBJECTIFS DU STAGE
1.1.2. C Service APplications
Le Service Applications assure la mise en place de solutions ou d'outils informatiques mo-

dernes et d'assurer leur fonctionnement et leur évolution. Ce service se décompose en deux parties,
une équipe " Mission Développement", et le service SAPMA.
L'équipe Mission Développement (placée sous la responsabilité d'un chef de projet) participe à
l'analyse fonctionnelle du besoin ainsi qu'à l'élaboration du modèle conceptuel des données. Elle
participe à la mise en oeuvre : paramétrages, formation...
L'équipe Service APplications Maintenance Applicative fait partie de l'unité SAP et est compo-
sée de 6 agents. Cette équipe a pour mission première d'assurer la maintenance, l'administration
technique et l'évolution des applications métiers du Département de la Réunion. Cependant elle
a également en charge de développer des applications lorsque la mise en place d'un progiciel ne
s'avère pas nécessaire.
1.1.2. D Service Support Utilisateur
Le Service Support Utilisateurs (auquel j'ai été aecté) est l'un des plus actifs parmi tous
les Services. En eet de part sa cellule d'interventions, ses diérents membres sont constamment
en action sur le terrain (les diérents sites du Conseil Général) et doivent maintenir un contact
permanent avec les utilisateurs. Pour plus d'ecacité cette équipe d'intervention est répartie
selon des secteurs : Est, Nord, Sud/Ouest plus une équipe placée constamment au niveau du
Palais de la Source.
Passer des marchés publics de matériels, évaluer les besoins, préparer des postes pour les utili-
sateurs, faire du dépannage sur site...toutes ces tâches rythment le quotidien du SSU.
1.2 Objectifs du stage

Initialement 3 thèmes ont été proposés comme sujet de stage.
1. Un thème principal (celui qui sera développé dans ce rapport, à savoir : "La mise en place
d'un outil de supervision des imprimantes et postes de travail ".
2. Une période d'un mois a été déni pour le second thème "Interventions sur site ", an de
travailler avec l'équipe d'intervention de la zone Nord. Ceci an d'appréhender l'architec-
ture, les contraintes du quotidien du monde professionnel et également de développer la
relation client.
Pendant cette période j'ai également préparé des postes clients (préparation multi-postes
en réseau grâce à un serveur WDS 1 ). Pour nir j'ai été en charge d'une dizaine de stagiaires
qui provenaient de diérents centres de formation, an de faciliter leurs insertions dans le
SSU.
3. Le troisième thème : "Formation " avait pour but une visée nettement plus pédagogique
que technique. En eet suite à la décision de la Présidente du Conseil Général de doter les
travailleurs sociaux d'ordinateurs portables, ceux-ci n'ont malheureusement pas eu d'ac-
compagnements sur les diérents éléments installés sur leurs postes.
1. Windows Deployment Services
12
1.3. PROBLÉMATIQUE
Un système d'exploitation plus récent (Windows 7), des logiciels de bureautique mis à jour
(Microsoft Oce Word/Excel 2007), ainsi que la modernisation des services(webmail plu-
tôt qu'un client lourd...), tous ces éléments nécessitent un certain suivi avec les utilisateurs.
Qualié par la suite comme étant une "Aide à la prise en mains de l'outil informatique"
plutôt qu'une formation à proprement parlé, tout simplement car aucun document ociel
n'atteste que je suis un formateur.
Pas moins de 90 agents de la Collectivité ont été formés correctement grâce à Kévin TAO-
CHY et moi-même. Outre l'aspect pédagogique ce mini-projet m'a permis de développer
le côté logistique, à savoir :
Mise en place de groupes
Mise en place de sessions
Coordination des moyens (techniques, humains...)
Un mois entier a été nécessaire pour la réalisation de ce projet qui a été un réel succès,
tellement que les demandes de participations aux sessions se poursuivent actuellement.
1.3 Problématique
An de réaliser correctement ce projet conséquent, un binôme a été formé : mon collègue
Kévin TAOCHY et moi-même. Kévin s'occupant de la partie développement de l'interface web
ainsi que de la partie sécurité informatique.
Quand à moi j'ai été en charge de la mise en place de l'outil de supervision, de l'étude d'un
protocole de communication menant à la rédaction de scripts an de récupérer des informations
sur les imprimantes (et multifonctions) en réseau ainsi que la recherche de diérentes commandes
et outils existants an de réaliser un diagnostic de premier niveau sur les postes de travail.
Notre étude préliminaire a donné naissance à la problématique suivante :
Est-il possible d'intégrer un outil de supervision à la structure déjà en place ? Quel est l'intérêt
de le coupler à des outils d'administration au sein d'une interface web ? Le fait de maximiser
les interventions à distance peut-il inuer sur la réduction des coûts de déplacement liés aux
interventions sur site ?
1.4 Présentation du Rapport

Dans une première partie, ce rapport présente le cahier des charges qui a été établi suite
à la proposition de ce thème de stage. Ainsi seront détaillés l'étude des besoins, les solutions
existantes, puis enn les solutions choisies tout en respectant l'architecture réseau déjà en place.
La seconde étape concerne la présentation des diérents outils, à la fois ceux mis à notre dispo-
sition et également ceux mis en place par la suite, sans oublier les dicultés rencontrées.
Enn nous terminerons avec la conclusion qui décrira l'apport personnel à ce stage ainsi que les
perspectives futures pour ce projet.
13
Chapitre 2
Analyse des besoins et spécications
2.1 Introduction
Une fois la problématique posée, l'étape suivante logique, était l'analyse des besoins. Cette
étape qui peut s'avérer assez longue est une phase préparatoire qui va mener à la réussite du
projet. En eet les statistiques ont montré que dans 70 % des cas un échec sur un projet était
dû à une analyse des besoins bâclée ou quasi inexistante et non pas à un mauvais développement
ou une mauvaise conception.
2.2 Les enjeux du projet

Ce projet a été initié par le SSU, et plus particulièrement par notre tuteur qui a lancé l'idée :
François BOYER pour les agents du SSU. Il faut comprendre que les membres du SSU et plus
particulièrement les techniciens d'interventions sont constamment sur le terrain et se doivent de
maintenir un bon relationnel avec les agents du Conseil Général, leur quotidien est très agité et
ils ont un quota d'interventions à respecter par mois.
Chaque intervention est listée et répertoriée via un outil appelé EasyVista (dont la description
sera donnée dans l'étude de l'existant). On comprend tout de suite que chaque intervention doit
être valorisée et la plus eciente possible (rendu vis-à-vis du temps passé à eectuer cette inter-
vention). C'est dans cette optique qu'intervient la mise en place de notre outil de supervision et
de contrôle distant. Dans le respect de ma problématique, ce projet doit inuer sur les paramètres
suivants et donc les améliorer :
Ecience de l'intervention L'ecience regroupe à la fois la vitesse d'intervention ainsi que

la qualité de l'intervention. Si le technicien bénécie d'informations pertinentes (dès lors se
pose le problème de la dénition d'une information pertinente) il n'aura sans doute pas à
passer autant de temps sur une intervention. S'il sait à quel endroit il devra agir, il devient
évident qu'il pourra alors préparer les outils nécessaires et procéder plus rapidement. Un
outil de diagnostic répond à ce besoin, en fournissant à la demande les informations jugées
nécessaires sur un bien matériel.
L'intervention à distance Une intervention sur site mobilise des moyens, de type humain (le
technicien doit se rendre sur place), de type matériel (il prend un des véhicules de service
du SSU), un des objectifs du SSU cette année est de maximiser les interventions à distance.
Un outil de contrôle résout en partie ce problème, lorsque l'on peut intervenir à distance
selon la nature du problème évidemment.
14
2.3. LES INFORMATIONS PERTINENTES POUR LE TECHNICIEN
2.3 Les informations pertinentes pour le technicien

Grâce à l'outil EasyVista évoqué précédemment, les techniciens se voient attribuer des inter-
ventions à traiter dans les plus brefs délais. Il faut bien évidemment établir un ordre de priorité
dans ces interventions.
Les problèmes les plus fréquents sont ceux liés aux postes de travail (le type de matériel le plus
nombreux), ils peuvent être d'ordre matériel (écran qui ne s'allume plus par exemple), logiciel
(impossibilité de faire une mise à jour) etc... Lorsque le problème est d'ordre logiciel il est plus
qu'essentiel de procéder à une intervention à distance, soit par téléphone avec l'agent concerné,
soit en prenant le contrôle de son poste et ainsi de corriger la défaillance constatée. En cas
de problème concernant un progiciel 1 , l'intervention sera rapatriée à SAPMA. Dans la section
précédente, j'ai évoqué la notion d'information pertinente pour augmenter l'ecience d'une in-
tervention, voyons à présent comment dénir ces informations.
1. Les postes de travail

Le ping Le ping permet de déterminer la première information logique, à savoir si le poste
est présent ou non sur le réseau (suivant si le ping est positif ou non)
Stratégie de groupe Windows Grâce à Active Directory, des stratégies peuvent s'ap-
pliquer aux postes clients, celles-ci peuvent aller des restrictions systèmes (impossibi-
lité d'installer des programmes), aux permissions serveurs (accès à tel ou tel serveur
de stockage en fonction de l'appartenance à un service). Ceci permet de garder un
contrôle sur l'utilisateur et son environnement.
DNS Permet la correspondance entre une adresse ip et un nom plus simple à retenir et
à dénir. Exemple de base si un utilisateur ne peut se connecter à un serveur de
stockage, il est possible que ses paramètres de DNS soient erronés.
Paramètres de proxy Le proxy installé à la DEMS est "ProxySquid", pour rappel un
proxy permet de faire la liaison entre le réseau interne (intranet) et internet, sans
conguration au préalable de ces informations, il est alors impossible à l'utilisateur
de se connecter à internet, et d'utiliser des services tel que le web par exemple.
2. Les imprimantes/multifonctions en réseaux
Le Ping Comme pour les postes de travail, ceci nous permettra de vérier si le matériel
est présent ou non sur le réseau
Le niveau d'encre Sans doute la problème le plus récurent étant donné que les niveaux
d'encre ne sont pas vériés, un état d'alerte (par exemple 15 % d'encre restant) pourra
être installé, pour prévenir ce problème
Absence de papier dans le/les bac(s) concerné(s) Le technicien pourra déterminer
si l'imprimante/multifonction dispose d'un ou plusieurs bacs et si l'en d'entre eux
voire plusieurs sont vides
Modèle, nom et serial number Cela peut sembler anodin mais certains modèles dis-
posent de caractéristiques bien spéciques, qu'il faudra peut-être prendre soin de
vérier (dans des ches techniques) au préalable avant d'intervenir
Localisation physique Pour m'être déjà rendu à plusieurs reprises dans certains locaux
du Conseil Général, il n'est pas chose facile de s'y retrouver, une localisation physique
du matériel avec indication sur le service concerné sera la bienvenue
Statut Le matériel est-il sous tension, est-il occupé au moment où on l'interroge (en cours
d'impression par exemple)...
1. Contraction de Produit et Logiciel qui fait référence à des applications métiers par exemple
15
2.4. ÉTUDE DE L'EXISTANT
2.4 Étude de l'existant

Cette section traite de l'architecture réseau en place actuellement au Conseil Général, ainsi
que des serveurs et/ou des diérents outils desquels nous dépendrons (donc pas de la totalité des
serveurs et outils présents) lors de la réalisation de notre projet. Ces éléments sont à prendre en
considérations, c'est à nous de nous adapter et de respecter ce qui est déjà en place, en aucun
cas nous ne pourrons nous permettre d'imposer un choix qui touche aux politiques déjà établies,
que celles-ci soient de sécurité ou autre.
2.4.1 Architecture du SI
L'architecture du Conseil Général est de type réseau maillé hébergé par l'opérateur histo-
rique. Il Dispose de plus de 150 sites interconnectés avec des débits variés. Le c÷ur du SI 2 est
un DataCenter sous VMWare. Les principaux OS sont Microsoft Windows Server, Debian et
Ubuntu pour les Serveurs. Les postes de travail ont Microsoft Windows XP à 7.
Figure 2.1 C÷ur de réseau du Conseil Général
Le c÷ur de réseau du Conseil Général est composé de la manière suivante :

Sécurité Deux rewalls protègent en permanence le système d'information. Un rewall dit "-
rewall interne" protège les serveurs internes, le second, appelé "rewall internet" sert de
rempart contre les attaques provenant de l'extérieur.
Connexion Deux connexions 10 Mbits en bre sont utilisées pour avoir accès aux applications
métiers et/ou aux sites hébergés par le Conseil Général. Une connexion de 50 Mbits est
dédié uniquement aux connections avec Internet.
DMZ 3 Pour rappel une DMZ ou zone démilitarisée est un sous réseau distinct du réseau local,
lié à celui-ci et à internet par le biais du rewall, en cas d'attaques externes le pirate n'aura
2. Système d'Information
16
accès qu'aux machines placées en DMZ et non au réseau local. Dans la DMZ on retrouve
donc les serveurs et les applications pouvant être accédés depuis l'extérieur, comme le
serveur ftp 4 ou l'application de messagerie.
Figure 2.2 C÷ur de LAN
Connexion Les diérents sites du Conseil Général sont reliés à la direction informatique par
des liaisons BVPN 5 allants de 2 Mbits à 10 Gbits. Les médias utilisés peuvent être de la
SDSL 6 ou de la bre optique.
Site Chaque site possède son propre sous-réseau et communique avec les autres sous-réseaux
grâce au switch c÷ur de réseau. Le réseau du Conseil Général est composé donc de VLAN 7
qui correspondent chacun à un site ou une solution technologique (exemple : wi placé sur
le VLAN ***). Enn sur chaque site un serveur de stockage est placé an que les agents
puissent régulièrement eectuer des sauvegardes de leurs documents de travail.
Voici une liste non exhaustive des serveurs qui me paraissent les plus importants (d'autres
tels que les serveurs d'applications etc... n'ont pas été évoqué volontairement) :
2.4.1. A Le serveur DNS
Un serveur DNS 8 ou serveur de système de nom de domaine est comparable à un annuaire.

En eet lorsque l'on souhaite joindre une machine distante (poste de travail ou serveur) qui se
trouve sur le réseau, notre ordinateur va requêter le serveur DNS pour récupérer l'adresse IP 9 de
4. File Transfer Protocol
5. Broadband Virtual Private Network
6. Symmetric Digital Subscriber Line
7. Virtual Local Area Network
8. Domain Name System
9. Internet Protocol
17
la machine à joindre. Tout simplement le serveur DNS permet de faire la relation entre le nom
de la machine et son adresse IP. Ce service a été conguré sous Windows Server 2003 R2.
2.4.1. B Le serveur DHCP
Un serveur DHCP 10 a pour rôle de distribuer des adresses IP à des clients sur le réseau pour
une durée déterminée (un bail DHCP). Cela permet de délivrer automatique des adresses en
fonction de l'endroit où l'on se connecte. Également ce serveur a été conguré comme l'un des
rôles sous Windows Server 2003 R2.
Par convention, seuls les postes de travail bénécient d'un bail DHCP, et donc d'une durée eec-
tive de l'adresse IP aectée à chaque poste, une fois ce bail dépassé, la machine se verra attribuer
une nouvelle adresse IP.
A contrario les autres éléments placés en réseau doivent absolument avoir une adresse IP xe,
notamment les serveurs ainsi que les imprimantes/multifonctions en réseau. En eet pour des
raisons évidents, ces machines sont sollicitées et requêtées régulièrement, il faut donc une adresse
xée. Des plages d'adresses IP sont donc réservées :
Les serveurs sont adressés en 10.2.1.* Les imprimantes et multifonctions en réseaux sont adressés
en 10.*.2.*
2.4.1. C Le contrôleur de domaine Active Directory
Active Directory est le service d'annuaire de Microsoft. Il faut prendre le terme d'annuaire
au sens large, Les services de domaine Active Directory stockent les données d'annuaire et gèrent
les communications entre les utilisateurs et les domaines, y compris le processus d'ouverture de
session utilisateur, l'authentication et les recherches dans l'annuaire. Le but étant d'orir des
services centralisés. Donc un utilisateur enregistré peut se connecter sur n'importe quel poste
du Conseil Général avec ses propres logins, tant que ce poste est placé correctement sur le do-
maine. Autre particularité les utilisateurs font partie de groupes que l'on appelle des OU 11 , qui
permettent ainsi d'identier les droits de chacun, et donc les stratégies qui sont appliquées. Un
contrôleur de domaine Active Directory est un serveur qui exécute les services de domaine Active
Directory.
LDAP 12 est le protocole qui permet d'interroger cet annuaire AD.
2.4.2 Easy Vista

EasyVista permet de recenser le matériel actif (gestion de l'inventaire) et de l'associer grâce
à un lien symbolique à des agents et aux services concernés. Le logiciel intègre également la
gestion des logiciels installés sur les équipements informatiques, et surtout les licences associées.
Autre fonctionnalité intéressante et largement exploitée au sein de la DEMS : La gestion des
problèmes, en eet au sein de l'interface se trouve une partie spécialisée dans la création de ches
de signalements d'incidents (chaque che est associée à un ticket unique), qui seront visibles par
les techniciens et seront répertoriées comme étant des interventions.
10. Dynamic Host Conguration Protocol

11. Organizational Unit
12. Lightweight Directory Access Protocol
18
Figure 2.3 Exemple de che de signalement d'incident
2.4.3 Le parc Imprimantes

Le parc imprimantes du Conseil Général, se compose d'imprimantes classiques (qui ne dis-
posent pas d'interface réseau, mais elles sont très rares), d'imprimantes monochromes en réseau,
d'imprimantes couleurs en réseau et également de multifonctions en réseau. Suite au dernier re-
censement du matériel en réseau il s'avère que 448 imprimantes/multifonctions sont placées en
réseau. Elles sont réparties de la sorte :
Figure 2.4 Hétérogénéité du parc d'imprimantes
Ce qui attire tout de suite l'÷il est donc la forte hétérogénéité de ce parc, ceci s'explique tout
simplement car des marchés publics sont établis assez régulièrement lorsqu'une nouvelle demande
est en cours d'exécution, donc il est impossible de privilégier telle ou telle marque de matériel.
Cependant je constate l'énorme pourcentage occupé par la marque HP (une trentaine de mo-
dèles diérents tous confondus) qui représente 273 exemplaires, suivi de près par Kyocera (cinq
modèles ) avec ses 104 exemplaires, puis de Toshiba (trois modèles) composé de 59 exemplaires.
19
2.5. GESTION DE PROJET
Les autres marques ne sont pas vraiment signicatives en terme d'eectifs , à savoir : Lexmark,
Canon et Sharp. Bon nombre des simples imprimantes sont destinées à disparaitre dans un futur
proche, remplacées par des multifonctions au sein des services ( par exemple un service où se
trouvent une imprimante couleurs, une imprimante monochrome et un scanner, se verra attribuer
une multifonction remplaçant tout ce lot de matériels).
2.4.3. A Panel Top Access
Le Panel Top Access est une application Web, permettant d'administrer, de paramétrer ou de
surveiller à distance l'état de la machine. Ce Panel est disponible sur l'ensemble des imprimantes
et multifonctions en réseau.
2.4.4 Convention de nommage

En informatique une convention de nommage, est une ou plusieurs règles à respecter, en gé-
néral une suite de caractères qui formalise (dans notre cas d'utilisation) un bien matériel.
En eet chaque bien matériel au Conseil Général possède un identiant unique que l'on appelle
un "code matériel" présent sous la forme d'une étiquette avec un code barre, collée sur chacun
d'entre eux. Lors de la préparation des postes, une étape essentielle est donc le renommage du
matériel pour l'identication sur le réseau (****** représente le code matériel disponible sur
l'étiquette qui est collée) :
PC****** pour les postes de travail

PT****** pour les ordinateurs portables
PR****** pour les imprimantes
En respectant ce nommage, l'inventaire du parc sera facilité et une fois l'ensemble ramené dans
l'outil EasyVista, cela permettra de mieux identier chaque matériel. Des sessions de recensement
sont organisées régulièrement an de maintenir le parc à jour. Kévin et moi-même avons participé
à ses recensements dans le cadre de notre intégration au SSU. Si concernant les postes de travail
et les portables, le renommage est respecté (vis à vis de la procédure à suivre pour la préparation
des postes), pour les imprimantes c'est une toute autre paire de manches, en eet seulement
70 imprimantes/multifonctions en réseau sont nommées correctement à l'aide du Top Access
sur près de 450 matériels. Des mesures seront à prendre très prochainement an de maintenir
l'uniformité du parc des imprimantes.
2.5 Gestion de projet
Figure 2.5 Gestion de Projet
20
Il est nécessaire de mener une conduite de projet, et donc d'instaurer une certaine trame à
suivre pour le bon déroulement de ce projet. Il faut prendre en compte le contexte (environ-
nement), les fournisseurs (service interne, prestataire...) et l'impact qu'aura notre outil sur les
utilisateurs (référence au besoin).
2.5.1 Équipe Projet
Figure 2.6 Graphe systémique de Patrick IRSAPOULLE
La réussite d'un projet passe par une organisation rigoureuse et ecace de l'équipe projet.
Deux notions sont à identier à présent : la MOA 13 et la MOE 14 .Les techniciens du SSU re-
présentent la MOA, car ils sont à l'origine de l'expression du besoin. Durant ce stage, Kévin
TAOCHY et moi-même avons joué le rôle de chef de projet, nous avons donc formé la MOE,
c'est-à-dire le personnel chargé de prendre connaissance du besoin exprimé et d'y répondre en
y apportant des solutions. Bien entendu, nous avons dû quotidiennement faire appel à nos col-
lègues de la DEMS, qui nous ont apporté leur aide, ou cas inverse, nous-même aider ces personnes.
Ce graphe représente les relations professionnelles entre les diérents acteurs, ces relations sont
exprimées par des èches dont la taille est proportionnelle à l'intensité des interactions entre ces
acteurs.
13. Maîtrise d'ouvrage

14. Maîtrise d'oeuvre
21
2.5.2 Planning Prévisionnel
Figure 2.7 Planning prévisionnel
2.5.3 Cycle de vie du Projet

Du planning prévisionnel précédent découle le cycle de vie du projet, il a semblé évident que
celui-ci serait un modèle en cascade. Plus simplement à chaque phase d'avancement du projet
une étape de vérication était nécessaire. Chaque n de mois une réunion mensuelle est orga-
nisée au SSU, an d'évaluer les tâches du prochain mois, ce qui a été réalisé pendant le mois etc...
Figure 2.8 Modèle en Cascade
Ces mensuelles nous ont permis de résumer notre avancement dans le projet à chacune de ses
phases, une fois que la phase actuelle était validée par notre chef de service, notre tuteur ainsi
que les techniciens, nous avons pu progresser petit à petit. Évidemment ce modèle sous-entend
de terminer à une date précise et de produire les livrables que si ils sont correctement dénis au
préalable.
Figure 2.9 Validation mensuelle de la progression du projet
22
2.5.4 Spécication des exigences

J'ai dû me consacrer principalement à ces imprimantes et multifonctions pendant que mon
collègue, Kévin, s'occupait des postes de travail. Avant toute étude des technologies à utiliser (le
chapitre suivant) nous avons dû remettre en considération le sujet de stage. En eet si le terme
supervision s'accorde parfaitement avec les imprimantes en réseau, ce n'est pas le cas pour les
postes de travail.
Il faut avouer en eet que superviser près de 3500 postes de travail ne serait pas très judicieux.
En revanche après m'être concerté avec mon collègue Kévin TAOCHY et notre tuteur François
BOYER, il a été convenu que le terme approprié pour les postes de travail serait uniquement
"diagnostic", vu la nature des outils à utiliser. Les états des postes seront achés et les techniciens
pourront se connecter à distance sur ceux-ci grâce à l'interface web uniée.
2.5.5 Exemple d'un scénario et d'un cas d'utilisation

Durant ma période de stage, j'ai pu moi-même assister à un des cas évoqués par notre tuteur
lors de la présentation des thèmes de stage. En eet les agents du CG ne possèdent que peu voire
pas de connaissances concernant la gestion d'un bien matériel telle qu'une imprimante en réseau,
et de toute façon ce n'est pas leur domaine de compétence.
Un scénario classique : Un agent du Conseil Général lance une impression d'un document, rien
ne se passe. Cet agent poste alors une demande d'intervention , en remplissant un formulaire
qui se trouve sur l'intranet. Un des techniciens présents ce jour-là indique sur EasyVista qu'il va
se charger de cette intervention. Il prend donc une des voitures du SSU (le nombre de véhicules
étant assez limité) se rend sur le site concerné an de dépanner cet agent, et une fois sur place,
se rend compte qu'une cartouche couleur était totalement vide et donc empêcher le lancement
de l'impression.
Reprenons dans l'ordre, pour cette intervention superue :
Temps de travail perdu pour une pseudo-intervention

Un technicien mobilisé alors que d'autres interventions n'ont pas pu être résolues
Un véhicule a été mobilisé, ce qui obligera peut-être un autre technicien à attendre le retour
de celui-ci
Du carburant a été consommé lors de ce trajet, et représente donc une dépense non indis-
pensable
Si une application telle que celle que nous allons mettre en place était déjà disponible, le niveau
d'alerte d'encre aurait pu être remonté et un technicien aurait pu prévenir le service concerné
an de changer la cartouche dont il est question.
Cette situation semble exagérée à première vue, mais selon les techniciens ces cas arrivent telle-
ment souvent, que nous ne pouvons les négliger.
Il faut prendre un peu de recul an d'observer la situation actuelle, en anticipant ce genre
de problèmes et donc d'établir un diagnostic de premier niveau (matériel et/ou logiciel), nous
pourrons sur le court terme, augmenter les interventions à distance, et surtout les rendre plus
ecientes. Sur le long terme, le problème des restrictions budgétaires qui est évoqué actuellement,
ne sera certes pas résolu en évitant ces trajets et donc ces dépenses non essentielles, mais il n'y
a pas de petites économies. Ainsi cumulés ces fonds pourront servir à d'autres missions plus
nécessiteuses.
23
Chapitre 3
État de l'art
3.1 Introduction
Une fois l'environnement de travail étudié, il fallait trouver des solution pour répondre à
notre problématique. Intervient alors l'étape de l'état de l'art, c'est-à-dire l'état des techniques
existantes dans le domaine étudié, sans que nous ayons besoin de faire preuve d'une activité
inventive. "Il ne faut pas réinventer la roue." Les sources peuvent être diverses : journaux,
revues et publications scientiques, articles, rapports de recherches... Cette démarche m'a permis
de dénir les technologies à utiliser et à appliquer.
3.2 L'aspect Monitoring

Le terme Monitoring couramment utilisé, provient de l'anglais, il signie supervision. Cepen-
dant une précision est à apporter, en eet ceci est un abus de langage, car en vérité le Monitoring
est composé de deux disciplines : la métrologie et la supervision.
La métrologie permet de créer des historiques de données, d'y appliquer un traitement (des ltres
par exemple) an d'extraire les données qui nous intéressent et de les présenter sous forme de
graphiques. Cet historique des données permet si besoin d'apporter des correctifs au niveau des
paramétrages des services, le juste pourcentage des ressources à utiliser... Cet aspect du Moni-
toring est tout aussi important car il va permettre d'améliorer le service, et donc ainsi le rendu
de l'utilisateur.
Concentrons-nous à présent sur la véritable notion qui est dénie dans ce rapport à savoir la
supervision. Une dénition récurrente sur le Web indique que : "la supervision est une technique
de suivi de pilotage informatique de procédés de fabrication automatisés. La supervision concerne
l'acquisition de données (mesures, alarmes, retour d'état de fonctionnement) et des paramètres
de commande des processus généralement conés à des automates programmables."
En résumé la supervision est la surveillance du bon fonctionnement d'un système ou d'une ac-
tivité. En eet quel que soit le secteur d'activité, l'informatique est devenue l'épine dorsale de
l'entreprise. Plus particulièrement le système d'information qui est au centre de l'activité de
diérentes entités métiers, doit fonctionner correctement et en permanence an de garantir l'ef-
cacité de l'entreprise.
Les problèmes liés à l'informatique doivent donc être réduits le plus que possible, car l'indispo-
nibilité d'un ou plusieurs éléments, quel que soit son niveau signicatif (réseau, serveurs d'appli-
cations, serveurs de données, terminal utilisateur...) inuera sur la qualité de service et donc le
bon fonctionnement de l'entreprise.
24
3.2. L'ASPECT MONITORING
Deux enjeux majeurs sont à noter :
garantir la disponibilité et les niveaux de service du système en cas de panne ou de baisse

des performances
tenter de prévenir l'administrateur des diérents problèmes et au besoin assurer une re-
montée des informations an de garantir une durée d'intervention minimale
3.2.1 Que peut-on superviser ?

La supervision est un vaste domaine de l'informatique qui reprend plusieurs activités dont
les principales sont :
Surveiller
Visualiser
Analyser
Piloter
Alerter
La véritable question à se poser serait " est-ce qu'un système d'information peut ne pas avoir de
faille ? "
Concrètement an de maintenir un fonctionnement optimal, tout devrait être supervisé, ou du
moins peut-être supervisé du moment que l'on peut déterminer un état :
réseau
serveurs
périphériques
postes client
applications...
Libre à l'administrateur de placer des niveaux de priorités entre les diérents éléments pour
dénir ce qui doit ou ce qui ne doit pas être supervisé selon diérents critères (charge du réseau,
manque de moyens...).
Actuellement à la DEMS, ne sont supervisés que les switchs, serveurs et tout ce qui touche à
l'état du réseau en lui-même (trac eectif).
Il sera important de rajouter les diérentes imprimantes et multifonctions en réseau parmi les
périphériques à superviser. Concernant les postes de travail, ils sont trop nombreux et les remon-
tées d'informations sur ceux-ci ne seraient pas assez pertinentes pour évaluer les problèmes. Des
outils d'administration plutôt que de supervision seront à adopter pour ce type de matériel.
3.2.2 Méthodes de Supervision

Deux grandes méthodes s'opposent lorsque l'on parle de supervision.
le polling
le heartbeat
Le Polling est un sondage réalisé périodiquement (à intervalle de temps régulier) par un super-
viseur.
25
Avantages Inconvénients
A l'initiative du superviseur Des échanges pour rien
Polling Permet un véritable suivi Temps de réaction
Possibilité de ne pas voir certains changements
Figure 3.1 Méthode du Polling
Le HeartBeat est un signal émis par un équipement à chaque changement d'état.
Avantages Inconvénients
Des échanges si nécessaire Suivi moins complet
HeartBeat Temps de réaction A l'initiative de l'équipement actif
Tous les changements d'états sont remontés
Figure 3.2 Méthode du heartbeat
En conclusion il n'y a pas de meilleure ou de moins bonne solution, mais il faut penser à orienter
le concept en fonction du projet que l'on veut mener.
Suite à une longue réexion an de déterminer lequel des deux concepts était le plus approprié à
notre projet, nous avons ni par conclure que celui-ci se rapprochera le plus du Polling, il faudra
qu'un serveur central interroge régulièrement les périphériques, et stocke les données, cependant
aucune notication particulière ne sera renvoyée.
L'outil sera à utiliser au besoin et donc sur demande, uniquement lorsque les pannes seront réfé-
rencées et indiquées. C'est pour cela que l'on couple la notion de Supervision à celle de Diagnostic.
26
3.2.3 Les diérentes solutions

Un outil de supervision doit répondre aux critères suivants :
des mécanismes pour déterminer l'état d'une ressource/process
une console de monitoring
des remontées d'alertes
3.2.3. A Les solutions propriétaires
Commençons par les solutions dites propriétaires. Quatre grosses sociétés se partagent le
marché de la supervision, elles sont appelées le "Big4".
Figure 3.3 Ibm Tivoli Software Figure 3.4 HP Openview
Figure 3.5 Computer Associates Tech-

nologies Unicenter Figure 3.6 HP Openview
Le but n'était évidemment pas d'acheter une ou plusieurs licences de logiciels propriétaires.
Même si ceux-ci proposent des solutions confortables, avec des atouts tels que le support et la
maintenance. Il faut comprendre qu'à l'heure actuelle, les anciens critères (abilité, support...)
qui opposaient les logiciels propriétaires aux logiciels Open Source ne sont plus valables. En ef-
fet aujourd'hui il est tout à fait possible d'avoir un Système d'Information dans une entreprise
composé uniquement de logiciels Open Source.
Leur principal atout ? Non pas la gratuité comme beaucoup le pense, mais bel et bien les réelles
communautés sur lesquelles s'appuient les solutions. Universitaires, développeurs reconnus, pro-
fessionnels tous s'associent désormais et forment les principaux contributeurs du monde Open
Source. Mieux encore les développeurs de logiciels propriétaires se séparent de leurs précédentes
rmes dans le but d'orir leurs propres solutions libres.
Ces solutions qui ont vu les jour et qui sont testées maintes et maintes fois avec des correctifs ré-
guliers, sont totalement ables, orent une modularité (plugins etc...) et une compatibilité totale.
En eet nit le problème des protocoles propriétaires, les normes sont adoptées et respectées, ce
qui permet d'établir une certaine souplesse et donc cela autorise l'hétérogénéité du matériel à
acheter.
L'administrateur ayant adopté une telle solution ne verra qu'une seule et véritable contrainte,
le besoin constant de rester informé sur la technologie, il faudra régulièrement se rendre sur les
forums, les blogs tout ce qui est capable de rééchir l'aspect communautaire, et ainsi d'orir
des réponses aux questions posées. Cet échange de bon procédé, permettra de mettre à jour
régulièrement les solutions et de les adapter en fonction du besoin utilisateur.
Voyons à présent les solutions disponibles dans le monde de l'Open Source concernant le domaine
de la supervision.
27
Figure 3.7 Métrologie ou Supervision ?
3.2.3. B Les solutions Open Source
Il faut savoir qu'il existe des dizaines de solutions Open Source dédiées au Monitoring, le
principal critère de choix réside dans les diérents cas d'utilisation.
Dans cette partie sont présentées quatre solutions parmi les grands noms du Monitoring, à savoir :
Zabbix, Cacti,Nagios et Centreon (d'autres solutions telles que "Munin" ont été volontairement
ignorées car elles sont décrites comme présentant uniquement le côté métrologie du Monitoring).
Ainsi un comparatif sera établi an de dénir correctement quelle solution sera la plus appropriée
en terme de supervision et non de métrologie.
1.
Zabbix est une application libre (open source) de supervision des systèmes et des réseaux.
Par sa polyvalence, Zabbix peut superviser et vérier les statuts d'une multitude de ser-
vices réseaux, ou systèmes, ce qui fait de lui un outil complet proposant des fonctionnalités
relatives à la supervision (alertes, mesures, actions sur conditions...).
Le principal reproche vient de l'aspect graphique où dans certains cas la lisibilité laisse à
désirer. Certains lui reprochent également son interface web dite un peu "vieillotte" et la
prise en main initiale n'est pas forcément intuitive.
2.
Cacti est un outil de monitoring qui a la particularité d'avoir une " Plugin architecture"
qui va lui permettre l'ajout de fonctionnalités grâce à l'importation et à la congurations
de plugins via l'interface web. L'aspect supervision proposé ici ne sera pas aussi développé
que dans les autres logiciels (nagios par exemple), on notera par exemple l'absence de panel
de msesures, de groupes d'utilisateurs...
Donc Cacti reste un outil de métrologie intégrant de nombreuses possibilités grâce aux
plugins, avec la possibilité d'une mise en place de supervision mais uniquement dans les
cas les plus simples.
3.
28
Nagios est ce que l'on appelle un ordonnanceur , c'est-à-dire qu'il va lancer les diérents
tests de supervision, appelés contrôles, sur les hosts et services. Il reste l'outil de supervi-
sion le plus utilisé à l'heure actuelle, sa conguration sous forme de chiers, peut s'avérer
vite repoussante mais en fait cependant un candidat idéal pour l'automatisation.
L'inconvénient de Nagios reste son IHM 1 très basique. Il faut avouer que son interface
ne donne pas spécialement envie d'être consultée, en eet au delà de la pertinence de
l'information, il faut de la compréhension et de l'interprétation. C'est sur ce constat que
vient se greer la prochaine solution décrite : Centreon.
4.
Centreon, une interface à Nagios. Première précision à apporter, le coeur de Centreon est
basé sur Nagios. Centreon propose une interface web diérente de celle de Nagios et y
ajoute des fonctionnalités (génération de la conguration de Nagios, stockage des données
de performance, interface ergonomique...).
En résumé, Centreon est considéré comme un outil à part entière même si il est basé sur
Nagios comme ordonnanceur. Il propose donc au sein d'une même interface tout ce qui est
nécessaire à la surveillance de l'infrastructure et donc à faire de la supervision pure et dure.
Malgré tout il ne propose que le minimum concernant la métrologie, on ne pourra pas par
exemple remonter des informations orientées services comme celle d'une base de donnée,
que l'on pourrait avoir sous Cacti ou Munin.
3.2.3. C Comparatif général des solutions Open Source

Solution Avantages Inconvénients
Zabbix - Outil complet - Prise en main complexe
- Polyvalent (supervision + métro- - Manque de lisibilité sur certains
logie) écrans
Cacti - Outil de métrologie complet - Création complexe des templates
- Multitude de fonctionnalités grâce - Insusant pour une supervision
aux plugins d'un grand parc matériel
Nagios - Outil de supervision par excellence - IHM à améliorer
- Automatisation (templates) - Conguration par chier
- Mesure des ressources - Pas d'exploitation graphique des
mesures
Centreon - IHM agréable et intuitive - L'aspect Métrologie est des plus
simples
- Basé sur le c÷ur de Nagios - Pas de graphes corrélant les per-
formances (utilisation d'un Apache
par exemple)
- Zabbix propose une interface uniée, avec des fonctions avancées, la partie métrologie pré-
sente présente vraiment des notions intéressantes (graphes complexes de mesures...), sa prise en
main n'est pas assez intuitive pour compenser son IHM qui est moins agréable que Centreon par
exemple.
- Il s'avère qu'au nal, Cacti soit un outil de métrologie avancée (pas autant que Munin),
même si il présent un aspect de supervision, pas assez développé malheureusement pour conduire
à son choix.
1. Interface Homme Machine
29
- Nagios semble parfait pour l'automatisation des congurations et la gestion centralisée de

l'infrastructure, son gros désavantage est et restera son interface graphique qui repoussera tous
les débutants dans le domaine de la supervision.
Mon choix s'est donc porté sur Centreon, an de bénécier d'une supervision com-
plète, avec également des possibilités de métrologie simple (ceci ne nous intéresse pas
vraiment), les générations de congurations automatiques, et son interface intuitive
en font un outil de choix à mettre en place.
3.2.4 La solution retenue : Centreon Enterprise Server
Centreon est une marque de la société Meréthis. Outre les arguments présentés
précédemment et qui ont conditionné mon choix, il fallait se décider sur la version à installer.
Suite à des recherches plus approfondies et aux conseil de Vincent BEAUVAL, je me suis
penché sur une variante de la solution, à savoir : Centron Entreprise Server.
Finit les installations "brique par brique", rappelons qu'à la base Centreon est une surcouche de
Nagios, et donc logiquement il fallait procéder à une installation complète de Nagios (plugins..)
puis à l'installation de Centreon. Grâce à CES, on retrouve le meilleur de la suite Centreon
dans une solution ecace, complète et maintenue au sein d'un même package. L'intérêt est bien
entendu de déployer rapidement les outils nécessaires à notre supervision vis-à-vis de notre in-
frastructure.
La solution est présentée sous la forme d'une image ISO, on peut alors la graver pour procéder à
l'installation, ou tout simplement créer une machine virtuelle basée sur celle-ci. Une fois installée
(comptez une vingtaine de minutes), CES est prêt à l'emploi. Il est composé des diérents outils
suivants :
1. Un noyau Linux
CES est basé sur la distribution Centos 6.5, elle-même basée sur RedHat
Enterprise Linux (REHL). Le principal avantage vient de l'outil YUM qui facilite l'exploitation
et la gestion des paquets au format RPM a , toutes les dépendances sont automatiquement
calculées par YUM, il n'est donc pas nécessaire de vérier les versions de chaque paquet. Un
simple "yum update" permet de mettre à jour tous les éléments de CES.
a. Redhat Package Management
2. Un Ordonnanceur (moteur central)
Depuis sa dernière release en date (mars 2014),CES propose le choix de deux

ordonnanceurs, le premier Nagios le plus classique connu de tous, et le second Centreon Engine,
développé par les équipe de Meréthis. Celui-ci ore une alternative au moteur central Nagios,
mais est cependant basé su Nagios 3.2. C'est un véritable challenge que se sont lancés les
équipes de Meréthis, en ne cachant pas qu'ils souhaitent à long terme remplacer Nagios par leur
propre ordonnanceur.
30
3. Un Broker
Un Broker est un module chargé de remonter les informations dans la base de données.
Initialement CES ne proposait que ndOutils, qui allait de pair avec Nagios. Mais depuis
l'arrivée de Centreon Engine, Meréthis a également développé son propre module, à savoir
Centreon Broker.
4. Une IHM intuitive
Ne nous attarderons pas ici, une description a déjà été faite au préalable, il
s'agit bien évidemment de Centreon lui-même, qui fournit une interface simpliée, pour rendre
la consultation de l'état du système accessible aux utilisateurs, également à présent les
informations et l'administration des ordonnanceurs sont inclus dans l'interface (sous le nom de
Monitoring Engine).
5. Un Serveur HTTP
CES propose la version propose la version la plus récente de APACHE (la

version 2) qui est actuellement le serveur HTTP le plus utilisé pour le développement. Son
support Multi-plateformes ainsi que les processus légers UNIX en font un incontournable.
6. Une base de données et son SGBD
Une base de données est installée an de permettre la remontée des

données à l'aide du Broker. An d'innover et de changer du classique Mysql Server, Meréthis
décide d'inclure suite à une conférence sur MySQL et MariaDB, le second à sa suite CES pour
des raisons de qualité et de performances. MariaDB se base sur le code source de MySQL 5.1, il
est donc 100 % compatible avec celui-ci et dispose des mêmes dépendances (par exemple si l'on
veut que PHP5 dialogue avec le serveur MariaDB il faut installer le paquet " php5-mysql").
Diérentes versions du package CES sont ainsi proposées. La version Standard est Open Source,
elle est donc libre et gratuite. Les autres versions quand à elles nécessitent une souscription
annuelle, ces versions proposent un support et donnent également accès à des sondes et des
modèles complémentaires touchant la partie matérielle. Nous nous contenterons de la version
Standard qui semble parfaitement répondre à nos attentes.
3.2.5 Le protocole de supervision

An de superviser des hôtes, il faut bien évidemment un serveur central relié à la totalité des
hôtes. Le véritable problème qui se pose par la suite, comment faire communiquer ecacement
ce serveur central avec les hôtes à superviser ? Entre en jeu la notion de protocole de supervision,
qui indépendamment de la plateforme et/ou du type de matériel devra assurer la communication
entre les acteurs précédents. SNMP nous avait été plus que suggérée lors de la présentation
du sujet de stage par notre tuteur. Le chapitre suivant explique les diérents mécanismes qui
entrent en jeu lors de l'utilisation du protocole SNMP, ainsi que ses avantages qui ont conduit à
son utilisation.
31
Chapitre 4
Le protocole solution pour la

supervision en réseau
4.1 Présentation de Simple Network Management Protocol

Un chapitre entier est dédié à l'étude de ce protocole sur lequel repose l'ensemble des requêtes
eectuées lors de la collecte des informations concernant les imprimantes (et multifonctions) en
réseau.
SNMP est un protocole de gestion de réseaux proposé par l'IETF 1 , un groupe informel et
international, ouvert à tout individu et participant à l'élaboration de standards Internet). Il reste
actuellement le protocole le plus couramment utilisé pour la gestion des équipements en réseaux.
SNMP est écrit en ASN.1 2 , un standard international spéciant une notation qui est destinée
à décrire des structures de données.
Comme son nom l'indique SNMP est un protocole assez simple, mais sa principale force réside
dans le fait de pouvoir gérer des périphériques hétérogènes et complexes sur le réseau. De ce fait
ce protocole peut également être utilisé pour la gestion à distance des applications : bases de
donnée,serveurs, logiciels...
L'environnement de gestion SNMP est constitué de plusieurs composantes :
Le Manager (station de supervision) exécute les applications de gestion qui contrôlent les
éléments réseaux, la plupart du temps le manager est un simple poste de travail
Les éléments actifs du réseau, sont les équipements que l'on cherche à gérer (switchs,
serveurs...)
La MIB (Management Information Base), est une collection d'objets résidant dans une
base d'information virtuelle
Le Protocole, qui eectue la relation entre le Manager et les éléments actifs
Chaque élément actif dispose d'une entité que l'on appelle un "agent", qui répond aux requêtes
du Manager.
32
4.2. LES PRINCIPAUX ÉLÉMENTS
Figure 4.1 Schéma SNMP de communication de base
4.2 Les principaux éléments

4.2.1 Le Manager
Rappelons que le Manager se trouvera sur un machine d'administration (un poste de travail
en général). Il reste un client avant tout, étant donné que c'est lui qui envoie les diérentes re-
quêtes aux agents. Il devra disposer d'une fonction serveur, car il doit également rester à l'écoute
des alertes que les diérents équipements sont susceptibles d'émettre à tout moment.
Si l'on se base sur le schéma précédent, l'administrateur peut observer correctement le compor-
tement de ses diérents équipements en réseau.
Le Manager dispose d'un serveur qui reste à l'écoute sur le port UDP 162 ainsi que d'éventuels
signaux d'alarme appelés des "traps". Le Manager peut tout autant être installé sur une machine
de type Windows, qu'une machine de type UNIX.
4.2.2 Agent SNMP

L'agent est un programme qui fait partie de l'élément actif du réseau. L'activation de cet
agent permet de recueillir la base de données d'informations et la rend disponible aux interroga-
tions du Manager SNMP. Ces agents peuvent être standards (Net-SNMP par exemple) ou encore
spécique à un fournisseur (HP insight agent par exemple).
1. Internet Engineering Task Force

2. Abstract Syntax Number 1
33
4.3. DES INFORMATIONS STRUCTURÉES
Cet agent doit rester à l'écoute d'un port particulier, le port UDP 161.
Les principales fonctions d'un agent SNMP :
Collecter des informations de gestion sur son environnement local

Récupérer des informations de gestion tel que déni dans la MIB propriétaire
Signaler un évènement au gestionnaire
Par ailleurs même si la principale fonction de l'agent est de rester à l'écoute des éventuelles
requêtes du Manager et y répondre si il y est autorisé, il doit également être capable d'agir de
sa propre initiative, s'il a été conguré.
Par exemple, il pourra émettre une alerte si le débit d'une interface réseau, atteint une valeur
considérée par l'administrateur comme étant critique. Plusieurs niveaux d'alertes peuvent ainsi
être dénis, selon la complexité de l'agent (température du processeur, occupation disque dur,
utilisation CPU...).
Figure 4.2 Les échanges entre le Manager et l'Agent
4.3 Des informations structurées

4.3.1 Management Information Base
Chaque agent SNMP maintient une base de données décrivant les paramètres de l'appareil
géré. Le Manager SNMP utilise cette base de données pour demander à l'agent des renseigne-
ments spéciques. Cette base de données commune partagée entre l'agent et le Manager est
appelée Management Information Base (MIB).
Généralement ces MIB contiennent l'ensemble des valeurs statistiques et de contrôle dénis pour
les éléments actif du réseau. SNMP permet également l'extension de ces valeurs standards avec
des valeurs spéciques à chaque agent, grâce à l'utilisation de MIB privées.
Un chier MIB est écrit en utilisant une syntaxe particulière, cette syntaxe s'appelle SMI 3 ,
basée sur ASN.1 tout comme SNMP lui-même.
En résumé, les chiers MIB sont l'ensemble des requêtes que le Manager peut eectuer vers
l'agent. L'agent collecte ces données localement et les stocke, tel que déni dans la MIB. Ainsi
le Manager doit être conscient de la structure (que celle-ci soit de type standard ou privée)de la
MIB an d'interroger l'agent au bon endroit.
3. Structure of Management Information
34
4.3. DES INFORMATIONS STRUCTURÉES
4.3.2 Structure d'une MIB et Object IDentier

Rappelons que la MIB est une collection d'informations pour la gestion des éléments du ré-
seau. Sa structure est une arborescence hiérarchique dont chaque noeud est déni par un nombre
ou un Object IDentier (OID). Chaque identiant est unique et représente les caractéristiques
spéciques du périphérique géré. Lorsqu'un OID est interrogé, la valeur de retour n'est pas un
type unique (texte,entier,compteur,tableau...) Un OID est donc une séquence de chires séparés
par des points.
Une MIB est un arbre très dense, il peut y avoir des milliers d'OID dans la MIB.
Figure 4.3 Structure de l'arborescence d'une MIB
Cet exemple illustre d'ailleurs un object typique qui est déclaré dans la RFC1213, à savoir le
"sysDescr" (une description du périphérique interrogé) dont l'OID s'écrit .1.3.6.1.2.1.1.1.
Une petite particularité est à signaler dans la MIB il s'agit de la branche "private" aussi appelée
"private enterprises" (dont l'OID est 1.3.6.1.4.1). Cette branche permet à chaque entreprise
de gérer sa MIB spécique. Chaque entreprise se voit attribuer un OID unique et se retrouve
alors à la charge de la gestion de sa branche. Les diérents OID d'entreprises sont alloués par
l'IANA 4 qui est l'organisation dont le rôle est la gestion de l'espace d'adressage IP d'Internet,
ainsi que d'autres ressources partagées de numérotation qui sont requises par des protocoles de
communication sur Internet.
4. Internet Assigned Numbers Authority
35
4.4. LES PARAMÈTRES D'INTERROGATIONS
4.4 Les paramètres d'interrogations

4.4.1 Les paquets à installer
Nous avons vu au préalable,quels éléments nous avons besoin an d'eectuer des requêtes
SNMP, il faut s'assurer que notre Manager dispose d'une environnement SNMP, pour se faire
le mieux est d'installer et de congurer un serveur SNMP en utilisant la solution open-source
"net-snmpd".
La suite CES dispose déjà d'un serveur SNMP installé et les congurations sont déjà eectuées
de manière à ce le package puisse être déployé immédiatement, et que les requêtes puissent se
faire sans problème.
4.4.2 Les diérentes versions de SNMP

Depuis la création de SNMP, ce protocole a connu des améliorations importantes. Cependant
les précédentes versions (la V1 et la V2C) sont encore les versions les plus utilisées actuellement.
Un support de SNMP V3 a récemment été lancé car il est plus sécurisé si on le compare à ses
prédécesseurs.
1. SNMP V1 : C'est la première version du protocole. La sécurité de cette version est mini-
male, car elle basée uniquement sur la chaîne de caractère appelée "communauté". Cette
version du protocole est dénie dans les RFC 1155 et 1157.
2. SNMP V2C : C'est un protocole révisé, qui comprend les améliorations de SNMP V1 dans
diérents domaines tels que :
Les types de paquets

Les éléments de structure MIB
Les requêtes protocolaires MIB
Cependant ce protocole utilise la structure d'administration de SNMP V1 ( à savoir "com-

munauté") d'où le terme SNMP V2C
3. SNMP V3 : Aussi connu sous le nom de version sécurisée de SNMP. SNMP V3 facilite la
conguration à distance des entités SNMP.
Ces trois versions sont les principales, même si des versions intermédiaires ont vu le jour (SNMP
Sec, SNMP V2, SNMP V2U,SNMP V2P), celles-ci ne présentent que des mises à jours mineures
plutôt que de véritables améliorations.
Actuellement les versions les plus utilisées (par ordre d'utilisation) sont : SNMP V1, SNMP V3
puis SNMP V2C.
Malgré tout la version SNMP V1 perdure encore sur les périphériques, plusieurs facteurs explique
ce phénomène :
Les infrastructures déployées en V1 ne sont plus modiées, tout simplement car cela fonc-
tionnait susamment à l'époque, du coup aucune modication n'y est appliquée
Les autres versions de SNMP ont été implémentées tardivement par les diérents construc-
teurs
SNMP V1 demande très peu de ressources sur des petits équipements tels qu'une impri-
mante ou un Hub
36
4.5. LES REQUÊTES SNMP
4.4.3 Les communautés

La notion de communauté est utilisée dans les réseaux administrés à l'aide du protocole
SNMP. Elle réunit à la fois le Manager et les diérents agents. Chaque communauté est identi-
ée par un nom de communauté. Par défaut seules les communautés "public" et "private" sont
dénies, cependant il est possible de nommer sa propre communauté, ceci à des ns évidents de
sécurité et donc de créer son propre domaine d'administration.
Ces dénitions de communautés permettent :
L'authentication : Consiste à envoyer une requête avec comme mot de passe le nom de la
communauté, permettant au récepteur de vérier l'authenticité de ce dernier
La politique d'accès : Pas d'accès, read-only ou read-write
Le service Proxy : Si les périphériques sont gérées par l'intermédiaire d'un proxy, ce dernier
connait les objets utilisés pour gérer la machine mandatée, et gère la politique d'accès
adéquat
4.5 Les requêtes SNMP

4.5.1 Les formats de requêtes
Commande Action
get-request Le Manager SNMP demande une information à un agent
get-next-request Le Manager SNMP demande l'information suivante à un agent
set-request Le Manager SNMP met à jour une information sur un agent SNMP
get-reponse L'agent SNMP répond à un get-request ou à un set-request
trap L'agent SNMP envoie une alerte au Manager
Les commandes get-request, set-request et get-next-request sont toutes émises par le Manager à
destination d'un agent, elles attendent une réponse de type get-response de la part de l'agent.
La commande trap quand à elle est une alerte, c'est-à-dire qu'elle sera toujours émise par l'agent
vers le Manager, cependant elle n'attend aucune réponse.
4.5.2 SnmpWalk
An de tester les requêtes SNMP, le plus simple est de commencer par les requêtes à eectuer
en ligne de commande plutôt que de se lancer dans l'exécution de plugins etc... Deux commandes
standard existent : SnmpWalk et SnmpGet. Commençons par SnmpWalk. Cette commande per-
met de récupérer toutes les valeurs d'un OID de type n÷ud, rappelons que la structure est une
arborescence donc, si l'OID interrogé n'est pas une feuille, nous allons récupérer toutes les valeurs
du sous-arbre (d'où le terme "walk" qui signie parcourt). SnmpWalk obtient ces informations
car la commande est dénie comme étant une suite de séquences au format "get-next-request"
Pour utiliser cette commande, voici les paramètres à respecter :
Listing 4.1 Format de commande SnmpWalk

1 snmpwalk −v < l a v e r s i o n > −c < lacommunaute > < a d r e s s e i p > < o i d >
37
4.5. LES REQUÊTES SNMP
Figure 4.4 Exemple de requête SnmpWalk
4.5.3 SnmpGet
SnmpGet quand à lui permet de récupérer la valeur d'un OID feuille spécique, donc nous
obtiendrons une seule et unique valeur. La syntaxe de la commande est identique à celle de
SnmpWalk. Si le SnmpWalk nous permet de trouver les sous-arbres disponibles, la contrainte
évidente avec SnmpGet est qu'il faut impérativement savoir quel OID interroger. Pour cette
raison, nous utiliserons uniquement la commande SnmpWalk dans la suite de ce projet.
Listing 4.2 Exemple d'exécution de la commande SnmpGet

1 s n m p g e t −v 2 c −c d e m o p u b l i c t e s t . n e t −snmp . o r g SNMPv2−MIB : : sysUpTime . 0
2 SNMPv2−MIB : : sysUpTime . 0 = T i m e t i c k s : ( 5 8 6 7 3 1 9 7 7 ) 67 days , 2 1 : 4 8 : 3 9 . 7 7
38
Chapitre 5
Réalisation
5.1 Les outils utilisés

La phase de réalisation et de mise en ÷uvre a nécessité l'installation de plusieurs outils dont
voici un aperçu :
1. VMware Workstation 10 est ce que l'on appelle un hyperviseur, c'est-à-dire une

plate-forme de virtualisation qui permet de faire cohabiter diérents systèmes d'exploitation
sur une même machine physique. Il intègre une gestion complète des périphériques ainsi que du
son, de la vidéo, la prise en charge réseau...Je me suis servi de cet hyperviseur pour créer ma
machine virtuelle avec comme base l'iso CES 3.0, la procédure est détaillée en annexe technique
à la n de ce rapport. Pourquoi ne pas utiliser le serveur déjà en production ? Pour des raisons
évidentes de sécurité, l'utilisation du serveur existant était à proscrire. De même une
duplication aurait pu être eectuée pour les premiers tests, mais CES a bénécié d'une mise à
jour au cours de cette année. J'ai donc entrepris l'installation de la dernière version en date
tout en m'assurant qu'il serait possible de migrer mon serveur et de le placer en production
sans qu'il n'altère celui déjà en place.
2. Notepad ++ est l'un des éditeurs de code source les plus connus, sa coloration
syntaxique et sa simplicité en font un outil de choix à garder constamment sous la main.
3. PuTTY est un émulateur de terminal UNIX qui permet de se connecter à distance à

une machine ou un serveur, en utilisant les protocoles SSH, Telnet ou Rlogin. L'ensemble des
sessions peuvent être automatiquement enregistrées sous forme de rapport an d'être consultées
ultérieurement.
39
5.2. DE LA SUPERVISION DES IMPRIMANTES...
4. WinSCP, visuellement il se présente comme un outil de transfert FTP, il

permet de lire le contenu des répertoires, d'éditer ou de supprimer des chiers, et surtout
d'assurer des copies ou des déplacements de chiers entre la machine hôte, et le poste sur lequel
nous sommes connectés, tout cela en se basant sur le protocole SSH.
5. Nmap est un scanneur de port réseau, disponible sous Unix et Windows. Ce

logiciel a pour but de détecter les ports réseau ouverts sur une machine, ainsi il permet de
détecter si la machine en question est bien présente sur le réseau, et également d'identier les
services qui tournent dessus.
6. phpMyAdmin est une interface pour gérer les base de données MySQL, il faut
avouer qu'explorer une ou plusieurs base de données dans un terminal n'est pas chose facile.
Cette interface permet de naviguer entre les bases, les tables et même d'eectuer des requêtes
au format SQL.
5.2 De la supervision des imprimantes...

5.2.1 Notion d'hôte/de groupe d'hôtes
Un hôte est un bien matériel que l'on souhaite superviser, dans notre cas une imprimante
ou une multifonction en réseau. Auparavant il fallait impérativement congurer les hôtes par le
biais de chier de conguration en ligne de commande, ces opérations assez fastidieuses ont été
simpliées grâce à Centreon qui à l'aide de champ pré-remplis nous génère le chier de congura-
tion automatiquement. Il sura alors de redémarrer Nagios (par le biais de Centreon également)
an que le nouvel ajout soit pris en compte par le serveur.
Chaque dénition d'hôte se base sur un template (un modèle pré-créé), il est intéressant de
modier un template an de répliquer ses spécications (intervalle de check, notications...) aux
hôtes que l'on dénira plus tard s'appuyant sur celui-ci.
Un groupe d'hôte à présent, considérons nos imprimantes, il est pertinent de dénir un groupe
d'hôte selon chaque marque d'imprimante étant donné que celles-ci partagent des caractéristiques
communes et donc se verront attribuer des services communs (cette notion sera dénie dans la
section suivante). Tout simplement, prenons un peu de recul, il sera plus simple de dénir un
service à un groupe d'hôtes, plutôt que de dénir le même service à chaque hôte. Entre en jeu la
notion de parent et d'enfant.
5.2.2 Dénition de commande

Une commande sous Nagios, est similaire à une commande UNIX que l'on taperait en ligne
de commande an de récupérer des informations. La plupart des commandes s'appuient sur des
scripts déjà en place ou à télécharger.
5.2.3 Dénition de service

Un service est l'application d'une commande, il faut la congurer avec les arguments à prendre
en compte, les intervalles de check et les éventuelles notications à envoyer, si notications il doit
40
5.2. DE LA SUPERVISION DES IMPRIMANTES...
y avoir. Il sut ensuite d'appliquer une relation entre le service et un groupe d'hôte, an que
tous les hôtes concernés soient check en temps voulu.
5.2.4 Installation de plugins pour Nagios

Comme le dit l'adage, il ne faut pas réinventer la roue, de nombreux plugins existent déjà, un
site communautaire les recense d'ailleurs : http://exchange.nagios.org/directory/Plugins
La majorité des plugins sont écris en Php ou en Perl, des dépendances sont à installer si
Nagios ne reconnait pas ces plugins. L'installation est très simple il sut de placer le plugin dans
le bon répertoire : "usr/lib/nagios/plugins/", de restart Nagios, puis de dénir une nouvelle
commande basée sur le nom du plugin.
5.2.5 Architecture de CES
Figure 5.1 Architecture globale de CES
Ce schéma illustre parfaitement le mode de fonctionnement, ainsi que les interactions entre
les diérents composants de la solution.
Centreon notre interface web permet non seulement d'acher les diérents statuts du matériel
supervisé, mais surtout de congurer et d'administrer Nagios sans avoir à passer par un terminal.
Quelques clics susent à charger une conguration, à rajouter des hôtes, créer des services et
des commandes, et également redémarrer le service Nagios.
41
5.3. ... AU DIAGNOSTIC
Nagios notre serveur central, ici conguré en mode architecture simple RRDtool quand à lui ne
nous intéresse pas vraiment, sa principale fonctionnalité est d'établir des graphes sur les données
de performances (utiles pour des serveurs supervisés par exemple).
5.2.6 Le combo Nagios et ndOutils
Figure 5.2 Nagios et ndOutils
Ndomod et Ndo2db sont deux éléments plus qu'essentiels à la suite CES, leurs rôles principal
est la communication entre l'interface web (Centreon) et notre ordonnanceur (ici Nagios). Ils
sont regroupés au sein de NdOutils.
Ndo2db est un daemon 1 qui permet de récupérer les données remontées par par Ndomod et de
les stocker dans une base de données (notre base MariaDb).
Ndomod est un module qui permet de remonter les informations d'un ou plusieurs ordonnan-
ceur(s) (selon si le modèle choisit est l'architecture simple ou l'architecture distribuée, avec
plusieurs pollers).
Attention seules les données de supervision et l'état de l'ordonnanceur seront remontées, les don-
nées de performances et les logs, seront quand à eux récupérés via CentCore, et ramener à la
base de données via CentStorage (qui ne sont pas représentés sur le graphe précédent).
5.3 ... Au diagnostic

5.3.1 La remontée d'informations dans la base de données
Figure 5.3 Base de données Centreon

1. Processus qui s'exécute en arrière-plan
42
5.3. ... AU DIAGNOSTIC
Suite à l'installation de CES, et lors de la conguration de la base de données (voir Annexe

technique) je remarque que celle-ci se décompose en deux sous-bases : Centreon_ status, et Cen-
treon_ storage. Il est conseillé de ne pas renommer ces bases et de laisser les paramètres par
défaut même si les liens symboliques sont correctement établis lors de la conguration. D'ailleurs
en cas de nouvelle installation ou de migration du superviseur il sura de migrer ces deux bases
de données.
La base Centreon_ storage contient les données de performances si le besoin est, d'établir
des graphes de performances par exemple.
Figure 5.4 Centreon status
La base Centreon_ status est celle qui m'intéresse, elle regroupe les dénitions d'hôtes, de
commandes, de services, et surtout les informations de supervisions stockées. 60 tables composent
cette base de données, il m'a fallu un peu de temps pour trouver où étaient stockées précisément
les données recherchées vis-à-vis des plugins utilisés. Il s'avère que les données intéressantes se
trouvent dans trois tables séparées : nagios_ services, nagios_ hosts et nagios_ servicestatus.
Le but était de remonter ces informations en entrant l'adresse IP d'une imprimante, la join-
ture m'a semblé la plus adaptée. Pour rappel la commande " INNER JOIN" est un type de
jointure commune pour lier des tables entre elles, elle permet de retourner les enregistrements
lorsqu'il y a au moins une ligne de chaque colonne qui correspond à la condition donnée en entrée.
Concrètement dans notre cas si une adresse IP est donnée (10.1.2.14 par exemple)
Listing 5.1 Requête de récupération des données brutes

1
2 s e l e c t output
3 from n a g i o s _ s e r v i c e s t a t u s
4 INNER JOIN n a g i o s _ s e r v i c e s
5 ON ( n a g i o s _ s e r v i c e s t a t u s . s e r v i c e _ o b j e c t _ i d = n a g i o s _ s e r v i c e s . s e r v i c e _ o b j e c t _ i d )
43
5.4. EN PASSANT PAR LA DÉCOUVERTE RÉSEAU
6 INNER JOIN n a g i o s _ h o s t s
7 ON ( n a g i o s _ s e r v i c e s . h o s t _ o b j e c t _ i d = n a g i o s _ h o s t s . h o s t _ o b j e c t _ i d )
8 where a d d r e s s = ’ 1 0 . 1 . 2 . 1 4 ’
Figure 5.5 Données brutes en sortie
Ces données brutes peuvent à présent être exploitées par mon collègue, une mise en forme sera
à eectuer avant de retranscrire les données au sein de l'interface web.
5.4 En passant par la découverte réseau

Appelé Discover SNMP, le principe est simple, à partir d'une plage d'adresses ip (les sous
réseaux du Conseil Général) le script va lancer un balayage réseau an de déterminer toutes les
imprimantes/multifonctions qui s'y trouvent.
Je ne suis pas l'auteur de ce script, je tiens à remercier Pierre-Louis Corrion qui l'a rédigé, qui
a été un des précurseurs de l'utilisation du protocole SNMP au sein de la DEMS.
En eet ce script couple l'outil NMAP aux OID de descriptions des diérentes marques d'impri-
mantes et se décompose donc en deux étapes :
1. Scanner les ports avec Nmap an de détecter la présence d'un matériel
2. Si le matériel détecter est une imprimante, interroger l'oid de description an de récupérer
son nom
An d'assurer une certaine cohérence et dans un souci de compréhension, un chier texte
appelé sites.txt (qui regroupe l'ensemble des noms donnés aux sites du Conseil Général, et les ip
correspondantes à ces sites) est requit par le script shell.
Nous avons entrepris d'utiliser ce script comme base d'outil pour eectuer le discover SNMP,
un travail préliminaire a dû être eectué, en associant chaque site (adresse IP) à une variable.
Parallèlement l'interface web devra présenter les diérents sites comme une sorte de ltre par
régions.
Voici un exemple de chier de sortie pou r un discover SNMP eectué à la DEMS :
Listing 5.2 Discover SNMP
1
2 10.1.0.0 DI Lan1 ; 1 0 . 1 . 2 . 1 0 ; p r 1 5 6 2 1 0 . i n t r a n e t . cg974 . f r ; HP L a s e r J e t 400 c o l o r M451dw ;
3 10.1.0.0 DI Lan1 ; 1 0 . 1 . 2 . 1 4 ; n p i 1 6 4 2 6 8 . i n t r a n e t . cg974 . f r ; HP L a s e r J e t 400 MFP M425dn ;
4 10.1.0.0 DI Lan1 ; 1 0 . 1 . 2 . 1 5 ; e t 0 0 0 4 0 0 d 1 5 5 7 7 . i n t r a n e t . cg974 . f r ; Lexmark T640 7919 C76 LS
5 10.1.0.0 DI Lan1 ; 1 0 . 1 . 2 . 5 2 ; mfp07678474 . i n t r a n e t . cg974 . f r ; TOSHIBA e−STUDIO356 ;
6 10.1.0.0 DI Lan1 ; 1 0 . 1 . 2 . 7 0 ; km8165d5 . i n t r a n e t . cg974 . f r ;KM−2560;
L'intérêt d'une telle requête est tout simplement de rechercher les imprimantes actives sur un
des sous-réseaux du Conseil Général, placé en paramètre, et également de s'apercevoir si celles-ci
sont correctement nommées ou non. A plus grande échelle on pourrait établir un mapping de ces
imprimantes.
44
5.5. DU SERVEUR DE DÉVELOPPEMENT AU SERVEUR DE PRODUCTION
5.5 Du serveur de développement au serveur de Production

On appelle serveur de production, le serveur sur lequel sera installé l'application une fois
terminée, donc accessible aux utilisateurs naux. Par opposition, le serveur de développement,
celui sur lequel j'ai eectué mes diérents tests, qui n'était ni plus ni moins que mon poste de
travail personnel. Il faut procéder à la migration de la machine sur Vcenter. Voyons quelques
petites notions avant de procéder :
vSphere est un hyperviseur "bare-metal" c'est-à-dire directement installé sur le serveur physique
qu'il partitionnera en plusieurs machines virtuelles. Sur chaque LAME 2 est installé vSphere. 5
LAME sont présents dans la salle serveur donc 5 vSphere.
VMware vCenter Server est un logiciel de gestion de serveurs et de virtualisation qui ore
une plate-forme centralisée. vCenter regroupe donc la totalité des vSphere au sein d'une même
interface de contrôle et d'administration. Le plus gros avantage est la répartition des charges entre
les vSphere, si un serveur consomme trop de CPU il sera automatiquement basculé sur un autre
vSphere, tout ceci est bien évidemment transparent aux utilisateurs, pour qui les applications
continuent de fonctionner. C'est l'un des principes de la prévention de pannes.
Figure 5.6 Centralisation des serveurs virtuels
La première étape de la migration est la modication de la compatibilité matérielle, rappelons

que le serveur CES était stocké en local sur ma machine personnelle , il fallait donc la migrer
2. serveur physique
45
5.6. LES DIFFICULTÉS RENCONTRÉES
vers le DataCenter 3 . Le fait d'avoir créé et paramétré cette machine sous Workstation 10 est un
avantage, en eet la migration (upload) est simpliée depuis cette version.
Ne pas oublier de créer un clone de la machine qui possèdera les modications matérielles de
compatibilité, ne surtout pas altérer sa machine existante.
Il faut se rendre ensuite dans la partie upload, et indiquer les informations du serveur sur lequel je
souhaite migrer la machine, une fois que cela est indiqué je peux sélectionner l'emplacement d'hé-
bergement sur le Vcenter, et plus particulièrement un ESX-LUN. L'upload se lance, la migration
s'eectue assez rapidement.
5.6 Les dicultés rencontrées

5.6.1 Protection du réseau
La progression des attaques est en croissance exponentielle sur Internet, peu importe l'échelle
de son entreprise, la protection du réseau est plus que jamais à l'ordre du jour.
Il va de soi qu'avec les services oerts par la DEMS (le serveur de gestion des bourses par
exemple), il faut éviter toutes intrusions ou menaces potentielles , que celles-ci viennent de l'ex-
térieur (DDOS..) ou de l'intérieur (prenons le cas d'une clé usb infectée qui en étant branchée
à un poste de travail, lancerait une contamination et une propagation de malwares sur le réseau).
Des politiques de sécurité ont du être appliquées que cela soit par choix personnel ou par néces-
sité. Ces règles sont dénies par les administrateurs du SAR et une fois mises en place à appliquer
la tolérance zéro. En eet malgré nos types de comptes sur l'AD (malgré l'OU dans lequel nous
nous trouvons, qui nous attribue un certain nombres de droits sur nos postes par rapport aux
utilisateurs "lambda"), nous devons faire face aux mêmes contraintes que les autres agents du
CG dès lors que l'on touche au réseau.
Je ne peux pas considérer que ces contraintes soient de la sur-protection réseau, elles sont justes.
Vincent Beauval m'a rapporté qu'en eet, il y avait des journées où des centaines d'intrusions
étaient lancées contre le réseau du Conseil Général, j'ai alors pris conscience réellement de la
nécessité d'appliquer ces termes de sécurité.
J'avais commencé à installer mon serveur de supervision sur la même machine virtuelle que Kévin
TAOCHY, en voulant lancer mes premières requêtes, je me suis aperçu que rien ne passait, à
part les requêtes vers Localhost. Rapidement j'ai compris qu'il s'agissait alors d'un problème de
ports UDP qui n'étaient pas ouverts, et comme ce serveur se trouvait sur un réseau isolé, j'ai dû
entreprendre alors l'installation sur ma machine personnelle et d'envisager une migration future
sur un serveur de production (ce qui a été validé et eectué).
Une fois que ma machine a été placée sur le serveur de production, je me suis retrouvé avec
un souci assez particulier, même si la conguration réseau avait été placée sur DHCP, je n'avais
aucune adresse IP, la solution a été de dénir une seconde interface réseau, de la placer en DHCP,
et de forcer le lancement de la conguration au démarrage, il aurait été dommage de perdre la
conguration réseau à chaque reboot serveur (merci à Florent PAYET pour son aide).
De ce fait nous avons dû interagir assez régulièrement avec les membres de SAR dès lors qu'un
problème lié au réseau était soupçonné.
3. Centre de traitement des données où sont regroupés les équipements
46
5.6.2 Respect des conventions de nommage

Si les conventions de nommage ont été établies assez récemment, elles ne sont malheureuse-
ment pas respectées.
La première étant le renommage des imprimantes sur le réseau, seule une soixantaine d'impri-
mantes a été nommée correctement, je me suis concerté avec François BOYER, pour nalement
décider qu'on ne superviserait dans un premier temps que les imprimantes correctement nom-
mées.
De même une communauté SNMP a été dénie par SAR, malheureusement la majorité reste
encore actuellement sur la valeur par défaut à savoir "public", j'ai dû grâce à l'outil Top-Access,
me connecter en session administrateur sur ces périphériques an de changer la communauté par
celle qui était nécessaire pour mes requêtes.
5.6.3 Livrables
Nous avons nommé notre projet DiagMoustik, un petit jeu de mots entre le mot diagnostic
et le petit insecte des tropiques tant détesté.
Les livrables représentent le résultat nal de notre prestation, c'est-à-dire tout ce que nous avons
produit pendant ces 6 mois de stages et qui sera remis entièrement à la DEMS.
5.6.3. A Architecture générale de l'outil
Regroupons à présent le travail de mon collègue et ce que j'ai produis. Les deux schémas
suivants très explicites ont été réalisé par Kévin TAOCHY, ils illustrent parfaitement la jonction
entre ses travaux et les miens.
Figure 5.7 Architecture de l'application DiagMoustik
47
Figure 5.8 Illustration du principe de fonctionnement
5.6.3. B Machines virtuelles
Déjà placé sur un serveur en production, la machine virtuelle où est installé le serveur central
CES possède à présent une adresse IP xe, et eectue ses requêtes régulièrement. Le serveur
physique sur lequel elle est placée a largement les ressources nécessaires ainsi que l'espace de
stockage. Cette machine a été fournie avec ses plugins, les paramètres, les hôtes, les diérentes
commandes et services.
La seconde machine virtuelle (celle de mon collègue) été déjà placée sur un sous-réseau (qui
était isolé certes), mais les ports sont à présent ouverts, et les communications avec ma machine
virtuelle ne posent plus aucun problème.
5.6.3. C Documentations
An de pérenniser l'outil il faut que d'autres que Kévin TAOCHY et moi-même soient ca-
pable de l'utiliser lorsque nous serons partis, dans cette optique plusieurs documentations sont
en cours de rédactions. Également des commentaires ont été écris dans les diérents scripts, an
que ceux-ci puissent être modiés au besoin.
Documentation technique, qui reprend l'ensemble des schémas d'architecture ainsi que les
technologies utilisées
Manuel d'utilisation, qui dénit les diérentes vues côté utilisateur (les techniciens) an
que ceux-soient soient parfaitement au courant des fonctionnalités présentes, quels boutons
utiliser pour arriver à tel ou tel résultat...
Procédure d'installation qui détaille pas à pas comment arriver à avoir un serveur stable,
fonctionnel et donc prêt à être déployé
48
Chapitre 6
Conclusion
6.1 Bilan
Ce stage à la DEMS a commencé le 6 janvier 2014 et se terminera le 7 juillet de la même
année (en eet ce rapport sera rendu deux semaines avant la n de mon stage), j'ai été placé
sous la tutelle de François Boyer au sein du Service Support Utilisateurs.
Ce stage de n d'études a été ma première véritable expérience en entreprise, en eet jusqu'à
présent notre cursus universitaire nous avait oert de nombreuses notions dans divers domaines,
que j'ai enn pu mettre en pratique sur le terrain.
Les premiers jours furent assez complexes, le temps de trouver mes marques sans doute, il a fallu
réaménager le bureau de l'assistant de manager de notre chef de service : Laurent Prunella an
de nous attribuer un bureau xe à Kévin TAOCHY et moi-même. Malgré cela, mon intégration
fut très rapide, notamment grâce à Anise FONTAINE et à Marie-Paule CRESCENCE qui se
sont comportées comme de véritables mères pour nous à la DEMS. En l'espace d'une semaine
nous avons visité l'ensemble des services, été présentés aux agents de la DEMS qui étaient pré-
sents (une bonne majorité était encore en congé lors de ce début de mois de janvier), et visités
également le Data-Center du Conseil Général.
Une fois intégré, j'ai fait face au quotidien rythmé du SSU, des journées dynamiques avec pleins
d'imprévus, gérées parfaitement par les agents du service, habitués à ce genre de situations.
Nous avons été placés à deux sur ce projet, Kévin TAOCHY et moi-même, j'avais pour ma
part lors de mon entretien mis l'accent sur mes capacités et ma volonté à mettre en pratique
mes notions sur l'administration des systèmes et des réseaux, j'ai donc été ravi lorsque l'on m'a
annoncé que cela serait la partie dont je serais en charge.
J'étais loin de me douter de l'ampleur et surtout de l'échelle de l'architecture que je devais res-
pecter. Pour rappel le Conseil Général est réparti sur environ 150 sites avec près de 5000 agents.
J'avais déjà créé des machines virtuelles (linux pour me parfaire dans les systèmes UNIX) et
Mac-OsX Lion (an de développer des applications pour Ios via Xcode), le projet de mise en
place d'un serveur CES ma permis d'utiliser une autre version de Linux (Centos), diérente de
celle que j'avais l'habitude d'utiliser (Debian).
J'ai appris qu'au sein d'une entreprise on ne peut se permettre de tester une solution dont on
ne connait pas les résultats ni l'ecacité, il faut se baser sur l'existant, et à ce niveau, forts de
leur expérience passée, Vincent BEAUVAL et Florent PAYET ont su me guider. J'ai pu constaté
également que les diérents agents de la DEMS doivent constamment rester à la pointe des tech-
nologies qu'ils étudient ou utilisent, forcés dans un monde où l'informatique est en plein essor
d'assurer la qualité de service dont dépend la collectivité.
49
6.2. APPORT PERSONNEL
Plus qu'un outil, l'informatique fait désormais partie intégrante du quotidien des agents, la
DEMS tend à favoriser son utilisation, an que tous voient le côté ludique et pratique et non une
contrainte.
Concernant le projet en lui-même il a été intéressant de constater que l'intérêt ne venait pas uni-
quement des techniciens du SSU, mais de toutes les personnes qui nous ont posés des questions
sur l'évolution de ce projet, et qui ont su trouver un côté positif à cette mise en place, je pense
notamment à Chris RAMASSAMY du SRM.
Je n'ai pas à me plaindre des conditions de travail, bien au contraire, en réalité je ne m'attendais
pas à trouver des agents aussi joviaux qui prennent plaisir à travailler et à instaurer une am-
biance aussi conviviale, merci à Jean-Pierre JOB et à François BOYER pour leur bonne humeur,
la DEMS est un peu comme une grande famille dont les membres se côtoient et interagissent
chaque jour, et savent qu'ils peuvent compter les uns sur les autres.
Les échanges et partages de connaissances ont favorisé l'entente avec les autres services, une
petite pensée à Jimmy OMERALY, Bertrand CHANE et Maurice REVEL avec qui chaque jour,
un petit débat était lancé concernant les technologies actuelles.
Pour conclure cette partie, je dirais que ce stage a été non seulement une expérience profession-
nelle, mais également une expérience humanisante.
6.2 Apport personnel

Anticiper les besoins, voilà les maitres-mots que je retiendrais de ce stage. Au fur et à mesure
du cheminement et de l'avancée de ce projet, j'ai commencé à raisonner autrement, étant placé
chef de projet en binôme avec mon collègue, cela a permis de développer notre esprit d'équipe.
Avoir une vision d'ensemble et une prise de recul susante pour aborder une situation concrète,
sont à présent ce que j'estime être non pas des qualités, mais des compétences élémentaires pour
un ingénieur.
Il a été plus qu'enrichissant pour moi de toucher à des technologies et solutions propriétaires,
moi qui étais convaincu que l'open-source remplacerait la plupart des solutions payantes à l'heure
actuelle, je me suis rendu compte que ces logiciels sur mesure facilitaient le travail des adminis-
trateurs, surtout en matière de maintenance, en eet une fois mis en place, les débogages sont
très rares, et on peut ainsi se consacrer à la valeur ajoutée et à la qualité de services à apporter.
Ce stage m'a permis de me concilier avec l'idée de devenir administrateur systèmes et réseaux,
la mise en place de serveurs, la gestion de parc informatique, l'établissement de diagnostics, la
mise en oeuvre de sécurité... tant de notions qui permettent de valoriser ce métier à part entière.
Je pense d'ailleurs qu'il serait judicieux que je passe des certications telles que Microsoft, Linux
et Cisco, an d'établir un véritable preuve sur mon niveau et mes aptitudes en plus de mon
bagage technique qui s'est peauné durant mes six mois de stage.
6.3 Perspectives futures

Je pense qu'il faudra compter deux bons mois de test, avec le serveur de supervision et l'ap-
plication en production, an de s'apercevoir des réels bienfaits de leur mise en place.
Je regrette que nous nous soyons fait rattraper ainsi par le temps, les périodes estimées dans le
planning prévisionnelle étaient plus ou moins correctes, mais les projets secondaires ont été très
50
6.3. PERSPECTIVES FUTURES
chronophages.
Malheureusement la version web mobile n'a pas pu être abordée, il n'était pas convenu à la base
de développer à la fois une version pour Ios et une version sous Android, mais bien une version
web mobile, basée sur un framework tel que " Jquery mobile" que j'ai déjà eu l'occasion d'utiliser
lors de mon parcours universitaire. Le fait d'utiliser la technologie "responsive design" aurait été
un véritable atout, pour qu'à la fois l'application fonctionne sous postes de travail, smartphones,
voire également les tablettes.
Si les mérites de ce projet sont correctement remontés, il faudra développer cette version.
Autre chose, en prenant un peu de recul vis-à-vis du parc des imprimantes, je me suis rendu
compte que sur le long terme même en mutualisant au maximum les imprimantes pour les rem-
placer par des multifonctions, il arrivera un moment où le nombre de sites physiques augmentera
considérablement, et il sera alors intéressant d'installer un second serveur poller Nagios, an de
répartir correctement les charges et d'instaurer ainsi une architecture distribuée.
Également si un réel engouement se présente pour le projet, pourquoi ne pas mettre en place
le système de Trap SNMP, an que des alertes soient remontées en cas d'états anormaux ou de
défaillances sur les biens matériels, évidemment il faut se projeter dans l'avenir, cette solution
serait pertinente uniquement si le parc des imprimantes augmenterait de manière signicative,
ne pas oublier la contrainte humaine, si des alertes sont envoyées il faut bien que quelqu'un les
reçoive, serait-il alors judicieux d'associer un agent du SAR, ou plutôt la totalité des techniciens
du SSU ?
51
Table des gures
1.1 Organigramme du Conseil Général de la Réunion . . . . . . . . . . . . . . . . . . 10

1.2 Organigramme DEMS fonctionnel et nominatif . . . . . . . . . . . . . . . . . . . 11
2.1 C÷ur de réseau du Conseil Général . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 C÷ur de LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Exemple de che de signalement d'incident . . . . . . . . . . . . . . . . . . . . . 19
2.4 Hétérogénéité du parc d'imprimantes . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5 Gestion de Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6 Graphe systémique de Patrick IRSAPOULLE . . . . . . . . . . . . . . . . . . . . 21
2.7 Planning prévisionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8 Modèle en Cascade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.9 Validation mensuelle de la progression du projet . . . . . . . . . . . . . . . . . . . 22
3.1 Méthode du Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2 Méthode du heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Ibm Tivoli Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 HP Openview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 Computer Associates Technologies Unicenter . . . . . . . . . . . . . . . . . . . . 27
3.6 HP Openview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.7 Métrologie ou Supervision ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1 Schéma SNMP de communication de base . . . . . . . . . . . . . . . . . . . . . . 33

4.2 Les échanges entre le Manager et l'Agent . . . . . . . . . . . . . . . . . . . . . . . 34
4.3 Structure de l'arborescence d'une MIB . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4 Exemple de requête SnmpWalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1 Architecture globale de CES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.2 Nagios et ndOutils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3 Base de données Centreon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.4 Centreon status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.5 Données brutes en sortie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.6 Centralisation des serveurs virtuels . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.7 Architecture de l'application DiagMoustik . . . . . . . . . . . . . . . . . . . . . . 47
5.8 Illustration du principe de fonctionnement . . . . . . . . . . . . . . . . . . . . . . 48
A.1 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
B.1 Créer une nouvelle machine, sélectionner "avancée" . . . . . . . . . . . . . . . . . 57

B.2 Laisser la compatibilité matériel par défaut . . . . . . . . . . . . . . . . . . . . . 57
B.3 Sélectionner " I will install the operating system later" . . . . . . . . . . . . . . 58
B.4 Congurer le nombre de processeurs : 1 processeur double coeur est susant . . . 58
B.5 Congurer la mémoire vive : 512 Mo sont amplement susant . . . . . . . . . . . 58
B.6 Sélectionner le mode Bridge, an d'avoir une véritable adresse ip à xer . . . . . 59
52
TABLE DES FIGURES
B.7 Créer un nouveau disque virtuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

B.8 20 Go sont recommandés pour un CentOs . . . . . . . . . . . . . . . . . . . . . . 59
B.9 Finaliser l'installation, ne pas démarrer la machine . . . . . . . . . . . . . . . . . 60
B.10 Éditer les paramètres de la machine et dans la partie CD/DVD, sélectionner l'iso
de CES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
B.11 Lancer une nouvelle installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
B.12 Première interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
B.13 Sélectionner la langue et le clavier du système . . . . . . . . . . . . . . . . . . . . 62
B.14 Sélectionner périphériques de stockage basiques . . . . . . . . . . . . . . . . . . . 62
B.15 Abandonner les données, an de procéder au partitionnement automatique . . . . 62
B.16 Sélectionner le fuseau horaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
B.17 Remplacer le système actuel (même si aucun n'est présent) . . . . . . . . . . . . 63
B.18 Installer un serveur central avec base de données . . . . . . . . . . . . . . . . . . 63
B.19 Choisir le duo Nagios/ndOutils . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
B.20 L'installation des dépendances commence . . . . . . . . . . . . . . . . . . . . . . 64
B.21 L'installation est enn terminée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
B.22 Redémarrer la machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
B.23 CES est bien basé sur CentOs 6.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
B.24 Une fois connecté à la session, repérer l'adresse ip . . . . . . . . . . . . . . . . . . 65
B.25 Le paramétrage se poursuit dans un navigateur web (taper l'adresse ip dans la
barre d'url) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
B.26 Les diérents modules se chargent . . . . . . . . . . . . . . . . . . . . . . . . . . 66
B.27 Sélectionner Nagios comme serveur central . . . . . . . . . . . . . . . . . . . . . . 66
B.28 Laisser les répertories par défaut . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
B.29 Vérier que ndOutils est le Broker sélectionné . . . . . . . . . . . . . . . . . . . . 67
B.30 Dénir ses paramètres d'administration . . . . . . . . . . . . . . . . . . . . . . . 67
B.31 Dénir les informations de la base de données . . . . . . . . . . . . . . . . . . . . 67
B.32 Vérication des paramètres entrés . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
B.33 On peut à présent se connecter à Centreon . . . . . . . . . . . . . . . . . . . . . . 67
B.34 Modication d'un hôte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
B.35 Les diérents groupes d'hôtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
B.36 Exemple de commande s'appuyant sur un plugin . . . . . . . . . . . . . . . . . . 68
B.37 Modication d'un service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
B.38 Relation entre un service et un groupe d'hôtes . . . . . . . . . . . . . . . . . . . . 69
B.39 Modication de la compatibilité hardware . . . . . . . . . . . . . . . . . . . . . . 69
B.40 Clone de la machine avec modications . . . . . . . . . . . . . . . . . . . . . . . . 70
B.41 Sélection d'un emplacement sur le DataCenter . . . . . . . . . . . . . . . . . . . . 70
B.42 Sélection d'un ESX-LUN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
B.43 Interface générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
B.44 Diagnostic imprimante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
B.45 Diagnostic poste de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
B.46 Lancement d'une commande de controle à distance . . . . . . . . . . . . . . . . . 72
B.47 Discover SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
B.48 Résultat d'un discover à la DEMS . . . . . . . . . . . . . . . . . . . . . . . . . . 73
53
Annexe A
Webographie
Developpez.com http://caleca.developpez.com/tutoriels/protocole-snmp/
WIKI MONITORING-FR.ORG http://wiki.monitoring-fr.org/zabbix/zabbix-snmp-host
SUGAR.BUG http://eric.coquard.free.fr/atelier/supervision/reseau/supervision_
snmp.html
LoriotPro http://www.loriotpro.com/ServiceAndSupport/How_to/InstallWXPAgent_FR.
php
OCS inventory-ng http://forums.ocsinventory-ng.org
php http://www.php.net/manual/en/function.snmp2-walk.php
Decrypt http://decrypt.ysance.com/
slideshare http://fr.slideshare.net/labynocle/
infoscience http://infoscience.epfl.ch/record/49953/files/Rei02.pdf
debian https://www.debian.org/releases/wheezy/
MEMO-LINUX.COM http://memo-linux.com/
Centreon http://www.centreon.com/Content-products/centreon-entreprise-server
nicolargo http://blog.nicolargo.com/2009/02/utilisation-de-centreon.html
Journal d'un Admin Linux http://journaldunadminlinux.fr/installer-et-configurer-centreon
WEBLOG de CEDRIC TEMPLE http://blog.cedrictemple.net/
ZIONETRIX http://wiki.zionetrix.net/informatique:systeme:monitoring:nagios
linuxpedia.fr http://www.linuxpedia.fr/doku.php/serveurs/nagios_centreon
Nagios Exchange http://exchange.nagios.org/directory/Addons/Database-Backends/NDOUtils/

details
54
PC SOFT http://doc.pcsoft.fr/fr-FR/?2034007
smnet.fr http://www.smnet.fr/ocsglpi/ocs-snmp.html
easeo http://blog.easeo.fr/aides-howto/
HARDWARE.FR http://forum.hardware.fr/hfr/systemereseauxpro/Logiciels-entreprise/
nagios-imprimantes-reseau-sujet_1612_1.html
HACKERS ARE US http://blog.hackersare.us/2011/06/checkhpjdnew-nagios-plugin.

html
ouieuhtoutca.org http://wiki.ouieuhtoutca.org/doku.php?id=nagios-centreon-part1
MG Monitoring http://www.mark-gadi.fr/supervision/
LinuxQuestions.org http://www.linuxquestions.org/questions/linux-networking-3/snmp-snmpwa
doc.monitoring-fr http://doc.monitoring-fr.org/3_0/html/gettingstarted-monitoring-routers.
html
yyovkov http://mwiki.yyovkov.net/index.php/SNMPHelp:SNMP_Mibs_for_%28HP%29_Printers
L'Internet Rapide et Permanent http://irp.nain-t.net/doku.php/215snmp:40_les_mibs
Blog de Victor Héry http://blog.héry.com/article9/
Blog Olivier Delort http://blog.olivierdelort.net/?p=270
ubuntu-fr http://doc.ubuntu-fr.org/installer_un_serveur_debian
StackExchange http://security.stackexchange.com/questions/36198/
Linux-France http://www.linux-france.org/article/gvallee/snmp/snmp.html#ref7
FrameIp http://www.frameip.com/snmp/
mibDepot http://www.mibdepot.com
55
A.1. TABLEAU DE BORD
A.1 Tableau de Bord
Figure A.1 Diagramme de Gantt
56
Annexe B
Annexes techniques
B.1 Création d'une machine virtuelle
Figure B.1 Créer une nouvelle machine, sélectionner "avancée"
Figure B.2 Laisser la compatibilité matériel par défaut
57
B.1. CRÉATION D'UNE MACHINE VIRTUELLE
Figure B.3 Sélectionner " I will install the operating system later"
Figure B.4 Congurer le nombre de processeurs : 1 processeur double coeur est susant
Figure B.5 Congurer la mémoire vive : 512 Mo sont amplement susant
58
Figure B.6 Sélectionner le mode Bridge, an d'avoir une véritable adresse ip à xer
Figure B.7 Créer un nouveau disque virtuel
Figure B.8 20 Go sont recommandés pour un CentOs
59
Figure B.9 Finaliser l'installation, ne pas démarrer la machine
60
B.2. INSTALLATION DE CES
B.2 Installation de CES
Figure B.10 Éditer les paramètres de la machine et dans la partie CD/DVD, sélectionner l'iso
de CES
Figure B.11 Lancer une nouvelle installation
Figure B.12 Première interface
61
Figure B.13 Sélectionner la langue et le clavier du système
Figure B.14 Sélectionner périphériques de stockage basiques
Figure B.15 Abandonner les données, an de procéder au partitionnement automatique
62
Figure B.16 Sélectionner le fuseau horaire
Figure B.17 Remplacer le système actuel (même si aucun n'est présent)
Figure B.18 Installer un serveur central avec base de données
63
Figure B.19 Choisir le duo Nagios/ndOutils
Figure B.20 L'installation des dépendances commence
Figure B.21 L'installation est enn terminée
64
Figure B.22 Redémarrer la machine
Figure B.23 CES est bien basé sur CentOs 6.5
Figure B.24 Une fois connecté à la session, repérer l'adresse ip
65
B.3. SUITE DE L'INSTALLATION DE CES VIA NAVIGATEUR WEB
B.3 Suite de l'installation de CES via navigateur Web
Figure B.25 Le paramétrage se poursuit dans un navigateur web (taper l'adresse ip dans la
barre d'url)
Figure B.26 Les diérents modules se chargent
Figure B.27 Sélectionner Nagios comme serveur central
Figure B.28 Laisser les répertories par défaut
66
B.3. SUITE DE L'INSTALLATION DE CES VIA NAVIGATEUR WEB
Figure B.29 Vérier que ndOutils est le Broker sélectionné
Figure B.30 Dénir ses paramètres d'administration
Figure B.31 Dénir les informations de la base de données
Figure B.32 Vérication des paramètres entrés
Figure B.33 On peut à présent se connecter à Centreon
67
B.4. LES DIFFÉRENTS ÉLÉMENTS DE CENTREON
B.4 Les diérents éléments de Centreon
Figure B.34 Modication d'un hôte
Figure B.35 Les diérents groupes d'hôtes
Figure B.36 Exemple de commande s'appuyant sur un plugin
68
B.5. MIGRATION DE LA MACHINE VIRTUELLE
Figure B.37 Modication d'un service
Figure B.38 Relation entre un service et un groupe d'hôtes
B.5 Migration de la machine virtuelle
Figure B.39 Modication de la compatibilité hardware
69
B.6. V1 DE L'INTERFACE WEB DE NOTRE APPLICATION
Figure B.40 Clone de la machine avec modications
Figure B.41 Sélection d'un emplacement sur le DataCenter
Figure B.42 Sélection d'un ESX-LUN
B.6 V1 de l'interface Web de notre application
70
Figure B.43 Interface générale
Figure B.44 Diagnostic imprimante
71
Figure B.45 Diagnostic poste de travail
Figure B.46 Lancement d'une commande de controle à distance
72
Figure B.47 Discover SNMP
Figure B.48 Résultat d'un discover à la DEMS
73

M2 Stage Rapport Irsapoulle Patrick 2014

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

M2 Stage Rapport Irsapoulle Patrick 2014

Transféré par

Droits d'auteur :

Formats disponibles

Département de Mathématiques et Informatique

Université de la Le Conseil Général

Rapport de Stage de Master M2

Mise en place d'un outil de supervision

Patrick IRSAPOULLE 28000541

Entité Académique : Université de la Réunion

Nom de la Société : Le Conseil Général de la Réunion

Dates du stage : 6 Janvier au 7 Juillet 2014

Saint Denis, île de la Réunion, 20 juin 2014

Le principe de la supervision est de s'assurer du bon fonctionnement d'un système, sa mise en

[Mots-clés : Microsoft, Linux, requêtes, programmation, SNMP, imprimante, poste

[Keywords : Microsoft, Linux, queries, programming, SNMP, printer, desktop com-

J'exprime ma reconnaissance à mon responsable pédagogique, Fred MESNARD, pour sa dispo-

2 Analyse des besoins et spécications 14

4 Le protocole solution pour la supervision en réseau 32

B.5 Migration de la machine virtuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

1.1 Présentation de l'organisme d'accueil

1.1.1 Le Conseil Général de la Réunion

Ses principaux domaines de compétence :

Figure 1.1  Organigramme du Conseil Général de la Réunion

1.1.2 La Direction de l'E-administration et Modernisation des Services

En plus de sa Direction (composée du Directeur et de la cellule Animation/Formation), la DEMS

1.1.2. A Service Ressources et Méthodes

Figure 1.2  Organigramme DEMS fonctionnel et nominatif

Les principales missions :

 assurer le suivi des marchés de la direction

1.1.2. B Service Architecture et Réseaux

Le service Architecture Réseaux a pour vocation de construire l'infrastructure du Système

 concevoir,maintenir et moderniser l'architecture du SI

1.1.2. C Service APplications

Le Service Applications assure la mise en place de solutions ou d'outils informatiques mo-

1.1.2. D Service Support Utilisateur

1.2 Objectifs du stage

1. Windows Deployment Services

Notre étude préliminaire a donné naissance à la problématique suivante :

1.4 Présentation du Rapport

Analyse des besoins et spécications

2.2 Les enjeux du projet

Ecience de l'intervention L'ecience regroupe à la fois la vitesse d'intervention ainsi que

2.3 Les informations pertinentes pour le technicien

1. Les postes de travail

2.4 Étude de l'existant

Figure 2.1  C÷ur de réseau du Conseil Général

Le c÷ur de réseau du Conseil Général est composé de la manière suivante :

Figure 2.2  C÷ur de LAN

2.4.1. A Le serveur DNS

Un serveur DNS 8 ou serveur de système de nom de domaine est comparable à un annuaire.

2.4.1. B Le serveur DHCP

2.4.1. C Le contrôleur de domaine Active Directory

LDAP 12 est le protocole qui permet d'interroger cet annuaire AD.

2.4.2 Easy Vista

10. Dynamic Host Conguration Protocol

Figure 2.3  Exemple de che de signalement d'incident

2.4.3 Le parc Imprimantes

Figure 2.4  Hétérogénéité du parc d'imprimantes

2.4.3. A Panel Top Access

2.4.4 Convention de nommage

 PC****** pour les postes de travail

2.5 Gestion de projet

Figure 2.5  Gestion de Projet

2.5.1 Équipe Projet

Figure 2.6  Graphe systémique de Patrick IRSAPOULLE

13. Maîtrise d'ouvrage

2.5.2 Planning Prévisionnel

2 Analyse des besoins et spécications 14

Figure 1.1 Organigramme du Conseil Général de la Réunion

Figure 1.2 Organigramme DEMS fonctionnel et nominatif

assurer le suivi des marchés de la direction

concevoir,maintenir et moderniser l'architecture du SI

Analyse des besoins et spécications

Ecience de l'intervention L'ecience regroupe à la fois la vitesse d'intervention ainsi que

Figure 2.1 C÷ur de réseau du Conseil Général

Figure 2.2 C÷ur de LAN

10. Dynamic Host Conguration Protocol

Figure 2.3 Exemple de che de signalement d'incident

Figure 2.4 Hétérogénéité du parc d'imprimantes

PC****** pour les postes de travail

Figure 2.5 Gestion de Projet

Figure 2.6 Graphe systémique de Patrick IRSAPOULLE

Figure 2.7 Planning prévisionnel

Figure 2.8 Modèle en Cascade

Figure 2.9 Validation mensuelle de la progression du projet

2.5.4 Spécication des exigences

Reprenons dans l'ordre, pour cette intervention superue :

Temps de travail perdu pour une pseudo-intervention

garantir la disponibilité et les niveaux de service du système en cas de panne ou de baisse

Figure 3.1 Méthode du Polling

Figure 3.2 Méthode du heartbeat

3.2.3 Les diérentes solutions

Figure 3.3 Ibm Tivoli Software Figure 3.4 HP Openview

Figure 3.5 Computer Associates Tech-

Figure 3.7 Métrologie ou Supervision ?

- Nagios semble parfait pour l'automatisation des congurations et la gestion centralisée de

Une base de données est installée an de permettre la remontée des

Figure 4.1 Schéma SNMP de communication de base

Collecter des informations de gestion sur son environnement local

Figure 4.2 Les échanges entre le Manager et l'Agent

4.3.2 Structure d'une MIB et Object IDentier

Figure 4.3 Structure de l'arborescence d'une MIB

4.4.2 Les diérentes versions de SNMP

Les types de paquets

Ces dénitions de communautés permettent :

Listing 4.1 Format de commande SnmpWalk

Figure 4.4 Exemple de requête SnmpWalk

Listing 4.2 Exemple d'exécution de la commande SnmpGet

5.2.2 Dénition de commande

5.2.3 Dénition de service

Figure 5.1 Architecture globale de CES

Figure 5.2 Nagios et ndOutils