Month: March 2005

Menedzser duma

Kíváncsi vagyok, kinek mit mond az, hogy “bullshit generator“, vagy az, hogy “lófasz bingó“.
Az első ugye egy olyan gép, melyet feltöltöttél értelmetlen, de jól hangzó frázisokkal (buzzword), majd ezek közül véletlen kombinációkkal értelmetlen, de naggyon jól hangzó mondatokat tudsz generálni magadnak – akár üzleti terv, akár prezentáció céljára.
A másik pedig egy játék. Véletlenszerűen feltöltesz egy táblázatot ezekkel az értelmetlen szavakkal, majd az értekezlet előtt minden résztvevőnek kiosztasz belőlük egyet. A játék akkor hatásos, ha a főnök nincs beavatva. Amikor az előadó kiejt a száján egyet a frázisok közül, akkor akinél ez előfordult, tesz a szó mellé egy ikszet. Akinél kijön a bingó, az szót kér, feláll és közli, hogy “lófasz”.

Ezek a kedves szórakozások Kathy Sierra cikkét olvasgatva jutottak eszembe. A hölgy egy könyvet mutat be, melynek címe: “Why business people speak like idiots?”
A leányzónak megint jól sült el a keze:

So what do you do as a reader when you come across one of these wtf sections? You re-read it. Again. Again. You stare at it harder thinking that if you just… keep… staring… it’ll suddenly make sense. That’s like speaking louder to someone who doesn’t understand the language. They don’t have a hearing problem, and you don’t have a reading problem. The message is just not in your native language.

Erről viszont egy másik szerző ugrott be. Scott Adams-nek hívják és többek között ő rajzolgatja a Dilbert karikatúrákat. De írt üzleti témájú könyveket is, bemutatva, hogy átlagos emberekből hogyan lehetünk jól fizetett, agymosott idióták. Három könyvéből kettő jelent meg magyarul az SHL kiadásában – a harmadik sajnos nem és nem is hiszem, hogy meg fog. Mindegyik forrás erősségű – nekem pl. pár nappal ezelőtt szükségem lett volna a “proaktív” szóra, de nem jutott eszembe. Kénytelen voltam levenni az egyik Adams könyvet és megkeresni benne.

És ha már könyvbemutatóknál tartunk, ejtsünk szót (szerény meghajlás) egy másik remekműről is. (Amilyen tolongás van érte a könyvesboltokban, azt hiszem, az egészet kirakhatnám az internetre.)
Nos, innen egy szócikk:

Think out of the box
[Gondolkodj ki a dobozból]

Jó mi, az ember ül és csak gondolkodik, csak gondolkodik, aztán kicsordul a dobozból.

Természetesen megint nem erről van szó.
Ez egy üzleti trend, valami olyasmi, mint a rég idejétmúlt ‘gyártsunk jó terméket, mert az kell a vevőnek’-elv illetve a még mindig divatos ‘kérdezzük meg, mi a jó a vevőnek, mert amíg erről beszélgetünk, elfelejti, miről akart reklamálni’-elv, röviden CRM.

Korunk üzleti folyamatainak résztvevői hajlamosak bezárkózni saját kis mikrorendszereikbe, azon belül végzik munkájukat, a peremen kielégítik a peremfeltételeket és mindenki elégedett.
Leginkább a peremfeltételek.

Erre most jön a kapitalista és felszólítja alkalmazottait, hogy emeljék fel fejeiket, tágítsák horizontjukat és lássanak át nagyobb rendszereket.

Ennél pofátlanabb hazugság kevés létezik. Bárki, aki elmúlt 12 és fél éves, láthatja, hogy igazából a mai üzleti világban csak a kiválasztottaktól várják el, hogy gondolkodjanak… a fölös agykapacitások és az önálló kezdeményezések olyan felesleges és veszélyes jelenségek, melyeket felmosóronggyal, nivellált stresszel, brazil sorozatokkal és realitikufircolásokkal igyekeznek felitatni.

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.

Horoszpók

Reggeli közben azt mondta a rádió, hogy a horoszkópom szerint az egész napot a hobbimnak fogom szentelni. Ehhez képest bent ülök a munkahelyen és postafiókokat rángatok egyik adatbázisból a másikba.

De hülye hobbijaim vannak…

Szar az Exchange… vagy?

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.

Harci kutya

Amilyen hülye napom ma volt… reggel az első telefon a zuhany alól rángatott ki, a második a vécéről. A harmadik telefon miatt az utazást kellett megszakítanom a metrón – de a negyedik telefonnál már nem szálltam le.
És ilyen volt az egész nap. Ebédelni nem volt időm, cserébe bent voltam estig.
Pedig semmi érdekes nem történt, egyszerűen a levelező rendszer a saját logikája szerint működött. Az emberek meg egyből pánikba estek, amikor ez nem egyezett azzal, amit elképzeltek.

Ps: Aki a címből egy viccre asszociál, az nem jár messze az igazságtól. Egész nap annak a poénját mormogtam.

© 2026 MiVanVelem

Theme by Anders Norén — Up ↑