SNMP pod Linuksem…

Mamy w firmie kilkadziesiąt modemów, kilkanaście zarządzalnych switchy,
ileś urządzeń radiowych. To wszystko razem tworzy dość skomplikowaną sieć.
A ja, wraz z kolegami muszę nad tym zapanować. Oczywiście radzimy sobie, ale
bywa to dość upierdliwe. Zwykle konfigurujemy urządzenia i badamy ich stan
przez WWW lub telneta. Oczywiście każde urządzenie ma inny interfejs,
a z każdym z tych interfejsów są jakieś problemy (np. w jednym modemie hasło
zmieniam elinksem, a przepustowość firefoksem, bo pierwsze nie działa
w firefoksie, drugie w elinksie). Sprzętu przybywa, więc zarządzanie nim staje
się coraz większym problemem.

Fajnie by było móc zarządzać wszystkim z jednego miejsca. Można część zadań
zautomatyzować jakimiś skryptami z osobnymi backendami dla każdego typu
urządzenia (tak mam teraz zrobiony backup konfiguracji części urządzeń)
i całością zarządzać w jednym miejscu (własny interfejs WWW), ale tu byłaby
kupa roboty. Taka śmierdząca kupa… więc sobie to daruję, przynajmniej na
większą skalę.

Jest jednak coś co łączy większość naszych urządzeń: SNMP. Prawie wszystkie te urządzenia obsługują
SNMP. Dotychczas używałem tego tylko do monitorowania wykorzystania łącz,
ewentualnie traktowałem jako ficzer, który należy wyłączać ze względów
bezpieczeństwa (niektóre urządzenie po ustawieniu hasła dostępu do WWW
i telneta dalej pozwalały na dostęp r/w przez SNMP z community name
private). Wczoraj, myśląc nad zautomatyzowaniem kolejnego zadania
(przygotowania konfiguracji MRTG dla wszystkich switchy, zsynchronizowanej
z danymi o topologii sieci z bazy danych), zacząłem się zastanawiać, czy nie
można by spróbować tego SNMP jakoś szerzej wykorzystać…

Od razu zaznaczam, że z SNMP jestem dość zielony, co może mieć duży wpływ
na to co napiszę poniżej – jak pisze bzdury, to prosze dać znać.

Wiem, że jest coś takiego jak słynne Open View, którego na oczy nie
widziałem, ale podejrzewam, że byłoby tym czego poszukuję. I to, że na pewno nas
na to nie stać. Postanowiłem poszukać coś tańszego, najlepiej otwartego i za
darmo. Zacząłem oczywiście od tego co widzi poldek…

Poldek, poza narzędziami do monitorowania urządzeń, w sensie rysowania
statystyk (to mi już u mnie MRTG + RRDTool załatwiają), znalazł niewiele. GXSNMP
jest nierozwijany od lat, a gdy go ostatnio oglądawał, to się za bardzo nie
nadawał do użytku. Tym razem sobie go darowałem. Kolejny był Scotty, którym już
też kiedyś się bawiłem. Pamiętam go jako brzydkie, ale działające coś w Tk/Tcl.
Chciałem znowu tego spróbować, ale nawet się nie uruchomiło. Scotty okazał się
niekompatybilny z aktualnym Tcl (używa jakiegoś prywatnego symbolu, którego
w nowej wersji biblioteki brak). Na razie nie chciało mi się z tym dalej
walczyć.

GXSNMP i Scotty to narzędzia nie tylko do zarządzania siecią przez SNMP, ale
też, a może przede wszystkim, do rysowania mapy sieci. Do SNMP poldek pokazał mi
jeszcze Mbrowse – Mbrowse is an SNMP MIB browser based on GTK and
net-snmp
. Pomyślałem, że to może się przydać – pozwoli się dobrać do
konkretnych zmiennych urządzenia. Po zainstalowaniu się nawet uruchomił, pokazał
drzewko MIB… ale nie udało mi się tym odczytać chociażby jednej wartości
z localhost (snmpwalk i snmpget z konsoli działały).
Do kitu.

