PUPPET AND ICINGA WEB

Automatisation Du Déploiement D’un Système De Supervision
Réalisé Par : TIANI TCHOUILO Rodrigue Wilfried
i
AVANT-PROPOS
L’obtention du diplôme national d’ingénieur au sein de l’Ecole Supérieure Privée
d’Ingénierie et de Technologie ESPRIT en Tunisie est couronnée par la réalisation d’un projet
de fin d’études au terme duquel l’étudiant est appelé à faire une présentation du travail effectué
tout au long dudit projet.
C’est dans ce cadre que j’ai effectué mon projet de fin d’études au sein d’ESPRITEC.
Cette division d’ESPRIT se charge du développement de solutions technologiques innovantes
et de trouver des solutions aux problèmes des entreprises qui font appel à ESPRIT.
Le projet d’Automatisation du Déploiement d’une Solution de Supervision m’a été
attribué dans le but de pallier au problème d’installations des agents de supervision sur les
équipements d’un réseau.

ii
DEDICACES
Je dédie le présent travail :
A mon papa TCHOUILO Isaac et à maman
NDANGUE Désirée Odette pour qui aucun sacrifice
sur Terre ne serait assez cher lorsqu’il s’agit de moi.
A MA FAMILLE A MOI

iii
REMERCIEMENTS
Je remercie l’ETERNEL pour son amour et toutes les grâces dont il me couvre. Père sans qui
je n’aurais pu réaliser ce travail.
Je remercie particulièrement mon enseignant et encadreur M Arafet BOUSSAID pour sa
patience, sa disponibilité, ses encouragements et les conseils qu’il n’a de cesse de me donner
aussi bien sur le plan professionnel que personnel, avec la réalisation du projet fût un bain dans
un océan de connaissances.
Je remercie également M Bayrem KADOUSSI enseignant à l’Ecole Supérieur Privée
d’Ingénierie et de Technologie pour tout le temps qu’il m’a consacré et l’aide qu’il m’a apportée
lors de la réalisation de mon projet.
BIG UP à tous ceux qui m’ont soutenu, que ce suis soit un tour au resto ou un repas délicieux,
un débat distrayant ou une critique constructive, un voyage à Hammamet ou une marche de
galère, …
Tous mes remerciements à tout le corps enseignant d’ESPRIT, à M. Tahar BEN LAKHDAR
et à M. Lamjed BETTAIEB pour leurs multiples efforts et sacrifices déployés pour nous
garantir une bonne formation.
Enfin, je témoigne ici à tous les membres du jury, toute ma reconnaissance et le respect que j’ai
pour eux pour avoir accepté d’évaluer mon travail.

iv
TABLE DES MATIERES
AVANT-PROPOS....................................................................................................................... i
DEDICACES...............................................................................................................................ii
REMERCIMENTS.....................................................................................................................iii
TABLE DES MATIERES..........................................................................................................iv
LISTE DES FIGURES..............................................................................................................vii
LISTE DES TABLEAUX ........................................................................................................viii
LISTE DES ABREVIATIONS ..................................................................................................ix
INTRODUCTION GENERALE……………………………………………...………………..1
PARTIE THEORIQUE ..............................................................................................................2
CHAPITRE I : PRESENTATION DU CADRE DU PROJET..................................................4
Introduction ............................................................................................................................5
I. Présentation Du Cadre de Travail...................................................................................5
II. Présentation Du Projet....................................................................................................6
III. Problématique.............................................................................................................6
A. Contrôle des Equipements....................................................................................6
B. Installation des nouveaux Equipements ...............................................................6
C. Interconnexion aux infrastructures existantes ......................................................7
D. Gestion des droits des utilisateurs (Mutiprofiling)...............................................7
E. La gestion de différents domaines (Multi tenace) ................................................7
F. Haute disponibilité................................................................................................7
G. Equilibrage décharge ............................................................................................7
H. L’automatisation des taches .................................................................................7
Conclusion..............................................................................................................................7
CHAPITRE II : ETAT DE L’ART ............................................................................................9
Introduction ............................................................................................................................9
I. Supervision...................................................................................................................10
A. Présentation ........................................................................................................10
1. But...................................................................................................................10

v
2. Cibles ..............................................................................................................10
3. Méthodes.........................................................................................................11
B. Présentation de solutions existantes ...................................................................11
1. Icinga ..............................................................................................................12
2. Shiken .............................................................................................................12
3. splunk..............................................................................................................13
4. eyes of network...............................................................................................13
C. Comparaison et critique des solutions................................................................14
II. Automatisation .............................................................................................................15
A. Présentation ........................................................................................................15
1. But...................................................................................................................15
2. Cibles ..............................................................................................................15
3. Principe ...........................................................................................................15
B. Présentation de quelques solutions.....................................................................16
1. Puppet .............................................................................................................16
2. Chef.................................................................................................................17
3. CFEngine ........................................................................................................17
C. Comparaison et critique des solutions................................................................18
III. Solution Proposée.....................................................................................................19
IV. METHODOLOGIE DE TRAVAIL .........................................................................19
1. Comparaison...................................................................................................19
2. Choix de la méthodologie...............................................................................22
Conclusion............................................................................................................................23
PARTIE PRATIQUE ...............................................................................................................24
CHAPITRE III : ANALYSE ET SPECIFICATION DES BESOINS.....................................25
Introduction ..........................................................................................................................26
I. Unified Modeling Language (UML) ............................................................................26
A. Les diagrammes structurels ou statiques ............................................................26
B. Les diagrammes comportementaux....................................................................27
C. Diagrammes d’interaction ou dynamiques.........................................................27
II. Contexte Statique..........................................................................................................28
III. Branche Fonctionnelle..............................................................................................29
A. Besoins Fonctionnels..........................................................................................29
B. Besoins Non-Fonctionnels..................................................................................30
C. Diagrammes De Cas D’Utilisation.....................................................................30

vi
D. Description Des Cas D’utilisation......................................................................33
1. Cas d’utilisation « S’Authentifier »................................................................34
2. Cas d’utilisation « Ajouter Equipement » ......................................................35
3. Cas d’utilisation « Ajouter Utilisateur ».........................................................36
4. Cas d’utilisation « Déployer Agent » .............................................................37
5. Cas d’utilisation « Ajouter Domaine »...........................................................38
IV. Branche Technique...................................................................................................39
A. Architecture ........................................................................................................39
B. Outils ..................................................................................................................40
Conclusion............................................................................................................................41
CHAPITRE IV : CONCEPTION.............................................................................................42
Introduction ..........................................................................................................................42
I. Architecture Du Système..............................................................................................43
II. Etude Dynamique .........................................................................................................44
Conclusion............................................................................................................................46
CHAPITRE V : REALISATION ET TESTS ..........................................................................47
Introduction ..........................................................................................................................48
I. Réalisation....................................................................................................................48
A. Environnement de travail ...................................................................................48
1. Environnement matériel..................................................................................48
2. Environnement logiciel...................................................................................48
B. Difficultés rencontrées........................................................................................49
1. La puissance des équipements ........................................................................49
2. Installation ......................................................................................................49
3. Interopérabilité................................................................................................49
C. Chronogramme de réalisation du projet .............................................................49
II. Tests..............................................................................................................................51
Conclusion............................................................................................................................54
CONCLUSION GENERALE ..................................................................................................55
WEBGRAPHIE........................................................................................................................56

