Rollback

Klasszikus probléma, hogy van egy Windows login az SQL szerveren, aki benne van N csoportban, amik benne vannak másik M csoportban, és a répamese jegyében ez összesen nagyon sok csoport lesz. A kérdés pedig az, hogy pontosan melyik csoporttagságán keresztül milyen jogot is szerzett az SQL szerveren. Na, pont erre nyomtam egy lenyűgöző Powershell demót a SQL 2008 R2 bejelentési eseményen, aztán elhagytam a scriptet. Mivel valami dupla mákos hakkolás volt, próbáltam felhajtani, de nem sikerült. Viszont a vicc, hogy ugyanezt a fícsört megtaláltam beleépítve a SQL szerverbe.

A neve xp_logininfo, és két irányba is működik:

exec master..xp_logininfo [EMEA\EBitemo], 'all'

megmondja az összes csoportot, melyen keresztül engem beenged a SQL Server.

exec master..xp_logininfo [EMEA\#DBA_Operators], 'members'

pedig megmondja, h kiket is enged ő be azon a csoporton keresztül.

Ezzel TT felé való négyhónapos adósságomat rendezettnek tekintem :)

Diszket kellett bővíteni egy SQL clusterben, a lehető legkevesebb leállással, úgyhogy úgy döntöttem, hogy folytatom, amiben jó kezdek lenni: scriptelek. A cluster diszkek hozzáadása önmagában nem nagy szám (most felhördül legalább 28 ember, akinek már voltak rossz élményei a témában – nekem is, de a lekapcsolt többi node majdnem mindig dobott a dolgon), a jó rész az, hogy az SQL csak azokat a diszkeket használja, amiken dependál a service, a dependenciát pedig csak leállított helyzetben lehet állítgatni. Itt jön jól a script, hogy ne kelljen klikkelni, míg megöregszem. Ezúttal a cluster.exe volt a műtéti alany, az eredmény pedig alant látható (a sql12clus clustert megtámogatva):

cluster.exe sql12clus resource "SQL Server" /Offline
cluster.exe sql12clus resource "SQL Server" /AddDependency:"K: BillingData"
cluster.exe sql12clus resource "SQL Server" /AddDependency:"L: BillingLog"
cluster.exe sql12clus resource "SQL Server" /Online

Azaz leállít, dependenciát hozzáad, elindít. Egy öröm volt.

Az egyszeri történet szerint a céges szabályzatok a következőképpen készülnek: egyszer egy csoport majmot bezártak egy ketrecbe, ahol felakasztottak egy banánt. Akárhányszor az egyik majom hozzányúlt a banánhoz, mindegyik állat hidegzuhanyt kapott. Hamar leszokott mindenki a banán piszkálásáról. Egy idő után megszűnt a víz, a majmok már nem is próbálkoztak. Aztán kicserélték az egyik majmot, és az új fiú rögtön rápróbált a banánra, de alig ért a közelébe, a többiek elverték. Lassan rájött, hogy a banán tabu. Aztán kicserélték az összes majmot, és mindet megtanította az aktuális csoport, hogy ne próbálkozzon a banánnal. Végül nem volt egy majom sem a ketrecben, aki látta volna a zuhanyt, de a banánhoz senki sem nyúlt.

Az informatikában így születnek a csontvázak, amikről senki sem tudja, hogy miért vannak ott és úgy, de senki nem meri megmozdítani. Hogy ezt miért mesélem most el? Mert a múltkor tesztkörnyezetet építettem, és miközben a SID-eket ütögettem át a Sysinternals NewSID.exe programjával, azon gondolkoztam, hogy miért is kell pontosan átütni őket… Valami rémlett ,hogy amikor belépnek a domainbe, akkor jön a gubanc, meg amikor egymással beszélgetnek, de hogy pontosan mi, azt nem tudtam. Úgyhogy elkezdtem túrni a netet, és belefutottam Mark Russinovich friss blogbejegyzésébe: a NewSID.exe megszűnik. Mark a Windows lelkivilágának nagy ismerője, a Sysinternalsos progik (többek között a newsid.exe) fő szerzője. De miért szűnik meg ez a kütyü?