W PLD nie znalazłem czego szukałem (rzadko to się zarza), to zajrzałem na
Freshmeat. Pierwsze na co tam
trafiłem, to MIB
Views
, firmy Muonics. Oprogramowanie komercyjne, z możliwością darmowego
wypróbowania przez piętnaście minut. Postanowiłem spróbować. Na pierwszy rzut
oka wygląda podobnie do Mbrowse, tyle że dużo ładniej… i działa. Wygląda na
to, że to co ma robić, to robi i robi to dobrze. Interfejs jest ładny
i wygodny (na tyle, na ile mnie się to udało teraz stwierdzić). Jednak raczej
tego nie kupimy – MIB Views nie daje żadnych mechanizmów zarządzania
całą siecią. W danym momencie pracuje się z jednym urządzeniem (agentem
SNMP), a żeby przełączyć się na inne trzeba od nowa podawać jego parametry.
Jeszcze muszę zobaczyć jak to będzie działać z konkretnymi urządzeniami (na
razie bawiłem się w domu, tylko z localhost), ale raczej to sobie darujemy.

Na Freshmeatcie znalazłem też trochę otwartego lub darmowego
oprogramowania. W szczególności zainteresowały mnie dwa Javowe programy: Open
Eyes i NetWhistler. Obydwa służą do
tworzenia mapy sieci i zarządania siecią. Pierwszy ma brzydki i mało
intuicyjny interfejs, nie chciało mi się w to wgłębiać. Drugi wydaje się
całkiem sensowny, ale strasznie długo z nim walczyłem, żeby dodać tam chociaż
jedną maszynę. Okazało sie, że NetWhistler działa tylko uruchomione z roota,
inaczej wali jakimiś mało mówiącymi wyjątkami. To zdaje się być normą
w oprogramowaniu Javowym – oprogramowanie zakłada, że ma dostęp do
wszystkich swoich plików, a instalator NetWhlister upierał się jeszcze, żeby
instalowac z roota. W każdym razie, z roota chodzi i nawet daje się używać,
ale na kolana nie powala. I zakłada, że wszystko jest zorganizowane w ładne
podsieci IP (u nas to bardziej skomplikowane – wiele VLANów, podsieci
w kilku VLANach jednocześnie, adresy oderwane od jakiejkolwiek podsieci)
i bezpośrednio dostępne (u nas wiele sieci jest odizolowanych, nie chciałbym
włączać pomiędzy nimi routingu, żeby wszystko dało się zapingowac z workstacji
adminów). Może warto się tym jeszcze pobawić… a może i nie.

Z oprogramowania na Freshmeat znalezionego pod hasłem SNMP zainteresowało
mnie jeszcze jedno: Internode
Nodemap
. Internode Nodemap to zestaw narzędzi to tworzenia map sieci, ale
nie koncentrujące się na urządzeniach, ale na łączech. Sama mapa nie jest
wyklikiwana, ale wczytywana z plików konfiguracyjnych. Pod każdą mapkę może być
podłożony obrazek jako tło – w ten sposób można np. wrysować swoje łącze
na plan miasta. To mogło by się dobrze u nas sprawdzić, wymagałoby jednak sporo
pracy – wypadałoby zrobić coś co zamieni dane o topologii sieci z naszej
bazy na plik konfiguracyjny dla Internode Nodemap i dołożyć informacje
o geograficznym/fizycznym położeniu urządzeń (czyli zrobić interfejs w którym to
będzie można wyklikać). Możliwy do uzyskania efekt kusi, więc może się tym
zajmiemy.

Wciąż nie jestem w pełni zadowolony z wyniku poszukiwań. To co znalazłem
może i może się do czegoś przydać, ale ciągle to nie jest to.
Nie znalazłem narzędzia, które mógłbym po prostu zainstalować i stosować,
wiedząc, że ułatwi mi pracę i nie musząc dostosowywać tego do naszej sieci, czy
naszej sieci do tego narzędzia. Np. myślałem o czymś, co mogło by bezpiecznie
(wykorzystując SNMPv3) korzystać z SNMP proxy na maszynach z dostępem do
zamknietych sieci. Jednak mało co umie SNMP w wersji 3, a obsługi proxy (czy
raczej kontekstów, bo jak dobrze zrozumiałem, to do tego się to sprowadza) nie
widziałem nigdzie. Liczyłem też na to, że uda się jakoś wykorzystać dane
o topologii sieci z naszej bazy – co do czego i jak jest podłączone.
A może wciąż gdzieś tam jest coś, czego nie znalazłem, a co rozwiązało by
wszelkie moje problemy…

