MonthFebruary 2006

Hülye nevek

Vannak olyanok. Annyira hülye nevek, hogy józan ésszel nem is lehet kitalálni, mi van mögöttük.

Az első példám ahhoz a bizonyos régi szilikáttechnológiai vizsgához kötődik.
Ugyanis megpróbáltam legalább elolvasni az anyagot – de már viszonylag az elején belefutottam egy olyan kifejezésbe, hogy ‘doghouse adagolás’. A porok készülékbe adagolásáról a kézzel – máséval – írott jegyzet több információt nem tartalmazott. Megkerestem pár évfolyamtársamat, de csak annyit tudtam meg, hogy az előadó nem részletezte a dolgot, egyszerűen csak lediktálta.
Én viszont belekapaszkodtam, mint Floki a lábtörlőbe. Próbáltam név alapján kilogikázni. Megkérdeztem idősebbeket, ők sem tudták. Internet, google… ugyan, hol voltak még ezek. Nyomtatott jegyzet? Maximum a holdban. Aztán valószínűleg Buzz Aldrin hozhatott egyet, mert sikerült felkajtatnom egy példányt. Ebből tudtam meg, hogy a roppant tudományosan hangzó szilárdanyag adagolási módszer Jenőt takarja a lapátjával. Komoly.

A másik ilyen kifejezés a ’round robin’ volt. Először tanfolyamon hallottam, még az előző évezredben. Csak néztem nagy gülü szemekkel, de kérdezni nem mertem, mert mindenki más szemmel láthatóan tudta, miről van szó. Vagy csak sokkal értelmesebb képet tudott vágni, mint én. Hiányos angol tudásommal annyit összeraktam, hogy a round az kör, a robin meg vörösbegy… de ebből csak nem állt össze, hogyan lesz ebből redundáns DNS névfeloldás. Azóta persze kupálódtam, megtanultam, hogy az informatikában a ’round robin’ az ‘ad-hoc’ kifejezést takarja, azaz jó magyarosan azt, hogy ‘ahogy esik, úgy puffan’. De hogy ennek mi köze van a ’round robin’ hétköznapi jelentéséhez, mely a ’sokak által aláírt kérdőív’-et jelenti… megint nem tudom.

A harmadik példány még teljesen friss. Exchange 2003 disaster recovery kapcsán olvashatunk olyan módszerről, hogy dial-tone visszaállítás. Első hallásra elsápad tőle még a sokat látott exchange admin is: micsoda… modemen keresztül kell visszaállítani valamit… vagy neadjisten, mobiltelefonról kell sms-ben parancsokat osztogatni? De persze, hogy nem; a névnek megint nincs semmi köze a módszerhez.
Mely nagyjából a következőképpen néz ki.
Legyen egy elszállt Exchange store. Az eredeti mérete – betartva a Microsoft erre vonatkozó ajánlásait – legyen 99.99 GB.
Legyen ez a VIP store.
A CEO legyen teljesen átlagos:

  • 1 perc emailtelenség után bevörösödik a feje,
  • 2 perc után kitör rajta a légiós betegség,
  • 10 perc után sátáni kacagással kezdi kilapátolni a HR ablakán az infomunkások munkakönyveit.

Ezzel szemben a restore rendszer nézzen ki a következőképpen:

  • Az adatbázis visszatöltési ideje másfél óra.
  • Mire megtaláljuk Jenőt, aki tudja, hol vannak a kazetták, megint másfél óra.

Mit lehet ilyenkor csinálni? Igen, dial-tone.

  • Letöröljük az adatbázis maradékait.
  • Felmountoljuk az adatbázist. Nem, nem szedtem be semmilyen tudattágító szert… tényleg felmountoljuk a semmit. Az Exchange2003 ilyenkor lesz olyan kedves, hogy létrehoz egy tök üres store-t, azokkal az adatbázis nevekkel, melyek a store tulajdonságlapján szerepelnek.
  • Lehet telefonálni a vezérnek, hogy működik a levelezés. Igaz, még nem mindenki éri el a régi leveleit, de a visszatöltés folyamatban van. Lehet levelet írni, kapni. A vezér meg fog nyugodni. Látja, hogy az emberek dolgoznak – és azt a betyár mindenit, tudnak a fiúk, milyen hamar működőképessé tették a rendszert!
  • Elindítjuk a visszatöltést a recovery storage group-ba.
  • Ha visszajöttek az adatok, ráküldünk egy összefésülést és hipp-hopp, vissza fognak kerülni a régi levelek a postafiókokba. Hátradőlünk és elégedett mosollyal kiélvezzük… azt a pár percet, amíg a munkaviszonyunk még tart. Ugyanis elég hamar rá fognak jönni kedvenc VIP felhasználóink, hogy nem működnek a szabályaik. Naná. Mivel eltűnt az összes. Ugyanis a merge csak a postafiókok tartalmát másolja, a metaadatokat, szabályokat nem. Az üres adatbázis meg egész konkrétan megszámolható szabályt tartalmazott.
  • Probléma szál sem, a nyúl már a cilinderben van – csak tudni kell, hogyan húzzuk elő. Miután visszajött az eredeti store a recovery storage group-ba, lemountoljuk. Hasonlóképpen lecsatoljuk a VIP store-t is, majd lemountolt állapotban kicseréljük a kettőt – értelemszerűen mindegyiket a megfelelő névre átnevezve.
  • És most már jöhet felcsatolás után a merge – hogy megkapják az ideges fiúk azokat a leveleket is, melyek a visszaállítás ideje alatt keletkeztek.

