Final Mem Oapi

UNIVERSITE DE YAOUNDE I UNIVERSITY OF YAOUNDE I
----- -----
ECOLE NATIONALE SUPERIEURE POLYTECHNIQUE NATIONAL ADVANCED SCHOOL OF ENGINEERING
----- -----
INSTITUT SUPERIEURE DE FORMATION AUX METIERS HIGHER INSTITUTE OF TRAINING IN
DES TELECOMMUNICATIONS, DE L”INNOVATION TELECOMMUNICATIONS, TECHNOLOGY INNOVATION,
TECHNOLOGIQUE, DE COMMERCE ET DE GESTION BUSINESS AND MANAGEMENT
Installation, Configuration et implémentation d’un outil de

monitoring réseau à l’aide d’une machine virtuelle avec
Nagios : Cas de l’O.A.P.I
Mémoire de fin d’études
Présenté et soutenu par :

MBELE ABANDA Alejandra Sonia Claude Arielle
En vue de l’obtention du
Master en management des systèmes d’informations
Sous l’encadrement de :
Encadreur professionnel : Encadreur académique :
Ing. Hervé KAMGA TCHOUANGOU Ing. Steve MABATTO
Année académique : 2022 – 2023

Installation, configuration et implémentation d’un outil de monitoring réseau au sein de l’O.A.P.I
Dédicaces
Je dédie ce travail :
A mes chers parents,
Qui n’ont jamais cessé de formuler des prières à mon égard, de me soutenir et de m’épauler pour
que je puisse atteindre mes objectifs.
2
Rédigé par MBELE ABANDA Alejandra Sonia Claude Arielle
Remerciements
Je tiens à remercier toutes les personnes qui ont contribué au succès de ce projet et qui m’ont
aidée lors de la rédaction de ce mémoire.
D’entrée de jeu, je remercie le Directeur Général de l’O.A.P.I. Monsieur Denis L. BOHOUSSOU

pour m’avoir accordé ce stage au sein de l’O.A.P.I.
Ainsi, souhaiterai-je remercier, mes encadreurs académiques et professionnels : Ing. MABATTO

Steve, Dr. EKOBO Brice, Ing KAMGA Hervé, M. DJENARBE Narcisse, M. KENNE Aurélien, M.
TCHINDA Armand pour leur patience, leur disponibilité et surtout leurs judicieux conseils, qui ont
contribué à alimenter de ma réflexion. La liste étant non exhautive, je remercie particulièrement
tous ceux qui de près ou de loin ont su apporter de l’expertise dans ce travail de longue haleine.
Aussi, je remercie toute l’équipe pédagogique de l’IFTIC-SUP, de l’ENSP et les intervenants

professionnels que j’ai sollicités tout au long de ce projet.
Je tiens également à témoigner toute ma reconnaissance aux personnes suivantes, pour leurs
aides dans la réalisation de ce mémoire :
- Mes parents, pour leur soutien constant et leurs encouragements,

- M. SUGEWE TCHENDJOU Harold Franck, Ingénieur Polytechnicien en génie électrique et
systèmes intelligents pour son omniprésence dès le début de ce projet et ses
encouragements innombrables,
- Mes camarades de promotion de l’année académique 2022/2023,
- Mes camarades et amis qui, de près ou de loin ont su fournir une indéniable plus-value à
ce bourgeonnement de travail,
- Ma co-stagiaire Alix Christelle Pideu pour son indéfectible soutien et assistance au cours
des travaux inhérents à ce mémoire.
3
Glossaire
Terme Définition
Activité Suite d'actions réalisées par un système. Le diagramme d'activité
représente ces actions pour une entité donnée, avec peu de prise en
compte des communications.
Alignement Démarche de fond consistant à redessiner la stratégie générale de
Stratégique l'entreprise et la stratégie de développement des technologies de
l'information afin qu'elles soient en parfait accord.
Application Ensemble logiciel cohérent, qui a pour objectif la réalisation d'un ensemble
de tâches donné.
Analyse Etude de la situation devant donner lieu à la réalisation d'un support
informatique. C'est classiquement la première étape du cycle de vie logiciel
Analyste Personne chargée, dans un projet logiciel, de l'analyse des besoins et de
leur formalisation
Audit Analyse et une évaluation des systèmes, infrastructures, politiques et opérations
informatique informatiques.
Big Data Analyse et une évaluation des systèmes, infrastructures, politiques et opérations
informatiques.
Brevet Selon l'Accord de Bangui, le brevet est un titre délivré pour protéger une invention.
Il confère à son titulaire un droit exclusif d'exploitation de l'invention.
Bug Erreur dans une programme, entraînant un comportement no prévu et
indésirable de celui-ci
Caas Service basé dans le cloud qui permet aux développeurs de logiciels ainsi qu'aux
(Containers as a services informatiques d'importer, d'organiser, d'exécuter, de faire évoluer et de

Service) gérer des conteneurs à l'aide de la virtualisation basée sur conteneur.
Cas d’Utilisation Situation donnée dans laquelle un utilisateur utilise un système
4
informatique.
Cloud Terme qui désigne les services hébergés fournis par un prestataire, accessibles par
Computing Internet sans que le client ne sache exactement où se trouvent physiquement les
matériels et les logiciels qu'il utilise.
Composant Brique de fabrication d'un système informatique. Un composant peut être
une classe, un ensemble de classes, un fichier, une base de données, etc.
Dans le cadre de la programmation orientée composant, qui étend la
programmation orientée objet, un composant est une unité de service et de
déploiement de code, qui contient souvent plusieurs classes.
Conception Réalisation d'une vue abstraite sur un système.
Contexte Informations de l'environnement ayant un impact sur l'exécution d'un

logiciel.
Cycle de vie Ensemble des étapes indispensables à la réalisation d'un logiciel, de
l'analyse des besoins à la livraison et à la maintenance.
Déploiement Phase d'un projet logiciel lors de laquelle l'application finie est chargée sur
les machines de production, installée, et démarrée.
Développement Codage d'une application.
Domaine Ensemble des caractéristiques spécifiques à une partie d'un logiciel
(modélisation des données, traitement, génération de page web), où à un
contexte précis (applications médicales, bancaires, etc.).
Domaine Ensemble d’équipements reliés dans un réseau (local ou public) et
(Au sens réseau) possédant une caractéristique commune.
Encapsulation Fait de masquer l'accès aux données d'une classe, en permettant l'accès par
le biais de méthodes seulement.
ERP Type de logiciel que les entreprises utilisent pour gérer leurs activités quotidiennes
telles que la comptabilité, les achats, la gestion de projets, la gestion des risques et
la conformité, ainsi que les opérations de supply chain.
Erreur Cause d'un ou plusieurs incidents.
5
Condition sous-jacente qui pourrait avoir des impacts négatifs sur le service
et qui doit donc être traité.
Evènement Occurrence d'une action identifiée, qui peut avoir des conséquences sur
l'environnement.
Etat Valeur des attributs d'un système.
Formulaire Document d’enregistement
Framework Parfois traduit par 'cadriciel'. Un Framework est :
1. Un ensemble de classes permettant de réaliser un type d'application
donné (par exemple des classes utiles dans le domaine médical)
2. Un ensemble de méthodes qui permettent de réaliser un type
d'applications donné.
Génération Possibilité de créer des applications à partir de modèles abstraits. On parle
alors de génération de code.
Gouvernance des Cadre formel visant à développer les technologies de l'information en
systèmes accord avec les objectifs globaux et la stratégie de l'entreprise.
d’information
Iaas Forme de cloud computing où l'infrastructure informatique est fournie aux
utilisateurs finaux sur Internet
Incident Tout événement qui ne fait pas partie du fonctionnement standard d'un
service et qui cause, ou peut causer, une interruption ou une diminution de
la qualité de ce service
événement unique non planifié qui provoque une interruption de service.
ITIL Ensemble de bonnes pratiques de management d'un service informatique
dans le but d'optimiser l'utilisation des ressources informatiques
ISO (Norme) Ensemble de normes internationalement reconnues qui ont été créées dans
le but d'aider les entreprises à établir des niveaux d'homogénéité en
matière de gestion, de prestation de services et de développement de
produits dans le secteur industriel.
6
Logiciel Software.
Partie modifiable d'un système informatique, par opposition au Hardware,
le matériel, qui ne peut être modifié que par substitution de parties
physiques.
Management des Discipline qui se concentre sur la gestion et l’utilisation efficace des
systèmes technologies de l’information (TI) au sein d’une entreprise ou d’une
d’information organisation impliquant la planification, la mise en œuvre et la gestion des
systèmes d’information et des technologies connexes, telles que les
réseaux, les bases de données, les applications et les systèmes de sécurité.
Mandataire Personne chargée d'assurer la représentation d'une tierce personne, (particulier

personne physique ou société personne morale), son « mandant », notamment
devant les Offices de propriété intellectuelle, afin d'effectuer les formalités et
actes nécessaires à l'acquisition ...
Modèle Représentation abstraite d'un système, d'une situation.
Modélisation Représentation d'une situation, d'un système de manière abstraite, afin de
faciliter l'étude et/ou la réalisation de cette situation, ce système.
Monitoring Surveillance informatique
Paas Environnement de développement et de déploiement complet dans le
cloud, avec les ressources nécessaires pour vous permettre de fournir
n'importe quel service, de la simple application cloud aux applications
d'entreprise sophistiquées.
Problème Défaillance d’un équipement
Processus Recueil de bonnes pratiques visant à améliorer le management des services
ITIL informatiques
Progiciel Ensemble de logiciels munis d'une documentation, conçus pour répondre à des
besoins spécifiques et permettre une utilisation autonome.
Propriété Outil de lutte contre la contrefaçon ou le plagiat, la propriété intellectuelle
7
intellectuelle permet à l'auteur d'une création de protéger son œuvre et de lui octroyer
les avantages issus de son œuvre.
Elle se penche sur les œuvres de l'esprit : inventions; œuvres littéraires et
artistiques; dessins et modèles; et emblèmes, noms et images utilisés dans
le commerce.
Prototype Version d'un système dont le principe est conforme au système final, mais
dont les fonctionnalités sont réduites.
Séquence Suite ordonnée de messages échangés entre plusieurs objets
Services Ensemble des moyens mis en œuvre pour produire de la valeur pour un
client, sans que celui-ci n'en supporte ni les coûts spécifiques et
supplémentaires ni les risques associés
Spécifications Représentation formelle ou semi-formelle des caractéristiques d'un
système. Les spécifications servent de référence lors des tests de
l'application, et lors de la recette.
Système Terme désignant une unité de conception et d'exécution informatique. Un
système peut être un serveur, une plate-forme d'application, une
application, en fonction du point de vue qu'en a le développeur, ou
l'utilisateur.
Système Ensemble organisé de ressources qui permet de collecter, stocker, traiter et
d’information distribuer de l'information, en général grâce à un réseau d'ordinateurs
Test Procédure formalisée de validation d'une fonctionnalité, ou d'un ensemble
de fonctionnalités, d'un logiciel. Les tests sont réalisés en fonction des
spécifications du système.
Ticket Message d’alerte transmis d’un utilisateur à un autre
Titre Intitulé d’une marque ou œuvre
Transition Passage d'un état à un autre du système.
UML « Unified Modeling Language », langage de modélisation générique qui
permet de représenter, par différents diagrammes, différentes vues sur le
8
système à concevoir.
Virtualisation Technologie que vous pouvez utiliser pour créer des représentations
virtuelles de serveurs, de stockage, de réseaux et d'autres machines
physiques
Veille Processus de collecte, d'analyse et de diffusion des informations relatives à
technologique un domaine technologique spécifique
Workflow Modélisation des processus métiers et la gestion des processus métiers
9
Liste des sigles et abréviations
ARIPO : African Regional Intellectual Property Organization
BAR : Bureau d’Accueil et de renseignement
CIB : Classification Internationale des Brevets
DAJ : Direction des affaires juridiques
DBCT : Direction des Brevets et autres techniques
DMSD : Direction des marques et des signes distinctifs
DSIP : Direction des systèmes d’information et de la publication
DPC : Direction de la prospective et de la coopération
DFP : Direction des finances et du patrimoine
DG : Directeur général
DGA : Directeur général adjoint
INPI : Institut National de la propriété intellectuelle
OAPI : Organisation Africaine de la Propriété intellectuelle
OAMPI : Office Africain et Malgache de Propriété Intellectuelle
OMPI (WIPO en anglais): Organisation Mondial de la propriété intellectuelle
OEB : Organisation européenne des Brevets
10
Table de Matières
DEDICACES ................................................................................................................................................................. 2
REMERCIEMENTS ....................................................................................................................................................... 3
GLOSSAIRE ................................................................................................................................................................. 4
LISTE DES SIGLES ET ABREVIATIONS.......................................................................................................................... 10
TABLE DE MATIERES ................................................................................................................................................. 11
RESUME.................................................................................................................................................................... 14
ABSTRACT................................................................................................................................................................. 15
LISTE DES FIGURES ET TABLEAUX .............................................................................................................................. 16
INTRODUCTION GENERALE ....................................................................................................................................... 18
CHAPITRE 1 : CONTEXTE ET PROBLEMATIQUE .......................................................................................................... 21
PARTIE 1 : PRESENTATION DE L’OAPI ................................................................................................................................... 21
1.1. Historique de l’O.A.P.I. ................................................................................................................................ 21
1.2. Missions de l’O.A.P.I. .................................................................................................................................. 25
1.3. Organisation de l’O.A.P.I. ........................................................................................................................... 26
PARTIE 2 : PRESENTATION DE LA DIRECTION DES SYSTEMES D’INFORMATION ET DE LA PUBLICATION .................................................. 30
2.1. Missions de la D.S.I.P .................................................................................................................................. 30
2.2. Organisation de la D.S.I.P ........................................................................................................................... 30
PARTIE 3 : LA GOUVERNANCE IT AU SEIN DE L’OAPI ................................................................................................................ 33
• La gestion du parc informatique par la méthode ITIL ..................................................................................... 33
PARTIE 4 : TACHES EFFECTUEES LORS DU STAGE ...................................................................................................................... 39
4.1. Application web du restaurant ou de la cantine ......................................................................................... 39
4.2. Assistance dans les travaux de configuration menée par le prestataire C.F.A.O ........................................ 44
4.3. Maintenance préventive dans les locaux de l’O.A.P.I. ................................................................................ 45
4.4. Autres interventions dans le cadre informatique ....................................................................................... 45
4.5. L’implémentation de Nagios à l’aide des équipements et du réseau local de l’O.A.P.I .............................. 46
4.6. Régénération des certificats du BOPI (Bulletin Officiel de la Propriété Industrielle) à l’aide de l’outil de
gestion ipas .............................................................................................................................................................. 46
PARTIE 5 : PRESENTATION DU PROJET ................................................................................................................................... 47
5.1. Aperçu du projet ............................................................................................................................................... 47
5.2. Description du contexte .................................................................................................................................... 47
5.3. Critiques sur l’existant : Application concurrente à Nagios .............................................................................. 54
5.4. Problématique .................................................................................................................................................. 55
5.5. Hypothèse ......................................................................................................................................................... 55
5.6. Point de mire du travail .................................................................................................................................... 56
5.7. Choix et intérêt du sujet .................................................................................................................................... 56
5.8. Délimitation du sujet......................................................................................................................................... 56
5.9. La portée du travail ........................................................................................................................................... 56
5.10. Les parties prenantes ...................................................................................................................................... 58
5.11. Contraintes obligatoires.................................................................................................................................. 58
CHAPITRE 2 : CAHIER DE CHARGE ............................................................................................................................. 61
11
2.1. PRESENTATION ET OBJECTIFS DE NAGIOS .................................................................................................................. 61

En résumé ................................................................................................................................................................ 65
2.2. FONCTIONNEMENT DE NAGIOS ............................................................................................................................... 65
2.3. AVANTAGES ET INCONVENIENTS DE NAGIOS .............................................................................................................. 69
2.4. QUELLES SONT LES ALTERNATIVES A NAGIOS ? ........................................................................................................... 71
2.5. EXPRESSIONS DES BESOINS DE L’UTILISATEUR ............................................................................................................. 71
2.5.1. Réseau à superviser ................................................................................................................................ 71
2.5.2. Règles sur le réseau ................................................................................................................................ 71
2.5.3. Fonctionnement technique..................................................................................................................... 72
2.5.4. Choix d’une machine virtuelle ................................................................................................................ 73
2.5.5. Choix de Linux ......................................................................................................................................... 75
2.5.6. Installation et configuration des équipements ....................................................................................... 75
2.6. CIBLES ET BENEFICIAIRES ........................................................................................................................................ 76
2.7. EXIGENCES DU PROJET........................................................................................................................................... 76
2.7.1. Exigences fonctionnelles......................................................................................................................... 76
2.7.2. Exigences techniques.............................................................................................................................. 77
2.7.3. Exigences en matière de données .......................................................................................................... 77
2.7.4. Exigences de performances .................................................................................................................... 77
CHAPITRE 3 : METHODOLOGIE DE TRAVAIL .............................................................................................................. 79
3.1. POURQUOI OPTER POUR L’USAGE DES METHODES AGILES ? .......................................................................................... 79
3.2. CHOIX DE LA METHODE AGILE UTILISEE : SCRUM ....................................................................................................... 80
3.2.1. Principe de SCRUM ................................................................................................................................. 80
3.2.2. Phases préliminaires du projet ............................................................................................................... 81
3.2.3. Phases d'études ...................................................................................................................................... 83
3.2.4. Phases de réalisation .............................................................................................................................. 85
3.2.5. Phases post-production .......................................................................................................................... 86
CHAPITRE 4 : REALISATION, RESULTATS ET DISCUSSIONS ......................................................................................... 88
4.1. PRÉSENTATION DU CHAMP DE TRAVAIL ..................................................................................................................... 88
4.1.1. Matériel, plugins et agents utilisés ................................................................................................................ 88
4.1.2. Objectifs de conception.................................................................................................................................. 89
4.1.3. Interface Utilisateur (Frontend) ..................................................................................................................... 89
4.1.4. Environnement de mise en œuvre du système actuel .................................................................................... 89
4.1.5. Logiciels additionnels utilisés ......................................................................................................................... 90
4.2. NAGIOS CORE ..................................................................................................................................................... 90
4.2.1. Installation de Nagios Core sur votre serveur Debian .................................................................................... 90
4.2.2. Téléchargement et compilation des sources de Nagios ................................................................................. 93
4.2.3. Installation de l’arborescence et des fichiers Nagios sur votre serveur ......................................................... 98
4.2.4. Connectons-nous une première fois à l’interface d’administration de Nagios ............................................ 102
En résumé .............................................................................................................................................................. 104
4.2.5. Préparation du serveur Debian à recevoir les plugins standards de Nagios ................................................ 104
4.2.6. Téléchargement et compilation les sources des plugins standards de Nagios ............................................ 105
En résumé .............................................................................................................................................................. 112
4.2.7. Présentation des répertoires de Nagios ....................................................................................................... 113
4.2.8. Maîtrisez les principales directives du fichier de configuration de Nagios .................................................. 115
En résumé .............................................................................................................................................................. 118
4.2.9. Configuration de Nagios .............................................................................................................................. 118
12
4.2.9.1. Les plugins................................................................................................................................................. 119

4.2.9.2. Les commandes......................................................................................................................................... 120
4.2.9.3. Les hosts.................................................................................................................................................... 121
4.2.9.4. Les services ............................................................................................................................................... 122
4.2.9.5. Notre première configuration ................................................................................................................... 124
En résumé .............................................................................................................................................................. 127
4.3. NAGIOS XI ........................................................................................................................................................ 128
4.3.1 Installation de Nagios XI ............................................................................................................................... 128
4.3.2. Configuration de Nagios XI .......................................................................................................................... 129
4.3.3. Aperçu général de la page d’accueil de Nagios XI ....................................................................................... 132
4.4. LE TOUR DU PROPRIETAIRE : NAGIOS ..................................................................................................................... 133
4.4.1. Aperçu général et description explicative de la page d’accueil de Nagios Core .......................................... 134
4.4.2. Exploitation des outils système de l’interface d’administration .................................................................. 144
4.4.3. Configuration pas-à-pas d’un monitoring réseau d’une machine sous Windows via le protocole SNMP sous
Nagios XI. ............................................................................................................................................................... 153
En résumé .............................................................................................................................................................. 159
4.5. DIFFICULTES RENCONTREES .................................................................................................................................. 159
CONCLUSION GENERALE ET PERSPECTIVES ..............................................................................................................161
REFERENCES BIBLIOGRAPHIQUES ............................................................................................................................162
A. OUVRAGES ................................................................................................................................................................ 162
B. WEBOGRAPHIE ........................................................................................................................................................... 162
13
Résumé
Dans un monde à propension digital, dans lequel l’outil informatique n’est plus une alternative
mais une nécessité, il revient d’une grande importance de se pencher non seulement sur le volet
managérial mais aussi technique des systèmes d’information. La même dynamique est d’ailleurs
corroborée au sein de l’O.A.P.I qui met au cœur de ses activités une direction des systèmes
d’information et de la publication (D.S.I.P) touchant du doigt chaque autre direction. Ainsi, cette
quasi-omniprésence de l’informatique n’est plus juste une aubaine mais aussi un enjeu dans la
mesure de la sécurité, de la gouvernance et de la prise en main de ce maillon central dans la
circonscription du domaine local (interne) et externe.
Toutefois, l’on ne saurait parler de domaine informatique en omettant son noyau qui n’est rien
d’autre que le réseau. Dès lors, sécuriser, gouverner et prendre en main le réseau devient une
primordialité tacite au sein de l’organisation. C’est ainsi que, sous le déploiement des principes
directeurs de la bonne gouvernance fournis par la méthode ITIL, nous nous sommes attelés à
plusieurs tâches au cours de ce stage que nous détaillerons dans la suite et plus particulièrement à
ce projet dont le but fut d’implémenter un logiciel de monitoring réseau afin de superviser chaque
équipement lié au réseau local de l’organisation. Ce projet a touché du doigt 06 bonnes pratiques
de la gestion des services notamment : la gestion de la sécurité de l’information, la gestion des
incidents, la gestion des problèmes, la gestion des actifs informatiques, la gestion des
changements, la gestion de la configuration des services et la gestion des demandes de services.
Compte tenu du panel riche de logiciels de management du système d’information, Nagios a su
apporter sa plus-value notoire dans la supervision du parc informatique.
Mots-Clés : Propriété intellectuelle, Gestion des incidents, Monitoring réseau, Nagios, Système
d’information, Domaine, sécurité informatique.
14
Abstract
In a world with a digital propensity, in which the IT tool is no longer an alternative but a necessity,
it is greatly important to look not only towards managerial but also technical aspects of
information systems. The same dynamic is corroborated within the O. A.P.I. which puts at the
heart of its activities an Information Systems Department (D.S.I.P) touching each other direction.
Thus, this quasi-omnipresence of IT is no longer just a boon but also an issue in the measurement
of security, governance and the handling of this central link in the constituency of the local
(internal) and external domain.
However, we cannot speak of a computer domain by omitting its core, which is nothing other than
the network. From then on, securing, governing and taking control of the network becomes a tacit
paramount within the organization. Thus, under the deployment of the guiding principles of good
governance provided by the ITIL method, we tackled several tasks during this internship that we
will detail later and more particularly this project whose goal was to implement network
monitoring software to supervise each equipment related to the local network of the organization.
This project touched on 06 service management best practices including: information security
management, incident management, problem management, IT asset management, change
management, service configuration management and service request management. Given the rich
range of information system management software, Nagios has been able to bring its notorious
added value in the supervision of the computer park.
Keywords: Intellectual property, Incident management, Network monitoring, Nagios, Information

system, Domain, IT security.
15
Liste des figures et tableaux
Figure 1 : Organigramme de l’O.A.P.I. 29