vii
LISTE DES FIGURES
Figure 1 : Architecture d'Icinga................................................................................................12
Figure 2 : architecture de Shinken............................................................................................12
Figure 3 : Architecture de Splunk ............................................................................................13
Figure 4 : Architecture de Eyes Of Network ............................................................................13
Figure 5 : Principe de fonctionnement des systèmes automatisés............................................16
Figure 6 : Architecture de Puppet.............................................................................................16
Figure 7 : Architecture de Chef................................................................................................17
Figure 8 : Architecture de CFEngine........................................................................................17
Figure 9 : Icône d'Icinga...........................................................................................................19
Figure 10 : Icône de Puppet......................................................................................................19
Figure 11 : Type de contraintes d'une entreprise......................................................................22
Figure 12 : Interaction 2TUP - UML .......................................................................................28
Figure 13 : Diagramme de paquetages .....................................................................................29
Figure 14 : Diagramme de cas d'utilisation global du système ................................................31
Figure 15 : Diagramme détaillé du cas d'utilisation "Superviser"............................................31
Figure 16 : Diagramme détaillé du cas d'utilisation "Gérer Utilisateurs" ................................32
Figure 17 : Diagramme détaillé du cas d'utilisation "Gérer Automatisation" ..........................32
Figure 18 : Diagramme détaillé du cas d'utilisation "Gérer Domaine"....................................33
Figure 19: Diagramme de séquence du cas d'utilisation "S'Authentifier"................................35
Figure 20: Diagramme de séquence du cas d'utilisation "Ajouter Equipement"......................36
Figure 21: Diagramme de séquence du cas d'utilisation "Ajouter utilisateur".........................37
Figure 22: Diagramme de séquence du cas d'utilisation "Dépoiler agent" ..............................38
Figure 23: Diagramme de séquence du cas d'utilisation "Ajouter Domaine" ..........................39
Figure 24 : Architecture Client-Serveur ...................................................................................39
Figure 25 : Architecture Décentralisée .....................................................................................40
Figure 26 : Architecture complète de notre système ................................................................43
Figure 27 : Diagramme d'activité du système ..........................................................................45
Figure 28 : Chronogramme d'avancement du projet ................................................................51
Figure 29 : Interface d'authentification d'Icinga .......................................................................51
Figure 30 : Interface d'ajout d'un hôte ......................................................................................52
Figure 31 : Interface d'ajout utilisateur.....................................................................................52
Figure 32 : Interface d'importation des hôtes AD ....................................................................53
Figure 33 : Interface de déploiement des agents de supervision..............................................53

Réalisé Par : TIANI TCHOUILO Rodrigue Wilfried vii
i
LISTE DES TABLEAUX
Tableau 1 : Comparaison des solutions de supervision............................................................15
Tableau 2 : Comparaison des solutions d'automatisation.........................................................18
Tableau 3 : Comparaison des méthodologies de travail...........................................................21
Tableau 4 : Schéma de la méthode 2TUP ................................................................................23
Tableau 5 : Présentation des étapes ..........................................................................................50

ix
LISTE DES ABREVIATIONS
2TUP: Two Truck Unified Process
AD : Active Directory
ESPRIT : Ecole Supérieur Privée d’Ingénierie et de Technologie ESPRIT
IP: Internet Protocol
NRPE : Nagios Remote Plugin Executor
WMI : Windows Management Instrumentation
NSCA : Nagios Service Check Acceptor
RFID : Radio Fréquence Identification
SI : Système d’informations
SNMP: Simple Network Management Protocol
TCP : Transmission Control Protocol
UDP : User Datagram Protocol
UML: Unified Modeling Language

1
A l’heure actuelle avec le développement technologique croissant, nous pouvons noter
une évolution exponentielle de la taille des systèmes d’information des entreprises. Le nombre
d’équipements réseaux et de serveurs à contrôler lui aussi augmente pour chaque société.
Cette augmentation des équipements rend la mise en place d’une solution de supervision
incontournable pour assurer le bon fonctionnement de toute l’infrastructure informatique d’une
entreprise. Mais toute solution de supervision nécessite l’installation de certains logiciels
appelés agents sur les machines qui devront être supervisés. Pour des entreprises de grande
taille, l’installation de ces agents devient elle-même une tâche très lourde.
Afin de réduire cette charge de travail supplémentaire, il est nécessaire de trouver un
moyen pour automatiser le déploiement de ces agents utilisés pour la supervision. C’est ainsi
qu’il nous a été confié pour tâche d’Automatiser le déploiement d’une solution de
supervision.
Le présent rapport divisé en deux grandes parties abordera donc les différentes étapes
qui nous ont permis de mener à bien la réalisation de notre travail.
Le premier chapitre sera consacré à la présentation du cadre de travail, du projet et de la
problématique du projet.
Puis dans le second chapitre nous ferons une étude et une critique des solutions
existantes et nous présenterons la solution que nous avons retenue.
Dans le troisième et le quatrième chapitre, nous parlerons de l’analyse de différents
besoins de notre solution, mais aussi des différentes étapes de la conception de projet.
Enfin dans le cinquième chapitre, nous présenterons la réalisation de notre solution et
les tests que nous avons effectués.

2

3

4

5
Introduction
Dans ce chapitre, nous commencerons par présenter notre environnement de travail dans
son ensemble. Puis nous passerons à la présentation du projet, les problèmes qui nous ont menés
à ce dernier et les objectifs qu’il vise.
I. Présentation Du Cadre de Travail
Le projet est réalisé à ESPRITEC au sein de l’Ecole Supérieure Privée d’Ingénierie et de
Technologie (ESPRIT), située au pôle technologique EL GHAZELA. ESPRIT-TECH est
composé de plusieurs équipes qui sont :
- CLOUD-COMPUTING : Qui travaille dans toutes les technologies du Cloud, à savoir
IAAS (Infrastructure As A Service), PAAS (Plateforme As A Service), SAAS (Software
As A service).
- ESPRIT MOBILE : Dont le travail est consacré à tout ce qui a trait aux technologies des
terminaux mobiles, allant des simples téléphones J2ME aux smartphones Android,
BlackBerry ou Apple
- M2M : Qui travaille sur les systèmes embarqués et tout ce qui concerne les microcontrôleurs
et les technologies plus innovatrices comme les RFID
- M-VISION : Ici le travail effectué concerne le traitement d’images et de sons c’est une
branche multimédia d’ESPRIT-TECH
La plupart des projets entrepris mobilisent un grand nombre de personnes et de différentes
équipes. Allant des aspirants ingénieurs aux docteurs en passant par des Utilisateurs chercheurs.

6
II. Présentation Du Projet
Dans le cadre de notre Projet de fin d’études (PFE), nous avons pour tâche de mettre en
place un système de supervision disposant d’un déploiement automatisé. Tout notre travail doit
se faire avec des outils gratuits et Open-Source
Ce projet nous permettra d’avoir une connaissance complète sur le fonctionnement des
solutions de supervision et d’automatisation. Et ainsi de maitriser une bonne partie des
connaissances acquises lors de notre formation. Mais surtout nous permettra d’être
opérationnels pour le monde professionnel.
III. Problématique
La finalité du projet est dans un premier temps de mettre en place un système de supervision
pouvant gérer plusieurs utilisateurs de différents domaines et ceci en intégrant un grand nombre
d’outils différents sur la même interface d’administration. Par la suite le déploiement de notre
solution doit être complètement automatisé.
Ainsi avant d’entamer toute étude pour réaliser le projet, nous allons commencer par
énumérer les problèmes majeurs qui touchent les systèmes de supervision actuels
A. Contrôle des Equipements
Acheter des équipements informatiques et les installer c’est bien mais il est indispensable
de connaitre leur état à tout moment, pour pouvoir les dépanner à temps en cas de problèmes
B. Installation des nouveaux Equipements
Lors de l’ajout d’un équipement dans un réseau la procédure qui consiste à le signaler et à
mettre à jour les outils censés le contrôler est un peu fastidieuse car elle est faite manuellement.

