Ciekawa formuła, a w zasadzie jej brak – to szkolenie odbyło się po raz pierwszy i my niejako kreowaliśmy jak będzie wyglądać w przyszłości. Ja wyniosłem wiele, więc wydaje mi się, że się udało.

Zaczęło się nietuzinkowo – dostaliśmy jakąś kopię bazy, która uległa awarii i żeby robić cokolwiek przez resztę dni, musieliśmy to odratować. Później było jeszcze ciekawiej.

Żeby było jeszcze bardziej PRO, zrobiliśmy nawet standby na ekspresie do kawy ;-)

Żeby nie było – ja też dałem coś od siebie prowadzącemu i kursantom. Promowałem Orbadę i tmux‘a!

/opt/FJSVmpd/bin/iompadm info

IOMP: vhba0
Element:
DISK: ETERNUS_DXL- 010309-0000-0002 (sdf)
PATH:
sdf 0000:02:00.0 standby "online" 11, 11, 2
sdf 0000:02:00.0 active "online" 10, 10, 0
sdf 0000:03:00.0 fail "no such device or address" 11, 11, 2
sdf 0000:03:00.0 fail "no such device or address" 10, 10, 0

DISK: ETERNUS_DXL- 010309-0000-0000 (sdg)
PATH:
sdg 0000:02:00.0 standby "online" 11, 11, 2
sdg 0000:02:00.0 active "online" 10, 10, 0
sdg 0000:03:00.0 fail "no such device or address" 11, 11, 2
sdg 0000:03:00.0 fail "no such device or address" 10, 10, 0

Nie zwracajcie uwagi na fail na jednej karcie – chwilowo światłowody od strony macierzy wpięte są do jednego przełącznika. Ważne to, że mamy dwa wolumeny i dwa urządzenia /dev/sdf i /dev/sdg.
Na AMS2100 wygląda to inaczej:

/opt/DynamicLinkManager/bin/dlnkmgr view -drv
PathID HDevName Device LDEV
000000 sddlmae /dev/sdb AMS.83004182.0001
000001 sddlmaf /dev/sdc AMS.83004182.0002
000002 sddlmag /dev/sdd AMS.83004182.0003
000003 sddlmah /dev/sde AMS.83004182.0004
000008 sddlmae /dev/sdh AMS.83004182.0001
000009 sddlmaf /dev/sdi AMS.83004182.0002
000010 sddlmag /dev/sdj AMS.83004182.0003
000011 sddlmah /dev/sdk AMS.83004182.0004
KAPL01001-I The HDLM command completed normally. Operation name = view, completion time = 2012/01/27 22:09:41

Mamy /dev/sddlmae, które to jest złączeniem /dev/sdb i /dev/sdh (analogicznie reszta). Możemy odwołać się do tego pierwszego urządzenia i wtedy mamy wielościeżkowość zapewnioną, ale równie dobrze możemy korzystać z pojedynczych urządzeń (naturalnie bez MPIO).
Niestety domyślnie składowe urządzenia są widoczne. Jeśli podłączając zasób odwołujemy się bezpośrednio do nazwy /dev/sddlmae to nie ma problemu. Gorzej, gdy montujemy korzystając z label‘i. Jako, że może istnieć wiele urządzeń tak samo nazwanych, system wybierze pierwsze i z niego skorzysta. W takim przypadku jak mój pierwsze oznacza to przez jedną ścieżkę (fdisk -l 2>&1|grep ^Disk).

Swego czasu przy przenoszeniu danych z macierzy Fujitsu na Hitachi nie zwróciłem na to uwagi, a to spowodowało krótką niedostępność…

Gdyby się ktoś nad tym zastanawiał, to UUID niczego nie zmienia:

/dev/sdb1: LABEL="database" UUID="e275b221-be9f-449b-a0ff-88de3a01799a" TYPE="ext3"
/dev/sdh1: LABEL="database" UUID="e275b221-be9f-449b-a0ff-88de3a01799a" TYPE="ext3"
/dev/sddlmae1: LABEL="database" UUID="e275b221-be9f-449b-a0ff-88de3a01799a" TYPE="ext3"

Kto dopisze jak ukryć urządzenia składowe przez udev?

rlwrap sqlplus

