CARNE Maxime A3RIR

Rapport de stage

MISE EN PLACE D’UN SERVEUR DE

SUPERVISION

Service Départemental d’Incendie et de

Secours des
Pyrénées-Atlantiques

Responsable de stage : F. SAUVE

Année 2007/2008 EXIA PAU

Remerciements

J’adresse tout d’abord mes remerciements au Colonel LEDOUX, pour m’avoir permis
d’effectuer mon stage au sein de son établissement.

Je tiens ensuite à remercier Franck SAUVE, mon responsable de stage, pour m’avoir
accueilli au service exploitation informatique ainsi que Thierry COURCET,
responsable du service informatique. Ils m’ont permis de parfaitement m’intégrer au
sein de l’équipe et m’ont accordé une grande confiance durant ces trois mois.

De plus, je tiens à remercier toute l’équipe du service informatique, David ANDRE,

Philippe BARBAUD, Serge BILHERE, Laurent BOCQUET, Michèle CAOULES,
Nathalie CHIRIE, Arnaud ELKAIM, Gérard LABORIE et Fabrice PALAZO qui m’ont
tous permis d’évoluer dans les meilleures conditions possibles.

Je tiens enfin à remercier l’ensemble du personnel de l’EXIA PAU, et tout

particulièrement, Jean-Christophe DUGALLEIX, pour sa disponibilité et son écoute.

2
Sommaire

I. Introduction 4

II. Présentation 5

A. Présentation de l’entreprise 5
B. Présentation du réseau informatique 9
C. Présentation du projet 11
D. Objectifs 13
E. Planning 14

III. Mise ne place d’un serveur de supervision 16

A. Préparation du système 16
1. Choix de la distribution 16
2. Mise en place du serveur LAMP 16

B. Cacti 19
1. Installation 19
2. Configuration 19
3. Utilisation 22

C. Plugins Cacti 25
1. Syslog 25
2. NTOP 27
3. Weather Map 29

D. Nagios 31
1. Présentation 31
2. Installation 32
3. Configuration 34
4. Utilisation 41

IV. Continuité du projet 50

A. Tâches restantes 50
B. Evolution 50

V. Conclusion 51

VI. Annexes 52

3
 I. Introduction

Dans le cadre de ma 3ème année de Responsable Ingénierie des Réseaux à l’EXIA,

j’ai choisi d’effectuer mon stage de trois mois au sein du service informatique du
Service Départemental d’Incendie et de Secours des Pyrénées-Atlantiques.

Sous la tutelle de Franck SAUVE, responsable de l’exploitation réseau informatique

du SDIS, j’ai pu évoluer dans une équipe dynamique et ainsi réaliser le projet qui
m’était proposé : la mise en place d’un serveur de supervision du réseau.
Mon objectif personnel était de découvrir concrètement la réalisation complète d’un
projet en milieu professionnel.
Respecter les délais, être réactif, être en constante veille technologique, travailler en
autonomie, tous ces points prennent une dimension plus importante en entreprise.

Intégrer au départ pour mettre en place le serveur de supervision, d’autres tâches

sont venues se greffer, me permettant d’aborder une multitude d’éléments
notamment la migration vers un nouveau domaine.
Ainsi, ce stage est un concentré d’expériences enrichissantes tant du point de vue
personnel que professionnel.

Les objectifs du stage étaient clairement définis. En commençant par la découverte

de logiciels de supervisions opensources, je devais ensuite proposer une solution de
mise en place d’un serveur de supervision en tenant compte des caractéristiques
propres au SDIS. Après une phase d’installation et de configuration des logiciels
retenus : Cacti et Nagios, le but était de mettre en production le serveur de
supervision. Enfin, le dernier point consistait en la rédaction d’un document
généraliste à destination d’Internet.

Mon stage s’est donc articulé autour de la mise en place d’un serveur de supervision.
Après avoir fait une présentation du Service Départemental d’Incendie et de Secours
et plus particulièrement du service informatique ainsi que de son réseau, je
présenterai le projet. Je tâcherai ensuite de décrire l’installation, la configuration et
l’utilisation de Cacti puis de Nagios. Enfin, je proposerai une partie sur l’évolution du
projet.

4
 II. Présentation

A. Présentation de l’entreprise

Le Service Départemental d’Incendie et de Sécurité (SDIS) est un établissement

public administratif. Son financement est assuré par les communes, les
établissements publics de coopération intercommunale et le département. Le SDIS
est administré par un conseil composé de 22 membres dont 14 au moins sont issus
du Conseil Général. Le SDIS fait donc parti de la fonction publique territorial et son
fonctionnement est critique pour la bonne santé de la sécurité civile.
La structure d’un SDIS se compose de cette manière :

• Un corps départemental qui comprend des centres d’incendie et de secours

classés en Centre de Secours Principaux (4 CSP dans les Pyrénées-
Atlantiques), en Centres de Secours (31 dans les PA) et en Centres de
Premières Interventions (11 dans les PA).
• Un service de santé et de secours.
• Des services opérationnels, administratifs ou techniques dont le service
Gestion du Système d’Information (GSI) dans lequel s’est déroulé le stage.

D’un point de vue informatique, chaque entité est reliée soit physiquement, soit
logiquement. Mais ceci sera développé par la suite.

Le SDIS est donc une structure indispensable à la sécurité civile dont les missions
s’organisent autour de deux axes :

• Le SDIS est chargé de la prévention, de la protection et de la lutte contre les

incendies. Ceci comprend :
o La prévention et l’évaluation des risques de sécurité civile.
o La préparation aux mesures de sauvetages et d’organisation des
moyens de secours.
o La protection des personnes, des biens et de l’environnement.
o Le secours d’urgence aux victimes d’accidents, de sinistres ou de
catastrophes, ainsi que leurs évacuations.

• Le SDIS concourt avec les autres services concernés à la protection et à la

lutte contre les autres accidents, sinistres et catastrophes, à l’évacuation et à
la prévention des risques technologiques ou naturels ainsi qu’aux secours
d’urgences.

La zone de couverture du SDIS 64 s’étend à tout le département. Pour une meilleure

gestion des interventions, le territoire a été divisé en 4 groupements dirigés par les 4
Centres de Secours Principaux : Pau, Orthez, Oloron et Anglet. Chaque groupement
comprend des Centres de Secours et des Centres de Premières Interventions.

5
 Landes ∗ ORGANISATION
TERRITORIALE

e
iqu
DU SDIS 64
ant Gers
Atl

LEGENDE
LEGENDE
an
Océ

Garlin
Garlin
Garlin
Limites secteur 1er appel
Garlin
Garlin
Puy
Puy
Puyoo
oo Arzacq-arraziguet
Arzacq-arraziguet
Arzacq-arraziguet
Arzacq-arraziguet
Anglet
Anglet
Anglet Urt
Urt
Urt
Urt Limites cantonales
Bidache
Bidache
Bidache
Salies-de-bearn
Salies-de-bearn
Salies-de-bearn Orthez
Orthez
Orthez
Saint-jean-de-luz-nautique
Saint-jean-de-luz-nautique Labastide-
Labastide- Salies-de-bearn
Salies-de-bearn
Saint-jean-de-luz-nautique
Saint-jean-de-luz-nautique
Saint-jean-de-luz-nautique Labastide-
Labastide-
Labastide- Arthez-de-bearn
Arthez-de-bearn
Arthez-de-bearn
Arthez-de-bearn
Arthez-de-bearn
vvvvvvillef
illef
illef Groupement d'Oloron
illefranche
illef
illef ranche
ranche
ranche Lembey
Lembeyeee
e
Lembey
Lembey
Saint-jean-de-luz
Saint-jean-de-luz
Saint-jean-de-luz
Saint-jean-de-luz Ustaritz
Ustaritz
Ustaritz
Ustaritz
Hasparren Sauv
Sauveterre-de-bearn
Sauv
Sauv eterre-de-bearn
eterre-de-bearn
eterre-de-bearn
eterre-de-bearn Artix
Artix
Henday
Hendaye
Henday
Henday
Henday ee
e Hasparren
Hasparren Artix
Artix
Artix
Saint-pee-
Saint-pee-
Saint-pee-
Saint-pee-
Saint-pee- Groupement de Pau
Cambo-les-bains
Cambo-les-bains
Cambo-les-bains Mourenx
Mourenx
Mourenx
Mourenx
Mourenx
sur-niv
sur-nivelle
sur-niv
sur-niv elle
elle
elle
elle
Saint-palais
Saint-palais
Saint-palais
Saint-palais
Saint-palais Groupement d'Orthez
Nav
Navarrenx
arrenx
arrenx Arbus
Arbus
Arbus
Nav
Nav
Nav arrenx
arrenx Monein Arbus
Monein
Monein
Monein
Monein Arbus
Pau
Pau
Pau Pau-dsi
Pau-dsi
Pau-dsi
Pau-dsi
Pau-dsi
Pau
Pau
Pau
Iholdy
Iholdy
Iholdy
Iholdy
Iholdy
Iholdy Groupement de Bayonne
Osses
Osses
Osses
Osses
Osses
Soumoulou
Soumoulou
Soumoulou
Soumoulou
Soumoulou
Mauleon-licharre
Mauleon-licharre
Mauleon-licharre
Mauleon-licharre
Mauleon-licharre Centre d'Intervention
Gan
Gan
Gan
Gan
Gan
Gan
Lasseube
Lasseube
Lasseube
Lasseube
Lasseube et de Secours (CIS)
Saint-etienne
Saint-etienne
Saint-etienne
Saint-etienne
Saint-etienne Oloron-sainte-marie
Oloron-sainte-marie
Oloron-sainte-marie
-de-baigorry
-de-baigorry
-de-baigorry
-de-baigorry
-de-baigorry Saint-jean-
Saint-jean-
Saint-jean- Nay
Nay
Nay
Nay Pontacq
Pontacq
Pontacq
Pontacq
Pontacq
pied-de-port
pied-de-port
pied-de-port
pied-de-port
pied-de-port Coarraze
Coarraze
Coarraze
Coarraze
Coarraze