Po nocce

Wczoraj znowu rozpierdziel w firmie. Tym razem przemeblowanie serwerowni.
Firma znalazła kupca na szafę rackową, a że w niej akurat stał nasz sprzęt, to
trzeba było wszystko poprzestawiać do stojaków (które, swoją drogą, mają w tej
serwerowni większy sens niż szafy). Do roboty przyszedłem na 15:00, żeby od
16-tej zacząć. Kolega miał do tego czasu opisać mi wszystkie połączenia (4
switche 24-portowe, z dziesięć serwerów, ponad dwie setki gniazd na
patch-panelach i cała masa połączeń). Nie zdążył, więc robiliśmy to razem
jeszcze z dwie godzinki. Potem było rozbieranie starych szaf, składanie
i wstawianie nowych stojaków, przekładanie patch-paneli z rozszytymi setkami
par itp. atrakcje. W końcu wstawianie sprzętu na nowe miejsce i podłączanie
wszystkiego tak aby zadziałało (oczywiście od razu działać nie chciało).
Wyszliśmy (brudni i śmierdzący, bo w budynku wodę na noc wyłaczają) z firmy
o 3:25. A niektórzy byli w pracy od 8:00.

Dzisiaj rano, normalnie od 8:00, też jakiś admin w firmie się przydał.
Jeden ma chorobowe, zostało nas dwóch. To uzgodniłem z kuplem, co wczoraj od
rana siedział, że ja przyjdę na tę ósmą, a w południe się zamienimy. Więc
przespałem się 3 godzinki, łyknąłem kofeinę z puszki (Booster — taka
podróba Red Bulla z Plusa, za grosze) i, niewiele czyściejszy niż przed
wyjściem z serwerowni, podobnie śmierdządzy i ledwo przytomny, pojechałem do
roboty.

W pracy oczywiście okazało się że parę rzeczy nie działa, ileś innych
działa, ale są podłączone tam, gdzie nie powinny itp. Latałem więc między
serwerowaniami (budynki oddalone o jakieś 500m), z serwerowni do swojego
pokoju, rozszyłem jeszcze parę kabelków na patch-panelu… i o 11-tej jakoś
się uspokoiło. Obiecałem jeszcze coś komuś sprawdzić, więc posiedziałem
jeszcze do wpół do pierwszej, ale do domu wróciłem sporo wcześniej niż
normalnie. Ufff…

W domu wreszcie mogłem się doprowadzić do porządku. Pospać to teraz bym
sobie i tak nie pospał (w dzień mi nie wychodzi), więc, mając tę chwilkę
wolnego, męczę Baculę. Jak już
sobie kupiłem tę nagrywarkę DVD do robienia backupów, to trzeba było w końcu
zacząć je robić. Niestety, pakiet z Baculą w PLD wciąż w rozsypce (ale się
buduje i nawet jakoś działa), a wsparcie dla DVD w Baculi wciąż nie domaga…
Ale jakoś udało mi się to zmusić do działania. Znaczy się, dysk mi rzęzi,
nagrywarka mruga diodą… czy z tej płytki się potem będzie dało coś odzyskać,
to się dopiero okaże.

Kłopoty z DNS

Mam kłopoty z DNS dla jajcus.net i dlatego czasami obrazki
z poprzedniego wpisu były niewidoczne. Zrobiłem workarounda: alias na serwerze
WWW w innej domenie i zmiana URLi we wpisie. Więc jak ktoś nie obejrzał sobie
zdjęć, to może spróbować teraz — powinno być lepiej.

PLD RescueCD i PXE

Po pierwsze trzeba mieć serwer DHCP (ten z pakietu dhcp,
zresztą chyba nie mamy innego w PLD) i TFTP. Uwaga serwer z paczki
tftpd nie chciał działać z syslinuxem, więc należy
zainstalować tftpd-hpa. Oprócz tego trzeba mieć bootloadera
umiejącego ładować system przez sieć. W moim przypadku był to
syslinux. No i potrzebna jest płytka RescueCD, z obrazem systemu do
uruchomienia. Trzeba użyć oficjalnego obrazu (datowanego
2004-07-18) dostępnego ze strony RescueCD. Nowsza wersja
(beta z 2005-06-19) się co prawda bootuje, ale nie można się
do niej zalogować.

