Conception, Implémentation d'une Base de Données pour la Gestion d'un Organisme et Administration Réseau à distance sur base des outils libres "Cas de Projet Limete Université Cardinal Malula"

Chapitre 7. LES TRAPS

7.1 UTILISATION DES TRAPS AVEC NAGIOS

Le protocole SNMP définit aussi un concept de trap. Une fois défini, si un certain évènement se produit, comme par exemple le dépassement d'un seuil, l'agent envoie un paquet UDP (port 162) à un serveur. Ce processus d'alerte est utilisé dans les cas où il est possible de définir simplement un seuil d'alerte. Dans nombres de cas, hélas, un alerte réseau ne devrait être déclenchée qu'en unissant plusieurs événements.

7.2 CONFIGURATIONS

Une petite configuration est nécessaire coté serveur et coté client pour que les traps puissent fonctionner. Au projet Limete/Université Cardinal Malula nous Commencerons par le client.

7.2.1 Coté client (l'agent)

Tout d'abord, il faut éditer le fichier /etc/snmp/snmpd.conf et ajouter les lignes suivantes à la fin du fichier. Pour nos tests, nous utiliserons la communauté « public ».

# Définit la communauté par défaut à utiliser quand les traps seront envoyées. trapcommunity public

# Envois des traps de version 1 - HOTE où se trouve le daemon snmptrad [Community [Port]] trapsink 192.1 68.88.129 public 162

# Envois des traps de version 2

trap2sink 192.1 68.88.129 public 162

#Utilisé lors d'envois d'inform ã la place des traps

informsink 192.1 68.88.129 public 162

# Envois de traps lors d'authentification ratée

authtrapenable 1

# Permet d'envoyer des traps lors du changement d'état (Down/Up) des interfaces réseaux

linkUpDownNotifications yes

# Envois des traps pour une liste de problèmes généraux defaultMonitors yes

7.2.2 Coté serveur

Premièrement, il faut créer (ou éditer) le fichier /etc/snmp/snmptrapd.conf et ajouter les lignes suivantes à la fin du fichier.

# On traite de la même façon toutes les interruptions : avec SNMPTT

traphandle default /usr/sbin/snmptt

# On accepte toutes les interruptions

disableAuthorization yes

#on ne journalise pas les interruptions reçues (c'est SNMPTT qui s 'en chargera). On aura quand même une trace de snmptrapd dans syslog, grâce à l'option -Lsd du lanceur (voir ci-dessous). donotlogtraps yes

Pour la petite histoire, snmptrad passe à SNMPTT les éléments de l'interruption qu'il a reçus via les paramètres de la ligne de commande.

Le lanceur du service snmptrapd doit être modifié pour ne pas traduire les OID, mais les laisser sous forme numérique. C'est SNMPTT qui fera la traduction. Il faut modifier /etc/init.d/snmptrapd :

OPTIONS="-On -Lsd -p /var/run/snmptrapd.pid" # Il faut rajouter le -On

Après modification, il suffit de redémarrer le daemon snmptrapd.

7.3 NAGIOS DOIT COMPRENDRE, SNMPTT L'AIDE.

SNMPTT^6(*) (SNMP Trap Translator v1.2beta2) est un handler de trap écrit en Perl pour être utilisé avec le programme snmptrapd de Net-SNMP.

7.3.1 Fonctionnement général

1. Un hôte sur le réseau (ou plutôt une application de cet hôte) envoie une interruption SNMP au serveur qui héberge Nagios. Celui-ci la reçoit via le service snmptrapd (qui est en écoute sur le port UDP 162).

2. Snmptrapd la passe ensuite à SNMPTT, dont le rôle est de rendre intelligible l'interruption.

Pour cela, il se base sur la MIB de l'application émettrice, que l'on aura bien sûr récupérée et transformée au préalable pour en nourrir SNMPTT.

3. SNMPTT envoie enfin l'interruption interprétée à Nagios, via le fichier de commandes externes de celui-ci. Il utilise pour cela la commande Nagios submit_check_result.

Dans notre configuration de Nagios, il n'y a qu'un service par hôte qui reçoit les traps SNMP. Cela signifie que si plusieurs traps sont reçus en provenance d'un même hôte, seul le dernier sera affiché.

Par contre, chaque trap reçu générera bien une notification. Pour acquitter une interruption dans Nagios, il faut soit forcer un check immédiat du service (qui fera un ping et remettra l'état à OK), soit soumettre manuellement un check passif, avec l'intitulé "Init", ou "RAZ", par exemple.

7.3.2 Configuration

Nous allons faire fonctionner SNMPTT en mode "stand-alone" ; il sera appelé chaque fois que nécessaire par le gestionnaire d'interruptions snmptrapd. L'initialisation est plus longue dans ce cas, mais le paramétrage plus simple.

Le fichier de configuration /etc/snmp/snmptt.ini doit contenir : [General]

mode = standalone

multiple_event = 1

dns_enable = 1

strip_domain = 1

strip_domain_list = <<END

mon.domaine

END
resolve_value_ip_addresses = 0 net_snmp_perl_enable = 1

net_snmp_perl_best_guess = 0 translate_log_trap_oid = 0

translate_value_oids = 1

translate_enterprise_oid_format = 1 translate_trap_oid_format = 1 translate_varname_oid_format = 1 translate_integers = 1

wildca rd_expansion_separator = " " allow_unsafe_regex = 0

remove_backslash_from_quotes = 0 dynamic_nodes = 0

description_mode = 0

description_clean = 1

[Logging]

stdout_enable = 0

log_enable = 1

log_file = /var/log/snmptt.log

unknown_trap_log_enable = 1

unknown_trap_log_file = /var/log/snmpttunknown.log

statistics_interval = 0

syslog_enable = 1

syslog_facility = local0

syslog_level_debug = <<END

END

syslog_level_info = <<END

END

syslog_level_notice = <<END

END

syslog_level_warning = <<END

END

syslog_level_err = <<END

END

syslog_level_crit = <<END END

syslog_level_alert = <<END END

syslog_level = info

syslog_system_enable = 1 syslog_system_facility = local0 syslog_system_level = warning

[Exec]

exec_enable = 1

pre_exec_enable = 0 unknown_trap_exec =

[Debugging]

DEBUGGING = 0

DEBUGGING_FILE =

DEBUGGING_FILE_HANDLER =

[TrapFiles]

snmptt_conf_files = <<END /etc/snmp/snmptt.conf END

7.3.3 A noter :

Le nom de domaine à supprimer pour ne garder que le nom d'hôte, qui devra être adapté ã l'environnement on travaille, et le fait que le module Perl net-snmp est activé. Il permet l'interprétation étendue des OID.

7.3.4 Compilation des mibs

Il faut maintenant récupérer le ou les fichiers MIB des équipements à superviser, pour les convertir au format SNMPTT. Le but est d'extraire ce qui dans le fichier MIB est un commentaire, pour que SNMPTT le mette en correspondance avec l'OID qui sera reçu.

snmpttconvertmib --in=<fichier MIB> --out=/etc/snmp/snmptt.conf.<equipement> \ --

exec='/usr/local/nagios/libexec/eventhandlers/submit_check_result $r TRAP 1'

Dans le cas où on aurait trop de MIB, on peut exécuter le petit script suivant en tenant compte que toutes les mibs se trouvent dans /usr/share/snmp/mibs/ :

for i in /usr/share/snmp/mibs/ *.txt

> do

> /usr/sbin/snmpttconvertmib --in=$i --out=/etc/snmp/snmptt.conf \ --exec='/usr/lib/nagios/plugins/eventhandlers/submit_check_result $r TRAP 1

> done

Ce qui va donc permettre de prendre en compte toutes les mibs dans le répertoire précédemment cité et les ajouter dans le fichier snmptt.conf. On aura quelques lignes dans le genre :

EVENT coldStart .1.3.6.1.6.3.1.1.5.1 "Status Events" Normal

FORMAT A coldStart trap signifies that the SNMP entity, $*

EXEC /usr/lib/nagios/plugins/eventhandlers/submit_check_result $r TRAP 1 "A coldStart trap signifies that the SNMP entity, $*"

SDESC

A coldStart trap signifies that the SNMP entity,

supporting a notification originator application, is

reinitializing itself and that its configuration may

have been altered.

Variables:

EDESC

7.3.5 Dans Nagios

Le principe est d'utiliser, pour recevoir les interruptions SNMP, des services passifs mais aussi volatiles, car si nous recevons une deuxième interruption pour le même hôte avant que la première ait été remise à OK, nous voulons être notifié à nouveau.

Pour cela, il faut (par exemple) définir un service générique pour les traps SNMP, dérivé de mon service générique général :

define service{

name snmptrap-service

use generic-service

register 0

service_description TRAP

is_volatile 1

check_command check-host-alive

max_check_attempts 1

normal_check_interval 1

retry_check_interval 1

passive_checks_enabled 1

check_period none

notification_interval 31536000

contact_groups admins
}

Et le dériver pour chaque machine supervisée, par exemple :

define service{

host _name Ubuntu

use snmptrap-service

contact_ groups admins

}

Tout d'abord, il y a la commande check-host-alive (un simple ping) qui permet de remettre à OK l'état du service en forçant un contrôle actif. D'autre part, l'intervalle de notification est artificiellement long : un an ici. Il permet d'éviter de recevoir régulièrement des notifications pour la même interruption (tant que le service n'est pas ramené à l'état OK), laissant penser qu'une nouvelle interruption, identique à la précédente, a été reçue. Le problème est qu'il faut redémarrer Nagios au moins une fois par an.

7.3.6Quelques Tests

Coté client (agent), il suffit de redémarrer simplement le daemon SNMPD pour qu'un évènement se produise dans les logs du serveur (manager) :

# tail -f /var/lo g/snmptt.log

Tue May 29 14:20:38 2007 .1.3.6.1.4.1.8072.4.0.2 Normal "Status Events" 192.1 68.88.1 28 - An indication that the agent is in the process of being shut down.

Tue May 29 14:20:40 2007 .1.3.6.1.6.3.1.1.5.1 Normal "Status Events" 192.1 68.88.128 - A coldStart trap signifies that the SNMP entity,

* ⁶ http://www.snmptt.org