Vous êtes sur la page 1sur 19

UFR sciences et techniques

2, rue de la Houssinire BP 92208 44322 Nantes Cedex 3

Stage du mois de juin 2005

Promotion : 2004 - 2005 Filire : Master 1 informatique Tuteur : Attiobg Christian

Rapport sur la mise en place dune solution de supervision avec Nagios

ADJIDO Idjiwa

CEntre de Recherche Mthodologique dArchitecture (CERMA) UMR CNRS 1563


EAN - Rue Massenet BP 81931 44319 Nantes cedex 3, France Tuteur entreprise : Thomas LEDUC

Sommaire
1. 2.
2.1. 2.2.

CE QUE NEST PAS CE DOCUMENT _______________________________ 4 OBJECTIFS ____________________________________________________ 4


Cadre et besoins __________________________________________________________________ 4 Cahier des charges ________________________________________________________________ 4

3.
3.1. 3.2. 3.3.

SUPERVISION DE RESEAUX ______________________________________ 5


Dfinition ________________________________________________________________________ 5 Objectif _________________________________________________________________________ 5 Problmatique____________________________________________________________________ 5

4.
4.1. 4.2.

SOLUTIONS EXISTANTES ________________________________________ 6


Les offres diteurs_________________________________________________________________ 6 Les offres libres___________________________________________________________________ 6

5.

SOLUTION SELECTIONNEE : NAGIOS______________________________ 7

5.1. Pourquoi Nagios ?_________________________________________________________________ 7 5.1.1. Cest une solution libre _________________________________________________________ 7 __ 5.1.2. Cest une solution stable qui a fait ses preuves _________________________________________ 7 5.2. Prsentation gnrale ______________________________________________________________ 8 5.2.1. Les fonctionnalits _______________________________________________________________ 8 5.2.2. Le concept _____________________________________________________________________ 8 5.2.3. Le principe de fonctionnement______________________________________________________ 8 5.2.4. Larchitecture___________________________________________________________________ 8 5.3. Les plugins_______________________________________________________________________ 9 5.3.1. Les plugins de base ______________________________________________________________ 9 5.3.2. NRPE, NSCA__________________________________________________________________ 10 5.4. Linstallation ____________________________________________________________________ 10 10 10 10 11 11

5.5. Le mode de dploiement___________________________________________________________ 5.5.1. Dploiement centralis___________________________________________________________ 5.5.2. Dploiement hirarchis _________________________________________________________ 5.5.3. Dploiement distribu ___________________________________________________________ 5.5.4. Dans le cadre du CERMA ________________________________________________________

Mise en place dune solution Nagios. Idjiwa ADJIDO.

5.6. La configuration de base __________________________________________________________ 5.6.1. Dfinition des commandes________________________________________________________ 5.6.2. Dfinition des contacts___________________________________________________________ 5.6.3. Dfinition des stations ___________________________________________________________ 5.6.4. Dfinition des services___________________________________________________________ 5.6.5. Dfinition des plages de fonctionnement pour les diffrents services _______________________

11 11 11 12 12 12

6.

NAGIOS COUPLE A SNMP_______________________________________ 12

Le principe de SNMP _____________________________________________________________ 13 6.1. 6.1.1. Lagent SNMP _________________________________________________________________ 13 6.1.2. Station dadministration__________________________________________________________ 13 6.2. Le protocole SNMP_______________________________________________________________ 13 6.2.1. Commandes du protocole dans sa premire version ____________________________________ 13 6.2.2. Ncessit dune standardisation des informations ______________________________________ 14 6.3. Management Information Base _____________________________________________________ 14 6.3.1. Syntaxe des informations de gestion (SMI) ___________________________________________ 14 6.3.2. Structure de la MIB _____________________________________________________________14 6.4. SNMP et Nagios _________________________________________________________________ 16

7.
7.1. 7.2. 7.3. 7.4.

LUTILISATION DE NAGIOS PAR LE CERMA________________________ 16


Les services monitors ____________________________________________________________ 16 La gnration des fichiers de configurations __________________________________________ 16 Laccs aux informations ___________________________________________________ ______ 17 Affichage des ports _______________________________________________________________ 17

8.
8.1. 8.2. 8.3.

BILAN PERSONNEL ____________________________________________ 18


Difficults rencontres ____________________________________________________________ 18 Comptences utilises _____________________________________________________________ 18 Comptences acquises_____________________________________________________________ 18

9. 10.

CONCLUSION _________________________________________________ 19 ANNEXE ____________________________________________________ 19

Mise en place dune solution Nagios. Idjiwa ADJIDO.

1. Ce que nest pas ce document


Nous prsentons dans ce document le contenu du stage (facultatif) rseau effectu sur une dure de un mois. Il prsente dans son concept et ses lments principaux la solution utilise pour mettre en place une supervision de rseaux complmentaire celle existante dj. Ce document nest donc pas un didacticiel tape par tape pour mettre en place ladite solution ; cest une prsentation de ce quil est conseill de savoir ou davoir lu avant de se lancer dans sa mise en place. Les documentations spcifiques la solution dploye allaient bien trop vite dans les manipulations techniques, nous avons donc souhait ici diffrencier le concept du technique .

