Month: September 2007

Link a levélben

Mit csinál valaki, ha hónapokig dühöng, nem találja a megoldást, majd egyszer csak rájön, hogy ő volt a hülye? Normális ember ilyenkor behúzza fülét-farkát és eloldalog. Én viszont cikket írok belőle.

Az utóbbi fél évben – különböző katasztrófákból kifolyólag – többször is újra kellett telepítenem gépeket. Oprendszer, szutykok, office. Természetesen már a 2007-es.
És mindannyiszor belefutottam abba, hogy az Outlook2007 nem hajlandó linkként kezelni a linkeket. Ha nem lennék már alapvetően ősz, tuti erre fognék néhány hajszálat.
Ötvenszer átnéztam minden beállítási lehetőséget, körbekérdeztem haverokat, feldobtam a témát levlistákra, széthajtottam a guglit – mindhiába. Mindenhol remekül működött a link a levélben, csak nálam nem. Pedig beállítottam mindenféle formátumot. Mindenféle nyelvi kódolást. Kecskét áldoztam éjfélkor keresztútnál. Nem ért semmit.
Beletörődtem. Ez úgy látszik, a karmámhoz tartozik, együtt kell élnem vele.

Nemrég úgy kaptam vissza a tabletpc-met, hogy elő volt rá telepítve mind az XP, mind az Office. Kisördög bebúj, levél elküld – a link bizony link maradt. A-ha. Ezután szépen elkezdtem személyre hangolni a progit, ahogy szoktam. És időnként küldtem egy levelet.

Nem rabolom tovább az idődet, meglett a bűnös.

Nagyítás

Imhol. Autocorrect, azon belül autoformat.

És ekkor lett volna kedvem headbang-elni az íróasztalon. Ugyanis rájöttem, mi okozta a vakságot. A nagyra nőtt egóm. Ugyanis baromira kényes vagyok arra, hogy egy szoftver azt csinálja, amit elgondolok. Ne, hangsúlyozom, _ne_ próbáljon meg okosabb lenni nálam, ne próbálja meg a fülem állásából kitalálni, hogy tulajdonképpen nem is azt akarom, amit begépeltem, hanem valami egészen mást. Emiatt az az első, hogy minden szoftverben, amelyben van valami hasonló, gondolkodás nélkül kikapcsolok minden autokorrekciót. Mi azt, hogy gondolkodás nélkül? Elolvasás nélkül!
Így történhetett meg az, hogy nem vettem észre: a linkre hasonlító szövegrészből bizony az Outlook2007 autocorrect funkciója csinál ténylegesen linket.
Mindenki másnál – de nálam nem.

Az ellopott tartományvezérlő esete

A szerverszobában, a szokásos hétfő reggeli névsorolvasáson azt vesszük észre, hogy eggyel kevesebb tartományvezérlő válaszolja azt, hogy ‘jelen’.
Mi ilyenkor a teendő?
Először természetesen a pánik. Egy-két perc dühödt headbanging a szerverrack-en határozottan ki tudja tisztítani az ember tudatát.
Amint elül a pánik, az ember kezdi végigondolni a lehetőségeit. Sajnos ekkor már késő. Ugyanis nagyon gyorsan kellene cselekednie, hogy csökkentse a hálózatát fenyegető veszélyt.
A legjobb, ha már azelőtt elgondolkodik a helyzetről, mielőtt elcsakliznák tőle a gépet.

Ezt tette Steve Riley a 2006 szeptemberi Technet Magazinban.
Miután végiggondolt mindent, részletesen kielemezte a lehetőségeket, ezenkívül számbavett minden rejtekutat – a következtetését egy mondatban foglalta össze: ember, építsd újra az egész AD erdőt.
Borzasztóan hangzik. (Eltekintve attól, ha a kedves olvasó nem pont AD telepítésekből él.) Ennél még a korábbi pánik is kellemesebb volt.
Ezt Riley is elismeri, ezért hívja fel a figyelmet arra, hogy tegyünk meg időben mindent a tartományvezérlőink védelmében.

