Nicolas Deves Yoann Moulin Olivier Allovon Rémi Roger Brice Sauvajon. Correction du TP Nagios

Transcription

1 Nicolas Deves Yoann Moulin Olivier Allovon Rémi Roger Brice Sauvajon Correction du TP Nagios

2 Installation de Nagios L exécution du script nagios.sh téléchargé sur installe nagios et ses plugins sur le PC. Nagios est alors configuré avec une version minimale qui ne contient qu un contact, une machine et le service ping sur celle-ci. Pour configurer Nagios (ajout de machines, contacts et services), il faut modifier les fichiers de configuration qui se trouvent dans /etc/nagios. Les fichiers de configuration sont les suivants : nagios.cfg resource.cfg misccommands.cfg hosts.cfg hostgroups.cfg contacts.cfg contactgroups.cfg timeperiods.cfg checkcommands.cfg services.cfg dependencies.cfg escalations.cfg cgi.cfg 1.1. nagios.cfg C est le fichier principal, il liste les autres fichiers de configuration à utiliser, l emplacement des fichiers de logs, l utilisateur et le groupe à qui appartient le processus nagios, ainsi que d autres paramètres tels que l intervalle entre les vérifications. Nous n aurons pas à modifier ce fichier pour le TP resource.cfg Ce fichier définit les «macros» utilisées dans les fichiers de configuration, la seule macro utilisée dans notre cas est $USER1$, elle désigne l emplacement du répertoire contenant les plugins et est utilisée dans le fichier checkcommands.cfg. Nous n aurons pas à modifier ce fichier pour le TP misccommands.cfg Ce fichier indique la ligne de commande à utiliser pour certaines commandes qui ne correspondent pas à un service particulier, telles que les commandes de notification par . Nous n aurons pas à modifier ce fichier pour le TP.

3 1.4. hosts.cfg Ce fichier définit les machines à surveiller ou sur lesquelles il faudra tester des services. Chaque définition contient entre autres le nom qui sera visible dans l interface de Nagios, un nom plus complet, l adresse IP, les périodes de fonctionnement, Pour le TP il faudra ajouter les définitions de toutes les machines à tester hostgroups.cfg Ce fichier définit des groupes de machines. Pour le TP, trois groupes seront crées : linux-boxes, windows-boxes et network contacts.cfg Ce fichier définit des contacts : il associe un nom de contact des commandes de notification, une adresse et des périodes de notification. Pour le TP, il faudra ajouter les trois administrateurs correspondant aux trois types de matériels, ainsi que l administrateur général contactgroups.cfg Comme pour le fichier hostgroups.cfg, ce fichier permet de créer des groupes de contacts. Pour le TP nous aurons trois groupes à créer pour que les notification parviennent à la fois à l administrateur concerné et à l administrateur général timeperiods.cfg Ce fichier définit des périodes de temps qui peuvent être utilisées pour indiquer les périodes de fonctionnement des machines à surveiller, les périodes de notifications, Nous n utiliserons que des périodes déjà définies dans ce fichier, il ne sera donc pas nécessaire de modifier ce fichier durant le TP checkcommands.cfg Ce fichier fait correspondre un nom de commande utilisé dans les fichiers services.cfg ou hosts.cfg à la ligne de commande à utiliser pour tester le service concerné. La plupart des commandes correspondant à des services simples sont déjà définies dans ce fichier, cependant il faudra ajouter les commandes utilisant nsclient pour tester des ressources sur une machine windows (question 4), les commandes que nous utiliserons pour tester les ressources distantes avec nrpe (question 5) et la commande utilisant le plugin à créer (question 6).

4 1.10. services.cfg Ce fichier est un des plus important, il définit quel service est à tester, sur quelle machine, qui doit être prévenu en cas de problème, les périodes de surveillance et le nom de la commande à utiliser pour tester le service. Ce fichier devra être largement complété pendant le TP dependencies.cfg Ce fichier permet de créer des dependences entre des services ou des machines. Ceci évite de tester un service dépendant d un autre si ce dernier ne marche pas, ou de tester les services sur une machine accédée à travers une autre qui ne marche pas. Pour ne pas compliquer le TP, il a été choisi de ne pas traiter les dépendances d hôtes ou de services. Le fichier ne sera donc pas modifié escalations.cfg Ce fichier permet de définir des notifications différentes selon le nombre d échecs obtenus pour un service. Par exemple, pour un service, il n y aura pas de notification jusqu'à 3 échecs, l administrateur du service concerné sera alerté entre 3 et 10 échecs, au-delà l administrateur général sera également prévenu. Ceci ne sera pas utilisé pendant le TP cgi.cfg Ce fichier contient des paramètres liés à l interface web de nagios (authentification, rafraîchissement de la page, ). Ce fichier ne sera pas modifié : le comportement par défaut sera utilisé.