Az úgy kezdődött, hogy Mark kapott pár visszajelzést, amikor a newsid.exe gubancot okozott. Ezeket próbálta kibogozni, és arra gondolt, hogy jó lenne tudni, milyen gubancot előz meg a progi. Elment tehát a Windows fejlesztőkhöz, hogy pontosan milyen problémák fakadnak a duplikált SID-ből. És a fejlesztők némi töprengés meg kód átnézés után azt mondták: Semmilyen.

Apró öröm, hogy Mark pont előttem egy héttel gondolkozott el ezen a témán, de az eredmény így is mellbevágó. Remélem most már mindenki érti a majmokat.

Még fut mellettem az install, de annyira jó, hogy le kell írnom (update: már Windows 7-en vagyok). A dizájnerek biztos nem vetették meg a sci-fit, remélem ez marad a bootloader a végleges változatban is :)

Első és legfontosabb: Windows 98 óta nem lehetett ennyi idő alatt Windowst telepíteni. 30 perc onnantól, hogy berakom az install DVD-t odáig, hogy kattinthatok először szabadon a start menün. Kérdez az elején hármat, a végén hármat, és ennyi. Feltoltam rá az Office-t meg néhány egyéb apróságot.

Vannak persze furcsa élményeim, mert kliensoldalon az XP az utolsó emlékem (a Vistát kipróbáltam pont amikor kijött, de két hét alatt nem jöttem rá, hogy miért szeretném jobban, mint az XP-t). Meg persze notebookra telepítem, és már előre a hekkeléshez van idomítva a rendszer – például KELL a 32 GB-nál nagyobb FAT32 partíció, hogy lássa az Ubuntu is a virtuális gépeimet, mert néha az fog kelleni (a company policy nagy úr). Viszont 64 bites a gép, 64 bites a W7, és minden működik. Még a beépített Bluetooth adaptert is simán felismerte magától.
Így egy (fél) nap után az élmény pozitív, az IE8 teljesen élvezhető, csak még nincs hozzá 5000 plugin, mint a Firefoxhoz, de remélem, hogy lesz. Emberek, vegyenek Windows 7-et! A fiamnak már adtam egy install DVD-t…

(For English version, read this) Elnézést, megvadultam, és elsőre angolul írtam meg ezt a postot, csak most fordul le magyarra.

Szóval kaptam egy kész Microsoft failover clustert, hogy megépítsem rá az SQL clusteremet, és a tesztelés során azt vettem észre, hogy botrányosan lassna billen át a cluster, másfél-két percig is eltart, az idő nagy részében pedig a network name-re várunk, ami online pending állapotban van vagy másfél percig. Némi molyolás után megállapítottam, hogy csak a network name a problémás, ha levittem offline-ba és visszahoztam rögtön ugyanazon a node-on, az is ugyanolyan sokáig tartott. Némi guglizás után találtam még egy csomó embert ugyanilyen problémával, de megoldást igazából nem. Végül kikötöttem egy Exchange 2007 W2K8-on poston, ami segített megtalálni a problémát, ami majd kiverte a szememet. Logikusan végiggondolva rá is jöhettem volna, de persze megint túldimenzionáltam ezt a kutya közönséges problémát, csak azért, mert egy komolyabb környezetben jött elő. Szóval az tartott másfél percig, hogy a hálózati kapcsolat beállításainál a DNS fülön be volt kapcsolva a Register this connection’s addresses in DNS opció, szegény szerver meg mindig nekiugrott a DNS szervernek, aki ignorálta a regisztrációs próbálkozásait. Erre ő elég lassan jött rá, és nem tanult az esetből, legközelebb megint megpróbálta. Kikapcsoltam, láss csodát: egy másodperc alatt felhozta a network name-et. Hepiend és kiváló alkalom volt megint az alázat gyakorlására.

Apropó cluster: a cluster ír egy kedves kis logot a C:\Windows\Cluster\cluster.log fájlba, néha hasznos lehet.