Montujemy płytkę RescueCD i kopiujemy z niej pliki vmlinuz i rescue.sqf do
/var/lib/tftp. Dla pełniejszej funkcjonalności można tez skopiować
boot.msg, help.msg i memtest. Część plików jest w katalogu
głównym płytki, część w boot/isolinux. Z katalogu /usr/lib/syslinux
kopiujemy plik pxelinux.0 (część syslinux służąca do bootowania przez sieć), też do
/var/lib/tftp. Pozostaje przygotować plik konfiguracyjny dla pxelinux. W tym celu
tworzymy katalog /var/lib/tftp/pxelinux.cfg, a w nim plik default (nazwą
pliku może też być np. adres MAC maszyny którą będziemy bootować, szczegóły w dokumentacji
syslinuxa). Plik ten tworzony jest na podstawie isolinux.cfg
z RescueCD. U mnie wygląda on tak (i to powinno działać z tą wersją RescueCD u każdego):

serial 0
prompt 1
timeout 99
default pxe
label pxe
 kernel vmlinuz
 append initrd=/rescue.sqf init=/linuxrc root=/dev/ram0  ramdisk_size=54000  console=tty0 console=ttyS0,9600n81
 ipappend 1
label mem
  kernel memtest

Ta konfiguracja jest oczywiście przygotowana do użycia z konsolą szeregową. Jak ktoś chce standardową konsolę VGA,
to powinien wywalić serial 0 i console=tty0 console=ttyS0,9600n81.

Gdy już mamy przygotowane pliki dla startowanej maszyny, musimy je jej wskazać. Robi się to przy pomocy
serwera DHCP, jednocześnie przydzielając adres IP. W moim przypadku załatwiał to poniższy wpis w /etc/dhcpd.conf,
w odpowiedniej deklaracji podsieci:

host pxeinstall {
	hardware ethernet 00:40:63:c3:99:a9;
	fixed-address 10.253.0.99;
	filename "pxelinux.0";
}

Adresy MAC i IP należy oczywiście dostosować do swoich potrzeb. Nazwa pliku jest względna do
katalogu /var/lib/ftp i może być właściwie dowolna. Większość wspomnianych wyżej
ścieżek w /var/lib/tftp jest konfigurowalna. Wyjątkiem jest katalog
pxelinux.cfg.

To właściwie tyle konfiguracji. Należy jeszcze się upewnić, że serwery TFTP i DHCP działają
i używają właściwej konfiguracji (dhcpd trzeba zrestartować), włączyć na maszynie do
wystartowania bootowanie przez PXE i uruchomić ją. Po chwili powinna dostać adres IP, pobrać parę
plików po TFTP i uruchomić system.

Geek kontra zderzak

Dzisiaj znowu dwa razy (raz pod przychodnią, raz pod dworcem PKP)
zahaczyłem zderzakiem o krawężnik. Ten drugi raz to był akurat o ten jeden
raz za dużo i kawał zderzaka mi się odłamał. Nie mógł tak wisieć (to już
będzie zagadka dla mechanika — czy da się to jeszcze poskładać), więc
trzeba było coś z tym zrobić. Ale co to dla mnie? ;-) Wyciągnąłem
z torby zestaw naprawczy, czyli metrowy patchcord zakończony wtykami RJ-45
(chyba nie krosowany) i przywiązałem to jakoś tak, żeby się trzymało. Jutro
tak jeszcze pojadę do pracy, a po południu do mechanika, niech mi przynajmniej
powie czy i co będzie trzeba kupić.

Pingwinaria, dzień pierwszy.

Wyjechałem z domu rano, dwadzieścia po siódmej. Podjechałem jeszcze na plac
Piastów po kolegę z Bytomia i ruszyliśmy w kierunku Krynicy. Droga była
bezproblemowa i udało się ją pokonać, spokojną jazdą (inaczej tym samochodem
się nie da), w cztery godzinki. Na miejscu jeszcze prawie nikogo poza
organizatorami nie było. Załatwiłem co było do załatwienia i
postanowiłem zwiedzić okolicę…

