Professional Documents
Culture Documents
Rapport de stage
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.
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
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
A. Tâches restantes 50
B. Evolution 50
V. Conclusion 51
VI. Annexes 52
3
I. Introduction
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
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 :
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
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.
6
Organigramme du SDIS 64
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.
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.
10
C. Présentation du projet
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.
D. Les objectifs
13
E. Planning des travaux
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
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.
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 :
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.
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.
18
B. Cacti
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 :
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 :
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.
# 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 .
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
Une fois Cacti en place, il est vivement conseiller de re-limiter les droits.
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 :
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 :
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.
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 :
# cp /home/user/Desktop/haloe /usr/share/cacti/site/plugins/ -R
$plugins[] = ‘haloe’;
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 :
# cp /home/user/Desktop/ntop /usr/share/cacti/site/plugins/ -R
$plugins[] = ‘haloe’;
28
3. WeatherMap
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 :
# cp /home/user/Desktop/weathermap /usr/share/cacti/site/plugins/ -R
$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
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 :
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 :
# 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 :
# ./configure - -with-command-group=nagcmd
# make all
# make install
# 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
# make install-config
Après extraction :
Puis l’installation:
# make install
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.
<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>
<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>
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 :
# 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
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.
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
}
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
}
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.
cfg_file=/usr/local/nagios/etc/objects/routeur.cfg
# /ect/init.d/nagios restart
40
4. Utilisation de 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 :
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.
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.
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.
2d_coords abscisse,ordonnée
statusmap_image icone.png
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.
45
« Status Map » complète des routeurs du réseau du SDIS 64 (2000x1500 pixels)
46
« Status Map » dans le navigateur
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
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 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