Month: May 2006

Egyszerű kiolvasás

2006-05-31 / / 0 Comments

Abszolút egyszerű feladatot kaptam. Csináljak egy listát, a következő oszlopokkal: felhasználói név, GUID. Az első oszloppal nem volt semmi gond és úgy véltem, a másikkal sem lesz. Kétperces munka. Egy perc volt, amíg megnéztem adsiedit-tel, hogyan is hívják a tulajdonságot: objectguid. A következő perc pedig azzal telt, hogy az előregyártott lekérdezőszkriptemben átírtam a lekérdezést a kívánt formára.
Majd az elkövetkező pár órában azzal foglalkoztam, hogy rájöjjek, miért is nem működik ez a módszer. A szkript ugyanis üres oszlopot hozott le.
Rutinosan kikapcsoltam a szofisztikált hibafigyelést (on error resume next), így meg is kaptam a várt runtime error-t.
Nézzük, ldp-ből mit látok. Semmit. Nincs ilyen tulajdonság. Visszamentem az adsiedit-hez, hátha az előbb káprázott a szemem, de nem – a tulajdonság ott volt, sőt, módosítani is tudtam. (Ezzel azért óvatosan.) Azaz jogosultsági probléma sem lehet.
Jöjjön a gugli power. Hosszas keresgélés után találtam olyan linkeket, miszerint felejtsem el, a feladat vbscript segítségével nem oldható meg. Ugyanis az objectguid az egy binárisokat tartalmazó tömb, a vbscipt viszont kizárólag a variant típusú tömböket tudja kezelni.
Szerencsére a lendület továbbvitt és kipróbáltam még néhány keresőszót. És meg is lett az eredménye, rátaláltam egy írásra Eric Lippert blogján.
A szokásos szöveggel indít. Hogy miért nem lehet megoldani a feladatot. Aztán megmutatja, milyen trükközéssel lehet mégis.
Először bedobja a cstr() függvényt. Ez egy olyan függvény, amely képes kigondolkozni a dobozból. Mindent, még az általa értelmezhetetlen adatokat is átkonvertálja sztringgé. Bízik benne, hogy a programoló csak tud kezdeni valamit a karakterkukaccal. És Eric tud. Nekiáll sztringet szeletelni, karaktereket konvertálni, nullából duplanullát csinálni – míg végül a boszorkánykonyhájából kipottyan a friss, ropogós GUID.

Egyszerű kiolvasás. Ja.

Pont, pont, vesszőcske

2006-05-27 / / 0 Comments

Egyik ügyfelünk anyacége leszólt, hogy “Béláim, legyetek kedvesek már használni a céges előírás szerinti formát a levelezési címlistában, köszi”.
Kérték, megcsináltuk, hátradőltem. Túlontúl hamar.
Pár nap múlva jöttek a reklamációk: néhány külsős partner nem tud levelet küldeni belsős címekre. Első reflexből visszaírtam, hogy “sorry, de tudomásom szerint az Exchange szerver nagy ívben nem foglalkozik az AD általunk módosított display name paraméterével, itt maximum véletlenek tragikus összejátszásáról lehet szó”. Pedig megtanulhattam volna az eddigi szívásokból, hogy nem jó első reflexből válaszolni, még akkor sem, ha maximálisan biztos vagyok magamban.
A módosítás lényege ugyanis az volt, hogy megvesszőztük a nevet. Azaz ami eddig “Kis Pál” volt, az mostantól “Kis, Pál” lett. Jó, persze fel lehet szisszenni, de hangsúlyozom, ez display name – azaz az a felület, melyet az AD a felhasználónak mutat. A levelezés nyilván a proxyaddresses alapján megy.
És ez bizony így is van. Egészen addig, amíg csak a szerver játszik. Egy igazi admin itt be is hunyja a szemét, mert ami a szervereken túl van, az már a gyehenna. Levelezőkliensek. Fúj.