Figure 2 : Image d’un extrait de la plateforme des logiciels de gestion des processus
métiers informatiques au sein de l’O.A.P.I. 33
Tableau 1 : Liste des processus du « Service Support » d’ITIL implémenté au sein de
l’O.A.P.I. 35
Tableau 2 : Liste des processus du « Service Delivery » d’ITIL implémenté au sein de
l’O.A.P.I. 35
Figure 3, 4, 5 : Présentation de la plateforme Web conçue pour le restaurant de l’O.A.P.I
42
Figures 6,7 : Présentation de la zone d’authentification du personnel de l’O.A.P.I. pour la
plateforme du restaurant. 43
Figure 8 : Exemple d’architecture réseau reconçu par nous, les stagiaires. 45
Figures 9, 10, 11, 12, 13, 14, 15, 16 : Vue globale de la plateforme de gestion des
incidents G.L.P.I. 52
Figure 17 : Aperçu de la plateforme iPas. 53
Figure 18 : Diagramme du contexte de travail 57
Tableau 3 : Liste des contraintes obligatoires 58
Figure 19 : Interface d’accueil de Nagios XI 61
Figure 20 : Vue panoramique des hôtes, services et autres fonctionnalités 66
Figure 21 : Choix des services lors de la configuration d’un hôte 67
Figure 22 : Présentation des informations de l’administrateur 68
Figure 23 : Vue stratégique sur les hôtes, les services opérationnels et les ressources dans
Nagios XI 69
Figure 25 : Vue statistique et globale sur les performances de tous les équipements
réseau enregistrés 71
Figure 26 : Schématisation des règles du réseau dans Nagios 72
Figure 27 : Configuration d’un routeur 76
Figure 28 : SCRUM Process 80
Tableau 4 : Matériels, plugins et agents utilisés 89
Figure 29 : Etape d’installation de serveurs essentiels pour Debian 91
Figure 30 : Présentation du site web Nagios favorisant le téléchargement du VmWare ou
de la version Linux, Microsoft de Nagios 94
Figure 31 : Vue de l’interface d’accueil du guide d’installation de Nagios Core. 95
Figure 32 : Vue de l’interface après téléchargement 96
16
Figure 33 : Interface du VMWare Nagios dans l’hyperviseur VMWare Workstation 128

Figure 34 : Etape 1 de la configuration de Nagios XI 129
Figure 35 : Etape 2 de la configuration de Nagios XI 130
Figures 36, 37, 38, 39 : Etapes finales de la configuration de Nagios XI 130
Figures 40, 41 : Page d’accueil de Nagios XI 133
Figure 42 : Page de l’interface d’administration de Nagios Core dans le navigateur de la
machine virtuelle Debian 134
Figure 43 : Exemple d'architecture supervisée 137
Figure 44 : Détails d'un objet Host. 140
Figure 45 : Commander un check immédiat sur l'objet 141
Figures 46, 47, 48, 49, 50, 51, 52, 53, 54 : Configuration pas-à-pas d’un monitoring réseau
d’une machine sous Windows via le protocole SNMP 159
17
Introduction générale
La gouvernance IT occupe une place importante dans toute organisation ou entreprise. Elle repose
sur cinq principaux piliers que sont : l’alignement stratégique, la création de la valeur, la gestion
des ressources, la gestion des risques, la gestion des performances. Ses trois principaux objectifs
sont : La maîtrise des coûts, la maîtrise des risques, la maîtrise de la qualité des systèmes
d’information. La supervision informatique sous-tend le bon fonctionnement d’un système ou
d’une activité et porte sur la surveillance de manière continue ou discontinue de la disponibilité
des services en ligne, du fonctionnement, des débits, de la sécurité, mais également du contrôle
des flux. Elle permet de surveiller, rapporter et alerter les fonctions normales et anormales du
système informatique en répondant à plusieurs préoccupations, soient techniques, soient
applicatives ou métier. En cas de disfonctionnement, le système de supervision permet d’envoyer
les messages sur la console de supervision ou d’envoyer un courriel à l’opération à une fréquence
prédéfinie.
Mais que gouverne-t-on en particulier ?
Le parc informatique d'une organisation est un assemblage, parfois hétéroclite de matériels et de

logiciels accumulés tout au long des années. On y trouve des :
- Matériels différents (téléphones, portables, pc, imprimantes, éléments d'interconnexions,

etc.) qui peuvent être de plusieurs générations ;
- Logiciels et systèmes d’exploitation variés (Linux, Windows, Mac OS, etc.) ;
- Applications utilisées dans différentes versions ;
- Niveaux de sécurité disparates.
De plus, la quantité de matériels et de logiciels à gérer, leur éclatement au sein de l'organisation

souvent très étendue dans l'espace, les exigences de performance et de réactivité font que la
gestion de parc est devenue un processus global, complet et indispensable. Cette activité de
18
gestion de parc informatique est décrite dans le processus ITIL1 Gestion des configurations. Ainsi,
la gestion du parc informatique recouvre non seulement la fonction d'inventaire de ces éléments
mais aussi celles concernant le suivi et l'évolution :
- La gestion de l'emplacement du matériel ;

- La gestion des partenaires (fabricants, fournisseurs, transporteurs, prestataires...) et des
contacts associés ;
- La gestion des contrats (prêt, location, leasing, assurance, maintenance et prestation) ;
- La gestion des licences logiciels ;
- Le télé-déploiement de logiciels ;
- La gestion financière des éléments d'inventaire (matériel loué ou acheté, amortissement) ;
- La gestion du cycle de vie de chaque élément ;
- La gestion des incidents ;
- La gestion de la documentation informatique (base de connaissance, FAQ, etc.) ;
- La gestion statistique (nombre d'interventions, coût des consommables, etc.) ;
- La prévision des besoins (aussi bien matériel, logiciel que de formation en exploitant
notamment les résultats statistiques de la gestion de parc).
Toute initiative de supervision nécessite par conséquent un audit du système, notamment une
analyse approfondie de l’état des services et équipements du réseau. Dans cette optique, Nagios
est une application permettant la surveillance système réseau et surveille les hôtes et services
spécifiés alertant lorsque les systèmes ont des disfonctionnements et quand ils repassent en
fonctionnement normal. C’est un programme qui se décompose en trois parties : le moteur de
l’application qui vient ordonnancer les tâches de supervision, l’interface web qui permet d’avoir
une vue d’ensemble du système d’information et des possibles anomalies, les plugins qui sont une
centaine de mini-programmes que l’on peut compléter en fonction des besoins de chacun pour
superviser chaque service et ressources disponibles sur l’ensemble des ordinateurs connectés au
réseau du système d’information.
Hormis l'introduction et la conclusion, notre travail s’articulera en cinq chapitres, à savoir :
19
• Chapitre 1 : Contexte et problématique

• Chapitre 2 : Cahier de charge
• Chapitre 3 : Méthodologie de travail
• Chapitre 4 : Réalisation, résultats et discussions
20
Chapitre 1 : Contexte et problématique
Partie 1 : Présentation de l’OAPI
1.1. Historique de l’O.A.P.I.
L'Organisation Africaine de la Propriété Intellectuelle (OAPI), a été créée par l'Accord de Bangui du 02 mars
1977 constituant révision de l'Accord de Libreville du 13 Septembre 1962.
L'OAPI doit sa création à la volonté des Etats membres de protéger sur leur territoire les droits de propriété
intellectuelle d'une manière aussi efficace et uniforme que possible.
En matière de propriété intellectuelle tel que stipule l'accord de Bangui en son article 2, l'OAPI a pour
objectif de mettre en œuvre les procédures administratives communes découlant d'un régime uniforme de
protection de la propriété industrielle ainsi que des stipulations des conventions internationales auxquelles
les Etats membres font partis.
Ainsi l'organisation constitue pour chacun de ses Etats membres l'Office National en matière de propriété
industrielle et, à ce titre, administre et gère entre autres titres, la protection des noms commerciaux qui
sont les dénominations sous lesquelles sont connues et exploiter les établissements commercial,
industriels, agricole ou artisanal. Le nom commercial appartenant à celui qui, le premier, en fait usage ou
en a obtenu l'enregistrement. Seuls les noms commerciaux enregistrés pouvant faire l'objet de sanction.
L'OAPI gère également la protection des dessins et modèles industriels. Ces derniers sont des aspects
ornementaux ou esthétiques d'un objet industriel qui peuvent résider dans la forme, la composition ou la
couleur de l'objet qui doit être susceptible d'être reproduit par des procédés industriels ou artisanaux.
Les objets couverts par les accords de Bangui sont :
- Les brevets d'invention ;
- Les modèles d'utilité
21
- Les dessins et modèles industriels,
-Les noms commerciaux
- Les appellations d'origine
- Les marques de produits et de services
- Les obtentions végétales ;
-La propriété littéraire et artistique.
Le siège de l'OAPI est basé au Cameroun, plus précisément à Yaoundé, capitale politique.
Pour accéder aux différents services offerts par I'OAPI, il suffit de s'adresser :
1. Soit directement à la Direction Générale de l'OAPI

2. BP : 887 Yaoundé — Cameroun
Tel : (237) 2220 57 OO / 2220 39 11
Fax : (237) 2220 57 27/ 2220 57 21
E-mail : oapi.oa@oapi.oa.wipo.net-
Site Web : http://www.oapi.wipo.net, http://www.oapi.int
3. Soit aux structures nationales de liaison (SNL) placée sous la tutelle des Ministères en charge de
l'industrie dans les états membres.
a) De l'OAMPI à l'OAPI
Jusqu'en 1962, la propriété industrielle dans la plupart des Etats francophones membres de l'OAP1, était
régie par les lois françaises. L'institut National Français de la Propriété Industrielle (INPI) était l'office
National de chacun de ces Etats regroupés alors au sein de l'union Française.
Vu la majorité des pays membres de I’Union Française, ayant accédé à l'indépendance en 1960, il s'est
avéré nécessaire de créer une structure sur leur territoire respectif dans le respect des conventions
internationales en matière de propriété industrielle.
22
Cette création a trouvé son fondement juridique dans l'article 19 de la convention de Paris pour la
protection de la propriété industrielle qui dispose que les pays, faisant partie à cette convention, se
réservent le droit de prendre séparément entre eux, des arrangements particuliers pour la protection de la
propriété industrielle autant que ces arrangements ne contreviennent pas aux dispositions de ladite
convention.
C'est sur la base de cette disposition que 12 pays de l'Afrique francophone ont décidé ensemble de créer
une structure commune agissant en tant que Office National de propriété industrielle (OAMPI) vit ainsi le
13 Septembre 1962 par l'accord connu sous le nom « Accord de Libreville ».
b) L'Accord de Libreville
Le régime de l'accord de Libreville était fondé sur trois principes fondamentaux :
- L'adoption d'une législation uniforme par la mise en oeuvre et l'application des procédures
administratives communes découlant d'un régime uniforme de la propriété industrielle
- La création d'un office commun car l'organisation tient lui pour chacun des Etats de service national
de la propriété industrielle
- La centralisation des procédures par l'existence d'une législation uniforme et d'un office commun
appelé tout naturellement la centralisation des procédures de telle sorte qu'un seul titre délivré se
scindait en autant de droits nationaux indépendants que des pays membres.
Sur le plan de compétence territoriale, l'Accord de Libreville couvrait des territoires des pays Africains
d'expression et de mouvances françaises.
S'agissant de la compétence matérielle, les objets régis par l'Accord de Libreville du 13 Septembre 1962
couvraient les brevets d'inventions, les marques de fabrique ou de commerce les dessins ou modèle
industriel. Les pays signataires de l'Accord de Libreville étaient les suivants :
1. République fédérale du Cameroun,
2. République Centrafricaine ;
3. République du Congo,
23
4. République de la Cote d'ivoire,
5. République du Dahomey ;
6. République de la Haute Volta ;
7. République de la Mauritanie ;
8. République Gabonaise ;
9. République du Sénégal ;
10. République du Tchad ;
11. République Malgache ;
12. République du Niger ;
c) L’accord de BANGUI
Le retrait de la République Malgache pour des raisons de souveraineté, le souci de couvrir tous les objets
de la propriété intellectuelle notamment les modèles d'utilité, les noms commerciaux , les marques de
produits et de service, le souci de mieux impliquer la propriété intellectuelle dans le développement,
l'ambition d'être le noyau d'une intégration plus large, ont amené les Etats fondateurs à réviser l'Accord de
Libreville et à créer l'Organisation Africaine de la propriété Intellectuelle (OAPI) par l'adoption d'une
nouvelle convention signée à Bangui le 2 Mars 1970. L’accord de Bangui, portant révision de l'accord de
Libreville, légifère désormais la propriété industrielle dans chacun des 16 Etats membres qui forme
actuellement l'espace OAPI. Ces 17 Etat membres sont :
1. Bénin
2. Burkina-Faso
3. Cameroun
4. Centrafrique
6. Cote d'ivoire
24
7. Gabon
8. Guinée
9. Guinée Bissau
10. Mali
11. Mauritanie
12. Niger
13. Sénégal
15. Tchad
16. Togo
17. Congo
1.2. Missions de l’O.A.P.I.
En matière de propriété intellectuelle, l’OAPI a pour missions entre autres, de mettre en œuvre les
procédures administratives communes découlant du régime uniforme de la protection de la propriété
industrielle ainsi que des stipulations des conventions internationales en ce domaine auxquelles les Etats
membres ou l'OAPI.
L'OAPI a pour missions :
a) Missions de délivrance
La mission traditionnelle d'un office de propriété industrielle telle que l'OAPI est naturellement
l'enregistrement et la délivrance des titres, selon une de procédure l'accord commune de BANGUI et
d’autres textes règlementaires tels que les annexes, les instructions règlementaires administratives, etc.
25
A cet égard, l'OAPI agit au nom et pour le compte des Etats membres.
b) Missions de documentation et d'information
L'accord de BANGUI fait obligation à l'OAPI de diffuser à titre d'information le contenu essentiel des titres
qu'elle délivre.
Le bulletin Officiel de Propriété Industrielle de l'Organisation (BOPI) illustre bien cette disposition de
l'Accord. Le souci de voir l'OAPI jouer un rôle encore plus important dans la documentation et l'information
à amener les législateurs à prévoir dans l'accord actuel une annexe intitulée « de l'organisme Centrale de
documentation et d'information dont l'article 2 précise : le centre de documentation contribuera à la
promotion du développement technique et industriel des Etats membres de l'Organisation par la mise à
leur disposition de documents et d'informations en rapport avec les inventions.
c) Missions d'implication dans le développement technologique
Une nation ne peut prétendre au développement industriel que si son système de propriété industrielle
offre une garantie suffisante pour les investisseurs. Aussi l'OAPI met elle en place un programme
d'information, de sensibilisation, de formation et destiné aux différentes couches et de la société ou le
besoin en droit de propriété intellectuelle se fait sentir.
1.3. Organisation de l’O.A.P.I.
Les organes qui constituent l'OAPI se présentent ainsi qu'il suit :
a) Conseil d'Administration :
26
Il est composé des représentants des Etats membres à raison d'un représentant par Etat. Le conseil
d'Administration arrête la politique générale de l'organisation, il règlemente et contrôle l'activité de cette
dernière et notamment :
- Etablir les règlements nécessaires à l'application de l'Accord de Bangui et de ses annexes
- Etablir le règlement financier et les règlements relatifs aux taxes, à la commission supérieure de recours,
au statut général du personnel et à la profession des mandataires
- Contrôler l'application des règlements en vigueur
- Approuver le programme et vote annuellement le budget et éventuellement, les budgets modificatif et

additionnel et en contrôle l'exécution
- Vérifier et approuver les comptes et l'inventaire annuel de l'organisation
- Approuver le rapport annuel sur les activités de l'organisation
- Statuer sur les demandes d'adhésion en qualité de membre ou d'admission en qualité d'Etat associé de
l'organisation
- Fixer le montant de toutes contributions des Etats membres et de celle des Etats associés
-Décider en cas de besoins de la création du comité ad-hoc sur les questions précises
- Arrêter la ou les langues de travail
b) La Direction Générale
Placée sous l'autorité d'un Directeur Général, elle est chargée des taches exécutives de l'organisation et en
assure la gestion et la continuité au quotidien. Elle exécute les directives du Conseil d'Administrations et
ainsi que les taches découlant des dispositions de l'Accord de Bangui et ses annexes et rend compte au
conseil d'Administration.
Le Directeur Général est le plus haut fonctionnaire de l'OAPI et est nommé pour une période de 5ans
renouvelable une fois. Il représente l'organisation dans tous les actes de la vie civile.
27
II est responsable de la gestion de l'organisation devant le conseil d'Administration auquel il rend compte
et aux directives duquel il se conforme en ce qui concerne les affaires intérieurs et extérieur de
l'organisation.
Le directeur Général prépare les projets de budgets, de programme et le bilan ainsi que les rapports
périodiques d'activités qu'il transmet aux Etats membres. Il prend part, sans droit de vote, à toutes les
sessions du conseil d'Administration. Il est d'office secrétaire desdits sessions.
Il recrute, nomme, révoque et licencie le personnel de l'organisation excepté le personnel hors catégorie,
conformément aux conditions définies par le statut général du personnel.
c) La commission supérieure de recours
La commission supérieure de recours est composée de 3 membres choisis par tirage au sort sur une liste de
représentants désignés par les Etats membres, à raison d'un représentant par Etat
Elle est chargée de statuer sur les recours consécutifs au rejet des demandes de titres de protection
concernant la propriété industrielle, au rejet des demandes de maintiens ou de prolongations de la durée
de protection, au rejet de demandes de restauration, aux décisions concernant les oppositions.
Les sessions de la commission supérieure de recours et la Procédure de recours devant elle sont
déterminée par un règlement adopté par le conseil d'Administration.
Voici, ci-dessous, l’organigramme de l’O.A.P.I :
28
Figure 1 : Organigramme de l’O.A.P.I.
29
Partie 2 : Présentation de la Direction des systèmes d’information et de la publication
2.1. Missions de la D.S.I.P
Placée sous l'autorité d'un Directeur, la Direction des Systèmes d'Information et de la Publication (DSIP) est
chargée :
- De planifier, coordonner, superviser et animer les activités des différents services,

- De concevoir et gérer le système d'information ; De gérer le patrimoine archivistique de
l'Organisation de produire les statistiques ;
- D'assurer les publications de I 'Organisation.
2.2. Organisation de la D.S.I.P
La Direction des Systèmes d'Information et de la Publication comprend :
- Un secrétariat de Direction ;
- Le service de l'exploitation des systèmes d'informations
- Le service du développement et de l'intégration des systèmes d'information ;
- Le Service de la publication, de la documentation et des statistiques Le Guichet unique.
a) Le secrétariat de Direction
Placé sous l'autorité d'un (e) Assistance (e) de Direction, le secrétaire de Direction est chargé :
- D'assister le Directeur dans les tâches quotidiens ;

- D'élaborer et de suivre l'agenda du Directeur ;
- De recevoir tous les documents destinés à la Direction ;
• De traiter le courrier arrivée et départ ;
30
• De transmettre des dossiers aux Services de la Direction ;
- De classer et de tenir à jour des dossiers physiques et numériques.
b) Service de l'Exploitation des Systèmes d'Information (SESI)
Placé sous l'autorité d'un Chef de service, le Service de l'Exploitation des Systèmes d’information est chargé
- D'assister les utilisateurs dans l'exploitation des applications métiers, D'assurer la maintenance du
matériel informatique, du réseau et de logiciels ;
- D’administrer les bases de données ;
- D'administrer le réseau informatique et téléphonique ; D'administrer les systèmes de sécurité
informatique ;
- D’assurer en liaison avec le service en charge du conseil juridique, le suivi des contrats et des
licences des logiciels ; D'effectuer les sauvegardes et les restaurations
- D'administrer la messagerie électronique.
c) Service du Développement et de l'intégration des Systèmes d'Information (SDISI)
Placé sous l'autorité d'un Chef de service, le Service du Développement et de l'Intégration des Systèmes
d’Information est chargé :
- D'élaborer et de mettre en œuvre le schéma directeur du système d'information

- De développer et d'intégrer de nouvelles applications ;
- D'assurer en liaison avec le service en charge de l'exploitation, le déploiement d'applications ;
- Les sites web et autres réseaux sociaux ;
- De développer et mettre un œil sur la veille technologique
- Surveiller le service en charge de la documentation en vérifiant les travaux informatiques sous-
jacents,
- D'assurer en liaison avec numérisation des archives.
31
d) Service de la publication, de la Documentation et des Statistiques (SDPS)
Placée sous l'autorité d'un Chef de service, le Service de la Publication de la Documentation et des
statistiques est chargé :
- D'assurer la publication des bulletins officiels, des rapports annuels, de l'annuaire statistique, etc.
- De gérer la documentation notamment les bibliothèques et les archives techniques et
administratives ;
- De produire les statistiques ;
- D'organiser et gérer les archives ;
- D'assurer en liaison avec en charge du développement et de l'intégration, la numérisation des
archives ;
- D'assurer les travaux d'imprimerie.
e) Le Guichet Unique
Placé sous I 'autorité d'un coordonnateur ayant rang de Chef de service, le Guichet Unique est chargé :
- D'assister les déposants ;

- De réceptionner le courrier technique ;
- D'assurer le traitement préliminaire du courrier technique :
- D'assurer la transmission de demandes traitées aux Directions.
32
Partie 3 : La gouvernance IT au sein de l’OAPI
Figure 2 : Image d’un extrait de la plateforme des logiciels de gestion des processus métiers informatiques
au sein de l’O.A.P.I.
• La gestion du parc informatique par la méthode ITIL
La gestion de parc permet, d'une part, de répondre aux multiples questions quotidiennes posées à
l'administrateur réseau (quelles sont les versions de Windows installées et sur quels postes ? Y a-t-il des
disques durs proches de la saturation ? Tel matériel est-il bien connecté au commutateur ? A quel endroit
se trouve tel élément ? Quelle est la valeur actuelle de tel autre composant ? Quels sont les postes encore
sous garantie ? etc.). Elle permet, d'autre part, une administration plus globale et à long terme : combien
de machines y aura-t-il à renouveler dans 2 ans ? Quels sont les nouveaux besoins ? Quelles formations
doit-on planifier ? Quel est le retour sur tel investissement ? Quel est le coût total de possession – ou TCO –
d'un poste ? etc. Le système informatique tisse les liens entre les activités de l'organisation, il importe donc
33
d'en connaître la composition à tout moment. Actuellement, la tendance des DSI (Direction des Systèmes
d'Information) est à l'adoption d'un référentiel commun de bonnes pratiques quant à ses processus métier.
ITIL (Information Technology Infrastructure Library) est le référentiel de "bonnes pratiques"
majoritairement adopté par les DSI ; il couvre essentiellement les métiers de la production informatique et
du support. Un logiciel de gestion de parc incluant notamment une gestion des configurations et
l'assistance aux utilisateurs représente l'élément central pour appliquer les recommandations ITIL.
Au sein de l’O.A.P.I, l’une des méthodes de gouvernance des systèmes d’information est la méthode ITIL
(Information Technology Infrastructure Library) et une des pratiques régulières de veille technologique est
la mise à jour et la révision constante du parc informatique. Les solutions de gestion de parc informatique
s’appuient sur un ensemble de guide d’information Technologiques et d’infrastructure en matière de
gestion de parc informatique définit par la norme ITIL créé en 1980 par l’OGC (Office of Governemment
Commerce).
Elle se décompose en neuf domaines, permettant de couvrir l'ensemble des problématiques couvertes par
les DSI. Les deux premiers domaines sont considérés comme étant le cœur de cette méthode :
- Service Support
- Service Delivery
- Infrastructure Management
- Applications Management
- Service Management
- Business Perspective
- Business Requirements
- Technology
Le « Service Support » est rattaché au fonctionnement et au support de l'infrastructure technologique. Il

