Ich habe an einer benutzerdefinierten SNMP-Mib gearbeitet und bin dabei auf eine Wand gestoßen, während ich versucht habe, einen Agenten dazu zu bringen, die richtigen Daten zurückzugeben.
MIB (validiert durch Ausführen von smilint -l 6 ):
Agentendatei:
%Vor%Wenn ich den Agenten starte, bekomme ich Folgendes:
%Vor%Ich weiß also, dass viel funktioniert. Allerdings, wenn ich den folgenden Befehl ausführen:
%Vor%Ich bekomme diese Fehlermeldung:
%Vor%Ich weiß von snmptranslate, dass die MIB-Datei korrekt eingestellt ist. Ich habe sogar das Debugging für snmpget (mit -DALL) durchgesehen, um sicherzustellen, dass die mib korrekt geladen und analysiert wird.
Meine Frage ist also: Warum wird mein Subagent die Anfrage nicht bestanden?
Aktualisierung:
Ich habe von @EhevuTov erfahren, dass meine MIB-Datei nicht gültig ist, smilint meldet jedoch keine Probleme, und wenn snmpget -v 2c -c mycommunity localhost:161 .1.3.6.1.4.1.42134.3.0 ausgeführt wird, wird der NAME des Objekts (IDB-MIB :: test2.0) korrekt gemeldet. findet aber keine Daten dafür.
Ich erhalte IDB-MIB::test2 = No Such Object available on this agent at this OID , was mich denken lässt, dass mein Agent nicht richtig registriert wird, aber es wirft keine Fehler auf.
Update 2:
Ich habe ein bisschen mit dem Agentencode herumgespielt. Basierend auf der CPAN-Dokumentation ( Ссылка ) sieht es so aus, als ob der $agent->register Funktionsaufruf 0 zurückgeben soll. Falls erfolgreich. Also überprüfte ich den Rückgabecode und bekam folgendes:
Das Ausdrucken mit Data::Dumper führt zu:
Ich verstehe vage, was Segen bedeutet, aber trotzdem habe ich keine Ahnung, was dieses Ergebnis bedeuten soll. Ich fange an zu denken, dass der Agent irgendwie falsch ist. Kann jemand diese Agenten debuggen? Kann ich irgendwo sehen, ob es richtig in den Master-snmpd geladen wird?
Und ich habe das Problem gelöst. Es war nicht mit der MIB, es war mit dem Agenten (von dem ich dachte, dass es die ganze Zeit in Ordnung war, also habe ich mich nie darum gekümmert, es zu überprüfen).
Ich hatte den Agenten eigenständig laufen lassen, weil es so aussah, als ob es gut funktionierte (es gab nie irgendwelche Fehler bei der Registrierung des Handlers). Offensichtlich muss es direkt von snmpd ausgeführt werden.
Ich habe es in ein Verzeichnis verschoben, auf das snmpd zugreifen kann (weil anscheinend auch snmpd keine Skripts von / root ausführen kann, obwohl es als root läuft), und fügte diese Zeilen in snmpd.conf hinzu:
%Vor%Beachten Sie, dass diese zwei Zeilen bereits vorhanden waren:
%Vor%Ich kann jetzt den Befehl snmpget ausführen und die erwartete Antwort erhalten.
%Vor%