Azaz:

  • Láncoljuk le őket valami elvihetetlen tárgyhoz. Ha ugyanezt elektronikusan is meg tudjuk oldani az még jobb.
  • A címtárat több erdőből építsük fel, majd vezessünk be szelektív autentikálást.
    Azt hiszem, ez megér némi magyarázatot. Először is, ilyesmi csak Windows2003 címtárban létezik. Másodszor – és ez nekem is újdonság volt – a Microsoft szakított az eddigi ‘használj egy erdőt és egy tartományt’ modellel. Feltételezem, nem kis mértékben a szelektív autentikáció miatt.
    Mi is ez pontosan? Addig gondolom oké, hogy ha egy cég egy címtárban több erdőt használ, akkor azokat egy forest root-on keresztül össze is kell trustolnia. Itt, a truston lehet beállítani az autentikáció típusát: ez lehet teljes vagy szelektív. A teljes azt jelenti, hogy az egyik erdőbeli felhasználó (Farkas), amikor megpróbálja elérni a másik erdőbeli erőforrást (Piroska), akkor megadja a felhasználói nevet és jelszót, majd az erőforrás jogosultsági listája alapján vagy eléri azt, vagy sem. Ezzel szemben a szelektív autentikációnál már az is egy jogosultság, hogy a Farkas egyáltalán autentikálhatja-e magát.
    Ebben az esetben ha lenyúlják az egyik erdő tartományvezérlőjét, akkor csak az illető erdőt kell újrahúzni, illetve azokat az erőforrásokat megpiszkálni a többi erdőben, amelyek egyáltalán autentikálhatóak voltak a kompromittált erdő felől.
  • Telepíts read-only DC-t.
    Ez – mondjuk úgy – jótanács a jövőre nézve. Read-only DC majd a Longhorn Server családban lesz, mint ahogy ezen a blogon tanult kollégám nagyon alaposan ki is vesézte a témát.
  • Végül Riley leírja, hogyan kell gyorsan, hatékonyan címtárat tervezni. Gondolom azért, hogy újratelepítéskor nem kelljen azon agyalnunk, milyen elvek mellett is építettük fel anno az egyes alrendszereket.

Nos, oké. Riley letette a voksát.

Ekkor lépett színre Joe. (Joe Richards az egyik személyes kedvencem. Mint írtam korábban, a fiú Directory MVP, néhány nagy sikerű segédprogram megalkotója és a maga kendőzetlen, nyers modorában egészen jó cikkek szerzője.)
Szóval Joe rögtön azzal kezdi, hogy ez egy nagyon jó a kérdés, de szerinte teljesen rossz a válasz. Nem is vacakol sokat, felsorolja a _rögtön_ lezongorázandó teendőket:

  • Töröljük az ellopott tartományvezérlőt a címtárból. Azonnal. Gondolkodás nélkül. Erre teljesen jó az NTDSUTIL segédprogram. (Én fűzném hozzá, hogy ha volt a DC-n valamilyen FSMO, akkor azt természetesen el kell tőle rabolni.)
  • Reseteljük mindenkinek az accountját, akinek lokális belépési lehetősége volt a tartományvezérlőkön. (Népszerűségi indexünk egész biztosan fel fog szökni – de erről majd később.)
  • Reseteljük mindenkinek az accountját, akinek file/registry/services módosítási joga van az erdő tartományvezérlőin.
  • Reseteljük mindenkinek az accountját, akinek jogosultsága volt bármilyen AD-hoz kapcsolódó alkalmazás (Exchange, SMS, MOM, stb…) menedzseléséhez.
  • Ha a fenti adminok közül valamelyiknek van nem admin felhasználója, reseteljük azt is. Lehet, hogy az illető ugyanazokat a jelszavakat használta.
  • Reseteljük az összes DC jelszavát. (Segítségképpen megadja, hogy a PSExex és a NetDom resetpwd lesz a mi barátunk.)
  • Reseteljük a krbtgt tartományi felhasználó accountját. Méghozzá kétszer. Ekkor fognak elveszni a korábbi TGT-k. Szerencsére. (TGT: Ticket Granting Ticket; jegy, amellyel jegyet lehet igényelni a Kerberos szervertől.)
  • Reseteljük mindenkinek az accountját, akinek joga volt a normális felhasználói aktivitáson túl belepiszkálni a címtárba.