7
C. Interconnexion aux infrastructures existantes
La plupart des entreprises ou écoles disposent déjà d’un système informatique. Il est
impératif que notre système de supervision s’adapte convenablement au système déjà existant.
Et aux annuaires d’utilisateurs déjà existants tels que LDAP.
D. Gestion des droits des utilisateurs (Mutiprofiling)
Dans un système tous les utilisateurs n’ont pas les mêmes droits et les mêmes niveaux
d’accès. Mais chacun aimerait avoir un contrôle total sur ce qu’il fait dans le système.
E. La gestion de différents domaines (Multi tenace)
De nos jours nous rencontrons de plus en plus de sous-domaines indépendants dans les
SI des entreprises ou des écoles. Donc la gestion de la multi-tenance est incontournable
F. Haute disponibilité
Les imprévus tels que le crash d’un serveur sont des évènements que nous pouvons
prévoir. Ainsi pour s’en prémunir il faut mettre en place un système hautement disponible.
G. Equilibrage décharge
Les systèmes informatiques évoluent très vite avec le temps donc il est indispensable de
prévoir cette évolution en mettant en place une architecture distribuée où chaque entité s’occupe
d’une partie du système à superviser.
H. L’automatisation des taches
C’est bien beau d'avoir une infrastructure complètement supervisée mais il arrive parfois
que la correction d’une faille doive être immédiate pour ne pas compromettre l’intégralité du
système. D’où la nécessité d’automatiser les tâches de maintenance et de correction d’erreurs
Conclusion
Nous venons de présenter de manière globale notre projet et l’environnement dans
lequel nous l’avons effectué. Dans le chapitre qui suit nous ferons une petite présentation de
l’état de l’art de notre projet.

8

9
Introduction
Nous ferons de ce chapitre un recueil dans lequel nous mettrons toutes les informations
pertinentes obtenues sur notre sujet et les résultats des études entreprissent pour mener à bien
notre projet.

10
I. Supervision
A. Présentation
La supervision est la surveillance du bon fonctionnement d’un système ou d’une
activité. Elle permet de surveiller, rapporter et alerter les fonctionnements normaux et
anormaux des systèmes informatiques.
1. But
Elle répond aux préoccupations suivantes :
 Technique : surveillance du réseau, de l’infrastructure et des machines ;
 Applicative : surveillance des applications et des processus métiers ;
 Contrat de service : surveillance du respect des indicateurs contractuels ;
 Métier : surveillance des processus métiers de l’entreprise.
Nous ajouterons les actions réflexes à cette surveillance du système. Ce sont les réactions
automatisées en fonction d’alertes définies.
En cas de dysfonctionnement, le système de supervision permet d'envoyer des messages sur
la console de supervision, ou bien d'envoyer un courriel à l'opérateur. Mais si le
dysfonctionnement se produit en dehors des heures de bureau, et en l'absence de système
approprié, l'alerte n'est pas reçue par l'opérateur, et les utilisateurs des applications ne sont pas
prévenus du dysfonctionnement.
C'est pourquoi il peut être utile de compléter le superviseur par un logiciel de gestion des
alertes, qui envoie automatiquement un courriel, un SMS, ou un appel téléphonique à un
opérateur sous astreinte.
2. Cibles
Les différentes entités que nous pouvons superviser sont :
 Les systèmes (OS) : Il s’agit généralement les processeurs, la mémoire, les
périphériques de stockage et parfois les processus

11
 Les réseaux : Qui a pour but de contrôler les périphériques réseau, leur disponibilité et
le flux de données qui les traverse.
 Les applications : Pour connaitre la disponibilité des services et des applications
hébergées par les serveurs.
3. Méthodes
Nous ne saurions parler de supervision sans parler d’agents de supervision. Les principaux
agents utilisés pour la supervision sont :
 SNMP : (Simple Network Management Protocol). C’est est un protocole (port UDP
161) qui permet aux administrateurs réseaux de gérer les équipements et de
diagnostiquer les problèmes. La majorité des équipements comprennent ce protocole.
 WMI : (Windows Management Instrumentation). C’est un système de gestion interne
de Windows qui prend en charge la surveillance et le contrôle de ressource système via
un ensemble d’interfaces. Il fournit un modèle cohérent et organisé logiquement des
états de Windows.
 NRPE : (Nagios Remote Plugin Executor) L’avantage de ce mode de supervision est
l’utilisation de n’importe quel langage pour faire son script d’interrogation. Et ainsi nous
pouvons utiliser n’importe quel agent pour exécuter les requêtes. Il permet aussi de
crypter les données transmises sur le réseau.
 NSCA : (Nagios Service Check Acceptor) Dans ce mode c’est l’agent qui envoie les
infos au superviseur au moment opportun donc il s’agît d’une supervision passive. Mais
il faut néanmoins configurer les requêtes que nous pouvons envoyer.
 NSClient : (Nagios Console Monitor) C’est un agent installable sur Windows qui en
plus de proposer les modes NRPE et NSCA a un mode propre qui est NSC (Nagios
Console Monitoring). Il se propose comme une bonne alternative à WMI sur les
machines Windows
B. Présentation de solutions existantes
Nous pouvons trouver un large panel de solutions de supervision sur le marché. Mais
nous en prendrons quelques-unes pour voir celle qui se rapproche le plus de ce que nous voulons
pour notre projet et qui pourrait pallier à la majorité des problèmes énumérés plus haut.

12
1. Icinga
Icinga est un logiciel de supervision qui a été créé à l’aide du code source de Nagios
(C’est un fils). Il est développé simultanément sous deux branches Icinga1 et Icinga2. Mais
nous ne nous concentrerons que sur la branche Icinga1 car elle est très similaire à Nagios.
Figure 1 : Architecture d'Icinga
2. Shinken
Shinken est une application permettant la surveillance système et réseau. Elle surveille
les hôtes et services spécifiés, alertant lorsque les systèmes vont mal et quand ils vont mieux.
C'est un logiciel libre sous licence GNU AGPL. Elle est complètement compatible avec le
logiciel Nagios et elle a pour but d'apporter une supervision distribuée et hautement disponible
facile à mettre en place. Démarrée comme une preuve de concept pour Nagios sur les
architectures distribuée, le programme a rapidement démontré des performances et une
flexibilité bien plus importantes que son ainé Nagios
Figure 2 : architecture de Shinken

13
3. Splunk
Splunk est une entreprise américaine multinationale dont le siège est situé à San
Francisco. Elle produit des logiciels de recherche et d'analyse de données, accessibles via une
interface web.
Figure 3 : Architecture de Splunk
4. Syes Of Network
C’est un OS orienté gestion de parc informatique et supervision des réseaux. Tous les
outils qu’il intègre sont open-source.
Figure 4 : Architecture de Eyes Of Network

