edirectory oktatási segédlet

Dokumentáció

www.npsh.hu

eDirectory oktatási segédlet

eDirectory oktatási segédlet – Dokumentáció

Védjegyek és Jogi nyilatkozat Copyright © Novell, Inc. Minden jog fenntartva. A Novell, és termékei a Novell, Inc. bejegyzett védjegyei az Egyesült Államokban és más országokban. A bejegyzett védjegyek teljes listája a Novell weboldalán található: http://www.novell.com/company/legal/trademarks/tmlist.html. A Linux Linus Torvalds bejegyzett védjegye. Az egyéb védjegyek a birtokos cégek tulajdonát képezik. A jelen dokumentáció kizárólag a HUEDU, ügyfél címe részére készült, ezért egyéb területen, más szervezetnél történő alkalmazásokhoz a Novell Consulting és a Novell Professional Services Hungary nem járul hozzá. A jelen anyag nem másolható, fénymásolható, továbbítható vagy tárolható, csak a Novell Professional Services Hungary előzetes írásos engedélyével. A jelen dokumentum OpenOffice.org 3 Novell Edition programmal készült. Novell Professional Services Hungary 1124 Budapest, Csörsz u. 45. Tel.: +36 1 4894600 Fax.: +36 1 4894601

2/37


Tartalomjegyzék I. Bevezetés................................................................................................................................. 5 II. Fogalmak................................................................................................................................. 5 II.1. A címtár...............................................................................................................................................5 II.2. Az eDirectory sémája...........................................................................................................................5 II.3. Partíciók...............................................................................................................................................5 II.4. Replikák...............................................................................................................................................6

III. Az eDirectory objektumai........................................................................................................ 6 III.1. Konténerobjektumok..........................................................................................................................6 III.2. Levélobjektumok................................................................................................................................7

IV. Az eDirectory biztonsági rendszere......................................................................................... 9 IV.1. Objektumok jogosultjai.......................................................................................................................9 IV.2. Objektumjogok.................................................................................................................................10 IV.3. Tulajdonságjogok.............................................................................................................................10 IV.4. Az Összes tulajdonság és a Kiválasztott tulajdonság közötti különbségek......................................11 IV.5. Az eDirectory-objektumok jogainak megállapítása..........................................................................11

V. Az eDirectory elnevezési szabályai........................................................................................ 12 V.1. Az objektumok elnevezési szabályai.................................................................................................13 V.2. Az objektumok névtípusai.................................................................................................................13

VI. Az eDirectory működése, állapotfelmérése........................................................................... 15 VI.1. Partíciószinkronizáció.......................................................................................................................15 VI.2. Időszinkronizáció..............................................................................................................................15 VI.3. DS-verziók........................................................................................................................................15 VI.4. Partíciófolytonosság.........................................................................................................................16 VI.5. Szabad hely a SYS köteten...............................................................................................................16 VI.6. A szerverek közötti kommunikáció..................................................................................................16 VI.7. Ismeretlen eDirectory-objektumok...................................................................................................16 VI.8. Háttérfolyamatok.............................................................................................................................17 VI.9. Egyedi faelnevezés...........................................................................................................................17 VI.10. Szám_szám objektumok.................................................................................................................17

VII. Segédprogramok.................................................................................................................. 17 VII.1. DSBrowse........................................................................................................................................17 VII.2. DSRepair..........................................................................................................................................18 VII.3. eDirectory-javítási műveletek NetWare-en.....................................................................................21

VIII. Az eDirectory karbantartása................................................................................................ 29 VIII.1. Heti teendők...................................................................................................................................29 VIII.2. Havi teendők..................................................................................................................................29

IX. Az eDirectory mentése.......................................................................................................... 30 IX.1. Az objektumazonosítók és a replikáció folyamata...........................................................................30 IX.2. Alternatív mentési eljárások.............................................................................................................31 IX.3. A Novell-címtárszolgáltatás visszaállítása.......................................................................................32 IX.4. Az eDirectory teljes visszaállítása....................................................................................................33

3/37


X. Az eDirectory karbantartása.................................................................................................. 34 X.1. Heti teendők (NetWare)....................................................................................................................34

XI. Az eDirectory hibaelhárítása................................................................................................. 34 XI.1. eDirectory hibakódok.......................................................................................................................34 XI.2. A támogatóközpont által kért adatok, naplófájlok összegyűjtése, elkészítése................................36

4/37


I. Bevezetés A Novell-címtárszolgáltatás (eDirectory) egy többplatformos, elosztott adatbázis, amely a számítógépes hálózat felhasználóiról, hardver- és szoftvererőforrásairól tárol adatokat és lehetővé teszi, hogy minden felhasználó egységesen, probléma mentesen és globálisan hozzáférjen az összes, számára engedélyezett hálózati erőfor ráshoz. Ezzel a teljes körű szolgáltatásokat nyújtó címtárral felügyelhető és kézben tartható a könyörtelen gyorsasággal változó, dinamikusan fejlődő, új technológia megoldásokat alkalmazó szervezetek teljes informa tikai háttere. Használatával komoly pénz takarítható meg, mivel lényegesen gyorsabban lehet reagálni a felhasználók igényeire és problémáira. Összefoglalva: az eDirectory egy teljes szolgáltatáskörű címtár, amely leegyszerűsíti, automatizálja és védi az adatokat és az őket kezelő folyamatokat, ugyanakkor maximálisan kihasználja és támogatja a kialakulóban lévő technológiákat. A rugalmas címtáradatbázis-sémára épülő eDirectory páratlan hálózati biztonságot és konzisztens, többplatformos fejlesztési környezetet nyújt. Az eDirectory ezt úgy valósítja meg, hogy a hálózati erőforrásokat egyformán, objektumokként tárolja. Az objektumok egy világosan áttekinthető, hierarchikus szerkezetű címtárfába szervezhetőek. Egyetlen munkaállomásról akár több címtárfa is felügyelhető. A címtáradatok módosulásai automatikusan átmásolódnak (replikálódnak) a szervereken tárolt eDirectory-adatbázispéldányokba, az ún. eDirectory-replikákba. A replikációs folyamatok nem csak NetWare kiszolgálókkal alakíthatók ki, mivel az eDirectory képes NetWare, Windows NT, Windows 2000, Solaris és Linux platformokon is futni és egymással együttműködni. Ez az egyedülálló képessége AIX és HP-UX platformokon is elérhető.

II. Fogalmak A replikáció és szinkronizáció megértéséhez elsőként tisztáznunk kell néhány alapfogalmat.

II.1. A címtár A címtár az alábbi tulajdonságokkal rendelkezik:

• Rendezett adatbázis, amely az eDirectory-címtárfa összes objektumának tulajdonságait tárolja – az objektumok nevét, a hozzájuk kapcsolódó jogokat és tulajdonságértékeket egyaránt.

• Az eDirectory a címtárat használja a hozzáférés vezérlésére (annak ellenőrzésére, hogy egy objektum jogosult-e megtenni valamit vagy sem).

• Az eDirectory a címtárat használja a hitelesítéshez. • A „Szerver”- és a „Kötet”-objektumokat kivéve, a címtár nem tartalmaz adatokat a fájlrendszerről.

II.2. Az eDirectory sémája Sémának nevezik az adatbázisok szerkezeti definícióját. Ebben határozható meg egyrészt az adatbázis fizikai felépítése – a táblázatokat, mezőket stb. – és a metafizikai struktúrája – azaz mindazon elemi egységek (és azok tulajdonságai), amelyek együttese fogja kialakítani a mindennapos tevékenységek során használt szerkezeteket. Az eDirectory sémája kifejezetten azt határozza meg, hogyan épül fel az ún. címtárfa – az a hierarchikus struktúra, amelybe az eDirectory objektumai szerveződnek. A séma rendkívül hasonlít az objektumorientált nyelvekből ismerős osztálykönyvtárakra: az általánosabb fogalmakból egyre specifikusabb objektumosztályokat definiál. Az eDirectory-séma a címtár egyik részében, ún. partíciójában, a sémapartícióban található.

II.3. Partíciók A particionálás a címtár részekre osztását jelenti. Mivel egy nagy címtár akár objektumok tízezreiről is tárolhat adatokat, szükség van a particionálásra, hogy a címtár szétosztható legyen több szerver között. A partíciókat a központi rendszergazda felügyeli.

5/37


II.4. Replikák A replika egy adott partíció objektumait ténylegesen tartalmazó adatfájl. A replikák a hálózat szerverein szétosztva találhatók, működésüket a központi rendszergazda felügyeli. Az eDirectory az alábbi replikatípusokat használja; melyek mindegyikének megvan a saját funkciója:

• Mester replikák (master) • Írható-olvasható replikák (read/write) • Csak olvasható replikák (read-only)) • Alárendelt referenciák (subordinate reference) • Szűrt replikák (filtered replica Hangsúlyozottan javasoljuk, hogy a címtárfa minden egyes partíciójáról tartsunk legalább három replikát, vagyis egy mastert és két írható-olvasható replikát. Három replika megfelelő hibatűrést biztosít, ugyanakkor minimalizálja a szerverek közötti szinkronizációs forgalmat. A NetWare telepítőprogram a címtárfa szervereinek telepítésekor alapértelmezés szerint automatikusan létrehoz három eDirectory-replikát a hibatűrés érdekében. Ha annak a partíciónak, amelybe telepítjük az új szervert, még nincsen három replikája, akkor a telepítőprogram egy írható-olvasható replikát tesz az új szerverre. A replikák fizikai elhelyezésével sokat javíthatunk az eDirectory-hozzáférés teljesítményén. Célszerű a partíció egy replikáját azon felhasználókhoz közel tárolni, akik a leggyakrabban férnek hozzá a benne található adatokhoz; ez lerövidíti a hitelesítésekhez, változtatásokhoz és keresésekhez szükséges időt. Ideális megoldás, ha egy partíció összes replikáját olyan szerverekre tesszük, amely ugyanazon fizikai helyen található, mint a partíció. Ha csak nem muszáj, sose tegyünk replikát egy WAN-kapcsolat túloldalára, ha vannak helyi (a WANkapcsolat innenső oldalán lévő) szerverek. Ha nem így teszünk, megnöveljük a szinkronizációs forgalmat, és lelassítjuk a szinkronizációt, ugyanis a partícióműveletek során a partíció összes replikájának látnia kell egymást; egy átmenetileg kiesett WAN-kapcsolat komoly problémákat okozhat. Ideális megoldás, ha a replika elhelyezés révén a felhasználók adatai ugyanazon szerveren találhatók, mint a home könyvtáraik. Ez persze nem mindig lehetséges, de nagymértékben megnöveli a felhasználók az eDirectory-objektumokhoz való hozzáférésének sebességét.

III. Az eDirectory objektumai Minden egyes eDirectory-címtárfa a sémában definiált osztályokba tartozó objektumokból épül fel. Az objek tumok meghatározott tulajdonságokkal (property) – vagyis bizonyos értékeket felvehető mezőkkel – rendelkeznek. A séma határozza meg azt, hogy az objektumok a fában milyen helyet foglalhatnak el, milyen tulajdonságokkal bírhatnak és milyenekkel nem. Az eDirectory-objektumok két fő típusa a konténerobjektumok és a levélobjektumok.

III.1. Konténerobjektumok A konténerobjektumok nevüket onnan kapták, hogy más objektumokat tartalmazhatnak. Alapvetően négy fő típusuk van, azonban minden olyan objektumot „konténerobjektumnak” nevezünk, amely alatt más objektumok találhatók (pl. DNS zóna objektum):

• „Ország” (Country, C) • „Helyszín” (Locality, L) • „Szervezet” (Organization, O) • „Szervezeti egység” (Organizational Unit, OU) Ötödik, kizárólag egyetlen példányban előforduló speciális konténerobjektum a [Root] objektum, a címtárfa kezdőpontja, „gyökere”. A legtöbb NetWare-telepítésben nem használják az „Ország”- és „Helyszín”-objektumokat, olyannyira, hogy a szabványos NetWare-telepítőprogram ki is hagyja őket. A konténerobjektumok legfontosabb szerepe, hogy tagolják a címtárfát és logikus, a vállalat felépítését és a fizikai hálózatot egyaránt tükröző rendbe szervezzék a hálózat objektumait. Mivel a konténerobjektumokhoz 6/37

eDirectory oktatási segédlet – Dokumentáció rendelt hozzáférési jogok alapértelmezésben továbböröklődnek a konténerben található objektumokra (amely öröklött jogok azután szükség esetén egyenként felülbírálhatók), a konténerekkel igen látványosan leegyszerűsíthető a hálózatfelügyelet, hiszen például felhasználók egész csoportjára határozhatunk meg egyszerre bizonyos hozzáférési jogokat. A „kötetobjektumok” nem nevezhetők konténerobjektumoknak, mivel az alattuk található információk a fájlrendszerben tárolódnak.

III.1.1 „Ország” (Country, C) Az „Ország”-objektumok, amennyiben használják őket, kizárólag a [Root] objektum alatt helyezkedhetnek el. Érdemi szerepük a több országra kiterjedő, multinacionális cégeknél lehet.

III.1.2 „Helyszín” (Locality, L) „A „Helyszín”-objektumok elhelyezkedhetnek akár a [Root] objektum, akár bármely más konténerobjektum alatt. Egyfajta „dzsókerkonténer”, a címtárfa az üzleti igényeknek leginkább megfelelő tagolásához használható.

III.1.3 „Szervezet” (Organization, O) A jellemzően a vállalat egészének, vagy legalábbis valamilyen igen nagy részének megfelelő „Szervezet”objektum a fent említett három konténer mindegyike alatt elhelyezkedhet, ám leggyakrabban közvetlenül a [Root] objektum alatt található. Minden fában lennie kell legalább egy O-objektumnak, és igen ritka, az egynél több O-konténer.

III.1.4 „Szervezeti egység” (Organizational Unit, OU) A „Szervezeti egység”-konténerobjektum is opcionális, leggyakrabban a szervezet kisebb egységei, munkacso portok, osztályok részlegek reprezentálására szolgál. Csak „Szervezet”-, „Helyszín”- és más OU-objektumok alatt helyezkedhet el, [Root] és „Ország” alatt nem.

III.2. Levélobjektumok Legegyszerűbb talán úgy definiálni a levélobjektumokat, hogy „minden objektum, ami nem konténer”. Nagy részük a hálózat fizikai entitásait – szervereket, nyomtatókat, munkaállomásokat, felhasználókat, köteteket stb. – reprezentál, szemben a levélobjektumok rendbe szervezésére és felügyeletének leegyszerűsítésére szolgáló konténerekkel. Fontos kiemelni, hogy a „Csoport”-objektum, bár neve azt sugallja, nem konténer – a hozzárendelt felhasználók ugyanis nem „benne találhatók”, csak „egyenrangúnak” vannak jelölve a csoporttal. Bizonyos levélobjektumok elsődleges szerepe, hogy egyszerűsítse a rendszerfelügyeletet, és ne kelljen egyesével törődni minden egyes felhasználóval a jogok megváltozása esetén. Néhány ezek közül:

III.2.1 „Felhasználó” (User) Minden egyes, a hálózatra bejelentkezni kívánó egyénhez tartozik egy „Felhasználó”-objektum. Tulajdonságai között megtalálható felhasználó neve és jelszava, saját könyvtára, hozzáférési jogai, címe és telefonszáma stb. „Felhasználó”-objektum bárhol létrehozható a címtárfában, de a felhasználónak ismernie kell saját ún. kontex tusát (annak a konténernek a teljes nevét, amelyben az ő objektuma található) ahhoz, hogy be tudjon jelent kezni a címtárfára.

7/37


III.2.2 „Csoport” (Group) Elsősorban azt a célt szolgálja, hogy több, különböző konténerben lévő felhasználónak, vagy egy konténer nem összes felhasználójának gyorsan ki lehessen osztani egyforma jogokat (egyébként ugyanis elég lenne azokat a konténerhez rendelni). A csoport-objektumok létrehozásakor vegyük figyelembe az alábbi szempontokat:

• Lehetőleg abban a konténerben hozzuk létre, amelyikben a hozzárendelt alkalmazás is található. • A tagok száma ne haladja meg az 1500-at. • A csoporttagság soha ne nyúljon át WAN kapcsolatokon. • Ha lehet, az adott csoport tagjai legyenek a csoporttal azonos partícióban. Ezáltal lecsökkenthető a külső hivatkozások száma és az általuk generált hálózati forgalom.

• A csoporttagság a csoport objektum és a felhasználó objektum két-két tulajdonságában kerül rögzítésre, ezek a csoport oldalon a „member” és a „equivalent to me””, a felhasználón a „Group membership” és az „security equal to” attribútumok.

• A csoport-objektum nem tartalmazhat más csoportokat.

III.2.3 „Szervezeti szerep” (Organization Role) Lényegében egyfajta „egyszemélyes” csoport: arra szolgál, hogy ne egy személyhez, hanem egy szerephez rendelhessünk bizonyos jogkört, és utána egyetlen mozdulattal helyezhessünk bele egy felhasználót ebbe a jogkörbe.

III.2.4 Dinamikus csoportok (Dynamic groups) A dinamikus csoportok egy LDAP URL-t használnak a szabálykészlet definiálásához, amelyet az eDirectory „felhasználó”-objektumoknak megfeleltetve határozzák meg a csoport tagjait. A dinamikus csoportok tagjai egy közös attribútumhalmazok osztoznak, amelyet az URL-ben megadott szűrő határoz meg. A dinamikus csoportoknál meghatározhatjuk a csoporttagság kiértékelésnél használt kritériumokat. A csoport aktuális tagjait az eDirectory dinamikusan értékeli ki, ezáltal a csoporttagokat logikai csoportosítással is meghatározhatjuk, és az eDirectory automatikusan hozzáadhat és törölhet csoporttagokat. Ez a megoldás kiegészíti az LDAP normál csoportjait, és nagyobb rugalmasságot biztosít. Az eDirectory 8.7.3 lehetővé teszi dinamikus csoportok létrehozását, ha a felhasználókat automatikusan csoportosítani szeretnénk valamely tulajdonság alapján, vagy ha ACL-eket szeretnénk alkalmazni a megfelelő DN-t tartalmazó csoportokra. Például létrehozhatunk egy csoportot, amelyben automatikusan benne lesz az összes olyan felhasználó, amelynek Department tulajdonságának értéke Marketing. Ha egy keresési szűrőt alkalmazunk a Department=Marketingre, a keresés eredménye egy olyan csoport lesz, amely magában foglalja az összes Department=Marketing-et tartalmazó felhasználót. Ezután a szűrő alapján létrehozhatunk egy dinamikus csoportot a keresés eredményéből. Ha a Department=Marketing kritériumnak megfelelő felhasználót adunk hozzá a címtárhoz, a felhasználó automatikusan bekerül a csoportba. A felhasználók, akinek a Department attri bútum értéke megváltozik (vagy akiket töröltek a címtárból) automatikusan törlődnek a csoportból. Az eDirectory 8.7.3-ban dinamikus csoportjai nem felügyelhetők ConsoleOne-on keresztül. Használjuk az LDAP parancsot ezen csoportok felügyeletéhez. A dinamikus csoportok leghasznosabb tulajdonságai a dgIdentity és a memberQueryURL.

III.2.5 Szerverek és „Szerver”-objektumok A szervereken (egészen pontosan a „NetWare-alapprotokollok szerint működő fájlszervereken”) tárolódik fizikailag az eDirectory-adatbázis (ill. annak részei), közönséges adatfájlokban. Minden olyan szervernek, amelyhez régebbi típusú – a NetWare 2 és 3 ún. binderyjének szolgáltatásait igénylő – kliensek kapcsolódnak,

8/37

eDirectory oktatási segédlet – Dokumentáció de fel kívánjuk venni a címtárfába, tartalmaznia kell az eDirectory egy speciálisan meghatározott területét, az ún. bindery-partíciót. Az eDirectoryban speciális objektumok, ún „Szerver”-objektumok képviselik a fizikai szervereket. Elsődleges szerepük tájékoztató jellegű, a „Szerver”-objektumokhoz megadott objektumjogok semmilyen hatással nincsenek a fájlrendszerrel kapcsolatos hozzáférési jogokra (kivéve a „Supervisor”-jogot, amely korlátlan hozzáférést biztosít a szerver összes kötetéhez).

III.2.6 Kötetek és „Kötet”-objektumok Hasonlóan a szerverekhez, az eDirectoryban speciális „Kötet”-objektumok mutatnak a fájlrendszer egyes köteteire, ám ezen objektumok szerepe is alapvetően tájékoztató jellegű. A „Kötet”-objektumokhoz megadott objektumjogok semmilyen hatással nincsenek a fájlrendszerrel kapcsolatos hozzáférési jogokra, ahhoz a fájlrendszer megfelelő segédprogramjait kell használni.

III.2.7 „Könyvtárleképezés”-objektum Bár fájlok és könyvtárak nem léteznek a címtárfában, létezik egy olyan eDirectory-objektum, amelyik a fájlrendszer egy könyvtárára mutat: a „Könyvtárleképezés”-objektum. Hagyományosan a felhasználók bejelentkezési parancssorozataiban található meghajtó-hozzárendelési parancsai közvetlenül egy könyvtárra mutattak, és a könyvtár megváltoztatásakor át kellett írni az összes parancssorozatot. A „Könyvtárleképezés”-objektumot használva hasonló esetben elegendő az objektum egyetlen tulajdonságát átírni.

III.2.8 Külső referenciák A külső referencia objektum lényegében csak egy jelző, amely információt tárol egy objektumról, amely nincs a szerveren lévő partíción. Az olyan szerverek, amelyek alárendelt referencia típusú replikákat tartalmaznak, és nem rendelkeznek az adott partíció replikáival, vagy egyáltalán nem tartalmaznak replikát, külső referencia objektumokat azért tartalmazhatnak. Egy külső referencia objektum egy, az eDirectory fában levő valódi objektumot reprezentál. Nem az objektum, illetve az objektum attribútumainak másolata. Mielőtt megvizsgálnák a külső hivatkozás létrehozásának, módosításának és törlésének feltételeit, meg kell ismernünk a külső hivatkozás, és az általa reprezentált objektum közötti különbséget.

IV. Az eDirectory biztonsági rendszere Az eDirectory-biztonsága kritikus fontosságú része a hálózatnak. Ezen keresztül engedélyezzük a felhaszná lóknak az eDirectory-erőforrásokhoz való hozzáférést, ugyanakkor akadályozzuk meg a jogosulatlan hozzáféréseket. Mivel a címtár a legfontosabb eszköz a hálózati erőforrások hozzáférésének vezérlésére, az eDirectorybiztonság a legfontosabb módszere a hálózati erőforrások vezérlésének. Az eDirectory biztonsági rendszere szabályozza az eDirectory-objektumokhoz és tulajdonságaikhoz való hozzáférést: azt, hogy ki mit tehet az eDirectoryban tárolt adatokkal.

IV.1. Objektumok jogosultjai Egy objektum jogosultja egy másik eDirectory-objektum, amely kezelheti az adott objektumot, valamint hozzá férhet vagy megváltoztathatja az objektum tulajdonságaiban tárolt adatokat. A jogosultak és jogaik az objektumok ún. „Object Trustees (ACL)”-tulajdonságában tárolódnak, az alábbi ábrán látható módon. A felhasználók csoportjait jelképező objektumok a jogokat egyszerre megadják minden felhasználónak, aki a tagjuk. Az eDirectory-biztonság egyszerűbben alakítható ki és felügyelhető, ha a jogokat olyan objektumoknak – pl. „Csoport”-objektumok vagy konténerobjektumoknak – adjuk, amelyek automatikusan továbbadják ezeket a jogokat több felhasználónak.

9/37


IV.1.1 A [Root] jogosult A NetWare telepítésekor létrejövő [Root] objektum az eDirectory-címtárfa legmagasabb szintje. Alapértelmezés szerint, minden felhasználó, aki sikeresen bejelentkezett, biztonságilag egyenlővé válik a [Root]-tal, vagyis a [Root]-nak adott jogok megilletik. Amennyiben a [Root] egy másik eDirectory-objektum jogosultjává válik, minden megkapott jog öröklődik a fa összes bejelentkezett felhasználójára. A legtöbb szervezetnél nem cél, hogy az eDirectory-címtárfa objektumai a szervezet minden felhasználójának rendelkezésére álljanak. Az eDirectory-erőforrások és -szolgáltatások védelme érdekében kerüljük a [Root]-nak való jogkiosztást.

IV.1.2 A [Public] jogosult A [Public] egy speciális „virtuális” eDirectory-objektum, lényegében egy, az egész címtárra kiterjedő „Csoport”objektum. A NetWare telepítésekor a [Public] a [Root] jogosultjává válik, és jogokat kap a teljes eDirectory-cím tárfa összes objektumának böngészésére. A fa összes eDirectory-objektuma biztonságilag egyenlő a [Public]kal. Ez a hozzárendelés biztosítja, hogy a felhasználók láthatják bejelentkezés előtt is az eDirectory-címtárfa bizonyos objektumait. Minden, a [Public]-nak megadott jogot a fa összes objektuma megkap. Éppen ezért a [Public] jogainak megnövelése a fa összes felhasználójának jogait megnöveli. Az előzőhöz képest a különbség, hogy ezek a jogok akkor is érvényesek, ha a felhasználók nem jelentkeztek be szabályosan a hálózatra. Éppen ezért a [Public] alapértelmezésű jogain a lehető legkevesebbet változtassuk.

IV.2. Objektumjogok Az objektumjogok az objektum jogosultjának megadott jogok. Szabályozzák, hogy

• mit tehet a jogosult az objektummal (például megtekintheti, átnevezheti vagy törölheti); • az objektumhoz – de nem az objektum tulajdonságértékeihez – való hozzáférést. jog

leírás

Supervisor (S)

Megad minden hozzáférési jogot. A Supervisor jog birtokában az objektum összes tulajdonságjogát is megadja.

Browse (B)

Engedélyezi, hogy egy objektum lássa az adott objektumot az eDirectory-címtárfában.

Create (C)

Engedélyezi, hogy egy objektum más objektumokat hozhasson létre az adott objektum alatt. Ez a jog értelemszerűen csak konténerobjektumoknál használható.

Delete (D)

Engedélyezi az objektum törlését a címtárfából.

Rename (R)

Engedélyezi az objektum nevének megváltoztatását.

Inheritable (I)

Engedélyezi a konténerben lévő objektumok számára a kiosztott objektumjogok továbböröklődését az alsóbb szintekre. Ez a jog alapértelmezés szerint meg van adva, az öröklődést biztosítandó. Megvonásával a jogok kizárólag a konténerobjektumra fognak vonatkozni, nem öröklődnek tovább. Ez a jog értelemszerűen csak konténerobjektumoknál használható. 1. táblázat: Objektumjogok

IV.3. Tulajdonságjogok A tulajdonságjogok

• szabályozzák az eDirectory-objektumok tulajdonságaihoz való hozzáférést (megtekintésüket, módosításukat stb.)

• szabályozzák, hogy a felhasználó milyen módon használhatja az eDirectory-objektum által reprezentált hálózati erőforrást. Például ahhoz, hogy egy felhasználó használhassa a „Könyvtárleképezés”objektumot, Read tulajdonságjoggal kell rendelkeznie annak Path tulajdonságához. Egy objektum jogosultja rendelkezhet az eDirectory-objektum összes tulajdonsága, illetve egyes, külön megadott tulajdonságai feletti jogokkal.

10/37


jog

leírás

Supervisor (S)

Megad minden hozzáférési jogot az objektum tulajdonságaihoz.

Compare (C)

Lehetővé teszi a tulajdonság értékének tetszés szerinti értékkel való összehasonlítását, eredményül True vagy False értéket visszaadva. A tulajdonság értéke nem tekinthető meg. Read jog megadása esetén a Compare jog is automatikusan megadódik.

Read (R)

Engedélyezi a tulajdonság értékének megjelenítését.

Write (W)

Engedélyezi az objektum tulajdonságértékének módosítását, beírását és törlését.

Add/Remove Self (A)

Engedélyezi az objektumjogosult számára a tulajdonságérték felvételébe saját magát. Write jog megadása esetén az Add/Remove Self jog is automatikusan megadódik

Inheritable (I)

Engedélyezi egy konténer esetében a tulajdonságjogok továbböröklését a konténerben található objektumokra is. E tulajdonság nélkül a tulajdonságjogok kizárólag a konténerobjektum tulajdonságaira vonatkoznak. Ez a jog alapértelmezés szerint be van kapcsolva az All Properties opció esetén és ki van kapcsolva a Selected Properties opció esetén. Ez a jog csak konténerobjektumok esetén használható. 2. táblázat: Tulajdonságjogok

IV.4. Az Összes tulajdonság és a Kiválasztott tulajdonság közötti különbségek A tulajdonságjogok kétféleképpen oszthatók ki:

• Az All Properties (összes tulajdonság) opcióval. Az All Properties opciót használva a tulajdonságjogok az összes tulajdonságra egyidejűleg adhatók meg: egy Read jog tehát az összes tulajdonságok értékeinek megtekintését engedélyezi.

• A Selected Properties (kiválasztott tulajdonságok) opcióval. A Selected Properties opcióval a tulajdonságjogok külön-külön adhatók meg minden egyes tulajdonsághoz. Ennek akkor van a legtöbb értelme, ha csak néhány tulajdonsághoz kell hozzáférni. Jellemzően a Selected Properties opciót akkor használjuk, ha a felhasználónak gyakran kell módosítania más objektumok tulajdonságait. Például egy titkárnő számára engedélyezhetjük, hogy kizárólag más felhasználók címét és telefonszámát módosíthassa. A Selected Properties opcióval megadott tulajdonságjogok felülírják az All Properties opcióval megadottakat. Ez igen hatékony felügyeletet tesz lehetővé. Egy konténerobjektum jogosultjainak megadható az Inheritable tulajdonságjog. Ez a jog alapértelmezés szerint be van kapcsolva az All Properties opció esetén és ki van kapcsolva a Selected Properties opció esetén.

IV.5. Az eDirectory-objektumok jogainak megállapítása Az eDirectory – a fájlrendszerhez hasonlóan – engedi a jogok öröklődését. Az öröklődés révén minimális mértékben kell egyedileg kiosztani jogokat, így egyszerűsödik a hálózat felügyelete. Mivel az eDirectory hierar chikus szerkezet, a jogok fentről lefelé, a konténerektől az alkonténerek felé terjednek tovább. Megjegyzés: A C jog azért nem folyik tovább az FS1 objektumra, mert a „Create”-jognak csak konténerobjektumok esetén van értelme, az FS1 pedig levélobjektum. Mind az objektumjogok, mind a tulajdonságjogok örökölhetők, a tulajdonságjogok esetén azonban az Inheritable (örökölhető) jogot külön kell megadnunk az egyes tulajdonságokhoz.

IV.5.1 Új jogosultság-kirendelések A magasabb szinten adott objektumjogok felülbírálhatók egy alacsonyabb szinten megadott explicit jogosultság-kirendeléssel.

11/37

eDirectory oktatási segédlet – Dokumentáció Új jogosultság-kirendelések különösen az All Properties opcióval megadott tulajdonságjogok esetében hasznosak, mivel All Properties opcióval megadott tulajdonságjogok, az Inheritable tulajdonságjog alapértel mezés szerint beállítódik. A Selected Properties opcióval megadott tulajdonságjogok esetében ez nincs így, ott külön kell megadni az Inheritable tulajdonságjogot. Ha meg akarjuk akadályozni egy objektum tulajdonságainak továbböröklődését, töröljük ki az Inheritable jogot. A Selected Properties opcióval megadott tulajdonságjogok felülírják az All Properties opcióval megadott tulajdonságjogokat.

IV.5.2 Az örökölt jogok letiltása örököltjog-szűrővel (IRF-fel) IRF-fel letiltható mind az objektumjogok, mind a tulajdonságjogok öröklődése; ez utóbbi esetében az All Properties és a Selected Properties opcióval megadottak egyaránt. Az IRF nem tiltja le az adott objektumhoz közvetlenül megadott jogokat, kizárólag azokat, amelyek a fa magasabb szintjeiről öröklődtek lefelé. Egy felhasználó esetében az új jogosultság-kirendelés használata célszerűbb, míg az összes felhasználóra vonatkozó korlátozás esetén az IRF-é. A Supervisor objektumjog letiltható IRF-fel, így a fa felügyelete vertiká lisan is szabályozható.

IV.5.3 A hatályos jogok kiszámítása Az eDirectory-biztonság felügyeletének részeként meg kell tudnunk állapítani az objektumok más objektumokra vonatkozó hatályos jogait. A felhasználó hatályos jogai az alábbiakból tevődnek össze:

• Explicite kirendelt jogok a „Felhasználó”-objektumhoz • „Csoport”- és „Szervezeti szerep”-objektumokon keresztül kapott jogok • Biztonsági egyenlőségek • A felhasználó konténerétől öröklött jogok (a „Felhasználó”-objektum biztonsága egyenlő az őt tartalmazó konténerrel)

• [Root] jogok • [Public] jogok • A magasabb szintről öröklött jogok • az IRF-ekkel megvont jogok (mínusz)

IV.5.4 Kapcsolat a fájlrendszerrel A szerver minden egyes fájljához és könyvtárához nem tartozik objektum az eDirectoryban. A fájlrendszer jogait a fájlrendszerre vonatkozólag „Supervisor”-jogkörrel rendelkező személy – aki kisebb hálózatoknál gyakran ugyanaz, aki a címtárfáért felelős – szabályozza.

IV.5.5 A fájlrendszer biztonsága Az eDirectory igen korlátozott szerepet játszik a fájlrendszer biztonságában: kizárólag a „Szerver”- és „Kötet”objektumokhoz adhatók jogok. A fájlokkal és könyvtárakkal kapcsolatos hozzáférési jogok ténylegesen azon szerver könyvtárbejegyzés-táblájában (DET) található, amelyen a fájl fizikailag található.

V. Az eDirectory elnevezési szabályai Az eDirectory szerkezetéhez igen szorosan hozzátartoznak az elnevezések: az objektumok elnevezése definiálja az objektumokat és az egymással való kapcsolatukat a címtárfában. Ezenfelül az objektumok keresése is a nevük alapján történik. Az átgondoltan kialakított nevek sokat javíthatnak a keresések teljesítményén, különösen, ha a rendszer további címtáralapú alkalmazásokkal bővül. Az alábbiakban igen röviden áttekintjük az eDirectory-nek az objektumok elnevezésére és kikeresésére szolgáló módszereit. Végezetül – példákkal illusztrálva – ismertetjük egy névszabvány készítésének módját.

12/37


V.1. Az objektumok elnevezési szabályai Amint azt neve is sugallja, az eDirectory egy címtárszolgáltatás: a hálózati erőforrások adatbázisa, és az erre épülő nyilvántartási, hitelesítési és felügyeleti szolgáltatások összessége. Minden egyes hálózati erőforrásnak van egy saját, egyéni azonosítóval rendelkező bejegyzése a címtáradatbázisban. Az erőforrás ezen egyedi név alapján kérhető, és egyazon hálózat bármelyik NetWare szervere képes összekötni a klienst a kívánt erőforrással. A NetWare-ben használt névrendszer hierarchikus felépítésű. A címtáradatbázis szerkezetét, a használható objektumok típusát, tulajdonságait és kapcsolatait az ún. séma tartalmazza. A NetWare-rel együtt kapott alapszintű séma objektumai nem törölhetők, de egyébként az eDirectory-séma szabadon bővíthető további objektumosztályokkal és tulajdonságokkal.

V.2. Az objektumok névtípusai Minden egyes objektumhoz tartozik egy ún. névattribútum (naming attribute) valamint ennek az értéke. A névattribútum határozza meg, hogy az objektum hogyan viselkedik a címtárfában. Egyes objektumok ún. konténer- (befoglaló) objektumok, mások ún. levélobjektumok. Az alábbi táblázat felsorolja az eDirectory-objektumok lehetséges névattribútum-értékeit: névattribútum

leírás

C

Country (ország) név

L

Locality (helyszín) név

O

Organization (szervezet) név

OU

Organizational unit (szervezeti egység) név

CN

Common name (általános név) 3. táblázat: Objektumok névtípusai

A C, L, O és OU konténerobjektumok típusait jelentik. A CN névtípus egységesen vonatkozik az összes levélobjektumra, függetlenül annak típusától; vagyis a felhasználók, nyomtatók, szerverek stb. névtípusa egységesen CN. Az eDirectory-objektumok neve kétféleképpen adható meg, az ún. teljes megkülönböztetett névvel (Full Distinguished Name) és az ún. relatív megkülönböztetett névvel (Relative Distinguished Name).

V.2.1 Teljes megkülönböztetett név Az objektum teljes megkülönböztetett neve az ún. általános nevéből (common name) és kontextusából (a címtárfában elfoglalt helyéből) áll. Az ábrán látható módon, az EMA szervezetben, a NYC szervezeti egység CORP szervezeti egységében található MJensen „Felhasználó”-objektum megkülönböztetett neve az alábbi:

.CN=MJensen.OU=CORP.OU=NYC.O=EMA Az EMA szervezetben található MJensen „Felhasználó”-objektum megkülönböztetett neve pedig:

.CN=MJensen.O=EMA A megkülönböztetett nevek mindig egy ponttal kezdődnek. A névben található objektumok szintén pontokkal vannak egymástól elválasztva, hasonlóan a DOS elérési útjaiban használt fordított törtvonalhoz. A megkülön böztetett névben az adott objektumtól a [Root]-ig az összes objektum fel van sorolva. Egy objektumot a megkü lönböztetett neve egyértelműen azonosít – két objektumnak nem lehet ugyanaz a megkülönböztetett neve.

V.2.2 Relatív megkülönböztetett név A relatív megkülönböztetett név:

13/37


• Az objektumtól az objektum aktuális kontextusát vagy az eDirectory-címtárfa aktuális helyét repre zentáló konténerig tartó objektumokat sorolja fel

• Nem kezdődik ponttal • A név egyes részei szintén pontokkal vannak elválasztva • Tartalmazhat lezáró pontokat Relatív megkülönböztetett nevek használatakor az eDirectory-nak kell azokat kiegészítenie a teljes megkülönböztetett nevekre. Ez úgy történik, hogy a relatív megkülönböztetett névhez hozzáveszi az aktuális kontextust: relatív megkülönböztetett név + aktuális kontextus = megkülönböztetett név Az alábbi példákban a különböző aktuális kontextus miatt tér el a teljes megkülönböztetett név, még akkor is, ha ugyanazt a relatív megkülönböztetett nevet használjuk. megadott név

aktuális kontextus

megkülönböztetett név

CN=MJensen

O=EMA

.CN=MJensen.O=EMA

CN=MJensen

OU=CORP.OU=NYC.O=EMA

.CN=MJensen.OU=CORP.OU=NYC.O=EMA

4. táblázat: A teljessé kiegészített relatív megkülönböztetett nevek Az általános név is relatív megkülönböztetett név.

V.2.3 Lezáró pontok Minden egyes lezáró pont a névben azt jelenti, hogy az eDirectory egy objektumnevet levág az aktuális kontextus bal oldaláról. Például: Legyen OU=ACCT.OU=RIO.O=EMA az aktuális kontextus. Amennyiben meg akarjuk változtatni a kontextust a RIO konténerben lévő ENGR konténerre, akkor a következő CX parancsot és relatív megkülönböztetett nevet adjuk ki, egy ponttal a végén:

CX OU=ENGR. Az eDirectory levág az aktuális kontextus bal oldaláról egy nevet és hozzáveszi a relatív megkülönböztetett nevet. Ez az alábbi teljesen megkülönböztetett nevet eredményezi:

.CN=Admin.OU=ENGR.OU=RIO.O=EMA Ha a kontextust meg kívántjuk változtatni az OU=ENGR.OU=RIO.O=EMA-ról az EMA konténerben lévő TOK konténerre, akkor kiadhatjuk az alábbi CX parancsot:

CX OU=TOK.. Mindez hasonlóan működik, mint a DOS CD parancs lezáró pontjai. A lezáró pontok csak a relatív megkülönböz tetett nevek esetében működnek.

V.2.4 Típusos megnevezés Típusos nevek használatakor az attribútumtípusok rövidítéseivel jelezzük a különbséget a különféle konténertípusok és levélobjektumok között az objektum megkülönböztetett vagy relatív megkülönböztetett nevében. Bár ennek használata nem kötelező, az attribútumtípusok használata segíthet csökkenteni a típus nélküli nevek használata esetén előforduló félreértéseket. Íme, egy példa egy típusos névre:

.CN=MJensen.O=EMA

14/37


V.2.5 Típus nélküli megnevezés A típus nélküli nevek nem tartalmazzák az objektumok attribútumtípusait. A .CN=MJensen.OU=CORP.O=EMA objektum típus nélküli megkülönböztetett neve az alábbi:

.MJensen.CORP.EMA Amennyiben nem adunk meg típusos objektumnevet, úgy az eDirectory maga helyettesíti be az egyes objek tumok attribútumtípusait. Amennyiben egy segédprogram helytelen attribútumot helyettesít be, úgy az objektumok nem lesznek azonosíthatók.

VI. Az eDirectory működése, állapotfelmérése Az eDirectory működésének megismeréséhez, annak karbantartásához pontosan ismerni kell az eDirectory felépítését és a használható segédprogramokat Az eDirectory-címtárfa jellemzőinek megállapításához különféle eDirectory-eszközöket használunk. Ezen eszközök többsége a NetWare-csomag része, vagy külső fejlesztőktől tölthető le/vásárolható meg. Ilyen eszközök például a DSRepair, a DSTrace, a ConsoleOne és az NLIST, valamint a későbbiekben ismertetett iMonitor. Ezek a programok használhatók a címtár „egészségi állapotának” (health-check) vizsgálatára is, amely az alábbiak ellenőrzéséből tevődik össze:

• Partíciószinkronizáció • Időszinkronizáció • Partíciófolytonosság • A SYS: köteten rendelkezésére álló hely • A szerverek közötti szinkronizáció • Ismeretlen objektumok • Háttérfolyamatok • Egyedi fanevek • Szám_Szám-objektumok (pl. 1_6) • Az eDirectory hangolható paraméterei

VI.1. Partíciószinkronizáció Az eDirectory egy ún. lazán csatolt konzisztens adatbázis. A konzisztencia érdekében az eDirectory egyes részeinek meghatározott időközönként szinkronizálniuk kell. Ez az ütemezett szinkronizáció – az ún. „eDirectory-szívverés” (eDirectory heartbeat) – alapértelmezés szerint 60 percenként történik a NetWare szervereken. Ha a szerverek nem képesek tökéletesen leszinkronizálni az adataikat, akkor folyamatosan ún. „utolérő” (catch up) módba kerülnek, ami nemcsak lerontja a teljesítményt, hanem inkonzisztenciát jelent a replikák között. Éppen ezért a szinkronizációs folyamat helyes működése minden eDirectory-címtárfa egyik legfontosabb feladata.

VI.2. Időszinkronizáció Az eDirectory időszinkronizáció ellenőrzése azért fontos, mert az eDirectory időbélyegek használatával követi nyomon, hogy a fizikailag eltérő helyeken lezajló események (objektumok létrehozása és törlése, tulajdonságok módosítása) milyen sorrendben is történtek. A TIMESYNC.NLM akkor tekinti a helyi órát szinkronban lévőnek, ha az nem több, mint 2 másodperccel (ez az érték állítható) tér el az aktuális hálózati időtől.

VI.3. DS-verziók A Novell rendszeresen frissíti az eDirectory-kezelő modulokat (NLM-eket). Ezek a frissítések a http://support.novell.com webhelyről tölthetők le. A frissítések telepítése a központi rendszergazda feladata.

15/37


VI.4. Partíciófolytonosság Az eDirectory partíciófolytonossága azt jelenti, hogy az összes olyan szerver, amelyen egy adott partíció (a címtárfa egy logikai darabja) replikája (a partíció fizikai másolata) található, képes legyen résztvenni a partíció műveletekben és helyesen szinkronizálni a partíció adatait. E szerverek mindegyikének ugyanazzal a „nézettel” (view) kell rendelkeznie a partícióról. A partíciófolytonosság ellenőrzése során megvizsgálunk minden egyes szervert, amelyen egy partíció replikája található, és ellenőrizzük, hogy a replikagyűrű (replikalista) összes szerverén ugyanaz az információ található. A partíciófolytonosság ellenőrzése során megvizsgáljuk a partíciók állapotát is. Ha egy partíció nem ON állapotban van, akkor valamilyen korábbi partícióművelet még nem ért véget.

VI.5. Szabad hely a SYS köteten Az eDirectory helyes működéséhez elegendő szabad területnek kell rendelkezésre állnia az egyes szerverek SYS: kötetén. Ha betelik a SYS: kötet, leállhat a Transition Tracking System (TTS), és ennek következtében lezáródik a szerver eDirectory-adatbázisa. Ökölszabályként sose engedjük a SYS: kötetet 75 százaléknál jobban megtelni.

VI.6. A szerverek közötti kommunikáció Az eDirectory-címtárfa összes szerverének kommunikálnia kell az összes többivel. A nem megbízható szerverek közötti kommunikáció eDirectory-szinkronizációs és időszinkronizációs hibákat eredményez. A szerverek közötti kommunikációs hibáknak számos különféle oka lehet:

• nem megbízható és nem eléggé stabil infrastruktúra, • gondok a WAN-kapcsolatokkal, • valamint instabil szerverhardver.

VI.7. Ismeretlen eDirectory-objektumok Ha egy eDirectory-objektum valamelyik kötelező tulajdonsága hiányzik, az eDirectory képtelen lesz azonosítani az objektumot (annak típusát) és képtelen lesz frissíteni az objektum adatait. Ilyenkor az eDirectory-objektum ún. ismeretlen objektummá válik. Ennek több oka is lehet:

• NetWare 3.x-ről való frissítés után • Ha egy kötelező tulajdonságot törlünk • Ha az eDirectory-adatbázis megsérült Mivel az eDirectory általában kideríti az ismeretlen objektumok típusát, ezek a hibák általában nem kritikusak. Ha viszont hosszabb távon sem sikerül feloldani az ismeretlen objektumokat, az általában szinkronizációs problémára utal. Az ismeretlen objektumok ikonja egy sárga kör alakú háttéren lévő kérdőjel. Amennyiben ismeretlen rendszergazdát.

objektummal

találkozik,

haladéktalanul

értesítse

a

központi

Ismeretlen objektumok felfedezésekor először is fel kell jegyezni az eseményt, de időt kell adni a rendszernek a feloldásukhoz. Ezek az objektumok önmagukban nem okoznak kárt az eDirectory-adatbázisban (az adatbázis mérete valamelyest megnőhet). Ez csak akkor jelent problémát, ha éppen kritikusan alacsony a SYS: köteten rendelkezésre álló terület. Statikus (alig változó) címtárfa esetén a Novell Consulting javaslata az ismeretlen objektum meghagyása a következő karbantartásig. A rendszergazdának magának kell eldöntenie, hogy szükség van-e ezekre az objektumokra. Gyakran igen nehéz kideríteni egy ismeretlen objektum eredetét; sokszor az egyetlen utalás az objektum neve.

16/37


Megjegyzés: Egyes objektumok azért látszanak ismeretlennek, mert a felügyeleti eszközből hiányzik a kezelésükhöz szükséges modul. Ebben az esetben csak a felügyeleti eszköz számára ismeretlen az objektum (az eDirectory-adatbázis számára nem). Ezeket az ismeretlen objektumokat másféle ikonnal (fehér négyzetben lévő kérdőjel) jelzi a rendszer.

VI.8. Háttérfolyamatok Az eDirectory normális működése során is fellépnek bizonyos hibák a környezet állapotának és változásának megfelelően. Ezek a – normálisnak tekinthető – eDirectory-hibák pontosan azt a célt szolgálják, hogy az eDirectory összes háttérfolyamata (pl. a bejelentkezés és a replikaszinkronizáció) sikeresen végbemenjen. Például DS Agent (DSA) hiba jön létre, ha a felhasználó rossz kontextussal próbál bejelentkezni. Ütközési hiba pedig akkor jön létre, ha az eDirectory elromlott WAN-kapcsolaton keresztül próbál replikálni. Ebben az esetben egy második szerver veszi át a feladatot, de a WAN-kapcsolat helyreállása után az eDirectory újra megpróbál replikálni, és ebből ütközés lesz, amelynek hatására az első szerver figyelmen kívül hagyja a replikációs kérést. Az ilyen és ehhez hasonló hibák teljesen normális jelenségek, pontosan az a céljuk, hogy az eDirectory rugalmasan alkalmazkodjon a változó környezetekhez is.

VI.9. Egyedi faelnevezés Nagyon fontos, hogy amennyiben több címtárfa található a hálózaton, mindegyik neve különböző legyen. Ha nem így van, az eDirectory rendkívüli instabilitásához vezethet – ráadásul ez egy igen nehezen felismerhető hibajelenség. A kettős fanevek előfordulása katasztrofális eredményekkel járhat. A legtöbb esetben mindkét címtárfa súlyosan károsodik. A kettős fanevekre általában a –672-es hibák tömeges megjelenése (ez a hiba az inkon zisztens replikagyűrűket jelzi) és a pontatlan eDirectory-öröklődési számítások utalnak. Ha nem szüntetjük meg nagyon gyorsan a helyzetet, az eDirectory teljesen összeomolhat.

VI.10. Szám_szám objektumok A szám_szám objektumokat gyakran szokás „átnevezés” vagy „névütközés” néven is emlegetni. Ez abból származik, ha két azonos nevű objektum van ugyanabban a konténerben, de eltérő replikákban és eltérő időbé lyegekkel. Mivel ez ellentmond az eDirectory sémadefiníciós szabályainak, az eDirectory át fogja nevezni az objektumok egyikét a szám_szám szabály szerint (pl. 1_2). Ilyen átnevezett objektummal tipikusan olyan LANvagy WAN-környezetekben találkozhatunk, ahol a kommunikáció nem stabil, illetve ha egy szalagos eDirectorymentést állítunk vissza, vagy a hardver helytelen frissítése után. Amennyiben szám_szám objektummal találkozik, értesítse a központi rendszergazdát.

VII. Segédprogramok VII.1. DSBrowse NetWare-en a DSBrowse segédprogram használatával tallózhatjuk a szerveren található, helyi eDirectory adatbázist. Indításakor 5 menüpont áll rendelkezésre:

• Tree browse – Használatával tallózhatjuk a címtárat fa nézetből • Schema browse – A menüpont lehetővé teszi a sémapartíció böngészését attribútumok és osztályok szerint.

• Partition browse – A címtár tallózható, eDirectory – partíciók szerint • Object search – Adott objektum keresése megadott feltételek szerint • Exit – Kilépés a programból A program használata során az alábbi funkcióbillentyűk használhatók:

• F1 – Segítség kérése • F3 – Adott objektum adatainak és attribútumainak megtekintése

17/37


• F7 – eDirectory hibakódok listázása • ALT-F10 – Kilépés a programból • ESC – Visszalépés az előző szintre • ENTER – Előrelépés egy szintet A program elsődleges funkciója, hogy kiszolgálónként tudjuk vizsgálni a címtár tartalmát, mivel a kliensoldali programoknál nem adható meg, hogy melyik replikából olvassa ki a kívánt információt.

VII.2. DSRepair A DSRepair segédprogram szolgál az eDirectory állapotának figyelésére, a hibák felderítésére és kijavítására az egyes szervereken. Jelen dokumentum a program legfontosabb opcióit ismerteti. A Novell elkészítette a DSRepair segédprogramot minden egyes, az eDirectory által kezelt platformhoz. A DSRepair számos funkciót kínál, de ezek három fő kategóriába sorolhatók:

• Unattended Full Repair (felügyelet nélküli teljes javítás) • eDirectory Monitor Operations (eDirectory-figyelési műveletek) • eDirectoryRepair Operations (eDirectory-javítási műveletek) Az Unattended Full Repair (UFR) platformtól függetlenül ugyanazokat a műveleteket végzi. A másik két kategória műveletei bár hasonlóak, kissé eltérnek az egyes platformokon.

VII.2.1 Unattended Full Repair (UFR) Az UFR alighanem a DSRepair leggyakrabban használt funkciója, bár az eDirectory által újabban kezelt óriási méretű adatbázisok terjedésével ez megváltozhat. Ez az opció egy adott szerver eDirectory-adatbázisfájljaiban megkeresi és kijavítja a legtöbb, nem kritikus eDirectory-hibát. Az UFR az alábbi módon indítható a különböző platformokon:

• NetWare: válasszuk ki a DSRepair főmenüjéből az Unattended Full Repair pontot. • NT: kattintsunk a Repairre és válasszuk ki az Unattended Full Repair pontot • Solaris/Linux: ndsrepair -U Az UFR nyolc elsődleges műveletet hajt végre minden egyes futtatásakor; ezek egyikéhez sincsen szükség a rendszergazda közreműködésére. E műveleteket az 1. táblázat foglalja össze. Bizonyos műveletek elvégzése alatt a helyi adatbázis lezáródik. Ez azt jelenti, hogy az új felhasználók nem képesek bejelentkezni (hitelesíteni) erre a szerverre, bár a már bejelentkezett felhasználók továbbra is hozzáférhetnek a szerver többi (nem eDirectory) erőforrásához. Az UFR ideiglenes másolatot készít a helyi adatbázisfájlokról, és azokon végzi a javítási műveleteket. Ez azt biztosítja, hogy komoly problémák esetén az eredeti fájlok változatlanul rendelke zésre álljanak.

18/37


művelet

leírás

Database Structure and Index Check

Megvizsgálja az adatbázisrekordok és indexek struktúráját és formátumát. Ez biztosítja, hogy ne legyen strukturális hiba az eDirectory-környezetben adatbázisszinten.

Rebuild the Entire Database

Ez a művelet szolgál a strukturális és indexellenőrzések során feltárt hibák kijavítására. Helyreállítja a megfelelő adatstruktúrákat és újra létrehozza az eDirectory adat- és indexfájljait.

Perform Tree Structure Check

Megvizsgálja az adatbázisrekordokat és ellenőrzi, hogy minden gyerekrekordhoz érvényes szülő tartozzon. Ez javítja az adatbázis konzisztenciáját. Az érvénytelen rekordokokat megjelöli, hogy később, az eDirectory replikaszinkronizációs folyamata helyre tudja állítani őket a partíció egy másik replikájából.

Repair All Local Replicas

Ez a művelet helyreállítja az eDirectory adatbázis inkonzisztenciáit: ellenőriz minden egyes objektumot és attribútumot, hogy megfelel-e a sémadefiníciónak. Szintén ellenőrzi az összes belső adatstruktúra formátumát. A Repair All Local Replicas továbbá feloldja a fastruktúra ellenőrzése során talált inkonzisztenciákat is: törli az érvénytelen rekordokat az adatbázisból. Ennek eredményeképpen az érvénytelen rekord összes gyerekrekordja „árva” (orphan) lesz. Ezek az „árva” rekordok nem vesznek el, bár a folyamat igen nagy számú hibát képes generálni az adatbázis újraépítése közben. Ettől ne ijedjünk meg, ez a jelenség normális és az árva objektumok automatikusan a helyükre kerülnek a replikaszinkronizáció során.

Check Local References

A helyi referenciák olyan mutatók, amelyek az adott szerver eDirectory-adatbázisának más objektumaira mutatnak. A Check Local References pont átvizsgálja a belső adatbázis-mutatókat, hogy valóban a megfelelő eDirectory-objektumokra mutatnak-e. Amennyiben érvénytelen hivatkozásokat talál a művelet, naplózza a hibát a DSREPAIR.LOG fájlban.

Repair Network Addresses

Ez a művelet ellenőrzi, hogy a szerverek az eDirectory-ban tárolt hálózati címei megegyeznek-e a helyi SAP vagy SLP táblázatokban található címekkel – vagyis hogy az eDirectory továbbra is pontos információval rendelkezik-e. Amennyiben eltérés található, úgy a művelet frissíti az eDirectory-t a helyes adatokkal. E fázis során az eDirectory-fájlok nincsenek lezárva.

Validate Stream Syntax Files

Az ún. streamfájlok, mint például a bejelentkezési parancssorozatok, az eDirectoryadatbázis speciális területén tárolódnak. Ez a művelet ellenőrzi, hogy az egyes streamfájlok érvényes eDirectory-objektumokhoz vannak-e rendelve. Ha nem, a fájlok törlődnek.

Validate Mail Alapértelemezés szerint az eDirectory a NetWare-szerverek SYS:Mail könyvtárában hoz Directories létre postakönyvtárakat, hogy kiszolgálja a bindery-felhasználókat. A bindery(Csak NetWare-en) felhasználók bejelentkezési parancsssorozata a postakönyvtárakban tárolódik. Ez a művelet ellenőrzi, hogy a postakönyvtárak érvényes eDirectory „Felhasználó”objektumhoz vannak-e rendelve. Ha nem, a postakönyvtár törlődik. Check Volume Objects And Trustees (Csak NetWare-en)

Ez a művelet először ellenőrzi, hogy a NetWare-szerver minden egyes kötete hozzá van-e rendelve egy „Kötet”-objektumhoz az eDirectory-ban. Ha nem, végigkeresi a szerver kontextusát, hogy létezik-e egyáltalán „Kötet”-objektum. Ha nem talál „Kötet”objektumot, akkor létrehoz egyet. A kötetinformáció érvényesítése után a művelet ellenőrzi a jogosultak azonosítóit. Az eDirectory minden egyes objektumának van egy egyedi, ún. jogosultazonosítója (trustee ID). Ezen azonosító segítségével kezeli az eDirectory a más objektumokra – például NetWare-kötetekre – vonatkozó jogokat a címtárfában. A művelet ellenőrzi, hogy a kötetlista minden egyes jogosultazonosítója érvényes eDirectory-objektumhoz tartozik. Ha nem, akkor a jogosultazonosító törlődik a kötetlistából. E fázis során az eDirectoryfájlok nincsenek lezárva. 5. táblázat: Az Unattended Full Repair által elvégzett műveletek

Megadható, hogy az előző tételek közül melyeket ellenőrizze vagy javítsa a Repair Local DS Database (helyi DS adatbázis javítása) opció, amelyet a későbbiekben, az „Advanced Options Menu” résznél részletesen tárgyalunk. A naplófájl rögzít minden tevékenységet az UFR művelet futása alatt. A javítások befejeztével a naplófájl megjelenik a képernyőn, tartalmából kiolvashatóak a változásokat és az adatbázis jelenlegi állapota. A felügyelet nélküli javítás parancssorból is elindítható, ha a DSREPAIR-t a -U opcióval futtatjuk.

19/37


VII.2.2 Report Synchronization Status A Report Synchronization Status (szinkronizációs állapot megjelenítése) opció elkezdi a replikaszinkronizációs folyamatot a szerveren tárolt összes partícióra. Ha ugyanezt a műveletet csak meghatározott partíciókra kívánjuk elvégezni, válasszuk ki a Replica and Partition Operations pontot az Advanced Options menüből. A Replica Synchronization művelet kapcsolatba lép a szerveren tárolt minden egyes replika listájának minden egyes szerverével. Saját magával nem próbál szinkronizálni a szerver, így a szerver saját replikájának állapota mindig „host” értéket tartalmaz. E művelettel gyorsan és egyszerű módon megállapítható, hogy a partíció és és szerverek helyesen kommunikálnak és szinkronizálnak-e. A művelet a naplófájlban rögzíti a tevékenységeit és minden észlelt hibát. A naplófájlban minden egyes partíció saját szekciót kap, amely a partíció nevével kezdődik, és az „All servers synchronized up to time” üzenettel ér véget – ez a partíció master replikája szerinti időbélyeg, nem pedig a replikagyűrű szinkronban lévő replikáinak valamiféle átlaga. A legfontosabb megjegyzendő dolog e ponttal kapcsolatban, hogy a szinkronizációs állapot kizárólag azon szerverek esetében látható, amelyek a helyi adatbázis szerint replikákat tartalmaznak. Az szinkronizáció állapota az alábbi módon kérdezhető le a különböző platformokon:

• NetWare: válasszuk ki a DSRepair főmenüjéből a Report Synchronization Status pontot. • NT: kattintsunk a Repairre és válasszuk ki az Report Synchronization Status pontot • Solaris/Linux: ndsrepair -E Az egyes replikabejegyzések mellett az alábbiak egyike látható:

• A legutolsó sikeres szinkronizáció dátuma és időpontja • A legutolsó sikeres szinkronizáció dátuma és időpontja, valamint egy hibakód (pl. –625) és annak leírása, hogy a hiba helyi vagy távoli a kérdéses szerverre vonatkozóan A replikagyűrű szerverek állapotainak összehasonlításával egyszerűen meghatározható, konzisztens-e a gyűrű. Például egy adott partíció replikagyűrűjének minden egyes szervere ugyanannyi replikát kell, hogy jelentsen (függetlenül a replika típusától, beleértve az alárendelt replikákat is).

VII.2.3 Time Synchronization (időszinkronizáció) A Time Synchronization parancs kapcsolatba lép minden, a helyi szerver által ismert szerverrel, és lekérdezi az időszinkronizáció, a címtárszolgáltatás és a szerver állapotadatait. Ez az információ szintén a naplófájlba íródik, táblázatként (ld. a 3. táblázat a naplófájl mezőivel kapcsolatban). A művelet befejeztével a naplófájl megjelenik, így ellenőrizhető az időszinkronizáció állapota, illetve a címtár egyéb adatai. Az időszinkronizáció állapota az alábbi módon kérdezhető le a különböző platformokon:

• NetWare: válasszuk ki a DSRepair főmenüjéből a Time Synchronization pontot. • NT: kattintsunk a Repairre és válasszuk ki az Time Synchronization pontot • Solaris/Linux: ndsrepair -T

20/37


mező

tartalom

Server Name

A kérést kiadó szerver megkülönböztetett neve.

DS.NLM Version

A válaszoló szerveren futó DS-verzió. Ez az információ igen értékes, mint gyorsreferencia a hálózat szerverei által futtatott eDirectory-verziókról.

Replica Depth

A replika mélysége arra utal, hogy milyen mélyen is (milyen messze a [Root] objektumtól) található az eDirectory-címtárfában a válaszoló szerver első replikája. Mindkét szerver tudja, melyik replika van a legmagasabban az eDirectory-címtárfában. Ez az érték a távoli szerver által jelentett érték. A pozitív számok azt jelzik, hány objektum van a [Root] és a legmagasabb replika között (a 0 arra utal, hogy a szerveren megtalálható a [Root] replikája). A -1 azt jelzi, hogy a szerveren nem tárolódnak replikák.

Time Source

E mező neve félrevezető. A mezőben nem az időforrás, hanem a lekérdezett szerver időszerver-típusa látható.

Time is in Sync

Ez a mező jelzi a válaszoló időszerver időszinkronizációs állapotát. A lehetséges értékek a Yes és a No. A megjelenő érték az egyes szerverek szinkronizációs jelzőbitjének állapotára utal. A Yes azt jelenti, hogy a szerver ideje az időszinkronizációs sugáron belülre esik. A No arra utal, hogy a válaszoló szerver vagy nem képes kommunikálni az időforrásával, vagy az ő ideje nincsen összhangban a hálózati idővel.

Time Delta

Ez a mező mutatja az időkülönbséget, ha van, az egyes szerverek időszinkronizációs sugarától. Az időszinkronizációs sugár alapértelmezés szerint 2 másodperc, úgyhogy várhatóan nem fogunk szervereket látni 2 másodpercnél nagyobb különbséggel. Amennyiben az érték nagyobb, úgy a Time is in Sync mező értéke alighanem No. A mezőben maximum 999 perc 59 másodperces eltérés látható. 6. táblázat: A DSREPAIR naplófájl mezői az időszinkronizáció ellenőrzése után

VII.3. eDirectory-javítási műveletek NetWare-en Bár az eDirectory-adatbázis figyelése fontos feladat, nem sok haszonnal jár, ha nem lehet kijavítani a felderített inkonzisztenciákat. A DSREPAIR számos eDirectory-javítási műveletet biztosít. Ezek a javítási műveletek három fő kategóriába oszthatók:

• Adatbázis-javítási műveletek • Partíció- és replikajavítási műveletek • Egyéb javítási műveletek Netware és Windows alatt minden adatbázis-javítási művelet ugyanabból a menüből érhető el a DSRepairben. A műveletek elindításához válasszuk ki az Advanced Options menüt, majd a Repair Local DS Database (ld. alábbi ábra) pontot. Az alábbi táblázat mutatja be e menü javítási műveleteit.

21/37


művelet

leírás

Rebuild Entire Database

Ez a művelet szolgál a strukturális és indexellenőrzések során feltárt hibák kijavítására. Helyreállítja a megfelelő adatstruktúrákat és újra létrehozza az eDirectory adatbázis- és indexfájljait.

Repair All Local Replicas

Ez a művelet helyreállítja az eDirectory adatbázis inkonzisztenciáit: ellenőriz minden egyes objektumot és attribútumot, hogy megfelel-e a sémadefiníciónak. Szintén ellenőrzi az összes belső adatstruktúra formátumát. A Repair All Local Replicas továbbá feloldja a fastruktúra ellenőrzése során talált inkonzisztenciáit is: törli az érvénytelen rekordokat az adatbázisból. Ennek eredményeképpen az érvénytelen rekord összes gyerekrekordja „árva” (orphan) lesz. Ezek az „árva” rekordok nem vesznek el, bár a folyamat igen nagy számú hibát képes generálni az adatbázis újraépítése közben. Ettől ne ijedjünk meg, ez a jelenség normális és az árva objektumok automatikusan a helyükre kerülnek a replikaszinkronizáció során.

Validate Mail Directories és Stream Syntax Files

E két művelet csupán NetWare-en használatos. Alapértelemezés szerint az eDirectory a NetWare-szerverek SYS:Mail könyvtárában hoz létre postakönyvtárakat, hogy kiszolgálja a bindery-felhasználókat. A bindery-felhasználók bejelentkezési parancssorozata a postakönyvtárakban tárolódik. Ez a művelet ellenőrzi, hogy a postakönyvtárak érvényes eDirectory „Felhasználó”-objektumhoz vannak-e rendelve. Ha nem, a postakönyvtár törlődik. Az ún. streamfájlok, mint például a bejelentkezési parancssorozatok, az eDirectoryadatbázis speciális területén tárolódnak. Ez a művelet ellenőrzi, hogy az egyes streamfájlok érvényes eDirectory-objektumokhoz vannak-e rendelve. Ha nem a fájlok törlődnek.

Check Local References

A helyi referenciák olyan mutatók, amelyek az adott szerver eDirectory-adatbázisának más objektumaira mutatnak. A Check Local References pont átvizsgálja a belső adatbázis-mutatókat, hogy valóban a megfelelő eDirectory-objektumokra mutatnak-e. Amennyiben érvénytelen hivatkozásokat talál a művelet, naplózza a a hibát a DSREPAIR.LOG fájlban.

Reclaim Database Free Space

Ez a művelet kikeresi a nem használt adatbázisrekordokat és törli őket a hely felszabadítása érdekében.

Rebuild Operational Schema

Ez a művelet újjáépíti az alapséma osztályait és attribútumait (ezekre van szükség az eDirectory alapvető funkcionalitásának biztosításához).

7. táblázat: A DSREPAIR adatbázis-javító műveletei NetWare-en

22/37


1. ábra: A DSREPAIR adatbázis-javító műveletei NetWare-en Az adatbázis-javító műveleteken kívül a DSREPAIR egy sor partíció- és replikajavító műveletet is biztosít, amelyek célja, hogy biztosítsák az elosztott eDirectory-környezet helyes működését (ld. 2. ábra). Más szavakkal, míg eddig a helyi adatbázissal foglalkoztunk, most a partícióval, és annak összes, a hálózat különféle szerverein tárolt replikáival.

3. ábra: A DSREPAIR partíció- és replikajavító műveletei NetWare-en Az alábbi táblázat mutatja be a különféle partíció- és replikajavító műveleteket. E műveletek végrehajtásához válasszuk ki az Advanced Options menüt, majd abból a Replica And Partition Operations pontot.

23/37


művelet

leírás

Sync Replica On All Servers

A művelet kapcsolatba lép a kiválasztott partíció replikáit tartalmazó szerverekkel, majd elkezdődik egy szinkronizációs ciklus.

Repair All Replicas

Ez a művelet helyreállítja az eDirectory adatbázis inkonzisztenciáit: ellenőriz minden egyes objektumot és attribútumot, hogy megfelel-e a sémadefiníciónak. Szintén ellenőrzi az összes belső adatstruktúra formátumát.

Repair Selected Replica

Replikajavítást végez kizárólag a kiválasztott replikán.

Repair Ring – Selected Replicas

Replikajavítást végez minden egyes szerveren, amelyik a kiválasztott partíció replikáját tartalmazza.

Repair Ring – All Replicas

Replikagyűrű-javítást végez minden egyes replikagyűrűn, amelynek az adott szerver tagja.

Schedule Immediate Sync

Replikaszinkronizációs ciklust indít minden egyes partícióra, amelynek replikája az adott szerveren tárolódik. Ez hasznos lehet például, ha ki akarjuk kényszeríteni az adatbázis friss változásainak szinkronját.

Designate This Server As New Master Replica

Ha egy adott partíció master replikája elvész hardvermeghibásodás miatt, akkor ezzel a művelettel lehet új mastert kijelölni annak érdekében, hogy a partícióműveletek helyesen működjenek. 8. táblázat: A DSREPAIR partíció- és replikajavító műveletei NetWare-en

Három további művelet áll rendelkezésre az alábbi módon: 1.

Válasszuk ki az Advanced Options menüt, majd abból a Replica and Partition Operations pontot

2.

Válasszuk ki a kívánt replikát, majd a View Replica Ring pontot

3.

Válasszuk ki a kívánt szervert a listából.

E három műveletet az alábbi táblázat írja le részletesen. E műveletek megtalálhatók az eDirectory Managerben is. művelet

leírás

Synchronize the Replica on the Selected Server

Megjeleníti a kiválasztott partíció szerveren tárolt replikájának szinkronizációs állapotát.

Send All Objects To Every Replica in the Ring

Ez a művelet újjáépíti a gyűrű minden egyes replikáját az adott szerveren található replika objektumai alapján. Figyelmeztetés: Minden olyan, más replikákon elvégzett változtatás, amely még nem szinkronizálódott le erre a szerverre, elvész.

Receive All Objects from Master to This Replica

Ez a művelet újjáépíti a helyi replikát a master replikától kapott objektumadatok alapján. Figyelmeztetés: Minden olyan, ezen a replikán elvégzett változtatás, amely még nem szinkronizálódott le a master replikára, elvész. 9. táblázat: A DSREPAIR partíció- és replikajavító műveletei NetWare-en

Végül, négy további, vegyes típusú javítási művelet is található a DSRepair segédprogramban. Ezeket az alábbi táblázat mutatja be. Az itt ismertetett műveletek alkalmazásával az eDirectory-környezet legtöbb, nem katasztrofális jellegű problémája megoldható.

24/37


művelet

hogyan indítható el?

leírás

Repair All Network Addresses

Válasszuk ki az Advanced Options menüt, majd abból a Servers Known To This Database pontot. Válasszuk ki a kívánt szervert a listából.

Ez a művelet ellenőrzi, hogy a szerverek az eDirectoryban tárolt hálózati címei megegyeznek-e a helyi SAP vagy SLP táblázatokban található címekkel – vagyis hogy az eDirectory továbbra is pontos információval rendelkezik-e. Amennyiben eltérés található, úgy a művelet frissíti az eDirectory-t a helyes adatokkal. Ha a művelet nem talál vonatkozó SAP vagy SLP bejegyzést, úgy a DSREPAIR hibát jelez.

Repair Selected Server’s Network Addresses

Válasszuk ki az Advanced Ugyanaz, mint az előbb, de csak a helyi szerveren lévő Options menüt, majd helyi partíció objektumait ellenőrzi a művelet. abból a Servers Known To This Database pontot. Válasszuk ki a kívántt, majd a Repair Selected Server’s Network Addresses pontot.

Check Volume Objects and Trustees

Válasszuk ki az Advanced Options menüt, majd abból Check Volume Objects and Trustees pontot.

A Check Volume Objects and Trustees művelet először ellenőrzi, hogy a NetWare-szerver minden egyes kötete hozzá van-e rendelve egy „Kötet”-objektumhoz az eDirectory-ban. Ha nem, végigkeresi a szerver kontextusát, hogy létezik-e egyáltalán „Kötet”-objektum. Ha nem talál „Kötet”-objektumot, akkor létrehoz egyet. A kötetinformáció érvényesítése után a művelet ellenőrzi a jogosultak azonosítóit. Az eDirectory minden egyes objektumának van egy egyedi, ún. jogosultazonosítója (trustee ID). Ezen azonosító segítségével kezeli az eDirectory a más objektumokra – például NetWarekötetekre – vonatkozó jogokat a címtárfában. A művelet ellenőrzi, hogy a kötetlista minden egyes jogosultazonosítója érvényes eDirectory-objektumhoz tartozik. Ha nem, akkor a jogosultazonosító törlődik a kötetlistából.

Check External References

Válasszuk ki az Advanced Options menüt, majd abból a Check External References pontot.

A külső hivatkozások olyan mutatók, amelyek az adott szerveren nem tárolt partíció eDirectory-objektumaira mutatnak. A Check External References művelet megvizsgál minden egyes ilyen hivatkozást, hogy még mindig érvényes eDirectory-objektumokra mutatnak-e. Szintén ellenőrzi a művelet a helyi adatbázisban található összes ún. obituaryt is. Az obituaryk szolgálnak az adatbázis konzisztenciájának megőrzésére, miközben az eDirectory egy objektummozgatást, törlést vagy átnevezést szinkronizál. Amennyiben egy replika megkísérel a módosított objektumra hivatkozni a régi információ alapján (mert még nem kapta meg az új adatokat), az obituary bejegyzés ezt lehetővé teszi hiba okozása nélkül. Miután minden replika leszinkronizálódott, a Janitor nevű rendszerfolyamat megszünteti az obituaryt. 10. táblázat: A DSREPAIR egyéb műveletei NetWare-en

VII.3.1 A DSREPAIR parancssori kapcsolói NetWare-en A Novell javasolja, hogy a DSRepair egyes műveleteit rendszeresen végezzük el az eDirectory-címtárfa helyes állapotának biztosítása érdekében. Éppen ezért a Novell a DSRepair funkcióinak nagy részét elérhetővé tette parancssori kapcsolókon keresztül is. E kapcsolókkal lehetséges a program időzített, automatikus futtatása, a rendszergazda közreműködése nélkül is. Az alábbi táblázat írja le a különféle kapcsolókat, amelyekkel automatizálhatók a DSRepair legfontosabb feladatai.

25/37


kapcsoló paraméter

leírás

–L

Fájlnév (elérési úttal)

A DSREPAIR naplófájl helyét határozza meg. Amennyiben a naplófájl már létezik, a további bejegyzések hozzáíródnak. Az alapértelmezés a SYS:SYSTEM\DSREPAIR.LOG.

–U

Nincs

UFR-t hajt végre, majd a végén leállítja a programot.

– RC

Nincs

eDirectory dump fájlt készít. Ez a fájl a helyi eDirectory adatbázis egyfajta „pillanatfelvétele”, amely hibakereséshez használható. A dump fájl a SYS:SYSTEM\DSR_DIB könyvtárba kerül.

– RD

Nincs

A helyi adatbázis javítása (Repair Local Database). Az alapértelmezett adatbázisjavítási opciókat hajtja végre: Structure and Index check, Rebuild database, Tree Structure Check, Repair all local replicas, Validate Mail/Stream files és Check local references.

– RN

Nincs

Repair Network Addresses művelet

– RV

Nincs

Perform Volume Object Repair művelet

– RVT

Kötetnév

Perform Volume Object Repair and Trustee Check művelet

–A

Nincs

A DSREPAIR speciális (advanced) módjának bekapcsolása 11. táblázat: A DSREPAIR parancssori kapcsolói

VII.3.2 Speciális opciók VII.3.2.1 Repair Timestamps and Declare a New Epoch (időbélyegek helyreállítása és új korszak indítása) Hogyan indítható el?: 1.

Írjuk be a konzolnál: LOAD DSREPAIR –A

2.

Válasszuk ki az Advanced Options menüt, majd a Replica and Partition Operations pontot

3.

Válasszuk ki a [Root] partíciót

4.

Válasszuk ki a Repair Timestamps and Declare a New Epoch pontot

Ez a pont szolgál az ún. „szintetikus idő” hibaüzenetek megszüntetésére. A szintetikus idő az az állapot, amikor a helyi operációs rendszer által szolgáltatott időbélyeg régebbi, mint az eDirectory-ban rögzítettek. A szinte tikus idő egészen addig fennáll, amíg a helyi szerver ideje utol nem éri a későbbi időbélyeg idejét. A szintetikus idő kétféle módon oldható fel:

• Várakozással • Az időbélyegek kijavításával és új korszak indításával A legjobb módszer a szintetikus idő problémáinak megoldására (amennyiben lehetséges) hagyni, hogy az idő teljen és megszűnjön a jelenséget kiváltó ok. Ez nyilván csak akkor reális lehetőség, ha az eDirectory-ban lévő időbélyeg nem sokkal (pár órával, esetleg egy-két nappal) mutat csak a jövőbe. Ha viszont az eDirectory-ban lévő időbélyeg túlságosan messze mutat a jövőbe (pl. évekkel későbbre), akkor kijavíthatók az időbélyegek, és új „korszak” indítható az adott partíción. Az új korszak indítása azt eredményezi, hogy a master replika nullázza a partíció összes objektumának módosítási időbélyegét és ezután a partícióban lévő összes objektumot szétküldi a replikagyűrű szervereinek. A master kivételével az összes replika New állapotba kerül. Ez igen komoly hálózatforgalmat eredményez, és elég sokáig eltarthat, amíg az összes replika On állapotba kerül. Az, hogy pontosan meddig is tart a folyamat, függ a szerverek közötti kapcsolatos sebességétől és a replikagyűrűben lévő szerverek számától.

26/37


Figyelmeztetés: NE HASZNÁLJUK EZT A PARANCSOT, csak ha biztosak vagyunk benne, hogy a master replika pontosan tartalmazza az eDirectory-adatokat, hogy a fa összes szervere kommunikál egymással, ÉS hogy nincs folyamatban egyetlen partícióművelet sem. HA BÁRMELYIK FELTÉTEL NEM TELJESÜL, NE KÍSÉRELJÜK MEG VÉGREHAJTANI A PARANCSOT!

Vonatkozó TID-ek:

• 10011031: SYNTHETIC TIME is being issued at the server console • 10016113: Declare new Epoch doesn't fix Synthetic Time • 10020862: „Repair Time Stamps and Declare a New Epoch” Done on Wrong Server

27/37


VII.3.2.2 Az -XK3 kapcsoló Hogyan indítható el?:

load DSREPAIR –XK3 A DSRepair XK3 kapcsolójának neve a „killer switch 3” rövidítéséből származik. A „gyilkos kapcsolók” nem dokumentált, kifejezetten a műszaki karbantartási személyzet számára, az eDirectory-problémák megoldása során az időigényes feladatok lerövidítésére szánt opciók. Mivel a gyilkos kapcsolók törölnek, kizárólag azok használják, akik tisztában vannak vele, mire szolgálnak! Normális esetben soha nem szabad, hogy szükség legyen rájuk. Nélkülük is meg kell tudni oldani a problémákat. Az XK3 kapcsoló kitörli az összes „külső hivatkozás” (external reference) objektum backlink állapotát (az EF_BACKLINKED jelzőbitet), a létrehozás idejét nullára állítja, az osztályt -1-re, és a külső hivatkozás összes attribútumának időbélyegét is nullára. Az inhibit_move obituaryk az alábbi módon törölhetők az XK3 kapcsolóval: 1.

Töltsük be a DSREPAIR-t az -XK3 kapcsolóval

2.

Válasszuk ki az Advanced options menüt

3.

Válasszuk ki a Repair local DS database pontot

4.

Győződjünk meg róla, hogy a Check local references Yes-re van állítva

5.

Végezzük el a javítást

6.

Mentsük el a kijavított adatbázist

7.

Lépjünk ki a DSREPAIR-ből

8.

A rendszerkonzolnál adjuk ki az alábbi SET parancsokat:

SET DSTRACE = ON SET DSTRACE = +BLINK SET DSTRACE = *B 9.

Miután megjelent a „BACKLINK: Finished checking backlinks successfully” üzenet, menjünk vissza a rendszerkonzolhoz és adjuk ki a

SET DSTRACE = OFF parancsot. A backlink obituaryk kitörlődtek, így a Moved és utána az Inhibit_move obituaries feldolgozhatóvá válik. 10. Az obituaryk jelzőbitjei ellenőrizhetők akár DSVIEW-ban, akár a DSREPAIR | Check external references pontjában, a fentiekben leírt módon. 11. Várjunk legalább 15-30 percig. Eltart egy darabig az Inhibit_move obituary törlése, attól függően, hogy hány replikája van a partíciónak és hány objektum tárolódik benne. 12. Ha ez az eljárás nem működött, vagy ha a szerver már nincsen a fában és a „Szerver”objektum is törlődött az eDirectory-ből, akkor csak a Novell Technical Services tud segíteni. Egyes esetekben nincsen vonatkozó átmozgatott obituary, mert az eDirectory obituary folyamata rendellenesen ért véget. Ebben az esetben a Novell Technical Services tud segíteni az elárvult inhibit_move obituaryk törlésében.

28/37


VII.3.3 Műszaki információs dokumentumok (TID-ek) VII.3.3.1 Az UFR-rel kapcsolatos TID-ek

tid#

hibaüzenet

gyorsjavítás

10020436

-128 Running DSRepair - Repair Database

Frissítsünk a legújabb kliensekre.

10013555

Warning: Remote DN for the távoli ID

Nem hiba, csupán információs üzenet.

10015674

Unknown Operational Class Definition was found

Nem hiba, csupán információs üzenet. 12. táblázat: A DSREPAIR parancssori kapcsolói

VIII. Az eDirectory karbantartása Az eDirectory-nak, mint minden adatbázisnak szüksége van bizonyos karbantartó műveletek végrehajtására, megadott időközönként. Ez a fejezet a szükséges lépéseket ismerteti.

VIII.1. Heti teendők • eDirectory időszinkron ellenőrzés: LOAD DSREPAIR/Time Syncronization • eDirectory szinkronizáció ellenőrzése: LOAD DSREPAIR/Check Syncronization • eDirectory Partícióellenőrzés: eDirectory Manager/Partition Continuity • eDirectory szerver ellenőrzés: minden kiszolgálón megfelelő mennyiségű szabad memória áll a rendelkezésünkre

• Trustee mentés: TBACKUP /S futtatása a köteteken (vagy trusttee.nlm) • Log file-ok összegyűjtése, két külön szerveren. Szükséges LOG fájlok: SYS:SYSTEM/ABEND.LOG, DSREPAIR.LOG, SYS:ETC/CONSOLE.LOG

• eDirectory mentése DSREPAIR-rel: LOAD DSREPAIR/Advanced Options/Create Database Dump (eDirectory Archive)

VIII.2. Havi teendők Összegyűjtött logfile-ok, trustee mentés és eDirectory (DSREPAIR) mentés CD-re írása

29/37


IX. Az eDirectory mentése Az eDirectory időérzékenysége miatt az eDirectory-replikák használata az eDirectory első számú hibatűrési mechanizmusa. A replikák tartalmazzák az objektumokkal és tulajdonságaikkal kapcsolatos legfrissebb adatokat. A replikákkal visszaállíthatók vagy újjáépíthetők az ugyanazon partíció megsérült replikájának adatai. Ehhez képest a szalagos mentések csupán egyfajta „pillanatfelvételnek” tekinthetők, amelyek – szemben a valódi replikákkal – villámgyorsan elavulnak. Ezzel együtt célszerű szalagra is menteni az eDirectory-adatokat a még nagyobb biztonság érdekében. Egyes esetekben – például egyszerveres hálózatok esetében – más eszköz nincs is az eDirectory-adatok védelmére, mint a biztonsági mentés. Mindemellett a szalagos mentés védi az eDirectory-adatokat a katasztrófák – például tűzesetek vagy természeti katasztrófák – esetében is, tehát mindenképpen javasolt az eDirectory-adatok rendszeres mentése. A replikák a partíciók fizikai másolatai. Több replika használata megnöveli a rendszer hibatűrését, ugyanakkor a túl sok replika a hálózat leterheltségét eredményezheti. Általában három replika – egy MASTER és két Read/Write – hibatűrés szempontjából elegendő biztonságot nyújt.

IX.1. Az objektumazonosítók és a replikáció folyamata Minden egyes eDirectory-objektumhoz tartozik egy egyedi objektumazonosító (object ID). Míg a NetWare 3 az objektumazonosítókat menti szalagra a fájlrendszer adataival együtt, addig a – NetWare 4-ben megjelent – SMS alapú mentési folyamatok az objektumok megkülönböztetett, típusos nevét mentik el, mint pl. az alábbi:

CN=.user1.OU=TEREZ.O=BUD Az eDirectory-objektumoknak egyetlen, egyedi megkülönböztetett nevük van; ugyanakkor, amikor egy replika egy szerverre kerül, az eDirectory egy egyedi objektumazonosítót generál az objektumokhoz. Egyetlen eDirectory-objektumhoz tehát több objektumazonosító is tartozhat, attól függően, hány replikája létezik az adott partí ciónak. Ez azt jelenti, hogy minden objektumnak különböző objektumazonosítója van a különböző szervereken. A szerverek az objektumazonosítókat használják az adott helyi szerveren lévő helyi objektumok, és pl. a fájlszolgáltatások kapcsolatának koordinálásához. A szalagos visszaállítások során, amennyiben már létezik az adott objektumhoz egy azonosító, akkor a visszaállítási folyamat nem hoz létre újabbat. Amennyiben viszont az objektum nem szerepel a fában, az ezt követő visszaállítás során új objektumazonosító jön létre a szerveren. Hasonlóan a NetWare 3-hoz, a fájlrendszer jogosultságai a fájlrendszer adataival együtt mentődnek. Az SMS TSA az objektum megkülönböztetett nevét használja a fájlrendszer hozzáférési jogainak elmentéséhez, annak érdekében, hogy megőrizze a jogosultságokat a visszaállítási folyamat során is. Tegyük fel például, hogy egy „Felhasználó”-objektumot kitöröltünk a fából, majd újra létrehoztuk. Amennyiben a felhasználó fájljait szalagról állítjuk vissza, a TSA képes megtalálni a fájlrendszer az adott felhasználóra vonatkozó jogosultságait a megkülönböztetett neve alapján (már amennyiben pontosan ugyanazon néven hoztuk másodszor is létre). Figyelem! Az előző bekezdés azt indokolja, miért kell visszaállítani az eDirectory-objektumokat, mielőtt megkísérelnénk visszaállítani a fájlrendszer adatait. Ha ugyanis a megfelelő objektumok hiányoznak a fából, a fájlrendszer visszaállítása során azok nem kaphatják vissza a jogosultságokat, mert nem tudják őket mihez hozzárendelni.

30/37


Az eDirectory-adatok mentéséhez különböző mentési stratégiák léteznek. Amikor csak lehet, célszerű az eDirectory-adatokat központilag menteni. Ideális esetben egyetlen rendszergazda megfelelő jogosultsággal rendelkezik a fa minden olyan szerveréhez, amely a mentéshez szükséges. Ez természetesen nem mindig lehetséges. Nagy, elosztott szervezetek esetében telephelyi rendszergazdákat jelölhetünk ki, akik a fa rájuk eső részének mentéséért felelősek. Figyelem! Amennyiben egy replikaszerver van a fában, amely minden partícióról tartalmaz információt, akkor célszerű erről a szerverről menteni az eDirectory-t. Az eDirectory mentése során az alábbi irányelveket tartsuk be:

• A mentés rendszeres legyen (például heti rendszerességű). A mentések száma attól függjön, hogy milyen gyakran és milyen mennyiségben változtatjuk az eDirectory adatait (pl. veszünk fel vagy törlünk felhasználókat, mozgatunk részfákat stb.). Amennyiben nagy mértékű változás történik az eDirectory-ban (nagyszámú felhasználó létrehozása, vagy nagy mozgatási műveleteket), akkor célszerű az adatokat e művelet előtt és után elvégezni.

• Szükséges egy vállalati irányelv létrehozása az eDirectory mentésének gyakoriságával kapcsolatban. Ez az irányelv állhat akár annyiból is, hogy az eDirectory mentések a fájlrendszerek mentésekor történjenek.

• TSAeDirectory.NLM azon a szerveren használható, amelyikről a mentés történik. Ez a szerver az, amelyik a fa legnagyobb partíciójának replikáját tartalmazza, vagy a replikaszerver. Amennyiben egy szerver nem tartalmazza a teljes eDirectory-fa összes partíciójának valamely replikáját, akkor olyan szerveren is menteni kell, amelyiken a hiányzó rész található.

• Fontos, hogy legyen írásos feljegyzés a partíciókról és replikákról. Amennyiben az eDirectory-t teljes egészében kell visszaállítani, szükség lehet annak ismeretére, hol is voltak az egyes partíciók és azok replikái. E feljegyzés előállítására (és fájlba mentésére) akár a DSREPAIR segédprogram is használható.

IX.2. Alternatív mentési eljárások Az alábbi eljárások nem biztosítanak átfogó mentési megoldást, mindazonáltal hasznos mentési mechaniz musnak bizonyulhatnak, amennyiben a szokványos mentések illetve visszaállítások valamilyen okból sikertelenek.

IX.2.1 Trustee-k (jogosultak) mentése Mivel a fájlrendszer jogosultságokat maga fájlrendszer tárolja, ezért lehetőség van csupán ezek mentésére is, anélkül, hogy a fájlokat is menteni kellene. A TBACKUP nevű program segítségével egy egyszerű szöveges állományba menthetők a jogosultságok. Itt akár manuálisan szerkeszthetők, illetve a RIGHTS parancs segítségével könnyedén visszaállíthatók. A trustee-k mentésére a Novell PSH álltal fejlesztett TRUSTEE.NLM is használható.

IX.2.2 Objektummentés Az előzőekhez nagyon hasonlatos program a Novell Consulting által fejlesztett eDirectoryExport/Import program, ami szintén egy szöveges fájlba menti az eDirectory információkat. Ennek a programnak vannak bizonyos korlátai, így a többváltozós mezők mentését és visszaállítását nem támogatja, mégis hasznos lehet egy szöveges állományban is tárolni az eDirectory objektumok adatait.

IX.2.3 Az eDirectory adatbázisának mentése A szerveren tárolt adatbázis egésze, a rajta található partíciók replikáival és minden objektummal együtt egyetlen tömörített állományba menthető. A LOAD DSREPAIR –RC paranccsal egy 0000000.$du nevű állomány

31/37

eDirectory oktatási segédlet – Dokumentáció jön létre a SYS kötet SYSTEM/DSR_DIB könyvtárában. Ezt az állományt azonban csak a Novell Technical Services képes visszaállítani. Másik megoldás az eDirectory állományok fizikai mentése. Az eDirectory adatbázis a SYS köteten az _NETWARE könyvtárban található. A DS.NLM kitöltése után (UNLOAD DS) ezeket minden további nélkül le lehet másolni egy a szerveren futó fájlkezelővel (pl. Compaq File Manager vagy JCMD). Ennek kezelése azonban fokozott figyelmet és megfelelő szaktudást igényel. Alkalmazása csak az eDirectory-ban jártas szakember felügyelete mellett javasolható.

IX.3. A Novell-címtárszolgáltatás visszaállítása A fentiek alapján tehát, az eDirectory-adatokat lehetőleg a replikákban tárolt adatokból, helyreállítási művele tekkel kell megkísérelni helyreállítani. Az aktívan működő replikák adatai a szalagra mentetteknél frissebbek és gyorsabbak. Amennyiben mégis szalagról szükséges visszaállítani az eDirectory-adatokat:

• A meglévő eDirectory-fában lévő replikák szinkronizációjának hibátlannak kell lennie – ez az eDirectory Managerrel vagy a DSTRACE-szel ellenőrizhető. Hibás replikaszinkronizáció közben történő eDirectory-visszaállítás hatványozhatja a problémákat.

• Amennyiben a replikaszinkronizáció nem tökéletes, a replikák számát csökkenteni kell mindaddig, amíg a szinkronizációs probléma nem oldódik meg.

• Mindig az eDirectory visszaállítása az elsődleges, és csak ezután következik a fájlrendszer és a jogosultságok visszaállítása. Ellenkező esetben a jogosultságok elvesznek.

IX.3.1 Részleges eDirectory-visszaállítás A NetWare SMS TSA-ival részlegesen is visszaállíthatók objektumok és azok csoportjai a mentésekből. A részleges visszaállítás csak igen megfontolt esetben javasolt. Egyetlen objektum helyreállítása esetén például lényegesen gyorsabb lehet az objektumot újra létrehozni az ConsoleOne segédprogrammal, mint végrehajtani a részleges visszaállítást. Ezen felül az alábbiakban áttekintett visszaállítási procedúra alapos ismerete szükséges a részleges visszaállítás sikerességéhez.

IX.3.1.1 Objektumazonosítók Az eDirectory-fában nem létező objektum visszaállításakor új objektumazonosítót kap. Az új objektumazonosító nem fog megegyezni a régivel. Ha viszont egy objektum már létezik a fában, visszaállításakor a szalagról visszaállított tulajdonságok felülírják az objektum meglévő tulajdonságértékeit.

IX.3.1.2 Függő objektumok Függő objektumnak nevezzük azokat az objektumokat, amelyek az eDirectory-fa más objektumaitól függenek. Egy „Print Queue”-objektum például tulajdonságértékekként tartalmazza a nyomtatási sor fizikai helyét és szerverét. Ezen adatok nélkül az objektum nem funkcionál. Tehát mindig ezen objektumokhoz tartozó objektumokat kell először visszaállítani, majd az adott objektumot kézzel létrehozni (esetleg a harmadik gyártó programját újra lefuttatni a konfigurációhoz).

IX.3.1.3 „Ismeretlen”-objektumok Az eDirectory visszaállításakor létrejöhetnek ismeretlen objektumok. Ha például a visszaállított objektum függ egy olyan másiktól, amelyik még nem létezik a fában, „Ismeretlen” típusú objektumként jelenik meg. Az eDirectory minden alkalommal „Ismeretlen”-objektumot hoz létre, amíg nem tudja visszaállítani teljesen a valódit. Amennyiben vissza tudja, az „Ismeretlen” típus és név visszacserélődik az objektum valódi típusára és nevére. Egy visszaállítás során mindig fogunk „Ismeretlen”-objektumokkal találkozni egészen addig, amíg az összes erőforrás – szerver, kötet, felhasználó stb. – nincs a helyén. A legtöbb ismeretlen objektum meg kell, hogy szűnjön a helyreállítás végére. Amennyiben nem teszik, ezeket törölni kell majd újra létrehozni, esetleg mentésből visszaállítani.

32/37


IX.3.1.4 Bindery-objektumok és alkalmazások Mivel új objektumazonosítók jönnek létre minden olyan objektumhoz, amelyek nem léteztek az eDirectoryfában, a bindery alapú alkalmazások – például nyomtatás, e-mail stb. – várhatóan nem fognak helyesen működni, lévén a – korábban megjegyzett régi – objektumazonosítókat használják a kommunikációhoz. A legtöbb esetben ezeket az alkalmazásokat újra kell telepíteni és konfigurálni a fa visszaállítása után. A bindery alapú „Felhasználó”-objektumokhoz tartozó bejelentkezési parancssorozatok a felhasználók MAIL könyvtárába kerülnek, ha a SYSCON-hoz hasonló segédprogrammal hoztuk létre azokat. Ezek az alkönyvtárak is az objektumazonosítókra épülnek, viszont ha a „Felhasználó”-objektumot más objektumazonosítóval állítjuk vissza, akkor ezek a MAIL könyvtárak nem neveződnek át automatikusan. Arra, hogy visszaállítás után a régi MAIL könyvtárnév (objektumazonosító) az újra változzon, a Novell RENMDIRS.NLM nevű segédprogramja használható.

IX.3.1.5 Nyomtatási szolgáltatások Amennyiben nyomtatásisor- (queue) alapú nyomtatást használunk, úgy az eDirectory visszaállítása után vissza kell állítani a nyomtatási szolgáltatások objektumait is. Ezen felül le kell futtatni minden olyan (külső gyártótól származó) beállítóprogramot, amely a nyomtatási környezet újrakonfigurálásához szükséges. Mivel a visszaál lítás során a nyomtatási sor objektumazonosítója is megváltozott, újra létre kell hozni a nyomtatási sort ahhoz, hogy az objektumazonosítóját az új „Print server”-objektum azonosítójához rendelhessük. Nagy valószínűség szerint a nyomtatókat is újra kell indítani az újrakonfigurálás után. (Ez nem vonatkozik a munkaállomáson keresztül történő nyomtatásra).

IX.4. Az eDirectory teljes visszaállítása Az eDirectory teljes visszaállítására akkor lehet szükség, ha az összes szervert egyszerre valamilyen katasztrófa érte. Nagy, földrajzilag szétszórt hálózatok esetében ez szinte kizárt. Kisebb, egytelephelyes, esetleg egyetlen épületben található cégek esetében valószínűbb ez a lehetőség. Az eDirectory teljes visszaállítása az alábbi lépéseket követeli meg:

• A NetWare-fájlszerver(ek) újratelepítése ugyanazzal a címtárfastruktúrával. Minden olyan fájlszerver visszaállítása szükséges, amelyhez függő objektumok tartoznak.

• Egynél több NetWare-szerver telepítésénél töröljük ki a [Root]-partíció alapértelmezésben létrejött replikáit a visszaállítás megkezdése előtt. Ezen a szerveren elegendő helyre van szükség az egész eDirectory tárolására.

• A szalagos mentőeszköz(ök) meghajtóprogramjainak újratelepítése. • A teljes eDirectory visszaállítása a szerverre. Az eDirectory-fa ezek után teljes egészében a [Root]partícióban található.

• Fájlrendszer visszaállítása minden egyes szerveren. • Partíciók létrehozása az írásos feljegyzések alapján. Alternatívaként újratervezhető a partícionálás. DSREPAIR futtatása minden egyes szerveren.

33/37


X. Az eDirectory karbantartása Az eDirectory-nak, mint minden adatbázisnak szüksége van bizonyos karbantartó műveletek végrehajtására, megadott időközönként. Ez a fejezet a szükséges lépéseket ismerteti.

X.1. Heti teendők (NetWare) • eDirectory időszinkron ellenőrzés: LOAD DSREPAIR/Time Syncronization. • eDirectory szinkronizáció ellenőrzése: LOAD DSREPAIR/Check Syncronization. • eDirectory szerver ellenőrzés: minden kiszolgálón megfelelő mennyiségű szabad tárterület és memória álljon rendelkezésre.

• eDirectory mentése DSREPAIR-rel: LOAD DSREPAIR/Advanced Options/Create eDirectory Archive vagy parancssorból „DSREPAIR -RC”.

XI. Az eDirectory hibaelhárítása Az eDirectory hibaelhárítása túlmutat jelen oktatási anyagon, ezért ez a fejezet csak a megelőzést, a leggya koribb hibák kezelését, valamint a támogatóközpont által bekért adatok, naplófájlok elkészítésének módját tárgyalja. Amint már ismertettük, az eDirectory egy lazán konzisztens adatbázis, ami folyamatos szinkronizációt igényel. A leggyakoribb problémák a szinkronizáció kimaradásából, vagy több, egy időben kiadott, egymásnak ellentmondó parancsból adódnak.

XI.1. eDirectory hibakódok Az eDirectory által visszaadott hibakódok -601 -től -768 -ig terjednek.

XI.1.1 Nem létező bejegyzés (no such entry): -601 XI.1.1.1 Hiba oka A kért objektum nem létezik az adott szerveren.

XI.1.1.2 Teendők Leggyakoribb oka, hogy rossz kontextust ad meg a felhasználó, vagy az alkalmazás van rosszul konfigurálva.

XI.1.2 Inkonzisztens adatbázis (inconsistent database): -618 XI.1.2.1 Hiba oka A legtöbb ilyen esetben megsérült a helyi adatbázis és az inicializációs folyamat sem fut le (a címtár nem nyílik meg).

XI.1.2.2 Teendők Valószínűleg mentésből kell visszaállítani a sérült adatbázist, vagy ki kell venni a szervert a fából.

34/37


XI.1.3 Kommunikációs probléma (transport failure): -625 XI.1.3.1 Hiba oka Ha egy replikát tároló szerver nem elérhető az 524-es NCP porton, a replikagyűrű nem szinkronizálódik megfe lelően. Ez -625 -ös hibaként jelentkezik pl. DSREPAIR-ben vagy DSTRACE-ben.

XI.1.3.2 Teendők Ilyen esetben értelemszerűen a legfontosabb teendő a kommunikáció helyreállítása. Ne végezzünk semmilyen partíció-műveletet, úgy mint:

• replika műveletek (törlés, létrehozás, split, merge, master váltás) • felhasználó mozgatása partíció-határon át • szerver telepítése a partícióba (ha kevesebb mint 3 replika létezik az adott partícióról, automatikusan új RW replikát rak rá) Ha mégis elindul egy partíció-művelet, azt nem fog befejeződni, bizonyos esetekben be is ragadhat az obituaryfolyamat.

XI.1.4 Folyamatban lévő mozgatás (previous move in progress): -637 XI.1.4.1 Hiba oka Mielőtt egy objektum újból mozgatható lenne, vagy partícióművelet szeretnénk végrehajtani a mozgatott objektum célpartícióján, minden mozgatási műveletnek le kell futnia. A mozgatási művelet lefutásának időtartama a replika méretétől, a replikák számától és a szerverek közti kommunikáció állapotától függ.

XI.1.4.2 Teendők Amennyiben huzamosabb ideig fennáll a hiba, ellenőrizzük, hogy a replika-gyűrűben minden szerver megfelelően kommunikál-e. Ha nincs probléma a kommunkációval (nincs -635 -ös hiba a DSREPAIR szinkronizációs jelentésében), de továbbra is fennáll a hiba, akkor valószínűleg beragadt az obituary-folyamat.

XI.1.5 Replika-szinkron folyamatban (replica in skulk): -698 XI.1.5.1 Hiba oka A replika-szinkronizációs folyamat egy olyan szerverrel próbálta meg felvenni a kapcsolatot, amelyik már szink ronizál egy másik szerverrel.

XI.1.5.2 Teendők Ideiglenes hiba, nincs teendő. A replika-szinkronizációs folyamat kezeli ezt a hibát.

35/37


XI.2. A támogatóközpont által kért adatok, naplófájlok összegyűjtése, elkészítése A Novell által kért adatok, naplófájlok megfelelő elkészítése elősegíti a gyors hibaelhárítást.

XI.2.1 DSREPAIR naplófájl kezelése Amennyiben a hiba jelentkezik DSREPAIR-ben, úgy a naplófájlban is rögzítésre kerül. Esetenként a naplófájl mérete indokolttá teszi egy új naplófájl létrehozását, azonban ne felejtsük el lementeni az előző példányt, mivel a hibaelhárítás során szükség lehet rá. Érdemes átnevezni a korábbi példányt. A naplófájlok helye: NetWare Az alapértelmezett naplófájl a SYS:SYSTEM\DSREPAIR.LOG A -L kapcsoló a DSREPAIR naplófájl helyét határozza meg. Amennyiben a naplófájl már létezik, a további bejegyzések hozzáíródnak. OES Linux eDirectory 8.7.x Az alapértelmezett naplófájl a /var/nds/ndsrepair.log A -F kapcsoló a DSREPAIR naplófájl helyét határozza meg. Amennyiben a naplófájl már létezik, a további bejegyzések hozzáíródnak. OES Linux eDirectory 8.8.x Az alapértelmezett naplófájl a /var/opt/novell/eDirectory/log/ndsrepair.log A -F kapcsoló a DSREPAIR naplófájl helyét határozza meg. Amennyiben a naplófájl már létezik, a további bejegyzések hozzáíródnak. Windows Az naplófájl alapértelmezésben a DIBFiles könyvtárban található, pl.: c:\Novell\NDS\DIBFiles\dsrepair.log A -L kapcsoló a DSREPAIR naplófájl helyét határozza meg. Amennyiben a naplófájl már létezik, a további bejegyzések hozzáíródnak.

XI.2.2 DSTRACE naplófájl készítése A DSTRACE naplófájl elkészíthető konzolon és iMonitor-ban is. Javasoljuk az iMonitor használatát, mivel a felület könnyen kezelhető és teljes értékű naplófájlok készíthetők. Amennyiben nem elérhető az iMonitor, használjuk a DSTRACE-t a szerver konzolján.

36/37


Táblázatjegyzék 1. táblázat: Objektumjogok....................................................................................................................................10 2. táblázat: Tulajdonságjogok.................................................................................................................................11 3. táblázat: Objektumok névtípusai........................................................................................................................13 4. táblázat: A teljessé kiegészített relatív megkülönböztetett nevek....................................................................14 5. táblázat: Az Unattended Full Repair által elvégzett műveletek.........................................................................19 6. táblázat: A DSREPAIR naplófájl mezői az időszinkronizáció ellenőrzése után...................................................21 Netware és Windows alatt minden adatbázis-javítási művelet ugyanabból a menüből érhető el a DSRepairben. A műveletek elindításához válasszuk ki az Advanced Options menüt, majd a Repair Local DS Database (ld. 1. ábra) pontot. A 7. táblázat mutatja be e menü javítási műveleteit.......................................................................21 8. táblázat: A DSREPAIR adatbázis-javító műveletei NetWare-en..........................................................................22 9. táblázat: A DSREPAIR partíció- és replikajavító műveletei NetWare-en.............................................................23 10. táblázat: A DSREPAIR partíció- és replikajavító műveletei NetWare-en...........................................................24 11. táblázat: A DSREPAIR egyéb műveletei NetWare-en.......................................................................................25 12. táblázat: A DSREPAIR parancssori kapcsolói....................................................................................................26 13. táblázat: A DSREPAIR parancssori kapcsolói....................................................................................................29

37/37

edirectory oktatási segédlet

Recommend Documents