SNMP


Opis

Moduł SNMP jest modułem zewnętrznym jPalio służącym do komunikacji jPalio z urządzeniami obsługującymi protokół snmp w wersjach 1,2c i 3. Umożliwia on:

Moduł ten jest modułem typu EXTERNAL, co oznacza, że domyślnie nie jest widziany przez jPalio, wymagana jest do tego konfiguracja w pliku instancji.

Status modułu

Listener może działać na jeden z trzech sposobów (INSTANCE, INSTANCE_LISTENER, GLOBAL_LISTENER) oraz znajdować się w jednym z pięciu stanów (FAILED, STOPPED, CREATING, LIMITED_LISTENING, LISTENING), jeśli został już uruchomiony, można to sprawdzić wykonując:

$snmp.getEngineType()
$snmp.getEngineState()

Typu modułu:

Określa typ listenera obsługującego nadchodzące pakiety:

Stany modułu:

Określają w jaki sposób działa mechanizm obsługi protokołu snmp:

Zobacz także:


[SNMP] Opis
 

Przykłady

Pobieranie/ustawianie zmiennych

Pobierać i ustawiać dane można w sposób asynchroniczny lub synchroniczny.

W przypadku zapytań synchronicznych(przyrostek S) funkcja zawsze zwraca odpowiedź, ale odpowiedź ta czasem nie będzie zawierała danych i posiadała status błędnej z różnych przyczyn (upłynął czas oczekiwania, niepowodzenie podczas uwierzytelnienia, itp.). Odpowiedź zostanie dostarczona w postaci obiektu klasy SnmpResponse, który przy pomocy metod modułu może zostać przekształcony na String albo tablicę. Odpowiedź w postaci tablicy zawiera trzy kolumny, minimum jeden wiersz (postaci: [status, tekstowo status, id żądania]) oraz kolejne zawierające dane, których zapytanie dotyczyło w postaci [oid,wartość,typ], dodatkowych wierszy będzie tyle, ile oidów zwierało zapytanie.

Wykonywanie zapytań asynchronicznych(przyrostek A) zawsze zwraca liczbę, będącą identyfikatorem zapytania - zależnie od sposobu przetwarzania odpowiedzi będzie ją można pobrać na podstawie tego numeru (np z bazy danych, bufora modułu, innego własnego mechanizmu). Tak otrzymaną odpowiedź można wykorzystywać w sposób identyczny jak odpowiedź otrzymaną z zapytania synchronicznego.

$snmp.getS("2c", "192.168.0.150:161", "public", "1.3.6.1.2.1.1.4.0")
$snmp.getA("3", "192.168.0.150:161", "torn", "1.3.6.1.2.1.1.4.0")

Wykonanie obiektu o poniższym kodzie(użytkownik torn, został wcześniej dodany), dla odmiany kod Groovy:

import palio.*
import palio.modules.*

Long requestId = Groovy.module("snmp").getA("3", "192.168.0.150:161", "torn", "1.3.6.1.2.1.1.4.0")
println requestId
palio.modules.snmp.model.SnmpResponse response = Groovy.module("snmp").getS("2c", "192.168.1.196:161", "public", "1.3.6.1.2.1.1.4.0")
println response
println response.toArray()

Będzie mieć taki efekt:

772159757
statusText: Success; status: 0; type: RESPONSE; error index: 0; requestId: 772159758; values: (oid: 1.3.6.1.2.1.1.4.0; value: o2; type: OCTET STRING; typeId: 4)
[[0, Success, 772159758], [1.3.6.1.2.1.1.4.0, OCTET STRING, o2]]

Można podawać także tablice oidów. W przypadku ustawiania zmiennych dodatkowo podaje się wartość i typ, typ jest opcjonalny, ale sprawdzenie typu odbywa się poprzez wykonanie zapytania o typ, nie każdy węzeł musi mieć uprawnienia do odczytu, zatem jeśli tym jest znany, warto go podawać.

$snmp.setA("1", "192.168.0.150:161", "public", "1.3.6.1.2.1.1.4.0", "o2", "OctetString")

Przetwarzanie odpowiedzi

