Ipari zen

Foglalj egy széles
sávot magadnak, majd ne
küldj rajta semmit.

Soha ne ess abba a hibába, hogy a lefoglalt sávszélsességből bármilyen következtetést vonj le a valódi átmenő forgalomra nézvést.

Szoros a verseny,
nagy a tét. Nem ok rá, hogy
megelőzd magad.

Valószínüleg pályafutásom legperverzebb hibajelenségét sikerült izolálni a múlt héten.  Az történt ugyanis, hogy egy laborban pöpecül zakatoló linux kernel modul azonnal feldobta a talpát, mikor a számára oly kellemes és megszokott környezetből kihoztuk egy irodába, ahol egy demo erejéig szerettük volna üzemeltetni. Ha visszavittük azonnal meggyógyult, ha kihoztuk megint beteget jelentett és azonnal lefagyott tőle az egész gép.

Csábitó az út,
de bármilyen vonzó, a
semmibe vezet.

Egy fix IP címeket használó hálózaton belül átmozgattunk egy gépet egy másik hálózati részre. A gép többféle hálózati szolgáltatást is használt (SQL szervereket, egyéb sharelt drive-okat és egyebeket), de azt reméltük, hogy újrakonfigurálás nélkül működni fog. Gondolom nem lep meg senkit, hogy nem tette.  A szoftvereink küldték kifele a hálózatra a csomagokat, de a gép hálókártyáin már kimenő forgalmat sem sikerült észlelni. Mint utóbb kiderült azért nem, mert az IP címmezők kiosztásánál a felületes szemlélő szerint egy tartományba tartozó 172.31.22.63 és 172.31.22.64 –es cím két különböző tartományba (172.31.22.0/26 és  (172.31.22.64/26)) és két különböző gateway mögé került. Emiatt aztán a régi routing tábla teljes mértékben érvényét vesztette. Szóval, ha azt tapasztalod, hogy szoftvered rendületlenül küldi a csomagokat, de a hálókártyákon semmi kimenet sincs, irány a routingtábla editálása (windowson

route

parancs, linuxon

ip route

parancs).  És ne definiálj soha olyan címtartományokat, amiket egy felületes szemlélő egy folytonos tartománynak gondolhat, holott nem azok.

Nem baj ha portod
rossz, mig kábeleden
nem jön be semmi.

Minden vasról akkor derül ki, hogy nem működik, ha használni próbálod. Szemre, tapintásra persze ugyanolyan mintha jó lenne.