2. Objectifs
2.1. Cadre et besoins
Le stage se droule dans un environnement comportant un parc dune centaine de machines et de quelques serveurs. Il existe actuellement un plan de rseau semi dynamique, cr partir dinformations sur les machines stockes dans des bases de donnes et partir de requtes SNMP1, qui permet de dterminer sur quel port se situe telle machine. Ladministrateur ne peut pas dterminer directement do vient le problme lorsquune machine est manquante sur le plan. Est-ce le port qui est dsactiv, est ce la machine qui est teinte ou linterface rseau de cette machine qui est hors service ? Ladministrateur ne peut pas non plus dterminer si un service particulier sur un serveur donn fonctionne correctement. Enfin, le simple fait de dtecter quune anomalie existe derrire tel port de tel commutateur ne peut se faire sans regarder le plan de faon frquente ou sans quun utilisateur ne dboule dans le bureau afin dalerter ladministrateur. Lobjet du stage est alors de trouver une solution afin de devenir pro actif face aux problmes rencontrs, de pouvoir contrler dun simple coup d il ltat global du rseau, de dterminer lorigine dun problme afin dy remdier le plus rapidement possible. Ces quelques critres rentrent dans le domaine de la supervision de rseaux, essentiel pour assurer une disponibilit (souvent indispensable) du systme dinformation de lentreprise. Nous dfinissons dans un premier temps ce que nous entendons par supervision de rseaux avant dnoncer un comparatif des solutions actuelles du march puis de nous pencher sur celle que nous avons choisie de mettre en place en prsentant les notions lentourant.

2.2. Cahier des charges


Ladministrateur rseaux devra pouvoir surveiller son rseau via une interface web scurise. Nimporte qui ne doit pas pouvoir accder cette interface, elle devra donc tre protge par un mot de passe. Linterface web devra comporter une cartographie du rseau, prsentant les diffrents postes utilisateurs, les serveurs, les lments actifs et imprimantes. Cette cartographie devra explicitement dcrire ltat des ces machines ; permettre didentifier ltat des ports des commutateurs sur ces mmes machine serait un plus. Linterface devra permettre galement, tant donn une machine, de vrifier que les services tournent correctement ou non. Des renseignements supplmentaires sur les diffrentes machines
1

Simple Network Management Protocol

Mise en place dune solution Nagios. Idjiwa ADJIDO.

(charge CPU, espace disque, mmoire disponible, etc.) pourront tre renseigns. Enfin, lorsque des problmes surviendront, ladministrateur devra tre notifi par un courriel dont le contenu indiquera le service et/ou la machine dfectueuse. La solution devra bien entendu tre la moins chre possible, nous pouvons comprendre gratuite. Nous nous sommes donc orient vers une solution du monde libre : Nagios.

3. Supervision de rseaux
Quest ce que la supervision de rseau, quoi elle sert et que ncessite-t-elle pour tre mise en place ? Cest ce que nous tentons dexpliquer dans cette partie.

3.1. Dfinition
La supervision de rseaux peut tre dfinie comme lutilisation de ressources rseaux adaptes dans le but dobtenir des informations (en temps rel ou non) sur lutilisation ou la condition des rseaux et de leurs lments afin dassurer une bonne qualit et une rpartition optimale de ceux-ci.

3.2. Objectif
Lobjectif dune supervision de rseaux peut ainsi tre rsum en trois points : - Etre ractif en alertant ladministrateur en cas de dysfonctionnement dune partie du systme dinformation ; - Etre pro actif en anticipant les incidents ; - Cibler le problme ds son apparition afin dagir rapidement de la faon la plus pertinente possible.

3.3. Problmatique
La supervision de rseau ncessite des outils adapts aux diffrents composants du rseau. Le parc est dot de machines sous Linux, Windows et Mac OS. Nous devons donc trouver, comme tout bon produit de supervision, un produit capable de superviser lensemble des quipements provenant de diffrents constructeurs et ayant des modes de gestion htrognes. Il sagit alors de trouver un produit reposant sur un protocole ou un environnement normalis afin de pouvoir servir de point dentre unique pour regrouper toutes les informations du rseau.

Mise en place dune solution Nagios. Idjiwa ADJIDO.

4. Solutions existantes
De nombreuses plateformes de supervision existent aujourdhui. Certaines se contentent de connatre tout instant ltat des n uds du rseau, dautres permettent galement de connatre ltat des services sur ces n uds, les derniers offrent la possibilit de ressortir de nombreuses statistiques du rseau permettant une analyse assez fine.

4.1. Les offres diteurs


Depuis quelques annes, conscient que la supervision est un march porteur, les socits nhsitent plus investir dans un produit leur permettant de surveiller et mieux grer leurs rseaux. Les diteurs se sont alors lancs dans la course aux produits de supervision ; deux familles apparaissent, celle proposant des solutions gnralistes supervisant le rseau, les serveurs, les applications, les sites web, etc. Cest le cas de Patrol ou Mainview (BMC), dUnicenter (Computer Associate), de la gamme openview (HP), de Tivoli (IBM), de BigBrother pour ne citer que les plus connus. Lautre famille supervise des domaines plus spcifiques comme Panorama (Altaworks) qui gre uniquement laspect scurit ou PathWAI (Candle) qui se penche principalement sur la supervision des applications. Toutes ces solutions ont en plus de spcificits les distinguant les unes des autres, un point commun : un prix lev. Il faut compter prs de 30 Keuros pour superviser un systme dinformation pour une entreprise de taille moyenne. Ce chiffre ne tient pas compte des formations du personnel travaillant avec ces solutions souvent complexes dutilisation !