Na północnym stoku Góry Parkowej, zaraz obok hotelu, leży jeszcze masa
śniegu (około 1.5m), ścieżka też ośnieżona, a ja w wiosennym ubraniu (bez
kurtki, czy swetra, tylko w koszuli flanelowej). I było mi ciepło. Szczególnie
że wdrapywałem się na górę szybkim krokiem, trasą niekoniecznie spacerową
— jeszcze częściowo ośnieżonym i oblodzonym torem saneczkowym. Po drodze
spotkałem kilka wiewiórek, a także stado jeleni (właściwie to łani), które
patrzyły się na mnie jak na jakiegoś idiotę (kto inny w letnich butach i bez
kurtki brodzi w śniegu?) i nawet nie próbowały uciekać. Na górze trochę wiało
(halny), ale i tak było dość ciepło, jednak nie na tyle, żeby długo tam
siedzieć. Było tam trochę tubylców, z jednym z nich, całkiem
sympatycznych, sobie trochę pogadałem. Zainteresował się, czy mi nie zimno,
poopowiadał co interesującego mogę zobaczyć w drodze na dół, pogadaliśmy o
tych łaniach, które tu właściwie oswojone, a kiedyś było ich nawet więcej itd.
itp. Oczywiście rozmowa nie była zupełnie bezinteresowana i pan pokazał mi co
ma na swoim stoisku. Polubiłem go, więc nawet coś kupiłem (trzeba wspierać
lokalny folklor), jakiś kamyczek co ma Wodnikowi szczęście przynosić, nawet
coś utargowałem, a do tego rzemyczek gratis ;-).

Wróciłem akurat na obiad. Wbrew Pingwinaryjnej tradycji, jedzenia było
dobre i dużo (szwedzki stół, na którym niczego nie zabrakło). Potem oficjalne
otwarcie i pierwsze wykłady. Na żadnym nawet nie ziewnąłem, więc całkiem
niezłe. Potem pyszna i obfita kolacja. Po kolacji miałem dylemat, pójść na
wykład polskiego CERTu, czy na basen (czynny tylko do 20:00), na który
przysługuje mi 45 minut dziennie. Wybrałem basen, bo rzadko zdarza mi się
popływać, a jak jest taka okazja, to warto zadbać o formę.

Po basenie wróciłem do pokoju, gdzie akurat odbywało się spotkanie ŚLUGu.
Trochę poudzielałem się w dyskusji, a jednocześnie próbowałem CJC odpalić.
Odpaliłem właściwie przed wyjściem, ale się wyłączył. W kolejnych próbach też,
albo się nie mógł połączyć, albo zaraz po zestawieniu połączenie się
zawieszało i w końcu zrywało. Dostęp do Internetu okazał się fatalny. Dopiero
później, po zakończeniu spotkania zaczęło to jakoś działać, więc mogę napisać
na Joggera to co piszę.

Z dostępem do Sieci było w ogóle ciekawie… Miał być. Jak przyjechałem do
hotelu okazało się, że nie ma, będzie za miesiąc. W pokoju gniazdko
Ethernet było, to podłączyłem HUBa, ale nawet lampka link się nie
zapaliła. Szybko okazało się dlaczego, bo zobaczyłem na korytarzu dziury w
ścianach pod skrzynki, gdzie wystawały kable Ethernet, nawet zakończone
wtyczkami RJ45. Przed obiadem już dwóch panów ładowało tam HUBy i montowało
skrzynki. Po obiedzie już link się świecił, ale adresu po DHCP się nie
dostawało. Przed kolacją już DHCP działało, ale net nie bardzo. A teraz działa
wszystko :-). Ciekawe jak długo…

207.46.250.119

Walczę sobie właśnie z zombie w naszej sieci… To znaczy wyciągam z logów
podejrzane adresy, z których było podejrzanie dużo połączeń SMTP, oglądam na co
się łączą i jak to rzeczywiście są różne MXy, to blokuję port 25 dla tych
komputerów. Standardowa procedura…

