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.

Életkép


A lányok éppen hermelint gyártanak. Megfertőződtek volna? Ugyan már…:-D

Mivel kaptam olyan kérdést, hogy mi a búbánatos nyavalya az a hermelin, jöjjön egy idézet Tycho oldaláról:

Na és itt most álljunk meg egy pillanatra, és adózzunk a közép-európai tejkultúra legnagyobb mestereinek emlékére. A Hermelín ugyanis a gasztronómia-tudomány legnagyobb vívmányai közé tartozik. Első ránézésre egy egyszerű fűszeres sajt, ami olajban úszik. Második ránézésre is az, sőt, elfogyasztását követően is az. Élettani hatását ugyanis csak néhány sörrel később fejti ki. Hatásmechanizmusának tudományos igényű elemzésével most nem untatnám a T. olvasóságot, röviden összefoglalva a lényeget annyit lehet elmondani róla, hogy 4-5 sörrel tud többet meginni utána az ember.