csfeco blogja

Magyarország jogállam, unortodox: az átlag polgárnak jogában áll szívni mint a torkosborz, másoknak meg mindenhez joga van.

Néhány éve küzdök egy hálózat monitorozós (+ sok egyebet is csináló) programmal ( ha valakit érdekel https://github.com/csikfer/lanview2 ).
Rendbe raktam benne a switch-ek VLAN konfigurációját lekérdező modult. És beletettem néhány ellenőrzést, mert jó pár switch-nél tapasztaltam (főleg a HPE 19xx  sorozatok), hogy totál hülyeségeket is be lehet rajtuk állítani, ha az ember nem figyel. Eredmény a 76-ból 15-öt megfúj-olt. Kezdtem is keresni a hibát a programban, ennyi hiba nem lehet, de nem a program hibás (ill. nem igazán hibás), csak nem kezeli azokat a "sajátosságokat" amiket az SNMP válaszokba sikerült belecsempészni.

1. feature: HPE 1920 sorozat. A dot1qVlanStaticEgressPorts, dot1qVlanForbiddenEgressPorts és dot1qVlanStaticUntaggedPorts -által visszaadott bitmap-ekből kihagynak portokat. Nem állítom, hogy nincs abban logika (persze nem sok), hogy kihagyják azokat a portokat, ahol nincs értelmezve a VLAN, de így csúsznak az indexek, és infó az meg nincs erről (ha mégis, elárulhatná valaki, hogy hol), és így már nettó baromság (szerintem). Tehát kell a programba is egy olyan feature, amivel megadhatóak az elbaszott bitmap indexek.

2. feature: A ProCurve switch-ekben elvileg nem lehet olyat beállítani, hogy nincs untagged VLAN egy portra. Elvileg, de azért van ilyen. Az egyik porton nem volt untagged VLAN, de azért a PVID az 1 volt, amúgy ez a VLAN a portra forbidden volt. Itt már nem sok logikát látok a válaszban, de végül is érdektelen mennyi logikát látok benne, kezelni kell valahogy. A program ellenőrzi, hogy az untagged VLAN azonos-e a PVID-vel, ha nem, akkor fújól. Ezt le kell tudni tiltani, mert azért van ilyen. És mivel redundáns infó, meg mit tudom én más típus mit kavar, eleve letiltható lett a PVID lekérdezése, az egész switch-re vagy figyelembe vétele portonként. (Azt hiszem beleteszem a feature-k közé az untagged bitmap-ek figyelmen kívül hagyásának a lehetőségét is, mert mi van, ha a bitmap rossz, és a PVID-k a jók.)

3. feature: HPE V1910 sorozatnál a trunk portok hiányoznak a bitmap-ekből, illetve minden érték 0. Amúgy bazi hosszú bitmap-ek jönnek, de adat csak az első néhány byte-ban van, a többi nulla. A VLAN kiosztás a tag portok alapján kideríthető, de azért csessék meg!

4. feature: Ha be van állítva autentikáció a portokra (802.1x), akkor számomra értelmezhetetlen az SNMP által visszaadott VLAN kiosztás. Eddig ilyen nálam csak ProCurve switch-eken van, ott a CLI menüjében sem igazán értelmezhető a VLAN kiosztás, ill. azt felülírják az autentikációs beállítások, aminek persze az egész menüben semmi jele. Az autentikációs port beállítások spec. a programból is kimaradtak, ezzel majd kezdeni kéne valamit.

Csak ennyi, nekem nem tűnik úgy, hogy véresen komolyan veszik ezt az SNMP-t. Van, a strigula behúzható, tessék neki örülni. Arra azért kíváncsi vagyok, más gyártók is ennyire lazák-e? (Van egy sejtésem, hogy igen.)

Persze ez most fele akkora szívás sem volt, mint amikor az LLDP lekérdezéseket akartam rendbe rakni. Mindenki más infót küld, mindent máshogy értelmez, nem is igazán sikerült normálisan rendbe tenni.

Kéne fejleszteni a hálózatot. A központi HPE 5406zl switch-ből kifogytak a portok, meg a gerinc 10G-bővítését is be kéne fejezni.
Mivel ehhez drága cuccok kellenek engedélyt kell kérni a nem megszorítások kormányának egyenesen a miniszterelnökségétől. Még egy év sem telt el, az engedély megjött. Ettől persze pénz még nem lesz rá, de azért próbálkozunk.
Na igen, de! Bár minket nem érint a forint gyengülése (mondotta egy politikusunk), de az eszközök azért drágábbak lettek, az eredeti terv alapján nem férünk bele az engedélyezett keretbe. Ráadásul, mivel a HP nagy ívben szarik a kompatibilitásra, az eredeti terv szerint beszerzendő 5406R kaszniba ugyan simán bele lehet dugni a régi moduljainkat, csak éppen nem működnek (kompatibilitási mátrixok közlésével felhagytak, a kedves vásárló tud olvasni, van Google derítse ki). Új terv kell!
Még lehet venni modult a régibe (mire lefut a beszerzés már nem biztos), az így nem felszabaduló 5400 helyett meg veszünk egy olcsóbbat. Találtam is egy tökéletes(-nek tűnő) switch-et, mindent tud, ami nekem kell: 2930F pont annyi SFP+ van benne amennyi kell, viszonylag olcsó, hurrá. Az árba is beférünk, egy kis sakkozás az eszközökkel, megvan a teljes 10G gerinc. Aztán felmerül, hogy a következő lépésben mit kellene fejleszteni, gondoltam ez a 2930F jó lehet máshova is kedvező ára miatt, egy kicsit tüzetesebben átnézem a specifikációt, és hoppá! A 2930F csak azt az egy transceiver típust nem támogatja ami nekem kellene (OM2-es kábelünk van, így a távolság miatt csak az LRM jöhet szóba, na ezt az egyet nem támogatja). Legutóbb a GBIC-ekkel szívattak, van egy rakat A-jelű BGIC-em, csakhogy ezt a legtöbb nem kimondottan régi eszközük nem támogatja, lehet venni ujjakat, de legalább nem olcsó. Tehát vagy választok másik switch-et, vagy lecserélek egy rakat transceivert, és kihúzatok új optikai kábelt, ez meg a költségek miatt nem fog menni.
Megoldható a dolog, a 2930M-el, csak kétszer annyiba kerül, sebaj faragok a költségen máshol.
Amúgy az a szép a HP választékában, hogy a régebbi eszközeiket néha képtelenség összekötni az újakkal. Költséghatékony megoldás lenne egy 2930F switch a központi mellé, de akkor sem tudom csatlakoztatni (10G), ha a fejem tetejére állok: a központin RJ45 és X2 portok vannak, a 2930F-en pedig SFP+. A lehetőségek (elméletileg): 10GB-T: kéne egy SFP+/RJ45 modul a 2930F-re, de ilyet a HP nem gyárt, (és semmilyen más gyártót nem támogatnak). Optikán összekötve (SR) nem költséghatékony, de az X2/SR modul már nem kapható, közbesz-ben reménytelen. Egy SFP+ modul a 5406-ba, és SFP+-SFP+ direkt kábellel összeköthető, csakhogy a modul kibasz. drága, ki kell dobni miatta egy másik modult (ő lenne a 7.) cserélni kell kidobott kártyán lévő X2 modulokat SFP+ -ra és megvagyunk (kb.: 2mFt). Talán a 1950 jó lesz, csak azt rühellem, és van pár protokoll, amit nem tud.

Bedőlt két Ubuntu szerverem, frissítettem, és onnantól elszáll valami boot-kor, és nincs diszk (Virtuális, Hyper-V alatt). Nem gond, ezt a kettőt nem nagyon használják, (a másik hármat nem bántom).
Letöltöttem a 18.04 szerver beta2-t, nézzük meg azt.
Megkérdezi, milyen nyelven szeretnék kommunikálni. Kiválasztom a Magyart. Következő oldal: cirill betűk, és (gondolom) orosz nyelvű szöveg.

Küzdök egy hálózat monitorozó/nyilvántartó programmal: https://github.com/csikfer/lanview2
Ennek egyik modulja felderíti (vagy inkább felderítené) a hálózati topológiát az SNMP/LLDP protokollok segítségével. SNMP-n keresztül lekérdezi a switch-eket, és megkísérli értelmezni az LLDP "info"-kat.
Elvileg az LLDP protokoll egyszerű lehetne mint a faék, de valószínűleg nem ez volt a cél. A protokoll ugyan nem túl bonyolult, de maximálisan támogatja, hogy mindenki azt küldjön amit akar, és úgy értelmezze ahogy csak akarja. És ezt a fantasztikus, kihagyhatatlan lehetőséget nem is hagyja ki senki.
A portok azonosítására az ifIndex és az ifDescr alapján lehetséges az SNMP-ben. Ezt így közvetlenül szinte senki nem küldi el.
A PeoCurve switch-ek elküldik ezeket, de ez a protokoll definíció alapján nem egyértelmű, csak ha detektáltuk hogy ez egy ProCurve Switch
A ProCurve Web management switch-eknél már nem így van. Ráadásul a portokat újra indexelték.(A lehetőség definíció szerint adott, csak tudnám kinek jó ez).
Kiolvashatók az LLDP szerinti indexek, de az IfDescr-et ebben a táblában a gyártótól függően hol névnek, hol descriptornak hívják, vagy éppen nem ezt adják meg, hanem a MAC-et (Van, hogy egyik portot a descriptor, másikat a MAC-el azonosítja pl. volt 3COM most HP switch).
A Windows egy külön kategória. Implementálták a protokollt, pont úgy, ahogyan azt Ők szokták. Semmilyen információt nem találtam, hogy lehetne konfigurálni. Csak annyi tudható meg egy Windows-ról, hogy mi a MAC-címe, két mező küld, mindkettő a port MAC, minden más mező üres.
Windows Server esetén sem találtam semmilyen infót, azon kívül, hogy nem működik, de még annyira sem mint Windows munkaálomásóknál. (Árnyalja a dolgot, hogy az LLDP csak a trunk portra engedélyezhető, aminek nem biztos, hogy van értelme, a trunk tagjaira ( a fizikai interfészekre) viszont nem mertem engedélyezni, mert pampog miatta, és nem lenne népszerű akció, ha bedönteném a Windows Cluster-t.

Otthon egy latopot használok asztali gépnek is, duál boot-tal, de szinte mindig az Ubuntu fut.
Történt, hogy kellene a munkahelyi gépről két fájl, de a (linux only) VPN beragadt, amíg nincs VPN, addig nem tudom a benti gépet újraindítani, enélkül meg nincs VPN, 22-es csapdája. Sebaj van Win-es VPN is, az nekem még sosem akart menni, de egy próbát megér. Persze most sem megy. A VPN szervernek nincs tanúsítványa, ki kéne kapcsolni az ellenőrzését, de a Wondows leszarja, hogy kikapcsoltam, marad bekapcsolva, és nem csatlakozik. Kipróbálom a lányom friss 8.1-es Windows-án, ott mint a szél megy a VPN. Megszületett az őrült gondolat: frissítsük a Win 7-et 10-re, úgyis szolt, hogy frissíthetek.
Frissítés elindul, egy jó idő múlva szól a GRUB, hogy nem tud boot-olni. OK, A frissítés kinyírta a GRUB-ot, sebaj majd helyrerakom, hagyományos MBR visszaírva egy USB-ről indított linux-szal, mehet tovább a frissítés.
Windows 10 rendben elindul, VPN most sem megy. Hiába állítom be a Rendszergazda leírása szerint a VPN-t nem megy. Aztán újra létrehozom a VPN-t nem állítok be semmit a szerver címén kívül, mindent a Win talál ki, és működik. Tök jó, hogy mindent be lehet állítani a GUI-ban, de minek...
Mindegy, (még) örül, megvan az a két fránya fájl. Kéne megint a dualboot, és itt jön a MEGLEPETÉS!!! Az Ubuntu rendszernek nyoma sincs.
A Windows 10 frissítés úgy döntött, hogy a Linux partícióm szabad terület, odabiggyesztett egy helyreállítási partíciót (lévén baromi gondos, a biztonság, meg az adataim védelme az első), és még maradt sok-sok szabad helyem a HD-n, csak éppen Linux-om nincs.
Mondjuk egy percig nem állítom, hogy csalódtam. Semmi lényeges nem veszett el, de azért annyira nem örülök.

Ma be kellet mennem dolgozni, mivel tervezett áramszünet van, és egy pár dolgot nem lehet távolról leállítani, meg jobb ha van valaki a helyszínen is.
Előzmény: A főiskolára kinevezett kancellár első döntése, ami engem is érint, hogy ma ingyen jöhetek be dolgozni, mert amíg nem látja át a helyzetet, az ilyen esetekre vonatkozó kifizetéseket felfüggeszti.
Első érdekesség: Minden szerver leállítva, a SAN mégis ezerrel dolgozik, gondoltam le kéne azt is állítani (ekkor már nem volt áram). Mire eljutnák idáig kikapcsolt a központi switch, mert az UPS lemerült. Jó átrak a másik UPS-re, switch nem boot-ol ;(
A SAN leállítási probléma "részben megoldódik", mivel kifogynak az UPS-ek a szuflából.
No, áram visszajön, első lépés a központi (Procurve 5406zl) bekapcsolása, nem boot-ol. A konzolon csak annyit mond: "IS2S".
Van rá élettartam garancia, de csak majd hétfőn foglalkoznak a témával, switch majd ezután lesz néhány nap múlva (szinte biztos, hogy nincs raktáron).
A switch helyettesítése majdnem lehetetlen (nincs tartalék, meglévő eszközökkel minimum egy nap kemény szívás, hogy legalább a létfontosságú dolgok működjenek).
Izgi lesz a hétfői nap.

Előélet: http://hup.hu/node/125041
Elkezdem dokumentálni. Nem mintha értenék hozzá de kell(ene).
Két érv hangzott el a dokumentálásra:
Csak így lehet másokat is megnyerni: De nagyon úgy tűnik így sem.
Befektetett munka nélkül nincs eredmény: Ez is elég szar érv, ha azt veszem, hogy erre a projektre havonta legalább 100órát elcseszek. Ennél többet sem a munkahelyem, sem a családom nem tolerálna, az ízületeim meg már most sem díjazzák.
Amit viszont nem említett senki:
Egy okból mégis csak jó, ha megkísérlünk olyan szándékkal dokumentálni, hogy azt más is megértse. Ehhez ugyanis le kell lassítani, és egy kicsit körbenézni, mit is lapátoltunk itt össze?
Ilyenkor más "megvilágításban" látjuk a dolgokat.
Sajnos egy egyszemélyes projektnél, ha kitalálsz egy marhaságot, akkor nincs aki erről felvilágosít. Aztán egyrészt szívatjuk magunkat, másrészt az egész kupac átláthatatlanabb lesz a szükségesnél.
Először bizonytalan voltam, hogy érdemes-e újra végigmenni az egészen, mivel már szinte minden, a hibás koncepcióból fakadó problémát megoldottam. Csináltam a GitHub-on egy elágazást, és tettem egy kísérletet. Mivel a módosításnál eddig a legtöbbet a Del gombot használtam, most már biztos vagyok benne, hogy megéri végigcsinálni. Sokkal tisztább, szárazabb érzés :).
Nem csak arra jó a dokumentáció készítés, hogy legyen másnak olvasnivalója, hanem jó okot ad a lassításra, és arra, hogy azt is észrevegyük amit eddig nem (akartunk?).

Már volt szerencsém erről a lassan, de bizonytalanul készülő rendszerről írni : http://hup.hu/node/109290 és http://hup.hu/node/109293 . A "nagy" érdeklődés, és a sok "pozitív" kritika ellenére még nem kukáztam a projectet.
El ugyan még nem készült, de kigyomláltam a nem publikus részeket és ami elkészült, azt kipakoltam a GitHub-ra : https://github.com/csikfer/lanview2 .
Sajnos a dokumentáció írása nem az erősségem, de azért megpróbáltam kiizzadni egy dokumentációnak tűnő valamit (lv2.odt), még azért dolgozom rajta.
Kiegészítés : A dokumentáció (szerűség) html-ben : http://svn.kkfk.bgf.hu/lanview2.doc/lv2.html folyamatosan frissül.

Kb. 7 éve elkezdtem írni egy hálózat monitorozó rendszert.
Anno, egy kis IT cégnél dolgoztam, és felhívtak egy főiskolából, hogy szeretnék korszerűsíteni a hálózatukat, és kérnek tőlünk ajánlatot. Nem igazán vettem komolyan a dolgot, mert majd pont tőlünk fognak egy ekkora projektet megrendelni, de azért lett belőle ajánlat, és csodák csodája megrendelés is. Aztán úgy alakult, hogy olcsóbban sikerült a kivitelezés (kiderült, hogy mindenhol megfelelően működik az olcsóbb GBIC) és a fennmaradó pénzből lett egy karbantartási megállapodás. Én meg, ennek keretében összelapátoltam egy monitorozó rendszer szerűséget. Akkor ez még nem volt más mint néhány Linux program: MRTG, arpwatch, meg pár Perl script, meg egy igen puritán weblap.
Aztán tartós lett a kapcsolat, és mivel kedvet kaptam a dologhoz az egészet átírtam egy összefogottabb valamivé LAMP alapon. Eddig gyakorlatilag hobbiból készült az egész, de kiderült, hogy a főnököm szempontjából is van egy hasznos funkciója: képes érzékelni a hálózati eszközök jelenlétét, vagyis ha elvisznek/eltulajdonítanak egy hálózati eszközt akkor jelezhet.
Vagyis erre az ekkor már általam LanView-nek nevezett rendszerre ráépült egy riasztó rendszer (IndAlarm) ami nem az én művem volt, és üzleti alapon készült.
Mivel ez a LanView életem első PHP-s próbálkozása, szinte nulla adatbázis gyakorlattal, voltak hiányosságai. Mint szabad programot közzé akartam tenni, de sosem készült el olyan szinten, hogy más is tudja használni, meg a jogállása is bizonytalan volt (egy részét azért munkaidőben írtam), ezért ebből sosem lett semmi.
Időközbe munkahelyet változtattam, és a fentebb említett főiskolán (ill. most már csak Főiskolai Karon, mert az összevonások során kaptunk egy „gyámot”) vagyok rendszergazda.
Munkám során határozottan hasznosnak tűnt a LanView, de a hiányosságai is egyre bosszantóbbak voltak. Ezért elhatároztam, hogy az egészet újraírom. Hozzá is láttam, és készült is mint a Luca széke, vagy ha pontos akarok lenni sehogy. Próbáltam támogatást szerezni a főnökségtől, mert ha az egész főiskolán és nem csak a karon használnák a programot, akkor talán a fejlesztés is nagyobb lendületet kaphatna, de az okosok látatlanul is tudták, hogy ez egy használhatatlan szar, és nem voltak rá kíváncsiak. Ez persze alaposan „fellelkesített”, és egy jó ideig pihentettem a projektet.
Így évekig a LanView2 projekt nem igazán fejlődött, volt egy jó pár kukázott próbálkozás, meg egy keretrendszer, vagy API szerűség Qt-ben megírva, és halvány elképzelések az adatbázis szerkezetére. Majd jelentkezett valaki (egy HUP-ra feltett kérdés alapján), hogy beszállna a fejlesztésbe, és Ő a felhasználói felületet csinálná Djangó-ba. Az Ő őtlete volt, hogy legyen az adatbázis kezelő Postgresql, és milyen jó, hogy van abban öröklődés. Az ürge persze jó hamar eltűnt, de lett egy többé kevésbé kitalált adatbázis, öröklődéssel, amit valójában egyáltalán nem támogat a Postgresql, csak úgy benne van, de most már bementem a csőbe.
Újabb lendületet adott, az IndAlarm továbbfejlesztése, amit nem akartam a régi rendszerre ráépíteni. Így nyár óta írom mint a mérgezett egér a rendszert. De egyre nyilvánvalóbbá válik, hogy én ezt egyedül nem tudom megcsinálni.
Jelenleg mi készült el:
Van egy adatbázis, ami úgy tűnik szinte minden információt (amire én eddig gondoltam) képes tárolni egy hálózat topológiájáról, és a benne lévő, ill. a kiszolgált eszközökről.
Többé kevésbé le van programozva az adatbázis logika (persze a mérgezett egér stílusú programozás miatt bizonyára tele hibával).
Van egy API szerűség a Qt-ben (C++) megírva. A programrendszernek van zárt része, mégpedig amik IndAlarm-al kapcsolatosak (HW fejlesztés, érzékelők, nem hálózati eszközök pl. monitor védelmére, egy Web-es kezelő felület django-ban).
Van egy nem interaktív import program, ami alapján feltölthető az adatbázis (ez SNMP eszközöknek a konfigurációját le tudja kérdezni).
Van néhány lekérdező daemon:
Egy „fő” daemon, ami a lekérdező daemonokat futtatja (nagyon félkész, minimális funkcionalitással, de működik)
SNMP-n keresztüli port állapot lekérdezések (egyenlőre csak a státuszok lekérdezése).
Az import is képes daemon módban futni, ha például távolról szeretnénk megadni feldolgozandó scriptet az adatbázison keresztül.
Elkezdtem írni egy GUI-s karbantartó programot Qt-ben, de ez igencsak kezdetleges állapotban van. Bár nem nagy kihívás Qt-ben GUI-t írni, de ha meg kel tervezni sok tucat dialógus ablakot, és megírni több száz függvényt, akkor hiába egyszerű, ha sok van, az nagyon sokáig eltart. (A django-s rész is tartalmaz karbantartó részt, de ez nem az én művem, és jócskán hiányos is.)
Szóval most itt tartok. Jó lenne valami GPL szerű licenc alatt közzétenni, de ahhoz el kéne jutni valami alap verzióig, amire egyedül nem sok esélyt látok.