PUPPET AND ICINGA WEB

i

Automatisation Du Déploiement D’un Système De Supervision

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.

Réalisé Par : TIANI TCHOUILO Rodrigue Wilfried

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

Introduction.............................................................................................................................4

I. Présentation Du Cadre de Travail...................................................................................4

II. Présentation Du Projet....................................................................................................4

III. Problématique.............................................................................................................5

A. Contrôle des Equipements....................................................................................5

B. Installation des nouveaux Equipements................................................................5

C. Interconnexion aux infrastructures existantes.......................................................5

D. Gestion des droits des utilisateurs (Mutiprofiling)...............................................5

E. La gestion de différents domaines (Multi tenace).................................................6

F. Haute disponibilité................................................................................................6

G. Equilibrage décharge............................................................................................6

H. L’automatisation des taches..................................................................................6

Conclusion..............................................................................................................................6

CHAPITRE II : ETAT DE L’ART.............................................................................................7

Introduction.............................................................................................................................8

I. Supervision.....................................................................................................................8


v


A. Présentation...........................................................................................................8

1. But.....................................................................................................................8

2. Cibles.................................................................................................................9

3. Méthodes...........................................................................................................9

B. Présentation de solutions existantes....................................................................10

1. Icinga...............................................................................................................10

2. Shiken..............................................................................................................10

3. splunk..............................................................................................................11

4. eyes of network...............................................................................................11

C. Comparaison et critique des solutions................................................................11

II. Automatisation..............................................................................................................13

A. Présentation.........................................................................................................13

1. But...................................................................................................................13

2. Cibles...............................................................................................................13

3. Principe............................................................................................................13

B. Présentation de quelques solutions.....................................................................14

1. Puppet..............................................................................................................14

2. Chef.................................................................................................................14

3. CFEngine.........................................................................................................15

C. Comparaison et critique des solutions................................................................16

III. Solution Proposée.....................................................................................................17

IV. METHODOLOGIE DE TRAVAIL..........................................................................17

1. Comparaison....................................................................................................17

2. Choix de la méthodologie...............................................................................20

Conclusion............................................................................................................................21

PARTIE PRATIQUE................................................................................................................22

CHAPITRE III : ANALYSE ET SPECIFICATION DES BESOINS......................................23

Introduction...........................................................................................................................24

I. Unified Modeling Language (UML)............................................................................24

A. Les diagrammes structurels ou statiques.............................................................24

B. Les diagrammes comportementaux....................................................................25

C. Diagrammes d’interaction ou dynamiques.........................................................25

II. Contexte Statique..........................................................................................................26

III. Branche Fonctionnelle..............................................................................................27

A. Besoins Fonctionnels..........................................................................................27


vi


B. Besoins Non-Fonctionnels..................................................................................27

C. Diagrammes De Cas D’Utilisation.....................................................................28

D. Description Des Cas D’utilisation......................................................................30

1. Cas d’utilisation « S’Authentifier »................................................................31

2. Cas d’utilisation « Ajouter Equipement ».......................................................32

3. Cas d’utilisation « Ajouter Utilisateur ».........................................................33

4. Cas d’utilisation « Déployer Agent »..............................................................34

5. Cas d’utilisation « Ajouter Domaine »............................................................35

IV. Branche Technique...................................................................................................36

A. Architecture.........................................................................................................36

B. Outils...................................................................................................................36

Conclusion............................................................................................................................37

CHAPITRE IV : CONCEPTION.............................................................................................38

Introduction...........................................................................................................................39

I. Architecture Du Système..............................................................................................39

II. Etude Dynamique..........................................................................................................40

Conclusion............................................................................................................................42

CHAPITRE V : REALISATION ET TESTS...........................................................................43

Introduction...........................................................................................................................44

I. Réalisation.....................................................................................................................44

A. Environnement de travail....................................................................................44

1. Environnement matériel..................................................................................44

2. Environnement logiciel...................................................................................44

B. Difficultés rencontrées........................................................................................45

1. La puissance des équipements.........................................................................45

