MonthMarch 2006

Lurdy ismét

Kicsit kalandos volt az odajutás. Ugyan 4 kilométerre lakom, de a máskor tízperces útból negyven lett. Valószínűleg zavar lehetett ma az erőben. Ezt az autóm is megérezte, mert az alapjárat a boldogabb vadászmezőkre távozott. Elég izgalmas volt a 40 perc dugózás. Automata váltóval. Kuplung nélkül. Ebben ugye az a trükk, hogy nem lehetett benyomott kuplung melletti gázfröccsökkel operálni, ehelyett egyik kézzel rángatni kellett a váltót, jobb lábbal meg nagy frekvenciával rugdosni hol a fék, hol a gázpedált.
De végül csak bevergődtem.
És most a lényeg.
Elég nehezen indult be nálam az előadás. mICK jól nyomta, de az anyag eleinte nem tett rám komoly benyomást. De csak eleinte nem. Amint menetközben rájöttem, hogy honnan kell nézni a cuccot, egyből érdekesebb lett. Itt elsősorban nem meglévő technológiák mély ismertetéséről volt szó, hanem közeljövőben debütáló technológiák fejtágító jellegű bemutatásáról.
Itt van például a NAP (Network Access Protection), melynek a demózásához Longhorn és Vista kellett volna – csak éppen ezek a rendszerek még nem úgy tudják az igét, ahogyan kellene, tehát a demó elmaradt. (Szegény mICK, lehet, hogy hiába tanulta be a mostani kilométer hosszú parancsokat, az élesben már máshogy lesznek?:)
A középső szakasztól pedig megváltozott a helyzet, onnantól már nemcsak ismerkedős anyagok jöttek, hanem elgondolkodtatósak is. Kezdve ott, hogy önmenedzselés. Ezen a területen azért meglehetős fenntartásaim vannak. El sem tudom képzelni, hogy abból az állapotból, amikor mindenféle nem odavaló hibaüzenetet kapunk, hogyan lehetne eljutni odáig, hogy a rendszer a hibaüzenet alapján beleavatkozik saját magába – és túléli.
Jó, el tudom képzelni. Csak valahogy nem ennyire hamar.
És utána kezdtünk el modellezni. Ez egy nagyon veszélyes szó, nem árt előre tisztázni, ki mit ért alatta. Én például amikor átfutottam a jegyzetet és megütötte szememet a ‘Modell-alapú Felügyelet’ kifejezés, egyből nekiálltam szórni a kereszteket minden irányba. Tudom, uncsi, de én valamikor ipari vegyészetet tanultam, azon belül is nagykanállal kaptam mind a szabályozástechnikát, mind a folyamatmodellezést. Ott ugyanez a kifejezés azt jelentette, hogy kockafejű matematikusok lemodellezték egy ipari folyamat egészét és a dinamikus modell a valósággal párhuzamosan futott. Aztán amikor a valóság el merészelt térni a modelltől, akkor kiigazították. (Lsd. Ajka, timföldgyár.)
A szent borzadályt az okozta nálam, hogy megpróbáltam elképzelni ugyanezt a filozófiát az informatikában. Elképzeltem, hogy dinamikus modellt kellene írnom egy olyan rendszerre, ahol egymás után tízszer megcsinálom ugyanazt és mégis más-más végeredményeket kapok. Nyilván meg lehetne csinálni valószínűségi sűrűségfüggvényekkel – de ez alapján folyamatot vezérelni?
Szerencsére kiderült, hogy nem erről van szó. A ‘modell’ kifejezés sokféleképpen érthető és itt elsősorban statikus, leíró modellekről volt szó. Mint például a jelenleg Exchange méretezésre emlegetett Capacity Planner. Ez például modell és használhatónak is tűnik. Használhatóbbnak, mint a hosszas fejvakarás után kibökött “rakjunk oda egy bazierős gépet” szentencia.
A modell leíró jellege a MOMv3 résznél domborodott ki igazán. Ha jól értettem, a modell erejét az adja, hogy pontosan leírja, ki kivel van jóban a bonyolult rendszerben és mennyire. Azaz ha valaki elkezd hülyeségeket beszélni, akkor a környezetében lévő háromperhármasok egyértelműen tudjanak rámutatni, hogy “igen, ő gárgyult meg”.
És ezzel vissza is csatoltunk oda, hogy mikortól lesz használható egy hibaüzenet. Nos, akkor, ha van hozzá egy jó modell.
Csakhogy ehhez az is kell, hogy minden elem tudjon beszélgetni egymással. És az is kell, hogy legyen valaki, aki naprakészen tartja a modellt.
Meg persze kell MOM. És ez megint egy kényes téma. Ugyanis abszolút nem értek hozzá. Pedig ha valakinek, akkor nekünk, ott az outsourcing cégnél kellene igazán ezzel kelni, ezzel feküdni. Hiszen SLA van, küszöbértékek vannak, bazi nagy seggberúgások vannak. Mégsem használjuk.

  • Az ügyfél ugyanis soha nem veszi meg. Ő azt mondja – jogosan -, hogy nem érdekli, hogyan biztosítjuk a rendelkezésre állást. (Feltételezem, ugyanez a probléma belső informatikánál is előjön. Egy olyan termékről nehéz meggyőzni a vezetőséget, mely első körben csak az informatikusok munkáját könnyíti meg. A második körig meg nagyon kevés vezető lát el.)
  • A szolgáltató viszont költségorientált. És kihasználja, hogy az ügyfelet tényleg nem érdekli, mivel oldják meg a monitorozást és riasztást. Azaz olyan rendszerekben is használhat ingyenes szoftvereket, gonosz, ‘X’-re végződő oprendszereken, ahol egyébként az ügyfél kizárja az open source termékeket. Tudásbázisnak meg ott vannak a szakemberei. (Mindemellett igen, a leírt, adatbázisba tolt tudásbázisnak tényleg megvan az extra előnye a fejben tárolt tudással szemben. Ez tény. De erre is megvannak a módszerek, mégha annyira nem is hatékonyak, mint a MOM tudásbázisa.)
  • Produkciós környezetben nagyon ritka a homogén Microsoft hálózat. Márpedig az üzemeltető azt szereti, ha lehetőség szerint egy monitorozó rendszer figyeli az összes szervert.

