Supervision Centralisee Infrastructures Distantes Reseaux Gestion Alarmes Notification Alertes

HAUTE ECOLE PAUL-HENRI SPAAK

INSTITUT SUPERIEUR INDUSTRIEL DE BRUXELLESEnseignementsuprieurdetypelong deniveauuniversitaire

SUPERVISION CENTRALISEED'INFRASTRUCTURES DISTANTES

EN RESEAUX AVEC GESTIONDES ALARMES ET NOTIFICATION

DES ALERTES

Travaildefind'tudesprsentpar

CHUNG CHOONG LON FranoisLOUSSE Jonathan

envuedel'obtentiondutitreetdugrade

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 DEBIAN

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.3. Aptitude (Advanced Packaging Tool APT)

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.4. L'diteur de texte VI

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.5. La supervision en bref

1.5.1. Description

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 logo 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 logicielso 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.5.2. Objectifs

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 prvention des pannesLa 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 reprise sur incidentEn 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. Cahier des charges

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 portables IBM ThinkPad R30 (PIII)Systme dexploitation : Windows 2000Description : Stations de testsLes premiers essais sont raliss sur ces portables qui reprsentent des serveurs superviser.

o 1 portable IBM ThinkPad A21M (PIII)Systme dexploitation : DebianDescription : serveur Nagios LocalCest sur ce portable que nous avons install et configur Nagios et que nous ralisons les premires vrifications dalarmes et de notifications.

o 1 PC fixe IBM Netfinity 3000 (PII)Systme dexploitation : DebianDescription : serveur Nagios CentralPossdant 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.


3. Nagios

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


3.2. Historique

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 NetSainto Mai 2002 : premire version de Nagioso 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.


3.3. Fonctionnalits

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 tempratureo 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 logo 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 Webo Temps d'arrt programms pour supprimer les alertes de serveurs et

de services pendant les priodes de pannes prvues


3.4. Architecture

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 Equipementso Rseaux/Protocoleso Applicationso Serviceso Clients

Lensemble des "plugins" standard, tris par catgorie et dtaills se trouve dans les annexes (Annexe 1).

3.4.1. Interface Web

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 Tactical Overview: 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 Detail: 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 Host Detail: vue dtaille de tous les htes superviss sur le rseau avec leur tat et l'heure de leur dernire vrification

o Status Overview: 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 Summary: aperu de ltat des services et des htes tris par groupes

o Status Grid: une vue de ltat des services ainsi que leurs dnominations rassembls par htes et tris par groupes

o Status Map: une cartographie du rseau supervis avec l'tat des diffrents htes

o Service Problems: une vue trs utile car elle visualise tous les problmes sur des services existant sur le rseau

o Host Problems: une liste des htes ayant un problme avec les diffrentes informations

o Process Info: une feuille technique de Nagios, on y voit l'tat actuel du programme mais galement la possibilit d'y intervenir

o Scheduling Queue: 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 Traffic Grapher), 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 Trends: une vue graphique de l'tat d'un hte ou d'un service dans le temps et des statistiques qui s'y rapportent

o Availability: des statistiques trs compltes sur un hte, un service ou mme un groupe d'htes

o Alert History: un historique des alerteso Alert Histogram: un historique des alertes par hte ou par service

sous forme de graphique

o Alert Summary: le dtail de l'historique de toutes les alerteso Notifications: le dtail de toutes les notifications envoyeso Event Log: le dtail de tous les vnements survenus par jour


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


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

3.4.2.2. Agent NSCA

L'agent NSCA (Nagios Service Check Acceptor) 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.


3.5. Installation

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 Co Un serveur Apacheo Un module CGIo 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.


3.6. Configuration

3.6.1. Serveur Apache

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/

AllowOverride AuthConfig Options ExecCGI Order allow,deny Allow from all

Alias /nagios/ /usr/share/nagios/htdocs/

Options None AllowOverride AuthConfig Order allow,deny Allow from all

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

Options ExecCGI AllowOverride AuthConfig Order Allow,Deny Allow From All AuthName "Nagios Access" AuthType Basic AuthUserFile /etc/nagios/htpasswd.users


require valid-user

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.mzZYqS2Mfrancois:6mU7.mzZYqS2M

Grce ce fichier, seuls les utilisateurs inscrits dans le fichier peuvent sauthentifier et se connecter linterface Web de Nagios.

3.6.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 valeursattribut2 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.cfgNagios 1.3Copyright (c) 1999-2004 Ethan Galstad ([email protected])Last Modified: 10-24-2004License: GPLReading 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: 0Total Errors: 0Things look okay - No serious problems were detected during the pre-flight checkdebian:/#

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


3.6.3. Serveur Postfix

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 = debianalias_maps = hash:/etc/aliasesalias_database = hash:/etc/aliasesmydestination = debian, localhost.localdomain, , localhostrelayhost =mynetworks = 127.0.0.0/8mailbox_command = procmail -a "$EXTENSION"mailbox_size_limit = 0recipient_delimiter = +inet_interfaces = all define type


4. Dveloppement de Nagios

