ANNEXES
Table des matières ANNEXES...1 1 - Nagios...3 1.1 - Architecture...3 1.2 - Organisation des fichiers de configuration...4 1.3 - Fichiers de configuration...5 1.3.1 - Hosts.cfg...5 1.3.2 - Hostgroups.cfg...5 1.3.3 - Services.cfg...6 1.3.4 - Checkcommands.cfg...7 NSClient ++...7 Imprimantes...8 Switchs et bornes WIFI Cisco...9 Photocopieurs...11 Onduleurs...12 1.4 - Cartographie du réseau...12 2 - Le protocole SNMP...13 2.1 - En pratique...13 2.2 - La MIB...15 2.3 - Informations sur les OID...18 3 - Fichier NSClient.ini...21 4 - Webographie...30 4.1 - En Français...30 4.2 - En Anglais...30 5 - Glossaire...31 Julien Guihéneuf TSGRI 2
1 - Nagios 1.1 - Architecture Julien Guihéneuf TSGRI 3
1.2 - Organisation des fichiers de configuration Nagios s'appuie plusieurs fichiers de configuration. C'est un choix de ses concepteurs que d'éclater la configuration sur plusieurs fichiers, chacun rassemblant des informations particulières et tous en relation avec un fichier principal. hosts.cfg : fichier dans lequel sont fait les déclarations d'hôtes et objets à superviser. hostgroups.cfg : déclaration des groupes d'hôtes hostextinfo.cfg : association d'icônes aux hôtes et objets pour les cartes 2D et 3D services.cfg : déclaration des services à superviser sur les hôtes serviceextinfo.cfg : association d'icônes aux services supervisés pour les cartes 2D et 3D checkcommands.cfg : déclaration des commandes auxquelles les services font appel misccommands.cfg : déclaration des commandes externes pour les notifications contacts.cfg : déclaration des contacts (personnes chargées de l'administration) groups.cfg : déclaration des groupes de contact Julien Guihéneuf TSGRI 4
1.3 - Fichiers de configuration 1.3.1 - Hosts.cfg Voilà comment se traduisent la création des hôtes sur le serveur CentOS : Modèle d'hôte (imprimantes ici) : Hôte : 1.3.2 - Hostgroups.cfg Le fichier de configuration pour un groupe d'hôtes : Julien Guihéneuf TSGRI 5
1.3.3 - Services.cfg Modèle de service (service template) : Service pour contrôler la charge en électricité des onduleurs : Julien Guihéneuf TSGRI 6
1.3.4 - Checkcommands.cfg Fichier important puisqu'il contient les scripts des plugins. -n = nombre d'essais -H = l'adresse IP à atteindre -s = hôte avec le service DNS NSClient ++ Les plugins tributaires du démon NSClient ++ sur les serveurs Windows : -p = port à ouvrir NSClient -v = variable du plugin (ici CPU) -s = mot de passe («none» quand aucun) -l = nombre de minutes, warning à 90 %, critical à 95 % Julien Guihéneuf TSGRI 7
-l = on précise le nom du disque Imprimantes On précise la communauté du protocole SNMP (sans l'argument -c) Julien Guihéneuf TSGRI 8
Plugin pour les imprimantes HP LaserJet1320. Plugin pour les imprimantes OKI, Epson, Lexmark et Samsung (l'argument -C est bien passé ce coup-ci). Switchs et bornes WIFI Cisco Le plugin «check_manubulon_snmp_mem» s 'adapte aussi bien aux switchs qu'aux bornes WIFI. -p = 161, port SNMP -C = communauté SNMP -w = warning -c = critical -I = matériel Cisco -f = pour un rendu graphique Julien Guihéneuf TSGRI 9
-T = matériel Cisco -i = interface -n = quand on précise le nom exact de l'interface -v = version du protocole SNMP -T = le débit maximal du port en Mb/s -s = permet de lister les ports de la machine Julien Guihéneuf TSGRI 10
Photocopieurs En plus du niveau du toner et le compteur, on peut surveiller plusieurs choses en passant l'argument «hardware» : USB, statut, Fax, Ethernet, IEEE 1284. Julien Guihéneuf TSGRI 11
Onduleurs Le plugin «check_snmp_mge_ups» que l'on trouve sur NagiosExchange.org indique au NMS l'état des onduleurs. 1.4 - Cartographie du réseau Julien Guihéneuf TSGRI 12
A partir de la carte globale du réseau, on parcourt l'arborescence suivante : La carte des onduleurs est venue s'ajouter par la suite et fonctionne sur le même principe. 2 - Le protocole SNMP 2.1 - En pratique Pour être utilisés par une large gamme de produits (systèmes terminaux, ponts, routeurs, équipement de télécommunication quelconque) et dans un environnement multiconstructeurs, les protocoles de gestion réseau sont regroupés dans deux grandes classes de standards : l'administration de systèmes OSI (CMISE/CMIP), et le SNMP. Le SNMP regroupe un ensemble de standards incluant un protocole, une spécification de Julien Guihéneuf TSGRI 13
la structure de la base de données et un ensemble d'objets. C'est le standard pour TCP/IP. Il se caractérise comme étant un protocole très simple, facile d'utilisation, qui permet une gestion à distance des différentes machines, dont le modèle fonctionnel pour la surveillance et pour la gestion est extensible, et qui est indépendant de l'architecture des machines administrées. Le système de gestion de réseau est basé sur deux éléments principaux : un superviseur et des agents. Le superviseur est la console qui permet à l'administrateur réseau d'exécuter des requêtes de management. Les agents sont des entités qui se trouvent au niveau de chaque interface connectant l'équipement managé au réseau et permettant de récupérer des informations sur différents objets. Switchs, hubs, routeurs et serveurs sont des exemples d'équipements contenant des objets manageables. Ces objets manageables peuvent être des informations matérielles, des paramètres de configuration, des statistiques de performance et autres objets qui sont directement liés au comportement en cours de l'équipement en question. Ces objets sont classés dans une base de données appelée MIB (Management Information Base). SNMP permet le dialogue entre le superviseur et les agents afin de recueillir les objets souhaités dans la MIB. Il existe plusieurs versions de SNMP plus ou moins sécurisées : SNMP v1 SNMP v2 SNMP v2c SNMP v3 Mots de passe en clair Sécurisée mais trop lourde Support des communautés Dernière version (support des communautés et est sécurisée) Il existe des communautés pour séparer les droits d utilisation. Une communauté SNMP est une relation entre un agent et les stations d'administration qui définit l'authentification et le contrôle d'accès. Dans notre cas on utilisera la communauté «public». Voici la représentation logique de son fonctionnement : Commande get-request get-nextrequest set-request get-reponse Trap Action Le Manager SNMP demande une information à un agent SNMP Le Manager SNMP demande l'information suivante à l'agent SNMP Le Manager SNMP met à jour une information sur un agent SNMP L'agent SNMP répond à un get-request ou a un set-request L'agent SNMP envoie une alarme au Manager Julien Guihéneuf TSGRI 14
Format d'un datagramme d'une requête SNMP : Celui d'un Trap : 2.2 - La MIB Une MIB (Base d'information de gestion) est un ensemble d'informations structuré sur une entité réseau, par exemple un switch ou un onduleur. Ces informations peuvent être récupérées, ou parfois modifiées, par le protocole SNMP. La structure de la MIB est hiérarchique : les informations sont regroupées en arbre. Chaque information est repérée par un OID (Object IDentifier), une suite de chiffres séparés par des points, qui l'identifie de façon unique. Elle est aussi repérée par un nom, indiqué dans le document qui décrit la MIB. Par exemple, 1.3.6.1.2.1.2.2.1.2 est OID ifdescr qui est la chaîne de caractères décrivant une interface réseau. Représentation en arbre de la MIB : Julien Guihéneuf TSGRI 15
Chaque constructeur propose des MIB pour leur matériel (en général disponibles sur leur site). Elles s'avèrent très utiles pour interpréter les OID. Un exemple des MIB disponibles pour le switch Cisco 2960 Julien Guihéneuf TSGRI 16
Des logiciels appelés Mib Browser se chargent d'interpréter l'arborescence : Le MIB Browser interprète la MIB et les OID, ainsi on retrouve certaines informations SNMP. Ici la température du switch. La MIB d'un matériel n'est pas indispensable dans le fonctionnement de Nagios et dans le cas où l'on utilise les plugins à disposition. Ces derniers intègrent dans leur script les OID correspondants à l'information recherchée. La MIB devient nécessaire lorsque l'on développe ces propres plugins ou lors d'envois d'interrogations passives à notre matériel (services SNMPTRAPD et SNMPTT indispensables). Il faut compiler la MIB dans Nagios, utiliser un check passif du type «dummy» (fourni dans le package de plugins) et spécifier la trap. On parle d'interruptions SNMP. Julien Guihéneuf TSGRI 17
Charger une MIB dans Centreon (Configuration => Services => Charger MIBs) C'est le NSCA qui permet d'envoyer des résultats de contrôles passifs de services à un autre serveur sur le réseau sur lequel tourne Nagios. Les contrôles sont actifs sur les serveurs répartis, passifs sur le serveur central. Le NSCA est composé de quatre fichiers : Démon qui tourne sur le serveur central de Nagios et qui traite les nsca résultats des contrôles faits sur les services passifs soumis par les clients. nsca.cfg Fichier de Configuration pour le démon nsca Programme client exécuté sur les serveurs répartis qui envoie les send_nsca résultats des services au démon nsca sur le serveur principal Nagios. send_nsca.cfg Fichier de configuration pour le client send_nsca Dans la supervision du lycée Camus, seules les interrogations actives des OID ont été utilisées. 2.3 - Informations sur les OID Pour obtenir toutes les OID d'un équipement il existe une commande : «snmpwalk» Sa syntaxe : # snmpwalk -v1 -c public @IP Il faut spécifier la version du protocole, ainsi que la communauté. Julien Guihéneuf TSGRI 18
Résultats d'un «snmpwalk» sur Nagios «snmpget» relève les informations pour un OID précis Résultats d'un «snmpget» sur Nagios Julien Guihéneuf TSGRI 19
Équivalent du même «snmpget» sur le MIB browser Julien Guihéneuf TSGRI 20
3 - Fichier NSClient.ini Pour utiliser le démon NSClient ++, il faut l'installer sur les serveurs Windows et configurer le fichier.ini en décommentant certaines lignes et rajoutant des informations telles que le numéro du port utilisé ou bien encore l'adresse IP du serveur Nagios. En rouge toutes les lignes à décommenter et / ou renseigner : [modules] # NSCLIENT++ MODULES # A list with DLLs to load at startup. You will need to enable some of these for NSClient++ to work.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! * * * N O T I C E!!! - Y O U H A V E T O E D I T T H I S * * *!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! FileLogger.dll CheckSystem.dll CheckDisk.dll NSClientListener.dll NRPEListener.dll SysTray.dll CheckEventLog.dll CheckHelpers.dll CheckWMI.dll RemoteConfiguration IS AN EXTREM EARLY IDEA SO DONT USE FOR PRODUCTION ENVIROMNEMTS! RemoteConfiguration.dll NSCA Agent is a new beta module use with care! NSCAAgent.dll LUA script module used to write your own "check deamon" (sort of) early beta. LUAScript.dll Script to check external scripts and/or internal aliases, early beta. CheckExternalScripts.dll Check other hosts through NRPE extreme beta and probably a bit dangerous! :) NRPEClient.dll Julien Guihéneuf TSGRI 21
Extreamly early beta of a task-schedule checker CheckTaskSched.dll [Settings] # OBFUSCATED PASSWORD This is the same as the password option but here you can store the password in an obfuscated manner. *NOTICE* obfuscation is *NOT* the same as encryption, someone with access to this file can still figure out the password. Its just a bit harder to do it at first glance. obfuscated_password=jw0kauudxlaauwasdaab # PASSWORD This is the password (-s) that is required to access NSClient remotely. If you leave this blank everyone will be able to access the daemon remotly. password=secret-password # ALLOWED HOST ADDRESSES This is a comma-delimited list of IP address of hosts that are allowed to talk to the all daemons. If leave this blank anyone can access the deamon remotly (NSClient still requires a valid password). The syntax is host or ip/mask so 192.168.0.0/24 will allow anyone on that subnet access allowed_hosts=127.0.0.1/32 # USE THIS FILE Use the INI file as opposed to the registry if this is 0 and the use_reg in the registry is set to 1 the registry will be used instead. use_file=1 # USE SHARED MEMORY CHANNELS This is the "new" way for using the system tray based on an IPC framework on top shared memmory channels and events. It is brand new and (probably has bugs) so dont enable this unless for testing! If set to 1 shared channels will be created and system tray icons created and such and such... shared_session=0 [log] # LOG DEBUG Set to 1 if you want debug message printed in the log file (debug messages are always printed to stdout when run with -test) debug=1 Julien Guihéneuf TSGRI 22
# LOG FILE The file to print log statements to file=nsclient.log # LOG DATE MASK The format to for the date/time part of the log entry written to file. date_mask=%y-%m-%d %H:%M:%S # LOG ROOT FOLDER The root folder to use for logging. exe = the folder where the executable is located local-app-data = local application data (probably a better choice then the old default) root_folder=exe [NSClient] # ALLOWED HOST ADDRESSES This is a comma-delimited list of IP address of hosts that are allowed to talk to NSClient deamon. If you leave this blank the global version will be used instead. allowed_hosts=172.17.213.10/27 172.17.212.3/27 # NSCLIENT PORT NUMBER This is the port the NSClientListener.dll will listen to. port=12489 # BIND TO ADDRESS Allows you to bind server to a specific local address. This has to be a dotted ip adress not a hostname. Leaving this blank will bind to all avalible IP adresses. bind_to_address= # SOCKET TIMEOUT Timeout when reading packets on incoming sockets. If the data has not arrived withint this time we will bail out. socket_timeout=30 [NRPE] # NRPE PORT NUMBER This is the port the NRPEListener.dll will listen to. Julien Guihéneuf TSGRI 23
port=5666 # COMMAND TIMEOUT This specifies the maximum number of seconds that the NRPE daemon will allow plug-ins to finish executing before killing them off. command_timeout=60 # COMMAND ARGUMENT PROCESSING This option determines whether or not the NRPE daemon will allow clients to specify arguments to commands that are executed. allow_arguments=0 # COMMAND ALLOW NASTY META CHARS This option determines whether or not the NRPE daemon will allow clients to specify nasty (as in `&><'"\ []{}) characters in arguments. allow_nasty_meta_chars=0 # USE SSL SOCKET This option controls if SSL should be used on the socket. use_ssl=1 # BIND TO ADDRESS Allows you to bind server to a specific local address. This has to be a dotted ip adress not a hostname. Leaving this blank will bind to all avalible IP adresses. bind_to_address= # ALLOWED HOST ADDRESSES This is a comma-delimited list of IP address of hosts that are allowed to talk to NRPE deamon. If you leave this blank the global version will be used instead. allowed_hosts=172.17.213.10/27 172.17.212.3/27 # SCRIPT DIRECTORY All files in this directory will become check commands. *WARNING* This is undoubtedly dangerous so use with care! script_dir=scripts\ # SOCKET TIMEOUT Timeout when reading packets on incoming sockets. If the data has not arrived withint this time we will bail out. Julien Guihéneuf TSGRI 24
socket_timeout=30 [Check System] # CPU BUFFER SIZE Can be anything ranging from 1s (for 1 second) to 10w for 10 weeks. Notice that a larger buffer will waste memory so don't use a larger buffer then you need (ie. the longest check you do +1). CPUBufferSize=1h # CHECK RESOLUTION The resolution to check values (currently only CPU). The value is entered in 1/10:th of a second and the default is 10 (which means ones every second) CheckResolution=10 # CHECK ALL SERVICES Configure how to check services when a CheckAll is performed....=started means services in that class *has* to be running....=stopped means services in that class has to be stopped....=ignored means services in this class will be ignored. check_all_services[service_boot_start]=ignored check_all_services[service_system_start]=ignored check_all_services[service_auto_start]=started check_all_services[service_demand_start]=ignored check_all_services[service_disabled]=stopped [External Script] # COMMAND TIMEOUT This specifies the maximum number of seconds that the NRPE daemon will allow plug-ins to finish executing before killing them off. command_timeout=60 # COMMAND ARGUMENT PROCESSING This option determines whether or not the NRPE daemon will allow clients to specify arguments to commands that are executed. allow_arguments=0 # COMMAND ALLOW NASTY META CHARS This option determines whether or not the NRPE daemon will allow clients to specify nasty (as in `&><'"\[] {}) characters in arguments. Julien Guihéneuf TSGRI 25
allow_nasty_meta_chars=0 # COMMAND ALLOW NASTY META CHARS This option determines whether or not the NRPE daemon will allow clients to specify nasty (as in `&><'"\[] {}) characters in arguments. script_dir=c:\my\script\dir [External Scripts] check_es_long=scripts\long.bat check_es_ok=scripts\ok.bat check_es_nok=scripts\nok.bat check_vbs_sample=cscript.exe //T:30 //NoLogo scripts\check_vb.vbs check_powershell_warn=cmd /c echo scripts\powershell.ps1 powershell.exe -command - [External Alias] alias_cpu=checkcpu warn=80 crit=90 time=5m time=1m time=30s alias_disk=checkdrivesize MinWarn=10% MinCrit=5% CheckAll FilterType=FIXED alias_service=checkservicestate CheckAll alias_mem=checkmem MaxWarn=80% MaxCrit=90% ShowAll type=physical alias_event_log=checkeventlog file=application file=system filter=new filter=out MaxWarn=1 MaxCrit=1 filter-generated=>2d filter-severity==success filter-severity==informational truncate=1023 unique descriptions "syntax=%severity%: %source%: %message% (%count%)" [includes] # The order when used is "reversed" thus the last included file will be "first" # Included files can include other files (be carefull only do basic recursive checking) myotherfile.ini real.ini [NSCA Agent] # CHECK INTERVALL (in seconds) How often we should run the checks and submit the results. interval=5 # ENCRYPTION METHOD This option determines the method by which the send_nsca client will encrypt the packets it sends to the nsca daemon. The encryption method you choose will be a balance between security and performance, as strong encryption methods consume more processor resources. Julien Guihéneuf TSGRI 26
You should evaluate your security needs when choosing an encryption method. Note: The encryption method you specify here must match the decryption method the nsca daemon uses (as specified in the nsca.cfg file)!! Values: 0 = None (Do NOT use this option) 1 = Simple XOR (No security, just obfuscation, but very fast) 2 = DES 3 = 3DES (Triple DES) 4 = CAST-128 6 = xtea 8 = BLOWFISH 9 = TWOFISH 11 = RC2 14 = RIJNDAEL-128 (AES) 20 = SERPENT encryption_method=14 # ENCRYPTION PASSWORD This is the password/passphrase that should be used to encrypt the sent packets. password= # BIND TO ADDRESS Allows you to bind server to a specific local address. This has to be a dotted ip adress not a hostname. Leaving this blank will bind to "one" local interface. -- not supported as of now -- bind_to_address= # LOCAL HOST NAME The name of this host (if empty "computername" will be used. hostname= # NAGIOS SERVER ADDRESS The address to the nagios server to submit results to. nsca_host=172.17.213.10 # NAGIOS SERVER PORT The port to the nagios server to submit results to. Julien Guihéneuf TSGRI 27
nsca_port=5667 # CHECK COMMAND LIST The checks to run everytime we submit results back to nagios Any command(alias/key) starting with a host_ is sent as HOST_COMMAND others are sent as SERVICE_COMMANDS where the alias/key is used as service name. [NSCA Commands] my_cpu_check=checkcpu warn=80 crit=90 time=20m time=10s time=4 my_mem_check=checkmem MaxWarn=80% MaxCrit=90% ShowAll type=page my_svc_check=checkservicestate CheckAll exclude=wampmysqld exclude=mpfservice host_check=check_ok [NRPE Handlers] # COMMAND DEFINITIONS # Command definitions that this daemon will run. # Can be either NRPE syntax: command[check_users]=/usr/local/nagios/libexec/check_users -w 5 -c 10 # Or simplified syntax: test=c:\test.bat foo $ARG1$ bar check_disk1=/usr/local/nagios/libexec/check_disk -w 5 -c 10 # Or even loopback (inject) syntax (to run internal commands) # This is a way to run "NSClient" commands and other internal module commands such as check eventlog etc. check_cpu=inject checkcpu warn=80 crit=90 5 10 15 check_eventlog=inject CheckEventLog Application warn.require.eventtype=error warn.require.eventtype=warning critical.require.eventtype=error critical.exclude.eventtype=info truncate=1024 descriptions check_disk_c=inject CheckFileSize ShowAll MaxWarn=1024M MaxCrit=4096M File:WIN=c:\ATI\*.* # But be careful: dont_check=inject dont_check This will "loop forever" so be careful with the inject command... # Check some escapings... check_escape=inject CheckFileSize ShowAll MaxWarn=1024M MaxCrit=4096M "File: foo \" WIN=c:\\WINDOWS\\*.*" # Some real world samples nrpe_cpu=inject checkcpu warn=80 crit=90 5 10 15 nrpe_ok=scripts\ok.bat check_multi_line=scripts\multi_line.bat Julien Guihéneuf TSGRI 28
# # The sample scripts # check_long=scripts\long.bat check_ok=scripts\ok.bat check_nok=scripts\xlong.bat check_vbs=cscript.exe //T:30 //NoLogo scripts\check_vb.vbs # REMOTE NRPE PROXY COMMANDS A list of commands that check other hosts. Used by the NRPECLient module [NRPE Client Handlers] check_other=-h 192.168.0.1 -p 5666 -c remote_command -a arguments # LUA SCRIPT SECTION A list of all Lua scripts to load. [LUA Scripts] scripts\test.lua Julien Guihéneuf TSGRI 29
4 - Webographie 4.1 - En Français http://cedrictemple.net/dotclear/ blog du créateur de FAN, aide et nouveautés concernant Nagios http://forum.centreon.com excellent forum francophone sur l'utilisation de Centreon (modules, plugins, tutoriels...) http://forums.bfl-solutions.eu forum d'aide sur Nagios, tutoriels, plugins créés par les utilisateurs http://www.nagiosexchange.org site regroupant tous les plugins pour Nagios http://blog.nicolargo.com aide sur la mise en place de Nagios, des clients tel que NSClient ++ http://nagios.manubulon.com/traduction/fr_2.5/toc.html documentation sur Nagios complète http://christian.caleca.free.fr/snmp.html informations et explications complètes le protocole SNMP sur 4.2 - En Anglais http://www.nagvis.org/ (anglais) site pour tout ce qui concerne le plugin de cartographie Nagvis http://en.doc.centreon.com/index.php/main_pages wiki sur Centreon Julien Guihéneuf TSGRI 30
5 - Glossaire Apache : logiciel de serveur HTTP. Backup : sauvegarde. Centreon : logiciel de surveillance et de supervision réseau, basé sur le moteur de récupération d'information libre Nagios. CGI : «Common Gateway Interface», interface normalisée utilisée par les serveurs HTTP. Le serveur exécute une programme puis retourne le contenu généré. Le CGI indique comment transmettre la requête du serveur HTTP au programme et comment exécuter la réponse. CNA : Cisco Network Assistant. FAN : Full Automated Nagios. GLPI : «Gestion libre de parc informatique». Logiciel de gestion de helpdesk et de parc informatique distribué sous licence GPL. Host : sous Nagios, machine, serveur ou équipement réseau. MIB : «Managment Information Base». Base de données utilisée pour la gestion des réseaux, manipulable par des protocoles tels que SNMP, CMIP. MIB Browser : logiciel détaillant l'arborescence d'une MIB, traduit ses OID. Monitoring : activité de surveillance et de mesure. Nagvis : plugin de Nagios dédié à la cartographie. NDO : stocke les données Nagios dans une base MySQL OID : «Object Unique Identifier», identifiants universels, représentés sous la forme d'une suite d'entiers. Ils permettent d'identifier les ressources sujettes au protocole SNMP. Perl : langage de programmation créé par Larry Wall en 1987. «Practical Extraction and Report Language». Postfix : Postfix est un serveur de messagerie électronique et un logiciel libre. Reporting : Le reporting est la présentation périodique de rapports sur les activités et résultats d'une organisation. SMTP : «Simple mail transfer protocol», utilisé pour transférer le courrier électronique vers les serveurs de messagerie électronique. SNMP : «Simple Network Mangment Protocol», permet aux administrateurs réseau de gérer les équipements du réseau, superviser et de diagnostiquer des problèmes réseaux, matériels à distance. Trap : Processus d'alerte SNMP correspondant à un paquet UDP envoyé sur le serveur (port 162). Julien Guihéneuf TSGRI 31