est décomposé selon les 6 processus suivants :
34
Tableau 1 : Liste des processus du « Service Support » d’ITIL implémenté au sein de l’O.A.P.I.
Le « Service Delivery », (stratégie, support, supervision, gestion) et se décompose selon les 4 processus
suivant :
Tableau 2 : Liste des processus du « Service Delivery » d’ITIL implémenté au sein de l’O.A.P.I.
La CMDB (Configuration Management DataBase), quant à elle, donne une vue complète des composants de
l’infrastructure informatique et des services, elle rassemble dans un modèle de données commun les
informations tenues à jour par une suite de configuration d’items :
- Des services rendus.
- Des utilisateurs.
35
- Des matériels (serveurs, réseau, imprimantes, baies de stockage, poste de travail.
- Des logiciels (OS, environnement virtualisé, ordonnanceur, EDI, middleware).
- Des applications (bases de données, ERP).
- Des ressources utilisées (locaux, onduleurs, accès physique, documentation, personnel interne/externe). -
- Des catégories.
- Des attributs (marque, modèle, adresse IP, version, criticité, service métier associé, populations
utilisatrices, engagements de niveau de service…).
- Des états (en préparation, actif, inactif, supervisé, commandé, acquis, validé, recetté, conforme à la
politique de configuration…).
- Des relations (contient, dépend de, a pour périphérique, est situé à, héberge, tourne sur, lance, arrête,
contrôle, met à jour, récupère, est le contact etc…)
La démarche ITIL permet de couvrir l'ensemble des problématiques informatiques suivantes:
- Satisfaction des utilisateurs (personnel et clients).
- Clarification des rôles.
- Amélioration de la communication inter-service.
- Mise sous contrôle des processus avec des indicateurs pertinents et mesurables, permettant d'identifier
les leviers pour réaliser des économies.
- Meilleure compétitivité.
- Sécurité accrue (disponibilité, fiabilité, intégrité).
- Capitalisation des données de l'entreprise.
- Optimisation de l'utilisation des ressources.
- Outil de parangonnage (benchmarking) et outil de positionnement vis-à-vis de la concurrence.
- Réduction du cout matériel TCO (Total Cost Investissement et ROI (Return On investissement).
36
Somme toute, La méthode ITIL présente 34 pratiques minutieusement appliquées au sein de l’O.A.P.I :
- Les pratiques de gestion générales :
• La gestion de l’architecture
• L’amélioration continue
• La gestion de la sécurité de l’information
• La gestion des connaissances
• La mesure et rapports
• La gestion de changement organisationnel
• La gestion du porte-feuille
• La gestion des projets
• La gestion des relations
• La gestion des risques
• La gestion financière des services
• La gestion de la stratégie
• La gestion des fournisseurs
• La gestion des effectifs et des talents
- Les pratiques de gestion des services :
• La gestion de la disponibilité
• La Business Analysis
• La gestion de la capacité et de la performance
• L’habilitation des changements
• La gestion des mises en production
• La gestion des incidents
• La gestion des actifs informatiques
• La gestion des problèmes
• La gestion du catalogue de services
• La surveillance et gestion des évènements
37
• La gestion de la configuration des services

• La gestion de la continuité des services
• La conception des services
• Le centre de service
• La gestion des niveaux de services
• La gestion des demandes de services
• La validation et test de services
-Les pratiques de gestion technique :
• La gestion des déploiements

• La gestion de l’infrastructure et des plateformes
• Le développement et la gestion des logiciels
La principale application de gestion du parc informatique utilisé par l’O.A.P.I est G.L.P.I
38
Partie 4 : Tâches effectuées lors du stage
4.1. Application web du restaurant ou de la cantine
Il nous a été demandé au cours du stage, de concevoir une application Web facilitant l’usage du restaurant
par les membres du personnel.
4.1.1. Problématique
Les divers points ayant conduit à la recherche d’une telle solution ont été :
- Le constat tacite du taux faible du personnel s’offrant un repas à la cantine

- Le déploiement d’un solution logicielle facilitant la demande de commandes
- L’accord d’une plage de dettes fixant à 50 000Fcfa au personnel
- Le règlement des factures directement lorsque le salaire sera viré
- La gestion informatique du stock du restaurant
- La possibilité de livraison directement par la plateforme
4.1.2 Méthodologie de travail
Notre travail a été calqué sous le prisme de la méthodologie SCRUM.
Ce projet a été conçu et déployé en équipe avec ma co-stagiaire Mlle Christelle Alix Pideu.
4.1.3. Avant-projet
Durant l’avant-projet, nous nous sommes attelés à effectuer des sondages auprès des membres du
personnel de la D.S.I.P et du service de la comptabilité. Ce sondage nous a permis de dresser un Product
back log et une User story des besoins de l’utilisateur. Par la suite, nous nous sommes également rendus au
39
restaurant en vue de questionner le membre du personnel gérant le restaurant dont le cuisinier en chef :
M. KENMOGNE qui sut donner ses attentes de son côté et les faisabilités du projet à leur niveau.
La seconde étape de ce projet était la phase d’analyse ou de conception, durant laquelle nous avons établi
un cahier de charge piuis listé les différents cas d’utilisation et leurs scénarios. Par la suite, nous avons
dressé à l’aide du logiciel PowerAmc le diagramme de cas d’utilisation globale puis de séquence et
d’activité des divers scénarios.
4.1.4. Phase de réalisation
Nous avons, en vue de peaufiner nos connaissances dans différentes approches, utilisé des technologies
différentes :
Ma co-stagiaire fit usage de WordPress et de ses additifs (plugins). Elle déploya son projet en local à l’aide
de Xampp par le biais du serveur Apache et déploya sa base de données en local sur PhpMyAdmin, sous le
système Windows 10 de son laptop dont la version du processeur était icore7.
En ce qui me concerne, j’ai utilisé le framework laravel et les plugins de Laravel Breeze pour la partie Front-
End. Je me suis servie de l’éditeur Visual Studio Code et du serveur web local Apache déployé par
l’application Wamp. Par la suite, j’ai effectué un codage entièrement en Php, me servant de la base de
données locale PhpMyAdmin. L’ordinateur utilisé pour ce projet était un laptop sous Windows 10 dont la
version du processeur était icore 7.
4.1.5. Phase de test

Compte tenu de la méthodologie SCRUM qui nous imposait des retours itératifs, à chaque étape du projet,
nous testions le résultat. Nous avions commencé par la plateforme principale du restaurant dont voici un
petit aperçu :
40
41
Figure 3, 4, 5 : Présentation de la plateforme Web conçue pour le restaurant de l’O.A.P.I
Cependant, ces pages ne sont accessibles que pour l’utilisateur s’étant préalablement identifié comme ci-
dessous :
42
Figure 6,7 : Présentation de la zone d’authentification du personnel de l’O.A.P.I. pour la plateforme du

restaurant.
43
Si l’utilsateur a perdu son mot de passe, il clique sur « forgot your password » et une page lui demander
son adresse mail avec laquelle il s’est authentifié s’ouvre. Suite à cela son mot de passe stocké dans la base
de données lui est renvoyé par mail. Nous avons configuré cela à l’aide d’un service de messagerie local
Mailtip dans les paramètres du code.
L’utilisateur comme vous le voyez peut passer une commande, voir son panier et effectuer un paiement
(paiement qui se fait physiquement) tel que l’a demandé le Directeur de la D.S.I.P en vue d’éviter certaines
contrariétés.
Nous ne nous attèlerons pas plus longtemps sur ce volet de notre stage, n’étant pas le thème principal du
stage.
4.2. Assistance dans les travaux de configuration menée par le prestataire C.F.A.O
Nous avons assisté les prestataires dans les travaux de configuration du réseau notamment C.F.A.O dans le
remplacement de Switch, le refonte de l’ancienne architecture réseau de l’O.A.P.I et le renouvellement de
cette architecture dont une ébauche désuète est la suivante :
44
Figure 8 : Exemple d’architecture réseau reconçu par nous, les stagiaires.
Nous avons fait usage des logiciels Aris et Visio, tout en conservant les représentations normées de Cisco et
en étiquetant les différents ports et équipements. Ce travail s’effectuait particulièrement dans la salle
Serveur et nécessitant une consultation régulière de toutes les armoires réseau ou rack de chaque
bâtiment et étage constitutive de l’O.A.P.I. Nous avons également effectué la vérification de certains
équipements réseau, les switchs et leurs ports, la configuration des switches de management et de
distribution de la fibre optiques à l’aide des jaretières déjà fixées, la bonne configuration des switchs (plus
particulièrement des Vlans) face à des disfonctionnements au niveau des caméras de surveillance.
Nous avons également assisté les membres du prestataire ISE dans la reconfiguration du pare-feu en vue
d’améliorer ses critères de sécurité et de le mettre à jour (dans le cadre de la veille technologique).
4.3. Maintenance préventive dans les locaux de l’O.A.P.I.
Nous avons effectué la maintenance préventive des deux bâtiments de l’O.A.P.I. (l’ancien Bâtiment dit
Guichet Unique et le bâtiment principale). Cette maintenance consistait à éliminer tout élément nocif au
bon fonctionnement d’un équipement informatique (la poussière, des saletés incrustés, des morceaux
coincés). Elle consistait également à mettre à jour des pilotes ou logiciels dans les machines du personnel. Il
est à noter que n’est autorisé à installer ou à mettre à jour dans ce machines hautement sécurisées le
personnel informatique muni de son identifiant et de son mot de passe.
4.4. Autres interventions dans le cadre informatique
Il s’agissait d’intervention de tout ordre dans le domaine informatique, notamment un dépannage face à
une difficulté du personnel, des mises en place d’outils informatiques nécessaires dans des salles de
réunion ou lors des permutations de bureau du personnel. La préparation et l’installation de nouveaux
équipements (Téléphone Cisco VoIp, Moniteur, Unité Centrale, tout-en-un, Scanner, Imprimante, etc.)
fournis par le département chargé de l’inventaire des équipements situé au 2ème étage.
45
4.5. L’implémentation de Nagios à l’aide des équipements et du réseau local de l’O.A.P.I
Il s’agit bien ici, de notre thème de mémoire sur lequel nous allons nous apesantir dans la suite.
En effet, nous avons mis sur pied Nagios Core et Nagios xi au sein du réseau local de l’O.A.P.I et nous avons
effectué le monitoring de Desktops, d’imprimante, de routeurs, et de laptops, tout en nous tournons vers
nombre de services qui nous importaient.
4.6. Régénération des certificats du BOPI (Bulletin Officiel de la Propriété Industrielle) à l’aide de
l’outil de gestion ipas
Notre travail consistait ici, à regénérer des certificats problématiques dans la plateforme iPas des noms
commerciaux.
46
Partie 5 : Présentation du projet
5.1. Aperçu du projet

Le projet consiste à installer, configurer et implémenter Nagios au sein de l’O.A.P.I. en vue d’un
monitoring plus dynamique du réseau
5.2. Description du contexte
L’OAPI déploie en son sein une technologie de pointe tant au niveau de son hardware et que de son
software.
Les solutions logicielles de gouvernance IT déployées au sein de l’O.A.P.I sont diverses :
5.2.1. G.L.P.I.
GLPI est une solution logicielle déployée au sein du réseau local de l’O.A.P.I dans le cadre de la
gouvernance IT en assurant :
- La gestion de l’infrastructure
Il permet de répertorier les équipements et leurs propriétés.
- La gestion des projets
47
- La gestion des déploiements
Il donne une vue panoramique sur les infrastructures déjà déployées ou en attente du déploiement. Il suffit
en fonction du type d’intervention, de déterminer l’outil informatique dont il est question.
- La gestion des niveaux de service
Il permet en effet de définir les différents niveaux de services lors d’un projet, grâce à son répertoire du
personnel classé par Direction, accompagné des adresses ou contacts de chacun.
Il met également en avant les différentes fonctions que peuvent avoir un membre du personnel et les
priorités sous-jacentes :
48
- La gestion des demandes de services

- La gestion de la disponibilité
Il permet de déterminer si un équipement est en production ou en attente.
- La gestion des incidents
A travers la gestion des tickets qui facilitent l’alerte d’un utilisateur à un autre, il permet d’être au taquet
face à des troubles du système et de prendre les mesures nécessaires à cet effet.
49
- La gestion des actifs informatiques
Il facilite la gestion des actifs informatiques tels que les ordinateurs, imprimantes, alimentations, etc. Un
petit aperçu est le susivant :
- La gestion du catalogue de service

- La gestion de la configuration des services
- La gestion de la capacité et de la performance
Pour gérer cela, l’administrateur peut installer des appliances ou des plugins qui lui permettront d’avoir
une vue panoramique sur la capacité et la performance des équiepements
50
- La gestion financière des services
Il permet de gérer le budget tout en ayant une vue global sur les fournisseurs, leurs contacts et les
documents ou closes jointes.
- La gestion des effectifs et talents
Il permet en effet de gérer le personnel tout en donnant les caractéristiques nécessaires. Voici un aperçu
du compte qui est mien :
51
- La gestion des relations
Il est sécurisé et permet l’attribution de certains droits à un personnel en fonction du fait qu’il soit
administrateur(admin) ou observateur (observer). La page d’accueil de ce logiciel est la suivante :
Fig 9, 10, 11, 12, 13, 14, 15, 16 : Vue globale de la plateforme de gestion des incidents G.L.P.I.
5.2.2. iPas
52
iPas, quant à lui, est un logiciel de gestion de la production. Il a remplacé, disons, est venu combler certains
manquants de Gestrickr. Il permet la gestion des noms commerciaux et des marques.
Son interface d’acceuil est présentée comme suit :
Figure 17 : Aperçu de la plateforme iPas.
Il permet notamment principalement de faire des recherches sur l’état d’avancement d’un dossier,
enregistrer un dossier, le modifier et générer automatiquement des certificats.
5.2.4. SAGE
Cet ERP est particulièrement utilisé par le service du patrimoine, de la comptabilité, achat, paie, ressources
humaines et des finances.
5.2.5. OAPROD
Il contient les informations des dossiers de marque en cours de production ou en phase d’étude.
5.2.6. NCPROD
Il contient les informations des dossiers de noms commerciaux en cours de production ou en phase
d’étude.
53
5.2.7. WIPO FILE ADMIN OA

Il contient les informations des dossiers des marques du monde accessibles uniquement aux
administrateurs
5.2.8. WIPO FILE AGENT OA

Il contient les informations des dossiers des marques du monde accessibles aux agents.
5.2.9. WIPO FILE ADMIN NC

Il contient les informations des dossiers des noms commerciaux du monde accessibles uniquement aux
administrateurs
5.2.10. WIPO FILE AGENT NC

Il contient les informations des dossiers des noms commerciaux du monde accessibles uniquement aux
administrateurs
5.2.11. ACTIVE DIRECTORY

Il met en place un environnement collaboratif de haut niveau entre collaborateurs et membres du
personnel, en fournissant des logiciels de messagerie, de travail et des algorithmes de partage de fichiers
ou de travail en distanciel du poste de travail mère. Il est, en fait, une implémentation de GPO qui est un
outil de gestion du réseau mettant en place une stratégie de groupe de haut niveau.
5.2.12. Des applications de TASK MANAGEMENT développées en local

Ces applications permettent à chaque membre du personnel de renseigner le nombre de tâches et la
qualité de travail effectué chaque semaine. Passé le délai d’une semaine, il n’est pas possible de renseigner
les tâches de la semaine qui précède. Grâce à cela, il est donc capable d’établir le pourcentage de
rentabilité de chaque personnel.
Ce rapport d’activité est consulté par chaque directeur de chaque département.
Cette application facilite également le suivi des engagements budgétaires et le contrôle dudit budget.
5.3. Critiques sur l’existant : Application concurrente à Nagios
54
Au moment où nous effectuons le sondage sur l’utilité et le bienfondé de l’implémentation de

Nagios, une initiative voisine avait déjà pensée notamment G.P.L.I. Cependant, ce dernier
présente des limites, notamment :
- Il ne renseigne pas suffisamment sur l’état dynamique de la machine

- Il ne donne pas la possibilité de choisir le service à monitorer
- Il ne permet pas d’avoir des alertes ou notifications à une fréquence définie par email
- Il ne permet pas d’avoir un mapping du réseau
- Il ne permet pas, sans Appliance, de dresser une grille statistique.
5.4. Problématique
A cet effet quelques questions méritent d'être posées :
• Comment résoudre le problème d'alerte dynamique concernant le réseau ?

• Comment rentabiliser la production à l’aide des statistiques ?
• Comment avoir une pléthore de services à monitorer plus aisément ?
5.5. Hypothèse
Etant donné que l'informatique est, de nos jours, l'outil par l'excellence qui procure la rapidité et
l'automatisation, source de la précision et de l'exactitude, nous ne pensons qu'à la résolution des
problèmes liées à l’emploi des équipements réseau, par la mise en place d'un logiciel de
monitoring Nagios qui offrirait :
• Une plus grande efficience dans la résolution des problèmes et incidents

• Une plus grande rentabilité dans la production en anticipant sur un problème ou incidents
• Une vue plus approfondie sur le fonctionnement d’un équipement réseau
55
5.6. Point de mire du travail
Ce travail est rédigé dans l'intention :
1. Des services techniques de l’O.A.P.I

2. Des services ou prestataires habilités à en faire usage dans le but d’un audit ou d’un
projet.
5.7. Choix et intérêt du sujet
Ce projet touche non seulement la dimension technique de la gouvernance IT mais également sa

dimension managériale inhérente au bon fonctionnement des services informatiques au sein de
l’O.A.P.I.
5.8. Délimitation du sujet
Notre travail s'articule sur l’installation, la configuration et l’implémentation d’un outil de

monitoring réseau au sein de l’O.A.P.I. Notre choix s’est tourné vers Nagios qui présente,
d’ailleurs, deux versions notamment une gratuite et open source Nagios core testée sur une
machine virtuelle caractérisée par la distribution Debian de Linux. Ensuite nous étudierons Nagios
XI, qui est une amélioration, payante, de Nagios Core.
5.9. La portée du travail
5.9.1. La situation présente
Comme limite, ce projet ne facilite pas la gestion du personnel, des tickets, du budget, comme le fait GLPI.
Cependant, il est complémentaire à ce dernier.
56
5.9.2. Le contexte du travail
Après avoir réalisé un sondage au sein de la D.S.I.P, il en ressort qu’il serait de bonne augure
d’entamer un tel projet car lors des pannes et disfonctionnements du système, il y a vraiment
beaucoup de difficultés à déterminer aisément et diligemment quel en est la cause.
Avant de commencer le travail de configuration proprement dit, certains travaux préliminaires

doivent déjà être relaissé. Il s’agit :
• D’un sondage sur le bienfondé et l’utilité de l’application,

• De la préparation de l’environnement de travail
Le diagramme ci-dessous donne un aperçu des travaux qui doivent être préalablement faites
avant de commencer le développement de l’application proprement dite :
5.9.3. DIAGRAMME DE TRAVAIL
2. Préparation des
équipements de travail
(PCs, imprimantes,site
web, scanner, etc.)
Installation,
configuration et
3. Préparation de
implémentation 1. Sondage sur l'utilité et
l'environnement logiciel
de Nagios Core le bienfondé de la
de la solution Nagios Core
et de Nagios XI solution envisagée
et Nagios XI
Figure 18 : Diagramme du contexte de travail
57
5.10. Les parties prenantes
5.10.1. Le client
Au cours de notre projet, le client est l’O.A.P.I.
5.10.2. Le consommateur
Le consommateur est l’O.A.P.I. et ses partenaires.
5.10.3. Utilisateurs du logiciel Nagios

Les utilisateurs du logiciel Nagios sont le personnel de la D.S.I.P et tout prestataire autorisé à en
utiliser les données ou informations procurées par Nagios.
5.10.4. Technicien de maintenance et de service

La maintenance du logiciel de supervision est globalement faite par l’équipe de la DSIP qui a des
accès particuliers d’utilisateur suprême.
5.11. Contraintes obligatoires

Nous appelons ici contraintes obligatoires toutes les contraintes unanimement choisies par
l’équipe et qui seront considérées comme obligatoires une fois adoptées.
5.11.1. Contraintes de la solution

Le tableau ci-dessous donne toutes les contraintes obligatoires unanimement choisie pour le reste
de l’implémentation du logiciel de supervision :
Tableau 3 : Liste des contraintes obligatoires

Description Justification Critère d’ajustement
NagiosXI doit être utilisé à partir Le web permet à Nagios XI à être Les technologies web doivent
d’un navigateur web accessible à tout ordinateur dans être utilisés pour
58
Nagios Core ne peut être utilisé le réseau l’implémentation du projet.

que sur une unique machine à Le navigateur permettra à
l’aide de son navigateur l’utilisateur d’utiliser son serveur
local Apache dans l’optique
d’une telle configuration.
L’application sera scindée en Pour une application mieux Nous aurons deux
deux : structurée, la prise en main est environnements de
- Interface Utilisateur plus facile du point de vue de la configuration distincts l’un pour
(Frontend) maintenance. l’interface utilisateur (IU), et
- Les lignes de Les lignes de commandes l’autre du côté du terminal.
commandes par le représentent le cœur même de
terminal Nagios Core tandis que du côté
de Nagios XI, elles peuvent être
utilisées pour se connecter au
serveur de la machine virtuelle
Nagios directement
Pour l’amélioration de Nagios Core, d’un La dernière version des logiciels
l’Interface Utilisateur de Nagios fonctionnement un peu plus doit être au rendez-vous durant
Core, nous allons utiliser Oreon sinué, n’est pas d’une prise en ce projet.
main facile. Ainsi, Oréon facilite
cette prise en main de part un
interfaçage plus compréhensible.
Pour l’implémentation de Des limites se posent quant à Il faudrait ainsi installer les
certains services, nous allons l’incompatibilité entre certains agents dans les équipements à
utiliser des agents et plugins systèmes d’exploitation et Linux monitorer et le plugin
qui était le système de correspondant dans le serveur
destination premier. Nagios.
5.11.2. Environnement de travail prévu
59
Le logiciel Nagios xi est conçu uniquement pour fonctionner sur un navigateur web via n’importe
quel ordinateur qu’en local sur une ou plusieurs machines en particulier, lorsque le VMWare de
Nagios XI est activé. La taille de l’écran sur laquelle l’application est ouverte va automatiquement
définir la taille de l’application sur l’écran. Avec Nagios Core, l’utilisateur peut uniquement
travailler en local.
La taille de l’Interface Utilisateur (IU) est hautement réajustable en fonction de la taille de

l’appareille sur laquelle l’application est lancé. Donc l’application est utilisable dans n’importe quel
terminal mobile connecté et détenant un navigateur web.
5.11.3. Contraintes de planification
Nous avons choisi de travailler sur ce projet dans le cadre du mémoire de fin en management des
systèmes d’informations à l’IFTIC-SUP. Le projet nous a été octroyé pour une période d’environs
deux (04) mois, temps très insuffisant pour un projet de cette taille. Nous allons donc travailler
jour et nuit parfois sans véritable repos pour pouvoir terminer le travail dans les délais.
5.11.4. Contraintes budgétaires
Nagios détient deux versions, l’une payante (Nagios xi) et l’autre gratuite (développé en local sur
la machine). Notre étude a porté sur les deux versions. En ce qui concerne la version payante,
nous nous sommes limités aux jours d’essai gratuit du logiciel en vue de mener notre étude.
Toutefois, l’implémentation au-delà des jours d’essai de Nagios XI est estime à minimum 997 500
Fcfa.
60
Chapitre 2 : Cahier de charge
2.1. Présentation et objectifs de Nagios
Figure 19 : Interface d’accueil de Nagios XI
Nagios XI est une solution d'alerte et de surveillance d'infrastructure informatique évolutive.

Conçue pour les PME et les grandes entreprises, elle leur fournit une vue détaillée de leur
infrastructure informatique, leur permettant ainsi d'anticiper les problèmes avant qu'ils
n'affectent les processus métier critiques.
Elle offre une vue centrale de l'ensemble de votre réseau d'opérations informatiques en
permettant de surveiller tous les composants de l'infrastructure, y compris les applications, les
services, les systèmes d'exploitation, les mesures système ainsi que les protocoles et
l'infrastructure réseau tout en planifiant les mises à jour de l'infrastructure avec des graphiques de
61
tendances et de capacité intégrés et automatisés, sans oublier qu’en cas de problème, Nagios XI
vous alertera.
L'accès multi-utilisateur et les vues spécifiques à l'utilisateur garantissent que les clients et les
parties prenantes ne voient que les composants d'infrastructure pertinents qu'ils sont autorisés à
voir, tandis que les API multiples facilitent l'intégration aux autres applications internes et
externes.
Somme toute, Nagios est un logiciel libre sous licence GNU-GPL et fonctionne sur divers systèmes
de type Unix. Avec l’aide d’un logiciel de machine virtuelle, il peut aussi être utilisé sur le
système d’exploitation Windows. Pour installer et utiliser cet outil de monitoring, il est nécessaire
d’avoir un serveur Web avec un module PHP : le logiciel Apache est alors recommandé. En plus du
noyau du programme, il faut également télécharger le plugin officiel de Nagios. Ces modules sont
responsables de l’exploitation et de l’analyse des différentes demandes de monitorage des
réseaux, hôtes et services, et sont ainsi essentiels pour la fonctionnalité du logiciel.
Aujourd'hui, Nagios dispose d'une structure digne d'un très grand éditeur. D'ailleurs, il y a quelques années,
le site Web de Nagios fut mis à jour vers une version beaucoup plus marketing car, Nagios a décidé, après
de nombreuses années comme application open source, de faire de l'argent. C'est l'avènement de Nagios
XI. Cependant, Nagios Core, la solution historique, avec ses plugins, reste open source et gratuite, mais
l'entreprise met désormais sensiblement en avant la version sous licence. Ainsi, Nagios XI présente une
interface Web d'administration/configuration qui respecte l'état de l'art des développements Web et
mobiles, et propose un framework de services de grande qualité : une gestion avancée des graphes, une
fonctionnalité de Capacity Planning automatique, des assistants de configuration, des snapshots de
configuration, une gestion avancée des utilisateurs, etc.
Nagios XI continue de fonctionner avec le cœur du code et le moteur historique open source,
Nagios Core.
Mais ce n'est pas tout. Maintenant, Nagios met aussi à disposition des produits complémentaires :
62
• Nagios Log Server, qui propose une plateforme de centralisation des logs ainsi qu’une
interface permettant de générer des requêtes dynamiques et des tableaux de bords
personnalisés ;
• Nagios Network Analyzer, qui fournit une analyse approfondie du réseau et de toutes les
sources de trafic, fournissant ainsi aux administrateurs des rapport d’alertes et des
indicateurs concernant la santé du réseau. Cet outil intègre également une interface Web
d’administration/configuration ;
• Nagios Fusion, qui rassemble les trois solutions Nagios XI, Nagios Log Server et Nagios
Network Analyzer au sein d'une plateforme de gestion centralisée.
Dans cette suite, nous nous appesantirons tant sur le logiciel open source et gratuit Nagios Core
que sur sa version payante, Nagios XI, plus pertinente dans le cadre d’un projet d’envergure.
Vous l'aurez compris, Nagios Core, en l'occurrence ici la version 4, est l'héritier direct du moteur
créé en 1996 par Ethan Galstad. Nagios XI n’est rien d’autre que la version améliorée de Nagios
Core conservant le fond ou cœur de l’application identique.
La grande force de Nagios réside dans son architecture applicative, composée de 3 éléments qui
sont :
L'ordonnanceur
L'ordonnanceur est le cœur du programme. Il s'agit d'un processus qui se lance en tant que service
système. Son mode de fonctionnement est simple mais très efficace : il paramètre des objets host et
service, qui seront supervisés par l'intermédiaire d'un objet command. Celui-ci lancera, à intervalles
réguliers et paramétrables, des sondes sous la forme de programmes exécutables. Les résultats de ces
actions de supervision sont stockés dans des fichiers au format texte. Bien entendu, configurer des objets
permet, entre autres, de :
• Définir des seuils permettant de juger les résultats (aussi appelés « statuts », OK,
WARNING ou CRITICAL, par exemple pour les objets de type service) ;
63
• Observer le temps entre chaque exécution de la sonde ;

• Gérer efficacement les notifications vers les acteurs responsables de la maintenance de ces
objets ;
• Indiquer un minimum de topologie concernant le schéma d'architecture réseau ;
• Déclencher des actions particulières sur certains statuts ;
• etc.
Les plugins
Les plugins (aussi appelés « sondes ») sont des programmes qui fonctionnent de manière autonome et
servent à superviser les caractéristiques des objets configurés. Parmi ces caractéristiques, on peut
notamment citer la charge CPU, l'occupation de la mémoire ou du disque, les services HTTP, SSH, FTP,
SNMP, PING, WMI, POP3, et beaucoup d'autres encore. Les plugins Nagios étant normalisés et très bien
documentés, il est possible de coder soi-même un plugin spécifique à son besoin ;
L'interface Web d'administration
Ce composant très pratique, codé en CGI/PHP, va lire les informations stockées dans les fichiers
résultat de Nagios afin d’afficher ces données sur des pages Web. Il est possible de générer des
rapports ou de gérer un minimum de droit utilisateur. Un système de pipe, Unix, permet à
l'utilisateur de donner des ordres au moteur Nagios (forcer le lancement d'une sonde à l'instant T,
redémarrer le service, modifier la configuration d'un objet, etc.). Il faut cependant noter que
l'interface Web de Nagios Core n'évolue plus beaucoup depuis la sortie de Nagios XI… or
l'interface d'administration de cette version commerciale est son principal argument de vente !
Mais Nagios Core peut aussi être équipé de modules tiers supplémentaires, qui viennent enrichir,
entre autres, les fonctionnalités du moteur et de l'interface. On peut mentionner des brokers
pouvant dialoguer avec une base de données, des add-ons générant des vues logiques, des
graphes ou encore une cartographie dynamique des objets supervisés.
64
Enfin, il est également important d'indiquer que Nagios est très bien documenté (Ce lien
hypertexte)
Il faut surtout évoquer la communauté Nagios. La solution dispose d'un historique important et les
utilisateurs n'hésitent pas à partager leurs expériences voire leurs créations (plugins supplémentaires,
interface administration spécifique, etc.).
La plateforme https://exchange.nagios.org fourmille d'apports techniques supplémentaires avec,

