Tagmigráció 5.5-

A saga folytatódik

Korábban már sokat írtam egy Exchange migrációról. Röviden összefoglalva: van egy Active Directory, ebben pedig egy több szerverből álló Exchange 5.5 organizáció, melyhez kapcsolódnak az AIX alapú rendszerek is. Az internet felé Symantec SMTP Gateway biztosítja a kijáratot.

Vázlatosan: Internet – SMTPGW – Exchange5.5 (+Outlook kliensek) – AIX.

A migráció célja a középső rész Exchange2003-ra történő cseréje volt.
Ez valamikor tavaly augusztusban kezdődött, decemberben volt a nagy ugrás és a folyamat idén februárban ért véget. Gondoltam én.
Május első hetében kaptunk egy bejelentést az ügyfél fejlesztőitől, hogy az adatbáziskezelő rendszerükből automatikusan generált levelek januári dátummal mennek ki. Megnéztem, a levél belsejében (data mező) lévő dátum tényleg rossz volt. A borítékra viszont már minden szerver a jó dátumot pecsételte rá. Visszadobtam a bejelentést, hogy tessék már egy kicsit a saját ház előtt sertepertélni, mert a levél összerakásakor történik valami a dátummal.
Megnézték a szervereik dátumait, közölték, hogy az bizony jó. Erre megírtam a kedvenc nagymamás hasonlatomat:

A nagyi remegő kezekkel odabiggyeszti levele végére a keltezést, becsúsztatja a lapot a borítékba, leragasztja, bélyeget nyal rá és feladja a postán. Szállítás közben az összes postahivatal rápecsételi bélyegzőjét a levélre. A címzett kibontja és megdöbbenve látja, hogy rossz dátum van a levél végén. Bemegy reklamálni a postahivatalba és csodálkozik, hogy a postások kórusban kiröhögik.

Azt a választ kaptam, hogy náluk fejlesztés van, nem kupleráj. Minden változtatás változásmenedzsmenten keresztül történik és az utóbbi hetekben nem változtattak semmit. Ergo az Exchange hülyült meg. Oldjam meg a feladatot. (Ilyenkor szívja a fogát egy MS adminisztrátor – ugyanis fogalma sincs arról, hogy mije változott a rendszerében azáltal, hogy szorgalmasan pecselgeti – ergo nem mondhatja azt, hogy nálam sem változott semmi, beee.)
Nos, itt már egy kicsit izzottak a vonalak, a probléma felszivárgott a középvezetők szintjére. Én váltig állítottam a saját középvezetőim felé, hogy tkp. a fejlesztők azt szeretnék, hogy mi végezzük el az ő munkájukat; a fejlesztők pedig meggyőzték a saját főnökeiket, hogy eszkaláltassák velünk a problémát a Microsoft felé, ha már mi ilyen bénák vagyunk.
Épp itt volt az ideje mélyebben elgondolkodni, hogy mi is történhet itt tulajdonképpen. A fő gubanc az, hogy a probléma két rendszer találkozási pontján keletkezik és egyik rendszer szakértője sincs képben, hogy mi van a másik oldalon. Megtettem az első lépést, megírtam a fejlesztőknek, hogy _szerintem_ hogyan működik a rendszerük. Egész jól tippeltem, alig kellett korrigálniuk: eszerint az adatok Oracle adatbázisokban vannak, ezeket AIX-en hajtja egy Oracle motor. A leveleket egy gyári Oracle modul készíti el és tolja bele szabványos SMTP-n keresztül a levelezőszerverbe – mely MX rekord alapján az Exchange2003 virtuális SMTP szervere.
Nem tehetek róla, de ha meghallom, hogy ’szabványos SMTP’, akkor nekem mindig telnetelhetnékem van. Saját gépről kipróbáltam, nem írtam a data blokkba dátumot és ennek ellenére a levélben benne volt a jó dátum. Innentől akár fel is dughattam magamnak a nagymama-hasonlatot, mert nem igaz: ha az első SMTP host (ahol a levél készül) nem talál dátumot a data-ban, akkor beleteszi a saját átvételi dátumát – azaz a postás bizony beleír a levélbe. Közben a fejlesztők is letesztelték, hogy mi történik, ha nem raknak az adatbázisuk dátum mezőjébe semmit – a levelek gyönyörűen megérkeztek, jó dátummal.
Vov: a workaround előállt. Valahol megnyugodtam – velem együtt a főnökeim is -, mert innentől kezdve a napnál is világosabb volt, hogy a fejlesztők adnak át rossz dátumot. De a fiúk nem nyugodtak. Főnökük kifejezetten ingerült levelet küldött, hogy _ök_nem_változtattak_semmit és már napok óta levelezünk, de senki nem vette a fáradtságot, hogy letolja a képét hozzájuk. Az én agyam itt dobta le a szíjat – simogassam meg a szerverüket?! -, és mivel volt egy lezárásközeli projektem, mely akkor már a harmadik határidőmódosítást szenvedte el, megkértem a főnökömet, hogy legyen kedves, priorizálja a feladataimat. Ő is úgy gondolta, hogy inkább az egyre cikisebb projektet zárjam le, a fejlesztőkhöz meg majd lemegy egy helyi emberünk és megcirógatja őket. Helyi emberünk nem sokat tökölt: megkérdezte, kipróbálták-e, hogy mondjuk júniusi dátumot írnak az adatbázisba. Beírták, jó lett. Hoppá.
Persze az eredményt értelmezni is kellett. Íme a megoldás:
Kiderült, hogy az alkalmazásuk, melynek része a levélküldő modul is, magyar nyelvű – tehát az adatbázisban lévő dátum is magyar formában jön ki az Oracle modulból. Rakjuk csak egymás mellé az angol és a magyar formát.