Dzisiaj jednak pojawiło się coś ciekawego… niektóre komputery łączą sie na
dziwne adresy IP (bez revDNS, lub z automatycznym revDNS jak np.
z neostrady), co sugerowałoby jakieś P2P na porcie 25 (zdarza się). Jednak na
niektórych z tych IP było normalne SMTP. Sprawdzając co to za adresy (czy
revDNS wygląda na jakiegoś MXa) trafiłem na IP: 207.46.250.119. To co pokazało mi
host 207.46.250.119 poraziło. Uznałem, że jakiś spamer przypisał sobie tyle
nazw, żeby utrudnić wykrycie albo ogłupić filtry. Nawet nie sprawdzałem czy
prosty DNS dla nich działa, założyłem, że nie… Z ciekawości zajrzałem jeszcze
do WHOIS… i szczęka mi opadła. Potem dla pewności sprawdziłem prosty DNS.
Wszystko się zgadza. Po cholerę ci idioci robili coś takiego? Żeby resolvery
na całym świecie się nie nudziły?

A teraz mam problem, czy te kompy co się tam (i nie tylko tam) łączyły są
rzeczywiście zarobaczone, czy to po prostu nowe normalne zachowanie
popularnego oprogramowania…

Radia internetowe… wrr…

W firmie postawiłem firewalla. Tym razem szczelnego, gdzie każde połączenie
ma być pod kontrolą (nie ma regułek pozwalających się łączyć na jakiś port
z dowolną maszyną) a do WWW i pokrewnych używane jest proxy
z uwierzytelnianiem Digest. No i nawet IE sobie jakoś z tym radzi.

Ale w firmie ludzie są słuchać radia. Firma nie opłaca abonamentu, więc
pozostają radia internetowe. Geeki nie mają problemów — słuchają swoich
egzotycznych stacji, najwyżej dadzą adres do przepuszczenia na
firewallu. Gorzej z dziewczynami, które chcą słuchać normalnego radia
— Planeta, albo RMF FM. Te stacje robią wszystko by uprzykrzyć życie
administratorom, a tym samym pozbawić siebie części słuchaczy
w zabezpieczonych sieciach. Pomagają im w tym Microsoft i Macromedia (Real
został wykopany z interesu, widać za mało utrudniał).

Bo przecież nie może być tak, że na stronie jest po prostu URL do
strumienia audio w jakimś sensownym formacie i protokole. Często jest jakaś
aplikacja we Flashu, która używa Media Playera do odtwarzania transmisji.
Oczywiście Media Player czy też ta aplikacja Flash uruchomiony w IE nie umie
już ze skonfigurowanego proxy korzystać. Albo uparcie próbuje
uwierzytelniania Basic (o którym wiadomo, że jest niebezpieczne), albo nie
uwierzytelnia się wcale. Więc trzeba zrobić dziurę do przepuszczenia
odpowiednich adresów bez autoryzacji albo bez proxy. I okazuje się, że nie są
to tylko adresy radia, ale także jakichś plików z Microsoftu. Nie dość że je
sobie musi ściągnąć (czemu nie ma w systemie podstawowych kodeków do
podstawowych formatów, albo czemu radiu używa niestandardowych?), to nie umie
tego zrobić poprawnie. Oprócz Microsoftu oczywiście trzeba odblokować serwery
radia. Ale jakie? Nie ma tak prosto, żeby były jakieś nazwy hostów które
wystarczyłoby sprawdzić w DNS. Strumień jest adresowany numerkiem IP (bez
revDNS), a co! Niech admin zgaduje co to i niech mu się konfiguracja posypie
przy pierwszej zmianie IP (już co najmniej jedna była)! Nie będzie się obibok
obijał!

Na razie jeszcze się w to bawię… ale za którymś razem, jak znowu
koleżanka do mnie przyjdzie, że jej radio z nowu nie działa, to odpowiem jak
na rasowego admina przystało nie da się, albo u mnie działa, gdy
puszczę u siebie jakąś alternatywną stację.

Złośliwości sprzętowe

(z góry przepraszam za masę polskawo-anielskawych słówek ;-))

