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 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
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 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. B. C. D. E.
Présentation de l’entreprise Présentation du réseau informatique Présentation du projet Objectifs Planning
III. Mise ne place d’un serveur de supervision
5 9 11 13 14 16
A. Préparation du système 1. Choix de la distribution 2. Mise en place du serveur LAMP
16 16 16
B. Cacti 1. Installation 2. Configuration 3. Utilisation
19 19 19 22
C. Plugins Cacti 1. Syslog 2. NTOP 3. Weather Map
25 25 27 29
D. Nagios 1. Présentation 2. Installation 3. Configuration 4. Utilisation
31 31 32 34 41
IV. Continuité du projet
50
A. Tâches restantes B. Evolution
50 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 de Franck SAUVE, responsable de l’exploitation réseau informatique 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éesAtlantiques), 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 : La prévention et l’évaluation des risques de sécurité civile. La préparation aux mesures de sauvetages et d’organisation des moyens de secours. La protection des personnes, des biens et de l’environnement. Le secours d’urgence aux victimes d’accidents, de sinistres ou de catastrophes, ainsi que leurs évacuations. o o
o o
•
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
e u q t i n l t a A n a é O c
∗
Landes Landes
Gers Gers
ORGANISATION TERRITORIALE DU SDIS 64
LEGENDE LEGENDE
Anglet Anglet
Puyoo Puyoo
Urt Urt
Arzacq-arraziguet Arzacq-arraziguet
Limites cantonales
Bidache Bidache
Orthez Orthez
Salies-de-bearn LabastideLabastide- Salies-de-bearn villefranche villefranche villefranche villefranche
Saint-jean-de-luz-nautique Saint-jean-de-luz-nautique Saint-jean-de-luz Saint-jean-de-luz Ustaritz Ustaritz Hasparren Hasparren Hendaye Hendaye Saint-peeSaint-pee- Cambo-les-bains Cambo-les-bains sur-nivelle sur-nivelle
Arthez-de-bearn Arthez-de-bearn Lembeye Lembeye
Sauveterre-de-bearn Sauveterre-de-bearn
Artix Artix
Saint-palais Saint-palais
Groupement d'Orthez
Arbus Arbus Monein Monein Arbus
Navarrenx Navarrenx
Pau Pau
Pau-dsi Pau-dsi
Osses Osses
Oloron-sainte-marie Oloron-sainte-marie
Lasseube Lasseube
Gan Gan
Arette Arette
Arudy Arudy
La-pierre-saint-martin La-pierre-saint-martin
Bedous Bedous
Laruns Laruns Gourette Gourette
Lescun Lescun Urdos Urdos
Centre d'Intervention et de Secours (CIS)
Nay Nay Pontacq Pontacq Pontacq Pontacq Coarraze Coarraze Coarraze Coarraze Coarraze
Tardets-sorholus Tardets-sorholus
Espagne
Groupement de Bayonne Soumoulou Soumoulou
Mauleon-licharre Mauleon-licharre Mauleon-licharre Mauleon-licharre Saint-jeanSaint-jeanpied-de-port pied-de-port pied-de-port
Groupement d'Oloron Groupement de Pau
Mourenx Mourenx
Iholdy Iholdy
Saint-etienne Saint-etienne -de-baigorry -de-baigorry
Limites secteur 1er appel
Garlin Garlin
ee s é n é r n y P s s u t e a H
Fabrege Fabrege Fabrege Fabrege
Presentation_org_ter_1
0
10
20
STIC A. Elkaim septembre 2007
30
Kilometers
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éesAtlantiques. 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 cactiplugin-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 cidessous, 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 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 Alias /nagios /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
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 use alias service_notification_commands host_notification_commands email }
administrateur1 administrateur-contact Administrateur Principal notify-service-by-email notify-host-by-email
[email protected]
define contact { contact_name use alias service_notification_commands host_notification_commands email }
administrateur2 administrateur-contact Administrateur Secondaire notify-service-by-email notify-host-by-email
[email protected]
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 alias members }
admins Nagios Administrateurs 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 host_name alias address hostgroups }
generic-router cisco1 Cisco 1 192.168.1.1 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 alias }
reseau-interne 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 host_name service_description check_command normal_check_interval retry_check_interval }
generic-service cisco1 PING check_ping!200.0,20%!600.0,60% 5 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 contact_name first_notification last_notification notification_interval }
cisco1 administrateur1 0 2 5
define hostescalation { host_name contact_name first_notification last_notification notification_interval }
cisco1 administrateur2 3 10 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 service_notification_period host_notification_period service_notification_options host_notification_options service_notification_commands host_notification_commands register } 39
administrateur-contact 24x7 24x7 w,u,c,r,f,s d,u,r,f,s notify-service-by-email notify-host-by-email 0
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 : routeurbedous 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 host_name alias address hostgroups 2d_coords statusmap_image }
generic-router cisco1 Cisco 1 192.168.1.1 reseau-interne 250,300 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