2. Installation.......................................................................................................45

3. Interopérabilité................................................................................................45

C. Chronogramme de réalisation du projet..............................................................45

II. Tests..............................................................................................................................47

Conclusion............................................................................................................................50

CONCLUSION GENERALE...................................................................................................51

WEBGRAPHIE........................................................................................................................52


vii


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


viii


LISTE DES TABLEAUXTableau 1 : Comparaison des solutions de supervision............................................................12Tableau 2 : Comparaison des solutions d'automatisation.........................................................16Tableau 3 : Comparaison des méthodologies de travail...........................................................19Tableau 4 : Schéma de la méthode 2TUP.................................................................................21Tableau 5 : Présentation des étapes..........................................................................................46


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.


INTRODUCTI

ON

2



PARTIE THEORIQUE

CHAPITRE I :

3


IntroductionDans 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.


CHAPITRE I :

4


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 EquipementsAcheter 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 EquipementsLors 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.

C. Interconnexion aux infrastructures existantesLa 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.


5


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échargeLes 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 tachesC’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

ConclusionNous 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.


6


IntroductionNous 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.


CHAPITRE II :

ETAT DE

L’ART

7


I. SupervisionA. 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. ButElle 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. CiblesLes 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

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.


http://fr.wikipedia.org/wiki/Astreinte

8


Les applications : Pour connaitre la disponibilité des services et des applications

hébergées par les serveurs.

3. MéthodesNous 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 existantesNous 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.

1. IcingaIcinga 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.


9


Figure 1 : Architecture d'Icinga

2. ShinkenShinken 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

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


http://fr.wikipedia.org/wiki/San_Francisco

http://fr.wikipedia.org/wiki/San_Francisco

http://fr.wikipedia.org/wiki/Nagios


http://fr.wikipedia.org/wiki/Preuve_de_concept


http://fr.wikipedia.org/wiki/Licence_publique_g%C3%A9n%C3%A9rale_Affero_GNU

http://fr.wikipedia.org/wiki/Surveillance

10


Figure 3 : Architecture de Splunk

4. Syes Of NetworkC’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

C. Comparaison et critique des solutionsPour 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

- Pas de graphes


11


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

- 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

- 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


12


A. PrésentationNous 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. ButLe 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. CiblesLes 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. PrincipeLes outils de gestion de configuration ont pour principe :

- Une architecture client/serveur.

- Le serveur dispose d’une configuration de référence.

- 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


13


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 solutionsNous allons juste présenter les trois outils d’automatisation les plus connus

1. PuppetC’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

2. ChefChef 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


14