14
C. Comparaison et critique des solutions
Pour se faire une idée des apports de chacune de ces solutions, voici un tableau qui
récapitule la majorité des fonctionnalités des outils présentés plus haut, et qui ressort leurs
avantages et leurs inconvénients.
OUTILS AVANTAGES INCONVENIANTS
- Supervision des
hyperviseurs
- Gestion des alarmes et
notifications en cas de
panne
- Supervision distribuée
multi tenance et haute
disponibilité
- Commande via l’interface
Web
- Possibilité d’intégrer
d’autres outils sur une seule
interface d’administration
- Pas de graphes
- Supervision des
hyperviseurs
panne
- Supervision distribuée et
haute disponibilité
- Interface non ergonomique
- Petite communauté de
développement
- Supervision des
hyperviseurs
panne
- Supervision distribuée
multi tenance et haute
disponibilité
- Commande via l’interface
Web
- Bonne GUI
- Solution payante
- Intégration d’autres outils
impossible

15
- L’ensemble des services
réunis au sein d’une
interface unique.
- Supervision de hyperviseurs
- Configuration via
l’interface web
- Solution très lourde et
consommatrice de
ressources
- Intégration d’autres outils
quasiment impossible
Tableau 1 : Comparaison des solutions de supervision
II. Automatisation
A. Présentation
Nous pouvons recueillir un nombre de définitions immense pour le mot
« Automatisation ». Mais celle qui nous convient le mieux se rapporte à l’automatisation des
processus. Qui est la Suppression totale ou partielle de l'intervention humaine dans l'exécution
de tâches diverses, industrielles, agricoles, domestiques, administratives ou scientifiques.
1. But
Le but de l’automatisation est de supprimer totalement ou partiellement l’intervention
de l’homme dans l’exécution d’une tâche. Dans notre cas, l’automatisation sera utilisée pour le
déploiement de nos agents dans les équipements à superviser afin de réduire le temps
d’exécution limité les erreurs de configuration. Ca limitera ainsi les erreurs dues à la main
humaine et réduira le temps d’exécution de ces tâches. Et aussi de fournir une gestion
centralisée des équipements
2. Cibles
Les cibles ne seront autres que des ordinateurs à contrôler avec notre solution, peu
importe le système d’exploitation. Afin de faciliter l’installation des différents agents qui
permettront de les superviser
3. Principe
Les outils de gestion de configuration ont pour principe :
- Une architecture client/serveur.
- Le serveur dispose d’une configuration de référence.

16
- Le client interroge le serveur.
- Le client effectue le changement afin de correspondre à la configuration de référence
Figure 5 : Principe de fonctionnement des systèmes automatisés
1- Le client demande les modèles de configuration
2- Le serveur les envoie
3- Le client traite en ordre ses modèles
4- (Optionnel) Le client envoie un accusé de réception ou un message d’erreur en cas de
problème
B. Présentation de quelques solutions
Nous allons juste présenter les trois outils d’automatisation les plus connus
1. Puppet
C’est une application qui décrit l’état de configuration d’un ensemble hétérogène des
stations de travail ou serveur et de s’assurer que l’état réel des machines correspond bien à l’état
demandé. En gros, il s’agit d’un logiciel de gestion de configuration de serveurs.
Figure 6 : Architecture de Puppet

17
2. Chef
Chef est un gestionnaire de configurations. Tout comme Puppet, Chef va permettre
d'établir des configurations de référence, que les clients appliqueront
Figure 7 : Architecture de Chef
3. CFEngine
Cfengine (ou GNU/cfengine) est un logiciel libre de gestion de configuration (ou gestion
de parc informatique), écrit en langage C. Il permet de déployer des configurations à travers un
parc informatique, de synchroniser des fichiers sur des serveurs hétérogènes (différents Unix,
Linux et Windows) et d'envoyer des commandes sur ces derniers.
Figure 8 : Architecture de CFEngine

18
C. Comparaison et critique des solutions
OUTILS AVANTAGES INCONVENIANTS
- Centralisation de la
configuration
- Télé déploiement des
configurations sur un
ensemble de serveurs
- Vérification
périodique des
configurations
- Support
multiplateformes
- Utilisation du SSL
- Problème de
déploiement
automatique
d’instance machine
- Supervision distante
- Partage de cookbooks
- Règles de
configuration strictes
- Interfaces utilisateurs
web
- Ecriture des
cookbooks complexe
- Configuration peu
aisée
- Communauté assez
jeune
- Outils complet et
puissant
- Contrôle complet des
hôtes autorisés
- Mise à jour très en
retard
- Difficile à configurer
Tableau 2 : Comparaison des solutions d'automatisation

19
III. Solution Proposée
Apres avoir ressorti les avantages et les inconvénients de nos solutions de supervisons et
d’automatisation, pour notre projet nous retenons donc :
Et nous développerons une interface web qui simplifiera le travail de l’administrateur.
IV. METHODOLOGIE DE TRAVAIL
1. Comparaison
Bien que n’étant pas en train de développer une application, l’utilisation d’une
méthodologie de travail serait un plus pour notre projet car ça augmentera notre rentabilité.
Voici un tableau comparatif des différentes méthodologies de travail parmi lesquelles nous
choisirons une.
- Icinga : Comme solution de supervision car il
répond à toutes nos exigences et est un outil assez
simple à utiliser. Grâce à son interface web
modifiable à volonté, nous pourrions y intégrer
toutes nos solutions alternatives et l’interface de
nos autres outils. Figure 9 : Icône d'Icinga
- Puppet : Comme solution d’automatisation
puisque contrairement à tous ses semblables, il
est le simple à mettre en place et sa communauté
de développement est très vaste. Il s’adaptera
facilement à l’évolution de notre système et
pourra contrôler les hôtes peut indépendamment
de leur système d’exploitation
Figure 10 : Icône de Puppet

20
Méthodologies Description Points forts Points faibles
Cascade
- Les phases sont
déroulées d’une
manière
séquentielle.
- Distingue
clairement les
phases du projet.
- Non itératif ;
- Pas de modèles
pour les
documents.
RUP (Rational
Unified Process)
- Promu par
Rational ;
- Le RUP est à la
fois une
méthodologie et
un outil prêt à
l’emploi ;
- Cible des projets
de plus de 10
personnes.
- Itératif ;
- Spécifie le
dialogue entre les
différents
intervenants du
projet ;
- Propose des
modèles de
documents pour
des projets types.
- Assez flou dans
sa mise en
œuvre ;
- Ne couvre pas les
phases en amont
et en aval au
développement.
2TUP(Two Truck
Unified Process)
- S’articule autour
de l’architecture;
- Propose un cycle
de
développement
en Y;
- Cible des projets
de toutes tailles.
- Itératif ;
- Laisse une large
place à la
technologie et à
la gestion des
risques ;
- Définit les profils
des intervenants,
- Plutôt superficiel
sur les phases
situées en amont
et en aval du
développement ;
- Ne propose pas
de documents
types.

21
les plannings, les
prototypes.
XP (eXtreme
Programming)
- Ensemble des
bonnes pratiques
de
développement ;
- Cible : Moins de
10 personnes.
- Itératif ;
- Donne une
importance aux
aspects
techniques ;
- Innovant :
programmation
en duo.
- Assez flou dans
sa mise en
œuvre ;
- Ne couvre pas les
phases en amont
et en aval au
développement.
Scrum
- Se base sur des
itérations dites
sprints de
développement.
- Donne toute
confiance aux
développeurs et
les laisser faire
leur travail ;
- Chaque itération
a un objectif bien
précis et fournit
une
fonctionnalité
testée.
- La mise en œuvre
du
développement
n’est pas
précisée ;
- Le
développement
rapide et répétitif
se traduit par une
forte pression sur
l’ensemble des
membres de
l’équipe de
développement.
Tableau 3 : Comparaison des méthodologies de travail