És végül eljutottunk kis kedvencemhez, a monadhoz. Pici, hatékony. Kell ennél több?
Ugyanolyan bizsergést érzek a tarkómban, mint amikor entínégy alatt elkezdtem barátkozni az MMC konzollal.

Mi van még? Egy gondolat maradt még a feljegyzéseim között. Arról szól, hogy tényleg nem hátrány, ha valaki fejlesztőként kezdte a pályáját és csak utána váltott át üzemeltetésbe. Nem csak azért mondom, mert anno én is így csináltam :P, hanem azért, mert szvsz sokkal jobban átlátja a rendszer működését az, aki valamikor védőszemüveggel hegesztette az objektumokat. Sokkal könyebb elképzelni az egyes szereplőket, ha az ember valamikor maga is kifaragott egyet-kettőt belőlük. Nem beszélve arról, hogy a szkripteléssel, az MSH-val szemléletet is kell váltani – és milyen jó, ha az új szemlélet már megvan, csak éppen szunyókál.

Aztán a végén volt könyvsorsolás. Az egyik képernyőn Janinak épp egy ismerősöm nevére mutattam rá, mely mozdulatot mICK jelentkezésnek nézte. Aztán mégsem adta nekem a könyvet, mert nem hitte el, hogy én vagyok Kovács Aranka.
Legközelebb jobban borotválkozok.

Itt sincs, ott sincs