4.2. Les offres libres


Il existe des solutions de supervision libres qui sont professionnelles. Parmi les plus r pandus, reconnus du moment nous pouvons citer Nagios (le successeur de Netsaint), Zabbix, openNMS. De ceux cits, Nagios est sans contexte le plus rpandu et le plus suivi par la communaut des dveloppeurs.

Mise en place dune solution Nagios. Idjiwa ADJIDO.

5. Solution slectionne : Nagios


5.1. Pourquoi Nagios ?
5.1.1. Cest une solution libre

Des solutions cites ci-dessus, HPopenview, BigBrother et Nagios sont les plus connues. BigBrother2 est un superviseur de service fonctionnant sous windows NT. Cest une solution efficace mais qui ne permet de superviser quun nombre restreint de services. De plus, il nest pas possible de rajouter des fonctionnalits ou de gnrer des alarmes par mail. HPopenview est une solution modulaire trs complte qui permet de cartographier automatiquement et dynamiquement le rseau, de collecter des informations de supervision, de les mettre en correspondance, denvoyer des alarmes, de gnrer des comptes rendus graphiques...mais cest galement une solution payante, donc carte de nos choix.

5.1.2.

Cest une solution stable qui a fait ses preuves

Parmi les solutions libres, Zabbix et le projet Oron ont t mis en concurrence pour notre choix avec le clbre Nagios. Ce dernier est en effet rput pour sa configuration fastidieuse mais galement pour le fait quil soit tout aussi complet que la solution HPopenview. Le projet Oron3 est une couche au dessus de Nagios regroupant une interface de configuration web, une dtection automatique du rseau et quelques fonctionnalits supplmentaires devant simplifier Nagios. Nous navons pas jug le projet assez avanc pour la slectionner comme solution stable. De plus, nous avons pens que mettre en uvre Nagios nous permettrait de mieux comprendre ce qui ce passe derrire Oron. Enfin, Zabbix, dsign comme un potentiel concurrent Nagios a t cart pour lorientation douteuse que prend le projet : lauteur, bien que prsentant son projet comme libre, ne veut pas que des dveloppeurs touchent son code, ce qui risque dengendrer assez vite des clones de lapplication rendant un support plus difficile. Nagios est stable, dispose dune grande communaut de dveloppeurs derrire elle et est utilise par un grand nombre de fournisseurs daccs ou de grands noms comme Air France, le CNRS4 (taille de lorganisation : 26000 machines), lIFSIC5 (2500 machines) ou encore le modeste Ministre de lEducation National (130 000 machines).

2 3

BigSister est libre, BigBrother n tant libre que pour une utilisation personnelle. Cest un projet lanc par cinq tudiants dEpitech 4 Centre Nationale de la Recherche Scientifique 5 Institut de Formation Suprieure en Informatique et Communication, Rennes

Mise en place dune solution Nagios. Idjiwa ADJIDO.

5.2. Prsentation gnrale


5.2.1. Les fonctionnalits

Lensemble des spcifications est disponible en ligne sur http://www.Nagios.org/about/ Nagios va permettre, entre autre, de superviser des services rseaux (SMTP, POP3, HTTP, DNS6, etc.), de superviser les ressources systmes (charge du processeur, processus en cours, etc.), de faire de la notification, classer les contacts avertir par groupe de contacts, les machines par groupe de machines, de reprsenter par coloration les tats des services et de leurs htes, de cartographier le rseau, de faire du reporting , dintgrer de nouveaux plugins, etc.

5.2.2.

Le concept

Nagios est un systme de supervision de service dvelopp pour des plateformes linux. Le concept consiste au lancement de contrle des services et/ou stations dfinis laide de plugins externes. Ces contrles se font selon un intervalle dfini durant la phase de configuration.

5.2.3.

Le principe de fonctionnement

Les services de surveillance fournissent lapplication les rsultats issus de lanalyse. Si ces rsultats font remonter un problme, une notification est faite. Elle peut tre effectue par sms, messagerie instantane ou mail. Dans le cadre du CERMA, nous nous contentons denvoyer un mail ladministrateur.

5.2.4.

Larchitecture

Nagios peut tre considr comme un noyau qui gre lordonnancement des vrifications (effectues laide de plugins) et les actions prendre en fonction des incidents (alertes, actions correctives, etc.)
Composants rseaux superviss

Nagios

Plugins

Afin de rendre plus exploitable les rsultats, une interface web (nous utiliserons apache) base sur les CGI7 fournis par linstallation par dfaut de Nagios a t rajoute.

6 7

Simple Mail Transfert Protocol, Post Office Protocol, HyperText Transport Protocol, Domain Name Server Common Gateway Interface

Mise en place dune solution Nagios. Idjiwa ADJIDO.

Nous obtenons alors larchitecture suivante :

Navigateur client

Serveur Web (apache)

CGI

Composants rseaux superviss

Nagios

Plugins

Une base de donne peut tre couple Nagios lorsque le nombre de machines supervises devient consquent, ce qui nest pas le cas du CERMA.

5.3. Les plugins


5.3.1. Les plugins de base