5 2. Configuration de Nagios 2.1. apache.conf fichier apache.conf : il définit les droits accès de l'interface web ainsi que les chemins d'accès. Ici, # BEGIN FOR NAGIOS # Bug and say that the ScriptAlias should be # /cgi-bin/nagios # but some reports, , (and the default config) say # that it should be # /nagios/cgi-bin # Anyone having problems with this, PLEASE dig deeper in WHY # it won't work for you... # # I'm enabling BOTH, just to be sure! ScriptAlias /cgi-bin/nagios /usr/lib/cgi-bin/nagios/ ScriptAlias /nagios/cgi-bin /usr/lib/cgi-bin/nagios/ <DirectoryMatch /usr/lib/cgi-bin/nagios/> Options ExecCGI AllowOverride AuthConfig Order Allow,Deny Allow From All AuthName "Nagios Access" AuthType Basic AuthUserFile /etc/nagios/htpasswd.users require valid-user </DirectoryMatch> Alias /netsaint /usr/share/nagios/htdocs/ Alias /nagios /usr/share/nagios/htdocs/ <DirectoryMatch /usr/share/nagios/htdocs/> Options FollowSymLinks AllowOverride AuthConfig Order Allow,Deny Allow From All AuthName "Nagios Access" AuthType Basic AuthUserFile /etc/nagios/htpasswd.users require valid-user </DirectoryMatch> # END FOR NAGIO

6 2.2. Hosts.cfg Le Template : il définit les paramètres par défaut d'un host. Paramètre utilisé au moment du démarrage et redémarrage de nagios : define host{ name notifications_enabled generic-host 0 event_handler_enabled 0 flap_detection_enabled process_perf_data 0 1 retain_status_information 1 retain nonstatus information register 1 0 Définition des différentes Machines correspondant à l'architecture demander pendant le TP : # 'linux1' host definition define host{ use generic-host gateway Linux Gateway address check-host-alive max_check_attempts 10 notification_interval notification_period 480 notification_options d,u,r define host{ use generic-host Esisar main server address check-host-alive max_check_attempts 10 notification_interval 480 notification_period notification_options d,u,r define host{ use generic-host Tux Linux server address check-host-alive max_check_attempts 10 notification_interval 480 notification_period notification_options d,u,r define host{ use generic-host Bill Windows server address check-host-alive max_check_attempts 10