Historię możemy również przeszukiwać wstecz przy użyciu kombinacji [Ctrl] + [R].
Aby zadziałało uzupełnianie, musimy podać plik z listą słów (-f). Oczywiście nie będzie to tak inteligentne jak psql z PostgreSQL, bo dopasowywać będzie każde słowo, niezależnie od kontekstu, ale zawsze to coś.

• procesor VIA Eden Processor 1000MHz, 1995.11 bogomips (wcześniej 500 MHz z 997.54 bogomips),
• pamięć w standardzie 512 MB (wcześniej 256 MB),
• karta graficzna bez zmian, ale jest wyjście DVI zamiast VGA (dają adapter DVI-VGA; minimum dla grafiki to 32 MB),
• sieć Realtek RTL-8110SC/8169SC (czyli Gigabit zamiast Fast Ethernet na RTL-8139/8139C/8139C+).

10ZiG sprzedaje to obecnie jako RBT-5572.
Dla zainteresowanych pliki z SystemRescueCD 2.4.0:

• cpuinfo
• dmesg
• fdisk
• lspci
• lsusb
• meminfo

Przy okazji – jestem żywo zainteresowany ściągnięciem i przetestowaniem Raspberry Pi. Jeśli ktoś chce się podpiąć pod zamówienie, proszę o kontakt. ]]> http://guzik.net.pl/blog/2012/01/odswiezony-clientron-u720/feed/ 3 http://guzik.net.pl/blog/2012/01/aktualizacja-nokia-suite-jest-polaczenie-z-thunderbird/ http://guzik.net.pl/blog/2012/01/aktualizacja-nokia-suite-jest-polaczenie-z-thunderbird/#comments Thu, 19 Jan 2012 21:58:10 +0000 guzik http://guzik.net.pl/blog/?p=3613 Rok temu wyżalałem się z powodu problemów z synchronizacją pomiędzy Nokia i Thunderbird, a tu (przed)wczoraj niespodzianka – aktualizacja Nokia Suite umożliwiająca takie połączenie:


Nie cieszmy się jednak pochopnie, synchronizacja dotyczy na razie (mam nadzieję, że tylko na razie) jedynie kontaktów. Jest już opisana w pomocy:

• Udostępnianie kontaktów w programach Outlook, Outlook Express i Mozilla Thunderbird

A! Można jeszcze synchronizować zakładki z Mozilla Firefox.

Jedna uwaga – to samo urządzenie (z zewnątrz łudząco podobne) znalazłem w ofercie firmy Tecnosteel jako model F3520, jeśli oprogramowanie ma to samo, to też można zastosować poniższy fortel.

I jeszcze jedna uwaga – obecnie używam firmware 1.3.111 (z 24-06-2011; wcześniej 1.3.108 z 12-04-2010). Zdobycie go nie było łatwe, bo kilka miesięcy próbowałem zarejestrować się na stronie producenta, a udało się dopiero niedawno. Na wiadomości e-mail nie odpisują.

A sztuczka z wyciągnięciem wskazań to nic innego jak parsowanie strony, na której można te dane wyświetlić. Droga do celu nie była trudna, choć zaskoczył mnie kod owej strony.
Na początku pomyślałem, że wystarczy wywołać stronę, która wyświetla się w ramce i z niej pobrać dane (/Sensors.htm). I tu zdziwienie – na stronie widzę 20°C, a w źródle „Not found”. O co chodzi? No tak, jest onLoad (InitPageSensors())! A tam jakiś JavaScript, który umieszcza te wartości w miejscu „Not found”.

Funkcja InitPageSensors() wywołuje SetSensorStatus() przekazując jej łańcuch valstring, który jest ukrytym polem formularza (na /Sensors.htm). Przykładowa wartość: C0003C123C130000000000.

Po analizie funkcji SetSensorStatus() wiem, że:

• dwa pierwsze znaki zamienione z HEX na BIN dadzą nam informacje o podłączonych czujnikach – w moim przypadku C0 = 11000000 czyli:
  • pierwszy czujnik T/H obecny,
  • drugi czujnik T/H obecny,
  • trzeci czujnik T/H nieobecny,
  • pierwszy czujnik otwarcia drzwi nieobecny,
  • drugi czujnik otwarcia drzwi nieobecny,
  • czujnik dymu nieobecny,
  • czujnik zalania nieobecny.
