Ecsedi Kornél

Egyetemi szolgáltatások LDAP adatbázison


Debreceni Egyetem

Informatikai Szolgáltató Központ

Kornel.Ecsedi@unideb.hu


2002. február 11.


Bevezetés


Az utóbbi idõben az internetes technológiák rohamos fejlõdésének lehettünk szemtanúi. Ma már egész másképp használjuk az Internetet, mint korábban – mindennapi életünk része lett, információt gyûjtünk, programot fejlesztünk, levelezünk, telefonálunk, rádiót hallgatunk, filmet nézünk rajta keresztül. Régebben ha akartunk valamit, beléptünk egy szerverre, és elindítottuk a megfelelõ programot. Habár a hagyományos értelemben vett szerverek szerepe még mindig meghatározó, a felhasználók elõtt szinte mindent elfed a webes felület. Az alkalmazások és a felület között persze valamilyen kapcsolatnak kell lenni. Ezt hivatott biztosítani az úgynevezett középréteg (middleware). Ez egy olyan szoftver réteg, amely számos szabványos szolgáltatást nyújt, mint például azonosítást, hitelesítést, elektronikus aláírást, vagy névtár és biztonsági szolgáltatásokat. Ennek a szabványos középrétegnek a kialakítása nagy erõkkel folyik, mivel a ma létezõ alkalmazások nagy része saját egyéni módszerekkel dolgozik, és ez teljesen inkompatibilis megoldásokhoz, végsõ soron pedig káoszhoz vezet.

Fontosságban kiemelkedik a névtár szolgáltatás, amelyet szinte minden alkalmazás felhasználhat. Egy névtár tartalmazhat adatokat személyekrõl, erõforrásokról, csoportokról, stb. Az információt névtárban elhelyezve a különféle alkalmazások konzisztens módon férhetnek hozzá az adatokhoz. A közeljövõben a névtár jelentõsége várhatóan hasonló lesz ahhoz, mint amit ma a DNS jelent. (Tekinthetjük a DNS általánosításának is: ez is elosztott adatbázis, és itt is hasonló kulcs alapján lehet keresni, mint ott – domain név/DN, – csak egy DNS bejegyzésben nagyon korlátozottan tárolhatunk adatokat.)

A névtár olyan adatbázis, amit legnagyobb részt olvasásra használnak. Egyetemi környezetben az egyik legfontosabb felhasználási területe a felhasználói (fõleg hallgatói) adatok kezelése. Másik jelentõs alkalmazása az elektronikus levelezéshez kapcsolódik. Egyre nagyobb problémát jelent például, ha nem lehet megtalálni valakinek a címét, vagy éppen a megadott cím nem mûködik. Névtárak használata esetén egy adott személyhez tartozó e-mail címet egyszerûen megkereshetünk, és a módszer mindenhol ugyanúgy mûködik. A ma elfogadott de facto névtár szabvány az LDAP v3, amelynek szabad forráskódú implementációja az OpenLDAP v2.


Névtár egyetemi környezetben


A Debreceni Egyetem a Szegedi Tudományegyetemmel és a Szent István Egyetemmel közösen 2001-ben elkezdte kialakítani a saját névtár rendszerét. Ennek a munkának a folytatásaként kapcsolódtunk be az NIIF névtár project-jébe, ami jelenleg is tart.

A fõ célkitûzéseink az alábbiak voltak: létrehozni egy mûködõ LDAP alapú névtárat, feltölteni adatokkal, kialakítani az egyetemen az egységes levelezõrendszert, ahol mindenki azonos formátumú e-mail címmel rendelkezik, egységes autentikációt biztosítani a központi szervereken, megoldani a hálózati csomópontok nyilvántartását, illetve mindezekhez webes karbantartó és felhasználói felületeket készíteni. A munka még csak az elején tart, és várhatóan hosszú idõt vesz igénybe a névtár teljes kiépítése.

