Aktuální stav LDAPu MetaCentra

Technická zpráva CESNETu číslo 29/2003
k dispozici též ve formátech PDF, PostScript a XML.

Jiří Sitera
prosinec 2003

1 Nová verze LDAPu MetaCentra

Počínaje 1.1.2004 je k dispozici nová verze adresářových služeb MetaCentra. Z pohledu uživatelů jde především o změnu schématu dat o uživatelských kontech a osobních údajích uživatelů. Tato technická zpráva navazuje na technickou zprávu [MetaLDAP], přičemž se zabývá téměř výhradně záležitostmi, které se od této technické zprávy změnily, nebo v ní nebyly obsaženy.

1.1 Základní změny v rámci aktualizace informačních služeb

V rámci aktualizace informačních služeb došlo k následujícím základním změnám:

Změna schématu - úprava a rozšíření LDAP schématu pro prezentaci údajů o uživatelích. Používané schéma je rozšířením standardního schématu o specifické atributy. Cílem provedené úpravy je využít co nejvíce standardních schémat a tím zvýšit kompatibilitu. Využito bylo zejména schéma eduPerson z projektu Internet2 (v oblasti informací o lidech) a rfc2307 (v oblasti informací o uživatelských kontech). Informace o novém schématu jsou součástí technické zprávy o systému Perun [Perun] a nebudou v této technické zprávě opakovány. Informace týkající se LDAP rozhranní jsou v uvedené technické zprávě soustředěny v jedné kapitole.
Propagace češtiny - situace s využíváním české diakritiky u klientů adresářových služeb není stále zcela vyhovující, použité řešení je kompromisní a umožňuje zachovat kompatibilitu a přitom zpřístupnit klientům odpovídající skutečně české informace.
Mechanismus distribuce dat z MetaDatabáze - tato úprava, nezávisle na struktuře dat, umožní zabezpečit propagaci změn databáze do LDAPu v reálném čase. Pro některé klienty a aplikace může tato funkcionalita znamenat značné zlepšení služeb informační infrastruktury.

V následujícím textu této kapitoly jsou shrnuty informace pro uživatele LDAP infrastruktury (s důrazem na nové věci resp. rozdíly oproti dřívějšímu stavu). V další kapitole jsou uvedeny informace, jejichž charakter je více implementačně orientován.

1.2 Přístup k datům

Základní parametry LDAP dotazu jsou popsány níže (jméno LDAP serveru, autentizace), port je implicitní (389). Báze dat ou=people,o=meta,c=cz.

1.2.1 Redundantní konfigurace klienta

Z hlediska uživatele je k dispozici LDAP server meta-ldap.cesnet.cz a v něm uložená data. Ve skutečnosti jsou zde tři servery meta-ldap1.cesnet.cz, meta-ldap2.cesnet.cz a meta-ldap3.cesnet.cz, které jsou navzájem zástupné. Správná konfigurace klienta by měla reflektovat tuto skutečnost, neboť použití záložního serveru v případě výpadku primárního je záležitostí klienta. Většina klientských knihoven funguje podobně jako např. DNS resolver (/etc/resolv.conf), tj. konfigurace určuje dostupné servery včetně pořadí v jakém mají být zkoušeny (funguje-li vše normálně, klient používá stále jen první server ze své konfigurace). Praktická konfigurace vypadá zpravidla tak, že namísto jména serveru se zadají jména tři oddělená mezerou. Pro běžné použití (dotaz z příkazové řádky) stačí samozřejmě použít alias meta-ldap.cesnet.cz.

1.2.2 Autentizace

Podporována je standardní Kerberos autentizace, to znamená GSSAPI přes SASL. Pro autentizaci je třeba mít kerberizovaného klienta (např. standardní řádkové tooly z OpenLDAPu) a platný Kerberos lístek. V této oblasti nedošlo k žádným změnám, vše podstatné je popsáno v technické zprávě [KrbLDAP]. Autentizace se v současnosti nepoužívá pro omezení přístupu k datům (data o uživatelích jsou veřejně přístupná), ale k ověření autenticity dat klienty (kteří je používají pro management uzlů apod.).

Poznámka: Adresářová služba MetaCentra nepodporuje autentizaci uživatelů protokolem LDAP, nelze ji použít jako autentizační službu.

1.2.3 Čeština

Celý obsah adresářové služby MetaCentra je primárně česky, nicméně bez háčků a čárek. Změna tedy neznamená zavedení češtiny (ale ani vícejazyčnosti), ale zavedení české diakritiky. Tento zásah se netýká struktury dat, používá tzv. language tagy jakožto nástroj pro uvedení několika "variant" hodnoty atributu.