• pozycja 5 i 6 to temperatura pierwszego czujnika w HEX powiększona o 40,
• 7 i 8 – wilgotność w HEX (czujnik pierwszy),
• 8-9, 10-11, 12-13 i 14-15 to odpowiednio t2, h2, t3 i h3 (oczywiście również w HEX i również temperatura powiększona o 40),
• i na koniec drzwi, dym i woda – te wskazania można odczytywać jedynie binarnie.

Z racji tego, że valstring znajduje się w kodzie HTML, nie trzeba się przejmować JavaScript, a jedynie wyciąć go i odpowiednio przetworzyć.
Ja to zrobiłem w Perl, żeby użyć jako wtyczki do Net-SNMP i móc odczytać z Cacti, choć shasta na Blip twierdzi, że Cacti nie robi różnicy czy dostaje STRING czy INTEGER. Tak czy inaczej mój kod w kawałkach wygląda tak:

use strict;
use WWW::Mechanize;

my $host = "1.2.3.4";
my $rootOID = ".1.3.6.1.4.1.39133.1";
my $url = "http://" . $host . "/Sensors.htm";

my $browser = WWW::Mechanize->new();

$browser->credentials("username", "password");
$browser->get($url, "selectNPM" => "00000001");

my $content = $browser->content();

$content =~ m/valstring" VALUE="(.*?)" RpSize/;

my $valstring = $1;

Jak widać w powyższym przykładzie nie używam już PEN 31337, a 39133, bo takim właśnie się opiekuję. W artykule „SNMP – co potrafi moje urządzenie?” ogłosiłem konkurs na znalezienie się w bazie IANA do końca roku. Czasu jeszcze trochę zostało, a procedura nie trwa długo.

Wycięcie właściwych danych załatwiły wyrażenia regularne. Na podane powyżej nie łapie się nic innego, więc na razie można bezpiecznie tego używać.

Dalej mamy już obsługę SNMP:

use strict;
use NetSNMP::agent;
use NetSNMP::ASN qw(ASN_OCTET_STR ASN_INTEGER);

my $index = 0;
my $bin = sprintf "%b", hex(substr $valstring, 0, 2);

sub callback_function {
  my ($handler, $registration_info, $request_info, $requests) = @_;
  my $request;

  for($request = $requests; $request; $request = $request->next()) {
    my $oid = $request->getOID();
    if ($oid == new NetSNMP::OID($rootOID . ".1.0")) {
      if (substr($bin, 0, 1) == 0) {
        $request->setValue(ASN_OCTET_STR, "Not found");
      } else {
        $request->setValue(ASN_INTEGER, hex(substr $valstring, 4, 2)-40);
      }
    }
    elsif ($oid == new NetSNMP::OID($rootOID . ".2.0")) {
      if (substr($bin, 0, 1) == 0) {
        $request->setValue(ASN_OCTET_STR, "Not found");
      } else {
        $request->setValue(ASN_INTEGER, hex(substr $valstring, 6, 2));
      }
    }
  }
}

my $agent = new NetSNMP::agent();
$agent->register("callback function", $rootOID, \&callback_function);

Naturalnie if‘ów jest więcej – powyżej to tylko przykład na obsługę pierwszego czujnika temperatury i wilgotności. Zainteresowanym mogę podesłać cały skrypt.

Cały skrypt dorzucamy jako wtyczkę do Net-SNMP i cieszymy się wykresami w Cacti ;-)

Najprościej wykonać to można dodając do konfiguracji dyrektywę extend (kiedyś exec lub sh). Składnia wygląda tak:

extend [MIBOID] NAME PROG ARGS

A na przykładzie:

extend .1.3.6.1.4.1.31337 Test /root/scripts/test.sh testarg1

Przy okazji pozdrawiam firmę Union & Comstar, której PEN (Private Enterprise Number) pożyczyłem :-)
Wadą tego rozwiązania jest fakt, że każdy wynik zwracany przez zewnętrzny program (printf czy echo) traktowany jest jak STRING. Gdy chcemy uzyskać INTEGER możemy wprawdzie posłużyć się kodem wyjścia, ale mamy do dyspozycji zakres 0-255. Do pomiaru temperatury w serwerowni czy na procesorze się może przyda, ale do sprawdzenia pamięci wykorzystywanej przez dany proces już niekoniecznie.