par exemple, plusieurs milliers de plugins ! En fouillant un peu, vous trouverez quelques pépites
comme une interface mobile, des didacticiels et des modules complémentaires très intéressants.
En résumé
Nagios Core est une solution pérenne, efficace et très bien supportée. Avec un peu de technique,
vous pourrez mettre en place un processus de supervision au périmètre très large. Les plugins
fournis avec le package de base couvriront sans doute la grande majorité de votre besoin…et le
tout gratuitement !
Son architecture modulaire permet d’ajouter assez facilement les modules fonctionnels qui
pourraient vous manquer avec le moteur de base, voire même de coder les vôtres et de partager
votre expérience. Seul petit bémol : son interface graphique qui vieillit assez mal… Mais si vous
êtes comme moi, une fois les principes de fonctionnement bien assimilés, vous n'hésiterez pas à
proposer votre propre développement spécifique pour ce composant, pour répondre à votre
besoin avec efficacité !
2.2. Fonctionnement de Nagios
Pour vouloir monitorer un système informatique individuel, une base de données ou un serveur, il
n’est pas nécessaire d’installer le logiciel sur chaque dispositif, en effet l’installer sur un serveur
65
Nagios séparé est amplement suffisant. A partir de là vous pouvez simplement configurer quel
système ou quel processeur doit être surveillé. Tout cela s’articule autour des quatre composants
ou objets suivants :
• Hôte : en tant qu’hôte, vous définissez les serveurs, bases de données et appareils, etc. du réseau
que vous souhaitez surveiller. L’indicateur le plus important pour un hôte est l’adresse IP
respective.
Figure 20 : Vue panoramique des hôtes, services et autres fonctionnalités
• Services : avec ce composant vous pouvez définir quelles caractéristiques de l’hôte Nagios doit
vérifier. Cela peut aussi être les services en cours d’exécution sur l’hôte (http, FTP, etc.), des
attributs internes comme l’espace disque disponible mais aussi des caractéristiques physiques
comme la température de votre matériel.
Nous verrons comment procéder avec Nagios Core, dans la suite.
66
Figure 21 : Choix des services lors de la configuration d’un hôte
• Commandes : avec ce volet vous contrôlez la séquence de monitorage. Vous pouvez configurer la
façon dont la surveillance des hôtes et des services doit être conçu et quand Nagios doit vous
avertir quand un évènement se produit.
• Contacts : avec la définition des contacts, Nagios peut alors envoyer des notifications à des
contacts administratifs via un email, un message texte ou encore un message vocal.
67
Figure 22 : Présentation des informations de l’administrateur
Nous verrons comment procéder avec Nagios Core, dans la suite.
Même si Nagios n’est pas installé sur les différents hôtes, les plugins (qui vérifient les données
internes) fonctionnent eux directement sur les hôtes. L’accès à distance peut également être
utilisé pour cette exécution, mais cette méthode est rarement employée puisqu’elle demande
plus d’effort et l’utilisation d’un système disproportionnée (avec une connexion sécurisée). C’est
pourquoi l’alternative la plus simple est l’installation de programmes spécifiques sur les hôtes.
Cela s’effectue seulement à partir des requêtes du système qui sont préconfigurées et
transmettent les résultats via les ports réseau vers le serveur Nagios. Le NRPE (Nagios Remote
Plugin Executor) est utilisé par défaut et avec cette combinaison, Nagios peut aussi monitorer les
systèmes Windows. L’on peut également télécharger d’autres agents tels que NCPA et NSclient++
dans le même but.
Une autre possibilité d’utilisation de Nagios pour vérifier les données respectives est la vérification
passive. Dans ce cas, aucune information n’est alors demandée au logiciel de monitorage, mais à
un autre programme comme Nagios Service Check Acceptor (NSCA). La surveillance du serveur est
68
simplement avertie du résultat à la fin du processus. Concernant le type de monitoring le serveur

Nagios transmet toujours un des statuts suivants :
• 0 (OK) : aucun problème trouvé pendant l‘analyse.

• 1 (WARNING) : l’examen résulte d’un message d’avertissement.
• 2 (CRITICAL) : un problème critique est survenu pendant l‘analyse.
• 3 (UNKNOWN) : le statut de l’hôte ou du service ne peut être déterminé.
Figure 23 : Vue stratégique sur les hôtes, les services opérationnels et les ressources dans Nagios XI
En outre, le programme de surveillance reçoit aussi un horodatage, une commande interne ainsi
qu’un texte optionnel qui peuvent apparaître pendant l’analyse.
2.3. Avantages et inconvénients de Nagios
Nagios est fortement apprécié comme solution de monitoring grâce à son large choix de fonctions.
Le code source libre signifie que le logiciel peut être personnalisé et étendu exactement comme
vous le souhaitez. Plus de 1.000 Plugins ont déjà étés développés ainsi que différentes interfaces
69
frontaux alternatifs qui sont généralement fournies gratuitement. En combinaison avec la

structure modulaire, même les administrateurs inexpérimentés peuvent construire un set de
fonctionnalités qui répond ainsi aux besoins de leur réseau sans avoir à programmer eux-mêmes
leurs propres interfaces.
Le principal inconvénient de Nagios est la configuration complexe des différents types de serveurs
et objets. Pour cette raison, il est conseillé de lire la notice d’instruction et de regarder les tutoriels
sur le site Web officiel de Nagios.
Finalement mais pas de moindre, il permet d’avoir non seulement une vue globale en plus de la
vue détaillée sur chaque équipement.
70
Figure 25 : Vue statistique et globale sur les performances de tous les équipements réseau enregistrés
2.4. Quelles sont les alternatives à Nagios ?
Nagios est devenu un classique dans le domaine de la surveillance et de mesure informatique,

mais il existe tout de même des alternatives pour réaliser un monitorage de réseau. Il y a plusieurs
outils similaires, mais moins complexes qui sont aussi recommandés. Dans le domaine open-
source il y a la solution entreprise Zabbix et la solution propriétaire comme CA qui ne traitent pas
seulement de la surveillance, mais réalisent également un management complet du réseau. Ce
sont de bonnes alternatives à Nagios pour une grande entreprise, en fonction du budget de cette
dernière.
2.5. Expressions des besoins de l’utilisateur

2.5.1. Réseau à superviser
Il est composé :
- D’un routeur Cisco

- D’un serveur Nagios
- D’un poste Client Windows 10
- D’un poste client virtuel Linux Debian
- D’une imprimante réseau
- D’un routeur TP-Link à monitorer
2.5.2. Règles sur le réseau
Sur le routeur, un firewall sera configuré grâce à des ACL (Access Control List) permettant l’autorisation ou
le refus de certaines connections.
71
Le firewall devra :
- Autoriser le protocole SMTP (pour l'envoi de mail) sortant mais pas entrant
- Autoriser le protocole IMAP (pour la réception de mail) entrant et sortant
- Autoriser le protocole HTTP entrant et sortant (pour le web)
- Autoriser le protocole ICMP entrant et sortant (pour l'envoi et la réception de PING)
- Refuser tous les autres protocoles dans les deux sens
Pour résumer, nous avons le schéma suivant :
Figure 26 : Schématisation des règles du réseau dans Nagios
2.5.3. Fonctionnement technique
Avant tout, il faut définir les informations qui seront récupérées par Nagios, sur chaque équipement du
réseau.
Sur le serveur "Windows Server", Nagios récupéra :
- La version du plugin qui envoie les informations au serveur Nagios : Si cette version n'est pas la dernière,
un e-mail sera envoyé à l'administrateur réseau.
- La charge CPU du serveur. Dans notre cas, si la charge dépasse les 90 %, un e-mail sera envoyé à
l'administrateur réseau.
72
- La durée depuis le dernier démarrage du serveur.
- La taille et l'occupation des disques durs. Dans notre cas, lorsque 90 % de l'un des disques durs est
occupé, un e-mail sera envoyé à l'administrateur réseau.
Sur les postes clients, Nagios récupéra :
- La version du plugin qui envoie les informations au serveur Nagios : Si cette version n'est pas la dernière,
un e-mail sera envoyé à l'administrateur réseau.
- La taille et l'occupation des disques durs. Dans notre cas, lorsque 90 % de l'un des disques durs est
occupé, un e-mail sera envoyé à l'administrateur réseau.
- Pour Windows 10 : La taille du dossier "C:\Documents and Settings" qui stocke les données des
utilisateurs en local. Si ce dossier a une taille supérieure à 2Go, un e-mail sera envoyé à l'administrateur
réseau pour qu'il puisse vider ce répertoire.
Si Internet n'est plus disponible, un SMS sera envoyé à l'administrateur réseau.
Si le routeur ne répond plus (le réseau ne peut donc plus marcher), envoie d'un SMS à l'administrateur
réseau.
Nagios doit avoir un historique des paquets rejetés par le firewall (voir les règles d'autorisations / refus
dans la section précédente)
2.5.4. Choix d’une machine virtuelle
Après réflexion, nous avons décidé d'utiliser une machine virtuelle sur laquelle nous avons installé Nagios.
Une machine virtuelle permet d'utiliser plusieurs systèmes d'exploitation sur une même machine
simultanément. Les avantages d'utiliser une machine virtuelle sont assez nombreux, et correspondent bien
aux besoins de notre projet.
73
Tout d'abord cela nous permet d'avoir un PC de moins dans notre réseau, ce qui est assez agréable
d'utilisation étant donné que nous en avons déjà trois (plus les câbles, les imprimantes réseaux, le
routeur...).
Etant donné que le PC sur lequel est installée la machine virtuelle est mon PC personnel, cela m’a permis de
travailler très facilement en dehors des séances de projet avec l’encadreur.
Ensuite, il est beaucoup plus aisé de faire des sauvegardes d'une machine virtuelle que d'une machine
physique.
Au niveau sécurité, la mobilité de la machine est très intéressante : Si la machine physique tombe en
panne, on peut mettre la machine virtuelle très rapidement sur une autre machine physique ; les délais de
coupure en cas de panne sont réduits. Ce cas de figure s'est d'ailleurs présenté lors de notre projet, car la
machine de l’encadreur eut un dommage qui fut résolu grâce à l’image de la machine virtuelle sauvegardé:
Heureusement il nous a donc suffi de reprendre notre backup qui était assez récent et ainsi nous avons pu
limiter les dégâts.
Dans une société où les équipements réseaux sont très nombreux, les machines virtuelles peuvent faire
gagner de la place dans les locaux.
Cette solution permettra également, en fin de projet, de pouvoir récupérer la machine sur laquelle est
installé Nagios, qui pourra resservir ultérieurement.
Il existe plusieurs logiciels permettant de créer des machines virtuelles. Un des plus connus est Vmware.
Nous avions commencé par utiliser Oracle VirtualBox, chose qui n’a pas été évidente du fait de
l’incompatibilité face à certaines ressources lors de l’installation du fichier. La configuration était moins
aisée et plus sinueuse. Nous n'avons pas retenu ce logiciel à licence gratuite, développé par InnoTeck et
nous nous sommes penchés sur VMware WorkStation malgré la licence Vmware, qui est payante. C'est un
logiciel fonctionnant sur les machines hôtes Windows, Linux et Mac OS X, et qui peut supporter Windows
et Linux comme systèmes invités.
De plus, VMware WorkStation est très simple d'utilisation avec une interface intuitive. Cependant pour
administrer la machine virtuelle Linux sur laquelle est installé Nagios Core, nous l’avons installé dans
l’hyperviseur VirtualBox.
74
2.5.5. Choix de Linux
- Le réseau sur lequel nous avons travaillé se compose de quatre équipements : Un routeur sur
lequel tous les équipements sont reliés, une machine possédant Windows 2010 Server qui servira à
administrer le réseau à l’aide de Nagios XI, deux machines clientes, une sur Windows 2010 et une
sur Linux, et enfin une machine possédant Debian sur laquelle est installé Nagios Core.
- Le choix d'avoir utilisé Debian pour faire fonctionner Nagios n'est pas un hasard. En effet, Debian
est une version de Linux connu pour sa stabilité. De plus le logiciel Nagios a été développé sur ce
même système d'exploitation, donc nous ne craignions pas les problèmes d'incompatibilité.
- Lors de l'installation de Debian, nous avons choisi d'utiliser l'interface graphique XFCE.Cette
interface a pour particularité d'être très légère et assez pauvre en outils intégrés. Cela nous
convient parfaitement pour l'utilisation que nous allons en faire, car cette interface ne nécessite
que très peu de ressources, ce qui est une caractéristique cruciale étant donné que nous utilisons
une machine virtuelle.
2.5.6. Installation et configuration des équipements
Nous avons installé les services SNMP dans les paramètres du routeur et des machines Windows.
Nous avons également installé le service OpenSSH pour faciliter le contrôle à distance de la machine
Windows qui fera usage de l’agent NCPA.
Par la suite, nous avons connecté tous ces équipements sur le réseau local de l’O.A.P.I. à l’aide des câbles
Ethernet. Nous avons repéré par la suite, les adresses ip de l’imprimante (qui se connectait à l’ordinateur et
possédant une interface graphique d’administration), des ordinateurs physiques (sous Windows) et virtuels
(sous Linux) et du routeur qui les relie. En effet, l’adresse ip est essentiel pour la configuration réseau :
75
Figure 27 : Configuration d’un routeur
2.6. Cibles et bénéficiaires
La principale cible est la DSIP et les principaux bénéficiaires seront l’O.A.P.I. et ses prestataires.
2.7. Exigences du projet
2.7.1. Exigences fonctionnelles

Les objectifs fonctionnels sont les suivants :
• Mettre en place une interface de monitoring Nagios XI utilisateur assez simple et intuitif
pour les administrateurs réseau de l’O.A.P.I.
• Mettre sur pied une interface de monitoring en local Nagios Core pour un super utilisateur
(super administrateur).
76
• Les alertes doivent être dynamiques et inhérentes aux attentes des administrateurs face
aux capacités des équipements.
2.7.2. Exigences techniques
Nous savons depuis le chapitre 1 que notre projet est constituée de deux applications différentes
voire cousines l’une est d’un interface utilisateur (IU) plus travaillé Nagios XI et l’autre Nagios Core
Les deux applications sont développées de manière séparée et peuvent être aussi hébergées dans
des serveurs physiques différents ou dans le même serveur physique. Dans les lignes qui suivent
nous allons parler des exigences fonctionnelles de l’IU (Frontend) et des exigences fonctionnelles
du server web (Backend).
2.7.3. Exigences en matière de données
Les données insérées dans les plateformes doivent être vérifiés (notamment l’existence et la concordance
des adresses ip, des services, des commandes, des noms d’hôtes, etc.), sinon, la supervision sera factice.
2.7.4. Exigences de performances
Nous allons utiliser des navigateurs et un système Windows de haute performance (Windows 10)
pour l’implémentation de l’outil de monitoring. En effet, le test a d’abord été fait à l’aide de
Windows Xp et cela n’a pas fonctionné. Il faudra également vérifier le stockage de RAM accordé à
la machine virtuelle Debian qui héberge Nagios Core et de la machine physique sur laquelle nous
avons préféré utiliser Nagios XI en vue de ne pas ralentir la machine virtuelle à laquelle nous
n’avions accordé que 15 Go de RAM. Comme Nagios fonctionne tel une application web à l’aide
77
d’un navigateur et du serveur Apache, cela impactera sur le temps de réponse entre une demande
(requête) et la réponse doit être de 2 secondes au maximum.
78
Chapitre 3 : Méthodologie de travail
3.1. Pourquoi opter pour l’usage des méthodes agiles ?
Il existe quatre principaux types de méthodes, démarches en vue de produire un résultat :
- Les méthodes fonctionnelles basées sur les fonctionnalités du logiciel
- Les méthodes objet, basées sur différents modèles (statiques dans lequel on identifie les
objets, les propriétés et leurs relations, dynamiques dans lequel on décrit le comportement des
objets, leurs états et évènements et fonctionnels) de développement logiciel
- Les méthodes adaptatives ou Agiles, basées sur le changement des besoins
- Les méthodes spécifiques, basées sur les découpages temporels particuliers.
En vue de parfaire ce projet, nous nous sommes intéressés aux méthodes dites adaptatives
subdivisées en 2 parties notamment : les méthodes prédictives et les méthodes agiles.
Les méthodes prédictives correspondent à un cycle de vie du logiciel en cascade ou en V. Elles sont
basées sur une planification très précise et très détaillée, qui a pour but de réduire les incertitudes
liées au développement du logiciel. Cependant, cette planification rigoureuse ne permet pas
l’évolution dans les besoins des utilisateurs qui doivent donc être figés à l’étape de définitions des
besoins.
D’où le choix des méthodes agiles qui correspondent à un cycle de vie itératif considérant que les
changements (des besoins d’utilisateurs, de l’architecture, de la conception, de la technologie)
sont inévitables et doivent être pris en compte par les méthodes de développement.
Les avantages de cette méthodologie sont les suivants :
79
- Une forte participation entre les administrateurs réseau et les utilisateurs

- Des livraisons fréquentes de tests
- Une prise en compte de possibles changements dans les besoins des utilisateurs au cours
du projet.
Les méthodes agiles en opposition aux méthodes de gestion de projet traditionnelle, prônent une
organisation plus souple et adaptable parmi les plus populaires KANBAN, SAFE et SCRUM. Les
méthodes de gestion de projets dites méthodes agiles ont tous un point commun, elles sont
directement inspirées du manifeste agile édité en 2001, dont le but est d’améliorer leur processus
et à réduire le taux d’échec.
3.2. Choix de la méthode agile utilisée : SCRUM
3.2.1. Principe de SCRUM
Figure 28 : SCRUM Process
80
3.2.2. Phases préliminaires du projet
3.2.2.1. Avant-projet
Durant cette étape, nous avons détaillé, le périmètre, la base du contenu du produit à développer,
une analyse de haut niveau. C’est durant cette phase que nous avons approfondi l’analyse ou la
conception de modèle présentée plus haut concernant le point suivant : Objectifs de Nagios et
fonctionnalités que nous souhaiterions voir dans Nagios. C’est également ici que l’on détermine
quelles seront les principaux outils à superviser.
Il s’agit de la phase d’avant-jeu de SCRUM. Le projet est décrit dans ses grandes lignes dans un
document dont la finalité est de :
- S’assurer que le projet répond à des besoins réels.

- De communiquer sur le projet auprès des utilisateurs concernés.
- De susciter des réactions permettant de conforter le projet.
3.2.2.2. Expression des besoins
L'avant-projet permet de s'assurer de la pertinence du projet, des besoins de l’utilisateur. Il

convient ensuite, pour le maître d'ouvrage, d'exprimer tous les besoins en termes de
fonctionnalités. En général, cette étude donne lieu à un document qui doit être validé, non
seulement par la direction de projet, mais aussi (et surtout) par les utilisateurs concernés du
produit envisagé).
Le Product Owner, qui est ici l’O.A.P.I, définit ses besoins et les fonctionnalités attendues sous
forme d’user story (histoire de l’utilisateur) qui sera organisé en Product backlog.
81
Pour se faire, nous avons décrit l’histoire de l’utilisateur en utilisant le langage, le vocabulaire et la
terminologie de l’usager.
Chaque user story est donc constituée du :
- Nom de l’application décrivant de manière succincte : la fonctionnalité première de cette

