Discussion :

[nicoho]

Bonjour à tous,

Celà fait quelques années que je viens "picorer" des informations sur votre forum et je vous remercie pour tout ce que j'ai pu en tirer.

Aujourd'hui un problème se pose à moi et je n'ai pas trouvé de solution qui me convienne.

Je parcours actuellement les différentes possibilités pour surveiller les machines d'un réseau. L'axe de ma recherche est snmp. A terme ce projet peut déboucher sur la programmation d'un logiciel de "monitoring". Mon problème vient du fait que je n'ai pas tout à fait compris le fonctionnement des traps. D'après ce que j'en ai compris, les traps sont générées par l'agent snmp, cependant j'ai essayé sur une plate forme xp et je n'ai pas trouvé moyen de paramétrer ces traps.

Ma question est : est ce que l'agent snmp inclut dans windows xp permet ce genre de configuration ? Si oui comment et si non quelle solution peut on envisager pour générer ces traps (installation d'un autre agent : lequel ? je ne pense pas qu'en coder un soit réellement une bonne idée car celà prendrait beaucoup de temps rien que pour refaire ce qui est déjà disponible sur l'agent 'de base' et en plus le parc sur lequel je travail comporte plusieurs sorte d'os et j'imagine que ce genre de développement est très spécifique à un os, le temps passé a ce genre de développement serait donc multiplié par le nombre d'os présent dans le parc.).

J'ai bien trouvé une partie de la MIB (iso.org.dod.internet.mgmt.mib-2.rmon.alarm) en lecture / ecriture et qui visiblement permet de régler les traps a générer cependant cette branche de la mib n'a pas l'air d'être présente sous windows xp, maintenant je ne sais pas s'il est possible de l'ajouter.

Donc si quelqu'un possède les connaissances ou même une piste je le remercie d'avance.

[nicoho]

Alors pour transformer un évènement système en trap snmp sous windows, on peut visiblement utiliser : Evntcmd.exe ainsi que sont petit amis plus graphique Evntwin.exe.. cependant certaines traps ne semblent pas être générées, ou pas captées (j'utilise SNMP Trap Watcher, parce que c'est le premier que j'ai trouvé, ce qui veut dire que ce n'est pas forcement le meilleur.).

Donc mon problème est résolu en théorie mais en pratique ça ne marche qu'a moitié (et encore).

[nicoho]

Afin de continuer mon auto-réponse, j'ai regardé ce qui transitait sur la boucle locale quand les events system n'était pas capté sous forme de trap, la réponse est : rien. On peut donc en conclure que ces fameux events system ne sont pas générés. La grande question reste de donc pourquoi.

Dans le même genre "agents snmp casse bonbon" je vous présente net-snmp. Je me suis penché sur l'aspect snmp d'un post linux. J'ai donc installer net-snmp (installation s'est bien déroulé mis à part un problème avec "ld -lelf" résolu grace à la FAQ et une incompatibilité avec la versions pearl présente, résolu avec l'otpion "DONT_CHECK_VERSIONS" ou un truc du genre).

J'ai donc configuré (snmpd.conf) mon démon snmp et je l'ai lancé.

Le problème vient du fait que si j'essai :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

snmpget -v 1 -c public localhost .1.3.5.1.2.1.1.3.0

J'obtiens :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Error in packet
Reasion: (noSuchName) There is no such variable name in this MIB.
Failed object: SNMPv2-SMI::org.5.1.2.1.1.3.0

si je fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

snmpwalk -v 1 -c public localhost .1.3.5.1.2.1.1.3.0

J'obtiens

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

End of MIB

Je comprend mal ou se trouve le problème, si quelqu'un pouvait m'aider : ça m'aiderait !

PS : Je travail avec fedora core 4 et la versions de net-snmp est la 5.4.

[nicoho]

Honte à moi ...l'erreur venait du fichier de configuration, dans la partie view j'avais écris "inclued" a la place de "included"... Je m'en suis rendu compte en lançant le démon snmp dans un mode un peu plus verbeux.

Cependant je compte bien vous harceler jusqu'à la fin (ça va pour le moment c'est pas trop violent je pose des questions et j'y réponds tout seul :p ) Je ne m'en sort vraiment pas avec les traps sous linux. En fait je ne comprend pas bien s'il faut modifier la MIB et ensuite l'agent envoie un trap quand cette partie de la MIB atteind une valeur, ou s'il faut tout simplement faire un script qui scrute ce que l'on veut observer (taille disk, etc) et qui utilise snmptrap lorsque ces valeur atteignent un seuil prédéfinis. Sur ce coup là je suis certains que vous allez tous me répondre

[nicoho]

Le retour des questions sans réponses :

Existe-t-il un moyen de générer une trap snmp à partir d'un évènement syslog ?

[Théolude]

s'il faut tout simplement faire un script qui scrute ce que l'on veut observer (taille disk, etc) et qui utilise snmptrap lorsque ces valeur atteignent un seuil prédéfinis. Sur ce coup là je suis certains que vous allez tous me répondre

