Supervision Centralisee Infrastructures Distantes Reseaux Gestion Alarmes Notification Alertes

HAUTE ECOLE PAUL-HENRI SPAAK
INSTITUT SUPERIEUR INDUSTRIEL DE BRUXELLES

Enseignement suprieur de type long de niveau universitaire
SUPERVISION CENTRALISEE
D'INFRASTRUCTURES DISTANTES
EN RESEAUX AVEC GESTION
DES ALARMES ET NOTIFICATION
DES ALERTES
Travail de fin d'tudes prsent par
CHUNG CHOONG LON Franois
LOUSSE Jonathan
en vue de l'obtention du titre et du grade
INGENIEUR INDUSTRIEL
ANNEE ACADEMIQUE2004-2005
Remerciements
Tout dabord, nous remercions lensemble du personnel de EASI pour leur
accueil, leur aide et leur courtoisie qui, dune manire globale, ont permis de
nous intgrer dans lentreprise et donc, de mener notre Travail de Fin dEtudes
dans les meilleures conditions.
Tout particulirement, nous remercions Monsieur Jean-Michel Block, notre
promoteur de stage, qui nous a non seulement permis de raliser notre stage
dans la socit EASI dans de bonnes conditions, tant du point de vue matriel
que de la disponibilit, mais qui nous a galement pauls et conseills dans
les choix relatifs la ralisation de notre TFE. De mme, nous remercions
Cdric Van Put qui a toujours t l pour nous aider lorsque nous avions des
problmes.
Nous exprimons galement toute notre reconnaissance envers le corps
enseignant de lInstitut Suprieur Industriel de Bruxelles qui nous a aid
durant toutes nos tudes et notamment envers Monsieur Giot sans qui ce
stage naurait pas t possible.
CHUNG FRANCOIS 4 me Ingnieur Industriel Anne 2004-2005
LOUSSE JONATHAN PAGE 1 SUR 95
Rsum
Pour assurer la disponibilit permanente de leur infrastructure informatique,
les entreprises ont rapidement compris que la supervision tait devenue une
ressource-cl. Bon nombre de logiciels de supervision existent mais, parmi
tout ceux-l, Nagios est trs certainement le logiciel Open Source le plus
rpandu et galement le plus suivi par la communaut de dveloppeurs.
La supervision a trois objectifs principaux: prvenir les incidents sur le rseau
par extrapolation des donnes fournies, agir rapidement ds qu'un systme est
not en erreur et permettre l'analyse "post mortem" d'un problme grce aux
informations collectes.
Bien que Nagios soit reconnu comme difficile installer et configurer, il
possde un nombre impressionnant de fonctionnalits telles que la surveillance
de services rseau (SMTP, POP3, HTTP, NNTP, PING, .), la surveillance de
ressources machine (charge du processeur, utilisation du disque, ...) et la
conception simple des "plugins" qui permet des utilisateurs de dvelopper
facilement leur propre service de vrification.
Dans le cadre de ce TFE, nous avons mis en place une supervision centralise
de linfrastructure informatique de EASI, une gestion dalarmes en cas de
problmes sur le rseau et une notification des alertes par email. Pour
effectuer cela, nous avons non seulement utilis les "plugins" standard de
Nagios mais nous avons galement dvelopp nos propres "plugins".
De plus, nous avons cr un mode multi-utilisateurs avec une authentification
via lannuaire LDAP de EASI et nous avons scuris les changes
dinformations entre les serveurs Nagios par un systme de cls publiques et
prives. Lobjectif terme est dtendre cette architecture lensemble des
clients de EASI.
Summary
To ensure the permanent availability of their data-processing infrastructure,
the companies quickly understood that the supervision become a key resource.
Many softwares of supervision are available but among all these, Nagios is
certainly the most spread Open Source software and also the most followed by
the developers community.
The supervision has three principal objectives: prevent the incidents on the
network by extrapolation of the provided data, act quickly as soon as a system
is noted in error and allow the "post mortem" analysis of a problem thanks to
collected informations.
Although Nagios is recognized to be difficult to install and to configure, it has a
impressing number of functionalities such as monitoring network services
(SMTP, POP3, HTTP, NNTP, PING, ...), machine resources (load of the
processor, use of the disc, ...) and the easy way to create their own service of
checking thanks to a simple structure of plugins.
Within the framework of this TFE, we develop a centralized monitoring of the
data-processing infrastructure of EASI, a management of alarms in the event
of problems on the network and a notification of alarms by email. To realize
that, we use not only the standard plugins of Nagios but we also develop our
own plugins.
We also created a multi-user mode with an authentification via a LDAP
directory and we made a secure exchange of informations between Nagios
servers by a system of public and private key. The objective in the long term
is to extend this architecture to all the EASIs custom.
1. Introduction
Ce Travail de Fin dEtudes dcrit la marche suivre pour superviser de manire
centralise des infrastructures distantes en rseaux. En cas de problmes sur
un composant rseau ou un service, nous allons expliquer comment grer les
alarmes et les mthodes appliquer pour notifier ces problmes aux personnes
responsables du bon fonctionnement de ces rseaux distants, en loccurrence
le dpartement "Systems Integration" de EASI. Cette notification se fait par le
biais dalertes, des emails dans notre cas.
La supervision comprend un certain nombre dactivits telles que la
surveillance, la visualisation, lanalyse et le pilotage. De notre ct, nous nous
intresserons la supervision informatique qui permet de contrler les
composants rseau et les applications dune entreprise.
Le fait de pouvoir centraliser la supervision permet un contrle total des
diffrents rseaux distants ainsi que de leurs quipements. Rapatrier les
informations provenant de ces derniers est donc primordial. Mais il est
galement important que les rseaux distants cherchent de manire
indpendante leur configuration sur un serveur Central. Suivant le mme
principe, cela permet une gestion centralise des diffrentes configurations.
Quant linfrastructure, cest un vaste domaine dans lequel on retrouve des
composants rseaux classiques (imprimantes, stations de travail, serveurs,
routeurs, ...), des services (HTTP, FTP, SMTP, POP3, PING, .) mais galement
des composants rseau non classiques (contrle de la temprature dun frigo,
de la disponibilit dune pointeuse, .). Tous ces composants, par leur
prsence sur le rseau, sont atteignables et donc supervisables.
1.1. SNMP vs Nagios
SNMP signifie Simple Network Management Protocol, ce qui se traduit par
protocole simple de gestion de rseau. Il s'agit d'un protocole qui permet aux
administrateurs rseau de grer les quipements du rseau et de
diagnostiquer les problmes qui peuvent y survenir.
Sur Internet, on retrouve des logiciels qui grent ce protocole. On peut citer
entre autres HP OpenView, OpenNMS, SNMP MIB Browser et SNMP Watcher.
Nagios, le logiciel que nous utilisons pour superviser, gre galement des
trappes SNMP mme sil n'est pas destin ni crit pour tre un remplaant
"point pour point" d'applications natives SNMP. Cependant, il peut tre
configur de manire ce que les interruptions SNMP reues par un hte
gnrent des alertes dans Nagios.
Pour effectuer la supervision, nous prfrons de loin Nagios pour plusieurs
raisons. Tout dabord, la mise en place est beaucoup moins contraignante car
dans le cas de SNMP, il faut installer des dmons sur les composants que lon
souhaite superviser ainsi qu'une base de donnes MIB (Management
Information Base) qui contient toute les informations ncessaires la gestion
d'un rseau informatique. Alors que Nagios ne requiert rien de particulier. Ce
qui est non seulement un gain de temps considrable mais aussi une facilit
pour limplmentation chez un client. De plus, Nagios est un logiciel Open
Source, ce qui diminue trs clairement les cots. Les logiciels SNMP sont
gnralement sous le cot de licences et si lon tient compte du fait que la
supervision se fera pour plusieurs petites PME et non pour quelques grandes
socits, il faudrait imaginer acheter plusieurs licences pour de petits parcs
informatiques. Cette solution nest pas rentable du tout. Les licences sont
rentabilises lorsque le parc informatique supervis reprsente un trs grand
nombre dordinateurs, ce qui n'est pas notre cas.
1.2. Linux DEBIN
Debian est un systme d'exploitation libre. GNU/Linux fournit le systme de
base et Debian fournit des logiciels trs divers. Cette structure est ralise par
une communaut de dveloppeurs qui travaille bnvolement travers le
monde. La distribution Debian GNU/Linux est rpute depuis longtemps pour
sa stabilit due une longue priode de test, sa gestion des paquets mais
aussi pour sa scurit.
Cependant, les difficults d'installation et d'utilisation associes Debian
GNU/Linux laissent trop souvent croire que ce systme d'exploitation n'est
rserv qu' des utilisateurs chevronns. Pourtant, si Debian parat
dconcertant pour un dbutant, aprs une courte priode de prise en main,
Debian est un systme trs agrable. De plus, sa logithque impressionnante
(environ 8710 paquets) en fait une distribution trs intressante aussi bien
pour une utilisation professionnelle que prive.
Il existe en permanence trois distributions Debian: "stable", "testing" et
"unstable". Chacune de ces distributions porte un nom mais, mis part pour
l'"unstable" o ceci est sans consquence, il ne faut pas confondre la
distribution et son nom.
La distribution "stable" reprsente la distribution officielle de Debian qui est
recommande pour un usage professionnel. Les seules modifications qu'elle a
subies au cours de son existence sont des corrections de "bugs" et de trous de
scurit. Elle est la seule tre officiellement suivie par l'quipe de scurit
de Debian.
La distribution "testing", celle que nous avons utilise dans le cadre de ce
Travail de Fin dEtudes, reprsente la future distribution "stable". Plus jour
que cette dernire (notamment quand celle-ci arrive en fin de vie) elle
bnficie, hormis l'aspect scurit, de la qualit et de tous les avantages du
systme de gestion des paquets Debian. La distribution "testing" est
recommande pour un usage personnel. Cest un excellent compromis entre la
version "stable" et "unstable". En effet, elle en est assez proche, et est au
got du jour tout en prsentant moins de risques de "bugs" que la version
"unstable", c'est pour tous ces avantages que nous l'avons choisie.
La distribution "unstable" est constitue de paquets l'essai avant d'tre
admise dans la distribution "testing". Malgr quelle soit la plus jour de
toutes, elle souffre de ruptures dans le systme de gestion des paquets. La
distribution "unstable" s'adresse donc plutt aux dveloppeurs ou ceux qui
sont la pointe quitte perdre un peu en facilit d'utilisation.
1.!. "titude #dvanced Pac$aging %oo& ' P%(
L'utilitaire APT est l'un des principaux outils de gestion de paquets sous Debian
en ligne de commande. Cet utilitaire ne se limite pas l'installation des
paquets mais permet galement une gestion complte de ceux-ci. Il donne
galement la possibilit de dsinstaller, de recueillir les diffrentes
informations sur les paquets, les dpendances, les conflits et les mises jour.
En ce qui concerne l'installation et la dsinstallation de paquets Debian, cest-
-dire dextension ".deb", APT possde un utilitaire trs performant bas sur
DKPG appel "APT-GET". Celui-ci permet, entre autres, de tlcharger et
dinstaller automatiquement un logiciel demand (par son nom) ainsi que
toutes ses dpendances partir de sources logicielles afin que celui-ci
fonctionne correctement.
On peut galement supprimer un paquet, vrifier le cache et les problmes
entre paquets, synchroniser les informations situes sur le systme avec celles
dune source, installer la version la plus rcente du paquet prsent dans le
systme, .
Grce lutilitaire "APT-GET", nous avons install convenablement Nagios,
logiciel de supervision, car, manuellement, les dpendances sont trs dures
grer et installer. De mme, pour linstallation de modules de Nagios,
lutilitaire APT-GET sest montr trs agrable et efficace.
1.). L*diteur de texte +I
VI est un des diteurs de texte les plus populaires sous Linux malgr son
ergonomie trs limite. En effet, VI est un diteur entirement en mode texte,
ce qui signifie que chacune des actions se fait l'aide de commandes texte.
Cet diteur, bien que peu pratique premire vue, est trs puissant et est trs
utile en cas de non fonctionnement de l'interface graphique.
Il y a 3 modes en VI: le mode normal dans lequel on se trouve l'ouverture du
fichier et qui permet de taper des commandes, le mode insertion qui insre les
caractres saisis l'intrieur du document et le mode de remplacement qui
remplace le texte existant par le texte saisi.
Pour modifier les fichiers de commandes et de configuration de Nagios en
mode console, l'diteur de texte a t plus quutile mme si au dbut, son
utilisation a t fort rude. Dans le cas du serveur Nagios central, comme nous
le contrlions distance et qu'un manque de mmoire ne nous permettait pas
de disposer dune interface graphique, l'utilisation de l'diteur de texte a t
invitable.
1.,. La su"ervision en -re.
1.,.1. Descri"tion
La supervision est un vaste domaine de l'informatique qui inclut plusieurs
activits: surveiller, visualiser, analyser, piloter, agir, . La supervision
informatique supervise l'ensemble du systme d'information de l'entreprise qui
comprend notamment le rseau et ses quipements, les serveurs, les
priphriques et les applications. Plusieurs mthodes existent:
o analyser les fichiers log
o rcuprer des rsultats de commandes et de scripts locaux ou
distants
o utiliser le protocole SNMP (Simple Network Management Protocol)
Autour de la supervision, plusieurs modules coexistent:
o La supervision rseau s'occupe de composants matriel tels que
serveur, imprimante, pare-feu, .
o La supervision systme s'occupe des applications et logiciels
o La notification permet lenvoi d'alertes par email, par sms, par
tlphone, par avertissement sonore, .
o L'excution de commandes permet de relancer une application qui
fait dfaut
o La retranscription d'tat du systme permet de voir tout moment
l'tat de tous les composants et applications superviss sous forme
d'un graphique, d'une carte ou d'un tableau. Son but est de rendre
les rsultats plus lisibles
o La cartographie visualise le rseau supervis par l'intermdiaire de
carte, de graphique, de tableau, .
o Le "reporting" consiste en un historique complet de la supervision
Le march de la supervision, quant lui, est dcoup en deux grandes sous-
parties: les offres diteurs et les offres du monde libre.
Les gros diteurs logiciels ont rapidement compris que la supervision tait une
ressource-cl pour les entreprises qui, de plus en plus, utilisent leur systme
d'information et ont donc besoin d'une disponibilit toujours plus grande de
leur infrastructure informatique. Par consquent, la supervision est un
domaine dans lequel les socits n'hsitent pas investir depuis quelques
annes. Ayant rapidement compris cela, les gros diteurs logiciels sont donc
trs vites entrs dans la course aux logiciels de supervision. Aujourd'hui, la
majorit des gros diteurs logiciels propose des outils complets de supervision.
On retrouve, parmi les plus connus:
o HP: la gamme Openview (NNM, OVO, ...)
o BMC: Patrol
o IBM: Tivoli
o Computer Associates: Unicenter TNG
Ces outils possdent tous leurs avantages face la concurrence. Cependant,
tous ont galement le mme dfaut: le prix. En effet, il faut savoir que, pour
une entreprise de taille moyenne, il lui faudra compter en moyenne 30 000
euros pour superviser son systme d'information, sans compter les jours de
services ou de formation sur les produits, invitables vu la complexit de ces
logiciels. Cette constatation faite, il est alors logique de voir de plus en plus de
socits aujourd'hui regarder du ct du logiciel libre, o les projets
commencent depuis quelques annes devenir de plus en plus professionnels
et suivis.
Depuis une dizaine d'annes dj, plusieurs projets de supervision ont vu le
jour au sein de la communaut du logiciel libre. On notera ainsi, parmi les plus
populaires:
o Nagios
o Zabbix
o OpenNMS
Parmi tous les logiciels libres de supervision, Nagios est trs certainement le
plus rpandu et galement le plus suivi par la communaut de dveloppeurs.
Cest dailleurs celui que EASI a choisi pour superviser son infrastructure
informatique ainsi que celle de ses clients, et qui va faire lobjet de notre
Travail de Fin dEtudes.
1.,.2. /-0ecti.s
Les systmes informatiques d'entreprises associent une diversit de services
(routage, messagerie, proxy, serveur Web, services de fichiers et
d'impressions, ...) plusieurs types de rseaux (LAN, Intranet, DMZ, Internet,
...). La disponibilit et le bon fonctionnement de chaque machine et logiciel
participant cet ensemble ont besoin d'tre vrifis rgulirement.
Des logiciels, les moniteurs, existent afin d'automatiser la vrification des
systmes informatiques. Ces outils ne fonctionnent pas tous sur le mme
principe (par exemple tester les services, interroger ces services sur leurs
tats, ou attendre une ventuelle alerte mise par le service). Par ailleurs,
l'outil de supervision ne doit pas remettre en cause l'architecture: il supervise
dans les meilleures conditions toutes les machines du rseau sans l'affaiblir,
cest--dire qu'il assure la scurit tout en absorbant la monte en charge.
La supervision a deux objectifs principaux:
o La "rvention des "annes
La surveillance d'un systme permet de connatre sa disponibilit un
instant t, mais aussi de mesurer dans le temps l'volution d'un certain
nombre de paramtres tels que l'occupation de l'espace disque ou la
charge mmoire. Il devient alors possible par extrapolation de prvenir
le moment de rupture du systme en prenant des mesures prventives.
o La re"rise sur incident
En gnral, un incident est connu lorsque l'utilisateur final se plaint d'un
disfonctionnement dans sa perception normale d'utilisation. Il faut alors
qualifier la panne, vrifier son origine s'il s'agit rellement d'une panne,
puis rparer.
Le cycle d'intervention peut tre grandement rduit par le biais de la
supervision: dans le cas d'une panne avre, le systme prvient
automatiquement l'quipe concerne, la rparation s'effectue alors avant
mme que l'utilisateur ne se soit aperu du problme; d'autre part dans le cas
d'une fausse alerte (erreur de manipulation de l'utilisateur), le systme de
supervision s'assure du bon fonctionnement de tous les quipements d'un coup
dil. Enfin, l'archivage des informations sur l'tat des systmes au cours du
temps est une source d'information pour l'analyse "post mortem" d'un incident.
En rsum, l'objectif est triple: prvenir les incidents par extrapolation des
donnes fournies, agir rapidement ds qu'un systme est not en erreur et
permettre l'analyse "post mortem" d'un problme grce aux informations
collectes. Un logiciel dit de supervision doit permettre de remplir tous ces
objectifs.
2. 1a2ier des c2arges
Un cahier des charges est un document ncessaire la russite d'un projet.
Tout d'abord, il assure la pertinence du projet envisag. Ensuite, il permet au
client de dfinir, de manire aussi prcise que possible, ses besoins. Enfin, il
formalise le besoin et l'explique aux diffrents acteurs pour s'assurer que tout
le monde est d'accord.
Le projet consiste superviser de manire centralise les infrastructures des
clients de EASI, la socit dans laquelle nous avons fait notre stage et notre
Travail de Fin d'Etudes, et plus particulirement leurs applications et leur
rseau informatique. Dans le cadre de notre dveloppement, nous supervisons
linfrastructure du rseau informatique de EASI.
Chaque client a un serveur Nagios Local, machine fonctionnant sous Linux et
faisant tourner un programme Open Source s'appelant Nagios, pour superviser
le parc informatique propre sa socit. Ce serveur fait partie du rseau de la
socit, ce qui permet Nagios d'effectuer la supervision de manire optimale.
Il a accs Internet pour communiquer avec le Serveur Nagios Central. Cette
communication sert changer les fichiers de configuration ainsi qu' envoyer
les diffrents tats des composants rseau et applications supervises. Le
client voit tout moment le rsultat de la supervision grce l'interface Web
scurise du serveur Nagios Central et son identifiant qui l'authentifie. Bien
entendu, l'accs la configuration lui est interdit et il ne voit que les lments
faisant partie de son propre rseau.
Pour mettre en place la supervision d'un client, il est bon de savoir ce que
celui-ci veut superviser. Un tableau dtaillant les diffrentes vrifications
possibles ainsi que les diffrents composants rseau de la socit cliente doit
tre complt par celui-ci. Dans un premier temps, cette liste de vrifications
comprend les vrifications standard du programme Nagios, mais aussi les
systmes non standard et terme, les demandes de supervision spcifiques
propres un client.
Le serveur Nagios Central rassemble les informations de tous les clients
superviss et il contient les fichiers de configuration de tous les serveurs
Nagios Locaux. En cas d'un problme signal sur le serveur Nagios Central,
celui-ci prvient par le biais d'un mail le dpartement "Systems Integration" de
EASI. Le personnel de ce dpartement rgle alors le problme et dans certains
cas, prvient la socit de l'ventuel disfonctionnement.
Un serveur Apache permet Nagios d'implmenter une interface Web, celle-ci
est accessible tous les clients mais en lecture. Tandis que EASI visualise
l'ensemble des composants superviss et peut intervenir sur la configuration
de Nagios.
Le serveur Nagios Central contient les fichiers de configuration des diffrents
clients, ce qui a pour but de faciliter la maintenance due la centralisation des
donnes. La rplication des fichiers de configuration est faite sur les serveurs
Nagios Locaux lors de modifications. Pour viter une faille de scurit dans les
rseaux des clients par l'ouverture de ports sur le pare-feu en entre, le
serveur Nagios Local se connecte au serveur Central pour vrifier si ses fichiers
de configuration sont diffrents de ceux stocks sur le serveur Central. Si les
fichiers sont diffrents, le serveur Nagios Local les tlcharge et redmarre le
programme Nagios avec la nouvelle configuration. En plus de cette scurit, la
connexion entre les diffrents serveurs est scurise.
Enfin, EASI ne souhaite pas vendre un produit de supervision mais bien un
service. En effet, EASI gre l'infrastructure informatique d'une cinquantaine de
clients. L'objectif de ce projet est d'inclure la supervision dans le contrat
associ la gestion de leur infrastructure, afin d'augmenter l'efficacit de
EASI. La vente d'un logiciel de supervision, tel qu'un logiciel SNMP, augmente
les cots ce qui constitue une barrire importante pour le client. De plus, cela
va l' encontre des objectifs de EASI car son but est bien d'augmenter la
qualit du service sans apporter de surcot auprs du client.
Nous devons galement concevoir des feuilles de documentation qui
permettent au personnel de EASI d'installer, de configurer et de tenir jour le
systme de supervision Nagios chez les clients.
Pour raliser ce projet, nous avons notre disposition le matriel suivant:
o 2 "orta-&es IBM %2in$Pad R!3 #PIII(
Systme dexploitation : Windows 2000
Description : Stations de tests
Les premiers essais sont raliss sur ces portables qui reprsentent des
serveurs superviser.
o 1 "orta-&e IBM %2in$Pad 21M #PIII(
Systme dexploitation : Debian
Description : serveur Nagios Local
Cest sur ce portable que nous avons install et configur Nagios et que
nous ralisons les premires vrifications dalarmes et de notifications.
o 1 P1 .ixe IBM Net.inity !333 #PII(
Systme dexploitation : Debian
Description : serveur Nagios Central
Possdant une mmoire de 64 Ram, nous sommes contraints de
travailler en mode console avec VI, l'diteur de texte propre Linux.
Pour plus de facilit, nous le contrlons distance travers une
connexion SSH. Au dbut, cette machine est prsente dans la pice o
nous travaillons. Ensuite, elle est place lextrieur de EASI chez
Interxion, une socit spcialise notamment dans lhbergement, pour
permettre une meilleure protection et un dtachement physique. Vu
certains problmes de connexion, la machine a rintgr EASI o se
sont drouls les derniers essais.
!. Nagios
!.1. Prsentation
Anciennement appel Netsaint, Nagios fonctionne sous Linux et sous la plupart
des systmes Unix. Ce logiciel a pour vocation la supervision de machines et
de services sur un rseau htrogne complexe. Il excute des scripts
intervalles programmables et ceux-ci vrifient le bon fonctionnement d'un
service ou d'une machine. Nagios centralise toutes ces informations et celles-
ci sont accessibles via une interface Web. Ainsi on connat la sant en temps
rel d'un rseau, d'une machine ou mme d'un service.
En cas de dfaillance d'une des tches supervises, Nagios met des messages
dalerte sous diffrents formats et il gre galement certains types d'erreurs.
Par exemple: lorsque Nagios dtecte que le serveur Web d'une machine Linux
est bloqu, il avertit quelqu'un que le service est dfaillant et il rgle le
problme par lui-mme en lanant un script qui redmarrera le serveur Web
distance. Si l'opration a bien russi, la personne responsable reoit une
notification disant que tout est rentr dans l'ordre. Dans le cas contraire, cette
personne remet le serveur Web en fonction.
Nagios ne se contente pas seulement de rcolter les informations provenant
d'une interrogation intermittente mais il analyse les rponses provenant de
modules externes ("plugins", ou greffons en franais) adapts chaque service
et plate-forme superviss.
Contrairement beaucoup dautres outils de supervision, Nagios ne dispose
pas de mcanisme interne pour vrifier ltat dun service, dun hte, . la
place, il utilise des "plugins". En fonction de la configuration dfinie par
ladministrateur, Nagios, qui nest en fait quun noyau, excute les "plugins" et
analyse les rsultats obtenus.
Voici comment on schmatise le fonctionnement de base:
Comme le montre ce schma, il est possible deffectuer des tests de toutes
sortes sur la machine Nagios (fonctionnement de service, espace disque,
charge, ...). Il excute galement des tests sur des machines distantes.
!.2. 4istori5ue
Nagios est entirement bas sur le moteur de Netsaint, ancien outil de
supervision rseau.
o Mars 1999 : premire version de NetSaint dveloppe par Ethan
Galstad
o Mars 2002 : dernire version de NetSaint
o Mai 2002 : premire version de Nagios
o Novembre 2002 : premire version stable de Nagios (1.0)
o Fvrier 2004 : sortie de la version 1.2 de Nagios, dernire version
stable actuelle
o Courant 2005 : sortie de la version 2.0 de Nagios
Dans le cadre de ce projet, nous utilisons la version 1.3 (du 24 octobre 2004)
car celle-ci est la plus rcente et la plus stable. La version 2.0 sortie en fvrier
2005 n'est pas considre comme une version officielle mais comme une
version beta.
!.!. 6onctionna&its
Le succs de Nagios provient du nombre impressionnant de fonctionnalits qu'il
possde. Nous avons repris les plus importantes sous forme de liste:
o Surveillance des facteurs environnementaux comme la temprature
o Surveillance des ressources machine (charge du processeur,
utilisation du disque, nombre d'utilisateurs connects, ...)
o Conception simple des "plugins" qui permet des utilisateurs de
dvelopper facilement leur propre service de vrification
o Vision des diffrents rsultats, services et htes sur un mme cran
en les comparant facilement de manire paralllise
o Capacit de dfinir une hirarchie des priphriques rseau
permettant la dtection et la distinction des serveurs en panne de
ceux qui sont inaccessibles
o Notification d'alertes envoyes lorsque des problmes de service ou
de serveur se produisent et doivent tre rsolus (par lintermdiaire
dun e-mail, dun SMS ou de la mthode dfinie par lutilisateur)
o Intensification facultative des alertes de serveurs et de services
diffrents groupes de contacts
o Capacit de dfinir des vnements pour une rsolution proactive des
problmes
o Rotation automatique des fichiers log
o Support pour l'implmentation de serveurs de supervision redondants
et distribus
o Interface Web pour suivre ltat du rseau, son volution, ses
problmes, ses fichiers log, .
o Systme simple d'autorisations dfinissant ce que les utilisateurs
voient et font partir de l'interface Web
o Rsolution des problmes via linterface Web
o Temps d'arrt programms pour supprimer les alertes de serveurs et
de services pendant les priodes de pannes prvues
!.). rc2itecture
Nagios est une plate-forme de supervision part entire qui utilise un serveur
Web et des fichiers CGI pour rendre l'interface plus conviviale et surtout plus
lisible. Nagios place tous les rsultats de la supervision dans un fichier log ou
dans une base de donnes, ceci rend bien entendu la lecture et l'interprtation
des rsultats difficiles. L'interface Web a pour but de simplifier cette lecture
fastidieuse.
Nagios stocke ces rsultats dans une base de donnes de type MySQL ou
PostgreSQL. La base de donnes n'est pas essentielle dans le fonctionnement
de Nagios et peut tre remplace par de simples fichiers texte. Cest dailleurs
ce que nous avons fait car dans ce cas-ci, la configuration est plus facile
mettre en place. De plus, les bases de donnes ne sont plus reconnues dans
les nouvelles versions.
L'architecture standard de Nagios est donc reprsente de la manire suivante:
Nagios dispose dune srie de "plugins" standard qui supervise dj de
nombreuses fonctionnalits sur un rseau, mais il est possible d'ajouter des
"plugins" provenant de librairies spcifiques ou mme de crer ses propres
"plugins". Nous verrons plus loin dans ce travail comment crire de nouveaux
"plugins" et la faon de les utiliser via Nagios. Pour les "plugins" standard,
nous les avons classs en plusieurs catgories en fonction de ce qu'ils
supervisent:
o Equipements
o Rseaux/Protocoles
o Applications
o Services
o Clients
Lensemble des "plugins" standard, tris par catgorie et dtaills se trouve
dans les annexes (Annexe 1).
!.).1. Inter.ace 7e-
L'interface Web de Nagios est accessible via un simple navigateur, permettant
ainsi un utilisateur de voir l'tat de sant du rseau. Elle permet galement
un administrateur de visualiser les rsultats de la supervision, de modifier
quelques lments de la configuration et surtout d'accder aux historiques.
Base sur des fichiers CGI, cette interface est donc scurise par les
mcanismes associs au serveur Web et aux CGI afin de restreindre les accs
aux informations en fonction des utilisateurs.
L'interface Web est compose de deux grands types de vues: les vues de
"monitoring" et de "reporting". Des captures d'cran de cette interface Web
sont disponibles dans les annexes (Annexe 17).
Premirement, les vues de "monitoring" permettent de connatre l'tat des
quipements et des services superviss en temps rel, et ventuellement
d'effectuer des actions sur ces derniers. Voici les vues principales disponibles:
o %actica& /vervie89 est une vue gnrale rsumant l'ensemble des
informations sur la sant du rseau, sur le nombre d'htes et de
services superviss
o Service Detai&9 vue dtaille de tous les services superviss sur le
rseau avec leur tat, l'heure de leur dernire vrification, leur
rponse et l'hte sur lequel ils tournent.
o 4ost Detai&9 vue dtaille de tous les htes superviss sur le rseau
avec leur tat et l'heure de leur dernire vrification
o Status /vervie89 rsum de l'tat des services tris par hte et par
groupe. Cette vue nous indique l'tat des htes et des services, ce
qui est pratique dans de grands rseaux.
o Status Summary9 aperu de ltat des services et des htes tris
par groupes
o Status :rid9 une vue de ltat des services ainsi que leurs
dnominations rassembls par htes et tris par groupes
o Status Ma"9 une cartographie du rseau supervis avec l'tat des
diffrents htes
o Service Pro-&ems9 une vue trs utile car elle visualise tous les
problmes sur des services existant sur le rseau
o 4ost Pro-&ems9 une liste des htes ayant un problme avec les
diffrentes informations
o Process In.o9 une feuille technique de Nagios, on y voit l'tat actuel
du programme mais galement la possibilit d'y intervenir
o Sc2edu&ing ;ueue9 une liste des vrifications que Nagios doit
encore excuter
Deuximement, les vues de "reporting" crent des rapports sur l'activit
passe du rseau, en fonction des donnes collectes par Nagios. Coupl avec
MRTG (Multi Router %raffic :rapher), un systme de gestion statistique et
d'analyse graphique, nous avons des graphiques facilement interprtables. Il
est alors trs facile de dtecter les problmes qui sont apparus sur le rseau.
Voici les vues principales disponibles:
o %rends9 une vue graphique de l'tat d'un hte ou d'un service dans
le temps et des statistiques qui s'y rapportent
o vai&a-i&ity9 des statistiques trs compltes sur un hte, un service
ou mme un groupe d'htes
o &ert 4istory9 un historique des alertes
o &ert 4istogram9 un historique des alertes par hte ou par service
sous forme de graphique
o &ert Summary9 le dtail de l'historique de toutes les alertes
o Noti.ications9 le dtail de toutes les notifications envoyes
o Event Log9 le dtail de tous les vnements survenus par jour
!.).2. Su"ervision distante
Le but de l'environnement de supervision distante ou rpartie est le
dchargement de l'excs de charge cr par les contrles de services du
serveur central sur un ou plusieurs serveurs rpartis.
La plupart des petites et moyennes entreprises n'ont pas rellement besoin de
mettre en uvre cet environnement. Cependant, quand il faut superviser des
centaines, voire des milliers d'htes ou services l'aide de Nagios, cela devient
important.
Le rle d'un serveur rparti, ou local, est le contrle de tous les services dfinis
pour un groupe d'htes du rseau. Selon la topographie du rseau, on peut
avoir plusieurs groupes en un seul lieu, o chaque groupe est spar par un
WAN, un pare-feu, . Pour chaque groupe d'htes, un serveur rparti sur
lequel Nagios tourne supervise les services du groupe. Un serveur rparti est
gnralement une installation simplifie de Nagios. Il n'y a pas besoin d'une
interface Web, d'envoyer des notifications, de faire tourner les scripts de
gestionnaires d'vnements ou de faire autre chose que l'excution des
contrles de service.
Le rle du serveur central est d'couter simplement les rsultats des contrles
de services d'un ou de plusieurs serveurs rpartis. Mais il excute galement
ses propres contrles. Comme le serveur central obtient des rsultats des
contrles de services passifs (raliss par des applications tierces et traits par
Nagios) d'un ou de plusieurs serveurs rpartis, il est utilis comme point
central pour la logique de supervision: il envoie des notifications, excute les
scripts de gestionnaires d'vnements, dtermine l'tat des htes, ...
Pour faciliter la communication entre les serveurs Nagios ou bien entre un hte
supervis et un serveur Nagios, des petits programmes appels agents de
supervision existent. Ils offrent la possibilit de profiter de la puissance offerte
par les "plugins". Il en existe deux types.
Ci-dessous, le schma reprsentant le fonctionnement de la supervision
centralise par Nagios.
!.).2.1. gent NRPE
Le principe de fonctionnement de l'agent NRPE (Nagios Remote Plugin
Executor) est simple: les "plugins" sont installs sur l'quipement superviser,
compils en fonction de son architecture car c'est elle qui les excute, ainsi que
le dmon NRPE faisant office de serveur. Sur Nagios, le "plugin check_nrpe"
fait alors office de client NRPE, rcuprant les informations en interrogeant le
dmon NRPE sur l'quipement concern.
Le "plugin check_nrpe" sur le serveur Nagios initie une connexion vers l'agent
NRPE de l'hte cible en lui demandant d'excuter une vrification. L'agent
NRPE retourne le rsultat au serveur Nagios.
!.).2.2. gent NS1
L'agent NSCA (Nagios Service 1heck cceptor) diffre de l'agent NRPE car la
vrification est planifie en local sur l'quipement supervis, excute, puis le
rsultat est envoy au serveur Nagios. De mme que pour NRPE, NSCA
demande la prsence du "plugin check_ncsa" sur la plate-forme Nagios.
!.,. Insta&&ation
L'installation de Nagios n'est pas chose facile, car ce programme a besoin, en
plus des "plugins", de satisfaire un certain nombre de dpendances. Certaines
d'entre elles ne sont pas obligatoires comme un serveur Web (Apache), une
base de donnes ou encore des librairies d'images (libgd 1.6.3 ou plus, libjpeg
et libpng). Mais d'autres dpendances sont obligatoires pour un bon
fonctionnement de Nagios.
Au dpart, nous avons install manuellement Nagios ainsi que ses
dpendances, selon un ordre:
o Un compilateur C
o Un serveur Apache
o Un module CGI
o Les librairies suivantes:
Gd 1.6.3 (carte de statut du rseau et courbes de tendances)
Zlib (fichiers PNG)
Libpng (fichiers PNG)
Jpeg (fichiers JPEG)
Freetype 2.x (police)
Xpm (fichiers BMP)
Ayant eu des problmes avec le paquet JPEG et GD, certains fichiers de
configuration nont pas t correctement installs. De ce fait, linstallation a
t bloque. Nous avons donc d reformater le serveur, rinstaller Debian et
videmment Nagios mais cette fois aid de lutilitaire APT de Debian qui a
install pour nous toutes les dpendances ncessaires.
!.<. 1on.iguration
!.<.1. Serveur "ac2e
Tout comme pour Nagios, linstallation de Apache se fait facilement avec "APT".
Nanmoins, il faut le configurer pour quil sadapte Nagios et sa structure.
Dans le fichier de configuration, nous ajoutons quelques lignes. Pour ce faire,
diffrentes possibilits s'offrent nous. La premire est de modifier le fichier
dans le rpertoire d'Apache et la deuxime est de crer un fichier avec les
modifications et d'ajouter dans le fichier de configuration de Apache le lien vers
ce nouveau fichier. Cette mthode laisse les informations propres Nagios
dans son dossier d'installation.
Voici les ajouts dans le fichier de configuration de Apache:
ScriptAlias /nagios/cgi-bin/ /usr/lib/cgi-bin/nagios/
<Directory "/usr/lib/cgi-bin/nagios">
AllowOverride AuthConfig
Options !ecC"#
Order allow$deny
Allow fro% all
</Directory>