És most el lehet kezdeni filozofálni. Joe véleménye szerint a fenti adminisztrátori teendőkhöz 2-5 adminisztrátor bőven elegendő. Határozottan kijelenti, hogy ennyi accounttal végigzongorázni a fenti listát, másodpercek kérdése. Ha több accountunk van, érdemes szkriptelni. Ha ez a gyorsaság nem megy kézségszinten, nos, akkor Joe szerint kutyaütők vagyunk, nem rendszergazdák. A címtár a hálózat legnagyobb értéke, akinek a dolga ezt védeni, annak nagyon ott kell lennie a szeren.

A másik filozófikus kérdés: egyeztessünk-e előtte? Joe szerint semmiképpen sem. Tegyük a dolgunkat. Itt másodpercek számítanak. És ha azok az opciók, hogy lesz néhány parázs veszekedésünk vagy egy korrupt címtárunk… akkor mindenképpen az elsőt kell választanunk. Sőt, Joe szerint már akkor elveszítettük a csatát, ha éles helyzetben egyáltalán azon filózunk, hogy értesítsük-e őket vagy sem.

A fentieken kívül két dolgot kell még megtennünk:

  • Járassuk le a sárga földig az összes felhasználó jelszavát. Előtte azért szóljunk oda a helpdesknek…
  • Figyelmeztessük az összes rendszer összes service account tulajdonosát, hogy egy órán belül változtassák meg az accountok jelszavát. Ha nem teszik meg, változtassuk meg mi. Jobb utólag röviden elnézést kérni, mint hetekig tartó türelmet később. Egy ideiglenesen leállt alkalmazás nem ugyanaz a nagyságrend, mint egy korrupttá vált címtár. (Nem tudom… azért a banki alkalmazásoknál nekem lennének kétségeim. Ezzel – Joe szerint – meg is buktam. Ő ugyanis a nem tervezett leállítás viszonylag rövid idejét veti össze a címtár – újrafelépítés okozta – hosszabb leállás idejével. Igenám, de az utóbbi tervezett. _Normális_ leállás után a cég addig kitalál valami metódust, mittudomén, papírnoteszt és postagalambot, meg egy adatfeldolgozási technikát, hogy hogyan lehet majd ezeket beledolgozni az újra felállt rendszerbe. Lehet, hogy ez kevesebb költséggel jár, mint egy inkonzisztens adatbázis.)

Végül természetesen a hapi szót kerít arra, hogy régen rossz, ha egy ilyen helyzetben improvizálnod kell. Hiszen rég a fiókban – és a megfelelő emberek fejében – kellene lennie a haváriatervnek.
Hogy miért is jó egy ilyen terv? Itt inkább idézem Joe-t:

A. Understand what your weaknesses are now so you can correct them.
B. Be able to block things others try to bring into your environment that will add more weaknesses later.
C. Have something you can follow when the fan and the excrement meet f2f.

Itt a vége felé térjünk vissza egy kicsit a realitás talajára. Azért ma már szinte mindenütt természetes, hogy van valamilyen szerverszoba – és ezek valamilyen formában zárhatók is. Ilyen helyekről szervert ellopni már nem olyan egyszerű.
Csakhogy… nem csak cégközpontok vannak a világon, hanem telephelyek is. Márpedig mifelénk még mindig elég drága a sávszélesség ahhoz, hogy érdemes legyen távoli helyekre is egy-egy lokális tartományvezérlőt lerakni. Általában az is igaz, hogy ezek a vidéki DC-k leginkább munkaállomás kategóriájú gépek, lelökve valamelyik sarokba – hiszen a plusz gép költségét is nehezen nézik el az informatikának, nemhogy még szerverszoba is legyen a telephelyen. Nos, ezeket már könnyű megcsapni – márpedig akármennyire vidéki is a DC, de ott van rajta a tartományi névtér írható változata, az egész erdő konfigurációs névterének írható változata és az egész erdő sémájának olvasható változata.
Ijesztő.
Erre lesz majd megoldás a Read-only DC – hiszen az azon végrehajtott Ad változtatások nem replikálódnak szét a címtárban, így hiába dugná vissza a gonosz tolvaj a preparált tartományvezérlőt, nem érne vele semmit. (Ettől függetlenül a tartomány felhasználóinak a jelszavát feltörheti, tehát a fentebb írt jelszó resetelések tartományi szinten továbbra is meg kell történjenek.)