Ostatnio w firmie zajmujemy się łączami radiowymi. Obecne założenia to szkielet sieci na
urządzeniach Proxim Tsunami 5GHz, i łącza końcowe na 2.4Ghz. Jedno łącze 5GHz
działa już od paru tygodni i jest przez nie podłączona jedna duża sieć
osiedlowa. Niestety działy się z tym różne dziwne rzeczy (zawisało od strony
ethernetu satelity lub stacji bazowej). Upgrade firmware do 2.0 tylko pogorszył
sprawę. Na szczęście pojawiła się wersja 2.0.1, która wydaje się rozwiązywać
problem (przynajmniej na razie).

To był konkretny błąd, który najprawdopodobniej został naprawiony (ale wciąż nie
wiem na czym polegał), jednak pewne felery tych Proximów pozostają bez zmian, a
podczas wymiany firmware dały się mocno we znaki. Po pierwsze czas rebootu.
Urządzenie restartuje się kilka minut, a trzeba je restartować po większości
zmian w konfiguracji. Naprawdę nieprzyjemne. Po drugie — interfejs do
zarządzania przez WWW — nawet dość wygodny, ale jedynie w
przedlądarce z JavaScript. Oczywiście ze standardami W3C ma niewiele wspólnego.

Ze względów bezpieczeństwa adresów access-pointów nie routujemy w świat.
Niestety z routera nie da się tym zarządzać, bo tam nie odpalę graficznej
przeglądarki (wiem, że jak się uprzeć to się da, ale ja nie chcę). Postanowiłem
sobie więc forwardować porty przez SSH. I to nawet działa — dopóki nie
próbuję zmienić jakiegoś parametru. Zmiany robione są przez funkcje JavaScript,
które odwołują się do urządzenia po HTTP, ale z konkretnym IP, czyli nie przez
127.0.0.1 na który mam porty przekierowane. Muszę więc dla każdego urządzenia:
1. przeforwardować port przez SSH i 2. dodać regułkę iptables przekierowującą
odwołania do adresu urządzenia na tak przeforwardowany port. Kupa roboty jak na
interfejs mający ułatwić pracę administratorowi. 😦

Ale te Proximy są i tak lepsze niż AP DLinka (2.4GHz). Ten ostatni też ma interfejs
WWW do zarządzania, jednak nie działający w żadnej Linuksowej przeglądarce. Żeby
zmienić jakiś parametr muszę to badziewie podłączać do Win*. Brrrr…

Najlepiej wypada interfejs WWW switchy DLinka. Też używa JavaScript,
miejscami nawet Java (nawet do wyświetlenia tabelek!), ale można go normalnie
forwardować i działa w Firefoksie. Jest nawet dość wygodny, miejscami może nawet
bardziej niż telnetowy interfejs (bardzo fajny, pełnoekranowy) ze starszych
switchy tej firmy. W jednym (a może nawet nie tylko jednym) switchu mam nawet SSH,
ale połączenie (dokładniej wymiana kluczy) trwa tak długo, że raczej nie będę
używał.

Wracając do AP DLinka — w czwartek skonfigurowałem jeden taki do pary
z odpowiednim urządzeniem Proxima do radiołącza na 2.4GHz. Podłączone w biurze
działało. Wczoraj zamontowali Proxima na kominie, DLinka na dachu w pobliżu.
Było to jak już kończyłem pracę, ale donieśli mi telefonicznie, że to nie
działa. Podobno DLink nie odpowiadał nawet na pingi po ethernecie i
nawet po resecie do ustawieni fabrycznych — tzw.
zgon. Dzisiaj więc skonfigurowałem innego DLinka (tego samego typu) i pojechałem
go podłączyć na tym dachu. Niby wszystko OK, nawet DLink pisze że połączył się z
AP. AP (Proxim) przez jakiś czas pokazuje, że DLink jest podłączony, ale potem
go znika z listy. No i łącze nie działa. Kombinujemy jak możemy,
wyłączamy wszelkie filtry, szyfrowanie itp. i nic. Zadzwoniłem więc do drugiego
admina, żeby spróbował reanimować tego martwego DLinka. Okazało się że
jest sprawny i normalnie odpowiada na domyślnym (fabrycznym) IP.
Poprosiłem o sprawdzenie wersji firmware. Okazało się, że w tym niby
martwym
jest firmware 2.0.7 (piszę z pamięci), a w tym który próbowaliśmy
uruchomić 2.0.3. Kazaliśmy przywieść tamten. Skonfigurowałem, podłączyłem… i
ruszyło :-). Ufff.