Dec – Dec – oké
Jan – Jan – oké
Feb – Feb – oké
Mar – Már – bejött egy ékezethiba
Apr – Ápr – bejött egy ékezethiba
May – Máj – hoppá, ékezethiba és karakterhiba
Jun – Jún – sima ékezethiba.

Mint látható, a Microsoft SMTP szerver, amikor összerakja a leveleket, az ékezethibákat még le tudja kezelni – de az ‘y’ helyett a ‘j’-t már nem. És május elsején megzakkant a belső dátum generáló algoritmusa és a hónapot januárra javította. A fejlesztők angolra állították a kritikus dátum formátumát és egyből megjavult a májusi levelezés is.
Most akkor mégis az Exchange szerver a hülye? A látszat – és a fejlesztők is – ezen a véleményen vannak. Én – már csak a mundér becsületének megóvása érdekében is -, visszaírtam, hogy ugye tudják, hogy a levél ‘forráskódjának’ formai szabályai vannak… és ezen szabályok szerint a data SMTP parancson belül a dátum szabvány szerint angol formátumú; és nem érdekel, hogy ők, vagy az Oracle modul, de legyenek kedvesek igazodni a szabványhoz.

Viszont van itt valami, ami miatt igazából tartani kellene a pofámat: a korábbi Exchange 5.5 szerver IMS megvalósítása valahogy megbírkózott a feladattal. Gondolom, megnézte, hogy milyen nyelvi támogatások vannak a rendszerben és azok alapján próbálta meg értelmezni az ismeretlen hónapneveket.
A 2003 már bekeményített. Nyilván lehet mögé ideológiát gyártani, de tény, hogy már a sokadik sunyi változtatást szívjuk meg azzal, hogy az öreg SMTP motort a fejlett újra cseréltük.

Kompati bili