dernière : Nagios
- Nom de l’utilisateur : Agent technique de l’O.A.P.I
- L’importance : Monitoring réseau
- Estimation du travail nécessaire : repertorier et configurer tous les services et outils à
superviser.
- Test simple ou démonstration
3.2.2.3. La hiérarchisation en Product backlog :
Le product Backlog est un miroir de ce qu’il fut faire pour réaliser les besoins du client et réaliser
l’user story :
- Une adresse locale qui donnera accès à Nagiosxi sur n’importe quel PC du réseau
- Le champ de visibilité de la documentation (Nagios possède une documentation populaire et

vérifiée)
- L’affichage de l’heure des différentes analyses (GMT de préférence)
- Description des services et commandes présents dans chaque hôte
Ce Product Backlog va constamment évoluer en fonction des besoins de l’utilisateur.
Cette première phase s’est déroulée en un mois incluant à la fois :
82
- La phase d’insertion et d’analyse des besoins de l’utilisateur (membres de la communauté

urbaine) et fonctionnalités
- La phase d’analyse des ressources nécessaires
3.2.3. Phases d'études
3.2.3.1. Expression détaillée des besoins
Il s'agit de la suite logique de la phase d'expression des besoins. En effet, pour la réalisation du
produit envisagé, il est nécessaire d'avoir la liste détaillée des fonctionnalités requises. Cette
phase est normalement conduite par la maîtrise d'ouvrage, mais il est usuel d'y associer la maîtrise
d'œuvre, dont l'intervention permettra de compléter utilement un certain nombre de "blancs" ou
de "silences".
Cette partie nous permit formuler la User Story qui fut essentiellement constituée de l’option d’un
accès à la documentation simple, à vil prix.
Cette phase se conclut par la production d'un document. Constamment, chaque membre voire
chaque équipe produisait un rapport d’activité pour juger du taux d’avancement et de
consommation de délai observé.
En effet, comme soulevé plus haut, la réalisation des éléments du PRODUCT BACKLOG s’est
effectuée dans des SPRINTS des développements itératifs courts de 2 à 4 semaines. Durant les
sprints, il y a des mêlées c’est-à-dire des Scrums effectuées chaque jour, en général debout, pour
s’assurer de l’avancée du projet, de la qualité des livrables et du respect des délais.Durant ces
sprints, il y a eu de la planification, des configurations, des tests qualités, avant la livraison du
produit ou de l’option de Nagios testé. L’ensemble des livraisons des sprint cumulé se nomme le
sprint backlog. Un Sprint commençait par un sprint planning meeting dans lequel on prend les
éléments prioritaires du PRODUCT BACKLOG.
83
Ensuite, chaque 3 jour, se faisaient des scrums (réunion courte) : L’équipe de projet constituée par
mon encadreur et moi nous rencontrons en présentiel ou en distanciel pendant 1heure dans les
meetings de mêlées appelés meeting scrum ou weekly meeting. Durant le déroulement de ces
weekly meeting, Le scrum master (l’encadreur dans le cas présent) fixait ce qui était déjà fait et ce
qui restait à faire. Je devais dire ce qui a été fait en semaine et les éventuels problèmes
rencontrés, ce que je vais faire par la suite et si je rencontre des difficultés pour effectuer le travail
à faire
3.2.3.2. Analyse fonctionnelle
Il s’agit d’un travail important de la maîtrise d'œuvre, puisqu'il s'agit de concevoir sur le plan
fonctionnel, le produit à réaliser. L'analyse fonctionnelle partira de l'expression détaillée des
besoins et en déduira l'architecture du produit à réaliser. Il y a souvent confusion entre cette
phase et la précédente. La phase d'expression détaillée des besoins est une liste de ces besoins,
tandis que l'analyse fonctionnelle est une construction conceptuelle du produit. Les résultats de
l'analyse fonctionnelle sont traduits dans un cahier des charges fonctionnel, validé par la maîtrise
d'ouvrage.
C’est ici que nous nous référons aux ressources sus-évoquées en apportant des compléments si
nécessaires. D’où le caractère évolutif suivant les besoins de l’utilisateur.
3.2.3.3. Etude technique
Les contraintes techniques sont ici examinées par la maîtrise d'œuvre qui décrira l'architecture
technique du produit Nagios, les moyens et ressources nécessaires à l’implémentation de celui-ci.
Les résultats de l'étude technique sont consignés dans un cahier des charges techniques qui
représentait ici, mon bloc-note, à valider par l’encadreur.
84
Nous nous sommes ici attelés sur
3.2.3.4. L’estimation du coût financier (évaluation financière du projet)
Nous n’avons pas dépensé quoique ce soit du fait de l’usage de la version gratuite de Nagios (Nagios Core)
et de l’essai gratuit de sa version payante (Nagios XI).
3.2.3.5. Les contraintes du projet
En termes de contraintes temporelles, ce projet devait être clos en quatre mois.
3.2.3.6. Les livrables, les extrants et intrants
Dans ce cas, le livrable est notre logiciel de supervision Nagios
Les extrants dans le contexte de ce travail sont représentées par les services et les données issus
de la supervision réseau.
Les intrants sont également des informations des hôtes, commandes et services à monitorer.
3.2.4. Phases de réalisation

3.2.4.1. Lancement du projet
Nous n’avons pas négligé la communication sur le projet auprès des utilisateurs proches ou
lointains du futur produit et nous avions vérifié que l’essentiel pour l’exécution du projet y était.
3.2.4.2. Configuration
85
C'est une phase dense pour la maîtrise d'œuvre qui doit vérifier que la planification prévue est
strictement suivie, mais qui doit aussi parer aux aléas inévitables : maladies, congés des
développeurs, pannes de ressources, déménagements de locaux, coupures de réseaux, etc.... Ces
aléas sont courants (bien plus que l'on croit) et ils doivent être pris en compte dans l'analyse des
risques.
En effet, la phase de configuration et d’implémentation doit prévoir :
-Une relation permanente avec la maîtrise d'ouvrage (pas d'effet "tunnel") pour l'informer de
l’avancement des travaux.
-Une mise en œuvre de la documentation relative au projet.
3.2.5. Phases post-production
3.2.5.1. Mise en œuvre
La phase de mise en œuvre consiste en l'installation dans les locaux et sur les matériels du
commanditaire du produit logiciel développé. La phase comprend également généralement la
formation des utilisateurs finaux.
3.2.5.2. Maintenance
Cette phase recouvre toutes les mesures à prendre pour que l'application installée continue à
fonctionner et puisse évoluer.
Cette phase peut faire l'objet d'un contrat de prestation complémentaire avec la maîtrise d'œuvre.
Cependant, dans ce cas, elle est entièrement fournie par l’agent technique de l’O.A.P.I.
86
3.2.5.3. Problèmes existants
Les problèmes les plus rencontrées sont les suivants
- L’utilisation de Nagios nécessite une prise en main et n’est pas facilement accessible à tous.
- Tout équipement informatique de l’organisation n’est pas forcément dans le réseau. Il existe des
machines (tels que certaines imprimantes, etc.) qui ne sont pas connectées au réseau. Dans ce cas,
l’outil s’avèrera inefficace.
- Nagios XI est un logiciel dont le prix d’achat est énormément élevé.
- Le souci du manque de compatibilité entre certaines versions de Windows et Nagios (sachant que
Nagios était initialement développé sur Linux).
Somme toute, notre feuille de route tout au long de ce projet a été la méthodologie SCRUM
accompagnés d’une pluralité d’études nous aidant dans le management, la conception et la
réalisation de ce projet de monitoring du réseau de l’O.A.P.I.
87
Chapitre 4 : Réalisation, résultats et discussions
Effectivement, l’on se demanderait bien si cet outil marche effectivement et n’a pas que le vent
en poupe. Nombre de moyens nous pousse à nous en assurer à regarder les prix qui lui sont
décernés :
• 2016 : Nagios est nommée « Network Monitoring Application of the Year » ;

• 2016 encore : Nagios Core est sélectionné « Project of the Week » en décembre ;
• 2015 : Nagios se voit décerner le titre de Top IT Infrastructure Monitoring Tools » par IT
Central Station ;
• Nagios est aussi nommé six fois consécutives « Best Monitoring Application » par le « Linux
Journal » .
D’entrée de jeu, définissons le processus d’installation de Nagios Core puis de Nagios XI.
4.1. Présentation du champ de travail
4.1.1. Matériel, plugins et agents utilisés
Comme outils de développement, nous avons utilisé des ordinateurs comme outils principaux avec
les caractéristiques suivantes :
Système d’exploitation Windows 10

Linux Debian
Processeur Intel Core i7
Agent Client utilisé NCPA (car la majorité des postes de travail à
l’O.A.P.I. sont sous windows)
88
Service téléchargé OpenSSH

SNMP
Imprimante en réseau Laser Jet 4600 pro
Routeur TP-link
Navigateur Firefox
Tableau 4 : Matériels, plugins et agents utilisés
4.1.2. Objectifs de conception
Les objectifs de la conception sont les suivants :
• Mettre sur pied un outil de monitoring réseau sécurisé.

• Obtenir des alertes lors d’un disfonctionnement ou d’un risque
• Faciliter les maintenances curatives et préventives au sein de l’O.A.P.I
4.1.3. Interface Utilisateur (Frontend)
Nagios XI offre un interface utilisateur plus agréable bien qu’étant accessible également en ligne
de commande tout comme Nagios Core. En effet, la configuration de Nagios Core se fait
entièrement en ligne de commande car n’est point doté d’un interface utilisateur tel que Nagios
XI, la version payante de Nagios.
4.1.4. Environnement de mise en œuvre du système actuel
Une fois l’installation et la configuration de IU terminé, l’application pourra être déployé dans le
même serveur physique ou dans des serveurs physiques différents. On peut aussi utiliser des
serveurs virtuels pour le même déploiement. Le logiciel sera ainsi disponible dans le monde entier
en utilisant un téléphone intelligent (smartphone), une tablette ou alors un ordinateur connecté
au réseau.
89
4.1.5. Logiciels additionnels utilisés
Dans le déploiement de logiciel, nous allons utiliser certains agents, plugins et appliance.
4.2. Nagios Core
4.2.1. Installation de Nagios Core sur votre serveur Debian
Le processus d’installation de Nagios Core sur un système GNU/Linux depuis les sources peut se
détailler en quatre grandes étapes :
• La préparation du serveur, qui va héberger le service Nagios ;

• Le téléchargement et la compilation des sources Nagios ;
• L’installation de l’arborescence Nagios ;
• La vérification de la connexion à l’interface d’administration de Nagios.
La machine cible est une Debian Stretch 9.6.0 en version minimale, disponible au téléchargement
directement sur le site de Debian. Voici, par exemple, pour une architecture amd6 disponible sur :
https://www.debian.org/releases/stretch/debian-installer
Installez Debian par internet
90
Pendant le processus d’installation, dans un premier temps, nous ne sélectionnons que le minimum
requis, à savoir :
• le serveur SSH, pour se connecter via un terminal distant ;

• les composants usuels du système, qui contiennent les librairies C les plus communément
employées.
Figure 29 : Etape d’installation de serveurs essentiels pour Debian
Quelques packages supplémentaires sont nécessaires afin de profiter pleinement de toutes les capacités de
Nagios.
Nous allons donc installer quelques dépendances via diverses commandes que nous verrons par la suite :
i) Installer le serveur Apache
Pour accéder à l’interface Web de gestion de Nagios, nous avons besoin d’un serveur Apache et de
l’interpréteur PHP.
apt-get install apache2 php php-gd php-imap php-curl php-mcrypt
Pour voir quels packages cette commande installe, vous pouvez voir les logs en téléchargeant https://s3-
eu-west-1.amazonaws.com/course.oc-static.com/courses/2035786/log_install_P2C1_1.log
91
ii) Installation des librairies Perl
Pour exploiter au maximum les possibilités offertes par les plugins de Nagios, nous avons besoin de
quelques librairies Perl supplémentaires :
apt-get install libxml-libxml-perl libnet-snmp-perl libperl-dev libnumber-

format-perl libconfig-inifiles-perl libdatetime-perl libnet-dns-perl
Nous pourrons noter par exemple les librairies perl SNMP. En effet sans l'inclusion de ces
librairies, le plugin SNMP de Nagios ne pourra pas fonctionner !
Pour voir quels packages cette commande installe, vous pouvez voir les logs en téléchargeant
https://s3-eu-west-1.amazonaws.com/course.oc-
static.com/courses/2035786/log_install_P2C1_2.log
iii) Installation des librairies graphiques
Nagios nécessite également quelques librairies graphiques :
apt-get install libpng-dev libjpeg-dev libgd-dev
iv) Installation des outils de compilation standards
Enfin pour installer Nagios et ses plugins vous aurez besoin des outils de compilation standards et
du package unzip :
En effet, Nagios est un programme compilé en C, donc le compilateur GCC et ses outils associés
MAKE et AUTOCONF sont indispensables, et les sources sont téléchargées souvent dans un
format compressé, donc UNZIP est nécessaire également.
apt-get install gcc make autoconf libc6 unzip
92
v) Création de l'environnement Nagios
Il nous reste juste quelques ajouts d’ordre administratif à effectuer… et notamment, la création de
l’environnement Nagios, avec son utilisateur, son groupe et son répertoire de travail. En effet,
Nagios est un programme qui n'a pas besoin de tourner sous root. Pour ajouter l’utilisateur
nagios sur le système, saisissez la commande suivante :
useradd -m -p $(openssl passwd nagios) nagios
Cette commande crée l’utilisateur nagios sur le système et initie son mot de passe à nagios. Bien
entendu, il vous faudra renforcer ce mot de passe sur une machine de production.
Par ailleurs, il est également nécessaire de partager un groupe commun entre l’utilisateur nagios et
l’utilisateur www-data (qui fait tourner le serveur Web apache2) afin, notamment, de permettre
l’administration de Nagios depuis l’interface Web. Saisissons les commandes suivantes :
groupadd nagcmd
usermod -a -G nagcmd nagios
usermod -a -G nagcmd www-data
1. La première commande crée un groupe nagcmd, qui servira à exécuter des commandes
Nagios depuis l’interface Web.
2. La seconde commande ajoute l’utilisateur nagios dans le groupe nagcmd.
3. La troisième commande ajoute l’utilisateur www-data, sous lequel tournent les processus du
serveur Web Apache2 dans le groupe nagcmd.
La dernière commande à passer est celle pour la création d’un répertoire de stockage pour tous
les téléchargements :
mkdir /home/nagios/downloads
VOILA, LE SERVEUR EST MAINTENANT PRET A RECEVOIR NAGIOS ET SES

COMPOSANTS.
4.2.2. Téléchargement et compilation des sources de Nagios
Pour télécharger les sources de Nagios Core, il faut se rendre directement sur le site de Nagios :
http://www.nagios.org. Dès la page d’accueil, vous trouverez un lien vers le téléchargement de
Nagios Core.
Un clic sur ce lien vous amène sur une page vous proposant de choisir votre système d’exploitation.
En ce qui vous concerne, ce sera bien entendu Linux et son fidèle TUX !
93
Figure 30 : Présentation du site web Nagios favorisant le téléchargement du VmWare ou de la version Linux,
Microsoft de Nagios
Dès lors, nous choisissons notre système d'exploitation pour installer Nagios Core.
Nagios fournit une documentation guide pour l’installation de Nagios permettant de télécharger les
sources à l’aide du lien suivant https://assets.nagios.com/downloads/nagiosxi/docs/Installing-Nagios-XI-
Manually-on-Linux.pdf
Il concerne principalement la version XI de Nagios.
Pour obtenir de la documentation sur Nagios Core et notamment sur le processus d’installation
pour Debian, nous nous sommes rendus sur cette page https://support.nagios.com/kb/article/nagios-
core-installing-nagios-core-from-source-96.html#Debian
94
Figure 21 : Vue de l’interface d’accueil du guide d’installation de Nagios Core.
Nous avons installé Nagios Core depuis les sources à partir de cette page.
En effet, dès lors, vous pouvez maintenant continuer le processus de téléchargement des sources et
cliquer sur le bouton « Download ». Vous arrivez alors sur un pop-in, qui vous propose de donner
vos coordonnées si vous souhaitez être informé des évolutions des produits Nagios. Cliquer sur «
Skip » vous évite de donner votre adresse de messagerie, si vous ne le souhaitez pas. Finalement,
tout ceci vous amène enfin à la page de téléchargement des sources de Nagios Core :
95
Figure 22 : Vue de l’interface après téléchargement
Dans la suite, nous allons vous expliquer l’ensemble des processus restant :
- Choisissez votre lien de téléchargement
- Effectuez un clic droit sur le lien nagios-X.X.X.tar.gz pour copier le lien dans le presse-
papier, puis saisissez la commande suivante dans votre terminal depuis le
répertoire/home/nagios/downloads. En l’occurrence ici, la version téléchargée est la 4.4.2.
Vous saisissez :
cd /home/nagios/downloads
wget https://assets.nagios.com/downloads/nagioscore/releases/nagios-4.4.2.tar.gz
Le résultat de cette commande doit ressembler à :
root@NagiosDebian:/home/nagios/downloads# wget
https://assets.nagios.com/downloads/nagioscore/releases/nagios-4.4.2.tar.gz
--2018-11-23 10:16:53--
https://assets.nagios.com/downloads/nagioscore/releases/nagios-4.4.2.tar.gz
Résolution de assets.nagios.com
(assets.nagios.com)…2600:3c00::f03c:91ff:fedf:b821, 72.14.181.71
Connexion à assets.nagios.com
(assets.nagios.com)|2600:3c00::f03c:91ff:fedf:b821|:443… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 11301454 (11M) [application/x-gzip]
Sauvegarde en : `nagios-4.4.2.tar.gz`
nagios-4.4.2.tar.gz
100%[==============================================================>] 10,78M
956KB/s in 13s
96
2018-11-23 10:17:06 (880 KB/s) — `nagios-4.4.2.tar.gz` sauvegardé

[11301454/11301454]
- Décompressez l’archive des sources de Nagios avec la commande suivante :
tar -zxvf nagios-4.4.2.tar.gz
Cette commande crée un répertoire nagios-4.4.2 dans le répertoire courant et y décompresse

toutes les sources.
- Positionnez-vous dans ce répertoire avec la commande suivante :
cd nagios-4.4.2
La compilation des sources Nagios passe par un script configure. Celui-ci permet, entre autres, de
s’assurer que les éléments nécessaires sont présents sur le système, et de passer quelques
paramètres au processus de compilation.
- Dans notre cas, nous allons indiquer deux choses : où se situe le répertoire par défaut de
configuration des sites Web, et où se situe le groupe nagcmd que vous souhaitez configurer… le
tout, avec la commande suivante (sur la même ligne !) :
./configure --with-httpd-conf=/etc/apache2/sites-enabled --with-command-

group=nagcmd
Si tout se passe bien, le résultat de cette commande doit ressembler à :
*** Configuration summary for nagios 4.4.2 2018-08-16 ***:

General Options:
-------------------------
Nagios executable: nagios
Nagios user/group: nagios,nagios
Command user/group: nagios,nagcmd
Event Broker: yes
Install ${prefix}: /usr/local/nagios
Install ${includedir}: /usr/local/nagios/include/nagios
Lock file: /run/nagios.lock
Check result directory: /usr/local/nagios/var/spool/checkresults
Init directory: /lib/systemd/system
Apache conf.d directory: /etc/apache2/sites-enabled
Mail program: /bin/mail
Host OS: linux-gnu
IOBroker Method: epoll
Web Interface Options:
------------------------
HTML URL: http://localhost/nagios/
CGI URL: http://localhost/nagios/cgi-bin/
Traceroute (used by WAP): /usr/sbin/traceroute
Review the options above for accuracy. If they look okay,
type 'make all' to compile the main program and CGIs.
97
- Pour lancer la compilation, exécutez la commande suivante :
make all
Encore une fois, si tout se passe bien, la sortie de cette commande doit ressembler à :
*** Support Notes *******************************************

If you have questions about configuring or running Nagios,
please make sure that you:
- Look at the sample config files
- Read the documentation on the Nagios Library at:
https://library.nagios.com
before you post a question to one of the mailing lists.
Also make sure to include pertinent information that could
help others help you. This might include:
- What version of Nagios you are using
- What version of the plugins you are using
- Relevant snippets from your config files
- Relevant error messages from the Nagios log file
For more information on obtaining support for Nagios, visit:
https://support.nagios.com
*************************************************************
Enjoy.
Il ne nous reste que quelques commandes à passer pour finaliser l’installation.
4.2.3. Installation de l’arborescence et des fichiers Nagios sur votre serveur

i) Création de l'arborescence Nagios
- Afin de créer l’arborescence Nagios et d’y installer les fichiers binaires, lancez la commande
suivante :
make install
- Nous pouvons vérifier que l’arborescence Nagios est créée avec la commande suivante :
ls -lrtha /usr/local/nagios
Cette commande affiche la liste des premiers répertoires de Nagios :
drwxrwsr-x 11 root staff 4,0K nov. 23 10:37..

drwxrwsr-x 2 nagios nagios 4,0K nov. 23 10:37 bin
drwxrwsr-x 2 nagios nagios 4,0K nov. 23 10:37 sbin
drwxrwsr-x 14 nagios nagios 4,0K nov. 23 10:37 share
drwxrwsr-x 2 nagios nagios 4,0K nov. 23 10:37 libexec
drwxr-sr-x 7 root staff 4,0K nov. 23 10:37 .
drwxrwsr-x 4 nagios nagios 4,0K nov. 23 10:37 var
98
ii) Installation du service Nagios
- Ensuite, vous allez installer le service Nagios, c’est-à-dire les composants nécessaires au
démarrage de Nagios avec la machine. Lancez la commande suivante :
make install-daemoninit
Cette commande vous retournera :
/usr/bin/install -c -m 755 -d -o root -g root /lib/systemd/system