Aktuální stav je kompromisem, který dovoluje vytvářet klienty plnohodnotně pracující s českou diakritikou a přitom je transparentní pro starší klienty.

Atributy, které mají textový obsah obsahující češtinu jsou uvedeny s několika language tagy.

Atribut bez tagu je cesky (ASCII ekvivalent).
Atribut s tagem lang-cs je česky - diakritika ve znakové sadě Unicode, kódování UTF-8.
Atribut s tagem lang-cs-ascii je cesky (tj. ASCII ekvivalent).

Další poznámky:

Při hledání (není-li explicitně uveden tag) se prohledávají hodnoty všech tagů daného atributu. Tj. položku najdete ať hledáte s češtinou či bez češtiny. Pokud chcete najít jen položky které vyhovují přesně včetně diakritiky, je nezbytné použít tag.
Pro takovou konfiguraci platí, že nezařídíte-li explicitně použití atributu s tagem lang-cs, jsou použité výsledky ASCII. Při hledání s češtinou (pokud klient použije správně UTF-8) se příslušné položky najdou. Takto se např. chová MS Outlook Express (verze 4.5 a vyšší) zatímco Pine s UTF-8 nepracuje, nelze ho pro češtinu vůbec použít (nelze do hledaného řetězce napsat české znaky, protože budou hledány jako latin2).

1.3 Struktura dat

Struktura dat (schéma, popis významu jednotlivých atributů) viz výše odkazovaná technická zpráva [Perun].

Základní předpokládané možnosti použití dat (kromě specificky vytvořených aplikací):

Data jsou uložena jako rozšíření standardního schématu inetOrgPerson, RFC 2798), měla by být srozumitelná všem běžným poštovním klientům (e-mailový seznam uživatelů MetaCentra).
Data splňují RFC2307, tj. vyjadřují uživatelské účty v rámci MetaCentra. Lze je přímo použít pro klienty jako je NSS_LDAP modul (více viz dále).
V omezeném rozsahu splňují data doporučení eduPerson projektu Internet2. Tato doporučení směřují obecně ke zlepšení interoperability zejména s ohledem na možné využití pro autorizaci a "roaming" uživatelů.

1.4 Použití pro e-mail seznam

Shrňme si základní informace potřebné pro konfiguraci klienta elektronické pošty pro přístup k adresáři (a telefonnímu seznamu) uživatelů MetaCentra:

LDAP server	`meta-ldap.cesnet.cz`
search base	`ou=people,o=meta,c=cz`
port	389 (standardní port)
autentizace	anonymní přístup

Tabulka 1: Základní parametry LDAP konfigurace pro e-mail klienta

1.4.1 Příklad - konfigurace pro Pine

K přidání adresáře MetaCentra do konfigurace Pine by měl postačovat následující postup (z hlavního menu (M)):

S - Setup
D - Directory
A - Add
meta-ldap.cesnet.cz - Zadat LDAP server do příslušného řádku
ou=people,o=meta,c=cz - Zadat search base do příslušného řádku
MetaCentrum - Zadat nickname do příslušného řádku
E - Exit setup
Yes - Yes, save changes

Poté máte k dispozici nový adresář pojmenovaný "MetaCentrum".

2 Technické poznámky a získané zkušenosti

2.1 Poznámky k aktuálnímu stavu LDAPu MetaCentra z hlediska uživatele

2.1.1 Využití pro NSS

NSS (Name Service Switch) je modul OS (např. libc), který dovoluje realizovat distribuci informací o uživatelských účtech na stroje technologií podobnou NIS (Network information system), více viz RFC2307, resp. nss_ldap¹. Nové schéma vychází ze snahy o kompatibilitu s RFC2307, ale v danou chvíli zde není k dispozici kompletní sada atributů - chybí kompletní Unix UID. Tato položka je lokální vůči buňce MetaCentra a dosud není zceka dořešena její propagace do centrální LDAP služby (více viz dále).

2.1.2 Atribut uidNumber

Vzhledem k výše uvedenému (Unix UID uživatele je lokální vzhledem k buňce, uživatel MetaCentra má několik hodnot UID) bylo nutno hledat cestu k vyjádření reality MetaCentra nad rámec RFC. Zvolen byl postup využívající volby atributu (attribute options) nebo také uživatelské tagy. Jedná se o stejný mechanismus jako v případě jazykových tagů, kdy jeden atribut může mít více hodnot, přičemž každá je označena volbou charakterizující specifikum uvedené hodnoty. V našem případě tato volba určuje buňku MetaCentra, ve které hodnota UID platí.