Bonjour,

Je suis en train de galérer également sur les traps sur Linux DEBIAN... En ce qui concerne ta question, c'est ta deuxième proposition qui AMHA est bonne. La MIB en elle même ne fixe pas de valeurs, elle est un simple dictionnaire. Par contre il doit exister des agents SNMP qui doivent pouvoir s'exécuter tout seul, surveiller ces seuils et générer les traps que tu géreras ensuite à ta sauce...

En ce qui concerne la gestion des traps par contre je cale, je lance un trap (sous Linux) avec snmptrap, avec cette syntaxe minimaliste et une MIB non traduite pour éviter les erreurs de MIB.

snmptrap -v 1 -c public 192.168.10.101 .0.1.2.3 192.168.10.101 2 5 ""

A la suite de ce *magnifique* exemple de trap, voici ce que je récupère:
trace: read_config(): read_config.c, 738:
read_config: /etc/snmp/snmp.conf:25 examining: dumppacket no
trace: read_config(): read_config.c, 659:
read_config: /etc/snmp/snmp.local.conf: No such file or directory
trace: read_config(): read_config.c, 659:
read_config: /usr/share/snmp/snmp.conf: No such file or directory
trace: read_config(): read_config.c, 659:
read_config: /usr/share/snmp/snmp.local.conf: No such file or directory
trace: read_config(): read_config.c, 659:
read_config: /usr/lib/snmp/snmp.conf: No such file or directory
trace: read_config(): read_config.c, 659:
read_config: /usr/lib/snmp/snmp.local.conf: No such file or directory
trace: read_config(): read_config.c, 659:
read_config: /root/.snmp/snmp.conf: No such file or directory
trace: read_config(): read_config.c, 659:
read_config: /root/.snmp/snmp.local.conf: No such file or directory
trace: read_config(): read_config.c, 678:
read_config: Reading configuration /var/lib/snmp/snmp.conf
trace: read_config(): read_config.c, 738:
read_config: /var/lib/snmp/snmp.conf:19 examining: dodebugging 0
trace: run_config_handler(): read_config.c, 441:
read_config: Found a parser. Calling it: dodebugging / 0

Snif, Snif, j'ai mal

Merci de votre aide !!

[fara morgana]

Bonjour,

Bon j'espère que c'est pas trop tard, je vais donc être clair, du moins je l'espère.

Cependant mon expérience porte sur Linux et non Windows mais j'espère que cela vous eclairera quand même.

Alors voila:

snmptrap est un daemon qui écoute les traps SNMP circulant sur le port UDP 162.

Il faut configurer le fichier “/etc/snmp/snmptrap.conf” pour exécuter des commandes “traphandle” qui vont permettre d'exécuter d'autres scripts (SHELL ou PERL ou PYTHON) selon le trap reçu.
Voyons dans un premier temps comment configurer ce deamon, et nous verrons ensuite comment récupérer ces données et les traiter.

Configuration

Il y a deux fichiers à configurer, le premier (snmpd.conf) permet d'autoriser les traps à arriver sur votre poste, et donc de recevoir les traps; le second (snmptrapd.conf) permet de spécifier le format des traps et de les traiter.

Premier fichier : /etc/snmp/snmpd.conf

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#SECTION Trap Destinations

#trapcommunity: Defaut trap sink community to use
#arguments: community string

trapcommunity secret

#trapsink: A SNMPv1 trap receiver
#arguments: host [community][portnum]

trapsink localhost
trapsink network //définie dans le fichier de conf de snmp et représente le réseau
// on peut également spécifier par adresse IP, 
// ex : trapsink 192.168.10.42

#inform: A SNMPv2 inform (acknowedged trap receiver)
#arguments: host [community][portnum]

informsink localhost
informsink network

#authtrapenable: Should we send traps when authentification failures occur
#arguments: 1|2 (1=yes, 2=no)

authtrapenable 1

Après création du fichier snmpd.conf avec les valeur décrites précédemment et recopie sous /etc/snmp/snmpd.conf, il ne reste plus qu'à lancer l'agent snmpd :
# /etc/rc.d/init.d/snmpd restart
On pourra lancer dans une autre fenêtre un sniffer réseau comme tcpdump pour voir les échanges agent SNMP/manager SNMP :
# tcpdump -vv -i lo

Deuxième fichier: /etc/snmp/snmptrapd.conf

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
format2 %02.2l/%02.2m/%y %02.2h:%02.2j:%02.2k %W de %A\n
disableAuthorization yes
doNotRetainNotificationLogs yes
traphandle default /var/www/html/recuptraps.pl

Ensuite on fait un test de compilation :
/usr/sbin/snmptrapd -c /etc/snmp/snmptrapd.conf
Si aucune erreur n'est renvoyée, le fichier de configuration est correct.
On peut alors tester la réception des traps avec la commande “snmptrap -Le -f”.
Et pour envoyer des traps « manuellement », le paquet net-snmp contient le programme snmptrap.