Tardets-sorholus
Tardets-sorholus
Tardets-sorholus
Tardets-sorholus
Tardets-sorholus
Arette
Arette Arudy
Arudy
Arudy

ées
Arette Arudy
Arudy

rén
Py
Bedous
Bedous
Bedous
Bedous
Bedous

s-
La-pierre-saint-martin
La-pierre-saint-martin Laruns
Espagne La-pierre-saint-martin
La-pierre-saint-martin
La-pierre-saint-martin Laruns
Laruns

ute
Gourette
Gourette
Gourette
Gourette
Gourette
Lescun
Lescun
Lescun
Lescun

Ha
Urdos
Urdos
Urdos
Urdos
Urdos Fabrege
Fabrege
Fabrege
Fabrege
Fabrege

Presentation_org_ter_1

0 10 20 30 STIC
A. Elkaim
Kilometers septembre 2007

Organisation Territoriale du SDIS 64

Les centres de secours sont soit composés uniquement de volontaires soit mixtes
volontaires/professionnels. Leur catégorie dépend du nombre d’interventions
effectuées dans l’année. Le SDIS des Pyrénées-Atlantiques est classé comme
département de 2ème catégorie (sur 5) par des critères de population, d’effectifs,
d’interventions et de moyens.
Les risques liés à la montagne, l’océan, l’affluence touristique, les aéroports de Pau
et Biarritz ou encore l’usine Total de Lacq font du SDIS 64 un organisme très critique
pour la sécurité civile.

Ainsi c’est plus de 2200 agents, composés de Personnel Technique et Administratif

(PAT), de Sapeurs Pompiers Professionnels (SPP) et de Sapeurs Pompiers
Volontaires (SPV, ¾ de l’effectif), qui assurent la sécurité dans les Pyrénées-
Atlantiques.

L’organigramme du SDIS 64 comprend trois niveaux : la direction, les groupements

territoriaux et les Centres d’Interventions et de Secours.

6
 Organigramme du SDIS 64

Le stage s’est déroulé au sein du service Gestion du Système d’Information rattaché

à la direction opérationnelle et technique. Ce service composé de 11 personnes est
dirigé par Thierry Courcet. Il comprend 5 entités : les transmissions, la gestion de
projet administratif et opérationnel, le support informatique, le système d’information
géographique et la gestion du réseau et des systèmes.

Organigramme de GSI
7
Le service est en constante mutation et plusieurs projets y sont en cours de
réalisations : mise en place d’un annuaire LDAP, refonte du système d’information
administratif et fonctionnel, développement de l’informatique communicante, création
d’un système d’information géographique, refonte de la plateforme d’alerte, évolution
de la plateforme informatique et développement d’un infocentre. Ces projets
demandent l’intervention des différentes entités du service en collaboration avec des
intervenants extérieurs.

Le stage s’est déroulé sous la tutelle de Franck Sauvé et Laurent Bocquet,

responsables de l’administration et de l’exploitation des réseaux et systèmes. Leurs
missions au sein du SDIS sont :

• L’exploitation : gérer les sauvegardes, l’Active Directory et les serveurs.

• La gestion de projet : mener à bien le schéma défini par l’urbanisation du
système d’information.
• La gestion du déploiement : gérer le déploiement du réseau informatique sur
l’ensemble du département.
• La maintenance préventive : vérifier l’état des équipements et maintenir les
mises à jours logiciels et systèmes.
• La maintenance curative : prévoir l’achat du matériel…
• La gestion de l’architecture : faire des choix cohérents dans l’évolutivité et
maintenir une veille technologique.

8
 B. Présentation du réseau informatique

Chaque centre est relié à la direction par VPN. Les médias de raccordements
peuvent être la fibre optique, le SDSL (1 ou 2 MB) ou l’ADSL (512 KB) selon les
centres de secours. Les divers sites sont reliés au backbone MPLS d’Altitude
Télécom.

9
Il existe deux VLAN distincts du SDIS 64 : le VLAN administrateur et le VLAN Alerte.
Les données du VLAN Alerte sont prioritaires. Pour communiquer avec les centres
de secours, les données sont collectées par les routeurs de l’opérateur Altitude
Télécom, qui assure le routage vers les centres de secours. Le transport des
données est assuré par le MultiProtocol Label Switching (MPLS).
Les routeurs de la direction sont reliés au nuage MPLS par une fibre optique et une
liaison SDSL qui est une liaison de secours.

Le serveur de supervision sera situé au niveau de la direction et permettra une vision

interne du réseau, contrairement aux opérateurs extérieurs qui supervisent les
communications externes.

10
 C. Présentation du projet

Le Service Départemental d’Incendie et de Secours, au même titre que les autres

organisations de la sécurité civile, est un organisme très sensible car la vie des
victimes dépend de la réactivité des pompiers et de leur délai d’intervention. Pour
mieux comprendre en quoi la mise en place d’un serveur de supervision est
nécessaire voir indispensable aux administrateurs du GSI, il s’agira dans un premier
temps de comprendre comment fonctionne le système d’alerte des pompiers et, dans
un second, de montrer la dépendance de se système d’alerte avec la bonne santé du
réseau informatique du SDIS 64. Une dernière partie exposera les objectifs du projet.

Le système d’alerte des pompiers est un processus clairement définit. Il se

décompose de la manière suivante. Lorsqu’un témoin ou une victime compose le 18,
l’appel est reçu par le Centre de Traitement de l’Alerte (CTA), situé à la Direction du
Service Départemental d’Incendie et de Secours (DDSIS). L’appel est pris par un
opérateur qui collecte les informations nécessaires à l’intervention et les renseigne
dans un logiciel d’alerte. Les machines des opérateurs sont des stations Sun reliées
à un serveur Oracle 7 Solaris. Une fois le logiciel renseigné, le serveur envoie l’alerte
dans le centre de secours le plus proche temporairement du lieu de l’accident qui a
les moyens d’intervenir et les équipements appropriés. L’alerte est reçue dans le
Centre de Secours sur un PC dédié à l’Alerte. Si l’Alerte a bien été reçue, le
stationnaire en place dans le Centre de Secours doit acquitter l’Alerte pour signaler
au CTA le départ en intervention. Une fois l’intervention finie, le stationnaire le
signale au CTA. D’un point de vue technique, chaque Centre de Secours possède un
Equipement de Traitement de l’Alerte (ETA). Un ETA est un boîtier relié au PC Alerte
d’un côté et de l’autre, relié au serveur Oracle et donc au CTA par divers moyens de
transmissions : un récepteur radio, une RTC, une ligne ADSL et bientôt un serveur
de ligne. Un serveur de ligne permet de transformer une information qui arrive par
TCP/IP sur le port COM.

11
 Schéma Equipement du Traitement de l’Alerte