Příklad vyjádření atributu uidNumber:

uidNumber;x-meta-ics.muni.cz: 18660
uidNumber;x-meta-ruk.cuni.cz: 1437
uidNumber;x-meta-zcu.cz: 61036

Předpokládá se, že uživatel využije možností konfigurace NSS_LDAP modulu tak, aby tento používal variantu atributu uidNumber odpovídající správné buňce.

2.1.3 eduOrg

Pro plnou realizaci standardu eduPerson (respektive jeho jádra) je nezbytné použít schéma eduOrg pro popis organizací kterým jsou uživatelé přiřazeni a které potenciálně spolupracují.

2.2 Technické zabezpečení aktuálního stavu LDAPu MetaCentra

2.2.1 Attribute options

Zvolená jména voleb atributu uidNumber (viz popis výše) používají dle RFC2252 rezervováný prefix pro privátní experimenty. Jména s jinými prefixy podléhají registraci IANA, pokud se zvolený způsob prezentace několika hodnot atributu dle buňky osvědčí, bude třeba změnit prefix jmen volby atributu.

Volby atributů nejsou dosud součástí schématu a LDAP klient je nemůže zjistit standardním mechanismem komunikací se serverem. V implementaci OpenLDAPu se volby atributu konfigurují speciální klauzulí konfiguračního souboru attributeoptions.

2.2.2 Mechanismus distribuce dat z databáze

Všechna data zobrazená ve výše popisované části LDAP stromu pocházejí z Peruna (centrální relační databáze MetaCentra) a LDAP je "výstavní skříň" pouze pro jejich čtení. Namísto kompletního občerstvení celého stavu LDAP stromu z databáze jednou denně byl navržen a realizován mechanismus dovolující propagaci změn podle potřeby. Tento mechanismus přitom neklade na zdroj dat nároky v oblasti detekce a propagace změněných částí dat.

Mechanismus propagace změn je následující:

Zdroj dat (Perun) produkuje pouze kompletní obraz databáze (LDAP podstromu). Tento lze použít pro počáteční inicializaci LDAP serveru a byl používán dříve k občerstvení celého stavu LDAP stromu z databáze jednou denně. Zdroj dat zajistí, že obraz je vygenerován vždy když dojde ke změně, maximálně však jednou za hodinu. Generování tohoto obrazu zdroj dat nijak významně nezatěžuje.
Z přijatého obrazu se vytvoří na úrovni LDIF souborů rozdílový soubor změn oproti aktuálnímu stavu LDAP serveru. K tomu slouží utilita ldifdiff udržovaná v rámci projektu NET::LDAP (perl-ldap)².
- Zpracování může probíhat na úrovni souborů a tedy relativně velmi rychle, neboť stav LDAP serveru se nemůže změnit (během porovnávání). To je velká výhoda. Existuje podobný nástroj ldapdiff, který je značně flexibilní, ale protože předpokládá "živý" LDAP strom je podstatně náročnější na zdroje (čte stav cílového LDAPu položku po položce)³.
- Celý systém je odolný proti výpadku procesu propagace dat. Vždy se vytvoří změnový soubor obsahující všechny dosud nerealizované změny. V krajním případě je schopen se zotavit i z úplné ztráty dat v LDAP serveru.
- Výstupní soubor je ve tvaru LDIF change formátu. Lze jej standardně zpracovat např. řádkovou utilitou ldapmodify.
Změnové operace jsou realizovány standardně protokolem LDAP na základě rozdílového souboru. Operace odpovídají pouze provedeným změnám, nedochází tedy k periodické zátěži serveru při propagaci dat.

Narozdíl od předešlé technologie není třeba odstavovat LDAP server. Ten beží stále a zodpovídá dotazy klientů.
LDAP server může být replikován zcela standardní technologií. Změny prováděné přes LDAP protokol na primární kopii jsou dále propagovány na repliky bez nutnosti mít na těchto replikách jakékoli další konfigurace nebo nástroje.

Použitá literatura

[Perun]	Systém Perun verze 2.2 Technická zpráva CESNET v přípravě
[KrbLDAP]	Kerberos a OpenLDAP Technická zpráva CESNET 18/2002
[MetaLDAP]	Využití adresářových služeb (LDAP) v projektu MetaCentrum Technická zpráva CESNET 2/2001

Poznámky:

Více viz http://www.padl.com/OSS/nss_ldap.html.
Více viz http://perl-ldap.sourceforge.net/.
Více viz http://freshmeat.net/releases/143892/