Megőrjít.
Van egy kliens gépem. Ezen akarok futtatni egy szkriptet, mely távoli AD szájtok felhasználóinál módosítana display nevet. (Vbscript + ADSI.) Az adatok Excel táblában vannak.
Lefuttattam az egyik szájtra, a nevek átíródtak. Megnéztem ADUC-ból, tényleg.
Lefuttattam ugyanazt a szkriptet a másikra, nevek látszólag átíródtak. ADUC – mégsem íródtak át. Átfutottam az összes DC-t, sehol sem íródtak át. Picit átírtam a szkriptet, hogy most csak lekérdezze az értékeket – és tényleg nem íródtak át. Beleraktam még vagy ötször a setinfo-t, biztos, ami kurvafix – és kiegészítettem azzal, hogy írás után olvassa is vissza ADSI-n keresztül az értékeket és írja ki fájlba. Szkript lefutott, és a megváltozott értékeket írta ki. Gyorsan ADUC – sehol sem volt változás. Site-site replikáció megrángatása, újból körbenézés, semmi. Lefuttattam a szkriptet csak olvasó módban – a régi értékek jöttek vissza.
Hihetetlen.
A kliens gépről egy gyors próba, ldp-vel megváltoztattam a távoli szájt felhasználójának az adatát – és így működött, tehát se jogosultsági, se tűzfal probléma nincs. Ha ugyanezt egy nyomorult háromsoros vbscript-ből csináltam, akkor bezzeg nem ment.
Bele fogok dilizni. Ez az egy lépés van hátra abból a holland projektből, melynek már a nevétől is feláll a szőr a hátamon. És itt, az utolsó lépésnél jön be egy ilyen X akta, amikor már nem vágyom másra, mint hogy lezárjam ezt a szutykot.

Miután jól kisírtam magam, nekiálltam gondolkozni. Mi lenne például, ha kitörölném a bűvös ‘on error resume next’ sort?
Hoppá. Rögtön az elején befigyelt egy hiba:

Run-time error ‘-2147016693 (8007200b)
Automation Error
The attribute syntax specified to the directory service is invalid

Na, vajon mi lehet ez? Erős a gyanú, hogy adathiba, hiszen a szkript más szájtra lefutott. Kezdjünk játszani. Első körben csak a displayname értékét írtam ki – nem volt hiba. Jött a keresztnév, nem volt hiba. Jött a vezetéknév – és vele együtt a hiba. Hmm… ennyire kényes lenne az az sn attribútum?
Ránéztem az excel táblára – és letéptem az első sor csempét. Az adott szájton nem mi adminisztrálunk és a fiúk nem vacakoltak, a teljes nevet a keresztnévhez írták – azaz az sn attribútumba üres mezőt kellett volna betölteni. Ettől borult meg a szkript futás közben – de az onerrorresumenext továbblökte, mintha mi sem történt volna. Nem is történt semmi. Kiírás sem.
Oké. Akkor tegyünk bele egy vizsgálatot és ha üres a mező, akkor a kérdéses mezővel ne történjen semmi, de a sor többi mezőjét írja ki. Jó lesz ez? Nem biztos. Lehet, hogy az ügyfél törölt egy értéket és szeretné, ha az el is tűnne az AD-ból. Jó, akkor írjunk ki egy “”-t.
Nos, aki azt hiszi, hogy az oChild.attributum = “” lesz a jó megoldás, az még menjen vissza egy kicsit a homokozóba. Ugyanis pont ez a forma adta a fenti runtime error-t.
Igenám, de akkor hogyan lehet törölni egy attribútum értékét? Gugli.
És végül itt van a megoldás. Annyira szép, hogy alig hiszem el.
Tudni kell, hogy az AD-ba lehet cseppeként is írni. Ilyenkor csak a megváltozott attribútum értéke utazik a dróton, azaz spóroltunk egy csomó sávszélességet. Cserébe kicsit bonyolultabb a szintakszis.
Ilyen: oChild.putex X, “attributum”, valtozo,
ahol az X a helyzet kulcsa. Ugyanis ha X=2, akkor kiírás következik, ha X=1, akkor törlés.
Tehát a kérdéses kódrészlet:

If Trim(Cstr(Cells(sor,1).value)) = “” then
oChild.putex 1, “displayname”, “”
else
oChild.putex 2, “displayname”, Trim(Cstr(Cells(sor,1).value))
EndIf

Dögi. Futtassuk meg.
Megint ugyanazt a runtime error-t kapjuk. WTF?
Nos, ismét jött egy kis Gugli – majd megint lekerült a falról egy sor csempe.
A putex-es verzió ugyanis tömböt kér paraméternek. Miért? Csak. Akkor, amikor törlök, akkor nem is igazán kell neki érték, a “” bőven megteszi. De akkor, amikor módosítok, akkor bizony tömbbe kell rakni a változót.
Így fog kinézni a sor:
oChild.putex 2, “displayname”, Array(Trim(Cstr(Cells(sor,1).value)))
És ez már tényleg működik.