7 notification_interval 480 notification_period notification_options d,u,r define host{ use generic-host Nagios Nagios station address max_check_attempts check-host-alive 10 notification_interval 480 notification_period notification_options d,u,r define host{ use generic-host Router Cisco 1700 router address max_check_attempts check-host-alive 10 notification_interval 480 notification_period notification_options d,u,r

8 2.3. Hostsgroup.cfg Chaque membres d'un hostgroup doit correspondre à un host définit dans le fichier hosts.cfg define hostgroup{ hostgroup_name linux-boxes Linux Servers contact_groups Linux members Esisar, Tux, Nagios define hostgroup{ hostgroup_name windows-boxes Windows Servers contact_groups Windows members Bill define hostgroup{ hostgroup_name Network Network material contact_groups Network members gateway, Router

9 2.4. Contact define contact{ contact_name linux_adm Linux_Administrator service_notification_period host_notification_period service_notification_options w,u,c,r host_notification_options d,u,r service_notification_commands notify-by- host_notification_commands host-notify-by- define contact{ contact_name windows_adm Windows_Administrator service_notification_period host_notification_period service_notification_options w,u,c,r host_notification_options d,u,r service_notification_commands notify-by- host_notification_commands host-notify-by- define contact{ contact_name network_adm Network_Administrator service_notification_period host_notification_period service_notification_options w,u,c,r host_notification_options d,u,r service_notification_commands notify-by- host_notification_commands host-notify-by- define contact{ contact_name admin Administrator service_notification_period host_notification_period service_notification_options w,u,c,r host_notification_options d,u,r service_notification_commands notify-by- host_notification_commands host-notify-by-

10 2.5. Contactsgroup.cfg Chaque membres d'un contactgroup doit correspondre à un contact définit dans le fichier contatcs.cfg define contactgroup{ contactgroup_name members define contactgroup{ contactgroup_name members define contactgroup{ contactgroup_name members Linux Linux_Administrators linux_adm, admin Windows Windows_Administrators windows_adm, admin Network Network_Administrators network_adm, admin 2.6. Remarque Si on ne configure que ces fichiers, le check-host-alive ne fonctionne pas, il faut au moins un service configuré par host pour que cela fonctionne. Dans le TP, il a donc été nécessaire de définir le service PING pour chaque host. Dans le template pas défaut du fichier hosts.cfg, les notifications ne sont pas activée. On a donc modifié le template pour l'activer au démarrage. 3. Configuration des services simples On entend par services simples tous les tests relatifs aux ressources locales ou aux services réseaux, ne nécessitant l intervention ni de NS Client pour les clients Windows, ni des plugins NRPE pour les tests de ressources distantes sur les stations Linux. Dans notre cas, les services simples concernent : - Sur la station ESISAR : Ping, Smtp, http, Ftp, Dns, Ssh et Daytime qui sont tous des services réseaux - Sur la station NAGIOS (la notre) : Load, Swap et Disk qui sont des ressources locales - Sur la passerelle ADSL : Ping (un service réseau) - Sur notre routeur Cisco : Ping (un service réseau) - Sur la station TUX : Ping (un service réseau) Pour configurer ces services, nous modifierons deux fichiers : checkcommands.cfg et services.cfg.

11 3.1. checkcommands.cfg Dans le fichier checkcommands.cfg, nous définissons les commandes à exécuter pour tester un service. L ensemble de ces commandes est présent sous forme d exécutable dans le répertoire plugin de Nagios. On peut donc tester en ligne de commande si les paramètres associés aux commandes fonctionnent. De même, on obtient l aide relative à cette commande grâce à l option h (ex : check_ping h). Prenons un exemple de service à tester : pour le test du Ping, voici la définition dans checkcommands.cfg : define command{ command_name check_ping command_line $USER1$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -p 5 Ainsi, pour associer le test du service ping, nous utiliserons le nom check_ping. Nous avons ici deux solutions : - soit on indique «en dur» les paramètres de la fonction check_ping - soit on indique les paramètres à utiliser et ces derniers seront écrits dans le fichier services.cfg Dans le cas présent, certains sont rentrés en dur, comme l adresse de l hôte. D autres seront à entrer en complément de la commande, comme ARG1 et ARG2. Dans notre cas d étude, nous devons configurer des commandes non définies dans checkcommands.cfg mais présentes dans le répertoire de plugin. Ainsi, on rajoute la définition de check_ssh, check_daytime et check_swap (voir fichier checkcommands.cfg) services.cfg Dans le fichier services.cfg, nous associons aux hôtes déjà définis le service que l on souhaite tester ainsi que les arguments nécessaires à son utilisation. Prenons l exemple du Ping sur la station ESISAR : define service{ use generic-service ; Name of service template to use Esisar service_description PING is_volatile 0 check_period max_check_attempts 3 normal_check_interval 5 retry_check_interval 1 contact_groups Linux notification_interval 240 notification_period notification_options c,r check_ping!100.0,20%!500.0,60%

12 On configure ici l hôte sur lequel on teste le service, les périodes de test et les périodes de notification ainsi et surtout de la commande à exécuter avec ses paramètres (ceux non rentrés en durs). Les arguments de la commande sont séparés par des «!», dans le cas du Ping, l argument 1 correspondant à ARG1 dans checkcommands.cfg est 100.0,20%, de même l argument 2 (ARG2) est 500.0,60%. Ces paramètres dépendent de la commande exécutée. Ainsi, pour chacune des stations citées dans le sujet et précédemment définie dans le fichier hosts.cfg, nous associons les services à tester.

13 4. NSClient 4.1. Installation Une fois l archive zip décompressée, il faut copier les fichiers pnsclient.exe, pdh.dll, psapi.dll et counters.defs dans le répertoire où l on veut installer NSClient (par exemple c:\nsclient) puis lancer la commande pnsclient.exe /install dans un prompt MS-DOS, ce qui installe le service NSClient sur la machine. On peut alors démarrer le servie à partir de cet écran. Du côté de la machine Nagios, il faut utiliser le plugin check_nt qui est fourni dans le fichier zip et le copier dans le répertoire des plugins de Nagios Configuration On modifie le fichier checkcommands.cfg en y ajoutant les blocs suivant : Test de la mémoire utilisée : define command{ command_name check_windows_mem command_line $USER1$/check_nt -H $HOSTADDRESS$ -v MEMUSE -w $ARG1$ -c $ARG2$

14 Test de l espace disque utilise : define command{ command_name check_windows_disk command_line $USER1$/check_nt -H $HOSTADDRESS$ -v USEDDISKSPACE -l $ARG1$ -w $ARG2$ -c $ARG3$ Puis on ajoute les blocs suivant dans le fichier sercives.cfg pour utiliser ces commandes sur la machine Bill : Test de la mémoire utilisée : define service{ use generic-service ; Name of service template to use Bill service_description MEMORY USED is_volatile 0 check_period max_check_attempts 3 normal_check_interval 5 retry_check_interval 1 contact_groups Windows notification_interval 240 notification_period notification_options c,r check_windows_mem!50%!90% Test de l espace disque disponible : define service{ use generic-service ; Name of service template to use Bill service_description DISK is_volatile 0 check_period max_check_attempts 3 normal_check_interval 5 retry_check_interval 1 contact_groups Windows notification_interval 240 notification_period notification_options c,r check_windows_disk!c!60%!80%

15 5. NRPE 5.1. Installation Une fois le fichier.tar.gz téléchargé et décompressé, on lance la configuration des options de compilation du programme avec la commande :./configure --disable-ssl enable-command-args L option disable-ssl désactive la compilation avec le support de ssl pour les transactions client/serveur car les bibliothéques nécessaires ne sont pas disponibles sur la machine de test. L option enable-command-args active le support de passage d atguments à travers le réseau. Ainsi, toute la partie de configuration de la commande se fait sur la machine Nagios. Ensuite, la compilation se fait par la commande make et on obtient un fichier binaire nrpe, un exemple de fichier de configuration nrpe.cfg et le plugin Nagios permettant d interroger la machine à distance check_nrpe, à copier dans le répertoire des plugins de la machine Nagios. Il faut aussi installer les plugins Nagios sur la machine où tourne le démon nrpe Configuration côté serveur Avant de lancer le démon nrpe, quelques modifications du fichier nrpe sont nécessaires. Afin d accepter les arguments passés à distance, il est nécessaire de mettre la variable dont_blame_nrpe à 1. Il faut aussi préciser dans ce fichier les adresses ip des machines ayant le droit de se connecter au serveur, dans la variable allowed_hosts. Ensuite, il faut modifier les lias des commandes se trouvant en fin de fichier. Par défaut, ceux définis dans le fichier ont les arguments de chaque commande définis en dur. Or, on désire utiliser les arguments envoyés par la machine Nagios. Nous allons donc remplacer les lignes : command[check_users]=@libexecdir@/check_users -w 5 -c 10 command[check_load]=@libexecdir@/check_load -w 15,10,5 -c 30,25,20 command[check_disk1]=@libexecdir@/check_disk -w 20 -c 10 -p /dev/hda1 Par : #command[check_users]=@libexecdir@/check_users -w $ARG1$ -c $ARG2$ #command[check_load]=@libexecdir@/check_load -w $ARG1$ -c $ARG2$ #command[check_disk]=@libexecdir@/check_disk -w $ARG1$ -c $ARG2$ -p $ARG3$ De plus, pour pouvoir verifier l état de la swap à distance, il faut rajouter l : #command[check_swap]=@libexecdir@/check_swap -w $ARG1$ -c $ARG2$ On peut ensuite lancer le démon nrpe parla commande./nrpe -d -c nrpe.cfg

16 5.3. Configuration de Nagios On définit ensuite les blocs de commande suivant dans le fichier checkcommands.cfg : # 'check_remote_users' command definition define command{ command_name check_remote_users command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c check_users -a $ARG1$ $ARG2$ # 'check_remote_load' command definition define command{ command_name check_remote_load command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c check_load -a $ARG1$ $ARG2$ # 'check_remote_swap' command definition define command{ command_name check_remote_swap command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c check_swap -a $ARG1$ $ARG2$ # 'check_remote_disk' command definition define command{ command_name check_remote_disk command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c check_disk -a $ARG1$ $ARG2$ $ARG3$ Puis on applique ces commandes à la machine Tux avec les blocs suivant : #Load sur TUX define service{ use generic-service ; Name of service template to use Tux service_description LOAD is_volatile 0 check_period max_check_attempts 3 normal_check_interval 5 retry_check_interval 1 contact_groups Linux notification_interval 240 notification_period notification_options c,r

17 check_remote_load!0.1,0.1,0.1!0.5,0.5,0.5 #Swap sur TUX define service{ use generic-service ; Name of service template to use Tux service_description SWAP is_volatile 0 check_period max_check_attempts 3 normal_check_interval 5 retry_check_interval 1 contact_groups Linux notification_interval 240 notification_period notification_options c,r check_remote_swap!50%!10% #Disk sur TUX define service{ use generic-service ; Name of service template to use Tux service_description DISK is_volatile 0 check_period max_check_attempts 3 normal_check_interval 5 retry_check_interval 1 contact_groups Linux notification_interval 240 notification_period notification_options c,r check_remote_disk!50%!10%!/dev/hda2 #USERS sur TUX define service{ use generic-service ; Name of service template to use Tux service_description USERS is_volatile 0 check_period max_check_attempts 3 normal_check_interval 5 retry_check_interval 1

18 contact_groups Linux notification_interval 240 notification_period notification_options c,r check_remote_users!2!4

19 6. Développement d un plugin Voici le plugin réalisé pour tester l état d une interface du routeur par une requête SNMP : #!/bin/sh # parametres : # $1 : adresse IP de l hote a tester # $2 : numero de l interface a tester # 1=FastEthernet0, # 2=Serial0, # 3=Serial1, # 4=Null # definition des valeurs de retour possibles OK=0 WARNING=1 CRITICAL=2 UNKNOWN=3 # test de la syntaxe de l appel du plugin if [ $# -ne 2 ] ; then # affichage d un message d erreur echo "usage : $0 <host> <interface_number>" exit $UNKNOWN fi # requete SNMP retour=`snmpget $1 c public v 2c ifoperstatus.$2` # est-ce que l interface est up? rt=`echo $retour grep up` # si elle n est pas up : if [ -z "$rt" ] ; then # est-ce qu elle est down? rt=`echo $retour grep down` # si elle n est ni up ni down : if [ -z "$rt" ] ; then echo "interface $2 state is unknown" exit $UNKNOWN fi fi # si elle est down : echo "interface $2 is down" exit $CRITICAL # si elle est up : echo "interface $2 is up" exit $OK

20 Ce programme respecte les règles des plugins nagios : il affiche une courte chaîne de caractères sur la sortie standard et renvoie un entier entre 0 et 3 correspondant à l état du service testé. Ce programme a été nommé check-snmp, rendu exécutable et placé dans le répertoire contenant les autres plugins nagios. Une nouvelle commande a ensuite été définie dans le fichier checkcommands.cfg : # 'check_interface' command definition define command{ command_name check_interface command_line $USER1$/check-snmp $HOSTADDRESS$ $ARG1$ Cette entrée fait la correspondance entre le nom de la commande nagios qui sera utilisé dans le fichier services.cfg et la ligne de commande à utiliser. Le paramètre $HOSTADDRESS$ est automatiquement rempli par Nagios et le paramètre $ARG1$ sera passé sur la ligne de commande dans le fichier services.cfg. Il faut enfin créer une entrée dans le fichier services.cfg : #Serial 0 sur Router define service{ use generic-service Router service_description SERIAL 0 is_volatile 0 check_period max_check_attempts 3 normal_check_interval 5 retry_check_interval 1 contact_groups Network notification_interval 240 notification_period notification_options c,r check_interface!2 Il ne reste plus qu à relancer le service Nagios pour que les modifications soient prises en compte.