Hochenburger Róbert MCNI / MCNE MCNI = Master CNI MCNE = Master CNE CNI = Certified Novell Instructor CNE = Certified Novell Engineer e-mail: hochenbr@comnetworx.hu
miről lesz szó a következő órában? NDS 8 TAO, avagy NDS 8.5 a "több platformos" NDS: edirectory Novell Account Management DirXML
bindery a Netare 3.x rendszeradatbázisa lapos, strukturálatlan lista szervercentrikus csak az adott szerveren tárolódik el csak az adott szerver erőforrásait és az azokról szóló rendelkezéseket tárolja "sémája" nem bővíthető objektumtípusainak száma fix és gyári
NDS Novell Directory Services a Netare 4.x és 5.x rendszeradatbázisa hierarchikus fastruktúra az intranet összes szerverén végigfeszül (feltehetően) az NDS egésze az összes szerveren másolat formájában eltárolódik a fenti állítás természetesen leegyszerűsített... partíciók, replikák! sémája bővíthető külső gyártók termékei is integrálhatók az NDS-sel
a DS.NLM verziószámáról van szó a DS.NLM ugyebár az NDS-nek mint adatbázisnak a motorja a verziószámok: Netare 4.10: v5.x Netare 4.11 és 4.2: v6.x Netare 5 és 5.1: v7.x és v8.x
a "régi fajta": v5.x, v6.x, v7.x az általa kezelt adatbázis (t.i. az NDS) Btrieve alapú a jelző, mivel illetni szokás: RecMan az "új fajta": v8.x ő az NDS 8 a jelző, mivel illetni szokás: Flaim
a Netare 5-höz ingyenesen letölthető feltét a Netare 5.1 része alapértelmezésben fel is települ számos előnye van és kevés hátránya
az NDS partíciók méretének van-e ajánlott felső korlátja? NDS 7: van (1000 4500 objektum) NDS 8: nincs ennek oka egy új szolgálatás: az object cache egy-egy partíció replikáinak ajánlott maximális száma: NDS 7: 6 12 NDS 8: 50
a dedikált replikaszerveren tárolt replikák ajánlott maximális száma: NDS 7: néhány tucat NDS 8: 150 a replikaszinkronizáció belső nyilvántartása min alapul? NDS 7: synchronized-up-to szerverenként külön-külön nyilvántartott, nem replikázott információ NDS 8: transitive vector az NDS részét képező, s ezért replikázott információ
egy-egy szinkronizációs "csomag" hány változást hordozhat? NDS 7: csak egyet NDS 8: akár többet is takarékosabb lehetővé teszi a tranzitív szinkronizációt? NDS 7: nem NDS 8: igen a DS.NLM által használt cache mérete konfigurálható? NDS 7: nem NDS 8: igen
IP és IPX IPX IP csak IPX csak IP NDS változás
hogyan lehet beállítani? SET DSTRACE=!MBa_cache_mérete_bájtban azaz például: SET DSTRACE=!MB64000000 hol tárolódik el? SYS:_NETARE\_NDSDB.INI hogyan lehet az érvényben lévő méretet lekérdezni? SET DSTRACE=ON SET DSTRACE=*P
TUNEABLE PARAMETER VALUES... ServerStateUpThreshold = 30 minutes... External Reference Life Span = 192 hours... JanitorInterval = 2 minutes... FlatCleaningInterval = 720 minutes... BacklinkInterval = 780 minutes... Heartbeat Data = 60 minutes... Heartbeat Schema = 240 minutes... Schema synchronization enabled = 1... SMI Max Cache = 64000000 (Alloced = 1688776, Blks In Use = 0)... SMI Entries Cached Per Thread = 50 (Cached: 54, ~= 124416 bytes)... SMI Attr Recs Cached Per Thread = 20 (Cached: 3, ~= 12288 bytes)... SMI Partitions Cached Per Thread = 20 (Cached: 12)... SMI Force Checkpoint Interval = 180 (cannot change)... SMI Maximum Read Transaction Seconds = 2400 (cannot change)... SMI Maximum Read Transaction Inactive Seconds = 30 (cannot change)
nincs DSMERGE.NLM nincs DSBROSE.NLM nem támogatott a katalógusszolgáltatás Catalog Services a Netare 5.x része a kontextusmentes bejelentkezéshez (contextless login) szükséges
DS.NLM v85.x (bizony, nem 8.5x!) nem az NCP-re, hanem az LDAP-ra optimalizálták NCP: Netare Core Protocol LDAP: Lightweight Directory Access Protocol felügyeletének ajánlott eszköze a ConsoleOne azaz ímmár nem az NDS Manager van DSMERGE.NLM és DSBROSE.NLM
szűrt replika a megszűnőfélben lévő katalógusszolgáltatás egyfajta utóda új replika fajták filtered read-write filtered read-only az eddig is létező típusok megmaradtak master read-write read-only subordinate
szűrt replika felügyeletének kizárólagos eszköze a ConsoleOne azaz ímmár nem az NDS Manager a szűrő a szerverobjektum tulajdonsága csak az abban engédelyezett objektumtípusok, és azoknak is csak az engedélyezett proprtyjei replikázódnak át
imonitor a Netare Management Portal szolgáltatásait bővíti a Netare Management Portal a Netare 5.x részét képező, a szerver fekügyeletét http alapon, mezei Internetes böngészővel lehetővé tévő szolgáltatása NDSIMON.NLM szinte minden olyan információt nyújt, mint az NDS Manager, ConsoleOne és a DSTRACE sőt, többet is: hyperlinkelt DSTRACE
indexelés az NDS, mint adatbázis indexelése célja: az indexelt propertykre vonatkozó lekérdezések (query) gyorsítása az, hogy egy adott indexelési konfiguráció mennyire gyorsítja a lekérdezéseket, analizálható predicate
tree federation "fák szövetsége" az egyik NDS fa erőforrásait egy másik NDS fa felhasználói (és más fajta objektumai) használhassák a fa (fák) neve kötött: DNS az NDS és a DNS egyfajta integrációja az NDS konténerek elérési útját DNS-sel is fel kell tudni oldani példa: sufni.comnetworx.hu
tree federation az NDS objektumok elérési útjának új szintaxisa született eddig olyasfajta szintaxist szoktunk meg, mint sufni.comnetworx.hu az új szintaxis ezt megtoldja azzal, hogy.fanév. sufni.comnetworx.hu.dns. a záró pont jelentősége láthatóan megváltozott! ezt az új szintaxist egyes (főleg.nlm) segédprogramok nem csak tree federation esetén alkalmazzák fscnx1.sufni.cnx.cnx_tree.
az NDS két külön termékké vált szét: edirectory Novell Account Management
platformok Netare, indows 2000, indows NT, Solaris, Linux, Compaq Tru64 Unix a szerver beépül az NDS-be a szerveren replika tárolható akár master avagy szűrt replika is LDAP imonitor ConsoleOne időszinkronizáció (timesync)...
a szerver az NDS-ből kiszolgálhat különböző alkalmazásokat példa: a mycnn.com a web-hely Internetes felhasználóit tárolja és felügyeli az NDS-ben lehet-e az "alkalmazás" az a folyamat, ahogy a felhasználók a helyi operációs rendszerbe (pl. Linuxba) való autentikálása? lehet, de ehhez a másik termék, a Novell Account Management is szükséges!
platformok Netare, indows NT, Solaris, Linux, Compaq Tru64 Unix a indows 2000 támogatását 2001 első félévére ígérik valóban csak egyfajta "account management"-et végez az edirectory szolgáltatásait használja az azonban legalábbis elvileg nem szükséges, hogy a két termék ugyanazon a gépen fusson
autentikálás a helyi operációs rendszerbe alkalmazások
edirectory Novell Account Management Netare indows NT indows 2000 K Solaris Linux Compaq Tru64 Unix
a Novell Account Management fizikai értelemben megszünteti a helyi operációs rendszer címtárát (avagy címtárszerűségét) az NDS-ből emulálja a helyi operációs rendszer címtárát, annak tartalmával együtt korábbi neve indows NT platformon: NDS for NT a másik lehetőség az összekapcsolás a helyi operációs rendszer címtárát meghagyjuk tartalmát szinkronizáljuk az NDS-ével DirXML
mindkét esetben ugyanazt az előnyt élvezzük: nem kell két (vagy több) címtárat (avagy címtárszerűséget) felügyelnünk bár a felhasználóobjektumot csak az NDS-ben hozzuk létre, a többi címtárba is autentikálhatunk e felhasználóként
az NDS tartalmát szinkronizálja címtárakéval adatbázisokéval a szükséges feltételek: edirectory 8.5 (azaz TAO) maga a DirXML az edirectory-t futtató szerveren DirXML konnektor (connector) a szinkronizálandó címtáron ill. adatbázison a támogatott operációs rendszerek: Netare, indows NT, indows 2000, Solaris, Linux
a DirXML a következő kincstári konnektorokat tartalmazza: NDS így két NDS fa tartalma szinkronizálható össze Active Directory Microsoft Exchange Lotus Notes Netscape Directory Server további, külső cégek által fejlesztett konnektorok is megvásárolhatóak pl. SAP
címtár vagy adatbázis konnektor NDS
Extended Markup Language a HTML utóda http://www.xml.org http://www.xml.com http://www.w3.org ezen a nyelven definiált a DirXML által elvégzendő szinkronizáció adatleképzés (data translation) eseményleképzés (event translation)
<rule name="placement"> <placement-rules dest-dn-format="slash" src-dn-format="slash"> <placement-rule> <match-class class-name="user"/> <match-path prefix="\dirxml_tree\q\notesusers"/> <placement>cn=<copy-name/>/o=q</placement> </placement-rule> </placement-rules> </rule>
egy DirXML rendszer kialakításának lépései: az NDS és a másik címtár/adatbázis adatainak összefésülése (azaz a szinkronitás egyszeri kialakítása) szinkronban tartása (valós időben, eseményvezérelt módon)
a rule-ok fajtái: creation schema mapper match ing placement rule a style sheet-ek funkciója: // mit? // mire? // van-e már létező? // hová? az adatok konverziója aláhúzás helyett szóköz, vezetéknév/keresztnév csere stb. események transzformációja törlés A archiválás stb.
feltételek: indows NT szerver tehát nem Linux! edirectory 8.5 Novell kliens DirXML Notes R5 szerver Notes kliens
egyetlen számítógép: indows NT szerver edirectory 8.5 Lotus Domino R5 DirXML az NDS és a Notes címtár tartalmának a szinkronizációja...... a szünet után!