Nous entendons par plugin un programme excutable ou un script (shell, perl, etc.) qui peut tre lanc en ligne de commande pour tester une station ou un service. Cest le rsultat de lexcution du plugin qui est interprt par Nagios pour dterminer ltat du service ou de la station teste. Chacun peut donc dfinir son propre plugin et le rajouter aux plugins disponibles par dfaut8 ce qui permet un grand nombre de tests possibles. Il faut cependant respecter certaines conventions de code et de retour de fonction lors de lcriture dun plugin afin de coller aux plugins existants et dtre le mieux possible intgr Nagios. Ainsi, le plugin devra tre excutable avec les droits de lutilisateur Nagios, il devra afficher un message de prfrence sur une seule ligne dcrivant la situation du service (par exemple : Temps de rponse OK : 0.586 secondes ) et possder un code de retour9 qui indique le statut du service : - 0 : OK, le service fonctionne correctement ; - 1 : Warning, le service est dgrad ; - 2 : Critical, le service ne fonctionne plus ; - 3 : Unknown, impossible de dterminer ltat du service. Un nombre consquent de plugins est fourni dans linstallation par dfaut ; ainsi derrire le plugin check_ping se cache la commande /bin/ping ou encore derrire le plugin check_dns se cache un simple ping sur ... google.com !

8 La communaut Nagios offre aujourdhui des bibliothques de plugins assez compltes disponibles sur les sites http://www.Nagiosexchange.org, http://www.Nagios.org/download, http://sourceforge.net/projects/Nagiosplug/ 9 Ce que fait parfaitement la fonction exit.

Mise en place dune solution Nagios. Idjiwa ADJIDO.

5.3.2.

NRPE, NSCA

Les crateurs du projet Nagios ont prvu des agents particuliers permettant de ne pas modifier les dispositions de scurit existantes. Il sagit principalement de Nagios Remote Plugin Executor et de Nagios Service Check Acceptator. Le premier constitue une mthode de surveillance active : un plugin check_nrpe permet la station moniteur Nagios denvoyer des instructions au dmon NRPE situ sur la machine distante. Le second est une mthode de surveillance dite passive : un client NSCA est install puis configur sur chaque station supervise afin quelle envoie delle-mme les rsultats de tests la machine Nagios.

5.4. Linstallation
Quelque soit la documentation10 que vous pourrez obtenir sur Nagios, elle vous indiquera quil faut sarmer de patience. Nagios peut sinstaller de deux faons, soit manuellement (cest la partie annonce comme fastidieuse, nous confirmons) en compilant les sources disponibles sur le site officiel, soit en utilisant les nombreux paquetages mis disposition selon la distribution que vous utiliserez. Personnellement, la phase manuelle nous permis, aprs cependant quelques heures de compilation, de recherche de librairies pour grer les dpendances, de bien comprendre ou tait install tel ou tel fichier. La phase automatique, via lutilisation dun RPM (ou dutilitaires tel que yum ou apt-get) se charge des dpendances entre les diffrents fichiers et librairies, une dizaine de minutes suffisent alors pour une installation minimale bien moins prise de tte . Il faut peut tre noter que les rpertoires suggrs lors de linstallation manuelle ne sont pas ceux utiliss lors des installations via paquetages et que les fichiers nont pas forcment les mme noms selon les versions installes. Un document dtaillant la mise en uvre Nagios mise en uvre pour le CERMA est fourni en annexe.

5.5. Le mode de dploiement


Nagios, en tant que bonne solution de supervision peut tre dploye de trois manires diffrentes : centralise, hirarchise ou distribue.

5.5.1.

Dploiement centralis

Toute la supervision se fait laide dune seule machine. Linconvnient immdiat est bien-sur que toute la gestion repose sur le bon tat de la station de supervision. De plus, la machine doit tre capable de grer lensemble des donnes de supervision lui arrivant du rseau.

5.5.2.

Dploiement hirarchis

Un serveur de supervision dialogue avec dautres serveurs de supervision ; chacun deux tant affect un unique segment de rseau. Ces mmes serveurs peuvent tre la fois client et serveurs de supervision, c'est--dire quils peuvent galement avoir dautres serveurs sous leur responsabilit. Ce type de dploiement est plus complexe mettre en place mais offre une meilleure tolrance la panne. Un inconvnient supplmentaire est galement un temps de
10

Une documentation officielle franaise est disponible derrire http://www.Nagios.org/docs/, nous recommandons vivement de la suivre au moins pour savoir ce que font les diffrents paquetages ensuite.

Mise en place dune solution Nagios. Idjiwa ADJIDO.

10

rponse plus long du une synchronisation ncessaire entres les serveurs pour la remonte dinformations.

5.5.3.

Dploiement distribu

Cest un dploiement qui combine les deux prcdents. Chaque station de supervision tient jour une base de donnes et toutes les stations changent entre elles toutes les donnes de supervision. Certaines stations peuvent tre spcialises ; la difficult de ce dploiement consiste mettre en place une parfaite coopration des stations.

5.5.4.

Dans le cadre du CERMA

Nous rappelons que le rseau est un rseau modeste dune centaine de machines. Nous pouvons nous permettre de centraliser la supervision sur une seule machine. Mettre en place un dploiement distribu serait du luxe inutile dans notre cas ; en revanche, le rseau tant segment en VLANs, nous pourrions trs bien imaginer faire un dploiement hirarchique. Mais ce serait prvoir plusieurs machines affectes la supervision ce que ne permet pas les moyens du parc. Nous mettons donc en place une seule station Nagios sur laquelle reposera toute la gestion de la supervision. Nous utiliserons principalement le protocole SNMP en association avec Nagios vitant ainsi linstallation puis la configuration des agents NRPE, NSCA sur les stations.

