PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : snmptrapd ruft traphandler nicht auf



Ironheart
30.08.07, 17:18
Hallo zusammen,

sitze nun schon seit mehreren Tagen vor einem Problem, welches ich nicht wirklich verstehe:

ein Monitoring-Server, auf welchem u.a. Nagios läuft, soll SNMP-Traps verarbeiten. Also läuft dort 'snmptrapd', welcher eigentlich die eingehenden Traps an den in der /etc/snmp/snmptrapd.conf eingetragenen Traphandler weiterreichen soll. Die entsprechende Konfigurationsdatei sieht so aus:



traphandler default /usr/local/bin/testscript

bzw. ab net-snmp-5.3.* kommt diese Zeile hinzu:


authCommunity log,execute,net public

bzw. das komplette Deaktivieren der Authentifizierung hat auch nichts geändert:


disableAuthorization yes


Der snmptrapd wird mit folgenden Parametern aufgerufen:


/usr/sbin/snmptrapd -Lsd -p /var/run/snmptrapd.pid -Lf /var/log/snmp/snmptrapd.log


Im Logfile sind die eingehenden Traps auch sichtbar, der Traphandler selbst wird aber nie ausgelöst:


2007-08-30 16:32:29 NET-SNMP version 5.1.2 Started.
2007-08-30 16:33:03 10.1.10.116(via 10.1.10.116) TRAP, SNMP v1, community public
SNMPv2-SMI::enterprises.232 Enterprise Specific Trap (11003) Uptime: 27 days, 19:54:41.20
SNMPv2-MIB::sysName.0 = STRING: SERVERFS01 SNMPv2-SMI::enterprises.232.11.2.11.1.0 = INTEGE
R: 0 SNMPv2-SMI::enterprises.232.11.2.8.1.0 = STRING: "Management Agents Test Trap sent - Donnerstag,
30. August 2007 16:33:03"


Habe die ganze Angelegenheit auf einem Server mit RHEL4 nachgestellt, dort kommt net-snmp-5.1.2-11 zum Einsatz und es hat auf Anhieb funktioniert: der Traphandler wurde aufgerufen. Beim Traphandler handelt es sich zu Testzwecken lediglich um ein Script, welches die aktuelle Uhrzeit in ein File dumpt. Dieses Script ist für alle User ausführbar, d.h. an den Berechtigungen kann es nicht liegen.

Folgendes habe ich bereits getestet:

Verschiedene net-snmp Versionen (5.1.2, 5.3.1, 5.4.1)
löschen sämtlicher alter Konfigurations-/Logfiles und Neuinstallation
Analyse des 'snmptrapd'-Prozesses mit 'strace' vom Start bis zum eingehenden Trap
SELinux ist deaktiviert
Berechtigungen auf sämtliche Konfigurations-/Logdateien sind korrekt
Aufruf von snmptrapd mit dem Parameter -Dread_config - alle Configfiles wurden ordnungsgemäß gefunden und verarbeitet, der angegebene Traphandler wurde im Output auch als 'registriert' angegeben.


Hat noch jmd eine Idee, woran es liegen könnte, dass der Traphandler auf einem Server (RHEL5) nicht aufgerufen wird, während es auf dem Anderen (RHEL4) mit der exakt selben SNMP-Konfiguration funktioniert?

Vielen Dank im Voraus

Gruß, Elias P.

403
01.09.07, 19:46
Hi,

Ich denke das liegt an nagios, wenn auf dem anderen System kein nagios zum Einsatz kam. (Dem frueheren Testsystem)

Bzw, liegt es an der unterschiedlichen Konfiguration, das nagios meint, es muesse noch keine Aktion ausloesen, oder du hast dortdrin irgendeine Information IP Adresse? nicht aktualisiert?

Hast du snmpdtrapd mal mit -DALL probiert?

Gruss 403

Ironheart
01.09.07, 19:59
Nagios kommt erst zu einem viel späteren Zeitpunkt, wenn der Trap durch den Translator verarbeitet wurde ins Spiel.

Da momentan aber noch nicht einmal der Translator aufgerufen wird, scheidet Nagios aus.

Das Problem muss innerhalb von snmptrapd bzw. dessen Konfiguration liegen.

Das Seltsame ist, dass ein '-Dread_config' mir noch anzeigt, dass der traphandler registriert sei, aber diesen in keinster Weise auslöst.

Mit -DALL habe ich es noch nicht probiert, werde das aber mal tun. Vermutlich wird aber nicht sehr viel mehr dabei herauskommen, denn selbst ein 'strace', welches mir ja sämtliche Systemcalls etc. ausgibt, hat nicht einmal etwas annähernd in Richtung "Suche/Aufruf eines traphandlers" ausgegeben.

Gruß, Elias P.