A l’heure actuelle, la majorité des alertes sont transmises par la ligne téléphonique
classique. Mais à terme, seul le serveur de ligne sera utilisé. L’envoi de l’alerte par
radio n’est utilisé qu’en cas de problème. D’ici deux ans l’alerte sera donc transmise
à l’ETA uniquement par le serveur de ligne. Les deux équipements critiques dans les
centres de secours sont donc le PC Alerte et le serveur de ligne. Ceux-ci sont reliés
au réseau et possède donc leur propre adresse IP. Toute l’utilité du projet de
supervision réside donc dans le fait de remonter la disponibilité de ces équipements
aux administrateurs et aux opérateurs du CTA. En effet, si le PC Alerte ou le serveur
de ligne ne sont plus joignables, il est nécessaire que le CTA soit immédiatement
averti afin de basculer l’alerte sur un autre moyen de communication (radio ou
téléphone).

Grâce à des logiciels tels que Nagios et Cacti, il est possible de visualiser en temps
réel l’état d’un équipement (UP ou DOWN), le trafic passant par ses interfaces, sa
disponibilité et surtout de remonter un dysfonctionnement afin d’intervenir quasi
instantanément. Ainsi, par exemple, lorsqu’un PC alerte ou un serveur de ligne ne
répond plus, l’information est directement relayée sur une interface graphique et par
un système de notification par mail ou SMS.
Dans le cadre du projet, les équipements à superviser sont dispersés sur l’ensemble
du territoire des Pyrénées-Atlantiques. L’idée est donc de mettre en place le serveur
de supervision et d’afficher les informations collectées sur une interface réactualisée
à intervalles réguliers. L’interface doit indiquer de façon explicite l’état des
équipements supervisés avec une vision géographique et permettre l’acquittement
des problèmes par les opérateurs du CTA. En effet, la carte des statuts des
équipements sera affichée sur un écran 42’’ sur la plateforme d’alerte du CTA où

12
24h/24 et 7j/7, les opérateurs sont présents. Le logiciel Nagios permet la génération
de cette carte et comprend un service de notification.

L’autre utilité du serveur de supervision est d’analyser la santé du réseau en

générant des graphiques sur trafic, l’utilisation des disques ou encore la charge des
CPU, par exemple. Ces fonctionnalités sont gérées par Cacti. La génération et
l’exportation des graphiques permettent donc d’analyser les statistiques relatives à
un équipement donné et ainsi prévoir l’évolution des besoins en terme de bande
passante ou de stockage si on reprend l’exemple précédent.

D. Les objectifs

• Découvrir les logiciels de supervisions disponibles en OpenSource.

• Proposer une solution de mise en place d’un serveur de supervision en tenant
compte des caractéristiques propres au SDIS 64.
• Installer et configurer le serveur ainsi que ces logiciels.
• Mettre en production le serveur de supervision.
• Rédiger un document généraliste à destination d’Internet afin de présenter les
deux dernières versions de Cacti et Nagios sur Debian ETCH.

13
 E. Planning des travaux

Le projet s’est décomposé en trois phases distinctes :

• Une phase de test

• Une phase de mise en production du serveur
• Une phase de rédaction du tutorial et du mémoire

La première phase consistait à la prise en main du projet et aux différents tests mis
en place sur machine virtuelle. Une fois le système stable, la phase de déploiement
sur le serveur de production a pu commencer. Il s’agit de la seconde phase du projet.
En plus de l’installation, cette phase comprend aussi la configuration des logiciels et
plugins.
Un des objectifs du projet étant de rédiger un document généraliste à destination
d’Internet, la fin du stage a été consacrée à cette partie.

14
GANTT du projet

15
III. Mise en place d’un serveur de supervision

A. Préparation du système

La mise en place d’un serveur de supervision, utilisant Cacti et Nagios va donc être
décrite, expliquée et analysée dans ce document.

1. Le choix de la distribution

A l’heure actuelle il existe de nombreux logiciels commerciaux de supervision

performants mais très onéreux. Une alternative libre est cependant possible, utilisant
une distribution Linux, un serveur LAMP et des paquets open source tel que Cacti et
Nagios, pour une supervision de réseau performante, modulable et à moindre frais.

Après comparatif des différentes distributions Linux, Debian a été retenu pour le
développement du serveur pour, entre autre, deux raisons : les paquets nécessaires
au déploiement du serveur de monitoring sont supportés par Debian et la richesse de
la documentation et la communauté est essentiellement francophone.

Debian GNU/Linux est donc une distribution Linux non commerciale, lancée en 1993.
Elle a pour principal but de fournir un système d’exploitation composé uniquement de
logiciel libre. Cette distribution contient environ 18 000 paquets logiciels élaborés et
maintenus par des milliers de développeurs. Debian est réputé pour sa fiabilité et son
gestionnaire de paquets (Apt et aptitude), au format de fichier .deb, permettant les
mises à jour et garantissant un système homogène.
Sur le serveur de production, Debian a été installé par sa version « netinst », qui
permet une installation via internet. La mise en place de Debian s’est faite dans sa
version minimale, aucune interface graphique et aucun module par défaut n’a été
installé. Ceci est volontaire afin d’optimiser l’utilisation des ressources et de maîtriser
la gestion des paquets installés.

2. Mise en place d’un serveur LAMP indispensable au fonctionnement de

Cacti et Nagios.

Avant d’expliquer l’installation du serveur LAMP (Linux, Apache, MySQL et PHP),

une mise au point sur la gestion de paquets sous Debian est nécessaire.

APT et maintenant APTITUDE sont les gestionnaires de paquets sous Debian. APT
simplifie l’installation, la mise à jour et la désinstallation de logiciels en automatisant
la récupération de paquets à partir de sources incluses dans la distribution ou
disponibles sur les miroirs Debian.
La commande d’installation d’APT est :

# apt-get install nom_du_paquet

APTITUDE est une alternative à APT. Fonctionnant sur le même principe,

APTITUDE permet en plus une meilleure gestion des dépendances entre les
paquets. La commande d’installation est :

# aptitude install nom_du_paquet

16
Les logiciels de supervisions nécessitent la mise en place d’un serveur LAMP. LAMP
est l’acronyme de Linux, Apache, MySQL et Php.
Linux qui assure l’attribution des ressources aux autres composants a été installé
préalablement. Apache est le serveur WEB. Il répond directement aux requêtes du
client web (en l’occurrence le navigateur). MySQL est un système de gestion de
bases de données. Il permet de stocker et d’organiser les données. Enfin, le langage
de script PHP permet la génération de pages web dynamiques et la communication
avec MySQL.

Cacti et Nagios, dont nous détaillerons l’installation plus tard, utilisent le serveur
LAMP. En effet, Apache permet l’affichage dans le navigateur des différents
graphiques ou autres composants. MySQL permet de créer la base de donnée
propre à chaque logiciel et de stocker les informations récupérées lors de la
supervision. Php permet d’afficher dynamiquement les informations stockées dans
les différentes bases de données dans le navigateur.

L’installation des paquets se fait en mode root/superutilisateur. Bien que l’ordre

d’installation des différents paquets ne soit pas fixe, il est préférable de suivre le
schéma ci-dessous enfin d’optimiser la gestion des dépendances :

# aptitude install apache2

# aptitude install php4 php4-mysql php4-snmp php4-gd
# aptitude install mysql-server

Le paquet php4-mysql permet de gérer les dépendances avec mysql

Les paquets php4-snmp et php4-gd sont nécessaires, leur utilité sera
expliquée ultérieurement.

Pour utiliser Cacti et Nagios, l’installation de SNMP et RRDTOOL est obligatoire.

SNMP (Simple Network Management Protocol) est le protocole de gestion de

réseaux proposé par l’IETF. Il est actuellement le protocole le plus utilisé pour la
gestion des équipements réseaux. SNMP est un protocole puissant qui permet une
gestion des réseaux hétérogènes complexes.
L’environnement de gestion SNMP est constitué de plusieurs composantes : la
station de supervision, les éléments actifs du réseau, les variables MIB et un
protocole.
• Les éléments actifs du réseau sont les équipements ou les logiciels que l’on
cherche à superviser. Cela va de la station de travail à un concentrateur, un
routeur, etc.
• Chaque élément du réseau dispose d’une entité dite agent qui répond aux
requêtes de la station de supervision. Les agents sont les modules qui
résident dans les éléments réseaux.
• La station de supervision (manager) exécute les applications de gestion qui
contrôlent les éléments réseaux : Cacti et Nagios
• La MIB (Management Information Base) est une collecte d’objets résidant
dans une base d’information virtuelle. Ces collections d’objets sont définies
dans des modules MIB spécifiques.
• Le protocole, permet à la station de supervision d’aller chercher les
informations sur les éléments de réseaux et de recevoir des alertes provenant
de ces mêmes éléments.