Még mindig ugyanarról a migrációról fogok írni.
Nem örömmel, de így telnek a napjaim.
Vázlatosan a levelezési lánc:
Symantec smarthost – Exchange organizáció – UNIX.
Itt frissítettük az Exchange szervereket 5.5-ről 2003-ra.
Az utóbbi napok tapasztalatai alapján kezd új értelmet nyerni számomra a ‘kompatibilitás’ szó.
Ma kaptam egy levelet. 650 hibaüzenet volt benne. És egy idegbeszakadt Unix adminisztrátor minden szívfájdalma. Meg egy figyelmeztetés, hogy ezek a fájdalmak a közeljövőben akár valóságosak is lehetnek a számomra.
Az NDR-ek a következő üzenetet tartalmazták:
The following recipient(s) could not be reached:
User, Jolan on 25/02/2005 09:38
The message contains a content type that is not supported
<mail-server-00.companyA.com #5.6.1 smtp;554 5.6.1 Body type not supported by Remote Host>
Nem sok, de legalább kevés. A legszebb, hogy ezek a levelek egy olyan alkalmazásból jöttek, melyet teszteltünk az új Exchange szerverekkel és akkor rendesen működött. Azóta pedig nálunk nem változott semmi. Tanácstalanul rákattintottam az eseménynaplóra, ahol a következőt találtam:
“A non-delivery report with a status code of 5.6.1 was generated for recipient rfc822;user.jolan@company.com (Message-ID <00…>).”
Ez nagy áttörés volt, mert volt hibakódja. Viszonylag rövid nyomozás során megtaláltam egyrészt azt, hogy az 5.6.1 státuszkód az RFC 1893 alapján azt jelenti, hogy… nos, baj van a levéllel. Másrészt ráleltem egy KB cikkre, melyben leírják, hogy hogyan kell kiherélni az ESMTP-t. Itt még nagyon nem sejtettem, hogy hogyan lesz ebből megoldás.
Mit csinál ilyenkor az ember? Telnetelget. Hoppá… a smarthost nem támogatja az ESMTP-t. Hogyan is állt ehhez a kérdéshez az 5.5 Exchange? Tudta az ESMTP-t ugyan, de nem mindegyik parancsát: pl. nem ismerte a 8bitmime formátumot. Izé, nézzünk már meg egy eredeti levelet: bingó, van benne csatolás. És amikor teszteltünk? Akkor nem volt. Ez már szag…
Ilyenkor szoktam bezárkózni a klotyiba – ott lehet a legnyugodtabban végiggondolni a szituációt. Tehát: régebben a UNIX megkérdezte az 5.5 szervert, hogy mit tudsz, öcsi? Mivel az nem tudta a 8bitmime-ot, elküldte a leveleket 7bitesen kódolt csatolásokkal – ezt meg még a smarthost is értette. Csakhogy bejött az 5.5 helyett a 2003, aki már azt mondta a Unix-os levelezőszerver kérdésére nagy arccal, hogy nyomjad Gézám 8 biten, bírom én a strapát. És utána esett pofára, amikor a smarthost nem bírta tőle átvenni. Persze intelligens levelezőrendszertől talán el lehetne várni, hogy ilyenkor átkonvertálja a csatolást… de ezt a magasságot inkább kihagyták a fiúk. Majd az E12.
No, mindegy, az Exchange visszadobott egy ‘message content’-re vonatkozó NDR-t és ráfogta a nyuszira.
Ekkor vettem hasznát az ESMTP kiajánlást részletező KB cikknek. Ugyan elég pilótavizsgásnak tűnt a helyes érték kikalkulálása, de szerencsém volt, mert véletlenül(?) pont a 8bitmime eltüntetését hozták fel példának. Már csak be kellett írni. Hová? Hát persze, a Metabase-be. De már tudjuk, hogy a Metabase képes – részlegesen – visszaszinkronizálódni az Active Directory-ból, azaz nyomulhatunk a jól megszokott ADSIEdittel is. A szokásos teaszünet, gyors telnet teszt és tényleg, már nem sorolja fel az Exchange2003 az ismert parancsok között a 8bitmime-ot.
Éles teszt, hurrá.
És a Unix-os srác is visszacsavarta a széklábat a helyére.

ps: Csak megjegyzem, hogy most éppen Zappa “The torture never stops” számának maratoni koncertverzióját hallgatom.

Egyszerű másolás