5.6. La configuration de base


Configurer Nagios sans utiliser doutils11 particulier revient diter des fichiers textes. Nous prsentons ici les principaux fichiers qui constituent la configuration de notre solution de supervision. Bien que certains outils nous permettent dignorer la prsence de ces fichiers, il est bon de savoir qui ils sont et ce quils contiennent ou encore comment ils sont relis entre eux. Les noms des fichiers indiqus sont ceux par dfaut, ils pourraient trs bien tre nomms autrement, le tout tant de savoir ce que lon met et dans quel fichier.

5.6.1.

Dfinition des commandes

Cest ici que lon se sert des plugins. Afin den simplifier lutilisation, nous crons une sorte dalias : une commande compose dun nom qui identifie la ligne de commande laquelle elle correspond. Ces commandes sont places dans un fichier commands.cfg et seront appels dans les autres fichiers de configurations pour pouvoir tester stations et services selon la commande et le plugin utilis.

5.6.2.

Dfinition des contacts

Lorsque des notifications sont faites par Nagios, elles peuvent tre transmises un contact par mail, par sms, etc. Cest dans un fichier contacts.cfg que lon dfinit le contact. Un contact doit alors avoir un nom, ventuellement un alias, les plages de fonctionnement auquel il peut tre notifi et la manire quil aura de ltre. Cest ce niveau que le mail doit tre renseign si ncessaire. Le contact peut alors appartenir un groupe particulier au mme titre que
11

Certains outils comme Nagat, Nagios-admin (pour ne citer queux !) sont disponibles sur http://www.Nagiosexchange.org/Configuration.40.0.html et permettent une configuration plus aise de ces fichiers textes.

Mise en place dune solution Nagios. Idjiwa ADJIDO.

11

dautres contacts. Ces groupes de contacts sont dfinis dans un fichier nomm contactgroup.cfg qui contient le nom du groupe et les membres qui y appartiennent.

5.6.3.

Dfinition des stations

Le fichier hosts.cfg comporte la dclaration de toutes les stations. Nous y retrouvons les noms, les alias, les adresses des machines et galement divers paramtres tels que les intervalles de tests, le nombre de tentatives, etc. Il y a bien sur possibilit de faire une dclaration gnrique. Ainsi, nous pouvons dfinir un host gnrique comportant une certaine configuration des paramtres. Toutes les stations dclares utilisant le paramtre use le nom de la station gnrique hriterons alors de ses proprits, cela permet dallger le fichier et une configuration plus claire. De la mme faon que la dfinition des contacts plusieurs stations peuvent faire partie dun mme groupe. Par exemple, le CERMA possde quatre commutateurs qui sont dclars individuellement mais qui font partie dun mme groupe commutateurs. Cest le fichier hostgroup.cfg qui comporte ces dclarations.

5.6.4.

Dfinition des services

Le fichier services.cfg comporte la dclaration des services superviser. De la mme faon que prcdemment une dclaration gnrique dun service particulier peut tre faite. Le paramtre use permet ensuite daffecter un autre service les caractristiques de ce service gnrique. A chaque service peut tre affect une ou plusieurs stations.

5.6.5. Dfinition des diffrents services

plages

de

fonctionnement

pour

les

Il est possible de dfinir des types dintervalles de temps permettant de grer le temps de fonctionnement de services, les priodes de prsence ou dabsence des administrateurs, etc. Cest le fichier timeperiods.cfg qui hberge ces dfinitions. Chaque plage de fonctionnement est nomme pour tre ainsi appel lors des dclarations dintervalles par exemple indiqus dans les fichiers de configuration prsents plus haut.

6. Nagios coupl SNMP


Simple Network Management Protocol est un des protocoles (simples) de gestion de rseaux les plus utiliss, devenu de fait un standard quasi incontournable dans le domaine. Il sappuie sur le protocole TCP/IP12 ce qui peut expliquer le fait quil se soit propag si rapidement. Trois versions se sont succdes : SNMPv1, SNMPv2 et SNMPv3. Plusieurs RFC 13 dfinissent ce standard, nous pouvons citer la RFC 1155SMI (Structure of Management Information), RFC 1156MIB (Management Information Base), RFC 1157SNMP Protocol, etc. SNMP est conu pour rpondre aux besoins pratiques et quotidiens de ladministrateur. Ce dernier a souvent besoin de connatre un certain nombre dinformations sur ses quipements. Sur un parc consquent se dplacer peut vite devenir sportif, voire puisant. Rgler des paramtres de son bureau, tranquillement assis sur une chaise est donc particulirement intressant. Les systmes utilisant SNMP possdent deux lments cls. Un agent logiciel, comprenant une base dobjets superviss et de variables, qui fonctionne dans les stations gres et une station de gestion (manager) qui contient le protocole et les
12 13

Transmission Control Protocol / Internet Protocol Request For Comments, documents spcifiant les normes, standards ou protocoles.

Mise en place dune solution Nagios. Idjiwa ADJIDO.

12