Illetve…
Boldogan engedtem rá a felturbózott szkriptet a böszme nagy excel táblára – és pár perc múlva megint runtime error-t kaptam. Egy kicsit megrugdostam az asztallábat majd nekiálltam nyomozni. Hiába. Minden teljesen rendben volt. Kínomban kimásoltam a táblázatból a dn értéket, benyomtam az ldp-be – és megfeküdt az is tőle. Nocsak. Nézzünk be az ADUC-ba.
Basszus. Amíg szarakodtam a szkripttel, addig törölték a felhasználót.
‘On error resume next’ visszakapcsol. Anyátok.

Eseutil XP alatt?

Bármilyen furcsa, de van. És időnként szükség is lehet rá.

A mostani hétvégét arra szántam, hogy kiépítsek otthon egy tesztkörnyezetet – elvégre nem élet az élet házi Exchange szerver nélkül. Virtual PC, Virtual Server van, idő szintén, akkor hajrá.
Az első meglepetést a Virtual PC okozta, ugyanis nem tudta bebootolni a virtuális gépet a telepítő cédéről. A cédé jó volt, a host gép be tudott róla indulni, a virtuális gép beállításai jók voltak – mégse. Mindegy, vacak 2004-es termék, lássuk a nagytesót.
Csakhogy ehhez előtte IIS-t kell telepíteni az XP-re. És rögtön az elején belefutottam egy dilemmába. Ez ugyanis még egy olyan oprendszer, mely sp1-ként települt és később lett rárakva az sp2. Milyen cédét adjak neki, amikor IIS-t akar telepíteni: sp1 vagy sp2?
Végül sp2-t adtam neki, de nem fogadta el. Gondoltam, mielőtt kipróbálnám az sp1-et, megpróbálom megetetni vele az önálló sp2 csomagot. Ez meg is volt valahol. Alig háromszor-négyszer kellett lefuttatnom, mire beugrott a varázslatos -x kapcsoló, amely csak kitömörít. (Korrektek voltak a fiúk, a /?, -? kapcsolókra simán elindult a telepítés. Ennyit a felhasználóbarátságról.) De ez a könyvtár sem tetszett az IIS telepítőnek. Végső elkeseredésemben beadtam az sp1 telepítőlemezt, de az sem volt elég jó.
Itt kezdtem el nagyon nem érteni a dolgot. Aztán a fejemre csaptam: az a hülye a staxmem.dll-t keresi, az összes telepítőszetben meg staxmem.dl_ van. Lehetséges, hogy ezen hasalna el a mutatvány? Ahogy visszaemlékszem, ez nem szokott problémát okozni – de tegye a szívét a kezére az, aki negyed másodpercnél tovább szokta figyelemmel kísérni az ilyen üzeneteket. Lehet, hogy most, pont most csúszott porszem a gépezetbe? És ha igen, mi a teendő? Átnevezhetem simán a dl_ fájlt dll-re? Vagy igyak inkább előtte egy fröccsöt?
Végül az lett a megoldás, hogy ittam egy fröccsöt és közben eszembe jutott, hogy még meg sem kérdeztem az esetről Gugli barátunk véleményét. Hiba volt. A korrekt esetleírás, a megoldási javaslattal, itt található.
Azért röviden összefoglalom.
Van egy secedit.sdb adatbázis valahol a %windir% valamelyik bugyrában. Ha ez megsérül, akkor az IIS telepítő nem fogad el bizonyos dll-eket. Hogy miért nem? Nincs hozzá gusztusa. Mittudomén. Azt se tudom, mitől sérülhet meg. Én egész biztosan nem szoktam kötekedni vele.
Imhol a gyógyítása:
esentutl /p %windir%\security\database\secedit.sdb
És ennél a sornál kezd el jojózni egy Exchange adminisztrátor szeme. Mi van? Eseutil? Az XP-ben?
Bizonyhogy. A név egy picit mutálódott, de a paraméterezés már ugyanaz. És az adatbázis kiterjesztése is beindíthatja a szabad asszociációs folyamot: mdb, edb… sdb… ez bizony JET típusú adatbázis lesz. Aztán amikor az enter lenyomása után megjelenik az a bizonyos rettegve utált karakteres bitkolbász, akkor már egész biztosan tudhatjuk, hogy a deja vu érzésünk helyénvaló volt.
Mellesleg a módszer működik.