Nos, ennyi. Elolvashattunk két véleményt. Nekem a magam részéről Joe elképzelése jobban tetszik – különösen azért, mert felhívja a figyelmet, hogy lennie kell egy alaposan kidolgozott tervnek erre az esetre is.
Tényleg, nálatok van?

Megyen a log vándorútra

Az már önmagában jó ötlet volt, hogy SCC helyett LCR meg CCR lett, de az igazi nagy dobássá az SCR vált.

Nem, nem golyóztam be, legalábbis nem szignifikánsan. A fenti mondat Exchange adminok folyosói beszélgetésében teljesen természetesnek számít. (Ha jót akarsz magadnak, kerülöd az Exchange adminokat folyosói beszélgetés közben.)

Hogy érthető legyen, amiről beszélni fogok, tisztázzuk le, mi is történik a levelekkel, miközben bekerülnek az adatbázisba. Most azzal nem akarok foglalkozni, hogy mi is az az ESE, jelen esetben nem lényeges. Sokkal fontosabb, hogy tudjuk, hogyan működik a tranzakció alapú adatbáziskezelés. Az alapelv az, hogy van egy napló, egy úgynevezett tranzakciós log, melybe vezetjük, hogy tulajdonképpen mit is szeretnénk tenni az adatbázissal. Az első félreértés már rögtön itt adódik: melyik adatbázissal? És jön is visszakézből: miért, hány adatbázis van? A válasz egyszerű: kétszer annyi. Mindig. Ugyanis minden megnyitott adatbázisnak van egy példánya, mely a merevlemezen van és van egy példánya/szelete a memóriában. Értelemszerűen sokkal gyorsabb azzal a példánnyal dolgozni, mely a memóriában van – csakhogy az a példány olyan, mint az élet: ha lekapcsolják a főkapcsolót, elillan. Amelyik megmarad, az a merevlemezen lévő. Melynek kezelése lassú, mint idő múlása a fogorvosi váróban. Jó lenne, ha egybe tudnánk gyúrni az előnyöket, anélkül, hogy a buliról a hátrányokat értesítenénk.
Nos, jön az a tranzakció. Tokkal vonóval beírjuk a logba, hogy pl. Kis Piroska törölte a ‘Ph@nt@st1c V I A G R A buy n0w’ tárgyú levelét. Ki is töröljük, a memóriában lévő példányból. A levelezőkliensek a memóriában lévő példányt látják, tehát azt hiszik, tényleg ki lett törölve a levél. Pedig nem, a lemezen lévő példányban ott van. Onnan akkor fog eltűnni, ha éppen ráér a szerver. Vagy hátbavágja egy backup. Akkor, amikor ténylegesen kitörlődik a lemezen lévő példányból, akkor lesz lezárva a tranzakció a logban. Nézzük, mi történik, ha a takarítónő elemet akar tölteni és emiatt a porszívó mellett a másik konnektorra is lecsap, kihúzva a redundáns tápunk mindkét madzagját? Az Exchange szerver leállt, a memóriában lévő adatbázispéldány füstté vált… de ott van a merevlemezen lévő adatbázis és a tranzakciós logok. Látjuk, hogy mely tranzakciókhoz tartozik lezárás – azok már kikerültek a vinyóra. De a lezáratlanok még nem – nosza, írjuk ki. Ezt hívják úgy, hogy rájátsszuk a logokat az adatbázisra.
Igen, jogos a kérdés… mit nyertünk ezzel? Hiszen írunk a lemezre… Írni ugyan írunk, de nem mindegy, hogyan. Ugye mindenki tudja, hogy a tranzakciós lognak külön merevlemeze van, ahová a fej folyamatosan ír, olvasni gyakorlatilag nem olvas? Ég és Föld különbség van eközött az írás és egy többszáz gigás adatbázisba illesztő írás között.