Alias /nagios/ /usr/share/nagios/htdocs/
<Directory "/usr/share/nagios/htdocs">
Options &one
Order allow$deny
Allow fro% all
</Directory>
Apache permet galement de scuriser un site Web, cela est trs utile pour
que seules les personnes autorises puissent avoir accs aux informations de
l'entreprise. Le mode le plus utilis pour scuriser un site Web est d'associer
un rpertoire un fichier contenant l'identifiant et le mot de passe des
utilisateurs.
Voici les ajouts dans le fichier de configuration de Apache:
ScriptAlias /nagios/cgi-bin /usr/lib/cgi-bin/nagios
<DirectoryMatch /usr/lib/cgi-bin/nagios>
Options ExecCGI
Order Allow,Deny
Allow From All
AuthName "Nagios Access"
AuthType Basic
AuthUserFile /etc/nagios/htpasswd.users
require valid-user
</DirectoryMatch>
Le fichier contenant les identifiants et les mots de passe utilise la syntaxe
"nom_utilisateur:mot_de_passe_crypt".
Voici le fichier htpasswd.users:
nagiosadmin:6mU7.mzZYqS2M
francois:6mU7.mzZYqS2M
Grce ce fichier, seuls les utilisateurs inscrits dans le fichier peuvent
sauthentifier et se connecter linterface Web de Nagios.
!.<.2. Serveur Nagios
La configuration de Nagios demande beaucoup plus de temps et n'est pas
chose aise. En effet, l'ensemble de la configuration du logiciel s'effectue dans
des fichiers textes d'extension ".cfg". Les fichiers de configuration sont dfinis
selon le format suivant:
define type
{
attribut1 valeurs
attribut2 valeurs
...
}
Ce mcanisme de dfinition implique qu'aucun espace ne doit tre insr dans
les paramtres et leurs valeurs. La cohrence des fichiers de configuration est
teste en excutant Nagios avec l'option "-v" et en lui fournissant le fichier de
configuration principal:
debian:/# /usr/sbin/nagios -v /etc/nagios/nagios.cfg
Nagios 1.3
Copyright (c) 1999-2004 Ethan Galstad (nagios@nagios.org)
Last Modified: 10-24-2004
License: GPL
Reading configuration data...
Running pre-flight check on configuration data...
Checking services...
Checked 83 services.
Checking hosts...
Checked 23 hosts.
Checking host groups...
Checked 2 host groups.
Checking contacts...
Checked 1 contacts.
Checking contact groups...
Checked 2 contact groups.
Checking service escalations...
Checked 0 service escalations.
Checking host group escalations...
Checked 0 host group escalations.
Checking service dependencies...
Checked 0 service dependencies.
Checking host escalations...
Checked 0 host escalations.
Checking host dependencies...
Checked 1 host dependencies.
Checking commands...
Checked 111 commands.
Checking time periods...
Checked 3 time periods.
Checking for circular paths between hosts...
Checking for circular service execution dependencies...
Checking global event handlers...
Checking obsessive compulsive service processor command...
Checking misc settings...
Total Warnings: 0
Total Errors: 0
Things look okay - No serious problems were detected during the pre-flight check
debian:/#
Nagios supervise les quipements travers le rseau, ceux-ci sont des
serveurs, des quipements rseaux, ou tout autre type de machine relie au
rseau. Ces htes sont dtaills dans le fichier "hosts.cfg" et sont regroups
dans un ou plusieurs groupes dfinis dans le fichier "hostgroups.cfg", agissant
ainsi sur un ensemble d'htes. Viennent ensuite les services, ils correspondent
aux services tests par les "plugins".
La vrification des services se droule selon des priodes de temps dfinies
dans le fichier "timeperiods.cfg". Les contacts prvenir en cas d'alertes sont
dfinis dans le fichier "contacts.cfg" et sont eux aussi groups et dfinis dans
le fichier "contactgroups.cfg". L'escalade des alertes entre les groupes, en cas
de non rponse de l'un d'entre eux, est dfinie dans le fichier "escalations.cfg".
Il reste le fichier "checkcommands.cfg" dans lequel sont dclares les
commandes destines au lancement de "plugins" et le fichier
"misccommands.cfg" dans lequel se nichent les commandes ncessaires
l'envoi de mails, de SMS, .
Enfin, d'autres fichiers sont galement utiliss tels que "dependencies.cfg" pour
dfinir des dpendances entre services, "cgi.cfg" pour la configuration des CGI,
"hostextinfo.cfg" pour les infos supplmentaires sur les htes (icnes,
coordonnes graphiques sur la carte de statut du rseau, ...) et
"serviceextinfo.cfg" qui possde la mme utilit mais pour les services.
Lensemble des fichiers de configuration sont dtaills avec des explications et
des exemples dans les annexes (Annexe 7).
!.<.!. Serveur Post.ix
Nagios envoie les alertes par diffrents moyens comme le mail, le sms, . Si
on souhaite que Nagios envoie des alertes par mail, il est ncessaire d'installer
un serveur SMTP. Par dfaut, Debian nen possde pas et nous installons donc
Postifx, qui est un Agent de transport de courrier lectronique. Son objectif,
la conception, tait de raliser un systme de courrier alternatif Sendmail,
qui soit rapide, facile administrer et scuriser tout en tant compatible.
Aprs lavoir install avec APT, un systme de configuration pour les paquets
Debian propose immdiatement de configurer Postfix, cet utilitaire s'appelle
"Debconf". Nous avons choisi la configuration "Internet Site" car la machine
sert plusieurs machines clientes et elle a accs Internet de manire
permanente.
Ensuite, nous ditons le fichier "/etc/postfix/main.cf" pour vrifier ces valeurs:
myhostname = debian
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = debian, localhost.localdomain, , localhost
relayhost =
mynetworks = 127.0.0.0/8
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all define type
). Dve&o""ement de Nagios
).1. na&yse du "ro0et
L'analyse du projet consiste se poser la question de savoir ce que nous
pouvons et devons superviser. Il y a deux grandes catgories, invitables en
informatique, c'est--dire le matriel et les applications.
Tout dabord, nous tablissons une liste des composants rseau que nous
pouvons superviser sur un rseau et nous la divisons en plusieurs catgories:
o Serveurs
o Serveurs Web
o Sites Web
o Imprimantes
o Firewalls
o Routeurs
o Switchs
La supervision dune machine implique invitablement la connaissance de ce
quelle fait et donc, de ce qui est critique si son rle nest pas effectu. Pour
un serveur Web, nous devons superviser le protocole HTTP, pour un serveur de
mails, nous devons superviser le protocole SMTP, . Ce qui est supervis sur
une machine a bien videmment un lien direct avec son rle sur le rseau.
Pour les sites Web, la supervision consiste vrifier si le serveur rpond bien.
Une requte propre au protocole HTTP, en l'occurrence une requte "GET", est
envoye au serveur. Si la page dindex du site nexiste pas ou si le serveur ne
rpond pas, une erreur est dtecte et une alerte au sein de Nagios apparat.
Les imprimantes sont soit relies un ordinateur, soit relies directement sur
le rseau avec une adresse IP. Dans ce cas, il est possible de contrler la
connexion de limprimante au rseau en excutant une commande "PING". Il
est galement possible de superviser des imprimantes en capturant les trames
SNMP quelles envoient lorsquil manque du papier ou de lencre par exemple.
Pour les lments constituant l'architecture du rseau tels que les pare-feux,
les routeurs et les "switchs", nous vrifions leur prsence et leur bon
fonctionnement par l'utilisation d'une commande "PING". Si l'un d'eux vient
faire dfaut, l'quipe de EASI est prvenue le plus rapidement possible car ceci
correspond une rupture critique dans le rseau.
Aprs avoir tabli la liste des composants superviser, nous dfinissons la liste
de ce qui peut tre supervis sur ces composants. Voici les diffrentes
catgories:
o Services standard
o Rseau
o Protocoles TCP/IP & UDP
o Services
o Mise en place de Nagios
o Services spciaux
Les services standard sont les services pour lesquels toutes les machines sont
supervises, cest--dire que ce sont des services qui ne tiennent pas compte
de la caractristique propre de la machine sur le rseau. On peut citer par
exemple la charge moyenne du systme, le taux dutilisation du disque dur,
lcart de temps avec un serveur de temps, . En ce qui concerne lespace du
disque dur, nous avons cr notre propre "plugin" qui vrifie laccroissement
du disque. Nous avons list ces diffrents services:
o Charge moyenne du systme
o Ecart de temps avec un serveur de temps
o Espace disque (utilisation)
o Espace disque (accroissement)
o Nombre de processus
o Taux d'utilisation de la mmoire SWAP
o Temprature
o Utilisation de la mmoire
La catgorie "Rseau" reprend lensemble des supervisions purement orientes
rseau tel que la vrification dun port en mode UDP, la vrification de la
connexion TCP avec un port spcifi, le statut dune interface rseau, . La
supervision la plus effectue dans cette catgorie est incontestablement la
connexion au rseau, ce qui est bien videmment indispensable pour un
serveur. Cest la commande "PING" qui est utilise et qui renvoie des
statistiques de connexion. Il est important de noter que quasi toutes les
machines possdent au minimum cette vrification.
Voici les vrifications effectues dans la catgorie "Rseau":
o Connexion au rseau
o Imprimante HP avec carte JetDirect
o Port en TCP
o Port en UDP
o Signal d'un rseau sans fil
En ce qui concerne les protocoles TCP/IP et UDP, nous avons tabli une liste
des protocoles les plus couramment utiliss et dont le bon fonctionnement est
indispensable aux diffrents serveurs:
o DHCP
o DNS
o FTP
o HTTP (HTTPS)
o IMAP
o IRCD
o LDAP
o NNTP
o POP3
o SMTP
o SNMP
o SSH
o .
Les services reprennent lensemble des applications tournant sur un serveur.
Pour superviser ces services, nous surveillons ltat des ports mais nous
vrifions galement, dans le cas dapplications sous Windows, que le service
est bien dmarr. Nous supervisons donc ces services:
o Citrix
o Fax
o MRTG
o MySQL
o NSClient
o Oracle
o Sendmail
La catgorie "Mise en place de Nagios" est constitue de deux vrifications
fondamentales: la notification du bon fonctionnement du Nagios Local vers le
serveur Nagios Central et la vrification de la validit de ses fichiers de
configuration. Ce sont donc les deux scripts qui permettent la structure
centralise de Nagios. En effet, il faut que le Nagios Central soit certain de la
bonne disponibilit des serveurs Nagios Locaux. Pour cela, il faut que ceux-ci
se manifestent intervalles rguliers. De mme, la structure centralise
implique que ce soit le serveur Nagios Central qui gre les configurations des
diffrents serveurs Nagios Locaux. Nous avons donc les deux vrifications
suivantes:
o Notification de fonctionnement vers NagServ
o Vrification de la configuration
Enfin, les services spciaux prennent en compte les services plus rares mais
qui sont compris dans les standards de Nagios. On peut citer notamment les
serveurs Novell, Radius et de licence Flexlm mais galement les quipements
sans fil Breezecom. Cette catgorie contient galement les actions possibles
en standard telle que lexcution de "plugins" locaux ou lexcution de
commandes distance en utilisant SSH. Voici quelques services spciaux
superviss par Nagios :
o Equipement sans fil Breezecom
o Excution de "plugins" locaux
o Excution d'une commande en utilisant SSH
o Onduleur UPS
o Prsence d'une chane dans un fichier log
o Rseaux Netware
o Serveur de licence Flexlm
o Serveur Novell
o Serveur Radius
o Serveur Unix
Pour une meilleure comprhension, nous avons cr un tableau reprenant la
liste de toutes les vrifications ainsi que la liste des composants rseau propres
un client. Ce tableau constitue une fiche que le client remplit afin de
dterminer ce quil souhaite que EASI supervise sur son rseau. Cette fiche
client est jointe en annexe (Annexe 10).
La supervision des protocoles TCP/IP et UDP consiste tester la connexion de
lhte sur le port utilis par le protocole, cest pour cela que nous ajoutons les
ports par dfaut ct de chaque protocole dans le tableau qui constitue la
fiche client.
Dans ce tableau, une diffrence est faite entre ce qui est supervis par le
Nagios Local et ce qui lest par le Nagios Central. Dans la partie locale, nous
supervisons les composants rseau du client, par contre dans la partie
centrale, nous supervisons des serveurs ou sites Web appartenant cette
mme socit mais sur un autre rseau. Cette mthode permet en cas de
problme sur le rseau du client de continuer superviser ces diffrents
lments. Supposons par exemple que le serveur Nagios Local dtecte un
problme mais qu'il n'ait plus de connexion Internet, il n'avise donc pas le
serveur Central et la panne n'est pas dtecte.
Enfin, titre dinformation, nous ajoutons galement le systme dexploitation
prsent sur chaque machine supervise. Linux et Windows sont bien
videmment prsents, mais il y a galement lOS/400 qui est un systme
d'exploitation destin aux systmes AS/400 d'IBM. Il est important de noter
que ce dernier peut contenir dautres partitions avec dautres systmes
dexploitation tels que Windows et Linux
).2. Dve&o""ement de ="&ugins=
Pour effectuer la supervision, il existe un nombre important de "plugins"
standard fournis avec le programme Nagios ou que l'on trouve sur Internet.
Dans le cadre de la supervision du rseau d'EASI, nous nous sommes vite
rendus compte que nous devrions crire nos propres "plugins". Pour ce faire, il
a tout dabord fallu comprendre le fonctionnement dun "plugin" et surtout ce
quil envoie comme informations et comment il les envoie Nagios.
Cette information, appele "code retour" du "plugin", est compose de 2
paramtres: une chane de caractres qui permet de dcrire le service et un
chiffre compris entre 0 et 3 qui dtermine ltat de ce service.
o valeur 0 : OK (le service fonctionne correctement)
o valeur 1 : Warning (le service fonctionne en mode dgrad)
o valeur 2 : Critical (le service ne fonctionne plus)
o valeur 3 : Unknown (impossible de dterminer ltat du service)
Fin d'un script de "plugin":
...
echo "Commentaire du service"
exit 0
Les langages que nous avons utiliss pour crire ces "plugins" sont le Perl et le
Shell. Ce dernier est fortement utilis dans Nagios pour lancer des
commandes, cest pourquoi nous lavons galement utilis. Par contre, ce
langage pose quelques problmes pour la manipulation de chanes de
caractres. Dans ce cas-l, nous avons alors prfr utiliser Perl.
).2.1. Envoi de noti.ications au Nagios 1entra&
Lorsque le serveur Nagios Local dtecte qu'un hte ou un service ne rpond
pas, il le fait savoir au Nagios Central. Nous avons vu plus haut que Nagios
peut utiliser un module NSCA mais rien n'est prvu dans Nagios pour l'utiliser
directement. Nous passons donc par un script que Nagios appelle et qui
envoie le message au Serveur Central.
Pour commencer, nous installons NSCA. L'installation de ce module se passe
en deux temps, d'abord sur le serveur Nagios Local (Client NSCA) et ensuite
sur le serveur Nagios Central (Serveur NSCA) pour que celui-ci reste l'coute
et reoive tout moment les messages NSCA qu'on lui envoie.
Pour installer le Client NSCA, nous copions le fichier "send_nsca.pl" sur le
serveur Nagios Local dans le rpertoire "/usr/sbin". Nous crons un fichier
"/etc/nagios/send_nsca.cfg" dans lequel nous mettons les diffrents
paramtres ncessaires la configuration du module.
Contenu du fichier send-nsca.cfg
password=nagios
encryption_method=1
"ass8ord9 il s'agit du mot cl/phrase utilis pour crypter les paquets sortants.
Il est vident que le mot cl doit tre le mme que celui utilis pour dcrypter
le paquet.
encry"tion>met2od9 cette option dtermine la mthode utilise par le client
pour crypter le paquet qui est envoy au serveur NSCA. La mthode de
cryptage ne doit pas tre choisie au hasard, mais est un compromis entre
scurit et performance. Une mthode trs scurise consomme beaucoup
plus de ressources qu'une mthode rapide qui prsente une plus grande faille
de scurit. Voici les mthodes de cryptage les plus connues et supportes par
NSCA:
o 0 = Aucun cryptage (A viter)
o 1 = Simple fonction XOR
o 2 = DES
o 3 = 3DES
Le dtail du fichier de configuration du client NSCA ainsi que toutes les
mthodes supportes par NSCA sont jointes aux annexes (Annexe 8).
Nous choisissons la mthode non scurise XOR (ou exclusif) car elle apporte
quelques avantages dans notre cas. Les informations que nous envoyons par
NSCA ne contiennent pas de donnes essentielles, il n'est donc pas utile de les
crypter de faon complexe. Par contre, nous voulons conomiser les
ressources du systme et cette mthode en consomme trs peu et est donc
trs rapide.
Remar5ue9 pour des questions de scurit, nous faisons trs attention au
droit que nous donnons ce fichier car il contient un mot de passe, nous ne le
laissons donc pas accessible tous les utilisateurs.
L'installation du Serveur NSCA s'effectue avec l'utilitaire APT de Debian. Nous
devons galement diter le fichier "/etc/inetd.conf" pour y ajouter cette ligne.
5667 stream tcp nowait nagios /usr/sbin/tcpd /usr/sbin/nsca -c
/etc/nsca.cfg --inetd
Il est galement important d'ajouter les adresses IP des htes qui vont
envoyer les notifications dans le fichier "/etc/nsca.cfg" comme montr ci-
dessous:
server_port=5667
allowed_hosts=127.0.0.1,172.22.3.73
Maintenant que le serveur et le client sont installs, nous nous intressons la
faon d'envoyer des messages. Avant de dvelopper ce script, nous essayons
d'envoyer des messages en mode console.
Lorsque le serveur NSCA reoit un message, il le dcrypte et le note dans le
journal de Debian. Cet historique s'crit dans "/var/log/messages". Grce la
commande "tail -f", il affiche la fin du fichier ainsi que les nouvelles
informations inscrites.
Sur le client NSCA, nous lanons la commande pour l'envoi d'un message.
Voici le test que nous avons effectu:
NagEASI:/# /usr/sbin/send_nsca -H 194.78.71.30 -c /etc/nagios/send_nsca.cfg -to
400
Test Update 0 info
Cette ligne de commande correspond la syntaxe suivante:
NagEASI:/# /usr/sbin/send_nsca -H Adresse_IP -c /etc/nagios/send_nsca.cfg -to 400
[ENTER]
Nom_de_l_hote [TAB] Nom_du_service [TAB] Statut_du_service [TAB] Commentaire |
[ENTER]
?49 option obligatoire car elle prcise l'adresse du serveur NSCA.
?c9 paramtre obligatoire car il indique l'emplacement du fichier de
configuration pour l'envoi de donnes au serveur.
?to9 option non obligatoire mais utile car elle allonge le "time out" du client
pour avoir le temps de taper le message en entier.
Aprs l'envoi de cette commande, ce message apparat dans l'historique de
Debian supportant le Serveur NSCA.
ServNag:/# tail -f /var/log/messages
May 17 13:59:56 ServNag nagios: EXTERNAL COMMAND:
PROCESS_SERVICE_CHECK_RESULT;EASI-ASEASI;CheckHTTP;0;Connection refused by host
May 17 14:00:06 ServNag nagios: Warning: Message queue contained results for
service 'CheckHTTP' on host 'EASI-ASEASI'. The service could not be found!
Maintenant que le client NSCA communique bien avec le serveur NSCA, nous
crivons le script qui enverra un message au serveur sans prciser l'adresse et
l'emplacement du fichier de configuration. Nous rdigeons ce script en Linux
Shell pour la facilit de programmation et pour la ressemblance avec les
commandes du mode console.
Voici le script Send-ServNag
/usr/bin/printf "%b" "$1\t$2\t$3\t$4\n" | /usr/sbin/send_nsca -H 217.71.120.199 -c
/etc/nagios/send_nsca.cfg
Le programme "send_nsca" ne prend pas les informations du message dans la
ligne de commande mais il lit les caractres entrs au clavier aprs le
lancement de la commande. Nous crons donc un tuyau ("pipe") dans notre
script pour que celui-ci envoie le message aprs avoir envoy la commande.
Pour excuter le script, nous tapons maintenant:
NagEASI:/# ./Send-ServNag test update 0 info
Ce script est utilis par Nagios pour envoyer au Serveur Central des
informations sur un service, nous crons galement un second script pour
envoyer des informations sur un hte. Celui-ci est fort ressemblant au
prcdent. Nous avons donc jug inintressant de tout rexpliquer. Ce script
s'appelle "Send-Host-ServNag" et voici son code:
/usr/bin/printf "%b" "$1\t$2\t$3\n" | /usr/sbin/send_nsca -H 217.71.120.199 -c
/etc/nagios/send_nsca.cfg
).2.2. +a&idit des .ic2iers de con.iguration
La configuration de Nagios demeure dans une dizaine de fichiers texte stocks
localement dans le rpertoire "/etc/nagios/". Ces fichiers proviennent du
serveur Nagios Central et sont rgulirement remis jour. Cette mise jour
n'est pas faite intervalles constants, elle est effectue lorsque des
changements dans les fichiers de configuration se produisent. Le Nagios Local
excute un script intervalles constants qui compare les fichiers de
configuration avec ceux du serveur Nagios Central.
Pour des questions de scurit que nous avons dj voques, nous excutons
cette vrification grce un canal SSH authentifi avec une paire de cl
publique et prive (voir chapitre 4.4). Il est galement important de
comprendre que le rle du serveur Nagios Local est d'ouvrir la connexion car
celui-ci est gnralement derrire un pare-feu. Ce matriel appartient aux
socits extrieures EASI et ils ne veulent pas ncessairement ouvrir un port
entrant car ceci ouvre une brche dans la scurit de leur rseau. Par contre,
si le pare-feu ouvre un port sortant, cela ne gne en rien la scurit du rseau.
Contenu du fichier "Check-Config".
cd /etc/nagios
do="0"
for i in *.cfg
do
varmonth=`ls -l $i |tr -s ' ' | cut -d ' ' -f "6"`
varday=`ls -l $i |tr -s ' ' | cut -d ' ' -f "7"`
varclock=`ls -l $i |tr -s ' ' | cut -d ' ' -f "8"`
vardistmonth=`ssh nagios@217.71.120.199 ls -l /NagConfig/$1/$i |tr -s ' '
| cut -d ' ' -f "6"`
vardistday=`ssh nagios@217.71.120.199 ls -l /NagConfig/$1/$i |tr -s ' ' |
cut -d ' ' -f "7"`
vardistclock=`ssh nagios@217.71.120.199 ls -l /NagConfig/$1/$i |tr -s ' '
| cut -d ' ' -f "8"`
if [ $varmonth != $vardistmonth -o $varday != $vardistday -o
${varclock:0:4} != ${vardistclock:0:4} ]
then
do="1"
fi
done
if [ $do = "1" ]
then
/etc/nagios/script/Send-ServNag $1 Check-Config 1 "Fichiers differents sur
ServNag"
exit 1
else
/etc/nagios/script/Send-ServNag $1 Check-Config 0 "Fichiers idem sur
ServNag"
exit 0
Fi
Pour chaque fichier d'extension "cfg" contenu dans le rpertoire "/etc/nagios"
de la machine cliente, le script compare la date et l'heure de modification du
fichier avec son homologue sur le serveur Nagios Central. Si ces valeurs sont
diffrentes, le script envoie d'abord un message prvenant que les fichiers ne
sont plus les mmes, ce qui dclenche au sein de Nagios un "Event Handler"
qui excute un autre "plugin" dont le but est de mettre ces fichiers jour. Si
ces valeurs sont les mmes, le script renvoie une rponse positive et Nagios
l'indiquera dans son interface Web.
).2.!. Mise @ 0our des .ic2iers de con.iguration
Si le script "Check-Config" prvient le serveur Nagios Local que les fichiers sont
diffrents, celui-ci lancera le script "Update-Config" avec comme paramtre le
nom de la machine Nagios Local. Ce paramtre permet au script de connatre
le chemin exact des nouveaux fichiers de configuration sur le Serveur Nagios
Central (/NagConfig/$HOSTNAME$). Ce script ne se contente videmment pas
de copier les fichiers. Avant d'craser l'ancienne version, il vrifie la cohrence
des nouveaux fichiers. Si les fichiers semblent corrects, le script redmarre le
programme Nagios.
Contenu du fichier "Update-Config".
# Cration d'un dossier avec la date et heure
test=$(date)
now=$(date +%d%m%y)
now=$now-${test:11:9}
cd /etc/nagios/Backup
mkdir $now
# Copie des fichiers de configuration dans le dossier
cp /etc/nagios/*.cfg /etc/nagios/Backup/$now
# Copie des fichiers de configuration depuis le ServNag
cd /etc/nagios
for i in *.cfg
do
scp -q nagios@217.71.120.19:/NagConfig/NagEASI/$i /etc/nagios/
ssh nagios@217.71.120.19 touch /NagConfig/NagEASI/$i
done
# Test de la configuration avec envoi d'un rapport
/usr/sbin/nagios -v /etc/nagios/nagios.cfg > /etc/nagios/temp
scp -q /etc/nagios/temp nagios@217.71.120.19:/NagConfig/NagEASI/rap-$now
test=$(grep "Total Errors:" /etc/nagios/temp)
test=${test:13}
# Test d'erreur
if [ $test != "0" ]
then
# Erreur de configuration
cd /etc/nagios/Backup/$now/
cp *.cfg /etc/nagios
/etc/nagios/script/Send-ServNag $1 UpConf 2 "Erreur de Config - Reprise de
l'ancienne"
else
# Remise en route de Nagios aprs changement de configuration
/etc/nagios/script/Send-ServNag $1 UpConf 0 "Config OK - Redemarage Nagios
- $now"
/etc/init.d/nagios reload
fi
La premire chose que le script fait, c'est de crer un dossier de sauvegarde
avec la date et l'heure et d'y copier les fichiers de configuration. Cette
sauvegarde permet, en cas de problme, de revenir une version prcdente
et utilisable des fichiers de configuration. Le script lance ensuite une
connexion SSH entre le serveur Nagios Local et le serveur Nagios Central pour
tlcharger les nouveaux fichiers de configuration.
Ds que les fichiers sont tlchargs, le script vrifie leur cohrence grce au
paramtre "-v" lors de la commande de dmarrage de Nagios.
NagEASI:/# /usr/sbin/nagios -v /etc/nagios/nagios.cfg
Nagios 1.3
Copyright (c) 1999-2004 Ethan Galstad (nagios@nagios.org)
Last Modified: 10-24-2004
License: GPL
Reading configuration data...
Running pre-flight check on configuration data...
Checking services...
Checked 83 services.
Checking hosts...
Checked 23 hosts.
Checking host groups...
Checked 2 host groups.
Checking contacts...
Checked 1 contacts.
Checking contact groups...
Checked 2 contact groups.
Checking service escalations...
Checked 0 service escalations.
Checking host group escalations...
Checked 0 host group escalations.
Checking service dependencies...
Checked 0 service dependencies.
Checking host escalations...
Checked 0 host escalations.
Checking host dependencies...
Checked 1 host dependencies.
Checking commands...
Checked 111 commands.
Checking time periods...
Checked 3 time periods.
Checking for circular paths between hosts...
Checking for circular service execution dependencies...
Checking global event handlers...
Checking obsessive compulsive service processor command...
Checking misc settings...
Total Warnings: 0
Total Errors: 0
Things look okay - No serious problems were detected during the pre-flight check
NagEASI:/#
Le script rcupre le nombre total d'erreurs dans la rponse fournie par
Nagios. Si ce nombre est bien gal 0, le script redmarre Nagios avec les
nouveaux fichiers de configuration.
Si ce n'est pas le cas, le script copie les fichiers qu'il a sauvegards, redmarre
le programme Nagios et envoie un message d'erreur ainsi que le rapport du
test au serveur Nagios Central.
).2.). +ri.ication de &*accroissement d*un dis5ue
Un des "plugins" compris dans Nagios donne des informations sur le disque dur
d'une machine. Il permet de connatre l'espace total, l'espace utilis et aussi
l'espace libre. Cette information est trs importante pour la supervision d'une
machine mais n'est pas suffisante pour la prvention de problmes. En plus de
connatre l'espace libre sur un disque dur, il est trs utile de dtecter un
accroissement anormal de donnes sur ce disque dur.
Nous dveloppons donc un "plugin" qui dtecte si le disque dur se remplit
anormalement. Ce "plugin" est complmentaire de celui qui vrifie l'espace
libre sur un disque, il n'est donc pas possible d'utiliser ce "plugin" sans utiliser
le "check_disk" de Nagios. Ce nouveau "plugin" se droule en deux phases.
La premire partie du script retire les informations du disque dur supervis
dans le fichier des statuts de Nagios qui se localise dans
"/var/log/nagios/status.log".
[1118402868] SERVICE;Chung;CheckHDD-C;OK;1/3;HARD;1118402719;1118403019;
ACTIVE;1;0;0;1118385033;0;OK;88642;21290;0;232560;0;0;1;0;0;0;0;0.00;0;1;
1;1;c: - total: 19.53 Gb - used: 9.83 Gb (50%) - free 9.71 Gb (50%)
Ce fichier n'est pas trs comprhensible mais il contient les informations que
nous avons besoin comme la taille totale du disque dur, l'espace utilis et le
pourcentage utilis.
Premire partie du fichier "Check-VarHDD"
totalsize=`grep $1 /var/log/nagios/status.log | grep $2 | cut -d ' ' -f "5"`
useP=`grep $1 /var/log/nagios/status.log | grep $2 | cut -d ' ' -f "11" | cut
-c2,3`
usesize=`grep $1 /var/log/nagios/status.log | grep $2 | cut -d ' ' -f "9"`
if [ "$useP" != "" ]
then
echo "$1 - $2 - $totalsize - $usesize - $useP" >>
/etc/nagios/script/HDD.log
else
echo "Les donnes ne sont pas lisible"
exit 3
Fi
Pour rcuprer ces informations, nous combinons une fonction "grep". Cette
fonction isole la ligne de texte comprenant le nom du service qui vrifie le
disque dur et le nom de l'hte. Ensuite, avec une fonction "cut", nous
sparons les diffrentes informations qui nous sont utiles. Avant d'inscrire ces
informations dans un fichier log que nous avons cr, nous vrifions que ces
donnes sont cohrentes par une boucle conditionnelle "IF". Si les donnes ne
correspondent pas ce que l'on attend, nous arrtons le script et nous
renvoyons une erreur pour que Nagios l'indique bien sur son interface Web.
Notre fichier log "/etc/nagios/script/HDD.log" utilise la syntaxe suivante
"nom_hte - nom_service - espace_total - espace_utilis -
pourcentage_utilis"
...
Danube - CheckHDD-C - 3.91 - 2.94 - 75
Chung - CheckHDD-C - 19.53 - 9.83 - 50
Danube - CheckHDD-C - 3.91 - 2.94 - 75
Chung - CheckHDD-C - 19.53 - 9.83 - 50
C'est partir de ce point que commence rellement le script de vrification.
Nous rcuprons les deux dernires valeurs correspondant au service que nous
vrifions. Pour cette recherche, nous utilisons la commande "tail" qui lit la fin
d'un fichier et la commande "grep" que nous avons utilis prcdemment. Une
fois les pourcentages d'occupation du disque dur rcuprs diffrents
intervalles de temps, nous vrifions qu'ils contiennent bien une valeur. Une
simple soustraction nous donnera l'accroissement de l'espace occup sur un
intervalle de temps dfini par Nagios.
Si l'accroissement est suprieur la valeur critique fournie en paramtre ou si
il est comprise entre la valeur d'attention et la valeur critique, le script renvoie
un message prvenant de l'ventualit d'un problme et termine le script avec
la valeur de retour adquate. Par contre, si la valeur de l'accroissement est
infrieure la valeur d'attention, le script renvoie un message pour prvenir
qu'il n'y a pas de problmes et termine le script avec "0" comme valeur de
retour. Nagios interprte ensuite ces rsultats pour l'afficher dans son
interface Web.
Voici la deuxime partie du fichier "Check-VarHDD"
nb=`tail -n 50 /etc/nagios/script/HDD.log | grep $1 | grep -c $2`
P=`tail -n 50 /etc/nagios/script/HDD.log | grep $1 | grep $2 | cut -d ' ' -f "9"`
i=èxpr $nb - 1`
i=èxpr $i*3`
j=èxpr $nb - 2`
j=èxpr $j*3`
x=${P:$i:2}
y=${P:$j:2}
if [ "$x" != "" -a "$y" != "" ]
then
u=èxpr $x - $y`
if [ "$u" -gt $4 ]
then
echo "Accroissement suprieur a $4 %"
exit 2
else
if [ "$u" -gt $3 ]
then
echo "Accroissement entre $3 % et $4 %"
exit 1
else
echo "Accroissement infrieur a $3 %"
exit 0
fi
fi
else
echo "Pas assez de valeur"
exit 3
Fi
A propos de ce script, n'oublions pas de donner accs au fichier log que nous
avons cr pour l'utilisateur de Nagios, sinon celui-ci ne saura ni crire ni lire le
fichier et il renverra des valeurs vides. Il est aussi intressant d'ajouter que
l'intervalle de temps entre deux relevs de valeurs dpend entirement de
Nagios car c'est lui qui lance le script en suivant son fichier de configuration.
).2.,. Pertinence des noti.ications
L'absence de messages du serveur Nagios Local a deux significations: la
premire est qu'il n'y a aucun problme dtect par le serveur Nagios Local et
donc aucune alerte n'est envoye. La seconde signifie que le serveur Nagios
Local n'assure plus son rle, soit parce qu'il ne rpond plus, soit parce qu'il y a
un problme sur le rseau. Dans ce cas, il est trs important de prvenir le
surveillant de ce disfonctionnement. Contrairement au clbre dicton "pas de
nouvelles, bonnes nouvelles", une autre solution pour vrifier la pertinence de
ces rsultats s'impose.
Dans les standards de Nagios, il existe un "plugin" appel "check_nagios"
utilis pour vrifier si les autres serveurs Nagios sont bien oprationnels. Ce
"plugin" est lanc depuis le Serveur Nagios Central et interroge le serveur
Nagios Local. Si les deux serveurs sont spars par un pare-feu, nous devons
changer les configurations de ceux-ci, sinon la connexion sera refuse.
En d'autres termes, le client doit ouvrir une porte entrante sur son pare-feu, ce
qu'il risque de refuser pour des questions videntes de scurit. Nous devons
donc trouver une autre solution.
L'ide est de forcer le serveur Nagios Local envoyer une notification de bon
fonctionnement au serveur Nagios Central, intervalles rguliers. Nous
dcidons d'envoyer cette notification toutes les cinq minutes par un petit script
SHELL qui va utiliser le client NSCA pour communiquer avec le serveur Nagios
Central travers Internet. Ce script est dtaill plus haut dans ce travail. Sur
le serveur Nagios Central, nous vrifions juste l'intervalle de temps entre le
dernier message reu et l'heure actuelle. Si ce laps de temps est suprieur
dix minutes, alors une notification est envoye au travers du client NSCA pour
avertir le serveur Nagios Central du problme. Celui-ci suivra la procdure
habituelle pour prvenir la personne responsable.
Nous dveloppons ce script en PERL, car ce langage offre une facilit de
maniement des chanes de caractres et de lecture dans les fichiers. Ce script
se droule en deux parties, la premire lit le fichier
"/etc/log/nagios/nagios.log" et regarde l'heure de la dernire notification du
serveur Nagios Local. La deuxime partie calcule la diffrence de temps entre
cette dernire notification et l'heure actuelle. Si elle est suprieure dix
minutes, un message d'alerte est envoy au serveur Nagios Central via le
client et serveur NSCA. Ds que le serveur Nagios Central reoit ce rapport
d'erreur, il envoie un mail la personne concerne.
Voici le code du script "Check-Notif".
open(F, '/var/log/nagios/nagios.log') || die "Problme l\'ouverture : $!";
$i = 0;
$searchhost="debian";
$searchservice="update";
$timestamp = 0;
while($ligne = <F>)
{
$temp=substr($ligne,(index($ligne,";")+1));
$host=substr($temp,0,(index($temp,";")));
$temp=substr($temp,(index($temp,";")+1));
$service=substr($temp,0,(index($temp,";")));
$temp=substr($temp,(index($temp,";")+1));
$status=substr($temp,0,(index($temp,";")));
$com=substr($temp,(index($temp,";")+1));
if ($searchhost eq $host && $searchservice eq $service)
{
if ($timestamp < substr($ligne,1,10))
{
$timestamp = substr($ligne,1,10);
}
}
}
close F || die "Problme la fermeture : $!";
$diff = time - $timestamp;
if ($diff > 10)
{
print "Erreur";
open(CON, "| /usr/sbin/send_nsca -H 172.22.3.17 -c
/etc/nagios/send_nsca.cfg");
$li= "debian\tupdate\t1\ttestfin\n";
print CON $li;
close CON;
}
).!. Modu&e NS1&ient
Nagios est initialement conu pour un milieu Linux, il a donc un "plugin" qui
permet d'excuter n'importe quelle commande distance via une connexion
SSH. En ce qui concerne Windows, rien ne semble tre prvu par dfaut.
Indpendamment du systme dexploitation, il est possible deffectuer des
supervisions orientes rseau. Ces supervisions ne font pas intervenir
directement le systme d'exploitation. Par contre, pour superviser des
informations propres au matriel, nous devons nous adresser au systme
d'exploitation. Nous diffrencions donc le monde Linux et le monde Windows.
Il existe deux possibilits pour superviser une machine Windows: soit utiliser le
protocole SNMP, soit utiliser un module qui permet de vrifier des services
standard de Windows.
La premire solution travaille avec le SNMP mais comme nous l'avons dj dit
prcdemment, Nagios peut travailler avec le SNMP mais n'a pas t
dvelopp sur ce systme. En plus, nous devons installer sur les machines
superviser une srie d'outils comme le SNMP, la base de donnes MIB, .
Cette mthode est donc trs complexe.
L'autre mthode, propre Nagios, utilise un module appel "NSClient" qui
supervise des serveurs NT. Ce module inclut un service qui tourne sur la
machine et un "plugin" qui s'excute partir du serveur Nagios Local.
Le module NSClient supervise:
o La charge CPU
o Lutilisation de lespace disque
o Le temps de fonctionnement
o Ltat des services
o Ltat des processus
o Lutilisation de la mmoire
Pour ce qui est de l'installation de ce module, nous l'avons expliqu en dtail
dans une procdure mise disposition des employs de EASI. Voir chapitre
4.10 pour plus d'informations ce sujet.
Le dtail des commandes pour l'utilisation de ce module se trouve dans les
annexes (Annexe 9)
).). Scurisation du trans.ert d*in.ormations
Pour passer des informations entre le serveur Nagios Local et Central, il faut
passer par Internet. Ce passage nest pas scuris, cest pour cela que nous
utilisons le protocole SSH. Celui-ci demande par dfaut un mot de passe lors
du passage des informations entre les 2 serveurs. Ceci est videmment
impossible puisque la plupart de ces passages sont automatiques. De plus, il
est impensable d'imaginer une personne taper le mot de passe chaque
connexion SSH.
La solution idale utilise le principe des cls publiques et prives. La cl
publique est installe sur le serveur Nagios Central tandis que la cl prive est
installe sur le serveur Nagios Local. Pratiquement, le serveur Nagios central
possdera les cls publiques de tous les serveurs Nagios Locaux.
La plupart des serveurs SSH utilise la version 2 du protocole. La version 1 est
trop vulnrable, elle utilise un cryptage RSA1 (Rivest Shamir dleman) tandis
que la version 2 utilise le cryptage RSA et DSA (Distributed System
rchitecture). Nous utilisons ce protocole pour transfrer les fichiers de
configuration sur le Web car ces fichiers contiennent toute la topologie du
rseau de l'entreprise et une attention toute particulire est apporte pour que
ces fichiers ne soient pas intercepts. Nous choisissons donc le SSH version
2.
Nous configurons d'abord le serveur Nagios Local, car c'est lui qui cre la paire
de cls SSH (ensemble de la cl publique et de la cl prive).
NagEASI:/# ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_dsa
Your public key has been saved in /root/.ssh/id_dsa.pub
The key fingerprint is:
0b:0b:54:f2:75:23:dc:05:10:81:90:95:ba:1f:ca:8b nagios@NagEASI
debian:/#
Cette opration cre deux fichiers dans "/root/.ssh":
-rw------- 1 root root 668 Jun 9 13:08 id_dsa
-rw-r--r-- 1 root root 601 Jun 9 13:08 id_dsa.pub
Maintenant que les cls sont cres, nous transmettons au serveur Central la
cl publique. Le fichier nomm "id_dsa.pub" est la cl publique, il s'ajoute la
fin du fichier "authorized_keys" qui se retrouve dans le rpertoire "/root/.ssh"
sur le serveur Central.
ServNag:/# cd /root/.ssh
ServNag:/# scp root@NagEASI:/root/.ssh/id_dsa.pub /root/.ssh/
Password: ********
ServNag:/# cat id_dsa.pub >> authorized_keys
ServNag:/# rm id_dsa.pub
Pour tester le bon fonctionnement, nous tapons la ligne de commande suivante
sur le serveur Nagios Local en tant connect comme utilisateur "nagios".
NagEASI:/# ssh -l nagios ServNag
Last login: Thu Jun 9 08:46:49 2005 from 172.22.3.75
NagEASI:/# _
Si aucun mot de passe nest demand, c'est que tout fonctionne correctement.
Dans le cas contraire, nous vrifions la configuration de sshd: le fichier
"/etc/ssh/sshd_config" doit contenir les paramtres suivants:
RSAAuthentication yes
PubkeyAuthentication yes
).,. Mode mu&ti?uti&isateurs
Aprs avoir install le serveur Nagios Central sur le rseau DMZ de chez EASI
et un serveur Nagios Local chez chaque client, lide est de permettre ceux-ci
de visualiser ltat de leur infrastructure informatique partir du serveur
Nagios Central. Les serveurs Nagios Locaux ne permettent pas de visualiser
localement ltat du rseau car ils n'excutent que des "plugins" et envoient les
rsultats au serveur Nagios Central. Le seul moyen pour un client davoir un
aperu de ltat de son rseau est de consulter le serveur Nagios Central, ce
qui rejoint le principe de supervision centralise.
Pour des raisons de scurit, un client a accs sa propre infrastructure
informatique et rien que la sienne. De mme, EASI, de son ct, voit toutes
les infrastructures distantes. Plusieurs solutions s'offrent nous.
La premire est de modifier le fichier en CGI qui affiche ltat des htes et des
services ("status.cgi") en lui ajoutant des boucles conditionnelles afin de
restreindre laccs aux informations en fonction de lutilisateur. Ce fichier est
crit en C et compil, nous avons donc recherch le code source. Une fois
trouv, nous l'avons compil avec :11 (:NU 1ompiler 1ollection), livr en
standard sur la trs grande majorit des systmes d'exploitation libres. Cette
technique sest avre fastidieuse car nous avons eu un trs grand nombre
derreurs la compilation, majoritairement dues aux fichiers den-tte
(dextension .h) et aux mauvais chemins daccs vers les fichiers de
configuration.
Aprs de longues recherches sur Internet, car ce problme ne semble pas tre
dactualit chez les utilisateurs de Nagios, la solution s'est avre tre dans la
configuration de Nagios. Si lon prend comme exemple un client nomm
Franois qui n'a accs qu une certaine partie de la supervision du rseau,
nous le dclarons d'abord dans le fichier "/etc/nagios/htpasswd.users" avec
son nom dutilisateur et son mot de passe qui y est crypt. Voici la ligne que
lon retrouve dans ce fichier avec la syntaxe "nom_utilisateur:
mot_de_passe_crypt".
Grce cette ligne, cet utilisateur peut sauthentifier et se connecter
linterface Web de Nagios. Nous le dfinissons maintenant en tant que contact
dans le fichier "contacts.cfg" afin quil soit associ ses htes et services.
Nous y ajoutons donc les lignes suivantes:
define contact{
contact_name francois
alias Utilisateur test
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,c,r
host_notification_options d,u,r
service_notification_commands notify-by-email
host_notification_commands host-notify-by-email
email f.chung@easi.be
}
Ce contact a besoin de faire partie dun groupe car les htes et services sont
eux-mmes associs des groupes. Pour continuer notre exemple, lutilisateur
Franois est plac dans le groupe appel EASI. Nous lajoutons dans le fichier
"contactgroups.cfg" de la manire suivante:
define contactgroup{
contactgroup_name EASI
alias EASI USERS
members francois
}
Nous dfinissons ensuite les groupes qui ont accs un certain groupe d'htes.
Cette opration se droule dans le fichier "hostgroups.cfg". Aprs avoir
spcifi un nom de groupe dhtes, nous dclarons quels seront les groupes de
contacts et les htes qui en font partie. Ainsi, dans cet exemple, les groupes
"admin" et "EASI" visualisent seulement ltat des pare-feux, du routeur et
dune imprimante chez EASI. Nous redmarrons ensuite Nagios pour rendre
les modifications effectives.
define hostgroup{
hostgroup_name EASI-Device
alias Groupe des devices EASI
contact_groups admin,EASI
members FWzaventem,FWliege,FWluxembourg,RtEASI,IBM-InfoPrint
}
Ainsi, lutilisateur Franois a maintenant bien accs linterface Web de Nagios
mais son accs aux rsultats de la supervision des htes et services est
restreint. Il ne peut consulter que les htes lists dans le groupe dont il est
membre. Pourtant, Franois sait toujours aller changer quelques lments de
la configuration de Nagios car cest dans ses droits par dfaut. Une solution
propose par la documentation officielle de Nagios est de supprimer le fichier
de configuration "cmd.cgi", fichier qui permet justement de changer des
lments de la configuration de Nagios. De la sorte, plus personne ne peut
effectuer des modifications, mme EASI. Donc, ce n'est pas une bonne
solution.
Alors, nous dplaons le fichier de configuration "/usr/lib/cgi-bin/nagios
/cmd.cgi" dans un rpertoire que nous protgeons par un fichier
"htpasswd.users" qui se nomme "/usr/lib/cgi-bin/command/cmd.cgi ". Voici
les lignes ajouter dans le fichier "/etc/nagios/apache.conf":
ScriptAlias /nagios/cmd /usr/lib/cgi-bin/command
<DirectoryMatch /usr/lib/cgi-bin/command>
Options ExecCGI
Order Allow,Deny
Allow From All
AuthType Basic
AuthUserFile /etc/nagios/htpasswd2.users
require valid-user
</DirectoryMatch>
A partir de maintenant, l'utilisateur Nagiosadmin a accs tout car il
reprsente un employ de chez EASI tandis que l'utilisateur Franois, qui
reprsente un client, ne peut changer la configuration des services et htes
mais a toujours le droit de voir l'tat de son infrastructure rseau.
Du ct du rpertoire o se trouvait le fichier "cmd.cgi", nous avons remplac
ce dernier par un fichier du mme nom et dont le but est de rediriger la page
vers le dossier protg. De nouveau, notre premire ide fut de lcrire en C,
mais ce langage ne permet pas aisment de traiter les variables reues
travers lURL via la mthode GET. Cest pourquoi nous choisissons le langage
PERL, beaucoup plus souple car cest un langage interprt qui gre facilement
ces variables.
Malgr cela, nous avons encore quelques problmes dus des droits daccs
au fichier "cmd.cgi". Tout dabord, il a fallu changer le propritaire du fichier
via la commande "chown" (voir Annexe 6). En effet, par dfaut, il ny a que le
super-utilisateur "root" qui a le droit de lecture sur ce fichier. Nous dclarons
donc Nagios comme tant le propritaire de ce fichier.
ServNag:/usr/lib/cgi-bin/nagios# chown nagios cmd.cgi
Ensuite, nous modifions les droits daccs ce fichier par la commande
"chmod" (voir Annexe 5). Nous ajoutons (paramtre +) le droit tout le
monde (paramtre a, pour "all") de lire (paramtre r, pour "read") et excuter
(paramtre x, pour "execute") ce fichier.
ServNag:/usr/lib/cgi-bin/nagios# chmod a+rx cmd.cgi
Et voici le script en PERL contenu dans ce fichier et qui redirige la page vers le
rpertoire protg contenant le fichier "cmd.cgi" initial:
#!/usr/bin/perl -w
use strict;
use CGI;
my $r = new CGI;
my $type_commande = $r->param('cmd_typ');
my $hote = $r->param('host');
my $serv = $r->param('service');
print $r->redirect(-
uri=>"../cmd/cmd.cgi?cmd_typ=$type_commande&host=$hote&service=$serv");
).<. ut2enti.ication "ar LDP
A ce stade, le mode multi-utilisateurs de Nagios fonctionne, il distingue
diffrents utilisateurs et affiche les informations auxquelles ceux-ci ont accs.
Le but de l'authentification par LDAP est de possder deux niveaux de scurit.
Un premier niveau pour les clients de EASI qui visualise l'infrastructure rseau,
les services superviss et leurs statuts. Un deuxime niveau de scurit pour
les personnes travaillant chez EASI et qui donne en plus un accs aux
commandes de Nagios.
EASI offre dj un service similaire qui permet aux clients de se connecter au
site Extranet de la socit. Les informations requises pour cette connexion
sont stockes dans un annuaire Domino. L'ide est que Nagios utilise ce
mme annuaire pour que les clients et employs d'EASI utilisent les mmes
identifiants et mots de passe. Depuis Domino, il est facile de crer un
annuaire LDAP qui nous servirait de base commune aux deux services.
L'avantage de cette mthode rside dans le fait que si un utilisateur change
son mot de passe sur l'Extranet de EASI, il en est de mme pour son mot de
passe Nagios.
Un annuaire LDP est un annuaire gr par lintermdiaire du protocole du
mme nom (Lightweight Directory ccess Protocol) et qui permet la gestion
dannuaires disponibles sur le rseau.
Par dfaut, les utilisateurs qui ont accs l'interface Web de Nagios doivent
avoir leur identifiant et mot de passe dans le fichier
"/etc/nagios/htpasswd.users" qui est prcis dans le fichier de configuration de
Apache.
nagiosadmin:6mU7.mzZYqS2M
Concrtement, il faut donc relier les droits daccs dApache non plus en
fonction dun fichier "htpasswd.users" mais en fonction de lannuaire LDAP, vu
que tous les clients de EASI y sont rpertoris. L'ide est de donner accs
l'interface Web de Nagios tous ceux qui s'affichent dans cet annuaire. Cela
ne veut pas dire que tous les clients de EASI voient les informations du rseau
car c'est quand mme Nagios qui dcide qui voit tel hte ou tel service. Il ne
faut pas oublier non plus que les employs de EASI ont un accs au dossier
contenant le fichier "cmd.cgi", celui-ci intervient sur les paramtres de Nagios.
Comme le protocole LDAP utilise une arborescence dans les contacts constitus
de groupe, il suffit de restreindre laccs au rpertoire contenant le fichier
"cmd.cgi" aux membres du groupe EASI.
Pratiquement, la mise en place de cette infrastructure est difficile et nous
avons pass beaucoup de temps la comprendre et la tester. La complexit
du protocole et larchitecture de lannuaire LDAP en ont clairement t la
cause. Pour mieux comprendre cette architecture, nous avons tlcharg un
client LDAP sur Internet, appel "LDAP Browser", pour parcourir lannuaire et
lanalyser. Pour interroger celui-ci, nous utilisons le module "ldapsearch"
fourni avec le logiciel "OpenLDAP", qui est une implmentation Open Source de
lannuaire LDAP. Ce programme interroge donc cet annuaire par le biais de
requtes dont voici la syntaxe:
ldapsearch -h hostna%e -b "baseD&" ' options ( "filter" ' attribute&a%e ))) (
Lattribut "-h" spcifie le nom du serveur sur lequel tourne lannuaire LDAP,
que ce soit par le nom de domaine ou par son IP. Lattribut
"-b" spcifie la base de l'annuaire appel "Distinguished Name" (DN) dont le
rle est de situer trs exactement lendroit o se trouve le contact dans cet
arborescence. On affine galement cette recherche avec des options, tels que
ltendue de la recherche et/ou un filtre.
Voici ci-dessous un exemple de commande envoye lannuaire. Le
paramtre "1ommon Name" (CN) correspond au nom du groupe dans lequel
on recherche le contact et lattribut "/rganization" (O) correspond au nom de
lorganisation laquelle appartient le groupe. Le rsultat de cette commande
nous donne les dtails du groupe NAGIOS.
ldapsearch -h *+,),,)*)- -b "C&.&A"#OS$ O.AS# "
Ces essais accomplis, nous comprenons quels paramtres nous fournirons
l'annuaire pour atteindre les contacts dans cette arborescence complexe. A
partir de l, nous cherchons comment le lier avec Apache, qui matrise
linterface Web de Nagios et lannuaire LDAP au niveau de lauthentification.
Aprs quelques recherches, nous trouvons un module qui excute le lien et
dont le nom est "auth_ldap". Aprs le tlchargement, nous le copions dans le
rpertoire des modules que Apache lance au dmarrage, c'est--dire dans le
rpertoire "/etc/apache2/mods-enabled/".
Pour permettre lauthentification travers lannuaire LDAP, ces quelques lignes
dans le fichier "/etc/nagios/apache.conf" sont galement ncessaires:
ScriptAlias /nagios/cgi-bin /usr/lib/cgi-bin/nagios
<DirectoryMatch /usr/lib/cgi-bin/nagios>
Options ExecCGI
AuthLDAPAuthoritative on
AuthLDAPEnabled On
AllowOverride None
AuthType Basic
AuthLDAPURL "ldap://217.71.120.196:389/?uid?sub"
require valid-user
</DirectoryMatch>
Le paramtre "AuthLDAPURL" tablit la connexion lannuaire LDAP travers
une URL. "WebServ01" est le serveur sur lequel est plac cet annuaire chez
EASI, il utilise le port par dfaut du protocole LDAP qui est le 389. Le
paramtre "uid" (user identifiant) effectue l'authentification par identifiant
unique de chaque contact et le "sub" (subtree) permet dtendre la zone de
recherche toute larborescence infrieure. Cela permet de retrouver toutes
les personnes qui font partie de lannuaire et de leur accorder le droit daccder
linterface Web de Nagios.
Par contre, pour le dossier contenant le fichier "cmd.cgi" qui modifie des
paramtres de Nagios, nous restreignons l'accs non pas tout l'annuaire
LDAP mais uniquement aux contacts appartenant l'organisation de EASI.
ScriptAlias /nagios/cmd /usr/lib/cgi-bin/command
<DirectoryMatch /usr/lib/cgi-bin/command>
Options ExecCGI
AuthLDAPAuthoritative on
AuthLDAPEnabled On
AllowOverride None
AuthType Basic
AuthLDAPURL "ldap://217.71.120.196:389/O=EASI?uid?sub"
require valid-user
</DirectoryMatch>
Nous ajoutons donc l'URL le paramtre "O" qui spcifie le groupe dont les
membres ont accs linterface Web.
).A. Noti.ications
Lorsquun problme apparat sur un composant rseau ou sur un service
supervis, Nagios cherche dans ses fichiers de configuration et regarde le nom
des contacts qui y sont associs pour leur envoyer une notification du
problme. Celle-ci peut se faire par diffrentes mthodes. A chaque contact
est associ une commande pour envoyer la notification.
Nous prcisons donc la commande pour un contact. Dans le fichier
"contacts.cfg", deux lignes sont ncessaires pour prciser les commandes
utiliser.
define contact{
contact_name Jonathan
...
service_notification_commands notify-by-email
host_notification_commands host-notify-by-email
email j.lousse@easi.be
}
Dornavant, lors de l'envoi d'une notification, Nagios excute la commande
propre au contact. Il est intressant de dire que deux sortes de notifications
sont introduites dans ce fichier. La premire prvient le contact en cas de
dfaillance d'un service. La seconde, quant elle, prvient en cas de problme
sur un hte.
Il est aussi important de prciser la commande, il ne suffit pas de l'appeler.
Les commandes utilises pour la notification sont dans un fichier appel
"misccommands.cfg". Voici le code permettant d'envoyer un mail en cas de
problme sur un service.
# 'notify-by-email' command definition
define command{
command_name notify-by-email
command_line /usr/bin/printf "%b" "***** Nagios *****\n\nNotification
Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress:
$HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $DATETIME$\n\nAdditional
Info:\n\n$OUTPUT$" | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ alert -
$HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$
}
Comme dans tous les fichiers de commande, la syntaxe est toujours la mme.
Elle se compose du nom de commande qui est utilis lorsqu'on en fait appel et
de la commande qui est excute par Nagios.
La mme mthode est utilise lors de la notification de l'tat d'un hte
quelques paramtres prs comme le nom du service ou l'tat du service. Dans
le fichier "misccommands.cfg", une deuxime fonction dfinie existe en cas de
problme sur un hte.
Dans le cas de la supervision centralise, le serveur Nagios Local suit la mme
procdure, mais au lieu d'envoyer un mail une personne, il prvient le
serveur Nagios Central. C'est le rle du serveur Central d'envoyer les
notifications aux personnes qui grent le rseau via un mail ou tout autre
moyen de communication. Nous changeons les paramtres dans le fichier
"contacts.cfg".
define contact{
contact_name Jonathan
...
service_notification_commands notify-easi
host_notification_commands host-notify-easi
email j.lousse@easi.be
}
Bien entendu, nous avons cr les fonctions correspondantes aux nouvelles
mthodes de notification. Nous les avons ajoutes dans le fichier
"misccommands.cfg".
# 'notify-easi' command definition
define command {
command_name notify-easi
command_line /etc/nagios/script/Send-ServNag EASI-$HOSTNAME$
$SERVICEDESC$ "$SERVICESTATE$" "$OUTPUT$"
}
# 'host-notify-easi' command definition
define command {
command_name host-notify-easi
command_line /etc/nagios/script/Send-ServNag EASI-$HOSTNAME$
$HOSTSTATE$ "$OUTPUT$"
}
La fonction excute lance le script "Send-ServNag" que nous avons dtaill
plus tt pour communiquer avec le serveur Central. A l'excution du script,
nous lui envoyons une srie de paramtres pour prciser le nom du service ou
de l'hte, mais galement le statut et le commentaire qui s'y rapportent.
Le serveur Nagios Central reoit le message pass par le module NSCA, qui
s'inscrit dans un fichier log. A intervalles rguliers, Nagios lit ce fichier et met
jour ses informations. Si une notification prvient qu'un problme existe,
Nagios prvient alors les personnes grant le rseau. Par dfaut, cela se fait
par lenvoi de mails intervalles prciss pour chaque hte ou service jusquau
retour la normale. Il est possible de configurer la notification pour que
Nagios n'envoie qu'un seul mail. Cette solution est trs intressante car elle
vite l'envoi de nombreux mails lorsque des problmes surviennent. Cette
option se dfinit dans le fichier "services.cfg" pour la notification des services
et dans "hosts.cfg" en ce qui concerne les htes.
Voici le code contenant les informations de la notification en rapport avec un
service dans le fichier "services.cfg":
define service{
use service-check
host_name Linux
contact_groups admin
notification_interval 240
...
}
Les premires lignes dfinissent le service supervis. Les autres lignes sont
expliques plus en dtail dans la partie qui concerne les fichiers de
configuration. Ce qui nous intresse ici, ce sont les deux dernires lignes. Le
champ "contact_groups" dfinit le nom du groupe prvenir en cas de
problme, ces groupes sont dfinis dans le fichier "contactgroups.cfg". Nous
dfinissons galement l'intervalle entre deux notifications par un chiffre dans le
champ "notification_interval", ce chiffre reprsente un nombre d'units de
temps.
Voici un schma rsumant le chemin parcouru par les notifications:
).B. 6ic2iers de con.iguration
La configuration de Nagios est divise en une dizaine de fichiers texte. Chaque
fichier traite un thme bien prcis. Dans ce travail, nous n'allons pas expliquer
toutes les options possibles dans ces diffrents fichiers. La liste complte de
ces options est dtaille dans les annexes (Annexe 7). Cette partie explique
comment les fichiers de configuration de Nagios fonctionnent et les options les
plus souvent utilises.
).B.1. Les 2Ctes #2osts.c.g(
Un hte symbolise un serveur physique, une station de travail, un
priphrique, un quipement ou n'importe quel composant connect au rseau.
Pour superviser un hte, nous l'ajoutons avec ses caractristiques dans le
fichier "hosts.cfg". Pour plus de facilit, nous dfinissons un modle qui
permet de dfinir les informations communes plusieurs htes. Ce systme
de modle ressemble au principe dhritage en programmation. Dans notre
cas, nous rassemblons une srie d'options dans un modle que nous appelons
"host-check". Voici ces options:
define host{
name host-check
notifications_enabled 1
event_handler_enabled 0
retain_status_information 1
check_command check-host-alive
max_check_attempts 3
notification_period 24x7
notification_options d,u,r
register 0
}
name
Cest le nom donn au modle, il permet d'associer ce modle aux htes.
noti.ications>ena-&ed
Si cette directive est mise 0, la notification lors de problmes est dsactive.
Dans notre cas, nous voulons recevoir ces notifications, donc nous lui
associons la valeur 1.
event>2and&er>ena-&ed
Cette directive active le gestionnaire d'vnements si elle est mise 1. Le
gestionnaire d'vnements est une commande optionnelle qui est excute
chaque changement d'tat. L'utilit de ces gestionnaires d'vnements est
qu'ils permettent Nagios de rsoudre certains problmes de manire
prventive avant que quelqu'un ne reoive une notification.
retain>status>in.ormation
Nagios mmorise les statuts des htes et services lors de son redmarrage si
nous associons cette directive la valeur 1.
c2ec$>command
Cette directive dfinit le nom de la commande utiliser pour vrifier la validit
d'un service ou d'un hte. Dans notre cas, le nom de la commande utilise est
"check-host-alive". Cette commande lance un "PING" vers l'hte pour voir sil
est bien connect au rseau. Si cet argument est vide, Nagios suppose que
l'hte est toujours bien connect.
max>c2ec$>attem"ts
Lorsqu'un hte passe en statut d'erreur, Nagios vrifie un certain nombre de
fois son rsultat avant d'envoyer une notification.
noti.ication>interva&
Cette directive dfinit le nombre d'units de temps entre les notifications. Si
cette valeur est gale 0, Nagios n'envoie qu'une seule notification.
noti.ication>"eriod
Cette directive dfinit la priode pendant laquelle les notifications sont
envoyes. Par dfaut, la priode est "24x7" ce qui indique que les notifications
sont envoyes 24 heures sur 24 et 7 jours sur 7.
noti.ication>o"tions
Il existe diffrentes sortes de notifications que nous dfinissons grce une
combinaison de lettres: "d" signifie lenvoi de la notification pour un tat
DOWN, "u" lenvoi de la notification pour un tat UNREACHABLE, "r" l'envoi de
la notification pour le retour la normale (tat OK). Et la lettre "n" (none)
permet de ne pas envoyer de notifications.
register
Cette directive diffrencie un modle d'un hte.
Ci-dessous, un exemple de dfinition dhte qui utilise ce modle. Tous les
htes superviser doivent tre dans le mme fichier que les modles.
# PC TEST
define host{
use host-check
host_name IBMR30
alias PC TEST
address 172.22.3.74
}
use
Cette directive associe un modle existant lhte. Dans notre cas, nous
lassocions avec le modle dcrit prcdemment.
2ost>name
Identifie l'hte, ce nom est utilis dans les groupes d'htes et dans les
dfinitions de services pour lui faire rfrence.
a&ias
Une description qui identifie plus facilement lhte.
address
Une adresse IP ou un nom qui permet de joindre l'hte
).B.2. Les services #services.c.g(
Un service est une tche fonctionnant sur un hte. Le terme de service
s'applique aussi bien un rle de l'hte (POP, SMTP, HTTP, ...) qu' une
mesure effectue sur un hte (charge moyenne du systme, usage des
disques, temps de rponse, ...). Tout comme les htes, nous dfinissons des
modles pour les services. Comme certaines directives sont les mmes pour
les dfinitions dhtes et de services, seules celles qui sont associes
exclusivement aux services seront dcrites. Voici le code de notre modle:
define service{
name service-check
active_checks_enabled 1
passive_checks_enabled 0
notifications_enabled 1
event_handler_enabled 0
retain_status_information 1
check_period 24x7
max_check_attempts 3
normal_check_interval 5
retry_check_interval 1
contact_groups admin
notification_period 24x7
notification_options c,r
register 0
}
active>c2ec$s>ena-&ed
Cette directive permet de vrifier activement un service. Les contrles actifs
sont des contrles lancs par Nagios.
"assive>c2ec$s>ena-&ed
Nagios traite galement les rsultats provenant de contrles passifs, c'est--
dire excuts par des applications tierces.
c2ec$>"eriod
Dfinit la priode pendant laquelle Nagios lance des contrles actifs.
norma&>c2ec$>interva&
Nombre d'units de temps que Nagios attend avant de retester le service.
contact>grou"s
C'est une liste de noms de groupes de contacts qui reoivent les notifications.
Voici un exemple de dfinition de service qui utilise le modle que nous avons
dtaill.
define service{
use service-check
host_name Chung
service_description CheckVarHDD-C
check_command check-VarHDD!CheckHDD-C!1!2
normal_check_interval 2
}
2ost>name
Cette directive dfinit le nom de l'hte sur lequel tourne le service ou avec
lequel il est associ.
service>descri"tion
Cette directive contient une description du service. Deux services associs au
mme hte ne peuvent avoir la mme description. Les services sont identifis
avec les directives "host_name" et "service_description".
).B.!. Les contacts #contacts.c.g(
En principe, un contact est une personne physique qui est prvenue en cas de
problme sur le rseau. Mais dans notre cas, un contact est plutt une
personne qui peut se connecter l'interface Web de Nagios. Les notifications
de tous les problmes sont envoyes exclusivement EASI.
Voici le dtail d'un contact:
define contact{
contact_name nagios
alias Nagios Admin
service_notification_commands notify-easi
host_notification_commands host-notify-easi
email nagios@localhost.localdomain
}
contact>name
Dfinit le nom qui identifie le contact. Il est utilis dans les dfinitions de
groupes de contacts.
a&ias
Donne une description ou un nom plus long pour le contact.
service>noti.ication>commands
2ost>noti.ication>commands
Ces deux directives sont dtailles plus tt dans ce travail, dans la notification
de Nagios.
emai&
Dfinit l'adresse email du contact. Selon la manire dont la commande de
notification est dfinie, elle est utilise pour mettre un email.
).B.). Les grou"es d*2Ctes #2ostgrou"s.c.g(
Les groupes d'htes se composent d'un ou de plusieurs htes pour simplifier
les notifications. Chaque hte appartient au moins un groupe et parfois
plusieurs. Les groupes d'htes ont une plus grande importance sur le serveur
Nagios Central car chaque groupe reprsente le rseau d'un des clients de
EASI.
Define hostgroup{
hostgroup_name EASI-Device
alias Groupe des devices EASI
contact_groups admin,EASI
members FWzaventem,FWliege,FWluxembourg,RtEASI,IBM-InfoPrint-
1120,FWliegeT
}
2ostgrou">name
Dfinit le nom qui identifie le groupe dhtes.
contact>grou"s
Dfinit le nom des groupes de contacts notifier en cas de problmes
mem-ers
Une liste de noms d'htes inclure dans ce groupe. Les noms doivent tre
spars par des virgules.
).B.,. Les grou"es de contacts #contactgrou"s.c.g(
En temps normal, un groupe de contacts regroupe des contacts. Cette
mthode facilite l'envoi de notifications un ensemble de personnes. Sur le
serveur Nagios Central, il est plus facile d'inscrire dans un mme groupe les
employs d'un mme client de EASI et de donner accs un groupe plutt
qu' une longue liste de contacts. Ce principe de multi-utilisateurs a dj t
dvelopp plus tt dans ce travail.
define contactgroup{
contactgroup_name EASI
alias EASI USER
members nagios
}
contactgrou">name
Dfinit le nom utilis pour identifier le groupe de contacts.
).B.<. Les "riodes #time"eriods.c.g(
Une priode est une tranche horaire pour les diffrents jours de la semaine
considrs comme valides pour l'envoi de notifications et pour le contrle des
services. Ce fichier n'a pas beaucoup d'intrt dans le cadre de notre travail
car les notifications et vrifications se droulent tout le temps. Mais il est
envisageable de crer des priodes de vrification.
define timeperiod{
timeperiod_name 24x7
alias 24 Hours A Day, 7 Days A Week
sunday 00:00-24:00
monday 00:00-24:00
tuesday 00:00-24:00
wednesday 00:00-24:00
thursday 00:00-24:00
friday 00:00-24:00
saturday 00:00-24:00
}
).B.A. Les commandes
Les commandes de Nagios sont dfinies dans plusieurs fichiers mais utilisent
exactement la mme syntaxe. Chaque fichier contenant des commandes
correspond un type bien dfini.
Les commandes de contrles de services sont dtailles dans le fichier
"checkcommands.cfg". Elles permettent Nagios de lancer des vrifications,
ou bien de lancer des scripts personnaliss.
Les commandes de notifications contenues dans "misccommands.cfg"
permettent d'envoyer les notifications. Ce point a dj t abord dans les
notifications de Nagios.
La syntaxe de la dfinition d'une commande est la suivante:
define command{
command_name nom_de_la_commande
Command_line ligne_de_commande
}
Les commandes standard utilises dans Nagios sont dfinies un autre endroit
"/etc/nagios-plugins/config/". Le dtail de ces commandes se trouve dans les
annexes (Annexe 15) ainsi que celles que nous avons crites (Annexe 16).
).D. Personna&isation de &a carte d*tat du rseau
Dans l'interface Web, la personnalisation des icnes affiches sur la carte des
statuts du rseau est possible. Par dfaut, Nagios utilise des points
dinterrogation. Ces images sont visibles plusieurs endroits de linterface
Web. On les retrouve dans le dtail des services et des htes superviss. De
manire gnrale, de simples images GIF suffisent, mais les images utilises
pour dessiner la carte des statuts du rseau sont obligatoirement des images
GD2.
GD2 est un format de fichier provenant de la librairie GD qui est souvent
utilise pour la cration dynamique d'images par des programmeurs
notamment pour gnrer des diagrammes et des graphes. GD est une librairie
Open Source crite en langage C. Cette librairie cre entre autre des images
d'extension PNG, JPEG et GIF. Cette librairie est tlcharge sur le site
"http://www.boutell.com/gd/".
Cette librairie est compose de plusieurs utilitaires. Dans le cadre de notre
travail, nous utilisons l'utilitaire nomm "pngtogd2" qui transforme des images
PNG en image GD2.
Voici le code taper dans une fentre de commande DOS de Windows.
pngtogd, i%age)png i%age)gd, /0 *
Le premier paramtre est lappel lutilitaire "pngtogd2", vient ensuite le nom
de limage PNG transformer et le nom de limage transforme en GD2. Le
quatrime paramtre est la taille des morceaux de limage, aussi appel
"chunk size". Cette taille est un nombre de 8 chiffres indiquant la taille des
morceaux de l'image. Cest une nouveaut par rapport lancienne version de
la librairie GD. Le nouveau format, GD2, emploie la bibliothque de
compression ZLIB pour comprimer l'image en morceaux, un peu comme le
principe des images GIF. Ce format supporte galement un bon nombre de
versions, ce qui le rend plus supportable que le format prcdent.
Il est intressant de noter que le changement de la "chunk size" na aucune
incidence sur la taille de limage, ce qui ne sera pas le cas du dernier
paramtre. En effet, celui-ci prcise si lon souhaite une image brute ("raw")
ou compresse.
Ci-dessous, voici le rsultat de la procdure tape dans la commande DOS de
Windows.
Une fois les images GIF et GD2 prtes, nous les copions dans le dossier
"/usr/share/nagios/htdocs/images/logos". A ce stade, rien n'est encore fait.
Dans Nagios, nous associons chaque machine une image. Pour cela, nous
ditons le fichier "hostextinfo.cfg".
define hostextinfo{
host_name hostname
icon_image Serv-Norm.gif
icon_image_alt Serveur
statusmap_image Serv-Norm.gd2
register 1
}
Dans celui-ci, nous retrouvons le nom de la machine qui est dfini
pralablement dans le fichier "hosts.cfg". Nous associons galement cette
machine une image GIF pour les diffrentes pages du site Web et une image
GD2 pour la carte de statut du rseau.
Aprs l'dition du fichier "hostextinfo.cfg" et la copie des images sur le serveur
Web, voici le schma que l'utilisateur aperoit sur l'interface Web de Nagios.
).13. Documentation
Pour faciliter l'installation et la configuration des logiciels et des machines chez
les clients d'EASI, une srie de documents permet aux employs d'EASI de
suivre une procdure bien prcise. De cette manire, les installations et les
configurations restent standard et nimporte quel employ de EASI peut
intervenir sur ce quun autre a fait. On peut citer par exemple les rpertoires
dinstallation utiliss ou les logiciels choisis pour offrir un service.
De la mme manire, il est intressant de disposer dune documentation
relative linstallation de Nagios, ce qui permet nimporte qui dinstaller
aisment ce programme. Bass sur la documentation de EASI, au niveau de
larchitecture et du design, les documents que nous avons rdigs vont
permettre de configurer une machine Linux ou Windows afin de la superviser.
Ils sont accompagns de captures dcran et de morceaux de code afin de les
rendre plus conviviaux et faciles dutilisation.
Voici la liste des documents que nous avons crs, ils se situent tous dans les
annexes (Annexe 18):
o Surveillance d'une machine Linux (Intel)
o Surveillance d'une machine Windows (Intel)
,. D"&oiement de Nagios
Aprs avoir effectu le dveloppement de Nagios en analysant le projet
raliser, en dveloppant nos propres "plugins", en scurisant les transferts
dinformations entre le serveur Nagios Local et le serveur Nagios Central et
aprs avoir cr un mode multi-utilisateurs avec une authentification via un
annuaire LDAP, il faut maintenant appliquer le projet linfrastructure
informatique des clients de EASI.
Nous analysons dabord le rseau existant du client pour mieux cerner les
besoins en matire de supervision. Ensuite, nous rflchissons la mise en
place de larchitecture pour superviser efficacement le rseau informatique.
Nous dfinissons ensuite les composants rseau superviser et expliquons
comment mettre en place Nagios dans ce rseau informatique.
Nous commenons par superviser l'infrastructure informatique de EASI. Cette
phase nous sert de test avant que EASI ne prenne la dcision de l'tendre
l'entiret de ses clients.
,.1. na&yse du rseau existant
Nous commenons donc par analyser le rseau informatique de EASI. Il existe
au sein de ce rseau de nombreux serveurs tels que des serveurs Web, DHCP,
DNS mais aussi des serveurs de mails et dimpression. Presque tous ces
serveurs se situent sur le site de EASI Zaventem. Sur le site du
Luxembourg, deux serveurs sont superviser en plus du pare-feu. Voici la
description des serveurs plus spcifiques galement utiliss chez EASI.
,.1.1. Rseau interne
Trois serveurs possdent un systme dexploitation diffrent de Windows et de
Linux et dont le nom est OS/400. Ces trois serveurs sont placs sur lAS/400
de EASI. Les lettres S sont l'acronyme d'pplication System, une machine
qu'IBM a lance dans les annes 1980. Cette gamme d'ordinateurs existe
toujours chez IBM sous le nom de iSeries.
Ci-aprs se trouve schmatis le rseau de EASI avec les trois sites
Zaventem, Lige et au Luxembourg ainsi que les composants les plus
importants dans chaque site. Le rle de ces serveurs est dfini dans les
annexes (Annexe 12).
,.1.2. Rseau DME
Tout dabord, le serveur "pass-thru" situ sur le rseau DME (DeMilitarized
Eone), un sous-rseau situ entre le rseau local et l'extrieur (Internet
gnralement), contrl par un pare-feu et accessible partir de l'extrieur du
rseau. Ce serveur a pour fonction de filtrer les connexions Lotus
Notes/Domino au rseau de EASI sans devoir crer de tunnels +PN (+irtual
Private Network), c'est--dire une connexion scurise entre plusieurs rseaux
informatiques distants. Il autorise ou refuse les connexions entrantes suivant
des paramtres complexes comme la machine source, l'utilisateur, . Pour
qu'une connexion initie par le client, c'est--dire une machine extrieure, soit
accepte vers le serveur interne EASI, celui-ci s'authentifie auprs du
serveur "pass-thru". Celui-ci interroge le serveur en question pour vrifier que
le client qui initialise la connexion ait bien accs via le "pass-thru". On a donc
un mcanisme de double scurit. Si un client souhaite entrer dans le rseau,
il doit non seulement se faire identifier par le serveur "pass-thru", mais il doit
galement s'authentifier par le serveur "destination" en passant par le "pass-
thru".
Exemple, si un consultant lextrieur souhaite se connecter au serveur
Domino04 sur le rseau de EASI, il passe par le serveur "pass-thru" qui est sur
Domino06 et qui lui donne une premire autorisation. Ensuite, ce serveur le
redirige vers Domino04 qui son tour, vrifie que cette personne est bien
autorise se connecter partir de Domino06.
Pour combattre le phnomne des courriers non sollicits mieux connus sous le
nom de "spam", EASI utilise le logiciel Spam Assassin, une solution anti-spam
gratuite qui reoit le mail et vrifie sil s'agit de spam. Concrtement, aprs le
passage du mail au travers du pare-feu de EASI Zaventem (FWzaventem), il
est directement trait par Spam Assassin qui dtermine si celui-ci est un spam.
Le cas chant, le mail est marqu au niveau du sujet comme tant un mail
non sollicit. Il est ensuite transmis au serveur de messagerie Domino04.
,.1.!. +PN et "are?.eux
Le pare-feu, par dfinition, permet le passage slectif des flux d'information
entre Internet et le rseau local. Les trois sites de EASI Lige, au
Luxembourg et bien sr Zaventem possdent chacun leur propre pare-feu.
L'interface vers Internet de chacun des trois pare-feux donne accs un canal
scuris de type VPN qui permet le passage dinformations entre les sites
distants. Ce canal relie les diffrents rseaux locaux de EASI en un grand
rseau de type LN (Local rea Network) tout fait scuris.
,.1.). Serveurs 7e-
Les serveurs Web sont diffrents des serveurs dans le sens o ils ne se
trouvent pas sur le site de EASI. En effet, pour des raisons de scurit et de
place, ceux-ci ont t placs dans une socit spcialise Interxion. Cette
socit gre lalimentation permanente et le suivi de ces machines ainsi que
lenvironnement dans lequel elles vivent (la temprature par exemple).
Le rseau dInterxion, sur lequel sont placs les serveurs Web de EASI, est
reprsent ci-dessous. On voit clairement que les trois Webservers
(Webserver01, Webserver02 et Webserver03) sont installs sur le premier
serveur (easiweb.easi.be).
,.2. rc2itecture @ mettre en "&ace
La premire tape est de dfinir l'emplacement du serveur Nagios. Le serveur
doit avoir accs un maximum de composants rseau mais doit galement
avoir accs Internet pour communiquer avec le serveur Nagios Central.
Nous devons galement changer la configuration du pare-feu, le serveur
Nagios Local doit pouvoir se connecter en SSH au serveur Central. Nous
devons donc ouvrir le pare-feu en sortie sur le port 22. Nous devons aussi
ouvrir le port 5667 en sortie pour que les notifications puissent tre envoyes
au serveur Nagios Central. Nous devons aussi ouvrir les ports spcifiques en
cas de vrifications externes au rseau.
Mais chez EASI, ce scnario n'est pas exact car le serveur Nagios Central est
plac, pendant la priode de test, sur le rseau DMZ de la socit. Nous
devons configurer le pare-feu diffremment du cas gnral. En ralit, lorsque
le serveur Nagios Local se connecte au serveur Central, il ne passe pas par
Internet mais passe juste par le pare-feu. Nous configurons donc le pare-feu
en sortie vers la DMZ en ouvrant les ports 22 (SSH) et 5667 (NSCA) pour que
la connexion entre les deux serveurs se fasse bien. Mais nous ouvrons
galement les ports 7 (ICMP) et 1352 (Domino) pour superviser le serveur
dj prsent sur ce rseau. En entre, nous interdisons videmment toutes les
connexions pour prserver la scurit du rseau interne de EASI.
Nous en profitons galement pour paramtrer le serveur Nagios Central et le
pare-feu. Nous fixons d'abord l'adresse IP du serveur sur le "range" (tendue
des adresses) du rseau DMZ. Pour le pare-feu, nous autorisons les ports en
sortie vers Internet:
o 80 pour vrifier les serveurs Web extrieurs la socit et ceux
placs chez Interxion
o 7 (ICMP) pour vrifier la connexion rseau
o 389 pour vrifier les annuaires LDAP mais galement pour
authentifier un utilisateur sur le serveur Nagios
o 25 pour vrifier les serveurs de mails SMTP. Nous en avons besoin
car le Nagios Central envoie les mails en cas de problmes
o 1494 pour vrifier le bon fonctionnement d'un serveur Citrix
o 1352 pour vrifier que le serveur Domino fonctionne correctement
Par contre, en entre, nous ouvrons le port 80 pour que les utilisateurs
puissent se connecter l'interface Web de Nagios, le port 22 pour les
transferts de fichiers entre les serveurs Locaux et le serveur Central et le port
5667 pour que le serveur Nagios Central reoive toutes les notifications.
Une fois le serveur Nagios Local install avec Debian et Nagios, nous lui
attribuons une adresse IP fixe faisant partie du sous-rseau de la socit. Pour
ce faire, nous ditons le fichier "/etc/network/interfaces" et nous ajoutons les
informations suivantes:
auto eth0
iface eth0 inet static
address xxx.xxx.xxx.xxx
netmask xxx.xxx.xxx.xxx
gateway xxx.xxx.xxx.xxx
Sur les stations Linux sur lesquelles le serveur Nagios effectue des tests, nous
crons un utilisateur qui peut tablir des connexions SSH sur le port 22 et qui
a le droit d'excuter des commandes sur l'hte distant. Nous copions les
"plugins" Nagios sur la machine superviser et copions galement la cl
publique pour l'authentification du serveur Nagios lors des vrifications.
Sur les serveurs Windows qui sont superviss par Nagios, nous installons
l'utilitaire NSClient qui permet d'interroger cette machine distance depuis le
serveur Nagios Local.
Pour terminer, nous installons les diffrents "plugins" et scripts que nous avons
dvelopps nous-mmes sur le serveur Local. Une fois toutes ces tapes
accomplies, nous crons les fichiers de configuration du nouveau serveur sur le
serveur Nagios Central. Le serveur Local tlcharge ces fichiers de
configuration et ainsi commence sa tche de supervision. Nous modifions bien
entendu les fichiers de configuration du serveur Nagios Central pour que celui-
ci affiche les rsultats qu'il recevra du Nagios Local.
Tout ce qui est expliqu dans ce point est dtaill dans les procdures que
nous avons cres pour faciliter l'installation des futurs serveurs par les
employs de EASI. Ces procdures sont listes dans le point 4.10 mais se
trouvent dans les annexes.
,.!. 1om"osants su"erviss
L'installation tant maintenant termine, nous devons savoir ce que Nagios
doit superviser sur le rseau de la socit. C'est au client de savoir quels sont
les services ou htes qui doivent tre superviss. Il va donc complter la fiche
client que nous avons cre avec l'aide d'un technicien de chez EASI. Celui-ci
le conseillera dans ses choix. Le modle de cette fiche client se trouve dans
les annexes (Annexe 10) et la fiche complte par EASI se trouve galement
dans les annexes (Annexe 11)
Une fois cette fiche complte, nous prparons un document listant les
diffrents composants rseau avec les services superviser sur chacun d'eux
(Annexe 12). Ce nouveau document permet au client de vrifier si toutes ses
exigences sont bien respectes et facilite aussi les modifications que nous
devons faire dans les fichiers de configuration de Nagios.
Quand cette liste est approuve par le client, nous modifions les fichiers de
configuration de Nagios sur le serveur Nagios Central. Ces diffrents fichiers
de configuration se trouvent dans les annexes (Annexe 14).
,.). Mise en "&ace de Nagios
Pour chaque vrification effectue par Nagios, il y un "plugin" qui se cache
derrire. Dans ce chapitre, nous dtaillons les "plugins" les plus importants,
notamment ceux que nous avons utiliss pour superviser le rseau
informatique de EASI. La vrification consiste parfois vrifier ltat dun port
sur lequel tourne un service ou un protocole ou consiste effectuer une
commande, par exemple vrifier l'espace du disque dur utilis. Nous
prsentons brivement ces "plugins" et nous dcrivons la syntaxe de la
commande avec ses principaux arguments utiliss. Le dtail des commandes
pour lensemble des "plugins" standard se trouve en annexe (Annexe 15).
o 12arge moyenne du systFme #Standard(
Le "plugin check_load" teste la charge moyenne du systme sous
Linux.
Syntaxe:
check_load -w WLOAD1, WLOAD5, WLOAD15 -c CLOAD1, CLOAD5,
CLOAD15
Ce "plugin" contrle la charge moyenne du CPU toutes les 1, 5 et 15
minutes. L'tat est CRITICAL si les moyennes dpassent les seuils
<cload1>, <cload5> ou <cload15>. L'tat est WARNING si les
charges moyennes dpassent les seuils <wload1>, <wload5> ou
<wload15>.
o Es"ace dis5ue #Standard(
Le "plugin check_disk" vrifie le pourcentage d'espace disque utilis
sur un systme Linux.
Syntaxe:
check_disk -w limit -c limit [-p path] [-t timeout]
Si le taux d'espace occup dpasse le seuil fix par <-c>, l'tat est
CRITICAL. S'il dpasse le seuil <-w>, l'tat sera WARNING.
L'argument <-p> spcifie le chemin de la partition vrifier (ex:
/dev/hda1). L'tat critique est renvoy si le "plugin" ne peut
contacter l'hte avant le dlai prcis par largument <-t> (10
secondes par dfaut).
o Gti&isation de &a mmoire #Standard(
Le "plugin check_vsz" vrifie l'utilisation mmoire de chaque
programme et lance des alertes en fonction de limites dfinies.
Syntaxe:
check_vsz -w <wsize> -c <csize> [-C command]
Ce "plugin" contrle les processus et vrifie que la taille totale en
octets ne dpasse pas les seuils WARNING ou CRITICAL donns par
les arguments <-w> et <-c>. Loption <-c> prcise quel processus
nous voulons vrifier.
o 1onnexion au rseau #Rseau(
Le "plugin check_ping" vrifie la connexion au rseau. Cest le plus
employ, il utilise la commande "PING" pour vrifier les statistiques
de connexion un hte distant.
Syntaxe:
check_ping -H <host_address> -w <wrta>,<wpl>%% -c
<crta>,<cpl>%% [-p packets] [-t timeout]
Les arguments <wrta> et <crta> sont les seuils d'alerte WARNING et
CRITICAL pour la dure moyenne du trajet (en millisecondes). De
mme, les arguments <wpl> et <cpl> sont les seuils d'alerte pour le
taux de perte de paquets. L'argument optionnel <-p> contrle le
nombre de paquets ICMP ECHO qui sont envoys l'hte spcifi (5
par dfaut).
o DNS #Protoco&es %1PHIP I GDP(
Le "plugin check_dns" vrifie le bon fonctionnement dun serveur
DNS, il utilise en fait le programme NSLOOKUP pour obtenir l'adresse
IP d'un hte/domaine donn. Chez EASI, cest le serveur "Danube"
qui se charge du service DNS.
Syntaxe:
check_dns -H host [-s server] [-a expected_address] [-t timeout]
Le "plugin" contrle la rsolution du nom de domaine spcifi par
l'option <-H>. Si on ne veut pas utiliser les serveurs DNS par
dfaut, il est possible d'en prciser un l'aide du second argument
<-s>. Largument <-a> spcifie une adresse IP facultative que le
serveur DNS doit retourner. L'tat critique est renvoy si le "plugin"
ne peut contacter l'hte avant le dlai prcis par largument <-t>
(10 secondes par dfaut).
o 6%P #Protoco&es %1PHIP I GDP(
Le "plugin check_ftp" teste la connexion FTP avec l'hte spcifi.
Syntaxe:
check_ftp -H host -p port [-w warning] [-c critical] [-s send] [-e
expect] [-t timeout]
Le "plugin" contrle la connexion FTP avec lhte spcifi par l'option
<-H>. L'argument <-p> prcise le port (par dfaut 21). L'tat de
retour est WARNING si l'hte ne peut tre contact en moins de <-
w> secondes, il est CRITICAL si l'hte ne peut tre contact avant <-
c> secondes. Si lon souhaite envoyer une requte sous forme de
chane de caractres, il faut utiliser largument <-s>. Le "plugin"
vrifie galement si la rponse du serveur contient une chane
spcifie par l'argument <-e>. L'tat critique est aussi renvoy si le
"plugin" ne peut contacter l'hte avant le dlai prcis par largument
<-t> (10 secondes par dfaut).
o 4%%P #Protoco&es %1PHIP I GDP(
Le "plugin check_http" teste le service HTTP sur l'hte spcifi mais
teste aussi HTTPS (HTTP Secure), suit les redirections, recherche des
chanes de caractres et des expressions rgulires, vrifie le temps
de connexion et renvoie la dure d'expiration d'un certificat.
Syntaxe:
check_http (-H <vhost> | -I <IP_address>) [-u <uri>] [-p <port>]
[-w <warning>] [-c <critical>] [-t <timeout>] [-a auth] [-e
<expect>] [-s string]
Ce "plugin" vrifie s'il peut se connecter soit l'hte virtuel spcifi
par largument <-H>, soit sur lhte spcifi par son IP ou son nom
avec largument <-I>. Si aucun URL n'est prcis par largument
<-u>, le "plugin" cherche le document racine. Si on prcise un
numro de port avec largument <-p>, il crase celui par dfaut
(80). L'tat de retour est WARNING si l'hte ne peut tre contact
en moins de <-w> secondes, il est CRITICAL si l'hte ne peut tre
contact avant que <-c> secondes ne se soient coules. L'tat
critique est aussi renvoy si le "plugin" ne peut contacter l'hte avant
le dlai prcis par l'option timeout (10 secondes par dfaut). Il est
galement possible de rechercher une chane de caractres dans le
contenu de la page grce largument <-s>.
o P/P! #Protoco&es %1PHIP I GDP(
Le "plugin check_pop" est utilis pour tester la connexion POP3 avec
un hte spcifi.
Syntaxe:
check_pop -H host -p port [-w warning] [-c critical] [-s send] [-e
expect] [-t timeout]
Le "plugin" contrle la connexion POP3 avec lhte spcifi par
l'option <-H>. Si un numro de port est prcis avec largument <-
p>, il crase celui par dfaut (110). L'tat de retour est WARNING si
l'hte ne peut tre contact en moins de <-w> secondes, il est
CRITICAL si l'hte ne peut tre contact avant que <-c> secondes ne
se soient coules. Il est possible denvoyer une requte sous forme
de chane de caractres grce largument <-s>. Le "plugin"
cherche en fait la chane spcifie par l'argument <-e> dans la
premire ligne de la rponse de l'hte ("+OK" par dfaut). L'tat
critique est aussi renvoy si le "plugin" ne peut contacter l'hte avant
le dlai prcis par l'option <-t> (10 secondes par dfaut).
o SM%P #Protoco&es %1PHIP I GDP(
Le "plugin check_smtp" teste le service SM%P (Simple Mail %ransfer
Protocol) sur l'hte spcifi. Nous lutilisons pour superviser
"Danube" et "Domino02"
Syntaxe:
check_smtp -H host [-e expect] [-p port] [-f from_addr] [-w
warning] [-c critical] [-t timeout]
Ce "plugin" essaie de se connecter au port SNMP de l'hte spcifi
par largument <-H>. Il cherche la chane spcifie par l'argument
<-e> dans la premire ligne de la rponse de l'hte ("220" par
dfaut). Si un numro de port sur la ligne de commande est prcis,
il crase celui par dfaut (25). Si une adresse doit tre prcise dans
la commande MAIL, il faut utiliser largument <-f>. L'tat de retour
est WARNING si l'hte ne peut tre contact en moins de <-w>
secondes, il est CRITICAL si l'hte ne peut tre contact avant que
<-c> secondes ne se soient coules. L'tat critique est aussi
renvoy si le "plugin" ne peut contacter l'hte avant le dlai prcis
par l'option timeout (10 secondes par dfaut).
o SS4 #Protoco&es %1PHIP I GDP(
Le "plugin check_ssh" vrifie si l'hte accepte les connexions SSH.
Syntaxe:
check_ssh <host> [-p port] [-t timeout]
Ce "plugin" essaie de se connecter au serveur spcifi par loption
<host> sur le port spcifi par l'argument <-p>. S'il contacte le
serveur avec succs, il retourne une rponse valide. L'tat CRITICAL
est renvoy si le "plugin" ne peut contacter l'hte avant le dlai
prcis par l'option timeout (10 secondes par dfaut).
o Services
Le "plugins check_tcp" vrifie s'il peut se connecter un hte et sur
un certain port.
Syntaxe:
check_tcp -H <host> -p <port>
Gnralement, la supervision des services consiste surveiller
ltat des ports quils utilisent sur le rseau en utilisant ce "plugin".
Par exemple, pour tester le service Domino, la russite de la
connexion sur le port 1352 permet de dire que le service Domino
fonctionne correctement. C'est ce mme principe qui est utilis pour
vrifier la plupart des services, citons les plus connus: Citrix (port
1494), Ms-SQL (port 1433), Sametime (port 1533), Spam Assassin
(port 25), ...
o 1ommande @ distance via SS4 #Services s"ciaux(
Le "plugin check_by_ssh" permet l'excution d'un "plugin" sur un
hte distant l'aide de SSH.
Syntaxe:
check_by_ssh -H <host> -C <command> [-p port] [-t timeout] [-i
identity] [-l user] [-n name]
Il faut tout dabord spcifier lhte distant en utilisant largument
<-H>. Ensuite, la commande, sous forme de chane de caractres,
doit tre envoye avec largument <-C>. Si un numro de port sur
la ligne de commande est prcis, il crase celui par dfaut (22).
L'tat CRITICAL est renvoy si le "plugin" ne peut contacter l'hte
avant le dlai prcis par l'option timeout (10 secondes par dfaut).
En option, lidentit d'une cl autorise peut tre prcise par
largument <-i>, le nom d'utilisateur SSH sur lhte distant par
largument <-l> et le nom de lhte dans la configuration de Nagios
par l'argument <-n>.
<. 1onc&usion
La supervision est un domaine trs intressant car elle permet une vue assez
tendue des rseaux informatiques, domaine dans lequel nous souhaitions
faire notre Travail de Fin dEtudes. Le dbut a t ardu car linstallation de
Nagios a demand beaucoup de temps et de patience. Pourtant, la longue,
son utilisation sest avre beaucoup plus comprhensible.
Quand nous nous trouvions face un problme, nous nous sommes rendu
compte qu'il n'existait pas toujours un document ou un livre qui expliquait
exactement notre problme, mais que nous devions prendre toutes des petites
parties venant d'endroits diffrents sur Internet. Nous avons donc pass
beaucoup de temps rechercher des informations sur des sujets bien prcis
comme sur le LDAP, le mode multi-utilisateurs, le SNMP, .
Nous avons eu quelques difficults pour finaliser notre projet. D'abord le
rseau que nous avons supervis, cest--dire celui de EASI, a fortement vari
tout au long de notre Travail cause de nombreuses migrations de serveurs et
d'infrastructures. Ensuite, nous nous somme rendu compte que suivre un
cahier des charges n'tait pas chose aise, d'autant plus lorsque des petites
modifications apparaissent durant le dveloppement de celui-ci. Cela na
pourtant pas eu dinfluence ngative sur notre travail.
Lexprience la plus enrichissante est certainement celle du monde Linux. En
effet, Nagios tant install sur des machines Linux, nous avons t contraints
dapprendre plus en profondeur ce systme dexploitation peu connu jusqu
maintenant. Que ce soit au niveau des commandes ou des utilitaires propres
Linux, tel que lditeur de texte, cette dcouverte sest avre trs
intressante.
Les langages de programmation ont galement t approfondis tels que Perl et
C. En effet, lors de lanalyse du mode multi-utilisateurs, nous avons analys
un fichier CGI dont la source est crite en C. Ayant eu des problmes lors de
la compilation de ce dernier, nous avons prfr crire un fichier en Perl. Mais
le plus enrichissant est certainement lapprentissage du langage Shell que nous
avons appris pour crire des "plugins". Ce langage est en fait un interprteur
de commandes, la partie du systme dexploitation utilise celles-ci comme
interface avec l'utilisateur.
En ce qui concerne le serveur AS/400, le temps nous a manqu pour le
superviser. Mais daprs ce que nous avons vu sur Internet, des "plugins"
permettant de rcolter des informations sur ces machines existent et leurs
installations ressemblent fortement celle du module NSClient pour Windows.
Des supervisions concernant le rseau ont quand mme t ralises car elles
sont indpendantes du systme dexploitation utilis.
Lannuaire LDAP a aussi t une grande dcouverte pour nous. Ayant d le
comprendre avec le protocole du mme nom dans le cadre de lauthentification
linterface Web de Nagios, nous avons beaucoup recherch avant de pouvoir
comprendre un minimum. Pourtant, la consultation dun annuaire se fait par
des requtes, tout comme on interroge une base de donnes SQL. Mais
lutilisation de ces requtes requiert un minium de connaissances sur ces
annuaires.
Lors de la personnalisation de la carte de statut du rseau sur l'interface Web,
nous avons dcouvert qu'il existait des fichiers images interprts et modifis
directement par le Serveur Web. Cela permet entre autre d'y introduire du
texte ou de les mettre dans un graphique existant. Ces images portent le nom
de GD2. Hormis leurs avantages de prsentation, celles-ci consomment trs
peu de ressource CPU lors de leur gnration.
Tout au long de notre travail, nous nous sommes intresss aux multiples
facettes d'un projet. Nous avons d'abord analys le projet en lui-mme mais
aussi les dpendances qu'il impliquait. Nous avons programm sur base de
notre tude et des conseils que nous avons reus des membres de notre
dpartement. Pour finir, nous avons mis en place notre architecture tout en
nous adaptant ce qui existait dj. Nous avons mme propos des solutions
de modification de l'infrastructure informatique. Citons par exemple
l'installation de programmes sur des serveurs de production.
Produire un Travail de Fin dEtudes qui servira est motivant, car cela nous
plonge dans des conditions optimales de travail, surtout au niveau de
lefficacit, puisquil faut invitablement aboutir un rsultat.
Il y a une grande diffrence entre ce que l'on pense, ce que l'on explique et ce
que l'on rdige. Certaines ides taient claires dans nos ttes mais quand est
venu le moment de les expliquer notre promoteur o a un collgue, il tait
plus difficile de s'exprimer. Nous avons donc appris communiquer avec les
bons termes et surtout ne pas avoir peur de tenir ces personnes au courant.
A terme, le mode multi-utilisateurs avec authentification par annuaire LDAP sur
linterface Web de Nagios permet EASI de dployer cette application
lensemble de ses clients. Il leur suffira tout dabord de remplir leur fiche client
pour dterminer ce quils veulent que EASI supervise dans leur rseau.
Ensuite, un membre du personnel pourra installer le serveur Nagios Local et le
configurer grce aux feuilles de documentation.
Dans un futur proche, il serait intressant de superviser les serveurs AS/400
car de nos jours, beaucoup d'entreprises utilisent ces machines. Il serait
galement fort utile d'tudier plus en profondeur le protocole SNMP pour
superviser des imprimantes et mme des programmes gnrant des alertes
SNMP.
A. Bi-&iogra"2ie
PILLOU Jean-Franois, Le protocole SNMP, 2005
http://www.commentcamarche.net/internet/snmp.php3
CALECA Christian, SNMP, 20/09/2003
http://christian.caleca.free.fr/snmp
FONTAINE Arnaud, ANDESI - Another Debian Site, 30/08/2004
http://www.andesi.org
JAMOT Marc, Apt, dpkg et paquets Debian,
http://lea-linux.org/software/soft_gere/apt_dpkg.html
Apt-get,
http://knoppix-fr.org/howto/aptget
PILLOU Jean-Franois, Lditeur de texte VI, 2005
http://www.commentcamarche.net/tutlinux/linvi.php3
GALSTAD Ethan, The Official Nagios Website
http://www.nagios.org
ANGELINI Pierre-Antoine, MOREAU Johan, VANGUERS Christian,
Documentation franaise de Nagios Version 1.0, 2003
http://sourceforge.net/project/showfiles.php?group_id=71182
CHAVERON Nicolas, Nagios et la supervision, dcembre 2004
http://www-igm.univ-mlv.fr/~dr/XPOSE2004/nchaveron/Supervision.html
GAUCHER Arnaud et THOMAS Yohann, Nagios: un outil de monitoring rseaux
pour Linux, 5/10/2004
http://docs.guill.net/article.php3?id_article=2
LE MONNIER Olivier, Traduction de la documentation en ligne de Postfix, 2001
http://linux.crdp.ac-caen.fr/Docs/Postfix
MILLE-MATHIAS Baptiste, Mise en place rapide d'un serveur SMTP Postfix,
http://baptiste.mille-mathias.info/files/Postfix_SASL/postfix_sasl_debian.pdf
BLACK Richard, Network File Copy using SSH, 9/20/1999
http://www.cpqlinux.com/sshcopy.html
HURST Mike, Nagios Network Monitoring Software, 20/07/2004
https://www.freebsd.uwaterloo.ca/twiki/bin/view/Freebsd/NagiosInstallation
PROCACCIA Jehan, Nagios par l'exemple, 15/04/2005
http://www.int-evry.fr/mci/user/procacci/Doc/nagios/nagios.html#htoc21
Nagios Plugin Development, 03/02/2005
http://sourceforge.net/project/showfiles.php?group_id=29880
HARRIS Kate, Configuring nagios commands, 1999
http://www.totkat.org/pages/nconf_commands.shtml
DUSART Xavier, Plugins de NetSaint
http://xavier.dusart.free.fr/netsaint/documentation-0.0.6/oldplugins.html
BOUTELL Thomas, GD Library
http://www.boutell.com/gd
Nagios Exchange: Nagios Plugins and Add Ons Exchange
http://www.nagiosexchange.org
MIRTAIN Laurent, LDAP, octobre 1999
http://www-sop.inria.fr/semir/personnel/Laurent.Mirtain/ldap-livre.html
PILLOU Jean-Franois et MAUDET Michel, Le protocole LDAP
http://www.commentcamarche.net/ldap/ldapinfo.php3
SUN Microsystems, The LDAP Search Tool
http://docs.sun.com/source/816-6400-10/lsearch.html
CARRIGAN Dave, auth_ldap
http://www.rudedog.org/auth_ldap

Supervision Centralisee Infrastructures Distantes Reseaux Gestion Alarmes Notification Alertes

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

Supervision Centralisee Infrastructures Distantes Reseaux Gestion Alarmes Notification Alertes

Transféré par

Droits d'auteur :

Formats disponibles

HAUTE ECOLE PAUL-HENRI SPAAK

INSTITUT SUPERIEUR INDUSTRIEL DE BRUXELLES

Vous aimerez peut-être aussi