3. CFEngineCfengine (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

C. Comparaison et critique des solutionsOUTILS AVANTAGES INCONVENIANTS

- Centralisation de la

configuration

- Télé déploiement des

configurations sur un

ensemble de serveurs

- Vérification

périodique des

configurations

- Problème de

déploiement

automatique

d’instance machine

- Supervision distante


http://fr.wikipedia.org/wiki/C_(langage)

http://fr.wikipedia.org/wiki/Gestion_de_configuration

15


- Support

multiplateformes

- Utilisation du SSL

- 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

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 :


- 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

16


Et nous développerons une interface web qui simplifiera le travail de l’administrateur.

IV. METHODOLOGIE DE TRAVAIL

1. ComparaisonBien 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.

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.

- Promu par

Rational ;

- Le RUP est à la

fois une

- Itératif ;

- Spécifie le

dialogue entre les

différents

- Assez flou dans

sa mise en

œuvre ;

- Ne couvre pas les


- 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

Figure 10 : Icône de Puppet

17


RUP (Rational

Unified Process)

méthodologie et

un outil prêt à

l’emploi ;

- Cible des projets

de plus de 10

personnes.

intervenants du

projet ;

- Propose des

modèles de

documents pour

des projets types.

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,

les plannings, les

prototypes.

- Plutôt superficiel

sur les phases

situées en amont

et en aval du

développement ;

- Ne propose pas

de documents

types.

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.

- Se base sur des

itérations dites

- Donne toute

confiance aux

- La mise en

œuvre du


18


Scrum

sprints de

développement.

développeurs et

les laisser faire

leur travail ;

- Chaque itération

a un objectif bien

précis et fournit

une

fonctionnalité

testée.

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

2. Choix de la méthodologie2TUP 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


19


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.

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


20


Tableau 4 : Schéma de la méthode 2TUP

ConclusionApres 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.

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.


21



PARTIE PRATIQUE

CHAPITRE III :

ANALYSE

22


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

- 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


CHAPITRE III :

ANALYSE

http://fr.wikipedia.org/wiki/Programmation_orient%C3%A9e_objet

http://fr.wikipedia.org/wiki/D%C3%A9veloppement_logiciel

http://fr.wikipedia.org/wiki/Pictogramme

http://fr.wikipedia.org/wiki/Langage

http://fr.wikipedia.org/wiki/Informatique

23


B. Les diagrammes comportementauxLes 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 dynamiquesLes 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.

Figure 12 : Interaction 2TUP - UML


24


II. Contexte StatiqueNous 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.

La figure ci-dessus permet de représenter les différents acteurs et leurs interactions avec

notre système.


25


SYSTEME

Adminsitrateur Utilisateur

Systèmes Auxiliaires

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

- Gérer Automatisation

- Gérer domaines


26


B. Besoins Non-FonctionnelsUne 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’UtilisationLes 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.

System

Adminsitrateur

Utilisateur

S'authentifier

Gerer Domaines

Gerer Utilisateurs

Superviser

<<include>>

<<include>>

<<include>>

Gerer Automatisation<<include>>

Figure 14 : Diagramme de cas d'utilisation global du système


27


System

Utilisateur

Ajouter Equipement

Supprimer Equipement

Modifier Equipement

S'authentifier

Generer RapportAfficher Graphe

Superviser

<<include>>

Adminsitrateur

Figure 15 : Diagramme détaillé du cas d'utilisation "Superviser"

System

Adminsitrateur

S'authentifier

Ajouter utilisateur

Supprimer Utilisateur

Modifier utilisateur

Gerer Utilisateurs

<<include>>

Figure 16 : Diagramme détaillé du cas d'utilisation "Gérer Utilisateurs"


28


System

Adminsitrateur

S'authentifier

Deployer Agent

Gerer Automatisation

Intégrer Agent

Intégrer Configurations

<<include>>

Figure 17 : Diagramme détaillé du cas d'utilisation "Gérer Automatisation"

System

Adminsitrateur

Ajouter Domaine

S'authentifier

Gerer Domaines

Supprimer Domaine

<<include>>

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.


29


D. Description Des Cas D’utilisationDans 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

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


30


Séquencement

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()

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

Post-conditions L’administrateur/l’utilisateur peut superviser l’équipement


31


ajouter

Le système actualise ses configurations et attend l’exécution

d’une autre action

Séquencement

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()

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



Scénario

Alternatif


Post-conditions Le nouvel utilisateur peut maintenant se connecter au système


32




Séquencement

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()


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



Scénario

Alternatif


Post-conditions L’équipement sur lequel a été déployé l’agent peut alors être


33


supervisé via l’agent qu’on vient de lui installer



Séquencement

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()


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


Scénario

Nominal

L’administrateur entre les paramètres du domaine à ajouter



Scénario

Alternatif


Post-conditions Tous les équipements du nouveau domaine peuvent maintenant


34


être supervisés.



Séquencement

Verification des parametre du domaineseq

[Test OK]

[Test pas OK]

[Test OK]

[Test pas OK]

: AdminsitrateurSysteme

1 : Saisi des parametres du domaine()


3 : Parametres OK()

4 : Message d'aquitement()5 : Mise a jour des Configurations()

6 : Parametres incorrects()


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. ArchitectureLes deux grands groupes d’architecture sont :


Figure 24 : Architecture Client-Serveur

- 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

35


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. OutilsLes différents outils que nous allons utiliser pour mener à bien notre projet sont :


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

- 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

36


ConclusionNous 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.


- VBS : C’est un langage qui nous permettra

d’effectuer des scripts de supervision très avancé sur

des clients Windows

CHAPITRE IV :

37


IntroductionDans 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.

I. Architecture Du SystèmeEtant 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.

PFSENSE

DMZ

Icinga Mast er192.168.22.1

LANMANagement

WinSer ver 2008192.168.11.1

INt er net

Admin192.168.0.1 Ecr an

Icinga SLAVE192.168.22.10

PUPPET MASTER192.168.22.50

PUPPET MASTER192.168.22.60

Figure 26 : Architecture complète de notre système


CHAPITRE IV :

38


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.

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


39



40


Figure 27 : Diagramme d'activité du système


UtilisateurAdministrateur

Authentification

Refus

SuperviserAjouter equipement

Gerer UtulisateuurGerer Autimatisation

Gerer Domaines

Supprimer Equipement

Modifier equipement

Afficher Graphes

Générer Rapport

Ajouter utilisateurModififer Utilisateur

Supprimer Utilisateur

Deployer Agent

Intégrer Configuration

Intégrer Agent

Ajouter Domaine

Supprimer Domaine

ValidationOK

Echec

41


ConclusionAyant 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.


42


IntroductionDans 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éalisationNous présenterons l’environnement de travail de matériel

et logiciel, puis le chronogramme des tâches effectuées.


CHAPITRE V :

REALISATION ET

TESTS

43


A. Environnement de travail1. 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 logicielVMware 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

EdrawMaw : Utilisé pour faire nos schémas

d’architectures.

B. Difficultés rencontréesLes principales difficultés que nous avons sont les suivantes

1. La puissance des équipementsDevant 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.


44


2. InstallationL’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 projetCi-dessous est détaillé le déroulement de notre projet

Numéro

sNom 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

supervision20 jours 26/02/14 25/03/14 4FS+4 jours

7 Etude comparative des solutions de

supervision7 jours 17/03/14 25/03/14 5FS+4 jours

8 Prise en main de la solution de

supervision choisie14 jours 28/03/14 16/04/14 7;6FS+2 jours

9Etude des méthodes et agents de

supervision14 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

globale3 jours 09/05/14 13/05/14 11

13 Configuration des serveurs 7 jours 14/05/14 22/05/14 12


45


secondaires de notre système

14 Intégration de plugins et d'outils

auxiliaires10 jours 26/03/14 08/04/14 7

15 Etude et comparaison des solutions

d'automatisation4 jours 17/04/14 22/04/14 8

16 Test de notre solution de

supervision finale60 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


19 Développement de l'interface

d'ajout de domaines2 jours 02/06/14 03/06/14

20 Développement de l'interface


21 Développement des scripts

d'arrière-plan de nos interfaces14 jours 13/06/14 02/07/14 20

Tableau 5 : Présentation des étapes

Figure 28 : Chronogramme d'avancement du projet


46


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

Figure 30 : Interface d'ajout d'un hôte


47


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.

Figure 32 : Interface d'importation des hôtes AD


Domaine :

Administrateur :

Mot de passe :

Adresse IP :

OK

48


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.

ConclusionAinsi 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.


OS :

Agent :

Adresse IP :

OK

49


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.


CONCLUSION GENERALE

50


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.

WEBGRAPHIE

(Ces liens ont été consultés pour la dernière fois le 01-07-2014 lors 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://blog.nicolargo.com/

http://www.tutorialarena.com/blog/run-shell-script-from-php.php

http://www.edcint.co.nz/checkwmiplus/

http://wiki.monitoring-fr.org/

http://www.microsoft.com/france/serveur-cloud/windows-server/comparer-editions.aspx

http://docs.icinga.org/

51


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)


https://wiki.icinga.org/display/howtos/Setting+up+Icinga+with+Reporting

http://fr.slideshare.net/wilfriedtiani/cacti-pnp

Education

PUPPET AND ICINGA WEB