/usr/bin/install -c -m 755 -o root -g root startup/default-service
/lib/systemd/system/nagios.service
Created symlink /etc/systemd/system/multi-user.target.wants/nagios.service →
/lib/systemd/system/nagios.service.
*** Init script installed ***
• Vous pouvez ici constater la création du fichier de service unit nagios.service dans
l’arborescence de systemd. Ainsi que la création du lien symbolique dans la « target multi-
user », afin de démarrer le service automatiquement avec le système.
iii) Installation du pipe de Nagios
L’étape suivante est d’installer le pipe de Nagios.
- Lancez la commande suivante :
make install-commandmode
Observez le résultat de cette commande :
/usr/bin/install -c -m 775 -o nagios -g nagcmd -d /usr/local/nagios/var/rw

chmod g+s /usr/local/nagios/var/rw
*** External command directory configured ***
Vous pouvez notamment constater qu’un répertoire rw a été créé dans l’arborescence Nagios. Les
droits de lecture et d’écriture sont attribués à l’utilisateur nagios et au groupe nagcmd(que vous
avez indiqué lors de l’exécution du script configure). Par ailleurs la présence du sticky bit (via la
commande chmod g+s) permet de distribuer l’ID du groupe nagcmd à tous les fichiers et répertoires
qui seraient créés dans ce répertoire rw.
iv) Installation des fichiers de configuration de Nagios
- Pour installer les fichiers de configuration de base de Nagios, lancez la commande suivante :
make install-config
99
Le résultat de cette commande indique la liste des fichiers de configuration déposée dans
l’arborescence, comme ci-dessous :
/usr/bin/install -c -m 775 -o nagios -g nagios -d /usr/local/nagios/etc

/usr/bin/install -c -m 775 -o nagios -g nagios -d /usr/local/nagios/etc/objects
/usr/bin/install -c -b -m 664 -o nagios -g nagios sample-config/nagios.cfg
/usr/local/nagios/etc/nagios.cfg
/usr/bin/install -c -b -m 664 -o nagios -g nagios sample-config/cgi.cfg
/usr/local/nagios/etc/cgi.cfg
/usr/bin/install -c -b -m 660 -o nagios -g nagios sample-config/resource.cfg
/usr/local/nagios/etc/resource.cfg
/usr/bin/install -c -b -m 664 -o nagios -g nagios sample-config/template-
object/templates.cfg /usr/local/nagios/etc/objects/templates.cfg
object/commands.cfg /usr/local/nagios/etc/objects/commands.cfg
object/contacts.cfg /usr/local/nagios/etc/objects/contacts.cfg
object/timeperiods.cfg /usr/local/nagios/etc/objects/timeperiods.cfg
object/localhost.cfg /usr/local/nagios/etc/objects/localhost.cfg
object/windows.cfg /usr/local/nagios/etc/objects/windows.cfg
object/printer.cfg /usr/local/nagios/etc/objects/printer.cfg
object/switch.cfg /usr/local/nagios/etc/objects/switch.cfg
iv) Installation de l'interface Web d'administration
- Pour installer l’interface Web d’administration de Nagios, lancez la commande suivante :
make install-webconf
Cette commande dépose le fichier nagios.conf dans l’arborescence Apache

(/etc/apache2/sites-enabled).
- Pour fonctionner correctement, l’interface d’administration de Nagios nécessite les

modules rewrite et cgi d’Apache. Pour les activer, lancez les commandes suivantes :
a2enmod rewrite
a2enmod cgi
Ces commandes vous demandent de redémarrer le service Apache afin d’être prises en compte.
Mais vous allez retarder cette instruction, car vous n’en avez pas encore terminé avec la
configuration de Nagios.
100
v) Configuration de l'accès Apache
Pour accéder à l’interface d’administration de Nagios, il est nécessaire de configurer un accès

Apache htaccess. Lancez la commande suivante :
htpasswd -cb /usr/local/nagios/etc/htpasswd.users nagiosadmin pass
Cette commande crée le fichier htaccess dans l’arborescence du site d’administration

(/usr/local/nagios/etc/htpasswd.users) et configure un premier utilisateur comme ci-
dessous :
• login : nagiosadmin ;
• password : pass (encore une fois, ce mot de passe est à renforcer dans un contexte de
production).
vi) Configuration des droits pour la configuration
La configuration Nagios s’effectuera directement avec le compte nagios, pas besoin d’être root
pour cela. Il faut tout de même attribuer les droits sur l’arborescence Nagios à l’utilisateur nagios.
Pour ce faire, lancez la commande suivante :
root@NagiosDebian:~# chown -R nagios:nagcmd /usr/local/nagios
Cette commande attribue, de manière récursive, la propriété à l’utilisateur nagioset au

groupe nagcmd de l’arborescence Nagios (/usr/local/nagios).
vii) Redémarrage d’Apache
Dernières opérations :
- Il faut redémarrer le service Apache et démarrer le service Nagios. Pour cela, lancez les
commandes suivantes :
systemctl restart apache2

systemctl start nagios
Si tout se passe bien, ces deux commandes ne renvoient rien en sortie standard.
Pour vérifier que Nagios tourne, lancez la commande suivante :
ps -edf | grep nagios
Parmi les lignes résultat, vous devriez trouver celles-ci :
nagios 29558 1 0 11:04 ? 00:00:00 /usr/local/nagios/bin/nagios -d

101
nagios 29559 29558 0 11:04 ? 00:00:00 /usr/local/nagios/bin/nagios --worker

/usr/local/nagios/var/rw/nagios.qh
nagios 29563 29558 0 11:04 ? 00:00:00 /usr/local/nagios/bin/nagios -d
- Debian 9 étant sous systemd, vous pouvez aussi lancer la commande suivante (sans oublier le
sudo pour obtenir le droit de le faire) :
systemctl status nagios
Le retour de cette commande est complet, car il permet non seulement de s’assurer que le service a
bien pour statut active, mais aussi de consulter les dernières lignes des fichiers de traces du service
Nagios. En l’occurrence, vous devriez obtenir quelque chose comme :
wproc: early_timeout=0; exited_ok=1; wait_status=32512; error_code=0;

wproc: stderr line 01: /bin/sh: 1: /bin/mail: not found
wproc: stderr line 02: /usr/bin/printf: erreur d'écriture: Relais brisé (pip
SERVICE ALERT: localhost;Swap Usage;CRITICAL;HARD;1;(No output on stdout) stde
SERVICE ALERT: localhost;Total Processes;CRITICAL;HARD;1;(No output on stdout)
Il semblerait donc que Nagios envoie déjà quelques alertes de supervision !
4.2.4. Connectons-nous une première fois à l’interface d’administration de Nagios
Allez immédiatement vérifier cet état de fait en consultant l’interface d’administration de Nagios.
Pour cela, ouvrez un navigateur et connectez-vous sur l’adresse IP de votre serveur Nagios via une
URL du type : http://@ipServeurNagios/nagios (par exemple
http://172.16.10.10/nagios ). Le site d’administration vous propose alors de vous connecter
en renseignant votre login et votre password. Souvenez-vous que dans le processus d’installation,
vous avez indiqué les accès suivants :
• login : nagiosadmin ;
• password : pass.
Une fois ces identifiants saisis, vous arrivez normalement sur la page d’accueil de l’interface Web
d’administration de Nagios :
102
figure 23 : Interface d'administration de Nagios Core
Profitons de ce premier accès à l’interface Nagios pour cliquer sur le « Alerts » dans le menu «
Reports », sur la gauche de la page.
figure 24 : Alertes de Nagios
Aïe ! Effectivement, Nagios relève déjà quelques soucis. Mais en observant un peu mieux la
description de ces lignes, nous pourrons observer qu’elles ont toutes une cause commune : "No such
file or directory".
103
Et la cause commune de ces erreurs est simple : Nagios cherche des fichiers qui n’existent pas dans
son arborescence. C’est normal, ces fichiers sont les plugins standards de Nagios, que nous n'avons
pas encore installés.
En résumé
Nous avons étayé la première étape de l'installation de Nagios Core, c’est-à-dire :
• La préparation de son serveur d'hébergement ;

• La compilation de ses sources ;
• La création de son arborescence ;
• La configuration de son interface Web d'administration. La seconde étape consiste justement
à compiler et installer les plugins. Ces actions viendront corriger d'elles-mêmes les erreurs
affichées sur l'interface. C'est ce que je vous propose de réaliser dans le prochain chapitre !
• Nous allons installer les plugins standards de Nagios. Ces plugins sont dits « standards »
parce que développés et maintenus par l’équipe de développement Nagios, contrairement
aux plugins dits « communautaires », mis à disposition par la communauté des utilisateurs
Nagios via la plateforme https://exchange.nagios.org.
• Une fois les plugins installés, nous définirons des alias de commande pour faciliter leur
utilisation. Bien que cette étape ne soit pas obligatoire, elle pourra vous faire gagner du
temps dans la suite du cours.
4.2.5. Préparation du serveur Debian à recevoir les plugins standards de Nagios
Nagios précise tout de même quelques spécificités concernant l’utilisation de plugins particuliers.
Vous pouvez retrouver ces informations ainsi que le processus d’installation des plugins sur le lien :
https://support.nagios.com/kb/article/nagios-plugins-installing-nagios-plugins-from-source-
569.html
Vous pourrez notamment y trouver les instructions pour des plugins spécifiques comme, par
exemple, la gestion d’un LDAP, d’une base de données MySQL ou encore de Samba :
104
Plugins requis pour installer les plugins standards
Quoi qu’il en soit, le processus d’installation des plugins va aussi vérifier l’installation des
composants nécessaires, signaler s’il en manque ou si tel ou tel plugin ne peut être compilé.
4.2.6. Téléchargement et compilation les sources des plugins standards de Nagios
Les sources des plugins standards de Nagios sont également disponibles gratuitement sur le site
de Nagios : https://www.nagios.org.
Le chemin pour accéder au téléchargement est quasiment le même que celui pour les sources de
Nagios. L’écran final vous propose le lien direct vers le fichier archive :
figure 25 : Lien vers le fichier archive
105
- Effectuez un clic droit sur le lien de téléchargement des sources nagios-plugins-X.X.X.tar.gz, et

copiez l’adresse dans le presse-papier.
À partir de votre terminal d’accès au serveur Nagios, téléchargez les sources dans le
répertoire/home/nagios/downloads avec les commandes suivantes :
cd /home/nagios/downloads
wget https://nagios-plugins.org/download/nagios-plugins-2.2.1.tar.gz
Si tout se passe bien, les sources des plugins standards (ici, ceux de la version 2.2.1) sont
téléchargées sur le serveur :
Résolution de nagios-plugins.org (nagios-plugins.org)… 72.14.186.43

Connexion à nagios-plugins.org (nagios-plugins.org)|72.14.186.43|:443… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 2728818 (2,6M) [application/x-gzip]
Sauvegarde en : `nagios-plugins-2.2.1.tar.gz`
nagios-plugins-2.2.1.tar.gz
100%[==============================================================>] 2,60M 896KB/s in 3,0s
2018-11-23 2:25:15 (896 KB/s) — `nagios-plugins-2.2.1.tar.gz` sauvegardé [2728818/2728818]
- Décompressez l’archive des sources via la commande suivante :
tar -zxvf nagios-plugins-2.2.1.tar.gz
- Cette commande crée un répertoire nagios-plugins-2.2.1 dans le répertoire courant et y

décompresse les sources. Positionnez-vous dans ce nouveau répertoire via la commande
suivante :
cd nagios-plugins-2.2.1/
Ce que nous allons faire ressemble au processus de compilation des sources de Nagios, que nous
avons vu au chapitre précédent. Il est nécessaire de lancer le script configure pour compiler les
106
plugins standards de Nagios. Ce script permet notamment de s’assurer que les éléments
nécessaires sont présents sur le système, et de régler quelques paramètres.
- Ici, en l’occurrence, vous allez indiquer qui sont, par défaut, l’utilisateur et le groupe
propriétaire de ces plugins, en lançant le script :
./configure --with-nagios-user=nagios --with-nagios-group=nagcmd
Si tout se passe bien, le résultat de cette commande doit produire une sortie comme ci-dessous :
configure: creating ./config.status

[...]
config.status: executing po-directories commands
config.status: creating po/POTFILES
config.status: creating po/Makefile
Si vous le souhaitez, vous pouvez retrouver toutes les informations recensées par le
scriptconfigure dans le fichier suivant :
more /home/nagios/downloads/nagios-plugins-2.2.1/config.log
Ce fichier est assez imposant, mais détaille précisément toutes les vérifications effectuées sur le
système et contiendra notamment les éventuelles lignes expliquant pourquoi tel ou tel plugin n’a
pas pu être compilé. Souvent, la raison est que telle ou telle librairie n’est pas présente sur le
système.
This file contains any messages produced by compilers while

running configure, to aid debugging if configure makes a mistake.
It was created by nagios-plugins configure 2.2.1, which was
generated by GNU Autoconf 2.63. Invocation command line was
./configure --with-nagios-user=nagios --with-nagios-group=nagcmd
hostname = NagiosDebian
uname -m = x86_64
uname -r = 4.9.0-8-amd64
107
uname -s = Linux
uname -v = #1 SMP Debian 4.9.130-2 (2018-10-27)
Bref : si, à terme, vous cherchez un plugin standard qui n’est pas compilé, référez-vous à ce fichier,
il vous indiquera sûrement pourquoi !
Le reste du processus est identique. Dans un premier temps, lancez la commande suivante pour
compiler les binaires :
make
Cette commande compile tous les plugins compatibles avec le système et affiche une sortie
comme ci-dessous :
make[2]: on quitte le répertoire `/home/nagios/downloads/nagios-plugins-2.2.1/plugins-root`

Making all in po
make[2]: on entre dans le répertoire `/home/nagios/downloads/nagios-plugins-2.2.1/po`
make[2]: rien à faire pour `all`.
make[2]: on quitte le répertoire `/home/nagios/downloads/nagios-plugins-2.2.1/po`
make[2]: on entre dans le répertoire `/home/nagios/downloads/nagios-plugins-2.2.1`
make[2]: on quitte le répertoire `/home/nagios/downloads/nagios-plugins-2.2.1`
make[1]: on quitte le répertoire `/home/nagios/downloads/nagios-plugins-2.2.1`
4.2.6.1. Installation des plugins standards dans l’arborescence de Nagios
Lancez la commande suivante :
make install
Vous pourrez notamment constater que cette commande déploie les plugins standards dans
l’arborescence de Nagios :
libtool: install: /usr/bin/install -c -o nagios -g nagcmd check_apt

/usr/local/nagios/libexec/check_apt
libtool: install: /usr/bin/install -c -o nagios -g nagcmd check_cluster
/usr/local/nagios/
[...]
libtool: install: /usr/bin/install -c -o nagios -g nagcmd check_mrtgtraf
/usr/local/nagios/libexec/check_mrtgtraf
108
libtool: install: /usr/bin/install -c -o nagios -g nagcmd check_ntp

/usr/local/nagios/libexec/check_ntp
Le répertoire par défaut des plugins standards Nagios est /usr/local/nagios/libexec/. Pour
vous en assurer, lancez la commande suivante :
ls -lrtha /usr/local/nagios/libexec
De plus, vous pourrez constater que, à quelques exceptions près, les 49 plugins standards
appartiennent bien à l’utilisateur nagios et au groupe nagcmd.
4.2.6.2. Vérification du fait que Nagios dispose bien de ses plugins
- Retournez maintenant sur le site d’administration de Nagios, sur l’onglet « Alerts » du menu
« Reports » à gauche de la fenêtre :
figure 26 : Présentation de toutes les alertes de Nagios sont au vert !
À la bonne heure ! Les alertes rouges de Nagios sont passées au vert !
Nous venons de compléter l’installation des plugins standards de Nagios sur un système
GNU/Linux Debian.
4.2.6.3. Définition des alias de commandes pour gagner du temps
Le processus pourrait tout à fait s’arrêter là… mais tant que nous en sommes aux actions
d’installation, nous avons ajouté deux petites manipulations facultatives mais efficaces
Vous verrez, lors que la mise en place de vos sondes, qu’il sera souvent nécessaire de tester la
configuration de Nagios. Pour cela, Nagios propose un argument spécifique à l’exécution de son
programme principal. Celui-ci permet d’effectuer un premier jeu de test. Il suffit, pour ce faire, de
lancer Nagios avec l’option -v, et d’indiquer son fichier de configuration principal.
/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
109
La configuration de Nagios étant alors minimale, la commande devrait se terminer correctement,

sans afficher d’erreur ni d’avertissement :
Checking objects...
Checked 8 services.
Checked 1 hosts.
Checked 1 host groups.
Checked 0 service groups.
Checked 1 contacts.
Checked 1 contact groups.
Checked 24 commands.
Checked 5 time periods.
Checked 0 host escalations.
Checked 0 service escalations.
Checking for circular paths...
Checked 1 hosts
Checked 0 service dependencies
Checked 0 host dependencies
Checked 5 time periods
Checking global event handlers...
Checking obsessive compulsive processor commands...
Checking misc settings...
Total Warnings: 0
Total Errors: 0
Lorsque vous allez configurer des sondes Nagios, vous le ferez sous le compte utilisateur nagios.
En effet, c’est toujours mieux de ne pas travailler directement sous le compte root si cela n’est pas
nécessaire.
Nous avons créé un raccourci de cette commande nommé « testNagios » dans le fichier de
configuration du shell interactif (sans login) de l’utilisateur nagios. Le service Nagios tourne de
manière indépendante et une connexion réelle du compte nagios n'est heureusement pas nécessaire.
Pour créer cet alias, exécutez la commande suivante :
echo "alias testNagios='/usr/local/nagios/bin/nagios -v

/usr/local/nagios/etc/nagios.cfg'" >> /home/nagios/.bashrc
Attention à la syntaxe de cette commande (sur une seule ligne) et notamment aux simple quotes et
aux double quotes.
Par ailleurs, lorsque vous allez changer la configuration de Nagios, en

ajoutant/supprimant/modifiant les sondes : il faut non seulement tester cette nouvelle configuration,
mais aussi indiquer à Nagios de la prendre en compte. Cette opération peut être effectuée en
rechargeant (« reload » ou « restart ») le service Nagios.
Cependant, l’utilisateur nagios n’a pas les droits pour relancer le service Nagios. C’est normal, car
cette opération nécessite des privilèges dont les comptes standards ne disposent pas par défaut.
110
Pour donner au compte nagios le droit de relancer Nagios, vous devez ajouter cette autorisation
dans un fichier prévu à cet effet : /etc/sudoers.
Ce fichier contient les règles à vérifier lorsqu’un compte standard demande des droits
supplémentaires avec la commande sudo.
Exécutez la commande suivante :
echo "nagios ALL=NOPASSWD:/bin/systemctl restart nagios" >> /etc/sudoers
Cette commande autorise le compte nagios à redémarrer le service Nagios sur le serveur, sans lui
demander son mot de passe. Il nous reste désormais à créer le raccourci associé avec la commande
suivante :
echo "alias restartNagios='sudo systemctl restart nagios'" >>

/home/nagios/.bashrc
Voilà, vous allez maintenant pouvoir tester ces deux alias.
Pour cela, passez sous le compte de nagios avec la commande suivante :
su - nagios
Cette commande vous permet de prendre l’identité de l’utilisateur nagios en chargeant son
environnement. Et comme vous l’exécutez depuis le compte root, vous n’avez pas besoin de fournir
de mot de passe !
root@NagiosDebian:/etc/selinux# su - nagios
nagios@NagiosDebian:~$
Dans un premier temps, testez le raccourci servant à examiner la configuration de Nagios, avec la
commande suivante :
nagios@NagiosDebian:~$ testNagios
Le résultat doit être identique au précédent :
Total Warnings: 0
Total Errors: 0
Things look okay - No serious problems were detected during the pre-flight
check
Maintenant, toujours sous le compte nagios, testez la relance du service en utilisant la commande
suivante :
111
nagios@NagiosDebian:~$ restartNagios
Cette commande ne doit renvoyer aucune sortie. Pour confirmer que le service vient d’être relancé,
lancez la commande suivante :
nagios@NagiosDebian:~$ systemctl status nagios | grep Active
Et assurez-vous que le service est bien actif depuis quelques instants :
nagios@NagiosDebian:~$ systemctl status nagios | grep Active
Active: active (running) since Fri 2018-11-23 15:45:03 CET; 2s ago
En résumé
Nous avons pu, ici, installer ses plugins standards et mettre en place des droits pour
l’utilisateur nagios.
Il est maintenant temps de s’intéresser en profondeur au fonctionnement de ces outils.
Pendant le processus d’installation, vous avez vu que le répertoire natif de Nagios était :
/usr/local/nagios/.
Exécutez la commande suivante afin de lister le contenu de ce répertoire :
ls -l /usr/local/nagios
Le résultat devrait ressembler à :
drwxrwsr-x 2 nagios nagios 4096 nov. 23 10:37 bin

drwxrwsr-x 3 nagios nagios 4096 nov. 23 11:02 etc
drwxr-sr-x 2 root staff 4096 nov. 23 12:42 include
drwxrwsr-x 2 nagios nagios 4096 nov. 23 12:42 libexec
drwxrwsr-x 2 nagios nagios 4096 nov. 23 10:37 sbin
drwxrwsr-x 15 nagios nagios 4096 nov. 23 12:42 share
drwxrwsr-x 5 nagios nagios 4096 nov. 24 09:19 var
Vous connaissez déjà deux des éléments de cette arborescence :
• le répertoire bin, qui contient le programme principal de Nagios (ainsi qu’un autre
programme permettant d’établir quelques statistiques) ;
• le répertoire libexec, qui contient l’ensemble des plugins standards Nagios compilés sur
ce serveur.
112
4.2.7. Présentation des répertoires de Nagios
Je vous propose maintenant de passer en revue les autres répertoires.
4.2.7.1. Le répertoire « etc » pour la configuration de Nagios
Le répertoire etc contient l’ensemble de la configuration de Nagios. À la racine du répertoire,

vous retrouvez le fichier htpasswd.users, que vous avez créé lors de l’installation de Nagios. Pour
rappel, il permet de protéger l’accès à l’interface Web d’administration par un mot de passe
htaccess.
Le fichier nagios.cfg est le fichier de configuration principal de Nagios. Au démarrage, c’est ce fichier
que le programme Nagios va lire en premier. Toute la configuration se trouve dans ce fichier ou dans
d’autres fichiers qui y sont référencés ! On peut citer, par exemple, resource.cfg, qui contient des
paramètres spécifiques à votre contexte (nommés USER MACROS), ou encore cgi.cfg, dédié à la
configuration de l'interface d'administration (notamment des droits utilisateur).
Ensuite, on trouve le répertoire objects. Il contient huit fichiers de configuration avec une extension .cfg.
Ces fichiers contiennent des modèles de configuration fournis directement par Nagios, nommés
TEMPLATES. Ils permettent de factoriser beaucoup de tâches, ce qui fait gagner du temps sur la
configuration et la maintenance des sondes. Ainsi, dans le fichier printer.cfg, vous trouverez des
modèles de configuration d’imprimantes, dans le fichier switch.cfg des modèles pour les équipements
d’interconnexion, etc.
4.2.7.2. Les répertoires share et bin pour l'interface d'administration
Les répertoires share et sbin contiennent les éléments utiles à l’interface d’administration de
Nagios.
• Le répertoire sbin contient les fichiers cgi compilés. Ceux-ci traitent de certaines des
fonctionnalités de l’interface d’administration. Par exemple, le fichier cmd.cgi traite les
actions utilisateurs, le fichier notifications.cgi les notifications
, summary.cgi l’affichage condensé des objets supervisés, etc.
• Le répertoire share, lui, contient le code des pages de l’interface Web. Ceux qui aiment
développer pourront modifier ces fichiers à la main pour adapter l’interface à leurs besoins.
Mais il existe aussi des « skins » sur la plateforme https://exchange.nagios.org, grâce
auxquels il est possible de modifier les fichiers CSS par défaut de l’interface.Vous
remarquerez que l’interface de la version 4 de Nagios inclut Bootstrap et AngularJS !
4.2.7.3. Le répertoire var pour les variables maintenues par Nagios
Le répertoire var contient toutes les données variables maintenues par Nagios. Nagios écrit dans le
fichier nagios.log (fichier de traces du processus) dès qu’il se passe quelque chose, que ce soit un
113
redémarrage du service, un équipement qui n’est plus joignable ou un service qui passe en alerte.
Les archives des fichiers de traces seront conservées dans le répertoire archives.
Il est important de bien comprendre que Nagios n’écrira pas dans ce fichier lorsque tout va bien,
mais uniquement lorsqu’un évènement se produit.
Les fichiers status.dat et retention.dat sont un peu particuliers :
• Le fichier status.dat contient l’ensemble des données de supervision de Nagios. Ces