Nem, nem akarom, hogy ez Exchange blog legyen. Az, hogy én mostanában mindig ezzel akadok össze, az csak egy gonosz tréfa.
A hétvégén egy teljesen egyszerű feladat várt rám: volt egy marha nagy adatbázis, szét kellett szedni négyfelé. Tipikus klaty-klaty-klaty, egykisdombralecsücsülünk munka.
(Emiatt is volt ilyen sok időm irkálni.)
Az első négy postafiók simán átment. Az ötödik már ránézésre sem ígért túl sok jót, lévén 4.6 GB a mérete. (Egész egyszerűen nem tudom elképzelni, hogyan lehet ennyi levelet összeszedni. 1997 óta tárolom pst-ben a leveleimet és rajta vagyok egy talicska levlistán – jó részükön pusztán archiválási célból -, de így is csak 3 darab cédé méretű pst-m van. Küldtek neki egy dvd image-et csatolásban?)
No, jól sejtettem, a postafiók 2 óra alatt átment, aztán a directory rendezésnél 2 újabb óra után gyanús lett, hogy befagyott a másolás. Nyomtam egy cancel-t -> ha lehet, még jobban befagyott. Telefon egy kollégának, aki tavaly nyáron már csinált ilyet: persze, jött a válasz, szokott ilyesmi történni. Task manager, kilőni, és valahogy visszahegeszteni az adatbázist. Sajnos többre nem emlékszik.
Folytattam a másolást. 10 embernél nem tudta megnyitni a mailboxot: elvettem tőlük, majd a kósza postafiókokat visszaraktam a hátukra. Egyből meg tudta nyitni. (Volt egy 11.8 GB méretű postafiók, 220000 levéllel. Ezzel nyolc órát mókolt. Végül 20 percbe tellett, mire másolás után lezárta: ezalatt a 20 perc alatt őszültem némiképp.)
Végül már csak ketten maradtunk a porondon: a 4.6 GB méretű mailbox és én. Szembenéztünk egymással, a szél ördögszekeret sodort keresztül az úton. Hirtelen mozdulattal rávetődtem a billentyűzetre és megismételtem a másolási parancsot – de most egy másik adatbázisba. Két óra szuttyogás után megint behalt a másolás… Task Manager, kilőni. Most már 3 példányban volt meg a mailbox – és mind a 3 működött. Egyszerre. Ha elvettem az egyiket a felhasználótól, mind felszabadult. Ha visszaakasztottam rá az egyiket, akkor a többit sem lehetett törölni, mert azt mondta, hogy használatban van. A helyzet kezdett kínossá válni. Végül kimentegettem az anyagot pst-kbe, lecsatoltam a mailboxot, töröltem a két rosszat, a maradékot visszacsatoltam – és gyönyörűen működött. Nem sokat dobott a kedvemen, hogy közben megtaláltam a helyes megoldást: a behalt mozgatást kilövés után folytatni kell _ugyanabba_ az adatbázisba, amelyikbe elkezdtük. Szószerint azt írták, hogy az Exchange van olyan intelligens, hogy észreveszi a sikertelen másolás darabjait. Usually. Hát… engedtessék meg nekem a kétkedés joga.
Mindegy, most már csak rendszerpostafiókok voltak az adatbázisban és azt írta ezekről egy srác, hogy ez nem probléma. Igaz, hogy a System Attendant Mailbox a fő Exchange szolgáltatás postafiókja és az adatbázis törlésekor hőbörögni fog az Exchange, de nem kell vele foglalkozni. A szervíz újraindításakor le fogja gyártani. (Imádom, ezeket a finom jövőidőket. És ha nem?)
Ennek ellenére nem tudtam törölni az adatbázist. Az Exchange közölte, hogy ebben bizony még vannak. A szemgolyóm már összemaszatolta a képernyőt, de akkor sem láttam senkit az adatbázisban. Szerencsére az üzenetnek volt kódja, irány a net. (Hogyan boldogultunk valamikor Google nélkül? És internet nélkül…?!) Meglepetésemre ugyanannak a srácnak a blogjában találtam meg a választ, akinél korábban már jártam egyszer. Ezt már nem úszta meg, feliratkoztam.
A belinkelt KB cikk alapján előhúztam az ldp-t és megvizsgáltam az adatbázist: a rendszer postafiókok mellett még 5(!) postafiók volt benne. Miközben a kezelői felületen nem látszott egy sem.
Ekkor jött el az a pillanat, amikor sorbaállítottam az irodában a székeket és nekifutásból felrúgtam az elsőt.
A többi már úgyis borult magától.
A mutatvány meghozta az eredményt, ugyanis beugrott a magyarázat: az AD-ban addig nem létezik egy objektum, amíg nem kap értéket. Ha valakinek nincs levele, akkor nem fog látszani az admin felületen a postafiókja – még akkor sem, ha az adatbázisba beíródik, hogy ő bizony ide tartozik.
A többi már sétagalopp volt. Átmozgattam a nemlétező postafiókokat is, adatbázistörléskor ignoráltam a visítozást, SA szervíz újraindult és lám az SA mailbox be is mászott a VIP adatbázisba. Ott jó helyen lesz.
Még kihúztam diskpart-tal egy partíciót – nehogy már leessen a végére az adrenalin – és átmozgattam erre a partícióra az adatbázisokat. Gyors teszt, inkább csak a biztonság kedvéért: benéztem néhány postafiókba. Illetve, csak benéztem volna. De nem sikerült. Már rutinosan navigáltam a Firefox ablak jobb felső sarkába – és persze erre is meglett a válasz: nem, ne hidd el, hogy az Exchange felmountolta az adatbázist. Dismount, mount – és már működik is minden.