Net-SNMP umożliwia nam wykorzystanie Perl’a – a konkretnie modułu NetSNMP::agent, do tworzenia własnych wtyczek (chyba dla Python też jest wsparcie).
Jako że kiepski ze mnie programista, a w szczególności programista Perl, postaram się wspierać swój przekaz kodem. I tak stworzenie agenta możemy wykonać następująco:

use NetSNMP::agent;

my $agent = new NetSNMP::agent();

Następnie tworzymy funkcję i rejestrujemy ją, by użyć przy wywołaniu konkretnego OID’a:

sub callback_function {
  my ($handler, $registration_info, $request_info, $requests) = @_;
  my $request;
  for($request = $requests; $request; $request = $request->next()) {
    my $oid = $request->getOID();
    if ($oid == new NetSNMP::OID(".1.3.6.1.4.1.31337.1.1.0")) {
      $request->setValue(ASN_INTEGER, hex(substr $valstring, 4, 2)-40);
    }
  }

$agent->register("callback function", ".1.3.6.1.4.1.31337.1", \&callback_function);

Funkcja jest wywoływana z czteroma parametrami: HANDLER, REGISTRATION_INFO, REQUEST_INFO, i REQUESTS. REQUEST_INFO może zawierać dwa tryby – MODE_GET i MODE_GETNEXT. Oczywiście przy jednokrotnym sprawdzaniu OID’a (np. przez Cacti) nie ma to znaczenia, ale gdybyśmy chcieli sprawdzić całe drzewo używając np. snmpwalk, to przy MODE_GETNEXT musimy podać adres kolejnego OID’a, który ma być sprawdzony po bieżącym. W przeciwnym razie snmpwalk skończy odczyt.

$request->setOID(".1.3.6.1.4.1.31337.1.1.1");

W odpowiedzi agent może zwrócić jeden spośród dwudziestu typów danych. Ja używam jedynie ASN_INTEGER i ASN_OCTET_STR. Resztę można znaleźć w dokumentacji.

Po stworzeniu modułu dodajemy jego wywołanie do Net-SNMP w pliku snmpd.conf:

perl do "/root/scripts/test.pl"

Następnie restartujemy demona i możemy odczytywać nasze dane. Należy pamiętać, że po każdej zmianie wtyczki niezbędne jest ponowne przeładowanie.

Czytaj też:

• Extending snmpd using perl
• RedHat Documentation: Extending Net-SNMP

O testowaniu usług w serwisie varlog.pl było już wiele wpisów. O tym, że ciągle warto to robić nie muszę chyba przypominać.
Czasami sprawdzenie serwera za pomocą standardowego klienta jest niewystarczające. Ba! W niektórych przypadkach do tego klienta możemy po prostu nie mieć dostępu. Co w przypadku gdy mamy do dyspozycji jedynie konsolę tekstową, a użytkownicy twierdzą, że np. ich połączenie z pocztą jest odrzucane?
Warto poznać budowę protokołów internetowych, by mieć możliwość dogłębnego zdiagnozowania problemu.

Poniższy wpis ma za zadanie przybliżyć budowę najpopularniejszych protokołów wymiany informacji, co pomoże początkującym administratorom zrozumieć zasadę działania usług i radzić sobie z ich błędami.

Konwencja zastosowana w tym wpisie – każdy listing zawiera komendy wpisywane przez użytkownika i odpowiedzi serwera. Te pierwsze zostały pogrubione.
Odpowiedzi serwera mogą się różnić w zależności od rodzaju i wersji oprogramowania. Ważne są kody odpowiedzi występujące na początku linii (np. +OK czy numeryczne 250).

W przykładach posługiwałem się narzędziem telnet po stronie klienta. Zazwyczaj jest dostępny. Wskazówki dla Windows jak go dodać do systemu znajdziesz tu: Telnet: często zadawane pytania. Możesz też użyć PuTTY. W przypadku Gentoo Linux niezbędna będzie paczka net-misc/telnet-bsd.
Bardziej zaawansowani administratorzy na pewno wybiorą netcat (nc). Za dokumentacją:

Unlike telnet, nc scripts nicely, and separates error messages onto standard error instead of sending them to standard output, as telnet does with some.

Jeśli myślimy o skryptach, które to zautomatyzują, możemy wybrać również expect.

Dobra, tyle wstępu – do dzieła! Na pierwszy rzut poczta – zacznijmy od pobierania wiadomości przez POP3. Standardowa komunikacja może wyglądać tak:

$ telnet serwer pop3
Trying 1.2.3.4...
Connected to serwer (1.2.3.4).
Escape character is '^]'.
+OK
USER guzik
+OK Tell me your password.
PASS 11^ak-to-jest-haslo-plain-text-JAhsus
+OK Welcome aboard! You have 820 messages.
LIST
+OK Scan list follows:
1 2912404
2 3562487
3 98194
[...]
818 157144
819 4260
820 1900
RETR 814
+OK Message follows
[...]
.
QUIT
+OK Done
Connection closed by foreign host.

Najprostszy test może sprowadzić się do komend USER i PASS. Już na tym etapie możemy sprawdzić czy serwer działa i czy na pewno uwierzytelnia użytkowników. Pozostałe komendy to:

• LIST – lista wiadomości (lp. i rozmiar),
• RETR nr – pobranie konkretnej wiadomości,
• QUIT – to chyba jasne.

Gdyby nie powiodło się uwierzytelnienie z powodu błędnego hasła bądź serwer nie mógł sprawdzić danych np. w bazie, dostaniemy stosowny komunikat. Wiedzę o POP3 można rozszerzyć przeglądając dokument RFC 1939.

Czas na IMAP. Pamiętać należy, że każda komenda poprzedzona jest identyfikatorem. Może to być dowolny ciąg – w zasadzie nic nie stoi na przeszkodzie, by zawsze ten sam, ale dla rozróżnienia odpowiedzi warto zastosować za każdym razem inny (w moim przykładzie zastosowałem Cx, gdzie x jest kolejną cyfrą).

$ telnet serwer imap
Trying 1.2.3.4...
Connected to serwer (1.2.3.4).
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS] Courier-IMAP ready. Copyright 1998-2005 Double Precision, Inc. See COPYING for distribution information.
C1 LOGIN guzik 11^ak-to-jest-haslo-plain-text-JAhsus
C1 OK LOGIN Ok.
C2 SELECT Inbox
* FLAGS ($MDNSent Junk NonJunk $Forwarded Draft Answered Flagged Deleted Seen Recent)
* OK [PERMANENTFLAGS ($MDNSent Junk NonJunk $Forwarded * Draft Answered Flagged Deleted Seen)] Limited
* 821 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1301686504] Ok
* OK [MYRIGHTS "acdilrsw"] ACL
C2 OK [READ-WRITE] Ok
C3 FETCH 814 BODY[HEADER]
* 814 FETCH (BODY[HEADER] {1805}
[...]
* 814 FETCH (FLAGS (Seen NonJunk))
C3 OK FETCH completed.
C4 LOGOUT
* BYE Courier-IMAP server shutting down
C4 OK LOGOUT completed
Connection closed by foreign host.

Moje testy IMAP zazwyczaj sprowadzają się do powyższego (minimum to LOGIN i LOGOUT). Nigdy nie diagnozowałem ustawiania flag i nie robiłem niczego bardziej zaawansowanego. Gdyby ktoś z czytelników chciał zgłębić wiedzę o tym protokole, odsyłam do RFC 3501 (IMAP v4.1).

Nadeszła kolej na wysyłanie poczty. Standardem jest protokół SMTP (RFC 2821). Sesja może wyglądać następująco:

$ telnet serwer smtp
Trying 1.2.3.4...
Connected to serwer
Escape character is '^]'.
220 serwer ESMTP j10si7143407wij.97
HELO client
250 serwer at your service
MAIL FROM: <guzik@___.edu.pl>
250 2.1.0 OK j10si7143407wij.97
RCPT TO: <jamzed@______.pl>
250 2.1.5 OK j10si7143407wij.97
DATA
354 Go ahead j10si7143407wij.97
Subject: TEST
test
.
250 2.0.0 j10si7143407wij.97 Message accepted for delivery
QUIT
221 2.0.0 serwer closing connection
Connection closed by foreign host.

I krótkie wyjaśnienie: na początek przywitanie z serwerem komendą HELO z podaniem hosta, z którego się łączymy. Następnie definiujemy nadawcę wiadomości – MAIL FROM: oraz jej adresata – RCPT TO:. Na koniec pozostaje podać treść wiadomości za komendą DATA. Wpisywanie kończymy podając pojedynczy znak „.” w linii. Transmisję kończymy za pomocą QUIT.
Treść wiadomości to nie tylko to co faktycznie chcemy przekazać adresatowi. Za DATA powinny się znaleźć nagłówki, które normalnie formatuje za nas program pocztowy. Ja w testach ograniczam się zazwyczaj do Subject:, ew. Date:.

W kolejnej części postaram się przybliżyć protokół HTTP i FTP oraz IRC. W przyszłości planuję również rozwinięcie tematu o transmisję szyfrowaną (SSL).

Zobacz także:

• Testuj, zanim będzie za późno
• Q&A – jak pobrać stronę bez używania przeglądarki?
• Basic Auth – proste zabezpieczenie zasobów WWW

• sysDescr.0 (1.3.6.1.2.1.1.1.0) – nazwa urządzenia,
• sysUpTimeInstance (1.3.6.1.2.1.1.3.0) – czas od uruchomienia,
• sysLocation.0 (1.3.6.1.2.1.1.6.0) – lokalizacja.

Zmienne przechowują konkretny rodzaj danych. Dla powyższych będzie to odpowiednio STRING, Timeticks i ponownie STRING. Mogą występować również inne typy, np. INTEGER, Gauge32 czy Counter32. W szczególnym przypadku możemy dostać zmienną typu OID czyli wskazanie na adres w drzewie.
Więcej na temat SNMP można znaleźć w RFC 1157. Ja chciałbym się skupić na tym ostatnim typie, bo to jest odpowiedź na tytułowe pytanie.

Istnieje specjalny OID, który jest wskazaniem na gałąź zawierającą zmienne dotyczące konkretnego modelu sprzętu danego producenta. W sysObjectID.0 (1.3.6.1.2.1.1.2.0) znajduje się OID, pod którym należy szukać szczególnych danych dotyczących konkretnego urządzenia. To co dostajemy w standardzie (np. za pomocą zwykłego odczytu snmpwalk) to ogólnie zdefiniowane wartości, tak jak wspomniane wcześniej nazwa urządzenia, lokalizacja czy ruch na interfejsach sieciowych. Dopiero to, na co wskazuje sysObjectID.0 może wyciągnąć z naszego urządzenia dane, których szukamy.

W sysObjectID.0 może znajdować się np. taka wartość: enterprises.211.1.21.1.60 (1.3.6.1.4.1.211.1.21.1.60). Jak widać część jest rozwiązywana na tekst, a część pozostaje w postaci numerycznej (używam snmpwalk). Dzieje się tak dlatego, że pierwszy człon po nazwie to identyfikator producenta (a później jego gałęzie), o których snmpwalk nic nie wie. Identyfikatory nadawane są producentom sprzętu (takim jak Royal Bank of Canada czy Samodzielny Publiczny Centralny Szpital Kliniczny :>) przez IANA, a ich lista jest publicznie dostępna.

Dwa piwa dla pierwszej osoby, która w komentarzu opisze w jaki sposób zdobyć swój numer, cztery dla tego kto znajdzie się w bazie do końca roku (chyba, że czas na umieszczenie jest dłuższy; na dzień dzisiejszy jest tam niespełna 1% firm, czyli ~300, których adres kontaktowy kończy się na „.pl”).

Kiedyś w artykule Xerox Phaser 6180DN jako czujnik temperatury i wilgotności opisałem moją walkę o wyciągnięcie wskazań temperatury i wilgotności z czujników wewnętrznych drukarki. Nie pamiętam czy posłużyłem się SNMP i gałęzią odpowiednią dla tego modelu. Teraz nie mam już pod ręką tego modelu. Piwo dla osoby, która sprawdzi czy może to tam jest.

Jeśli nie potrafimy się odnaleźć w specyficznych wartościach zwracanych przez urządzenie, można posiłkować się bazą opisową dostarczaną przez producentów sprzętu. Plik taki kopiujemy do /usr/share/snmp/mibs, a następnie przy wywołaniu snmpwalk czy snmpget podajemy nazwę bazy (jedna z pierwszych linii, tuż przed DEFINITIONS ::= BEGIN; często też nazwa samego pliku), np. tak:

snmpget -On -c public -v 1 -m FJDARY-E60 host fjdaryPfcmCount.0

Przy okazji – przełącznik -On nie rozwiązuje nazw i pokazuje je w postaci numerycznej.
Jeśli producent bazy nie dostarcza (niestety zdarzają się tacy) pozostaje nam samodzielne zgadywanie.

Zobacz także:

• Using SNMPwalk and a vendor MIB file

• zdalne zarządzanie gniazdami zasilającymi (włącz/wyłącz),
• pomiar temperatury i wilgotności z możliwością odczytu wartości przez SNMP,
• gniazda cyfrowe wyjściowe – np. do sterowania wentylatorem,
• możliwość rozliczania gniazd (moc/prąd) – najlepiej też przez SNMP.

Reszta wodotrysków bezpośrednio mnie nie interesuje.
Krótko o tym urządzeniu – nie spełnia moich wymagań, ale nie jest złe. Przede wszystkim nie ma cyfrowych wyjść (wejść również nie). Jest wskazanie ogólnego poboru prądu, nie ma per gniazdo.

Co ciekawe domyślnie wszystkie gniazda są w stanie wyłączonym (chyba, że ktoś przestawił je tak przede mną), więc po zaniku zasilania znów trzeba je było włączyć. Dzięki tej zaskakującej właściwości wiem, że można je ustawić w jednym z trzech trybów: włączone, wyłączone i ostatni stan.
Domyślnie nie ma też żadnego opóźnienia przy starcie gniazd. Ale można to ‘doklikać’.

Zaskakująca jest również implementacja klienta DHCP, który nie pamięta poprzedniego adresu i za każdym razem prosi o nowy. W dodatku po jednokrotnym pobraniu adresu z DHCP następnym razem nie chce już sobie ustawić domyślnego nadanego przez producenta. Naturalnie można ustawić adres na stałe.

Do listwy można podłączyć dwa czujniki – jeden do dedykowanego gniazda, drugi do portu szeregowego (tracimy wtedy możliwość zarządzania przez ten port). Testowałem tylko czujnik temperatury, na pewno są też dwu-funkcyjne (temperatura i wilgotność), nie wiem czy są inne w sprzedaży.
Dużą wadą jest typ zastosowanych gniazd pod czujniki – PS/2. Pewnie można użyć przedłużacza do klawiatury, żeby wyciągnąć czujnik dalej, ale nie jest to tak wygodne jak RJ/11 czy RJ/45, gdzie możemy wykorzystać okablowanie strukturalne.

Oprócz zarządzania przez WWW (strona wręcz prymitywna, ale przynajmniej dobrze i szybko się wyświetla) jest oczywiście SNMP i Syslog. Choć w przypadku tego ostatniego w ciągu kilku dni złapał mi się tylko jeden komunikat:

EPC-NET-4x: device powered up

Być może – tak jak w przypadku SNMP, trzeba ustawić jakieś wyzwalacze.

Sprzęt wygląda porządnie i chyba ta etykietka jest zasłużona, jeśli by przyjąć stereotyp „niemiecka precyzja”.

Wiem, że nie ma rzeczy idealnych, ale szukam dalej czegoś, co zbliży się do ideału. Z drugiej strony jeśli coś jest do wszystkiego… Dlatego rozważam rozbicie funkcjonalności – osobno monitoring i sterowanie (np. Infratec RMS300), a osobno zarządzanie zasilaniem. I tu opisywane powyżej listwy świetnie pasują.

Czytaj w tym temacie także:

• Monitoring środowiska informatycznego
• Infratec PM 8 ujarzmiony!
• Infratec AG: RMS 310 – nowe czujniki
• Clever NPM
• Clever NPM cz. 2