Przetwarzanie odpowiedzi wewnątrz modułu

Odpowiedzi napływają do kolejki modułu, a następnie są przetwarzane przez listenery, moduł zawiera trzy podstawowe:

Należy tu zwrócić uwagę, iż nie są to listenery o których jest mowa w nasłuchiwaniu modułu na pakiety - są to listenery nasłuchujące na gotowe odpowiedzi klasy SnmpResponse, skądkolwiek one znalazły się w kolejce modułu.

Możliwa jest rejestracja własnego listenera w module, należy jedynie stworzyć klasę implementującą EventListener, a następnie zarejestrować ją przy pomocy metody modułu. Obecnie listenery można dodawać jedynie gdy manager kolejki nie jest uruchomiony, co oznacza, że jeśli instancja miała skonfigurowane i włączone wbudowane listenery oraz zostały one automatycznie uruchomione, poniższy kod nie będzie miał efektu.

EventListener<SnmpResponse> listener = new myListener();
Groovy.module("snmp").registerResponseListener(listener);

Przetwarzanie odpowiedzi poza modułem

W przypadku implementacji snmp zawartej bezpośrednio w module lub zawartej w listenerze instancji odpowiedzi są przekazywane bezpośrednio do kolejki modułu i przetwarzane w sposób opisany w poprzednim punkcie.

W przypadku przetwarzania przez listener serwerowy, wszystkie odpowiedzi, oraz nadchodzące zgłoszenia (np. trapy) są rozsyłane do wszystkich instancji, oznacza to, że każda instancja zna odpowiedzi innych instancji.

MibParser

Parser dopasowuje oid na podstawie zapisanych plików, pliki będą pamiętane w bazie, pogrupowane w rozłączne konteksty. Plik może należeć tylko do jednego kontekstu, aby użyć go w wielu kontekstach, należy dodać go do każdego z osobna.

Polecenie będzie tłumaczone w ramach podanego kontekstu, ze wszystkich plików w nim zawartych podjęta zostanie próba zbudowania drzewa poleceń i wartości. Użycie różnych kontekstów może być przydatne podczas komunikacji z urządzeniami, których pliki mib są niekompatybilne/sprzeczne.

Przykład, dodanie 2 plików, próba uzyskania komendy, oraz usuwanie plików z kontakstu:

$snmp.addMibFile("kontekst1", "nazwa1", "treść 1 miba")
$snmp.addMibFile("kontekst1", "nazwa2", "treść 2 miba")
$snmp.commandToOid("kontekst1","sysDescr")
$snmp.removeMibFile("kontekst1", "nazwa2")
$snmp.isMibContextComplete("kontekst1")
$snmp.removeContextMibFiles("kontekst1")
$snmp.removeAllMibFiles()

W rezultacie snmp.commandToOid otrzymany zostanie (albo nie) oid dla zadanego polecenia. Polecenia umożliwiają tłumaczenie, weryfikację spójności drzewa, dodawanie, usuwanie plików z kontekstów.

Uwierzytelnianie

Wersja 1 oraz 2c

W przypadku wersji protokołu 1 lub 2c nazwa użytkownika jest używana jako community string i nie potrzebne są inne zabiegi, aby pakiet został poprawnie obsłużony.

Wersja 3

Aby komunikować się protokołem w wersji 3 wymagane jest zdefiniowanie użytkowników, wraz z ich algorytmami uwierzytelnienia i prywatności oraz hasłami. Użytkownicy mogą być zapisywani do bazy danych i odczytywani przy starcie instancji. Dane użytkowników obowiązują w ramach jednej instancji, niezależnie od sposobu działania listenera, można je dodawać, usuwać oraz pobierać na podstawie nadanej, mającej charakter informacyjny nazwie.

$snmp.addV3user("torn", "SHA", "torntorn", "DES", "torntorn")

Nazwa użytkownika w przypadku wersji 3 spowoduje pobranie danych użytkownika o danej nazwie, a w przypadku wersji 1 i 2c nazwa zostanie użyta jako community string, nie będąc nigdzie zapisywana.

Uwagi