17
Le fonctionnement SNMP est basé sur un fonctionnement asymétrique. Il est
constitué d’un ensemble de requêtes, de réponses et d’un nombre limité d’alertes. Le
manager envoie des requêtes à l’agent, lequel retourne des réponses. Lorsqu’un
événement anormal surgit sur l’élément réseau, l’agent envoie une alerte (trap) au
manager. SNMP utilise le protocole UDP. Le port 161 est utilisé par l’agent pour
recevoir les requêtes de la station de gestion. Le port 162 est réservé au manager
pour recevoir les alertes des agents.
Les paquets SNMP et SNMPD sont donc indispensables à Cacti et surtout à Nagios
pour interroger les agents pour le premier et recevoir les TRAP pour le second.

Le second paquet indispensable est RRDTOOL. Surtout utilisé par Cacti, RRDTOOL
est une suite d’outils permettant de stocker des données, sous un format « .rrd », de
les restaurer et d’afficher un graphique avec ces données.

Pour achever la préparation de l’environnement nécessaire à Cacti et Nagios, il faut

donc installer les paquets SNMP, SNMPD et RRDTOOL :

#aptitude install snmp snmpd

#aptitude install rrdtool

Le système est maintenant apte à recevoir et à faire fonctionner Cacti et Nagios.

Pour plus de confort pour la suite de la procédure d’installation, l’installation du
paquet Webmin n’est pas indispensable mais fortement conseillée.
Webmin est une interface graphique qui permet d’administrer un serveur Linux à
distance via un navigateur web. Il sera donc plus aisé de gérer les problèmes de
MySQL et de droits.

18
 B. Cacti

Cacti est un logiciel de supervision basé sur RRDTOOL, permettant de surveiller

l’activité d’une architecture informatique à partir de graphiques quotidiens,
hebdomadaires, mensuels et annuels. Cette solution n’est donc pas destinée à
alerter en temps réel sur les dysfonctionnement d’un système mais bien de proposer
une vision dans le temps d’indicateurs matériels et logiciels (trafic réseau, volumes
des disques, temps de réponses, etc,.). Les dysfonctionnements seront remontés par
Nagios qui sera abordé plus tard.
Cacti permet donc une vision graphique de l’activité des agents réseaux. Cacti est
par ailleurs très évolutif grâce à ses différents plugins. L’installation et l’utilisation des
plugins NTop, WeatherMap et Syslog seront expliqués ensuite.

1. Installation

Cacti est un paquet inclus par défaut dans la distribution Debian. Lors de la rédaction
de ce mémoire, c’est la version 0.8.6i qui est distribuée. Le télécharger s’effectue
avec la commande :

#aptitude install cacti

Un message peut apparaître, indiquant qu’il manque certaines librairies. Dans ce

cas, l’installation des librairies manquantes est indispensable :

#aptitude install librairie1 librairie2 librairie3

Une fois les librairies manquantes installées, le re-téléchargement du paquet Cacti

est nécessaire.

Lors du téléchargement, un écran de configuration automatique apparaît. Il faut

renseigner le serveur web: Apache2 puis refuser la création automatique d’une base
de donnée Cacti. Cette partie sera effectuée par la suite manuellement.

Une fois le paquet téléchargé et installé, il faut procéder à la configuration de Cacti.

2. Configuration

Tout d’abord, la création d’un utilisateur Cacti doit se faire en mode superutilisateur :

# adduser cacti

Il faut ensuite créer une base de donnée avec MySQL afin que Cacti puisse stocker
les informations récoltées :

#mysqladmin –user=root create cacti

La base étant créée, il faut maintenant attribuer tous les privilèges à l’utilisateur afin
que Cacti puisse créer, supprimer et modifier les données stockées dans la table :

19
#mysql –u root –e ”grant all privileges on cacti.* to cacti@localhost identified by
‘cacti’; flush privileges;“

Il arrive que cette commande n’attribue pas réellement tous les droits à l’utilisateur.
Afin de le vérifier, il faut se connecter à Webmin via le navigateur en rentrant
l’adresse https://ip_serveur:10000/ (attention au httpS). Dans la rubrique serveur,
aller dans MySQL Database Server puis dans Users Permissions. En cliquant sur
l’utilisateur Cacti, ses permissions apparaissent. S’il n’a pas toutes les permissions, il
faut lui attribuer puis sauvegarder.

L’utilisateur Cacti a désormais toutes les permissions. Il faut désormais appliquer le

modèle des tables de Cacti à la nouvelle base de donnée de Cacti :

# zcat /usr/share/doc/cacti/cacti.sql.gz | mysql –u cacti –password cacti cacti

Si le chemin de cacti.sql.gz n’est pas le bon, il faut rechercher l’archive :

# updatedb&
# locate cacti.sql.gz

Maintenant que la base de donnée Cacti est créée et renseignée, il faut indiquer à
Cacti comment se connecter à la base de donnée. Pour cela, il faut éditer le fichier
/usr/share/cacti/site/include/config.php et renseigner les lignes suivantes de cette
manière :

$database_type = « mysql » ;
$database_default = «cacti » ;
$database_hostname = « localhost » ;
$database_username = « cacti » ;
$database_password = « cacti » ;
$database_port = « 3306 » ;

Si ces lignes ne sont pas présentes, il faut éditer le fichier indiqué après le ‘require’.
Ce fichier est sans doute /etc/cacti/debian.php .

La configuration concernant la base de donnée est terminée. Il faut maintenant

indiquer à php de communiquer avec mysql. Pour cela il faut éditer les fichiers
/etc/php4/apache2/php.ini et /etc/php5/apache2/php.ini et décommenter les lignes
contenant ‘extension=mysql.so’

Il faut désormais redémarrer Apache pour que les modifications soient prises en
compte :

# /etc/init.d/apache2 restart

Cacti est maintenant prêt à l’emploi. On y accède via un navigateur web à l’adresse
http://ip_serveur/cacti/ . Le login et mot de passe par défaut sont ‘admin’.

20
Attention

• Il arrive que le message « Warning …Access denied » apparaisse. Ceci

signifie que l’utilisateur n’a pas les droits requis. Pour résoudre ce problème
temporairement il faut donner les droits d’écriture, d’exécution et de lecture à
tous avec la commande :

# chmod 777 /usr/share/cacti –R

Une fois Cacti en place, il est vivement conseiller de re-limiter les droits.

• Un second problème concerne l’identification lors des premières connexions.

Si le mot de passe ne fonctionne pas il faut le réinitialiser avec la commande :

# update user_auth set password = md5 (‘newpassword’) where

username = ‘admin’ ;

21
 3. Utilisation

Cacti étant installé et configuré, il faut le tester. Voici les instructions et les captures
d’écran pour superviser un équipement contenant un agent snmp.

Tout d’abord, il faut créer un ‘device’. Pour cela après avoir cliqué sur ‘Device’
(onglet dans le menu à gauche) puis sur Add, cette page apparaît :

Là, il faut renseigner ‘Description’, ‘Host name’, ‘Host template’ et la ‘SNMP

Community’ puis cliquer sur ‘create’.

Une fois le ‘device’ créé il faut créer les graphiques en cliquant sur ‘Create graph for
this host’ (en haut à droite). Différents choix de graphiques sont disponibles :

22
Une fois les graphiques créés, attendre 10 minutes pour voir les premiers résultats
en cliquant sur l’onglet ‘graphs’.

Cette capture d’écran montre la charge du CPU d’un routeur ainsi que le trafic
réseau à travers son interface Fast Ethernet 1/0/3.
Cacti peut générer des graphiques sur l’ensemble des équipements possédant le
protocole SNMP.

Voici des graphiques sur la charge du CPU, le trafic de la carte réseau et du disque
C : sur un PC XP Pro :

Cacti propose de multiples manières de trier les graphiques et d’effectuer des

recherches.
L’évolution du logiciel est très importante car il est possible à chacun de se créer ses
propres modèles graphiques. Mais ceci ne sera pas traité dans ce document, car
c’est une partie développement et programmation.
23
L’installation et la prise en main étant effectuées, il s’agit maintenant de s’intéresser
aux plugins de Cacti qui font parties intégrantes du projet.

24
 C. Plugins Cacti