A hosszú bevezetésnek annyi volt az összes értelme, hogy tudjuk: aktuális adatbázis = merevlemezen lévő adatbázis + tranzakciós logok. A sok CR végű akronim pont ezzel a képlettel trükközik.

És akkor oldjuk is fel őket:

  1. SCC – Single Copy Cluster
  2. LCR – Local Continuous Replication
  3. CCR – Cluster Continuous Replication
  4. SCR – Standby Continuous Replication

Az első a sima cluster. Exchange2003-ban csak és kizárólag erre hivatkozhattunk, ha magas rendelkezésreállásról faggattak az ügyfeleink.
Exchange 2007-ben viszont már megjelentek az ún. log shipping technikával dolgozó eljárások is. Ezek a *CR-ek.

LCR: A konkrét Exchange gépen egy megadott könyvtárba ‘elülteti’ (seeding) az adatbázist – azaz másolatot készít róla. Innentől miközben dübörög az Exchange szerver, pörögnek a logok, mindegyikről másolat is készül az előző könyvtárba. Mit védtünk ki ezzel? Azt, hogy ha például megsérül az adatbázisfájl. Ha felrobban az adatbázist tartalmazó merevlemez. Ekkor ugyanis a másik merevlemezről – mert annyi eszünk gondolom volt, hogy az LCR könyvtár másik merevlemezre került – manuális beavatkozással beröffentjük az adatbázist. (Ugye van minden: log és adatbázis.) Ez a legegyszerűbb log shipping, nem kell hozzá semmi se, igaz, csak merevlemezhiba ellen véd.

CCR: Ez már komolyabb. Kell hozzá a cluster szolgáltatás. És kell hozzá a Microsoft Exchange Replication szolgáltatás. A forgatókönyv az, hogy van egy cluster, két node, ahogy kell… de nincs közös adatterület! Nincs quorum. Kell a francnak, csak baj volt vele. Ehelyett van egy file share valahol, oda irkál mindkét node. (Igen, van egy kicsi ‘Majority Node Set’ áthallás.) Az adatok naprakészségét pedig úgy biztosítja az előbb említett szép hosszú nevű szolgáltatás, hogy a logokat másolgatja folyamatosan mindkét node-ra. Látható, hogy ez már komolyabb dolog: automatikus failover/failback, komoly rendelkezésreállás, de böszme hardverköltség nélkül. Viszont vannak hátrányai is: a cluster két node-ja nem lehet külön alhálózaton. Ezzel gyakorlatilag nem tudunk védekezni az épület lebombázása ellen.

SCR: Egyfajta arany középút. De tényleg arany. Mit is tud? Van egy éles Exchange szerverem és van egy standby Exchange szerverem. Mindkettő működik, a magvetés után mindkettőn ott van az adatbázis, de a felhasználók az éles szervert érik el. A logmásolás folyamatos. Ha kidől az éles szerver, a standby szerveren lévő adatbázist előléptetjük – és megy minden tovább. Nézzük az előnyöket: kitörtünk a szerverszobából. Nincs alhálózatra vonatkozó megkötés, ha jó a vonalunk, akár Balatonfőkajárra is lerakhatjuk a standby szervert. Nem kell hozzá cluster szolgáltatás. Egyszerre több standby gépet is használhatunk, maximum négy lehet. A forrás gép lehet egyszerű Exchange szerver, de lehet LCR, CCR, SCC is. Hoppácska. Azaz mezei szerverekkel össze tudok hozni egy olyan figurát, hogy a szerveren belül LCR-t használok, telephelyen kívül pedig SCR-t. (Viszont SCC/CCR esetében él az alhálózati korlát, hiszen ezt végül is a cluster szolgáltatás kényszeríti ki. Kivéve persze az MNS-t.) Hátrány: nincs automatikus átállás, össze kell piszkolnunk a kezünket. Másik hátrány: majd az SP2-ben jelenik meg végleges formában; viszont a béta2-ben már tesztelhető.