Jó mulatság, férfimunka volt.
20 óra hétvégi munka feljegyezve.
Úgy, hogy magát a szétrángatást váltott műszakban végeztük egy kollégával.

Amikor a logika már szaltózik bukfenc helyett

Hihetetlenül ráérek, így leírok egy másik esetet is a korábban említett átállásból.
Exchange5.5 rendszert upgradeltünk 2003-ra egyik ügyfelünknél. Az SMTP konnektor (illetve a korábbi Internet Mail Service – IMS) nem közvetlenül kapcsolódik az internetre, hanem egy Symantec SMTP gateway ( a továbbiakban SSGW) vállalja magára az ezzel járó fáradalmakat. Azaz a részfeladat: van egy – egyébként korrekten működő – 5.5 IMS, melyet ki akarunk lökni a smarthost elől és egy 2003 SMTP konnektort (továbbiakban SC-t) tennénk a helyére.
Szépen felhúztuk az új szervert, első körben ráállítottuk a bejövő forgalmat, feltettük az Archive sinket, leszkripteltük a mailarchív biztonságos helyre mentését – remekül működik. (Illetve elsőre nem, de ez majd egy másik cikk lesz.) Jöhet a kifelé menő levelezés átállítása: névtér átír, forgalom átmegy – és bedugul. Miaf…?
Gyors ellenőrzés: mailbox server: queue üres; SC: queue tele; SSGW: queue üres. Tesztlevelek 10-200 perc között érkeznek meg és az SC queue folyamatosan dagad.
Ki a bűnös? Valszeg az SSGW, az szokott ilyesmiket csinálni. Konstans javítási mód: újraindítjuk. Semmi. Visszaállítjuk az e-mail routolást, az IMS 5 perc alatt kiszórja a leveleket. Most ki a bűnös? Talán az új SC?
Ilyenkor az első ötlet természetesen a névfeloldás átnézése: DNS, WINS, TCP/IP beállítások, route tábla, napfolttevékenység. Minden rendben.
Jó, akkor tartsuk be a Microsoft ajánlásokat.
Pontosabban a nem-ajánlásokat. Leinstalláljuk az Archive sinket (csak diagnosztikai célokra javasolják) és megszüntetjük a kifelé menő levelek feladó szerinti szűrését (egyáltalán nem ajánlják). Semmi változás.
Nézzük telnettel. Az SC-ről rámegyek az SSGW-re, a mail from beadása után elmegy vadászni és kb 1 perc után szól vissza, hogy sender ok. Tehát mégis az SSGW a hibás! Ellenpróba: ugyanezt megcsinálom az IMS-ről – és itt is befigyel az 1 perc várakozás! Várjunk csak… akkor az SSGW lenne a hibás, de az IMS ezt nagy ívben letojja, míg az SC megsértődik? Dehát ez az újabb termék!
Na jó, elő a netmont. Majd az eldönti. Először megszaglásszuk a jó forgalmat. Tesztlevél elmegy, az Ethereal szépen összerakja a levélhez tartozó forgalmat. Ugyanez a lassú forgalomnál teljes káoszhoz vezet: valami akkora dzsuvát rak össze az Ethereal _1_ levélnek, hogy az őrület. Arról nem is beszélve, hogy _nyoma sincs_ a tesztlevélhez tartozó csipcsipcsókának (SYN/ACK/ACK; copyright by FótiMarci) az egész fájlban! De hát… ez fizikai képtelenség!?
Itt döntöttünk úgy, hogy szoptunk mi már eleget, szopjon most már más is -> Microsoft Premier Support.
Az első másfél hónap meglehetősen nyugodtan telt. A magyar részleg bekért párszáz mega anyagot, majd továbbpasszolta az egészet a német csoportnak. Ők újra bekértek párszáz mega adatot és elmentek gondolkodni. Sajnos olyasvalakihez került az úgy, aki nem igazán állt a helyzet magaslatán. Folyamatosan jött a hülyébbnél hülyébb ötletekkel – dobjuk ki a Symantec gateway-t, használjuk a virtuális smtp szervert az smtp konnektor helyett, meg ilyenek. Látszott, hogy fogalma sincs, mi történik a háttérben, de próbálkozott. Én meg nem győztem végezni a szemmel láthatóan vezérfonal nélküli kísérleteket. Végül levélváltásaink kezdtek túlmenni azon a határon, amit egészséges iróniának nevezünk – így egy másik mérnök vette át az ügyet.
Természetesen bekért párszáz mega anyagot. Aztán jött egy levél, amitől melléültem a széknek.
Azt írta, hogy az 5.5 IMS – erőforráspazarló módon – minden levélküldéshez külön sessiont nyitott. A 2003-ban ezt már átdolgozták, és alaphelyzetben minden session 20 levelet küld. (Ezért nem találtam a tesztlevélhez tartozó csipcsipcsókát – mert 20 levélhez tartozott 1. És ezért mutatta az Ethereal 1 levélnek a huszat.) Csakhogy. Ugye ott van az az 1 perc, amíg az SSGW ellenőrzi a mail from adatot. És addig a 20 levél nem áll össze az SSGW-n, amíg a huszadiknak is le nem ellenőrizte a feladóját. Na, ekkor küldi csak ki a köteget. Közben meg szépen torlódik az SC-n a queue.
Persze valami gubanc még ezenkívül is lehetett, mert valahogy össze kellett jönnie a mért 200 perces csúszásnak is – de a jelenség okozója a kötegelés volt, melyet az a jelentéktelennek tűnő 1 perces kivárás borított ki. Az 5.5 IMS ezzel nem foglalkozott: minden levél várt 1 percet, aztán ment tovább. Nagy ügy.
A workaround se volt akármi. Annyit beszélünk Exchange-dzsel kapcsolatban az AD-ról, meg adatbáziskezelésről, hogy az ember hajlamos elfelejteni, hogy az SMTP valahol az IIS része – tehát a működését befolyásoló paraméterek a Metabase-ben vannak(1). Nyilván nem mindegyik van kivezetve a grafikus felületre; többek között az sem, amelyik megmondja, hogy hány levelet küldjön egy sessionben.
Ha esetleg valakinek szüksége lenne rá, ezt a változót kell megkeresni: MaxBatchedMessages – és ki kell javítani az ott lévő értéket 1-re. (Vigyázat, két helyen is szerepel; és csak akkor történik változás, ha mindkét helyen átírjuk. És persze befigyel még az IIS Admin szolgáltatás obligát újraindítása.)