Ainsi sur deux terminaux différents, on pourra tester :

(1)[root@pc]# snmptrapd -f -Le
(3)2006-05-29 11:33:14 0.0.0.0(via UDP: [192.168.10.54]:32920) TRAP, SNMP v1, community secret
HOST-RESOURCES-MIB::hrProcessorLoad.8 Warm Start Trap (0) Uptime: 0:00:00.01

(2) [root@pc]# snmptrap -v1 -c secret 192.168.10.54 .1.3.6.1.2.1.25.3.3.1.2.8 0 1 i 1

(1) On lance le programme snmptrapd pour récupérer des traps
(2) dans un autre terminal, on lance la commande permettent de générer une trap
(3) On récupère bien la trap
On remarque que l'arrivée des traps se fait plus ou moins avec la même syntaxe que lors de la réception de celles-ci avec le sniffer. Mais on peut aller encore plus loin pour voir les détails.

Revenons à la configuration du fichier snmptrapd.conf, et expliquons l'utilité de chaque ligne:

La première ligne format2 %02.2l/%02.2m/%y %02.2h:%02.2j:%02.2k %W de %A\n
permet de spécifier le format des données reçues. Compte tenu de la complexité de sa mise en place, je préfère vous épargner les détails.

L'option disableAuthorization a été introduite pour des raisons de sécurité et est devenue obligatoire avec la version 5.3 du paquet net-snmp. Cette option n'est pas reconnue par les versions antérieures.

Mettre « doNotRetainNotificationLogs yes » permet d'annuler le support de NOTIFICATION-LOG-MIB. Normalement, le programme snmptrapd conserve les traps reçues, lesquelles peuvent être récupérées par la suite. Cependant beaucoup (trop) de trap sont reçues et la plupart sont inutiles. Ainsi pour ne pas encombrer l'information utile, traiter directement les données afin de les rentrer dans une base.

Enfin la commande « traphandle » permet de lancer un script quand une trap est reçue. Ainsi à chaque traps, la liste des trap handle est consultée et le programme associé est lancé. S'il ne trouve pas de handle, n'importe quel handler « default » est lancé. L'information contenue dans la trap est passée au programme via la sortie standard.
J'aurais pu mettre par exemple:
traphandle IF-MIB::linkDown /usr/bin/php /var/www/html/snmphandler.php
traphandle IF-MIB::linkUp /usr/bin/php /var/www/html/snmphandler.php
..., etc.
Ainsi pour chaque type de trap, on peut lancer un programme différent, ce qui est très efficace si l'on souhaite filtrer les données ou effectuer une action particulière selon une trap spécifique reçue.

Faites un programme général qui récupère toutes les traps pour les stocker dans un fichier texte.
(y'en a sur le net)

Pour finir, il ne faut pas oublier d'ouvrir le port 162 pour permettre aux traps d'arriver sur le poste.

Ainsi après exécution du programme, nous obtenons des données de la forme:

New trap received: jeu jun 29 15:58:28 CEST 2006 for

HOST: 192.168.10.9
IP: UDP: [192.168.10.9]:50439
TRAP: DISMAN-EVENT-MIB::sysUpTimeInstance 0:7:31:25.56
TRAP: SNMPv2-MIB::snmpTrapOID.0 SNMPv2-SMI::enterprises.9.0.1
TRAP: SNMPv2-SMI::enterprises.9.2.9.3.1.1.1.1 5
TRAP: TCP-MIB::tcpConnState.192.168.10.9.80.192.168.10.57.1438 finWait2
TRAP: SNMPv2-SMI::enterprises.9.2.6.1.1.5.192.168.10.9.80.192.168.10.57.1438 11
TRAP: SNMPv2-SMI::enterprises.9.2.6.1.1.1.192.168.10.9.80.192.168.10.57.1438 19
TRAP: SNMPv2-SMI::enterprises.9.2.6.1.1.2.192.168.10.9.80.192.168 10.57.1438 168
TRAP: SNMPv2-SMI::enterprises.9.2.9.2.1.18.1 ""
TRAP: SNMP-COMMUNITY-MIB::snmpTrapAddress.0 192.168.10.9
TRAP: SNMP-COMMUNITY-MIB::snmpTrapCommunity.0 "secret"

On remarque que les informations fournies sont très complètes et suffisantes. Il ne reste donc plus qu'à traiter ces informations pour pouvoir les rentrer dans la base.

Voila en gros.

[drKzs]

tiens, cette discussion est pile-poil ce que je cherchais

Donc si j'ai bien compris, il est possible de définir plusieurs traphandle par défaut ? Ce qui signifie qu'on peut définir deux méthodes de traitement de trap qui seront DANS TOUS LES CAS exécutées (et pas l'une puis l'autre) ?