Potem jeszcze w firmie trochę walczyliśmy z VLANami. Postanowiliśmy wydzielić
tę nową sieć do osobnego VLANa. Jednak był problem w skonfigurowaniu switchy, bo
nie mogliśmy się połapać na których portach ma być (w grę wchodziło 6 switchy 24
portowych)… nie ma to jak dobry bajzelek ;-). W końcu się
udało i chyba na razie wszystko działa jak należy. Oby jak najdłużej.

P.S. poprzedni wpis dla wybranych zalogowanych

Kto tu jest adminem?

W zapowiedziano mi, że w czwartek dostanę access-pointy i switcha do
skonfigurowania na radiołącze na pewnym kominie w Rudzie Śląskiej. W czwartek
sprzęt przyszedł… o godzinie 15:00 (pracuję do 16:00) i szef powiedział że
muszę to jeszcze tego dnia zrobić. Fajnie… sprzęt, którym nigdy się nie
bawiłem — więc go nie znam, do tego dwóch różnych firm (Proxim i
DLink), a mam go skonfigurować do poprawnego (uwzględniając separację VLANami
itp.) i bezpiecznego działania w godzinę (jak nie będzie działało, to będę się
wdrapywał na komin, żeby poprawiać). Zrobiłem to nawet. Napewno nie optymalnie,
ani nie w pełni bezpiecznie, ale działało.

W piątek dostaliśmy do tego switcha, więc mogliśmy też go skonfigurować i
sprawdzić radiołącze z VLANami. Działało. Na komin nie poszło — widać nie
było to tak pilne. Ale to by było za pięknie, więc pod koniec godzin pracy, po
zwisie innej radiolini szef postanowił to naprawiać. Zrobił upgrade na
access-pointach, po którym siadało wszystko, nawet łącze modemowe do centrali
(po chwilowym odłączeniu AP z radiolini od switcha do którego podłączony był
modem). Jak wychodziłem z pracy (już trochę po 16:00) to niby wszystko działało,
ale szef kontynuował psucie (właściwie naprawianie — przez downgrade
firmware’u do poprzeniej wersji) i jeszcze wieczorem coś trzebabyło przez
telefon ustalać. Dobrze, że przynajmniej nie musiałem więcej osobiście przy tym
grzebać.

Bałem się, że w weekend będę musiał jeździć naprawiać te radiówki, ale na
szczęście nie było to konieczne, więc sobotnia impreza (nie nadająca się do
opisania na tym poziomie) odbyła się praktycznie bez zawodowych zakłóceń.

W poniedziałek w pracy spotkała mnie niespodzianka. Szef przyniósł mi karteczkę
z nazwami i adresami access-pointów ze szkieletu naszej sieci radiowej —
tak jak je skonfigurował po kolejnych zmianach firmware.. Były to
nazwy i adresy zupełnie inne niż ja z drugim adminem ustaliłem i udokumentowałem
w naszych materiałach. Do tego jeden AP miał adres należący do switcha (którego
adresu szef nie zmienił — to switch też ma IP?). No kurde —
kto w tej firmie w końcu jest adminem?

Z jednej strony to nawet fajnie, że sam z tym firmware nie musiałem walczyć i
zajął się tym ktoś inny. Trochę nawet mnie to zaskoczyło, bo ostatnio szef nawet
nie zaglądał do serwerowni, bo prezesowi przecież nie wypada np. restartować
modemów (kiedyś czasem jeździł, bo miał znacznie bliżej niż ja). Z drugiej
jednak strony, to w końcu ja jestem odpowiedzialny za działanie całej
infrastruktury sieci i ja ustalam zasady adresacji, podziału łącza
(przyzwyczaiłem już się do tego, że szef regularni podnosi ponad rozsądny poziom
ograniczenie przepustowości łącza do sieci w której jest podpięty) itp. i raczej
nie powinno tak być, żebym o zmianach dowiadywał się ostatni (przecież mogłem
pół nocy stracić zastanawiając się dlaczego gdzieś pingi nie dochodzą).