Jó, mi? De hogy miért dial-tone? A fene tudja.

Részletesebb írás a módszerről Jim McBee blogján.

SMS8200 megint

Mióta bevezettük egyik nagy ügyfelünknél, azóta egy kicsit visszafogom magam. Nem rossz persze, de…
Már a tervezésnél beleszaladtunk egy furcsaságba. A kütyünek két hálókártyája van, de mindkettőnek ugyanabba a LAN-ba kell csatlakoznia. A két NIC között nincs smtp routolás. Magyarul, az egyik lábára jönnek kívülről a levelek és ugyanezen a lábon mennek tovább a belső smtp szerverre. A belső szerver a másik lábára küldi a kimenő leveleket és ugyanaz a láb dobja is ki az internetre azokat.
Valószínűleg teljesítmény okok rejtőzhetnek a háttérben, de akkor is furcsa. (Arról nem is beszélve, hogy könnyű úgy teljesítményt növelni, hogy így az Exchange szerverre hárul a dmz-k közötti smtp routing megvalósítása.)
De nem ez volt a legnagyobb tű a vudubabában.
Egy hét után az eszköz eldobta az agyát. Se ssh, se https, se smtp… egyedül pingre válaszolt. Helyi erő kiment, oldalba rúgta.
Az eszköz feléledt és jó egy órán keresztül működött is. Aztán megint megborult. Helyi erő blazírtan megint kiment és kihúzta a seggéből a hálózati kábelt. (Pusztán Varánusz kedvéért: az eszköz seggéből.:) Gyors rollback a korábbi rendszerre, a levelezés visszaállt.
Az alatt az egy óra alatt, amíg élt a cucc, megpróbáltuk kiolvasni belőle, mitől halt el. Nem sikerült. Pedig meglehetősen sokat próbált emberek ugrottak neki, de nem. Az eszköz alatt ugyanis egy rh linux oprendszer szaladgál – és bárhonnan próbálkoztunk hozzáférni, mindenhonnan a mail admin jail-jébe kerültünk – ahol a korlátozott lehetőségek között nem szerepelt a log elolvasása. (Csak tail volt.) A grafikus felületen viszont kizárólag az MTA logjához fértünk hozzá, az meg nem mondott semmit arról, hol csúszott ki a rendszer alól a talaj.
Mindez elég messze van attól, ami egykor lelkendezésem tárgya volt: hogy ssh és oprendszer szintű konfigurálás. Nyilván van valamilyen mód rá, hogy a Symantec mérnökei belenyúljanak root jogosultsággal, de azért ez kissé kellemetlen metódus ahhoz, hogy mondjuk kinyerjünk egy infót a syslog-ból.

Eljöttek az angyalok

A címekkel együtt.

Előzmények:
Itt írtam róla, hogy egyik ügyfelünknél váratlan áldás érkezik: közel 33000 kontakt pottyan az égből a címtárukba. Azt is írtam, hogy sikerült megvédeni ezektől a globális címlistát – de nem túl elegáns módon. Mindenképpen szükség lett plusz adminisztrálásra, ami emberi munka, következésképpen hibaforrás. (Nem mintha a gép nem tudna…)

A héten megkaptuk az első adag címet és alaposan szemügyre vettem őket ldp-vel. Ahogy haladtam sorról sorra, egyre szomorúbb lettem. Sajnos bejött a logika – ha ezek az idegen sejtek látszódni akarnak a szervezetünkben, akkor teljesen hasonulniuk kell. Még az exchangeLegacyDN érték is teljesen ugyanaz, mint a saját címeinknél.
Nem hatásvadászatból írom, tényleg így történt: amikor a tulajdonságok végére értem, akkor találtam – az utolsó sorban – egy olyan bejegyzést, amely egyből bearanyozta a napomat. Ez a neve: msExchangeOriginatingForest. A név magáért beszél: annak az erdőnek a neve van benne, ahonnan a címet migrálták. Értelemszerűen azoknál a címeknél, melyek helyben születtek, ez a tulajdonság üres – azaz nem látszik az ldp-ben.
Innentől kezdve egyszerűen csak ki kell egészítenem a GAL lekérdezést a (!(msExchOriginatingForest=*)) feltétellel és az a bizonyos sokat emlegetett Bob már rögtön a bácsikám is.