Uwierzytelnienie dla użytkownika jest opcjonalne, szyfrowanie wymaga ustawionego uwierzytelnienia.

Jeśli urządzenia posiada skonfigurowanego użytkownika o nazwie np torn oraz zdefiniowane hasła, a serwer jPalio posiada użytkownika o nazwie user oraz podanych jednakowych algorytmach i hasłach, komunikacja asynchroniczna nie dojdzie do skutku (odpowiedzi oraz trapy nie będą przetwarzane).

Aby temu zapobiec użytkownik zdefiniowany w instancji musi nazywać się tak samo jak na urządzeniu - w tym przypadku torn, zamiast user.

Konfiguracja

Nasłuchiwanie

Moduł wymaga do działania jPalio w wersji 7.2 lub wyższej, aby zapisywać zdefiniowanych użytkowników wersji 3, odpowiedzi na zapytania snmp oraz otrzymane trapy niezbędne są dodatkowe tabele. Tabele te mogą zostać automatycznie wygenrowane dla obsługiwanych przez jPalio baz danych, użytkownik nie musi tego robić ręcznie. Opcja ta jest domyślnie włączona.

Nasłuchiwanie na porcie można skonfigurować na 3 sposoby:

Kolejność wyboru jest następująca: jeśli nazwa listenera w konfiguracji nie jest podana, zostanie utworzony listener instancji, w przeciwnym przypadku instancja spróbuje się połączyć z listenerem jPalio o zadanej nazwie, zaczynając od instancyjnego, a jeśli takiego nie będzie - spróbuje się zarejestrować w globalnym.

Aktualny adres listenera można pobrać metodą getListenerAddress:

 

$snmp.getListenerAddress()

 

Tagi

Zobacz także:


[SNMP] Konfiguracja
 

Przykłady konfiguracji

instancja.xml, konfiguracja modułu:

 

<instance>
  ...
  <module name="snmp">
    <!--listenerName>inst1<⁄listenerName-->	
	
    <listenerAddress>192.168.1.167:10162<⁄listenerAddress>
    <defaultTimeout>1000<⁄defaultTimeout>
    <defaultRetries>1<⁄defaultRetries>
    
    <moduleLoggingLevel>all<⁄moduleLoggingLevel>
    <queueSize>10000<⁄queueSize>
    <queueThreads>1<⁄queueThreads>
    <logResponses>true<⁄logResponses>
    <saveResponses>true<⁄saveResponses>
    <bufferResponses>true<⁄bufferResponses>
    <responsesBufferSize>10000<⁄responsesBufferSize>
    <cacheMibCommands>true<⁄cacheMibCommands>
    <cacheMibFiles>true<⁄cacheMibFiles>
    <persistUsers>true<⁄persistUsers>
    <updateDatabase>true<⁄updateDatabase>
  <⁄module>
  ...
<⁄instance>

 

instancja.xml (cała), minimalna konfiguracja, z włączonym zapisywaniem nadchodzących pakietów do logów oraz bazy danych:

<instance type="master">

	<admin user="admin"  password="admin"⁄>

	<page default="1"⁄>

	<secure sid="3838381" algorithm="MD5"⁄>
	
	<connector name="palio" url="jdbc:postgresql:⁄⁄localhost:5432⁄testsnmp"  traceRead="true" traceWrite="true" traceExecute="true">
		<user>postgres<⁄user>
		<password>atfudb2<⁄password>
	<⁄connector>
	
	<module name="snmp">
		<listenerAddress>192.168.1.167:10162<⁄listenerAddress>
		<saveResponses>true<⁄saveResponses>
		<bufferResponses>true<⁄bufferResponses>
	<⁄module>

<⁄instance>

Zobacz także:


[SNMP] Przykłady konfiguracji
 

Schemat bazy danych

Tabele w bazie danych instancji

Od wersji jPalio 7.4 obsługiwana jest automatyczna aktualizacja oraz tworzenie tabel, o ile nie zostało to zablokowane w konfiguracji.

Struktura tabel dodawana do instacji (schemat dla Postgresa).

model
Skrypt generujący schemat: pobierz.

API

http://jpalio.torn.com.pl/modules/palio/modules/SNMP.html