Une des grandes forces de Cacti est sa capacité d’utiliser d’autres outils dans des
plugins intégrés à son interface. L’avantage est alors de gérer plusieurs logiciels sur
la même plateforme. Pour ce projet, les plugins NTOP, WeatherMap et Syslog seront
décrits.

Avant de commencer l’installation des plugins, il faut préparer le système à les

recevoir. Pour cela, l’installation du plugin appelé « architecture » est requis. Chaque
version de Cacti a son plugin « architecture » dédié. Ici, il faut utiliser le plugin cacti-
plugin-arch-1.1 pour la version Cacti 0.8.6i. Ce plugin est disponible sur le site
caciusers.org. Une fois téléchargé, le décompresser :

#tar –xvf /home/user/Desktop/cacti-plugin-arch.tar.gz

Puis il faut déplacer les fichiers décompressés dans le site Cacti.

#cp /home/user/Desktop/cacti-plugin-arch/* /usr/share/cacti/site/ -R

#cd /usr/share/cacti/site
#patch –p1 –N < cacti-plugin-0.8.6i.diff

Le Cacti est maintenant prêt à recevoir les plugins NTop, WeatherMap et Syslog.

1. Syslog

Syslog (anciennement Haloe) est un plugin très intéressant car il permet de lire les
logs dans l’interface web de Cacti. L’avantage est qu’il est possible de trier, classer
ou supprimer des logs ainsi que de déclencher des alertes.
Syslog se présente de cette manière :

25
Pour l’installer, télécharger le plugin. Dans le dossier contenant l’archive, entrer la
commande suivante :

# tar -xvf /home/user/Desktop/haloe-0.4.tar.gz

Puis copier le dossier haloe dans le dossier /usr/share/cacti/site/plugins/

# cp /home/user/Desktop/haloe /usr/share/cacti/site/plugins/ -R

Éditer le fichier /usr/share/cacti/site/include/config.php et ajouter juste après la ligne

commençant par "$plugins = array();":

$plugins[] = ‘haloe’;

Attention, si le paquet syslog-ng n’est pas installé et paramétré sur le système, le

plugin Syslog ne fonctionnera pas. Ce paquet permet de récupérer les log du
système et de les insérer dans une base de donnée.

Pour activer le plugin, il faut se connecter sur l’interface Cacti -> cliquer sur l'onglet
console -> cliquer sur "User Management" dans le section "Utilities" -> cliquer sur un
utilisateur -> activer la case "View Syslog".

26
 2. NTOP

Le second plugin installé est NTOP. Cet outil permet de fournir des statistiques sur
l’utilisation du réseau. Il analyse les paquets qui transitent sur le réseau et le serveur.
Il se présente de cette manière :

27
Ou encore :

Avant d’installer le plugin NTOP, il faut installer le paquet NTOP sur le système :

# aptitude install ntop

Il faut ensuite télécharger le plugin et le décompresser :

#tar -xvf /home/user/Desktop/ntop-0.1.tar.gz

Puis copier le dossier ntop dans le dossier /usr/share/cacti/site/plugins/ :

# cp /home/user/Desktop/ntop /usr/share/cacti/site/plugins/ -R

Il s’agit ensuite comme pour les autres plugins d’éditer le fichier

/usr/share/cacti/site/include/config.php et d’ajouter juste après la ligne commençant
par "$plugins = array();":

$plugins[] = ‘haloe’;

Il est maintenant nécessaire de démarrer ntop grâce à cette commande :

# ntop -u user -w 3000

Puis d’activer le plugin en se connectant à l’interface de Cacti, en cliquant sur l'onglet

console -> puis sur "User Management" et dans le section "Utilities" -> en cliquant
sur un utilisateur -> en activant la case "View NTop".

28
 3. WeatherMap

Enfin le dernier plugin installé est Weathermap. Weathermap est un outil

particulièrement utile qui génère des cartes graphiques pour mesurer les bandes
passantes (en pourcentage ou en absolu) des liens du réseau.
Les cartes montrent alors si il existe des goulots d'étranglements sur le réseau et
ainsi permettre la gestion de l’évolution des besoins.
Pour mesurer la bande passante des liens réseaux, PHP Weathermap utilise des
fichiers de type rrd.
Lors de la rédaction du document, la partie configuration du Weathermap n’était pas
achevée, ainsi seuls quelques serveurs apparaissent sur cette capture d’écran :

Comme pour les autres plugins, Weathermap suit la même procédure d’installation.
Pour l’installer, télécharger le plugin. Dans le dossier contenant l’archive, entrer la
commande suivante :

# tar -xvf /home/user/Desktop/php-weathermap-0.82.zip

Puis copier le dossier weathermap dans le dossier /usr/share/cacti/site/plugins/

# cp /home/user/Desktop/weathermap /usr/share/cacti/site/plugins/ -R

Éditer le fichier /usr/share/cacti/site/include/config.php et ajouter juste après la ligne

commençant par "$plugins = array();":

$plugins[] = ‘’weathermap’;

29
Puis activer le plugin en se connectant à l’interface de Cacti, en cliquant sur l'onglet
console -> puis sur "User Management" et dans le section "Utilities" -> en cliquant
sur un utilisateur -> en activant la case "Weathermap".

30
 D. Nagios

1. Présentation

Après avoir expliqué et détaillé l’installation et le fonctionnement de Cacti, ainsi que

de ses plugins, nous allons voir la partie Nagios, qui est le cœur du projet. Nagios est
un outil de supervision libre. Il est disponible sous Licence GNU GPL.
La principale fonctionnalité de Nagios est d’indiquer l’état d’un élément du réseau, et
de remonter les problèmes aux administrateurs par systèmes de notifications. Les
notifications peuvent être remontées de différentes façons, qui vont du mail au SMS.
Nagios repose sur un serveur web et des CGI. Avant la version 3.0, Nagios utilisait
un système de base de données. Ce système a été abandonné par les développeurs
et a été remplacé par des fichiers tournants. Il est cependant toujours possible de
venir greffer une base de donnée au serveur, comme le montre le schéma ci-
dessous, mais ceci n’est pas indispensable. L’architecture standard de Nagios est
donc représentée de cette manière :

Architecture de Nagios

Nagios est très performant mais sa configuration est délicate. En effet, il est
nécessaire de manipuler une multitude de fichiers de configuration pour le
paramétrer correctement et communiquer avec les CGI. A la moindre erreur, Nagios
ne démarre pas. Cependant, avec un travail méticuleux et une bonne préparation
préalable permettent d’éviter les problèmes.
Sur le schéma, on constate la présence de plugins entre le cœur du système Nagios
et les hôtes à superviser. Les plugins sont des programmes exécutables ou des
scripts (perl, shell, etc..) qui sont lancés par le système pour tester l’état d’un hôte ou
d’un service. Pour le SDIS, c’est le plugin « check_ping » qui sera utilisé. De cette
manière, le Nagios « pingera » à intervalles réguliers les PC alertes, les serveurs de
lignes et les routeurs de chaque centre dans le département et signalera à
l’administrateur lorsqu’un hôte ne répond pas.
L’ensemble des états des hôtes et des services est recensé sur des tableaux de
bord, où chaque hôte et chaque service sont classés par groupe. Une rubrique carte
des statuts « StatusMap » permet d’afficher géographiquement ou spatialement les
hôtes ainsi que leur statuts. Cette fonctionnalité est particulièrement intéressante,
car c’est avec ceci que sera affiché la carte du département sur l’écran 42’’ situé sur
la plate-forme d’alerte.
Après cette présentation, il s’agira dans un premier temps d’expliquer l’installation et
la configuration de Nagios et d’en un second d’expliciter son fonctionnement.

31
 2. Installation

Le paquet Nagios n’est pas inclus par défaut dans la distribution Debian. Il faut tout
d’abord le télécharger. La version Nagios 3.0rc1 est disponible sur Nagios.org ou sur
SourceForge.net.
Avant de commencer l’installation proprement dite de Nagios, il faut régler quelques
problèmes de dépendances. L’installation des librairies libgd2-dev et libgd2-xpm-dev
sont nécessaires :

#aptitude install libgd2-dev libgd2-xpm-dev

Si le compiler « GNU Compiler Collection » (GCC) n’est pas installer sur le serveur il
faut l’installer. Les fichiers de Nagios étant compilés en C, le GCC est indispensable
pour le fonctionnement du système :

# aptitude install gcc

# install make

Le dernier point avant de débuter l’installation concerne la création d’un utilisateur et