22
2. Choix de la méthodologie
2TUP signifie « 2 Track Unified Process».C’est un processus qui répond aux
caractéristiques du Processus Unifié. Le processus 2TUP apporte une réponse aux contraintes
de changement continuel imposées aux systèmes d’information de l’entreprise. En ce sens, il
renforce le contrôle sur les capacités d’évolution et de correction de tels systèmes.« 2 Track»
signifient littéralement que le processus suit deux chemins. Il s’agit des « chemins fonctionnels
» et « d’architecture technique », qui correspondent aux deux axes de changement imposés au
système d’information
Figure 11 : Type de contraintes d'une entreprise
La branche gauche (fonctionnelle) : capitalise la connaissance du métier de l’entreprise. Elle
constitue généralement un investissement pour le moyen et le long terme. Les fonctions du
système d’information sont en effet indépendantes des technologies utilisées. Cette branche
comporte les étapes suivantes :
- La capture des besoins fonctionnels, qui produit un modèle des besoins focalisé sur le métier
des utilisateurs.
- L’analyse.
La branche droite (architecture technique) : capitalise un savoir-faire technique. Elle
constitue un investissement pour le court et moyen terme. Les techniques développées pour le
système peuvent l’être en effet indépendamment des fonctions à réaliser. Cette branche
comporte les étapes suivantes :
- La capture des besoins techniques.
- La conception générique.

23
La branche du milieu : à l’issue des évolutions du modèle fonctionnel et de l’architecture
technique, la réalisation du système consiste à fusionner les résultats des 2 branches. Cette
fusion conduit à l’obtention d’un processus en forme de Y.
Cette branche comporte les étapes suivantes :
- La conception préliminaire.
- La conception détaillée.
- Le codage.
- L’intégration
Tableau 4 : Schéma de la méthode 2TUP
Conclusion
Apres avoir fait le tour des différents outils et solutions qu’on pourrait utiliser pour notre
projet, et après une comparaison bien élaborée nous avons retenu les solutions qui nous aideront
à mener notre tâche à bien.

24
Ainsi donc s’achève la partie théorique de notre rapport. Dans la prochaine partie nous
verrons toutes les étapes qui nous ont aidés à mener à bien notre projet.

25

26
Introduction
Une fois le choix des solutions et des méthodologies nécessaires à la réalisation de notre
projet fait, il convient maintenant de choisir un langage de modélisation afin de faire une
analyse plus approfondie des différentes fonctionnalités que doit fournir notre solution. Comme
il est conseillé dans la méthode 2TUP, nous commencerons d’abord par identifier les principaux
acteurs et leurs rôles. Par la suite dans la branche fonctionnelle, nous allons définir aussi bien
les besoins fonctionnels que les besoins non fonctionnels de notre solution. Puis viendra la
présentation et la description des cas d’utilisations de notre système. Et nous terminerons la
branche technique de notre méthodologie où nous listerons les moyens techniques utilisés.
I. Unified Modeling Language (UML)
En informatique UML ou Langage de Modélisation Unifié, est un langage de modélisation
graphique à base de pictogrammes. Il est utilisé en développement logiciel, et en conception
orientée objet et couramment utilisé dans les projets logiciels. Il est composé de 14 diagrammes
répartis sur 3 groupes de diagrammes qui sont :
A. Les diagrammes structurels ou statiques
Les diagrammes de ce groupe décrivent le contexte statique de notre système. Parmi ses
diagrammes on distingue :
- Le diagramme de classe : Il contiendra toutes les classes du système à modéliser

27
- Le diagramme d’objets : Pour la représentation des objets (Instances de classes) utilisées
dans le système
- Le diagramme de composants : Donne la représentation d’un point de vue physique des
composants du système tels qu’ils sont mis en œuvre
- Le diagramme de déploiement : Afin de représenter les éléments matériels et la manière
dont les éléments du système sont répartis sur ces éléments matériels et leurs interactions
- Le diagramme de paquetage : Utilisé pour représenter les dépendances entre les groupes
d’éléments
B. Les diagrammes comportementaux
Les diagrammes de ce groupe représentent le comportement et les fonctionnalités de notre
système. Nous y distinguons
- Le diagramme d’activité : Qui décrit sous forme de flux ou d’enchainement d’activité le
comportement du système ou de ses composants
- Le diagramme de cas d’utilisation : Il permet d’identifier les possibilités d’interactions
entre les acteurs et le système ou encore toutes les fonctionnalités que doit fournir le système
C. Diagrammes d’interaction ou dynamiques
Les diagrammes de ce groupe montrent d’une manière plus détaillée le fonctionnement du
système lors de son utilisation. On y trouve entre autres :
- Le diagramme de séquence : Donne la représentation de toutes les étapes du déroulement
des traitements et des interactions entre les éléments du système et/ou de ses acteurs.
- Le diagramme de communication : permet de décrire les enchaînements possibles entre les
scénarios préalablement identifiés sous forme de diagrammes de séquences.
Comme vous pouvez le voir sur la figure ci-dessous, l’utiliser UML et 2TUP permet un travail
optimal car les deux sont complémentaires.

28
Figure 12 : Interaction 2TUP - UML
II. Contexte Statique
Nous allons ici lister les différents intervenants de notre système. Pour éviter toute
ambigüité avec les termes techniques un peu de vocabulaire ne serait pas de trop :
- Acteur : C’est toute entité (homme ou machine) qui pourra interagir avec notre système
- Système : C’est la solution que nous devons mettre en place au cours de notre projet de fin
d’études
- Acteur primaire : Acteur pour qui est réalisée la solution
- Acteur secondaire : Acteur qui interagit avec le système mais donc les fonctionnalités
permettent de satisfaire les besoins des acteurs primaires
Les différents acteurs principaux de notre système sont :
- Les Utilisateurs : Ce seront les maillons faibles de la chaine des acteurs car leurs
interactions avec le système seront très limitées.
- L’administrateur : Il pourra tout contrôler sur le système et c’est aussi lui qui se chargera
du bon fonctionnement de ce dernier.
- Les systèmes auxiliaires (Acteurs secondaire) : Bien que nous n’en parlerons pas trop dans
la suite de notre étude, il faut noter que notre système pour une raison ou un autre pourra
interagir avec d’autres entités, tels que des annuaires et des bases de données distantes.

29
La figure ci-dessus permet de représenter les différents acteurs et leurs interactions avec
notre système.
Figure 13 : Diagramme de paquetages
Bien que nous arrivons à distinguer clairement les différents acteurs, cette représentation
reste incomplète car n’apporte aucune information sur le fonctionnement de notre système. Le
prochain point nous apportera les détails qu’il nous maque à ce niveau
III. Branche Fonctionnelle
Nous avons une vue très générale de notre système après le contexte statique. Pour éclaircir
certains points afin de faciliter notre travail, nous allons nous attaquer à l’énumération des
différents besoins que doit fournir notre système.
A. Besoins Fonctionnels
Les besoins fonctionnels représentent les attentes des utilisateurs en termes de
fonctionnalité du système. C’est en quelque sorte l’ensemble des fonctionnalités que doit
fournir notre système pour pouvoir dire qu’il est opérationnel. En d’autres termes ce sont nos
différents cas d’utilisation. A ce titre nous pourrons citer.
- S’authentifier
- Superviser
- Gérer utilisateur
SYSTEME
Adminsitrateur Utilisateur
Systèmes Auxiliaires