applications de gestion. Cette station permet de rcolter, danalyser les donnes relatives aux quipements superviss. Le protocole est asynchrone, de type question/rponse. Il peut faire lui tout seul lobjet dune tude, nous le prsentons succinctement et ne nous lancerons donc pas dans les dtails ; tout comme nous naborderons pas les questions de scurit des diffrentes versions.

6.1. Le principe de SNMP


6.1.1. Lagent SNMP

Chaque quipement sur lequel intervient ladministrateur via SNMP doit disposer dun agent SNMP. Il sagit dun serveur qui reste lcoute dun port particulier : lUDP 161. Le serveur rpond aux requtes quil reoit (dune entit autorise). Soit pour agir localement sur un paramtre que ladministrateur souhaite modifier, soit pour retourner linformation demande. Lagent pourra galement, sil a t configur pour, envoyer de lui-mme des alertes. Ces agents SNMP peuvent tre placs sur des quipements terminaux (ordinateurs) mais galement sur des quipements intermdiaires (routeurs, switchs, ponts, etc). De plus en plus dquipement intermdiaire dispose dagents SNMP. En revanche, lagent doit tre install sur les stations (et serveurs). Sous Windows (2000 Pro, Server et XP) lagent est incorpor, sous Unix existe net-SNMP ou ucd-SNMP. Les agents SNMP peuvent tre paramtrs (la finesse dpendant du systme) afin de crer des groupes de scurit qui ont un accs en lecture seule sur les informations. Dautres en lecture/ criture ou encore en criture seules et sur certains paramtres seulement.

6.1.2.

Station dadministration

Ladministrateur dispose sur sa machine dun outil appel manager . Loutil fait office la fois de serveur (puisquil reoit les alertes) et de client (puisquil envoi des requtes). Le manager reste lcoute sur le port UDP 162. Ladministrateur peut donc en thorie observer le comportement de lensemble du rseau (que ce soit un LAN ou un WAN) depuis sa station. Des managers existent en version graphique (openview, open eyes, etc.) ou en version commande en ligne (sous unix, SNMPwalk est un des plus connus et celui que nous avons utilis principalement durant nos tests). Des versions plus labores pouvant tirer des graphes, des statistiques, afficher la charge dinterfaces rseaux existent galement. Lapplication getif gratuite sous Windows rassemble par exemple a elle seule de faon plus ergonomique, les fonctionnalits de SNMPwalk, SNMPget, SNMPset et SNMPtranslate disponible sous unix avec le package net-SNMP.

6.2. Le protocole SNMP


6.2.1. Commandes du protocole dans sa premire version

La version 1 comporte 5 commandes principales : - get-request : le manager demande une information lagent ; - get-next-request : le manager demande linformation suivante lagent ; - set-request : le manager met jour une information sur un agent ; - get-reponse : lagent rpond un get-request ou a un set-request ; - trap : lagent envoie une alarme au manager. Nous rappelons que lagent utilise le port 161 et le manager le port 162.

Mise en place dune solution Nagios. Idjiwa ADJIDO.

13

6.2.2.

Ncessit dune standardisation des informations

Comme on le constate le protocole est simple. Cependant, tant un protocole Internet, il doit tre utilisable sur des plates formes htrognes (matriel et systmes dexploitations !). Il a donc fallu lui associer des standards pour la gestion, le stockage des informations transportes et utilises par le protocole. Un lment indissociable de SNMP est donc la MIB pour Management Information Base, une base dinformations de gestion.

6.3. Management Information Base


SNMP doit permettre de retrouver les informations et dagir sur les paramtres des quipements de faon indpendant du matriel et du logiciel. La MIB se prsente comme cette base de donne normalise qui permet de lire et dcrire sur les quipements distants (de faon galement standard). Cest lagent lui-mme de traduire les informations entre SNMP et la plate forme de supervision.

6.3.1.

Syntaxe des informations de gestion (SMI)

Cette syntaxe dfinit comment chaque lment est reprsent dans la base dinformation de gestion. Cest en fait un sous ensemble de la norme ASN.114 : seuls quatre types de donnes sont utilises : - Integer : ce sont des valeurs entires ; - Octect String : cest une suite de zro ou de plusieurs octets pouvant accepter des valeurs comprises entre 0 et 255 ; - Object Identifier : suite de numros rfrenant un objet enregistr par une autorit comptente ; - Null. Il y a galement deux types de donnes structures utilisables que sont les listes et les tables deux dimensions.

6.3.2.

Structure de la MIB

La Management Information Base contient lensemble des variables supervises. Elle met en uvre un jeu de variable traitant la fois du matriel et du logiciel. Les noms des lments de la base suivent une hirarchie dfinie par lISO15 pour le nommage des objets rseaux ; les objets de la base sont ainsi classs en une structure de classes dobjets. Un premier niveau de classes dobjets de la base (MIB 1) comprend, entre autres, les groupes suivants : system : informations relatives au n ud lui-mme ; interfaces : pour les ports et les interfaces rseaux ; address translation : pour la traduction des adresses ip ;

Seuls certains groupes dobjets peuvent tre implments suivants le type dquipement grer. De la mme faon, des MIB propritaires ont vu le jour ; elles comportent des objets spcifiques.
14 15

Abstract Syntax Notation International Organisation for Standardization

Mise en place dune solution Nagios. Idjiwa ADJIDO.

14