d’un groupe Nagios :

# groupadd nagios
# adduser nagios

Le système est maintenant prêt à recevoir Nagios. La phase d'installation suit les
étapes suivantes. Tout d’abord il faut décompresser l’archive :

# tar xzf nagios-3.0rc1.tar.gz

Puis il faut passer à la compilation, avec les options choisies :

# ./configure - -with-command-group=nagcmd
# make all

Quand la compilation est terminée sans erreur, on peut passer à l'installation :

# make install

Pour rendre Nagios complètement opérationnel, il reste quelques commandes à

passer :
Installer le script de démarrage de Nagios /etc/init.d/nagios

# make install-init

32
Créer et mettre les droits sur le répertoire qui va contenir les fichiers de
communication entre le serveur Nagios et les CGI de présentation

# make install-commandmode

Installer un exemple de configuration de Nagios. Les fichiers de configuration ainsi

créés verront leur nom se terminer par -sample, pour éviter ainsi d'écraser la
configuration actuelle en cas d'upgrade

# make install-config

L'installation de Nagios est alors terminée. Il faut maintenant passer à la phase

d’installation des plugins qui permettront de « checker », les hôtes. Pour la version
3.0rc1 de Nagios, l’utilisation du nagios-plugins-1.4.11 fonctionne.

Après extraction :

# tar xvf nagios-plugins-1.4.11.tar.gz

La compilation peut démarrer :

# ./configure - -with-nagios-user=nagios - -with-nagios- -group=nagios

Puis l’installation:

# make install

L’installation du Nagios est désormais complète. Il faut maintenant le configurer.

33
 3. Configuration

Afin d’établir la communication entre Nagios et le serveur web il faut rajouter les
lignes suivantes dans le fichier httpd.conf. Pour le localiser utiliser la commande : find
/ -name httpd.conf.

ScriptAlias /nagios/cgi-bin /usr/local/nagios/sbin

<Directory "/usr/local/nagios/sbin">
Options ExecCGI
AllowOverride None
Order allow,deny
Allow from all
AuthName "Nagios Access"
AuthType Basic
AuthUserFile /usr/local/nagios/etc/htpasswd.users
Require valid-user
</Directory>

Alias /nagios /usr/local/nagios/share

<Directory "/usr/local/nagios/share">
Options None
AllowOverride None
Order allow,deny
Allow from all
AuthName "Nagios Access"
AuthType Basic
AuthUserFile /usr/local/nagios/etc/htpasswd.users
Require valid-user
</Directory>

Puis redémarrer le serveur Apache :

# /etc/init.d/apache2 reload // redémarrage d'Apache2

Ces lignes permettent d’autoriser l’affichage de Nagios. Après définition du droit

d’accès avec cette commande, il est possible d’accéder à l’interface de Nagios :

# htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

(Adapter le chemin du htpasswd.users au système)

Pour accéder au Nagios : http://ip_serveur/nagios/.

Si Nagios ne peut pas démarrer : il faut utiliser les fichiers de configuration livrés pour
l’exemple et redéfinir les droits :

# cp -R /tmp/nagios3.0rc1/sample-config /usr/local/nagios/etc
# chown -R nagios.nagios /usr/local/nagios/etc
# chmod 755

34
Le dernier point concernant l’installation, concerne le module « StatusMap » qui est
un élément principal du projet. Il est possible que le StatusMap ne fonctionne pas
après l’installation de Nagios. Ceci est soit dû à l’absence d’une librairie soit à une
mauvaise configuration de base. Si le StatusMap ne fonctionne pas il faut suivre ces
directives pour palier aux problèmes.
Tout d’abord, vérifier si la librairie libgd-dev est installée. Si ce n’est pas le cas :

#aptitude install libgd-dev

Ensuite vérifier dans les fichiers /etc/php4/apache2/php.ini et/ou

/etc/php5/apache2/php.ini que la ligne contenant « gd.so » n’est pas commentée. Si
cette ligne est commentée, le serveur web ne peut pas afficher les modules
graphiques utilisant les bibliothèques GD.

Enfin, il faut re-confectionner les CGI et les déplacer dans le Nagios :

# cd /tmp/nagios-2.9
# make devclean
# ./configure --with-gd-lib=/usr/lib --with-gd-inc=/usr/include
# make cgis
# cd cgi
# cp *.cgi /usr/local/nagios/sbin

Le StatusMap devrait fonctionner correctement après redémarrage.

Nagios est maintenant installé et sa configuration peut commencer.

La configuration de Nagios repose sur plusieurs fichiers comportant l’extension .cfg :

nagios.cfg, cgi.cfg et une multitude de fichiers définissant les hôtes, les services ou
encore les contacts.
Le fichier principal de configuration de Nagios est le fichier
/user/local/nagios/etc/nagios.cfg. Ce fichier est lu à la fois par le processus Nagios et
par les CGI. Il définit les chemins des autres fichiers de configurations ainsi que les
options relatifs au fonctionnement de Nagios et des extensions.

35
Dans ce fichier il faut dé-commenter et éditer les lignes suivantes afin d’obtenir ceci:

log_file=/usr/local/nagios/var/nagios.log

cfg_file=/usr/local/nagios/etc/objects/commands.cfg
cfg_file=/usr/local/nagios/etc/objects/contacts.cfg
cfg_file=/usr/local/nagios/etc/objects/timeperiods.cfg
cfg_file=/usr/local/nagios/etc/objects/templates.cfg

resource_file=/usr/local/nagios/etc/resource.cfg

status_update_interval=60

nagios_user=nagios

nagios_group=nagioscmd

check_external_commands=1

command_file=/usr/local/nagios/var/rw/nagios.cmd

external_command_buffer_slots=4096

Il faudra aussi rajouter autant de cfg_file qu’il y a de groupe ou de type d’hôte. Les
définitions d’hôtes et de groupes peuvent être soit condensées dans un fichier
unique ou ils peuvent être éclatés en plusieurs .cfg .
Les autres lignes du document ne seront pas éditées sauf si un problème survient.

Le second fichier de configuration est le cgi.cfg . Ce fichier définit les options pour
que le Nagios communique avec les CGI. Ceci comprend les options du StatusMap,
les sons, les liens URL mais aussi des autorisations les différents utilisateurs. Dans
le cadre du projet, il n’y a qu’un seul administrateur de Nagios, nagiosadmin. Le
second point à modifier concerne les paramètres du StatutMap. Mais l’édition du
code sera décrite plus tard.

Les derniers points de configuration, concernent les fichiers commands.cfg,

contacts.cfg, timeperiods.cfg, templates.cfg et les différents fichiers hôtes.cfg.

Pour faciliter la compréhension de la configuration, l’explication sera développée

autour d’un exemple. Comme c’est le cas dans le projet, la supervision dans cet
exemple concernera un routeur. Ce routeur sera pingé toutes les cinq minutes et en
cas de problème, un système de notifications enverra un mail à l’administrateur
principal du réseau et si celui-ci n’acquitte pas le problème dans les 10 minutes, le
mail sera envoyé au second administrateur du réseau. Ce service est appelé
« escalation ».

36
Tout d’abord il faut créer les personnes à contacter en cas de problèmes. Celles-ci
sont contenues dans le fichier contacts.cfg. Les deux contacts seront administrateur1
et administrateur2.

define contact {
contact_name administrateur1
use administrateur-contact
alias Administrateur Principal
service_notification_commands notify-service-by-email
host_notification_commands notify-host-by-email
email administrateur1@mail.fr
}

define contact {
contact_name administrateur2
use administrateur-contact
alias Administrateur Secondaire
service_notification_commands notify-service-by-email
host_notification_commands notify-host-by-email
email administrateur2@mail.fr
}

Les deux contacts sont définis comme administrateur1 dont l’alias est Administrateur
Principal et administrateur2 dont l’alias est Administrateur Secondaire. Les contacts
utilisent le modèle « administrateur-contact » qui est un modèle de base renseigné
dans le fichier templates.cfg. En cas de problème sur un service (ping, snmp…) ou
sur un hôte (routeur qui ne répond pas), on définit que les contacts doivent être
contactés par mail : notify-service-by-email et notify-host-by-email. Ces notifications
sont définies dans le fichier commands.cfg.

Les deux contacts étant créés, il faut maintenant définir un ou des groupes. Chaque
contact doit appartenir à un groupe. Contrairement aux anciennes versions de
Nagios, la définition des groupes se fait dans contacts.cfg, à la suite de la définition
des contacts.