A projectek keretében beszereztünk egy központi LDAP szervert, egy IBM Netfinityt, 1 GHz-es PIII-as processzorral, 2 GB RAM-mal és Linux operációs rendszerrel, amelyen OpenLDAP v2 fut. A korábbi LDAP implementációnak nagy hártánya volt, hogy nem használt semmilyen szabványos karakteres kódolást. Az LDAP v3 UTF-8-as kódolást ír elõ a szöveges adatok tárolására, így megoldódott a nehézség, amit a magyar ékezetes betûk többféle eltérõ kódrendszerû megjelenítése okozott. Másrészt minden attribútum-típus és minden objektumosztály saját egyedi azonosítóval rendelkezik (OID), ami azért nagyon jelentõs elõrelépés, mert ugyanarra a dologra többféle elnevezés is használatos (pl. az userid és az uid attribútum ugyanazt jelenti), viszont az OID egyértelmûen meghatározza õket. Az LDAP v3 továbbá lehetõséget ad annak a megjelölésére, hogy milyen nyelven adtunk meg egy attribútumot. Az attribútum neve kibõvíthetõ módosító tagokkal, pl. nyelvi tagokkal (language-tag). Természetesen e lehetõség kiaknázása külön nehézséget jelentett a programok írásánál, és még nincs egészen letisztult koncepciónk a nyelvi módosító tagok használatára vonatkozóan. Annyi bizonyosnak látszik, hogy még a struktúra kialakításánál célszerû eldönteni, hogy valamely attribútumhoz megengedünk-e nyelv megjelölést. Az adminisztrációs felületekben az egyes attribútumoknak minden megadott nyelven meg kell jelenniük, viszont a nagyközönség számára készült keresõkben csak a felhasználó által választott nyelven, illetve a nyelvi megjelölés nélkül megadott értékeket érdemes megjeleníteni.

Az adatbázisban jelenleg kétféle adatot tárolunk. A hálózati csomópontok nyilvántartása van jobban kidolgozva. A személyi nyilvántartás struktúrája már kialakult ugyan, de az adatok feltöltése korántsem teljes.


LDAP és DNS


Az LDAP és a DNS kapcsolatáról már egy korábbi Networkshop elõadásban szóltam, mégis kell tennem néhány megjegyzést ezzel kapcsolatban. Az adatbázis struktúrája híven követi a DNS zóna felépítését, azaz az unideb.hu domain nevet a szokásos módon a dc=unideb,dc=hu dn-re konvertáljuk. Az egyetlen probléma az volt, hogy a Debreceni Egyetem több intézmény egyesülésével jött létre, és ezek hozták magukkal a saját domain neveiket, ráadásul az egyesült egyetemnek új domain neve is lett. Így több gyökere van a csomópont nyilvántartó adatbázisnak, és a programokban is meg kellett oldani, hogy több domain-t is tudjanak kezelni. Az átállás a régi LDAP v2-es rendszerrõl megkövetelte egy saját egyetemi OID létét is, amivel az általunk definiált objektumosztályt (unidebNetworkNode – a dnsDomain továbbfejlesztése) egyedi azonosítóval ellátva be tudtuk illeszteni az LDAP v3 struktúrába. Ezen kívül a régi csomópont nyilvántartó rendszer nagyrészt C++-ban íródott, s mindent át kellett írni PHP-ba. Összességében azonban a DNS nyilvántartás kompaktsága miatt sokkal könnyebben kezelhetõ, és kevesebb problémát vet fel, mint a személyi nyilvántartó rész.


Felhasználói adatok LDAP adatbázisban


A személyi nyilvántartáshoz is létrehoztunk egy saját unidebPerson nevû objektumosztályt, ami az eduPerson leszármazottja. Ami az utóbbi objektumosztályt illeti, az az Internet2 konzorcium MACE-Dir munkacsoportjának alkotása. Rengeteg hasznos, az egyetemek, kutatási intézetek szervezetéhez jól illeszkedõ attribútum-típus található benne, s ezt vette alapul az NIIF névtár project is. A struktúra kialakításánál több utat is választhattunk. Vagy készítünk egy mélységében tagolt fát, ami híven tükrözi a szervezeti felépítést, a karok és tanszékek viszonyát, vagy lapos szerkezetet választunk, és mindenkit néhány nagy csoportba viszünk fel. Döntésünkben a fõ szempont a minél egyszerûbb karbantarthatóság volt, s ezért a lapos szerkezetet választottuk. Ha ugyanis a szervezeti felépítés változik, akkor egy mélységében erõsen tagolt fát meglehetõsen nehéz átalakítani, nem is beszélve arról, hogy átmenetet kell biztosítani a régi és az új állapotok között, ami külön problémákat vet fel. Ezzel a döntéssel talán vesztettünk valamit a hozzáférési jogosultságok hangolhatóságából, de ez nem jelent akkora hátrányt, tekintve, hogy az adatbázist erõsen centralizált jellege miatt néhány ember fogja kezelni.