Ps: Természetesen ez csak a workaround. Az igazi megoldás az lesz, ha megtaláljuk, miért szuttyog annyit a feladóellenőrzés a ’smart’ hoston.

(1) Persze ez sem teljesen igaz. Erre az első újraindításkor jöttünk rá, amikor az AD-ból visszaszinkronizálódótt a Metabase-be az a bizonyos 20-as szám. A levelezés meg ismételten fejreállt.

Szar az Exchange… vagy nem?

Túltettem magam a tegnapi napon – most már le is tudom írni, mi történt. Talán nem lesz minden tanulság nélkül.

Egyik ügyfelünk Exchange5.5 rendszerét upgradeltük 2003-ra. Az ügyfél házirendjébe beletartozik, hogy nem levelezhet mindenki az internet felé – tehát az internetes smtp konnektoron van egy csoporttagság alapján történő szűrés. (Na, erről már meséltem.) Ugyanez megvolt az 5.5 esetében is, de ott nem működött rendesen: ha valaki levelezőkliensből küldött levelet, azt megvizsgálta, de ha idegen levelezőszerver relézett rajta keresztül, azzal nem foglalkozott. Ezt használta ki az ügyfél népes Unixos csapata: mindenféle, nem igazán létező feladói címmel küldték ki tömeges üzleti leveleiket. (Nem szpemmer cég, mielőtt bárki rosszra gondol.:-)
A 2003 betömte ezt a lukat – tehát a fiúknak olyan feladói emailcímeket kellett volna használniuk, melyek olyan felhasználókhoz tartoznak, mely felhasználók benne vannak az engedélyezett csoportban. (Huh, remélem, érthető lett.)
Az átállás előtt próbáltunk is végigmenni a rendszereiken, de azok számosan és elkanászodottan voltak. És persze pont egy ilyen rendszerről derült ki – a végleges átállás után két héttel -, hogy nem mennek róla a levelek.
Most csúsztattam egy kicsit: úgy tűnhet, hogy az a csúnya szakállas UNIX adminisztrátor fiú cseszte el az átállást. Nem, a helyzet nem ilyen egyszerű.
Merüljünk bele a részletekbe. Hogy is néz ki egy levél a születése pillanatában, mondjuk Command Promptból?
telnet enyimszerver.enyimdomain.hu 25
helo
mail from: vityipetya@microsoft.hu
rcpt to: sirbillgates@microsoft.com
data
from: “Nénikéd” <auntbetty@val.ahol.com>
subject: Congratulation
Kedves Bill!
Oda és vissza vagyunk.
Csók a család.
.
quit