4.1. Analyse du projet

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 Serveurso Serveurs Webo Sites Webo Imprimanteso Firewallso Routeurso 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 standardo Rseauo Protocoles TCP/IP & UDPo Serviceso Mise en place de Nagioso 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 systmeo Ecart de temps avec un serveur de tempso Espace disque (utilisation)o Espace disque (accroissement)o Nombre de processuso Taux d'utilisation de la mmoire SWAPo Tempratureo 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 rseauo Imprimante HP avec carte JetDirecto Port en TCPo Port en UDPo 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 DHCPo DNSo FTPo HTTP (HTTPS)o IMAPo IRCDo LDAPo NNTPo POP3o SMTPo SNMPo SSHo

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 Citrixo Faxo MRTGo MySQLo NSClient


o Oracleo 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 NagServo 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 Breezecomo Excution de "plugins" locauxo Excution d'une commande en utilisant SSHo Onduleur UPSo Prsence d'une chane dans un fichier logo Rseaux Netwareo Serveur de licence Flexlmo Serveur Novello Serveur Radiuso 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


4.2. Dveloppement de "plugins"

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.


4.2.1. Envoi de notifications au Nagios Central

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=nagiosencryption_method=1

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

encryption_method: 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 XORo 2 = DESo 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.

Remarque: 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=5667allowed_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]


-H: option obligatoire car elle prcise l'adresse du serveur NSCA.

-c: paramtre obligatoire car il indique l'emplacement du fichier de configuration pour l'envoi de donnes au serveur.

-to: 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/messagesMay 17 13:59:56 ServNag nagios: EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;EASI-ASEASI;CheckHTTP;0;Connection refused by hostMay 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


4.2.2. Validit des fichiers de configuration

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/nagiosdo="0"for i in *.cfgdo 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 [email protected] ls -l /NagConfig/$1/$i |tr -s ' ' | cut -d ' ' -f "6"` vardistday=`ssh [email protected] ls -l /NagConfig/$1/$i |tr -s ' ' |


cut -d ' ' -f "7"` vardistclock=`ssh [email protected] 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" fidoneif [ $do = "1" ]then /etc/nagios/script/Send-ServNag $1 Check-Config 1 "Fichiers differents sur ServNag" exit 1else /etc/nagios/script/Send-ServNag $1 Check-Config 0 "Fichiers idem sur ServNag" exit 0Fi

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.


4.2.3. Mise jour des fichiers de configuration

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 heuretest=$(date)now=$(date +%d%m%y)now=$now-${test:11:9}cd /etc/nagios/Backupmkdir $now# Copie des fichiers de configuration dans le dossiercp /etc/nagios/*.cfg /etc/nagios/Backup/$now

# Copie des fichiers de configuration depuis le ServNagcd /etc/nagiosfor i in *.cfgdo scp -q [email protected]:/NagConfig/NagEASI/$i /etc/nagios/ ssh [email protected] touch /NagConfig/NagEASI/$idone# Test de la configuration avec envoi d'un rapport/usr/sbin/nagios -v /etc/nagios/nagios.cfg > /etc/nagios/tempscp -q /etc/nagios/temp [email protected]:/NagConfig/NagEASI/rap-$nowtest=$(grep "Total Errors:" /etc/nagios/temp)test=${test:13}# Test d'erreurif [ $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 reloadfi

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.cfgNagios 1.3Copyright (c) 1999-2004 Ethan Galstad ([email protected])Last Modified: 10-24-2004License: GPLReading 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: 0Total Errors: 0Things look okay - No serious problems were detected during the pre-flight checkNagEASI:/#

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.


4.2.4. Vrification de l'accroissement d'un disque

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"ùseP=`grep $1 /var/log/nagios/status.log | grep $2 | cut -d ' ' -f "11" | cut -c2,3ùsesize=`grep $1 /var/log/nagios/status.log | grep $2 | cut -d ' ' -f "9"ìf [ "$useP" != "" ]then echo "$1 - $2 - $totalsize - $usesize - $useP" >> /etc/nagios/script/HDD.logelse echo "Les donnes ne sont pas lisible" exit 3Fi


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 - 75Chung - CheckHDD-C - 19.53 - 9.83 - 50Danube - CheckHDD-C - 3.91 - 2.94 - 75Chung - 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"ì=èxpr $nb - 1ì=è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=`expr $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 fielse echo "Pas assez de valeur" exit 3Fi

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.


4.2.5. Pertinence des notifications

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 = ){ $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;}


4.3. Module NSClient

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 CPUo Lutilisation de lespace disque o Le temps de fonctionnemento 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)


4.4. Scurisation du transfert d'informations

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 Adleman) tandis que la version 2 utilise le cryptage RSA et DSA (Distributed System Architecture). 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 dsaGenerating 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_dsaYour public key has been saved in /root/.ssh/id_dsa.pubThe key fingerprint is:0b:0b:54:f2:75:23:dc:05:10:81:90:95:ba:1f:ca:8b nagios@NagEASIdebian:/#

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/.sshServNag:/# scp root@NagEASI:/root/.ssh/id_dsa.pub /root/.ssh/Password: ********ServNag:/# cat id_dsa.pub >> authorized_keysServNag:/# 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 ServNagLast login: Thu Jun 9 08:46:49 2005 from 172.22.3.75NagEASI:/# _

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 yesPubkeyAuthentication yes


4.5. Mode multi-utilisateurs

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 GCC (GNU Compiler Collection), 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".

francois:6mU7.mzZYqS2M


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

Supervision Centralisee Infrastructures Distantes Reseaux Gestion Alarmes Notification Alertes

Documents

Transcript of Supervision Centralisee Infrastructures Distantes Reseaux Gestion Alarmes Notification Alertes