edirectory oktatási segédlet

Dokumentáció www.npsh.hu edirectory oktatási segédlet

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őforrá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 informatikai 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 replikaelhelyezé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 objektumok 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

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, munkacsoportok, 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. kontextusát (annak a konténernek a teljes nevét, amelyben az ő objektuma található) ahhoz, hogy be tudjon jelentkezni 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 attribú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

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ímtá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 Supervisor (S) Browse (B) Create (C) Delete (D) Rename (R) Inheritable (I) leírás Megad minden hozzáférési jogot. A Supervisor jog birtokában az objektum összes tulajdonságjogát is megadja. Engedélyezi, hogy egy objektum lássa az adott objektumot az edirectory-címtárfában. 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ó. Engedélyezi az objektum törlését a címtárfából. Engedélyezi az objektum nevének megváltoztatását. 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 Supervisor (S) Compare (C) Read (R) Write (W) Add/Remove Self (A) Inheritable (I) leírás Megad minden hozzáférési jogot az objektum tulajdonságaihoz. 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. Engedélyezi a tulajdonság értékének megjelenítését. Engedélyezi az objektum tulajdonságértékének módosítását, beírását és törlését. 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 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ó. 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: 2. táblázat: Tulajdonságjogok 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 hierarchikus 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

Ú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értelmezé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 C L O OU CN leírás Country (ország) név Locality (helyszín) név Organization (szervezet) név Organizational unit (szervezeti egység) név 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önbö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 reprezentá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öztetett 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 objektumok 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 objektummal találkozik, haladéktalanul értesítse a központi rendszergazdát. 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 rendelkezésre álljanak. 18/37

művelet Database Structure and Index Check Rebuild the Entire Database Perform Tree Structure Check Repair All Local Replicas Check Local References Repair Network Addresses Validate Stream Syntax Files leírás 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. 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. 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. 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. 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. 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. 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 Directories (Csak NetWare-en) 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 binderyfelhaszná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ő Server Name DS.NLM Version Replica Depth Time Source Time is in Sync Time Delta tartalom A kérést kiadó szerver megkülönböztetett neve. 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. 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. E mező neve félrevezető. A mezőben nem az időforrás, hanem a lekérdezett szerver időszerver-típusa látható. 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. 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 Rebuild Entire Database Repair All Local Replicas Validate Mail Directories és Stream Syntax Files Check Local References Reclaim Database Free Space Rebuild Operational Schema leírás 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. 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. 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. 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. Ez a művelet kikeresi a nem használt adatbázisrekordokat és törli őket a hely felszabadítása érdekében. 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