Látható, hogy a levél kicsit olyan, mint a csigapostás csomag: nemcsak kívülre van írva cím, hanem van egy a dobozban is. Ezzel vége is a hasonlóságnak, a levelet ugyanis a <mail from>-ba írt adat alapján továbbítják, de a <from>-ba írt adatot mutatják a felhasználóknak – azaz mindenhol azt látod, hogy a nénikéd vette magának a fáradságot, hogy írjon. (Tudom, nehéz elképzelni, de úgy látszik, mégis van valami, ami bizarrabb a Magyar Királyi Postánál.)
A UNIX adminisztrátor természetesen átírta a feladót a Sendmailben – de ez a progi a <from> mező tartalmát módosítja. Ránézésre jó volt. Hibaüzenet jött? Nem.
Izé… miért is nem?
Ehhez meg kell vizsgálni a levél forráskódját. Ott lesz elrejtve ez a sor:
Return-Path: <vityipetya@microsoft.hu>
Tehát a visszatérési cím _is_ a <mail from> értéke. Ezt viszont – mint utólag kiderült – a Sendmail névfeloldás alapján kalkulálja ki magának. Persze az Exchange eldobja az ismeretlen feladótól származó levelet, majd küld egy NDR-t (Non Delivery Report) ugyanennek a feladónak. Aki nem létezik. És mindenki ül boldogan a fenekén, egészen addig, amíg az egyik üzleti partner a több százból rá nem kérdez, hogy de jól mennek a dolgok, hogy már két hete nem kap helyesbítendő adatot.
Na, ekkor tör ki a pánik – és természetesen első körben az Exchange a szar. Mert az egyébként is szar.

Nos, tényleg szar az Exchange? Nem, nem úgy tűnik. De tud idegesítően viselkedni – és egy bizonyos szint fölött már nem igazán találni róla információt. Az ember kénytelen saját tapasztalataira és innen-onnan összeszedett tudásmorzsákra támaszkodni, ha általános adminisztrálásnál komolyabb problémákba ütközik.
És persze kell hozzá egy adag szerencse is: ezt az esetet egész biztosan nem tudtam volna ilyen hamar felgöngyölíteni, ha az ügyfélnél nem telepítettük volna fel az ArchiveSink csomagot. (A Message Tracking nem ért semmit, az is az elmaszkolt címet mutatta – a levelek meg szószerint eltűntek.)

Jó kis “Ki Mivel Szív” jellegűre sikerült az írás.
Szerettem azt a rovatot.
Amikor mások írásait kellett olvasni.