Az adatbázis feltöltése is nehézkesen haladt mindaddig, amíg nem volt az egyetemen egységes tanulmányi rendszer. A 23.000 hallgató és 1.700 oktató felvitele kizárólag valamilyen elsõdleges adatbázisból képzelhetõ el (konkrétan a tanulmányi osztályok rendelkeznek ilyennel), de eddig ezt csak részben tudtuk megoldani. Az egyetemen jelenleg folyik a Neptun bevezetése. Reményeink szerint innen könnyen átvehetõk lesznek majd mind a hallgatói, mind az oktatói adatok az LDAP adatbázisba.

A felhasználói és karbantartói webes felületek PHP4-ben íródtak. Az egységes kinézetet stíluslapok használata biztosítja. Készült egy általános karbantartó program, amely megtanítható az LDAP séma ismeretére, és így képes bármilyen típusú bejegyzés felvitelére, módosítására és törlésére, valamint kezeli a módosító tagokat is. A felhasználói adatokhoz tartozó nyilvános felület is készen áll már. A Neptun bevezetésével át kell állni az onnan történõ adatfelvitelre. Ehhez el kell készíteni a megfelelõ konvertáló programokat.

Az egységes egyetemi levelezõrendszerre vonatkozó terveink megvalósulása egyelõre elég távolinak tûnik, legalábbis ami az e-mail címek egyforma kinézetét illeti (név@unideb.hu). Egy központi levelezõ szerver felállítása azonban nagyon idõszerû lenne. Ez a szerver fogadná a kintrõl beérkezõ leveleket, és ezen keresztül lehetne kifelé is küldeni. Az egyetemen létezõ e-mail címeket az LDAP adatbázisból venné, és a bejövõ leveleket ennek alapján küldené tovább a helyi belsõ szervereknek. A központi szerver másik nagy elõnye, hogy egyetlen ponton lehet kiszûrni a levelekbõl a vírusokat, amelyek mára elárasztották a windows-os gépeket. Ahhoz, hogy felállíthassunk egy ilyen szervert, többek között be kell gyûjteni az összes címet az LDAP adatbázisba. Reményeink szerint nagyrészt ezt is meg lehet majd oldani a Neptun segítségével, minthogy abban a személyi adatok között szerepel az e-mail cím.

A szerverekre történõ egységes bejelentkeztetésre történtek kísérletek, bár az eredmények nem túl biztatóak. Homogén linuxos környezetben sikerült ugyan az LDAP alapú autentikáció az nsswitch-ldap segítségével, de a kódolt jelszó mindenki számára látható, ami meglehetõsen nagy hiányossága a módszernek. Az nsswitch mechanizmus mûködik Solaris alatt is, és AIX-ban is lehetõség van LDAP-s autentikációra, de ez utóbbi eltérõ adatszerkezetet használ, emiatt ha nem is lehetetlen, de jóval körülményesebb a szükséges adatok kezelése. Windows-os autentikációval egyelõre nem foglalkoztunk, mivel a nagy szervereken Unix fut. A jelszó változtatása sem egészen megoldott: nyilván nem várható el egy felhasználótól, hogy kiadjon egy megfelelõen felparaméterezett ldapmodify parancsot. Így saját programot írtunk hozzá.


Irodalomjegyzék


  1. Internet2 – http://www.internet2.org/

  2. eduPerson 1.0 Specification (http://www.educause.edu/eduperson/)

  3. RFC 2251. Lightweight Directory Access Protocol (v3). M. Wahl, T. Howes, S. Kille. December 1997.

  4. RFC 2252. Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions. M. Wahl, A. Coulbeck, T. Howes, S. Kille. December 1997.

  5. RFC 2596. Use of Language Codes in LDAP. M. Wahl, T. Howes. May 1999.

  6. RFC 2256. A Summary of the X.500(96) User Schema for use with LDAPv3. M. Wahl. December 1997.

  7. RFC 2307. An Approach for Using LDAP as a Network Information Service. L. Howard. March 1998.

  8. RFC 2247. Using Domains in LDAP/X.500 Distinguished Names. S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri. January 1998.

  9. RFC 2279. UTF-8, a transformation format of ISO 10646. F. Yergeau. January 1998.

  10. OpenLDAP 2.0 Administrator's Guide (http://www.openldap.org/doc/admin/)