define contactgroup {
contactgroup_name admins
alias Nagios Administrateurs
members administrateur1, administrateur2
}

Le groupe s’appelle admins, son alias pour l’interface Web est Nagios
Administrateurs.

Les contacts et leurs groupes étant créés, il faut maintenant définir les hôtes et leurs
groupes, en l’occurrence un routeur appelé « Cisco 1 » dont l’adresse IP est
192.168.1.1 et appartenant au groupe « Réseau Interne Entreprise». A cela se
rajoute la définition du service. Dans l’exemple, il s’agit d’un service PING. Les hôtes
seront définis dans le fichier routeur.cfg qu’il faut créer soit même dans
/usr/local/nagios/etc/objects/. La définition des hôtes, des groupes et des services

37
suit la même logique que pour contacts.cfg, on renseigne d’abord les hôtes puis les
groupes et enfin les services dans le même fichier.

define host {
use generic-router
host_name cisco1
alias Cisco 1
address 192.168.1.1
hostgroups reseau-interne
}

L’hôte Cisco est maintenant créé, il utilise le modèle « generic-router » définit dans
templates.cfg.

define hostgroup {
hostgroup_name reseau-interne
alias Réseau Interne Entreprise
}

Le groupe « Réseau Interne Entreprise » est désormais créé. Il reste maintenant à

définir le ou les services qu’il faut appliquer à l’hôte Cisco 1.

define service {
use generic-service
host_name cisco1
service_description PING
check_command check_ping!200.0,20%!600.0,60%
normal_check_interval 5
retry_check_interval 1
}
Le service utilise le modèle « generic-service » et il est appliqué au routeur
« cisco1 ». Ce service est de type Ping. Il interroge Cisco1 toutes les 5 minutes et s’il
n’y a pas de réponse, toutes les minutes. Si c’est un serveur qui avait été supervisé,
il aurait été possible grâce au protocole SNMP, d’interroger les tailles de disques,
charge du CPU ou encore la température du système.

38
La mise en place d’un service « escalation » est nécessaire pour que la notification
suive un parcours particulier s’il n’y a pas d’acquittement ou de résolution du
problème dans un temps donné. C’est aussi dans ce fichier qu’il faut l’indiquer.

define hostescalation {
host_name cisco1
contact_name administrateur1
first_notification 0
last_notification 2
notification_interval 5
}

define hostescalation {
host_name cisco1
contact_name administrateur2
first_notification 3
last_notification 10
notification_interval 5
}

Dans l’exemple, administrateur1 est le premier à recevoir la notification

« first_notification 0 ». On définit que la notification sera renouvelée après 5
minutes « notification_interval 5 » et que si au bout de 2 notifications (soit 10
minutes) il n’y a pas eu d’acquittement ou résolution de problème, la notification
passe au second contact administrateur2 : pour administrateur1 « last_notification
2 » et pour administrateur2 « first_notification 3 ». Il est ainsi possible de définir
autant d’ « escalation » qu’il y a de contacts ou de groupe de contacts et jouer sur les
intervalles d’envoi de mail.

La définition de l’hôte est maintenant terminée. Il reste un dernier fichier à modifier, le

templates.cfg qui permet de générer des modèles à appliquer aux différents hôtes.
Dans ce fichier, sont contenus les modèles génériques pour les contacts, les hôtes et
les services. Ce fichier n’est pas indispensable, car les paramètres renseignés dans
les génériques peuvent être appliqués indépendamment à chaque hôte, contact ou
service. Ce fichier est quand même utile afin d’éviter de recopier sans cesse les
mêmes informations dans les fichiers de configurations.

Voici un exemple de contact générique :

define contact {
name administrateur-contact
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,c,r,f,s
host_notification_options d,u,r,f,s
service_notification_commands notify-service-by-email
host_notification_commands notify-host-by-email
register 0
}

39
Le contact générique définit que l’utilisateur recevra les notifications des services et
des hôtes par mail pour les événements, 24h sur 24 et 7 jours sur 7 lorsqu’un service
est en état « w : warning, u : up, c : critical, r : recovery, f : flapping et s : scheduled »
ou que l’hôte est en état « d : down, u : up, r : recovery, f : flapping et s : scheduled ».

Les hôtes et services génériques sont définis sur le même modèle avec des
paramètres propres.

Le dernier fichier qui peut-être modifié est le timeperiods.cfg. Ce fichier permet de

définir les heures et les jours de travail et les périodes auxquelles il faut contacter les
différents contacts.

Pour achever la configuration, il faut indiquer au système de lire le fichier de

configuration routeur.cfg en insérant une ligne dans le fichier nagios.cfg :

cfg_file=/usr/local/nagios/etc/objects/routeur.cfg

Il faut désormais redémarrer le Nagios avec la commande :

# /ect/init.d/nagios restart

Le Nagios est maintenant démarré et prêt à la production. La page d’accès à

l’interface se fait à l’adresse http://ip_serveur/nagios/. Le mot de passe et l’utilisateur
sont alors demandés. Dans ce document il s’agit de utilisateur=nagiosadmin et mot
de passe = nagiosadmin.

40
 4. Utilisation de Nagios

L’installation et la configuration de Nagios sont désormais effectives. La mise en

production peut démarrer. A terme le serveur supervisera environ 60 routeurs, 60
machines alertes et serveurs de lignes ainsi qu’une dizaine de serveurs. Pendant la
rédaction de ce document, seul 50 routeurs et 8 serveurs de lignes sont supervisés.
Les différentes captures d’écran sont issues du Nagios mis en place au sein du SDIS
64.

Le Nagios est accessible à l’adresse http://ip_serveur/nagios/

La page d’accueil peut être personnalisée, car contrairement aux autres rubriques
qui sont des CGI, cette page est en HTML. Le menu de gauche est le cœur de la
navigation de Nagios. Il est divisé en quatre parties :

• General : qui permet d’accéder à la page d’accueil et à la documentation

• Monitoring : qui permet d’accéder à l’ensemble des hôtes et des services en
cours de supervisions. Les différentes rubriques permettent de visualiser l’état
des hôtes et des services individuellement ou en groupes. Cette partie permet
aussi d’accéder au « Status Map », élément majeur du projet.
• Reporting : qui permet de générer des rapports sur les alertes, les logs, les
notifications ou encore la disponibilité des éléments supervisés.
• Configuration : cette partie permet de visualiser la configuration du Nagios,
mais ne permet pas de la modifier.

41
Les capacités de Nagios sont très vastes, ainsi ce document ne présentera que les
principales rubriques utilisées durant le projet.

La première rubrique est le tableau de bord du Nagios, qui permet d’avoir une vue
générale des éléments supervisés.

Tactical Overview Monitoring

Le « Tactical Overview Monitoring » donne une vision générale de l’état des hôtes et
des services. Il est possible de détailler les services et les hôtes individuellement ou
par groupe.
Pour cette présentation de Nagios, seul le cas des hôtes, en l’occurrence les
routeurs, sera détaillé. Les différentes catégories sont identiques pour les services.

Pour résumer, il y a trois niveaux de visions des hôtes : « Host Group » (lui-même
divisé en trois), « Host Detail » et « Host ».

Les niveaux « Host Group » permettent d’avoir une vision des hôtes en les classant
en groupes définis dans configuration. C’est une vision plus précise que le « Tactical
Overview Monitoring » mais qui donne moins d’informations que le « Host Detail ».

42
 Host Group Overview

La catégorie « Host Detail » permet de rentrer plus dans les détails, en précisant
pour chaque hôte, le statut, l’heure et la date du dernier « ping » ainsi que des
informations supplémentaires sur le statut.

Host Detail
43
On constate sur cette capture d’écran que deux routeurs ne répondent pas : routeur-
bedous et routeur-iholdy sont « DOWN ». Cependant l’icône indique que le
problème a été acquitté par l’administrateur et que le problème est en cours de
résolution.

Le dernier niveau de visualisation des hôtes est l’hôte lui-même. C’est ici que
l’administrateur peut acquitter un problème, reprogrammer un test de l’état de l’hôte,
envoyer des notifications ou encore ajouter des commentaires.

Host Routeur Bedous

Cet exemple montre l’état du routeur situé à Bedous dont l’adresse IP est
192.168.10.190. Cette page permet de fournir de nombreuses informations sur
l’hôte : son état, l’heure du dernier « check », la date du dernier changement d’état,
ainsi que l’état des différents services. La rubrique « Host commands » située à
droite de l’écran permet de gérer les actions sur l’hôte. Enfin la rubrique « Host
Comments », située en bas, indique les messages que l’administrateur a renseignés
pour l’hôte.