Lorganisation hirarchique se fait de la mme faon que les domaines dInternet. Elle contient une partie commune tous les agents SNMP, tous les agents dun mme type de matriel ensuite, une partie spcifique aux constructeurs enfin. Les appellations des diverses rubriques qui composent la MIB sont galement normalises et permettent thoriquement une meilleure lecture pour l il humain. En effet, SNMP ne se sert que de lindexation faite de ces appellations. Chaque niveau hirarchique est index numriquement.

Mise en place dune solution Nagios. Idjiwa ADJIDO.

15

Pour un rseau IP cest le n ud dod et le sous n ud Internet qui seront utiliss. Il sagit donc de passer par les n uds .1.3.6.1 ce qui correspond .iso.org.dod.internet . Pour dsigner une feuille on rajoute un 0 pour indiquer le scalaire (la valeur), n si il sagit dun tableau de scalaires. La notion de chemin absolu/relatif est retrouve par le . plac avant la suite de n uds. .1.3 dsigne un chemin absolu, 1.3 dsigne un chemin relatif. Passer de la version numrique la version textuelle parfois plus parlante peut se faire avec des outils comme SNMPtranslate ou mme des options de SNMPwalk.

6.4. SNMP et Nagios


Comme nous lavons expliqu dans les rubriques ci-dessus, SNMP peut tre un outil intgr Nagios. Nous avons vu que des plugins spcifiques NRPE, NSCA fourni par Nagios permettent de ne pas utiliser SNMP. Cependant, lutilisation de ces plugins impose linstallation dun agent spcifique (les agents SNMP tant par dfaut sur tous les commutateurs) sur chaque machine supervise ! Des plugins utilisant SNMP sont galement fournis dans linstallation par dfaut de Nagios. Nous pouvons citer check_snmp ou check_ifoperstatus par exemple. Le second va nous permettre par exemple de remonter ltat, le statut (up ou down) dun port prcis dun commutateur donn. Ce dernier plugin par exemple utilise la commande snmpget sur lOID .1.3.6.1.2.1.2.2.1.8.x ou x est le numro du port considrer.

7. Lutilisation de Nagios par le CERMA


7.1. Les services monitors
Le service de base utilis sur lensemble du parc est le test de leur prsence sur le rseau. Un ping, via le plugin check_ping est effectu intervalles rguliers. Sur certaines machines, les serveurs linux notamment, nous pouvons tester galement que les services ftp, http, ssh soient fonctionnels. Plusieurs plugins offert dans la distribution par dfaut sont des plugins locaux. Ainsi tester lespace disque restant o la mmoire utilise en utilisant ces plugins se fait localement ; le test ne peut donc pas tre effectu de la machine de supervision par dfaut. Nous navons pas souhait installer les plugins NRPE ou NSCA dans un premier temps. Une autre solution sera dcrire un plugin spcifique utilisant SNMP (activ sur les machines concernes) afin de rcuprer ces informations.

7.2. La gnration des fichiers de configurations


La gnration manuelle des fichiers de configuration est fastidieuse. Il faut dfinir chaque station. Dfinir le groupe auquel elle appartient. Dfinir ensuite les services de cette station. Et ce, pour toutes les stations du parc superviser ! Un utilitaire existe nmap2nagios16 qui permet de crer des fichiers de configuration partir dun fichier xml gnr par Nmap. Nmap gnre le fichier xml en scannant le rseau. Problme avec le rseau du CERMA : les machines sont la plupart du temps teintes ! Seules une vingtaine de machines ont donc t scannes lors de lutilisation du script, les serveurs linux. Cette solution nest donc pas adapte aux conditions pratiques du parc du CERMA. Il a fallu trouver un autre moyen de gnrer le fichier xml puis dans la foule nous avons personnalis la gnration des fichiers de configuration. Pour ce faire, l'administrateur du CERMA a adapt un script perl crit pour le
16

Disponible sur http://www.nagiosexchange.org

Mise en place dune solution Nagios. Idjiwa ADJIDO.

16

plan textuel existant afin de fournir le fichier xml et nous avons dvelopp quelques lignes de code pour gnrer partir du xml produit par son script les six fichiers de configuration directement li la gestion du parc.

7.3. Laccs aux informations


Laccs aux informations fournies par Nagios se fait classiquement par linterface web qui est fourni avec linstallation par dfaut dcrite en dtail (rubrique par rubrique) dans la documentation. En lisant cette documentation ou en manipulant quelques secondes linterface nous dcouvrons comment nafficher que les informations par groupe de machines (seulement les donnes concernant les imprimantes ou les serveurs linux) ou par services, etc. La cartographie et autres informations sont donc accessibles via un navigateur. Laccs ces donnes est protg par un mot de passe. Lauthentification se fait en utilisant lannuaire LDAP.

7.4. Affichage des ports


Nous avons utilis une astuce pour afficher les ports sur la cartographie. Chaque port est dfini pour Nagios comme une station normale, sans adresse spcifique. Nagios afin de permettre un meilleur affichage offre la notion de parent pour une machine donne. Ainsi une machine connect un commutateur aura pour parent ce dernier. De cette faon, laffichage montre clairement que la machine dpend du commutateur. Nous avons donc utilis cette fonctionnalit en insrant le port (considr comme une station par Nagios) entre la machine et le commutateur du port auquel elle est connecte. Ainsi, la machine a pour parent un port qui a pour parent son commutateur. Le plan permet donc de savoir graphiquement quelle machine est derrire quel port.