données peuvent concerner le processus Nagios en tant que tel (nombres
d’équipements/services supervisés, date de démarrage du programme, directives générales,
etc.), mais aussi tous les équipements et services supervisés (dernier statut détecté, temps de
latence et durée d’exécution des sondes pour chaque équipement/service, etc.). C’est un
fichier très important : il appartient à Nagios et vous ne devez pas le modifier à la main. Ce
fichier est mis à jour selon une directive inscrite dans le fichier nagios.cfg ;
• Le fichier retention.dat est construit un peu sur le même principe que status.dat.
Cependant, ce fichier est généralement mis à jour moins souvent, car il sert uniquement
lorsque le service Nagios redémarre. Le programme principal vient alors lire les valeurs
inscrites dans ce fichier afin de positionner le statut et les données des équipements/services
à superviser par défaut. Cela évite que toutes vos sondes soient remises à zéro à chaque
redémarrage du service ! Le comportement de Nagios vis-à-vis de ce fichier est également
défini dans nagios.cfg.
Le fichier object.cache fonctionne sur le même principe que les deux fichiers précédents, mais
contient simplement le cache de toute la configuration de Nagios. Vous ne devez pas intervenir
directement dans ce fichier.
4.2.7.4. Le répertoire « rw » pour le pipe de Nagios
Le répertoire rw contient notamment le pipe de Nagios. Rappelez-vous : vous avez rencontré ce

répertoire lors du processus d’installation.
Exécutez cette commande pour lister ce répertoire :
nagios@NagiosDebian:~$ ls -l /usr/local/nagios/var/rw/
Si votre service Nagios est actif, cette commande devrait renvoyer la sortie suivante :
total 0
prw-rw---- 1 nagios nagcmd 0 nov. 23 15:45 nagios.cmd
srw-rw---- 1 nagios nagcmd 0 nov. 23 15:45 nagios.qh
Le fichier nagios.cmd est le « pipe FIFO » (First In First Out) de Nagios. C’est un fichier très
important. Son attribut Linux, le petit « p », vous indique que ce fichier est de type « named pipe ».
Le principe est simple : c’est une connexion directe vers le processus Nagios, qui va lire de manière
114
continue les instructions passées dans ce fichier et les exécuter si elles sont compréhensibles. Les
instructions passées dans le fichier sont nommées « commandes externes », et c’est sur ce
mécanisme que s’appuie l’interface d’administration de Nagios pour discuter avec son processus.
Le fichier nagios.qh est l’une des principales nouveautés de la version 4 de Nagios. L’attribut
Linux s indique que ce fichier est un « socket ». Il est notamment utilisé par les processus fils créés par
Nagios pour discuter avec le processus principal, mais peut aussi être utilisé par un développement
spécifique pour s’adresser à Nagios.
OK ! Vous avez fait le tour de l’arborescence Nagios, il est maintenant temps de se pencher sur le fichier le
plus important de cette arborescence : nagios.cfg.
4.2.8. Maîtrisez les principales directives du fichier de configuration de Nagios
Découvrons ensemble quelques-unes des directives les plus importantes du fichier nagios.cfg.
Le fichier contient une centaine de directives au total. Il serait évidemment trop long de toutes les
détailler, alors attardons-nous sur les plus importantes.
4.2.8.1. log_file
Vous connaissez désormais la directive log_file, qui indique à Nagios le chemin vers son fichier
de traces. Il est possible de changer le chemin par défaut, à condition que le comptenagios ait les
droits d’écriture.
4.2.8.2. cfg_file
La directive cfg_file permet d’indiquer à Nagios de manière spécifique le chemin vers un fichier
de configuration à prendre en compte au démarrage.
Exécutez la commande suivante :
nagios@NagiosDebian:~$ grep ^cfg_file /usr/local/nagios/etc/nagios.cfg
Vous pourrez alors constater que le fichier nagios.cfg référence cinq fichiers de configuration
contenus dans le répertoire /usr/local/nagios/etc/objects :
cfg_file=/usr/local/nagios/etc/objects/commands.cfg
cfg_file=/usr/local/nagios/etc/objects/contacts.cfg
cfg_file=/usr/local/nagios/etc/objects/timeperiods.cfg
cfg_file=/usr/local/nagios/etc/objects/templates.cfg
cfg_file=/usr/local/nagios/etc/objects/localhost.cfg
4.2.8.3. cfg_dir
Cette directive a le même objectif que cfg_file. Cependant, plutôt que de référencer les fichiers de
manière individuelle, cfg_dir référence tous les fichiers avec une extension .cfg contenus dans le
115
chemin fournit en paramètre et ce, de manière récursive (en y incluant tous les répertoires et sous-
répertoires).
Par défaut, il n’y pas de répertoire référencé, vous allez donc créer le vôtre. La question qui se pose
est : où placer votre répertoire de configuration spécifique ? C’est une question importante,
notamment si vous devez un jour effectuer une migration de serveur.
Je vous conseille fortement de laisser les répertoires de l’arborescence Nagios inchangés et de créer
votre propre répertoire de travail à la racine du répertoire d’installation de Nagios. Lancez la
commande suivante :
nagios@NagiosDebian:~$ mkdir /usr/local/nagios/opencr_conf
Il nous reste maintenant à référencer ce répertoire dans le fichier de configuration Nagios. Vous
pouvez le faire en utilisant les commandes suivantes :
Attention à bien indiquer deux chevrons pour ajouter ces lignes en fin de fichier :
nagios@NagiosDebian:/usr/local$ echo "#CONFIG OPENCLASSROOMS" >>

nagios@NagiosDebian:/usr/local$ echo "cfg_dir=/usr/local/nagios/opencr_conf" >>
Vous pouvez vérifier avec la commande suivante :
nagios@NagiosDebian:/usr/local$ tail /usr/local/nagios/etc/nagios.cfg

# jobs_min The minimum amount of jobs to run at one time
[...]
#loadctl_options=jobs_max=100;backoff_limit=10;rampup_change=5
#CONFIG OPENCLASSROOMS
cfg_dir=/usr/local/nagios/opencr_conf
4.2.8.4. status_file et status_update
Ces deux directives indiquent à Nagios le chemin vers le fichier status.dat précédemment abordé
dans ce cours, ainsi que l’intervalle de temps entre chaque mise à jour de ce fichier (en secondes).
nagios@NagiosDebian:/usr/local$ grep ^status_ /usr/local/nagios/etc/nagios.cfg

status_file=/usr/local/nagios/var/status.dat
status_update_interval=10
Vous pouvez ici constater que le fichier status.dat est bien référencé et qu’il sera mise à jour
toutes les 10 secondes.
4.2.8.5. resource_file
Cette directive indique les fichiers contenant la définition des USER MACROS précédemment
évoquées dans le cours. Par défaut, le fichier correspondant
116
est/usr/local/nagios/etc/resource.cfg et vous permet de disposer de 256 variables. Celles-ci

vont de $USER1$ à $USER256$ et permettent de stocker des valeurs « constantes » dans votre
configuration Nagios.
D’ailleurs, Nagios définit votre toute première macro $USER1$ en tant

que $USER1$=/usr/local/nagios/libexec.
Souvenez-vous que ce répertoire contient l’ensemble des plugins standards compilés de Nagios.
Vous pourrez donc adresser ce répertoire dans votre configuration directement en
utilisant$USER1$lorsque nécessaire (et ce sera très souvent nécessaire). Utiliser cette macro a deux
avantages :
• si vous êtes amené à changer le répertoire des plugins pour quelque raison que ce soit, vous
n’aurez alors que ce fichier à changer pour positionner la nouvelle valeur de$USER1$. Vous
pourrez ensuite migrer immédiatement toute votre configuration.
• le deuxième avantage relève de la sécurité.
4.2.8.6. command_file, check_external_commands, log_external_commands
Voici la signification des trois directives liées au pipe FIFO de Nagios :
• la directive command_file indique le chemin vers le « pipe FIFO » de Nagios ;

• la directive check_external_commands indique si Nagios doit écouter ce pipe ;
• la directive log_external_commands indique si Nagios doit tracer les commandes
exécutées via son pipe.
Pour connaître leur valeur, exécutez la commande suivante :
nagios@NagiosDebian:/usr/local$ grep command /usr/local/nagios/etc/nagios.cfg |

grep -E ^[^#]
Ignorez la première ligne du résultat de cette commande, vous connaissez déjà sa signification :
cfg_file=/usr/local/nagios/etc/objects/commands.cfg
check_external_commands=1
command_file=/usr/local/nagios/var/rw/nagios.cmd
log_external_commands=1
Les trois valeurs par défaut de ces directives sont intéressantes et vont vous permettre de lancer des
commandes externes.
Voilà quelques directives importantes. Vous pouvez tout à fait consulter la signification de toutes
les directives existantes en consultant la documentation
https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/configmain.html
117
Lorsque vous serez en production avec un serveur Nagios supervisant beaucoup d’équipements et
de services.
En résumé
Vous connaissez maintenant le fonctionnement de Nagios, les éléments qui constituent son
arborescence et les principales directives de son fichier de configuration. Passons à la pratique avec
un premier exemple : la supervision de Nagios par Nagios lui-même.
Maintenant que votre environnement de supervision est prêt et que vous comprenez comment est
structuré Nagios, il est temps de découvrir son fonctionnement. Nous allons voir ensemble les éléments qui
constituent le système de supervision : les plugins, la command, le host et le service. Puis nous mettrons en
place la supervision d'un équipement et du service associé : le serveur Nagios lui-même. Oui, nous allons
superviser le serveur Nagios avec Nagios !
Avant de se plonger dans la configuration minimale de Nagios, il est important que vous compreniez son
schéma de fonctionnement.
4.2.9. Configuration de Nagios
Le fonctionnement de Nagios se base sur quatre éléments essentiels :
• Les plugins. Vous les connaissez, ce sont des programmes exécutables par Nagios : binaires
compilés, script Perl, script Bash, etc. ;
• La command. Cet objet appartient à Nagios et permet de définir le lancement d’un plugin ;
• Le host. Cet objet appartient à Nagios et représente tous les équipements à superviser. Ils
possèdent généralement une adresse IP et peuvent répondre aux pings ICMP standards.
• Le service. Cet objet appartient à Nagios et représente toutes les données à superviser sur
un host. On peut citer, entre autres, les services réseaux, par exemple les ports ouverts
d’un switch ou des services applicatifs, le service SSH ou HTTP d’un serveur, mais aussi la
charge CPU.
Dans cette section, nous allons voir ensemble comment fonctionne chacun de ces éléments.
118
4.2.9.1. Les plugins
Au plus bas niveau se situe le plugin. Ce programme contient, en fin de compte, toute
l’intelligence de Nagios. C’est lui qui est responsable de contacter le host ou le service à
superviser, de tester son statut et de récupérer les données associées.
La notion la plus importante à comprendre ici réside dans le fait que le plugin fonctionne de
manière autonome et indépendante !
Je vous propose cette petite manipulation : exécutez le plugin check_ping sous le compte nagios(qui
est le compte du service Nagios) de manière indépendante, en lançant la commande suivante :
nagios@NagiosDebian:/usr/local$ /usr/local/nagios/libexec/check_ping
Cette commande produit la sortie suivante :
nagios@NagiosDebian:/usr/local$ /usr/local/nagios/libexec/check_ping
check_ping: Impossible de décomposer les arguments
Utilisation :
check_ping -H <host_address> -w <wrta>,<wpl>% -c <crta>,<cpl>%
[-p packets] [-t timeout] [-4|-6]
Le plugin vous indique ici qu’il attend un minimum d’arguments, notamment l’adresse du host à
vérifier (adresse IP ou nom si Nagios a accès à un DNS), ainsi que les deux arguments :
• w, pour le seuil WARNING, et
• c, pour le seuil CRITICAL.
Ces deux arguments prennent pour valeur le temps nécessaire au retour du ping et/ou le
pourcentage de paquets perdus par le réseau.
Relancez alors cette commande avec les arguments :
nagios@NagiosDebian:/usr/local$ /usr/local/nagios/libexec/check_ping -H localhost -w 40,40% -c 60,60%
119
Le premier argument demande de vérifier que le serveur localhost est bien défini de la même
manière que dans le fichier /etc/hosts du serveur. Le second argument indique un seuil WARNING à
40 ms et/ou 40 % de paquets perdus. Le troisième argument indique un seuil CRITICAL à 60 ms
et/ou 60 % de paquets perdus. Bien entendu, ces seuils ne devraient pas se déclencher avec une
vérification sur localhost ! Observez le résultat de cette commande :
nagios@NagiosDebian:/usr/local$ /usr/local/nagios/libexec/check_ping -H localhost -w 40,40% -c 60,60%

PING OK - Paquets perdus = 0%, RTA = 0.05 ms|rta=0.049000ms;40.000000;60.000000;0.000000 pl=0%;40;60;0
Vous pouvez constater que le plugin renvoie OK avec un certain nombre d’informations,
notamment le temps d’aller-retour de la requête ainsi que le pourcentage de paquets perdus. Ces
informations sont comparées aux seuils passés en paramètre afin de déterminer le statut de cette
supervision. Vous comprenez ici que ce sont bien les PLUGINS qui, de manière indépendante,
déterminent le statut de l’objet à superviser.
Le plugin renvoie un statut WARNING car le temps aller-retour de la requête dépasse les 5 ms,
mais reste inférieur à 20 ms.
4.2.9.2. Les commandes
Au-dessus des plugins se trouvent les commandes Nagios. Deux caractéristiques les définissent :
• Leur nom. L’idée est de bien nommer ces commandes pour que leurs rôles soient
intelligibles au premier coup d’œil, et
• Le chemin vers le plugin à lancer avec, éventuellement, les arguments associés.
Pour définir une commande qui exécuterait le plugin check_ping sur localhost comme vu
précédemment, il faut ajouter, dans un fichier de configuration Nagios, la syntaxe suivante :
define command {
command_name check-ping-localhost
command_line /usr/local/nagios/libexec/check_ping -H localhost -w 40,40% -c 60,60%
}
120
Et c’est tout ! Comme vous pouvez le constater, le nom de la commande est très explicite, et la
ligne de la commande correspond parfaitement à notre exécution précédente.
Mais attendez : rappelez-vous du chapitre 3 de cette deuxième partie, et notamment de la notion

de USER MACROS. Vous avez pu constater que Nagios proposait par défaut une première macro
nommée $USER1$, qui référençait justement le chemin vers les plugins. Vous pouvez donc
transformer cette déclaration de commande :
define command {
command_line $USER1$/check_ping -H localhost -w 40,40% -c 60,60%
}
Ainsi, si à l’avenir vos plugins changent de place, vous n’aurez pas à toucher à votre configuration
de commande : il vous suffira, tout simplement, de modifier le fichier resource.cfg !
4.2.9.3. Les hosts
Maintenant que vous disposez d’une commande vous permettant d’effectuer un check_ping avec vos
propres arguments, il faut définir l’objet Nagios host afin d’ajouter sa supervision.
L’objet Nagios host dispose d’un peu plus de directives que l’objet command. Ces directives sont
parfaitement édictées ici :
https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/objectdefinitions.html#host
Nous allons devoir définir les directives minimales suivantes :
• host_name : c’est le nom de l’objet tel qu’il sera reconnu par Nagios. Le champ est libre,
mais il faut être le plus précis possible afin d’éviter les confusions ;
• address : l’adresse IP ou le nom pour joindre l’objet (par
exemple, locahost,www.unsupersite.com, etc.) ;
• max_check_attemps : cette directive spécifie à Nagios le nombre de tentatives successives
maximum renvoyant un résultat négatif avant que Nagios considère ce résultat comme
121
fiable et passe l’objet au statut déclenchant des notifications. C’est une directive très
importante sur laquelle vous devrez vous documenter sérieusement, notamment pour
maîtriser les notions de statut SOFT et HARD ;
• check_command : c’est cette directive qui fait la liaison entre votre commande
précédemment définie et cet objet host !
Bref, pour reprendre notre exemple précédent, il faut ajouter, dans un fichier de configuration
Nagios, la syntaxe suivante :
define host {
host_name Nagios Server
address localhost
check_command check-ping-localhost
max_check_attempts 3
}
4.2.9.4. Les services
Dernier élément de configuration : les services, qui sont des objets obligatoirement rattachés à un
host. Pour les observer en détails, lancez dans un premier temps la commande suivante :
nagios@NagiosDebian:~$ /usr/local/nagios/libexec/check_ssh
Vous avez maintenant compris que cette commande exécutait un plugin Nagios. Et il est fort
probable que ce plugin teste la réponse d’un service SSH. Elle doit renvoyer la sortie suivante :
nagios@NagiosDebian:~$ /usr/local/nagios/libexec/check_ssh
check_ssh: Impossible de décomposer les arguments
Utilisation:
check_ssh [-4|-6] [-t <timeout>] [-r <remote version>] [-p <port>] <host>
Le seul paramètre obligatoire indiqué par ce plugin est host. Relancez donc la commande avec ce
paramètre, fixé à la valeur locahost :
nagios@NagiosDebian:~$ /usr/local/nagios/libexec/check_ssh localhost
122
SSH OK - OpenSSH_7.4p1 Debian-10+deb9u4 (protocol 2.0) | time=0,005931s;;;0,000000;10,000000
Le plugin renvoie ici le statut OK, le service SSH est bien disponible sur localhost.
Tout comme pour le host, il faut, afin de superviser ce service, commencer par créer la commande
associée :
define command {
command_name check-ssh-localhost
command_line $USER1$/check_ssh localhost
}
Ensuite, il faut définir un objet service. Cet objet possède ses propres directives, qui sont très bien
documentées
https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/objectdefinitions.html#s
ervice
Voici la liste des directives minimale pour l’objet service :
• service_description : c’est l’identifiant du service. Il doit être unique pour chaque host ;
• host_name : c’est la référence à l’objet host hébergeant le service à superviser. Attention :
la valeur de cette directive doit correspondre à celle de la directive host_name de l’objet
host concerné ;
• check_command : cette directive permet d’indiquer la commande à exécuter pour
effectuer la supervision ;
• max_check_attempt : possède la même signification que pour le host.
La définition d’un tel objet service donnerait quelque chose comme :
define service {
service_description SSH sur Nagios Server
check_command check-ssh-localhost
123
}
4.2.9.5. Notre première configuration
Nous avons créer un nouveau fichier Nagios Server.cfg dans notre répertoire de
travail/usr/local/nagios/etc/hosts, en utilisant la commande suivante :
cd /usr/local/nagios/etc/hosts
sudo nano Nagios Server.cfg
Rassemblez les lignes précédemment vues dans la section précédente dans ce fichier :
define command {
command_line $USER1$/usr/local/nagios/libexec/check_ping -H localhost -w 40,40% -c 60,60%
}
define command {
command_name check-ssh-localhost
command_line $USER1$/check_ssh localhost
}
define host {
address localhost
}
define service {
service_description SSH sur Nagios Server
check_command check-ssh-localhost
}
124
Cela a été effectué après avoir défini les chemins Hosts et services par défaut.
Enregistrez votre fichier et lancez la commande testNagios pour effectuer une première
vérification :
nagios@NagiosDebian:~$ testNagios
Le résultat de cette commande devrait ressembler à :
Nagios Core 4.4.2

Copyright (c) 2009-present Nagios Core Development Team and Community Contributors
[...]
Total Warnings: 4
Total Errors: 0
Things look okay - No serious problems were detected during the pre-flight check
Vous allez constater trois avertissements sur notre configuration minimale pour le service, et un
avertissement sur celle du host. C’est normal, certaines directives ne sont pas encore définies,
mais ce n’est pas bloquant ! Pour que le service prenne cela en compte, vous pouvez le relancer
avec la commande restartNagios.
Si tout se passe bien, cette commande ne devrait rien renvoyer en sortie. Pour vérifier que votre
nouvelle configuration a bien été prise en compte, rendez-vous sur l’interface d’administration de
Nagios. Dans un premier temps, cliquez sur le lien « Hosts » à gauche de la page :
125
figure 27 : Interface « Host » de Nagios
Vous y retrouvez votre nouvel équipement supervisé « Nagios Server ». Cliquez maintenant sur le
lien « Services » à gauche de la page :
figure 28 : Interface « Services » de Nagios
Vous y retrouvez la supervision de votre service « SSH sur Serveur Nagios » sur le host « Nagios
Server ».
Vous venez d’ajouter votre serveur Nagios et son service SSH en supervision. Je vous invite
maintenant à étudier le contenu du fichier /usr/local/nagios/libexec
126
Vous allez y découvrir la définition d’un host nommé localhost, et de huit services définis sur le
même modèle que les vôtres. Vous venez de comprendre comment Nagios se supervise lui-
même !
define host {
use linux-server
host_name localhost
alias localhost
address 127.0.0.1
}
define service {
use local-service
host_name localhost
service_description PING
check_command check_ping!100.0,20%!500.0,60%
}
define service {
use local-service
host_name localhost
service_description Root Partition
check_command check_local_disk!20%!10%!/
}
[...]
Vous remarquerez cependant quelques différences dans la définition de la directive

check_command avec, notamment, l’utilisation du caractère
En résumé
Dans ce titre, vous avez pu ajouter un nouvel équipement : le serveur Nagios lui-même, ainsi que son
service à superviser. Ceci nous a permis d’observer les premiers retours des sondes sur l’interface
d’administration Nagios.
127
4.3. Nagios XI
Comme évoqué à l’entame, il ne s’agit que de la version améliorée de Nagios Core.
Ainsi, les configurations en ligne de commande de Nagios Core sont également possibles en ligne de
commande sur Nagios XI.
4.3.1 Installation de Nagios XI
Son installation est relativement plus simple. En effet, après avoir téléchargé sur le site officiel de Nagios le
fichier image .ova de Nagios qui pèse 2 Go, nous l’avons importé dans VMWare Workstation, puis déployé,
tout en veillant à ce que la machine physique soit connecté au réseau local et que l’accès par pont au
réseau de la machine virtuelle est activé. Voici le résultat :
Figure 29 : Interface du VMWare Nagios dans l’hyperviseur VMWare Workstation
128
Après avoir entré le nom d’utilisateur par défaut root et le mot de passe par défaut nagiosxi, cela démarre
automatique Nagios via l’adresse ip définie plus haut. Il est cependant aussi possible de modifier cette
derniere via la commande nmtui et de vérifier l’adresse via la commande ip -a.
4.3.2. Configuration de Nagios XI
En se servant directement d’un navigateur, entrant l’adresse ip indiqué, nous obtenons les interfaces de
configuration suivantes :
Etape 1 : Renseigner le langage ; le fuseau horaire, l’adresse url, comme présenté :
Figure 29 : Etape 1 de la configuration de Nagios XI
Etape 2 : Choisir la version désirée :
129
Figure 30 : Etape 2 de la configuration de Nagios XI
Etape 3 : Configurer les paramètres d’accès et de l’administrateur
Figures 31, 32, 33, 34 : Etapes finales de la configuration de Nagios XI
130
131
4.3.3. Aperçu général de la page d’accueil de Nagios XI
En se connectant sur un autre poste de travail, voici le résultat :
132
Figures 35, 36 : Page d’accueil de Nagios XI
4.4. Le tour du propriétaire : Nagios
Notre visite portera précisément sur la version gratuite de Nagios : Nagios Core.
133
Lorsque vous accédez à l’interface d’administration, la page d’accueil vous présente les menus de
navigation sur la gauche, et le contenu principal de la page sur la droite :
4.4.1. Aperçu général et description explicative de la page d’accueil de Nagios Core
Figure 37 : Page de l’interface d’administration de Nagios Core dans le navigateur de la machine virtuelle
Debian
i) Menu « General »
Le menu « General » contient deux sous-menus :
134
• « Home », qui vous ramène à la page d’accueil, et