30
- Gérer Automatisation
- Gérer domaines
B. Besoins Non-Fonctionnels
Une fois les exigences des acteurs pris en considération, il serait bien d’énumérer l’ensemble
des éléments nécessaires pour le bon fonctionnement de notre système. Pour notre projet nous
avons entre autre :
- L’ergonomie des interfaces
- L’extensibilité
- La sécurité
- La haute disponibilité
- L’équilibrage de charges
- L’interopérabilité avec d’autres systèmes
- La multi tenance
Une fois l’énumération des différents besoins de notre système effectué, nous pouvons
passer à l’étude des cas d’utilisation de notre système.
C. Diagrammes De Cas D’Utilisation
Les cas d’utilisation de notre système ne sont rien autres que l’ensemble de besoins
fonctionnels de ce dernier. C’est donc dans cette partie que nous ressortirons le rôle de chaque
acteur de notre système.

31
Figure 14 : Diagramme de cas d'utilisation global du système
Figure 15 : Diagramme détaillé du cas d'utilisation "Superviser"
System
Adminsitrateur
Utilisateur
S'authentifier
Gerer Domaines
Gerer Utilisateurs
Superviser
<<include>>
<<include>>
<<include>>
Gerer Automatisation
<<include>>
System
Utilisateur
Ajouter Equipement
Supprimer Equipement
Modifier Equipement
S'authentifier
Generer Rapport
Afficher Graphe
Superviser
<<include>>
Adminsitrateur

32
Figure 16 : Diagramme détaillé du cas d'utilisation "Gérer Utilisateurs"
Figure 17 : Diagramme détaillé du cas d'utilisation "Gérer Automatisation"
System
Adminsitrateur
S'authentifier
Ajouter utilisateur
Supprimer Utilisateur
Modifier utilisateur
Gerer Utilisateurs
<<include>>
System
Adminsitrateur
S'authentifier
Deployer Agent
Gerer Automatisation
Intégrer Agent
Intégrer Configurations
<<include>>

33
Figure 18 : Diagramme détaillé du cas d'utilisation "Gérer Domaine"
Les figures ci-dessus représentent l’ensemble des cas d’utilisation de notre système.
Toutefois dans la suite de notre étude nous ne les présenterons pas tous, mais nous pourrions y
faire allusion.
D. Description Des Cas D’utilisation
Dans cette partie nous entrerons plus en détail sur les principaux cas d’utilisations de notre
système, nous n’énumérerons pas tous les cas d’utilisation. Mais plutôt ceux qui nous semblent
intéressants. Ainsi les cas que nous allons étudier seront :
- S’authentifier
- Ajouter Equipement
- Ajouter utilisateur
- Déployer agent
- Ajouter domaine
System
Adminsitrateur
Ajouter Domaine
S'authentifier
Gerer Domaines
Supprimer Domaine
<<include>>

34
1. Cas d’utilisation « S’Authentifier »
Etapes Description
Résumé  Acteurs : Administrateur/Utilisateur
 Titre : S’Authentifier
 Description : Le système identifie à ce niveau
l’administrateur/l’utilisateur qui veut se connecter.
Pré conditions  L’administrateur/ l’Utilisateur s’est connecté au système
 Le système est opérationnel
Scénario
Nominal
 L’administrateur/ l’utilisateur entre ses paramètres de connexion
identifiant et mot de passe
 Le système vérifie les informations saisies
 Le système affiche la page de profil de l’administrateur/
l’utilisateur
Scénario
Alternatif
 Les données saisies sont erronées
Post-conditions  L’administrateur/ l’utilisateur est sur sa page de profil
 Le système attend désormais qu’il exécute une action

35
Séquencement
Figure 19: Diagramme de séquence du cas d'utilisation "S'Authentifier"
2. Cas d’utilisation « Ajouter Equipement »
Etapes Description
 Titre : Ajouter Equipement
 Description : l’administrateur/l’utilisateur veut ajouter un
équipement à pour le superviser
Pré
conditions
 L’administrateur/ l’utilisateur s’est authentifié au système et
accède à l’interface d’ajout d’équipements
Scénario
Nominal
 L’administrateur/l’utilisateur entre ses paramètres de
l’équipement à ajouter
 Le système vérifie les paramètres saisis
 Le système affiche un message d’ajout correct
Scénario
Alternatif
 Les paramètres entrés sont incorrects
Verification login et mot de passealt
[Test OK]
[Test KO]
[Test OK]
[Test KO]
: Utilisateur
Systeme
1 : Saisi de Login et Mot de passe()
2 : Verifier Valider login et mot de passe()
3 : Login et mot de passe correct()
4 : Affichage des l'interface de supervision()
5 : Login et mot de passe incorrect()
6 : Affichage de l'interface d'authentification()

36
Post-conditions  L’administrateur/l’utilisateur peut superviser l’équipement
ajouter
 Le système actualise ses configurations et attend l’exécution
d’une autre action
Séquencement
Figure 20: Diagramme de séquence du cas d'utilisation "Ajouter Equipement"
3. Cas d’utilisation « Ajouter Utilisateur »
Etapes Description
 Titre : Ajouter Utilisateur
 Description : l’administrateur/l’Utilisateur veut ajouter un
utilisateur au système
Pré conditions  L’administrateur/ l’Utilisateur s’est authentifier au système et
accède à l’interface d’ajout d’utilisateur
Scénario
Nominal
 L’administrateur/l’Utilisateur entre les paramètres de l’utilisateur
à ajouter
Verification des Parametresseq
[Test pas OK]
[Test OK]
[Test pas OK]
[Test OK]
: Utilisateur
Systeme
1 : Saisi des parametres de l'equipement()
2 : Verification des parametres()
3 : Parametres corrects()
4 : Message d'acquissement() 5 : Mise a jour des Configurations()
6 : Parametres incorrects()
7 : Message d'erreur()

37
Scénario
Alternatif
Post-conditions  Le nouvel utilisateur peut maintenant se connecter au système
Séquencement
Figure 21: Diagramme de séquence du cas d'utilisation "Ajouter utilisateur"
4. Cas d’utilisation « Déployer Agent »
Etapes Description
Résumé  Acteurs : Administrateur
 Titre : Déployer Agent
 Description : l’administrateur veut déployer un agent de
supervision sur un équipement
Pré conditions  L’administrateur s’est authentifier au système et accède à
l’interface de déploiement
Scénario
Nominal
 L’administrateur entre les paramètres de déploiement
Verification des parametre de l'utilisateurseq
[Test OK]
[Test pas OK]
[Test OK]
[Test pas OK]
Systeme
: Adminsitrateur
1 : Saise des parametres de l'utilisateur a ajouter()
2 : Verifications des parametres()
3 : Parametres Corrects()
4 : Message d'acquitement()
5 : Mise à jour des Configurations()
6 : Parametres Incorrects()

38
Scénario
Alternatif
Post-conditions  L’équipement sur lequel a été déployé l’agent peut alors être
supervisé via l’agent qu’on vient de lui installer
Séquencement
Figure 22: Diagramme de séquence du cas d'utilisation "Dépoiler agent"
5. Cas d’utilisation « Ajouter Domaine »
Etapes Description
Résumé  Acteurs : Administrateur
 Titre : Ajouter Domaine
 Description : l’administrateur veut ajouter tous les équipements