Ces différentes pages recensent donc les informations relatives aux hôtes et
permettent en quelques clicks d’avoir une vue de l’état général de chacun un d’eux.
Une autre possibilité est intégrée dans le Nagios : la « Status Map ». Cette carte
permet de visualiser géographiquement l’état d’un hôte. La mise en place de cette
carte est un élément majeur du projet. En effet, la possibilité d’afficher une carte du
département recensant l’ensemble des routeurs, des Pc alertes ou des serveurs de
lignes ainsi que leur état est une plus value importante pour la vision générale et

44
l’intervention lors d’un problème. La configuration de la « Satus Map » va donc être
expliquée.

Il existe des « Status Map » par défaut intégrés dans le Nagios, qui placent les hôtes
aléatoirement. Cependant une fonctionnalité permet de choisir un fond de carte, de
définir les coordonnées d’un hôte et lui appliquer une icône. Pour configurer cette
« Satus Map » personnalisée, il faut éditer le fichier de définition des hôtes. Si l’on
reprend l’exemple de configuration expliquée précédemment, ce fichier est
/usr/local/nagios/etc/objects/routeur.cfg.

Dans la partie de définition de l’hôte, il faut rajouter les suivantes :

2d_coords abscisse,ordonnée
statusmap_image icone.png

Ainsi par exemple :

define host {
use generic-router
host_name cisco1
alias Cisco 1
address 192.168.1.1
hostgroups reseau-interne
2d_coords 250,300
statusmap_image router.png
}

Une fois ce fichier édité, il faut indiquer au fichier de configuration des CGI, la
modification. Pour cela il faut éditer le fichier /user/local/nagios/etc/cgi.cfg et
s’assurer que les lignes suivantes sont identiques :

statusmap_background_image=fond_de_carte.png
default_statusmap_layout=0

La première ligne indique le nom du fond de carte qui doit être contenu dans le
dossier /user/local/nagios/share/images/ et qui doit être au format .gd ou .png.
La seconde ligne permet d’indiquer au système d’utiliser les coordonnées
renseignées dans les fichiers de configuration et non les coordonnées par défaut.
Une fois l’édition terminée, redémarrer le Nagios.

Cette carte représente le département des Pyrénées-Atlantiques avec une

disposition géographique des routeurs sur l’ensemble des centres de secours du
SDIS. Comme son nom l’indique, cette « Status Map » montre le statut des hôtes.
Lorsqu’un hôte ne répond pas, son icône est entourée d’un cercle rouge.
Cette carte est un point majeur du projet, car elle permet à une personne n’ayant pas
de connaissances informatiques, comme c’est le cas des opérateurs du CTA, de
savoir quand il y a un problème sur le réseau, et ainsi basculer l’alerte par radio ou
téléphone.

45
« Status Map » complète des routeurs du réseau du SDIS 64 (2000x1500 pixels)

46
 « Status Map » dans le navigateur

Pour terminer avec cette présentation de l’utilisation de Nagios, il faut s’intéresser à

la partie « Reporting ». Nagios, en plus de donner l’état des hôtes et des services,
permet d’exporter une multitude de données sous forme graphique ou texte.
Volontairement, cette partie ne sera pas plus développée car elle est en de
nombreux points similaires à Cacti.
Les deux seules catégories du « Reporting » qui seront traitées brièvement sont
« Notifications » et « Event log ».

47
La page « Notifications » recense l’ensemble des notifications transmises aux
utilisateurs sur des intervalles donnés.

La page « Event Log » donne, quant à elle, l’ensemble des logs du Nagios heure par
heure.

48
La présentation d’installation, de configuration et d’utilisation de Nagios est
désormais terminée.
En utilisant un navigateur web et des CGI, Nagios est assez souple dans son
exploitation. Cependant la configuration doit être minutieusement préparée. En effet,
à la moindre erreur, dans un des fichiers cfg, Nagios ne démarre pas. Il faut donc
prendre le temps d’établir un plan de supervision, ne pas hésiter à créer et utiliser
des templates, et bien regrouper en groupe les hôtes.

Après avoir présenté le projet dans son ensemble puis les solutions mises en œuvre
que sont Cacti et Nagios, il s’agit maintenant de s’attarder sur l’évolutivité de se
projet notamment au niveau de la mise en forme.

49
IV. Continuité du projet

A. Tâches restantes

A la remise du rapport, une tâche reste à mettre en place, il s’agit de la configuration

du Weather Map qui sera utile aux administrateurs pour évaluer les besoins futurs en
bande passante. Cette tâche se déroulera du 26 au 4 avril 2008 et marquera la fin du
stage.

B. Evolution

Les objectifs du stage ont tous été accomplis. Cependant, certains points peuvent
encore être travaillés tant du point de vue de la configuration qu’au niveau de
l’ergonomie.

Concernant la configuration, les PC alertes n’étant pas encore été installés dans tous
les centres de secours, le plan d’adressage IP n’a pas encore été définis. De ce fait,
certains hôtes ne sont pas encore intégrés dans Cacti et Nagios. Lorsque tous les
éléments réseaux critiques seront supervisés et que le serveur sera complètement
stable, il faudra mettre en place une réplique de secours, au cas où le premier
serveur rencontrerait un problème. Ceci permettra de suivre la logique du réseau
informatique du SDIS 64 en terme de disponibilité.

L’autre point concernant l’évolution est l’ergonomie. En effet, les différents menus du
Cacti et du Nagios ne sont pas pensés pour l’utilisation par une personne non initiée
au réseau informatique. L’objectif final du projet est de permettre aux opérateurs du
CTA de comprendre rapidement lorsqu’un équipement réseaux ne répond plus, afin
de contacter l’astreinte ou le centre de secours concerné. Un travail de
développement est donc nécessaire afin de rendre explicite les données provenant
du serveur de supervision. Cette partie mise en forme doit être réalisée par une
personne ayant à la fois des compétences en réseau et en développement. La
réalisation d’un tableau de bord est donc la prochaine phase du projet.

50
V. Conclusion

Ce stage de trois mois au sein du service informatique du Service Départemental

d’Incendie et de Secours des Pyrénées-Atlantiques, m’a permis d’évoluer dans un
environnement professionnel et ainsi faire un rapprochement concret entre les cours
inculqués à l’EXIA et la vie en entreprise.
Très vite intégré dans une équipe dynamique et disponible, j’ai pu évoluer, la
majorité du temps, en autonomie. Franck SAUVE, mon responsable de stage, m’a
proposé un projet plus qu’intéressant, où j’ai pu totalement m’impliquer et apporter
mes connaissances.
Ce point est très important pour moi, j’ai été écouté et chaque idée que j’ai pu
apporter a été prise en compte.
Ainsi, mis en confiance et dans de bonnes conditions de travail, j’ai découvert le
monde du logiciel opensource et de la supervision.
J’ai ainsi pu voir naître, se développer et se réaliser un projet, avec la grande
satisfaction qu’il soit mis en production.
Des premières lignes de commandes à la remontée du premier problème réseau, j’ai
assisté à l’ensemble des étapes du processus de réalisation d’un projet.
J’ai pu me rendre compte de la faculté d’adaptation requise pour exercer ce métier et
ainsi faire le parallèle avec cet état d’esprit qui nous est enseigné à l’EXIA.
Un goût pour la gestion, un bon sens du relationnel, le respect des délais, la
réactivité et la veille technologique, sont autant d’éléments indispensables,
complémentaires et nécessaires pour mettre en œuvre un projet.
Ce stage m’a donc permis de connaître concrètement la réalisation d’un projet en
entreprise.
Désirant devenir chef de projet de systèmes d’informations, je serai amené à
réemployer des techniques et connaissances, acquises au sein de ce service, afin de
réaliser convenablement des projets.

Ce stage m’a aussi démontré que le fait d’évoluer dans une ambiance et un cadre
agréable, où chacun écoute les idées des autres, permet une meilleure productivité.
J’ai donc appris beaucoup tant sur l’aspect technique que sur l’aspect humain.

C’est donc avec un grand plaisir que j’ai passé trois mois à travailler avec l’équipe
informatique du SDIS 64.

51
VI. Annexes

Cette version électronique ne contient pas les annexes. En effet, certains documents
n’existent qu’en version papier. Les annexes sont disponibles dans le document
rendu au secrétariat de l’EXIA PAU.

52