Category2000/2003

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.

Üzenet egy másik bolygóról

Egyik ügyfelünk egyik Exchange2003 szerverén nem indul el az MTA stack szolgáltatás. Nem nagy ügy, nem core service. Az adott gépen van 15 postafiók és nem is várható mozgás.
Mivel maximalista vagyok, utánajártam a hibának.
Event id: 9405, azon belül a hibakód: 1073478776.
Van is rá KB cikk: http://support.microsoft.com/default.aspx?scid=kb;en-us;840470
Nna, ezután kellett felmosni.
A javítás menete röviden összefoglalva:

  1. Távolítsd el az _összes_ Exchange szervert.
  2. Távolítsd el az Exchange organizációt az AD-ból.
  3. Installáld le a szerverekről az IIS-t és az ASP.NET-et.
  4. Installáld újra az IIS-t és az ASP.NET szolgáltatásokat.
  5. Forestprep
  6. Domainprep
  7. Installáld újra az összes Exchange szervert.

Az ügyfélnek 5 site-on van egy 6 domaint magában foglaló, országos méretű tartományi rendszere. A 6 tartományból háromban vannak exchange szerverek. Az összes szerveren vigyorogva fut az MTA Stack szolgáltatás, csak ezen az egyen nem indul el.
Úgy elgondoltam, hogy mennyi időbe tartana, amíg hivatalosan is idiótának minősítenének, ha egy ilyen javaslattal betámadnék az ügyfélhez.

Most már csak arra vagyok kíváncsi, hogy ezek a fiúk melyik bolygón élnek!?

A zseni átlátja a káoszt

Anélkül, hogy túlzottan belemennék a részletekbe. Van az Exchange2003-nak egy olyan beállítása, amelyik ki van vezetve ugyan a grafikus felületre, gyönyörűen be is lehet állítani mindent – de a beállítások addig nem lépnek életbe, amíg be nem mész a registrybe és nem veszel fel bizonyos kulcsokat. (Q277872) Gondolom a next-next-finish adminok elleni védekezésnek szánták…
Már önmagában ez is durva, de a végső szépség az, hogy a registrykulcsok is csak akkor hatnak, ha újraindítasz két szolgáltatást (smtp, message routing) a _megfelelő_ sorrendben.
Elég sokat eljátszottam vele, mire rájöttem, hogy csak a “leállítom az egyiket, újraindítom a másikat és visszaindítom az elsőt” koreográfia működik. (Oké, lehet, hogy más is, de ez biztosan működött.)
Itt látszik, hogy nem vagyok még zsigerből profi ezen a területen. Később ugyanis rájöttem, hogy nem kellett volna vacakolni a szolgáltatásokkal: egyszerűen újra kellett volna indítani az IIS Admin szolgáltatást – mivel avval mindkét másik szolgáltatás függőségi viszonyban van, így az újraindításokat a rendszer magától lezongorázza.
Vegyük észre a gondolat szépségét: a bizarr logikájú rendszer megzabolázására saját logikáját használjuk fel. Valahol itt van a határ: geek az, aki ennyire el bír szakadni a normális észjárástól.
Bár kérdés, hogy szabad-e ilyen mélységben idiótának lenni.