• « Documentation », qui vous amène sur le lien :
https://library.nagios.com/library/products/nagios-core/manuals/
ii) Menu « Current Status »
Ce menu se concentre sur les données de supervision des équipements et des services. Le sous-
menu « Tactical Overview » offre une vue globale des objets supervisés, et vous donne accès à
quelques options de configuration.
Figure 38 : Page « Tactical Overview » de Nagios
135
Le sous-menu « Map » vous permet d’obtenir une vue en fonction de la topologie définie dans les
objets Nagios. Attention : elle ne reflète pas votre topologie réelle, sauf si vous la configurez
intégralement dans Nagios.
Figure 39 : Sous-menu « Map » de Nagios
Par défaut, les objets supervisés seront rattachés directement à votre serveur Nagios. C’est
notamment le cas de votre host Nagios Server, qui se trouve au même niveau que le hostlocalhost (qui
est le même !). La topologie Nagios peut être configurée avec la directiveparents, au niveau des
objets hosts. Il est possible d’indiquer plusieurs hosts dans cette directive, et souvent ce sont des
équipements d’interconnexion comme des switchs, des routers, des firewalls, etc.
C’est une directive très importante car, si Nagios détecte qu’un de ces équipements ne répond
plus, il va passer tous les hosts et les services dont il est le parent en statut « UNREACHABLE » ou
« UNKNOWN », statuts qui ne déclenchent pas de notification.
Le schéma suivant est disponible sur la documentation de Nagios.
136
Figure 40 : Exemple d'architecture supervisée
On observe que le Router1 est déclaré « parent » du Switch2 et du Router2. Lorsque le Router1
n’est plus joignable (le plugin « check_ping » renvoie CRITICAL par exemple), Nagios va passer en
UNREACHABLE le statut de Switch2, de Router2, mais également de tous les équipements qui en
dépendent (c’est-à-dire ici : Workstation1, HPLJ2605, et somesiteweb.com). Seuls les contacts
associés à Router1 recevront une alerte
Pour la pratique, nous avons défini le host localhost en tant que parent du host Nagios Server. Pour
cela, modifiez le fichier /usr/local/nagios/opencr_conf/nagios-server.cfg et ajoutez la directive « parents »
dans l’objet host Nagios Server :
define host {
137
address localhost
parents localhost
}
Vérifiez la configuration et relancez le service avec les commandes suivantes :
testNagios
restartNagios
Cliquez sur le sous-menu « Map » pour vérifier que cette topologie a bien été prise en compte :
figure 41 : Nouvelle topologie de votre réseau
Vous pouvez constater que localhost est maintenant le parent de Nagios Server.
iii) Le menu « Hosts »
Le menu « Hosts » vous propose une vue d’ensemble des objets host supervisés par votre serveur
Nagios.
138
Les colonnes présentées affichent les informations suivantes :
• Host : le nom de l’objet, tel qu’il a été défini dans le fichier de configuration ;
• Status : l’état courant du host ;
• Last Check : la date de dernière exécution de la commande définie par la
directive check_command du host ;
• Duration : le temps cumulé de supervision du host, et
• Status Information : les informations renvoyées par le plugin lors de sa dernière exécution.
Vous venez de rencontrer pour la première fois la notion de « check ». Un check est l’action
d’exécuter la commande définie dans la directive check_command d’un objet, et donc de lancer le
plugin défini dans cette commande.
En cliquant sur le lien affiché sous le nom du host, vous obtenez un affichage détaillé de l’objet :
139
Figure 42 : Détails d'un objet Host.
Le pavé « Host State Information » reprend les données de l’écran précédent et y ajoute quelques
informations, dont :
• Performance Data : ces données sont renvoyées de manière normalisée par le plugin et
peuvent être interprétées par des moteurs de rendu graphique ;
• Next Scheduled Active Check : indique le moment où l’objet sera à nouveau supervisé via
sa commande check_command et le plugin associé, et
• Last State Change : indique le moment où l’objet a changé de statut pour la dernière fois.
Le pavé « Hosts Commands » permet d’interagir avec l’objet directement depuis l’interface
d’administration via des commandes externes (comme nous l’avons vu dans le chapitre 3, avec le
pipe FIFO de Nagios).
Nous allons maintenant demander à Nagios de ne pas attendre le prochain check de cet objet,
mais de l’effectuer immédiatement. Pour cela, cliquons sur « Re-schedule the next check of this
host » :
140
Figure 43 : Commander un check immédiat sur l'objet
Vous pouvez décider du moment du prochain check. Par défaut, il vous sera proposé de faire un
prochain check immédiatement. Il vous suffit simplement de cliquer sur le bouton commit pour
exécuter le check. Si tout s’est bien passé, vous devez obtenir un message de confirmation.
En cliquant sur le lien « Done », vous revenez à la vue détaillée de la supervision de ce host. Et
vous pouvez constater l’exécution de votre commande externe en observant la nouvelle valeur du
champ Last Check Time.
Pour afficher les informations, l’interface Nagios se base sur le fichier /usr/local/nagios/var/status.dat .
Nous avions parlé de la valeur de la directive status_update_interval=10 dans le fichier nagios.cfg. Il faut
comprendre que l’interface d’administration peut mettre au maximum 10 secondes pour afficher
le résultat de cette commande externe. En d’autres termes, c’est le temps maximum qu’il faut à
Nagios pour écrire dans le fichier. Par conséquent, si le résultat de votre commande externe ne
s’affiche pas immédiatement, patientez 10 secondes et rafraîchissez la page !
Pour continuer avec ces histoires de commandes externes, répétez exactement la même
opération depuis l’interface, mais en ajoutant une commande dans le terminal afin d’écouter sur
le fichier de traces de Nagios en temps réel.
141
Dans un premier temps, exécutez la commande suivante :
nagios@NagiosDebian:~$ tail -f /usr/local/nagios/var/nagios.log
Puis, depuis le pavé de commandes de l’interface d’administration, relancez un check immédiat

sur le host localhost. Vous devriez voir apparaître la ligne suivante :
[1543075682] EXTERNAL COMMAND: SCHEDULE_FORCED_HOST_CHECK;localhost;1543075681
Que vous dit cette ligne ? Vous pouvez observer, dans le premier champ entre crochets, le nombre
de secondes écoulées depuis le 1er janvier 1970 à minuit : c’est le fameux timestamp des
informaticiens. Au timestamp indiqué, Nagios a exécuté une commande externe
nomméeschedule_force_host_check , en prenant pour paramètre le host localhost et un nouveau
timestamp indiquant le moment souhaité du check.
À croire que cliquer sur le lien depuis le navigateur a envoyé cette commande à Nagios (et c’est
effectivement ce qui s’est passé !). Comment votre navigateur a envoyé cette commande à
Nagios par le pipe FIFO de Nagios (d’où l’intérêt d’ajouter le compte www-data dans le
groupe nagcmd lors de l’installation de Nagios).
En résumé, le clic sur « Re-schedule the next check of this host » correspond à l’écriture, dans le
pipe FIFO, de la commande :[TIMESTAMP] SCHEDULE_FORCED_HOST_CHECK;localhost;TIMESTAMP
Vous pouvez vérifier vous-même cet état en exécutant la commande suivante (sur la même
ligne !) :
nagios@NagiosDebian:~$ DATE=`date +%s`;echo "[$DATE] SCHEDULE_FORCED_HOST_CHECK;"Nagios Server";$DATE"

> /usr/local/nagios/var/rw/nagios.cmd
Dans le fichier de traces de Nagios, vérifiez l’exécution de votre commande externe avec :
nagios@NagiosDebian:~$ tail /usr/local/nagios/var/nagios.log

[1543073348] Warning: Service 'SSH sur Nagios Server' on host 'Nagios Server' has no check time period defined!
142
[1543073348] Warning: Service 'SSH sur Nagios Server' on host 'Nagios Server' has no notification time period
defined!
[1543073348] Warning: Host 'Nagios Server' has no default contacts or contactgroups defined!
[1543073348] Successfully launched command file worker with pid 29007
[1543076289] EXTERNAL COMMAND: SCHEDULE_FORCED_HOST_CHECK;Nagios Server;1543076289
La dernière ligne correspond à votre commande pour le host Nagios Server !
Vous avez désormais compris comment fonctionnait l’interface entre l’interface Web
d’administration de Nagios et le service Nagios. Toutes les commandes externes que vous allez
rencontrer fonctionnent sur le même principe.
Les commandes externes Nagios sont normalisées et disponibles sur

https://assets.nagios.com/downloads/nagioscore/docs/externalcmds/
iv) Le menu « Services »
Le menu « Services » vous offre une vue d’ensemble des objets services supervisés par votre
serveur Nagios. Cet écran fonctionne sur le même principe que celui des hosts.
Pour voir l’affichage détaillé d’un service, il faut cliquer sur le lien sous le champ « service », et
non sous le champ « host ».
143
figure 44 : Vue détaillée d'un service Nagios Core
Nous avons eu l’occasion de découvrir les autres sous-menus :
• « Hosts Groups », qui vous permet de visualiser la supervision des objets de type host par
groupe. Les groupes se définissent aussi par des objets spécifiques.
• « Service Groups », qui fait la même chose pour les objets de type services.
• « Problems », qui vous permet de recenser, sur le même écran, les alertes en cours
relevées par Nagios.
4.4.2. Exploitation des outils système de l’interface d’administration
L’interface d’administration de Nagios propose également quelques fonctionnalités système à

l’utilisateur.
i) Le menu « Reports »
Le menu « Reports » propose de construire des rapports en fonction des compteurs stockés par le
moteur Nagios.
144
Le sous-menu « Availability » permet d’établir des rapports montrant les pourcentages de temps
sur les états pour les objets de type hosts ou services :
figure 45 : Service state breakdowns de Nagios Core
Le sous-menu « Trends » permet de construire des rapports concernant l’historique d’évolution

de l’état d’un objet host ou service.
figure 46 : Menu « Host Trends » de Nagios Core
Le sous-menu « Alerts » affiche un condensé horodaté de tous les évènements survenus aux
objets services et hosts supervisé.
145
figure 47 : Menu « Alerts » de Nagios Core
Le sous-menu « Notifications » affiche un résumé des différentes notifications générées par

Nagios.
Enfin, le sous-menu « Event Log » affiche, tout simplement, tout le contenu du fichier de traces de
Nagios /usr/local/nagios/var/nagios.log :
146
figure 48 : Menu « Event Log »
ii) Le menu « System »
Le menu « System » est un menu important qui fournit beaucoup d’informations sur le
comportement du serveur Nagios.
Le sous-menu « Comments » recense tous les commentaires des utilisateurs de l’interface

d’administration concernant les évènements survenus aux objets supervisés.
Le lien « Downtime » offre la possibilité de définir une période de temps pendant laquelle Nagios
ne tiendra pas compte des résultats des plugins pour les notifications normales, seules les
notifications indiquant le départ et l’arrêt de ces périodes seront envoyées.
147
figure 49 :Fonction « Downtime »
Le sous-menu « Process info » permet d’obtenir des statistiques sur le fonctionnement de Nagios :
148
figure 50 : Menu « Process Info »
Vous constaterez que cette page contient un panel de « Process Commands », qui fonctionne
exactement comme les « Host Commands » et les « Service Commands ». En d’autres termes, un
clic sur ces liens se traduit par une commande externe envoyée sur le pipe FIFO de Nagios.
Notez qu’il est possible, entre autres, de :
• arrêter ou redémarrer le service Nagios ;

• stopper toutes les sondes pour les objets de type host ;
• stopper toutes les sondes pour les objets de type services. Le sous-menu « Performance
Info » affiche les informations de performance :
149
figure 51 : Menu « Nagios Performance » sur Nagios Core
Cet écran est très important car il donne des indicateurs concernant « l’état de santé » du serveur
Nagios, parmi lesquels :
• le nombre de checks actifs pour les hosts par minute ;

• le nombre de checks actifs pour les services par minute ;
• le temps d’exécution maximum pour les checks hosts et services.
150
Vous pouvez constater que, sur cette page, le check d’un host prend 4 secondes ! C’est beaucoup
étant donné que, pour l’instant, vous surveillez uniquement le serveur Nagios.
Pour identifier le check du host qui prend autant de temps :
nagios@NagiosDebian:~$ grep -n check_execution_time /usr/local/nagios/var/status.dat
Observez le résultat de cette commande :
68: check_execution_time=4.094
Vous pouvez constater que trois sondes mettent plus de 4 secondes à s’exécuter. Consultez
désormais ce fichier à partir du premier numéro de ligne renvoyé par la commande (ici, 68) :
56 hoststatus {
57 host_name=Nagios Server
58 modified_attributes=0
59 check_command=check-ping-localhost
60 check_period=
61 notification_period=
62 importance=0
63 check_interval=5.000000
64 retry_interval=1.000000
151
65 event_handler=
66 has_been_checked=1
67 should_be_scheduled=1
68 check_execution_time=4.094
Vous constatez alors que la sonde de votre équipement « Nagios Server » met 4 secondes, alors
qu’elle est exécutée à partir de ce même équipement !
Pour vérifier ce temps d’exécution, relancez à la main le plugin check_ping que vous avez configuré
dans le fichier /usr/local/nagios/opencr_conf/nagios-server.cfg et ajoutez devant la commande time
permettant de relever le temps d’exécution telle que :
nagios@NagiosDebian:~$ time /usr/local/nagios/libexec/check_ping -H localhost -w 40,40% -c 60,60%

real 0m4,104s
user 0m0,000s
sys 0m0,000s
Effectivement, le ping du localhost prend 4 secondes !
Relancez le plugin avec son option -help pour comprendre ce phénomène et intéressez-vous
notamment à l’option -p :
nagios@NagiosDebian:~$ /usr/local/nagios/libexec/check_ping -help
Ci-dessous, le texte décrivant l’option -p :
-p, --packets=INTEGER
nombre de paquets ICMP à envoyer (Défaut: 5)
Et voilà ! La sonde met 4 secondes car elle envoie cinq paquets ! Un check sur la même machine
ne sera pas forcément probant. On pourrait descendre le nombre de paquets à 1, mais dans ce
cas, les seuils concernant le pourcentage de paquets perdus ne seraient plus probants. Encore une
fois, pour un check local, ce n’est pas grave.
152
Relancez la commande :
nagios@NagiosDebian:~$ time /usr/local/nagios/libexec/check_ping -H localhost -w 40,40% -c 60,60% -p 1

real 0m0,004s
user 0m0,000s
sys 0m0,000s
À retenir : consultez régulièrement le sous-menu « Performance Info » et assurez-vous que les

valeurs importantes sont maîtrisées ! Attention aux options par défaut des plugins lors de
l’exécution des sondes !
Vous aurez remarqué qu’il n’est pas possible d’ajouter un objet à superviser directement depuis
l’interface d’administration de Nagios Core. C’est le grand défaut de l’interface, que la
communauté a essayé de combler avec des interfaces spécifiques, qui ne sont plus vraiment
maintenues à ce jour
4.4.3. Configuration pas-à-pas d’un monitoring réseau d’une machine sous Windows via le
protocole SNMP sous Nagios XI.
Les images suivantes indiquent les étapes successives après avoir cliqué sur Configuration
wizards :
153
154
155
156
157
158
Figure 52, 53, 54, 55, 56, 57, 58, 59, 60 : Configuration pas-à-pas d’un monitoring réseau d’une machine sous
Windows via le protocole SNMP
En résumé
Voilà, le petit tour du propriétaire de l’interface d’administration Nagios est terminé. Vous avez
compris comment fonctionne cette interface, vous avez saisi la notion de commande externe via
le pipe FIFO de Nagios. Vous savez également où trouver les informations importantes sur cette
interface et vérifier les performances de vos sondes.
4.5. Difficultés rencontrées
Lors de l’implémentation de ce projet, nous nous sommes rendus compte de certains problèmes tout au
long de la phase d’installation, de configuration et d’implémentation de la solution de monitoring,
notamment :
159
- Des recherches plus poussées nécessaires pour la configuration de Nagios à l’aide du terminal.
- Des omissions sur les agents et services à installer au préalable.
- Des équipements mal connectés/non connectés au réseau.
160
Conclusion générale et perspectives
L’installation, la configuration et l’implémentation de Nagios a permis une expérimentation

poussée, voire une maîtrise des techniques, normes et démarches en rapport avec une telle
entreprise. Plus encore, elle a su développer en nous nombre de compétences transversales.
De surcroît, ce stage nous a permis, dans une incubation-métier profonde, de peaufiner nos
compétences en développement Web à travers la mise en place d’un site web dynamique du
restaurant permettant plus aisément de passer les commandes et de parcourir d’autres options.
Nous avons également pu participer à des projets d’envergure portant sur la configuration réseau
et des travaux de maintenance au sein de l’O.A.P.I. En addition, nous avons exécuté des
opérations dans des logiciels de gestion GLPI (des incidents) et iPas (de la production) sous la
conduite de notre encadreur. Assistant à plusieurs conférences en son sein, nous avons une idée
plus limpide la Propriété intellectuelle ainsi que de la gestion du personnel et de la production
grâce à l’outil informatique. Toutefois, compte tenu du développement incessant des
technologies, et avec l'expérience acquise en ce domaine, la maîtrise de la solution de Monitoring
est de plus en plus importante pour une meilleure utilisation. Le réseau demeure, entre autres, le
maillon le plus sensible d’une organisation, car qui touche son réseau, touche son cœur et est à
même de le détruire.
161
Références bibliographiques
A. Ouvrages
a. Camille Meyer, La numérisation ou la construction d'une mémoire
virtuelle,Université Paris IV,Sorbonne
b. Castells Manuel La société en réseaux Fayard, 1996.
B. Webographie
1. Supervision avec Nagios :
https://www.ibisc.univ-evry.fr/~petit/Enseignement/Reseau/IPV6/nagios.pdf
2. https://openclassrooms.com/fr/courses/2035786-mettez-en-place-un-outil-de-
supervision-de-production-avec-nagios
3. https://www.doc-developpement-durable.org/file/Projets-informatiques/cours-&-
manuels-informatiques/Nagios/LasupervisionavecNagios-Centreon.pdf
4. https://fr.wikipedia.org/wiki/Nagios
5. https://www.debian.org/releases/stretch/debian-installer
6. https://s3-eu-west-1.amazonaws.com/course.oc-
10. https://exchange.nagios.org
162
11. https://assets.nagios.com/downloads/nagiosxi/docs/Installing-Nagios-XI-Manually-on-
Linux.pdf
12. https://support.nagios.com/kb/article/nagios-core-installing-nagios-core-from-source-
96.html#Debian
13. https://www.nagios.org.
14. https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/configmain.html
15. https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/objectdefinitions.
html#host
16. https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/objectdefinitions.
html#service
17. https://assets.nagios.com/downloads/nagioscore/docs/externalcmds/
18. https://library.nagios.com/library/products/nagios-core/manuals/
163

Final Mem Oapi

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Final Mem Oapi

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSITE DE YAOUNDE I UNIVERSITY OF YAOUNDE I

Installation, Configuration et implémentation d’un outil de

Mémoire de fin d’études

Présenté et soutenu par :

Année académique : 2022 – 2023

A mes chers parents,

D’entrée de jeu, je remercie le Directeur Général de l’O.A.P.I. Monsieur Denis L. BOHOUSSOU

Ainsi, souhaiterai-je remercier, mes encadreurs académiques et professionnels : Ing. MABATTO

Aussi, je remercie toute l’équipe pédagogique de l’IFTIC-SUP, de l’ENSP et les intervenants

- Mes parents, pour leur soutien constant et leurs encouragements,

(Containers as a services informatiques d'importer, d'organiser, d'exécuter, de faire évoluer et de

Cas d’Utilisation Situation donnée dans laquelle un utilisateur utilise un système

Contexte Informations de l'environnement ayant un impact sur l'exécution d'un

Mandataire Personne chargée d'assurer la représentation d'une tierce personne, (particulier

Liste des sigles et abréviations

ARIPO : African Regional Intellectual Property Organization

BAR : Bureau d’Accueil et de renseignement

CIB : Classification Internationale des Brevets

DAJ : Direction des affaires juridiques

DBCT : Direction des Brevets et autres techniques

DMSD : Direction des marques et des signes distinctifs

DSIP : Direction des systèmes d’information et de la publication

DPC : Direction de la prospective et de la coopération

DFP : Direction des finances et du patrimoine

DGA : Directeur général adjoint

INPI : Institut National de la propriété intellectuelle

OAPI : Organisation Africaine de la Propriété intellectuelle

OAMPI : Office Africain et Malgache de Propriété Intellectuelle

OMPI (WIPO en anglais): Organisation Mondial de la propriété intellectuelle

OEB : Organisation européenne des Brevets

2.1. PRESENTATION ET OBJECTIFS DE NAGIOS .................................................................................................................. 61

4.2.9.1. Les plugins................................................................................................................................................. 119

Keywords: Intellectual property, Incident management, Network monitoring, Nagios, Information

Liste des figures et tableaux

Figure 1 : Organigramme de l’O.A.P.I. 29

Figure 33 : Interface du VMWare Nagios dans l’hyperviseur VMWare Workstation 128

Mais que gouverne-t-on en particulier ?

Le parc informatique d'une organisation est un assemblage, parfois hétéroclite de matériels et de

- Matériels différents (téléphones, portables, pc, imprimantes, éléments d'interconnexions,

De plus, la quantité de matériels et de logiciels à gérer, leur éclatement au sein de l'organisation

- La gestion de l'emplacement du matériel ;

Hormis l'introduction et la conclusion, notre travail s’articulera en cinq chapitres, à savoir :

• Chapitre 1 : Contexte et problématique

Chapitre 1 : Contexte et problématique

Partie 1 : Présentation de l’OAPI

1.1. Historique de l’O.A.P.I.

Les objets couverts par les accords de Bangui sont :

- Les brevets d'invention ;

- Les modèles d'utilité

- Les dessins et modèles industriels,

-Les noms commerciaux

- Les appellations d'origine

- Les marques de produits et de services

- Les obtentions végétales ;

-La propriété littéraire et artistique.

1. Soit directement à la Direction Générale de l'OAPI

Tel : (237) 2220 57 OO / 2220 39 11

Fax : (237) 2220 57 27/ 2220 57 21

Site Web : http://www.oapi.wipo.net, http://www.oapi.int

Le régime de l'accord de Libreville était fondé sur trois principes fondamentaux :

1. République fédérale du Cameroun,

4. République de la Cote d'ivoire,

6. République de la Haute Volta ;

10. République du Tchad ;