d’un autre domaine au système
Pré conditions  L’administrateur s’est authentifier au système et accède à
l’interface d’ajout de domaine
 L’administrateur entre les paramètres du domaine à ajouter
Verification des parametres de déployementseq
[Test OK]
[Test pas OK]
[Test OK]
[Test pas OK]
: Adminsitrateur
Systeme
1 : Saisi des parametres de déployement de l'agent()
3 : Parametres corrects()
4 : Message d'acquitement()
5 : Mise a jour des Configurations()
6 : Parametres incorrets()

39
Scénario
Nominal
Scénario
Alternatif
Post-conditions  Tous les équipements du nouveau domaine peuvent maintenant
être supervisés.
Séquencement
Figure 23: Diagramme de séquence du cas d'utilisation "Ajouter Domaine"
IV. Branche Technique
Une fois que les fonctionnalités du système ont été présentées, il est temps de lister les outils
que nous allons utiliser et l’architecture de notre système.
A. Architecture
Les deux grands groupes d’architecture sont :
Verification des parametre du domaineseq
[Test OK]
[Test pas OK]
[Test OK]
[Test pas OK]
: Adminsitrateur
Systeme
1 : Saisi des parametres du domaine()
3 : Parametres OK()
4 : Message d'aquitement()
5 : Mise a jour des Configurations()
6 : Parametres incorrects()

40
Dans notre travail nous allons sans hésitation choisir l’architecture décentralisée car
notre système nécessite plusieurs outils assez consommateurs de ressources matérielles et
de ce fait nous ne pouvions l’implémenter sur un seul serveur. Pour assurer la supervision
d’un réseau assez vaste, nous devrons faire une distribution des tâches de supervision sur
les différentes parties de notre réseau.
B. Outils
Les différents outils que nous allons utiliser pour mener à bien notre projet sont :
- Client – Serveur : Caractérisé par la communication
entre deux entités qui sont le client et le serveur. Cette
architecture est facile à implémenter et a un temps de
réaction excellent. Mais la tolérance aux pannes et
aux incidents est extrêmement réduite
- Décentralisée : Ici le client peu communiquer avec
plusieurs serveurs. Et en cas de panne d’un serveur, le
service ne s’arrêtera pas pour autant
Figure 25 : Architecture Décentralisée
- HTML : (Hyper Text Markup Language) Nous
réaliserons les pages web de notre système avec ce
langage.
- CSS3 : (Cascading Style Sheet) Nous permettra de
faire la mise en forme de nos pages web pour afin
d’avoir des interfaces conviviales
- JavaScript : Il apporte de fonctionnalité
supplémentaire au HTML et permet d’effectuer des
contrôles coté client.

41
Conclusion
Nous avons fini tout le travail d’étude et d’analyse de notre solution. Dans le chapitre
qui suit, nous attaquerons la conception de notre solution.
- PHP : (HyperText Processor) C’est un langage de
programmation qui s’intègre dans vos pages HTML.
Il nous permettra de faire le lien entre l’interface web
et nos commandes systèmes.
- Perl : C’est un langage de programmation multi
plateforme. Nous l’utiliserons pour l’exécution des
plugins qui de supervision de notre système
- Python : C’est un langage de programmation multi
plateforme. On l’utilisera pour l’exécution de nos
taches d’automatisation.
- Shell : Nous l’utiliserons pour exécuter des
commandes système de tout genre
- VBS: C’est un langage qui nous permettra d’effectuer
des scripts de supervision très avancé sur des clients
Windows

42
Introduction
Dans ce chapitre nous présenterons l’architecture complète de notre système, et nous ferons
une étude dynamique. Partie dans laquelle nous présenterons le diagramme d’activité de tout
notre système.

43
I. Architecture Du Système
Etant dans un projet d’administration réseau et système, la présentation de l’architecture
complète de notre système sera un plus pour la compréhension de notre travail.
Figure 26 : Architecture complète de notre système
Les deux serveurs Icinga permettent de mettre en place une solution de supervisons
distribuées. Sur tous les équipements de notre système, nous trouvons au moins l’un des agents
de supervision (NRPE, NSClient, WMI, …) énoncé dans la partie théorique. Dans nos serveurs
de supervision nous avons installé de nombreux plugins et des outils tels que PNP4Nagios
(Graphes), Jasper Report(Rapport), Nconf (Pour la configuration des hôtes). Nous y avons
configuré aussi les hôtes suivant leur niveau d’accréditation.
Le serveur Puppet Master contient toutes les configurations nécessaires pour déployer
les agents de supervision dans les hôtes nouvellement ajoutés à notre système. Et il permettra
éventuellement la mise en place d’autres serveurs de supervision.
PFSENSE
DMZ
Icinga Ma st er
192.168.22.1
LAN
MANa gement
WinSer ver 2008
192.168.11.1
INt er net
Admin
192.168.0.1 Ecr a n
Icinga SLAVE
192.168.22.10
PUPPET MASTER
192.168.22.50
PUPPET MASTER
192.168.22.60

44
Le Serveur Windows contient l’annuaire (Active Directory) de notre système pour le
stockage des utilisateurs et peut être utilisé comme solution d’authentification de nos
utilisateurs. Il possède aussi notre DNS pour la résolution des hôtes que nous ajoutons depuis
l’annuaire.
Le pare-feu PFSense contrôlera le flux de données qui circulera dans notre système pour
fournir un assez bon niveau de sécurité.
II. Etude Dynamique
Apres avoir vu l’architecture complète du système, nous montrerons ici un aperçu du
système et son fonctionnement via son diagramme d’activité. Ce diagramme représente
l’organigramme de notre système ou encore une traduction algorithmique de ce dernier

45
Figure 27 : Diagramme d'activité du système
UtilisateurAdministrateur
Authentification
Refus
Superviser
Ajouterequipement
GererUtulisateuur
GererAutimatisation
GererDomaines
SupprimerEquipement
Modifierequipement
AfficherGraphes
GénérerRapport
AjouterutilisateurModififerUtilisateur
SupprimerUtilisateur
DeployerAgent
IntégrerConfiguration
IntégrerAgent
AjouterDomaine
SupprimerDomaine
Validation
OK
Echec

46
Conclusion
Ayant atteint la fin de ce chapitre qui nous a permis de compléter l’analyse faite
précédemment par la conception de notre solution, nous pouvons maintenant passer à la phase
de réalisation et de test de notre solution.

47

48
Introduction
Dans les chapitres précédents, nous avons fait ressortir l’ensemble des besoins,
l’architecture et le fonctionnement algorithmique de notre système. Ici nous parlerons de la
réalisation de notre solution et nous présenterons les tests effectués lors de notre travail.
I. Réalisation
Nous présenterons l’environnement de travail de matériel et logiciel, puis le chronogramme
des tâches effectuées.
A. Environnement de travail
1. Environnement matériel
Dans le cadre de notre projet, nous avons utilisé un ordinateur portable ayant les caractéristiques
suivantes.
- Modèle : HP 620
- Système d’exploitation : Windows 7 Edition Intégrale 64Bits
- Processeur : Pentium(R) Dual-Core CPU T4500 @ 2.30GHz (2 CPUs), ~2.3GHz
- Mémoire Vive : 6144MB
2. Environnement logiciel
VMware Workstation 10 : Comme logiciel de
virtualisation pour mettre sur pied notre
architecture
CentOS 6.5 : Il sera installé comme sur des
machines virtuelles pour nos systèmes de
supervision et d’automatisation
Windows Server 2008 Datacenter : Il contiendra
notre annuaire et notre serveur de noms.
StartUML : Nous l’utiliserons pour la
modélisation de notre système