Nos, boncoljunk levelet.
Egy közönséges email áll egyfelől borítékból és tartalomból. A borítékon van egy feladó (ezt adjuk meg a MAIL FROM smtp paranccsal) és van egy címzett (ezt adjuk meg az RCPT TO smtp paranccsal). A tartalom – mely a DATA smtp parancson belül utazik – meglehetősen összetett valami, pl. meglepő módon neki is van FROM mezője. És itt jönnek be a képbe a levelezőkliensek. A boríték kitöltésével nincs gond, azt kutyakötelességük ugyanúgy kitölteni – de a belső FROM mező már szabad préda. Ma már teljesen elterjedt forma pl. ez: “displayname” <emailaddress>.
Jó, ezt tudjuk. Mi a probléma?
Csináljunk egy kísérletet. Küldjünk magunknak egy levelet, telnettel.
telnet smtp.sajat.domain.hu 25
helo
mail from: nagymagyartarka@sajat.domain.hu
rcpt to: sajat.email@sajat.domain.hu
data
from: “nagymagyar, tarka” <sajat.email@sajat.domain.hu>
subject: apuhodmedbe
pamparampampam
.
quit
És most nézzük meg, mit csináltunk. Küldtünk magunknak egy levelet, melynek a borítékjára feladóként ráírtunk egy fantom címet (nagymagyartarka@sajat.domain.hu), címzettként pedig magunkat (sajat.email@sajat.domain.hu). A trükk ott van, hogy a belső FROM mezőbe beírtuk a saját címünket!
A levelet természetesen meg fogjuk kapni. Nyomjunk rá egy reply-t! Bizony, azt fogjuk látni a címmezőben, hogy nagymagyar, tarka <sajat.email@sajat.domain.hu>, kedvesen aláhúzva. Reménykedőbbek még mondhatják, hogy jó-jó, az Outlook odamaszkol valamit a címsorba, de küldéskor úgyis az email Return-Path mezőjét fogja használni. Ha már itt járunk, nézzük is meg. Nyissuk meg az eredeti levelet, view/options, rögtön az első sorban ott fog vigyorogni, hogy Return-Path: nagymagyartarka@sajat.domain.hu. Tehát, gondoljuk naívan, ha ezt a replyt elküldjük, akkor ez berepül a fekete lyukba – feltéve, hogy valamelyik sunyi kollégánk időközben nem hozott létre nagymagyartarka címet.
Van egy rossz hírem. Az emailt meg fogjuk kapni. A belső FROM értéke űbereli a borítékra írt címet. És ebben a FROM mezőben már szerepel a display név értéke.
Persze még mindig nem látszik, mi itt a baj. Oké, ott van a címben egy vessző. Na és? Kellően körbezártuk idézőjellel, kedves levelezőkliens, tessék nyugodtan nem figyelembe venni.
Most visszaásunk a múltba. Van egy remek oldal, ahol le van írva, milyen karakterek szerepelhetnek az emailcímben. A vesszőre spec azt írja, hogy “megbolondultál?”. Az ugyanis az RFC822 szerint elválasztó karakter. Igenám, de az RFC822-t 2001-ben érdemei elismerése mellett nyugdíjazták, bejött helyette az RFC2822, mely már megengedi a vesszőt, feltéve, hogy idézőjelek között van.
Most már közel vagyunk. Semmi másra nincs szükségünk, mint egy 2001 előtti levelezőkliensre, melynek halvány fogalma sincs az RFC2822-ről. Mit fog csinálni a szerencsétlen, ha ez kerül a címsorába, hogy “Kis, Pál” <kispal@sajat.domain.hu>? Azt fogja mondani, hogy ez két cím: “Kis az egyik, Pál” <kispal@sajat.domain.hu> a másik. Aztán nekiáll visítozni, hogy nem találja a címeket.
Aki szeret kísérletezgetni, nekiugorhat a Freemail webes felületének, remekül hozza a hibát – legalábbis a múlt héten még hozta.