Mise en place dune solution Nagios. Idjiwa ADJIDO.

17

8. Bilan personnel
8.1. Difficults rencontres
La principale difficult a dabord t le systme dexploitation. Nous ne connaissions linux que de faon superficielle, les commandes de base tel que ls, cd, etc ; et uniquement quelques fichiers comme le .bashrc, lilo.conf, etc. Il nous a donc fallu passer une barrire en nous habituant au nouvel environnement, comprendre comment tait organis les fichiers, ou se trouvait les fichiers de configurations, les fichiers de logs, les scripts de lancement de services... prendre nos marques sur la distribution. Les premiers problmes ont donc t les outils avec lesquels nous travaillions. Une fois nos raccourcis placs, lenvironnement mieux matris, nous avons aprs avoir essuy quelques essais laborieux de compilation manuelle de Nagios dcouvert puis compris le fonctionnement des utilitaires tels que yum, synaptic, apt-get. A partir de ce moment l seulement, loutil linux na plus t un problme et nous ne perdions plus de temps grer les dpendances : nous pouvions nous concentrer sur la configuration de Nagios.

8.2. Comptences utilises


Connatre le principe de configuration par fichier texte et savoir lire une documentation (en ligne ou non) auront t un plus. Nos quelques connaissances en Shell nous ont permis de faciliter nos dmarches dans lautomatisation de certaines tches rcurrentes. Les acquis de la formation Java nous ont permis de dvelopper quelques lignes de codes permettant de gnrer automatiquement les fichiers de configurations de Nagios. Enfin, un soupon de bon sens, de persvrance et de patience ont t les derniers ingrdients pour cette recette.

8.3. Comptences acquises


Sans se poser de question : linux. Nous pouvons maintenant dire sans complexe que nous avons de bonnes bases sous linux aprs un mois dutilisation quotidienne du systme dexploitation ; nous avons test deux distributions diffrentes qui sont la Fdora Core 2 et la Ubuntu. Quelques astuces de programmation (shell et java 1.5) nous ont galement t fournies gnreusement. Nos connaissances thoriques sur le protocole SNMP ont t amliores et la vie quotidienne en entreprise au ct dun administrateur rseau nous a confront des cas pratiques de problmes/solutions qui nont fait quaugmenter notre exprience. Nous avons galement appris livrer une solution de dploiement partir dune installation par dfaut. La solution Nagios mise en uvre pour le CERMA peut tre installe en tapant trois commandes. Une personne ne connaissant pas Nagios peut ainsi aisment mettre en place la solution. Un autre avantage dun dploiement efficace est que ces trois commandes sont galement ce quil faudrait faire pour monter en quelques minutes une autre machine de supervision en cas de dfaillance de la premire. Enfin, accessoirement, nous avons galement intgr aprs avoir quelque peu particip la migration de commutateurs du parc combien la pose professionnelle du cblage tait importante et ncessaire dans un rseau .

Mise en place dune solution Nagios. Idjiwa ADJIDO.

18

9. Conclusion
Nous avons appris bien des choses durant ce mois pass trs vite. Cependant, nous avons limpression en sortant du stage que tout reste faire ! La solution livre est fonctionnelle, elle permet de visualiser en temps rel ltat des stations et des quelques services mis en place sur certaines machines. Il y a cependant un problme qui na pas encore t rgl. Certaines machines nont pas dadresse ip dfinies lors de la gnration des fichiers de configurations, il sagit des machines dont ladresse est affecte dynamiquement. Les outils standard comme le ping fournis avec Nagios, la base cre pour la supervision de serveurs ayant donc des adresses fixes, ne fonctionnent pas sans adresse ip. Nous avons alors utilise une astuce qui fonctionne sur quelques machines : utiliser le nom netbios. Pour toutes les machines rfrences, la rsolution dadresse se fait bien, le ping est alors fonctionnel. En revanche, ltat actuel de la solution est incapable de superviser les machines non rfrences et sans adresse ip, Nagios les considre logiquement comme en tat critique puisquelles ne rpondent pas au ping. Une solution serait alors dcrire (ou de trouver) un plugin qui dtermine dynamiquement ladresse ip dune machine donne partir de son nom ou de son adresse mac en utilisant rarp par exemple. Une autre fonctionnalit intressante serait dutiliser nagios graph17 et des plugins comme check_traffic ou autre afin de rcuprer des informations sur les dbits circulants sur les diffrents ports des commutateurs ; il serait alors possible davoir en temps rel des courbes indiquant des donnes sur le trafic du rseau. Ce sont principalement les deux points que nous aurions dvelopps sur un stage plus long.

10. Annexe
Sont fournis en annexe avec ce rapport : un document orient installation tape par tape de Nagios prsentant la mise en uvre de la solution pour le CERMA ; les sources de lapplication java gnrant automatiquement les fichiers de configurations et la documentation associe ; un Makefile et une archive permettant une installation aise : lutilisateur tape simplement make install aprs linstallation de Nagios par dfaut, elle-mme effectue laide de deux commandes partir dinstalleur tel que yum ou apt-get.

17

http://sourceforge.net/projects/nagiosgraph/

Mise en place dune solution Nagios. Idjiwa ADJIDO.

19

Vous aimerez peut-être aussi