49
EdrawMaw : Utilisé pour faire nos schémas
d’architectures.
B. Difficultés rencontrées
Les principales difficultés que nous avons sont les suivantes
1. La puissance des équipements
Devant réaliser un système assez consommateur en ressources, nous avons eu
d’énormes difficultés pour faire tourner notre solution sur notre architecture physique car, elle
n’avait pas de caractéristiques nécessaires pour supporter tout notre système.
2. Installation
L’installation de Puppet fût loin d’être aisée car il fallait trouver la bonne version du
master et de l’agent. Mais aussi il faut gérer les problèmes de certificat entre le master et le
slave.
3. Interopérabilité
Notre système possède des entités hétérogènes donc, nous devons assurer la
communication entre ces différentes entêtées.
C. Chronogramme de réalisation du projet
Ci-dessous est détaillé le déroulement de notre projet
Numéros Nom des tâches Durée Début Fin Prédécesseurs
1 Automatisation du déploiement
d’une solution de supervision
109
jours
03/02/14 03/07/14
2 Etude Générale 70 jours 03/02/14 09/05/14
3 Prise en main du sujet 6 jours 03/02/14 10/02/14
4 Analyse des besoins 7 jours 11/02/14 19/02/14 3
5 Etude des solutions de supervision 13 jours 20/02/14 10/03/14 4
6 Installation des solutions de
supervision
20 jours 26/02/14 25/03/14 4FS+4 jours

50
7 Etude comparative des solutions de
supervision
7 jours 17/03/14 25/03/14 5FS+4 jours
8 Prise en main de la solution de
supervision choisie
14 jours 28/03/14 16/04/14 7;6FS+2 jours
9
Etude des méthodes et agents de
supervision
14 jours 04/04/14 23/04/14
6FS+7
jours;7FS+7
jours
10 Rédaction du rapport 58 jours 14/04/14 02/07/14 7FS+10 jours
11 Pannes du PC 11 jours 24/04/14 08/05/14 9;8;7;6;5;4;14;15
12 Mise en place de notre topologie
globale
3 jours 09/05/14 13/05/14 11
13 Configuration des serveurs
secondaires de notre système
7 jours 14/05/14 22/05/14 12
14 Intégration de plugins et d'outils
auxiliaires
10 jours 26/03/14 08/04/14 7
15 Etude et comparaison des solutions
d'automatisation
4 jours 17/04/14 22/04/14 8
16 Test de notre solution de
supervision finale
60 jours 09/04/14 01/07/14 14
17 Supervision de tout notre système 28 jours 23/05/14 01/07/14 13
18 Installation et test de la solution
d'automatisation
28 jours 23/05/14 01/07/14 13
19 Développement de l'interface
d'ajout de domaines
2 jours 02/06/14 03/06/14
20 Développement de l'interface
d'automatisation
7 jours 04/06/14 12/06/14 19
21 Développement des scripts
d'arrière-plan de nos interfaces
14 jours 13/06/14 02/07/14 20
Tableau 5 : Présentation des étapes

51
Figure 28 : Chronogramme d'avancement du projet
II. Tests
Ici nous présenterons quelques captures d’écran de notre système.
Figure 29 : Interface d'authentification d'Icinga
Pour accéder aux différentes fonctionnalités du système, l’utilisateur doit se connecter
à cette interface d’authentification

52
Figure 30 : Interface d'ajout d'un hôte
Pour pouvoir ajouter un périphérique afin de le superviser, l’utilisateur doit remplir cette
interface avec les paramètres adéquats.
Figure 31 : Interface d'ajout utilisateur
Cette interface permet d’ajouter un utilisateur a notre système et de définir ses droits
d’accès.

53
Figure 32 : Interface d'importation des hôtes AD
L’interface ci-dessus permet de récupérer tous les hôtes présents dans un annuaire active
directory et de l’ajouter à la liste des hôtes à superviser dans notre système.
Figure 33 : Interface de déploiement des agents de supervision
Sur cette interface on va pouvoir choisir le pc sur lequel on va exécuter le déploiement
de l’agent de supervision.
Domaine :
Administrateur :
Mot de passe :
Adresse IP :
OK
OS :
Agent :
Adresse IP :
OK

54
Conclusion
Ainsi donc se termine cette partie où nous avons présenté la réalisation et les tests
effectués lors de la mise en place de notre système.

55
Le présent document a été rédigé au terme du projet de fin d’études réalisé au sein
d’ESPRITEC. Le projet consistait à l’AUTOMATISATION DU DEPLOIEMENT D’UNE
SOLUTION DE SUPERVISION. Cette automatisation a pour but de faciliter et réduire les
tâches de déploiement des agents qui permettent de superviser nos équipements. Pour mener à
bien notre travail, nous l’avons divisé en deux parties.
La partie théorique qui consiste à faire une étude du projet est subdivisée en deux
chapitres. Dans le premier nous avons présenté ESPRITEC et notre projet, puis la
problématique de notre sujet et les objectifs qu’il devait atteindre. Dans le second chapitre, nous
avons eu à étudier comparer et critiquer des solutions de supervision et d’automatisation. Et de
cette étude nous avons tiré la solution qui convenait le mieux à l’élaboration de notre projet.
La deuxième partie de notre rapport intitulé partie théorique quant à elle comporte trois
chapitres. Dans cette partie nous avons commencé par faire ressortir l’ensemble des besoins de
notre système aussi bien du point de vue fonctionnel que non-fonctionnel et de là nous avons
déduis les cas d’utilisation de notre système. Puis dans la zone réservée à la conception, nous
avons présenté l’architecture complète et la vue algorithmique de notre système. Enfin nous
avons montré les étapes de réalisation de notre solution et les tests effectués lors de cette
dernière.
Pour aller plus loin et perfectionner notre solution, on pourrait automatiser le
déploiement des serveurs de supervision et de ses services par la même occasion.

56
WEBGRAPHIE
(Ces liens ont été consultés pour la dernière fois le 01-07-2014lors de la rédaction de ce rapport)
http://docs.icinga.org/ (Documentation d’Icinga)
http://www.microsoft.com/france/serveur-cloud/windows-server/comparer-editions.aspx
(Comparaison des éditions de Windows server)
http://wiki.monitoring-fr.org/ (Toutes informations détaillées concernant la supervision)
http://www.edcint.co.nz/checkwmiplus/ (Plugin perl pour la supervision via WMI)
http://www.tutorialarena.com/blog/run-shell-script-from-php.php
(Exécution de scripts Shell via des pages web)
http://blog.nicolargo.com (Recueil d’infos et de tutoriels sur la supervision)
http://fr.slideshare.net/wilfriedtiani/cacti-pnp (Comparaison de solutions de métrologie pour
Icinga)
https://wiki.icinga.org/display/howtos/Setting+up+Icinga+with+Reporting (Reporting)

PUPPET AND ICINGA WEB

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à PUPPET AND ICINGA WEB

Similaire à PUPPET AND ICINGA WEB (20)

Plus de Wilfried Tiani

Plus de Wilfried Tiani (7)

Dernier

Dernier (19)

PUPPET AND ICINGA WEB