Szuper, megvan a gizda. Mit lehet vele csinálni?

  1. Szólunk a multi Anyucinak, hogy ne legyen vessző a displaynévben. Oké, oké, tudom, csak a teljesség kedvéért írtam ide.
  2. Beállítjuk Exchange organizáció szinten, hogy ne küldje el a display nevet, csak az email címet. (Message format ablak, valamelyik fül.) Nekem, kockafejűnek, ez teljesen jó megoldás lett volna, de az üzlet egyből Apage Satanas-t kiáltott.
  3. Kivezetjük az ősembereket a barlangból a fényre. Magyarul, nekiállunk supportálni az ügyfél üzleti partnereit is, hogyan kell beállítaniuk azt a többezer fajta levelezőklienst, amelyekből néhány nem tudja lekezelni ezt a szituációt.
    Az élet szép.

[Update]
Azóta kisérleteztem egy kicsit és rájöttem, hogy nem ilyen egyszerű a helyzet. Könnyű lenne mindent a kliensre tolni, de mégsem ő tehet a balhéról – hanem a levelezőszerver. A kliens átadja a megfelelő smtp parancsot – nagyjából ugyanúgy – de a szerver az, mely – feltéve, hogy nem ismeri, vagy nem jól ismeri a szabványt -, belebukik a vesszőbe.
Tényleg érdekes.

Beláncolva

2006-05-15 / / 0 Comments

Régen írtam már szakmai témáról. Ez nektek rossz, nekem jó: ugyanis azt jelenti, hogy mostanában nincsenek nagy szívások a munkahelyemen.
Ez a mostani írás is inkább a munka melletti tanulás eredménye. (Érdekes módszer szerint szoktam tanulni. Előveszek egy könyvet, kinézem, mely fejezetet fogom átnézni, majd nem ritkán amíg a teámat kortyolom és átnézem a reggeli feedeket, postokat, elindulok valamelyik íráson és jó másfél-két órán keresztül próbálom letisztázni, mi is van a cikk mögött. Az előkészített könyv meg csak duzzog az asztalon.)

Van egy olyan valami az Active Directoryban, hogy ‘linked value’. Hallani már hallottam róla, különösen akkor, amikor az AD2003 előnyeit tanultam vizsgára – de olyan nagyon nem mélyedtem bele, mi is ez. Pedig elég érdekes.
Először az a bizonyos előny: az AD2003-ban jobb lett az LVR. Ugye, mennyivel könnyebb immár a lelkünk? De tényleg; az LVR rövidítés a linked value értékek replikációját jelenti.
Most már azért jó lenne tudni, mit is takar az a kifejezés. Könnyű lenne azt mondani, hogy kérem, a linked value az objektum egyik tulajdonságának olyan értéke, mely több elemből áll. Látni fogjuk, hogy ez messze nem igaz, de egyelőre maradjunk ennél a meghatározásnál. Az LVR pedig annyival lett jobb, hogy az AD2003-ban, ha az értékeket tartalmazó tömb egyik eleme megváltozott, nem az egész tömb replikálódik, csak a megváltozott elem. Ez különösen akkor lehet izgalmas, ha mélyebben belemegyünk a susnyásba.
És most akkor felejtsük is el gyorsan az előző defíniciót. Az ugyanis egész pontosan a multi-valued fogalmat fedi, melynek ellentéte a single-valued fogalom. A linked value egy egészen más szempontból történő csoportosítás eredménye. Például ellentéte a DN-valued fogalom.
Nos, eleget ködösítettem már és mivel a blogon nem szótagszám alapján fizetnek, épp ideje rendet raknom. Röviden:
DN-valued: amikor Géza írja be valamilyen eszközzel (kőbalta) a tulajdonság értékét.
Linked value: amikor az AD belső mechanizmusa gyűjti össze az értékeket, más objektumok tulajdonságaiból.
Azaz általában igaz, hogy a linked value körbe tartozó értékek tömbök. De tény, hogy vannak egyelemű tömbök is.
Nézzünk egy konkrét példát:
Minden postafióknak van egy homeMDB tulajdonsága. Az értéke lentebb látható. Itt tárolódik, hogy a konkrét postafiók mely szerver mely store-jában virít. Tippeljünk, milyen tulajdonság lehet ez? Akár DN-valued is lehetne… de nem az.

Kényelmi okokból nem az. Ugyanis létezik egy másik tulajdonság, egy másik objektumon. Minden store objektumnak van egy HomeMDBBL tulajdonsága, itt egy tömbben szerepelnek azon felhasználók CN értékei, melyeknek az adott store-ban van a postafiókjuk. Meg se kérdezem, látszik, hogy ez tipikus linked value tipusú tulajdonság. Az AD belső mechanizmusa mazsolázza össze a HomeMDB értékekből a HomeMDBBL (a BL a BackLink rövidítése) tömböt. Az meg csak egyszerű technikai megfontolás, hogy egyszerűbb a mazsolázás, ha a HomeMDB is linked value típusú.

Most gondoljuk el. Van egy Exchange szerverünk, ahol a konkrét store-ban van négyszáz postafiók. Jön az adminisztrátor, felvesz egy újabb felhasználót, postafiókkal. Amíg az LVR úgy működött, hogy mindig ment az egész tömb, ha akár csak egy eleme is megváltozott, addig volt itt nyüzsgés a dróton, rendesen.
De még így is kell trükközni a replikációval. Ilyen trükk, hogy először a DN-valued tulajdonságokat küldik át a replikációs ügynökök a túloldalra (ahol ugye az igazság lakozik) és csak utána jöhetnek a linked value tulajdonságok.

Érdekes dolgok sülhetnek ki ebből.
Vizsgáljuk meg a fenti példát.
Létezik olyan az Exchange-ben, hogy system policy. Ezen belül van olyan, hogy Mailbox Enable User Policy. Ő a felelős a postafiókokhoz tartozó mailnickname, homeMDB, homeMTA és msExchHomeServerName tulajdonságok kezeléséért. Felvettünk egy új felhasználót (igen, leesett az asztalról), az adatai feliratkoztak a replikációra. Most már tudjuk, hogy a homeMDB tulajdonság linked value típusú, tehát egy konkrét replikációs csomag rájátszásakor csak akkor kerül sorra, ha a többi érték már a helyére került. Leterhelt DC esetén ez akár 10-20 másodperc is lehet. Eközben viszont aktivizálódhat a Mailbox Enable User Policiy. Mit lát? A postafióknak már van mailnickname, homeMTA és msExchHomeServerName értéke (mert ezek már megjöttek), de nincs homeMDB értéke. Nosza, ad neki egyet. A helyi szerver default store értékét. Azaz lazán áthelyezte a postafiókot egy másik store-ba. Jó esetben akár még egy másik szerverre is. A legszebb az egészben, hogy mivel ez a módosítás történt később, így ez az érték fog szétreplikálódni a továbbiakban. Aranyos.
Itt található egy KB cikk, amelyikben leírják, hogyan kell módosítani a Mailbox Enable User Policiy szűrőparaméterét, hogy csak akkor induljon be, ha a postafióknak már van homeMDB értéke.
De nem csak ezt a policyt lehet behülyíteni. Gondolkozzunk el, mi történik, ha a recipient policyt például a homeMDB értékhez kötjük? (Ez egyáltalán nem nagy ügy: amikor kiválasztjuk azon postafiókok körét, amelyekre a megadott emailcímnek rá kell esnie, össze lehet kattogtatni olyan szűrőfeltételt, amelyikben szerepel, hogy mely szerver mely store-jára vonatkozzon a policy.)

Itt állítható be a szűrőfeltétel.

És itt látható a konkrét ldap filter – benne gyönyörűen a homeMDB vizsgálat.

Nos, vegyük elő a korábban felvázolt esetet. A replikáció még nem fejeződött be, a postafiók még nem kapta meg a linked value homeMDB értéket. Közben viszont beköszön a recipient policy – melyet ugye a homeMDB-hez kötöttünk. A feltétel nem teljesül, tehát a postafiók a default recipient policyben megadott címeket fogja első körben megkapni. A következő körben, amikor már meglesz a homeMDB értéke, megkapja a jó emailcímeket is, de a korábbi emailcímek nem törlődnek.
Mit lehet itt tenni? Egyszerű: barátaim, ne kössünk recipient policyt linked value értékhez.

Nos, ennyi. A bevezetőben említettem, hogy imádok elcsatangolni egy-egy cikk nyomán. Ez a mostani írás is így született, az ihletője pedig Bill Long szaki kíváló cikke.