Projekt Pleiades informační infrastruktura z pohledu

Transkript

1 Projekt Pleiades informační infrastruktura z pohledu jejího uživatele Jiří Sitera Centrum informatizace a výpočetní techniky, Laboratoř počítačových systémů, Západočeská univerzita v Plzni, sitera@civ.zcu.cz Verze ze dne 4. února :08 (JSCVSREP: Revision: 1.6 ) Tento dokument podává základní informace potřebné pro využití informační infrastruktury distribuovaného výpočetního prostředí ZČU projektu ORION. Tato infrastruktura je založena na jednotném rozhraní realizovaném prostřednictvím adresářových služeb, konkrétně protokolu LDAP. Více informací a vazby na okolí viz sekce vazby (4). 1 Infrastruktura a společné poznámky 1.1 Redundantní konfigurace klienta Z hlediska uživatele je k dispozici LDAP server ldap.zcu.cz a v něm uložená data. Ve skutečnosti jsou zde dva servery ldap1.zcu.cz a ldap2.zcu.cz, které se navzájem zálohují. Správná konfigurace klienta by měla reflektovat tuto skutečnost, nebot 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 tedy vypadá tak, že namísto jména serveru se zadají jména dvě oddělená mezerou (viz příklady dále). Pro běžné použití (dotaz z příkazové řádky) stačí samozřejmě použít alias ldap.zcu.cz. 1.2 Autentizace V současné době se předpokládá zejména anonymní přístup k datům. 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. 1

2 1.3 Čeština V současné době je čeština (háčky, čárky atd.) k dispozici pouze v části telefonního seznamu. Atributy, které mají textový obsah obsahující češtinu jsou uvedeny s několika lang tagy. Atribut bez tagu je cesky (ASCII ekvivalent). Atribut s tagem lang-cs je česky a atribut s tagem lang-en je cesky (tj. ASCII ekvivalent, nikoli anglický, jak mohou někteří klienti právem předpokládat). Další chování je plně dle standardu, tj. zejména: Čeština je ve znakové sadě Unicode, kódování UTF-8. Při hledání (není-li explicitně uveden tag) se prohledávají hodnoty všech tagů daného atributu. Tj. položku najdete at hledáte s češtinou či bez češtiny. 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. Pine s UTF-8 nepracuje, nelze pro češtinu vůbec použít. 1.4 Shrnutí parametry LDAP dotazu Parametry pro LDAP dotaz proti Pleiades infrastruktuře lze shrnout takto: stroj ldap1.zcu.cz ldap2.zcu.cz nebo jen ldap.zcu.cz viz výše popis zajištění redundance služby, port 389 (default LDAP port), báze dle dat, které chceme používat, popis viz níže. Prázdná báze znamená použití telefonního seznamu, filtr dle potřeby informací, které jsou k dispozici a popisu významu jednotlivých atributů, popis a příklady viz níže, autentizace anonymní přístup, žádná autentizační data nejsou potřeba, rozsah prohledávání celý podstrom (obvykle implicitní volba). 2 Dostupné informace Z mnoha důvodů jsou informace dostupné přes LDAP rozhraní rozděleny do několika zcela nezávislých skupin. Zásadní jsou informace o lidech. Zde jsou dvě skupiny, jedna je obraz telefonního seznamu (=data odpovídající databázi a aplikaci tohoto jména), druhá jsou informace o uživatelích distribuovaného výpočetního prostředí, které vycházejí z databáze managementu ORIONu. 2

3 2.1 Telefonní seznam Větev dat reprezentující telefonní seznam je dostupná implicitně, pokud uživatel nezadá žádnou bázi 1. Ve skutečnosti je báze této větve následující: ou=phonebook,ou=virtual,o=zcu,c=cz. Data jsou uložena jako rozšíření standardního schématu (inetorgperson), měla by být srozumitelná všem běžným poštovním klientům. Pro případ vlastního použití je shrnut popis atributů v tabulce 1 a následují příklady. K dispozici je klient ve formě WWW rozhraní (telefonní seznam ZČU), realizovaný v PHP. Jméno atributu, alias cn sn, surname givenname pid employeenumber employeetype departmentnumber ou mail telephonenumber roomnumber mobile street facultyname význam jméno a příjmení osoby včetně titulů příjmení osoby jméno osoby jednoznačná identifikace člověka vnitřní identifikátor managementu distribuovaného výpočetního prostředí zajišt uje jedinečnost záznamu, pouze u studentů jednoznačná identifikace zaměstnance zajišt uje jedinečnost záznamu, pouze u zaměstnanců; v současné době to není žádný skutečný identifikátor (např. osobní číslo), ale náhodné číslo typ člověka, v našem případě tento atribut existuje a má hodnotu STAFF jedná-li se o zaměstnance (nebo doktoranda) zkratka organizační jednotky, zpravidla katedry; pouze u zaměstnanců plný název organizační jednotky (katedry) u zaměstnanců, konstantní řetězec STUDENTS u studentů adresa elektronické pošty (zadaná v aplikaci telefonní seznam, tj. nemusí se jednat o standardní adresu poskytovanou ZČU) číslo telefonu; může mít několik hodnot zkratka místnosti číslo mobilního telefonu; dává se sem číslo uložené v položce původně určené pro přímé linky, které již dnes nejsou adresa pracoviště zkratka fakulty informace platná pouze u zaměstnanců Tabulka 1: Telefonní seznam objectclass pleiadesphone Telefonní seznam prakticky Do svého oblíbeného poštovního klienta nastavíte LDAP adresář na server ldap.zcu.cz, přičemž všechny ostatní parametry jsou implicitní. Podrobný popis konfigurace Outlook Express je součástí dokumentace na V pine je postup následující: S Setup D Directory 1 Dokonce je podporována i báze c=us, kterou za některých okolností používá MS Outlook Express v případě uživatelem ponechaného prázdného políčka báze. 3

4 A Add ldap server zadat ldap.zcu.cz E Exit setup Y Yes, save changes Poté máme k dispozici telefonní seznam jako nový address book pojmenovaný ldap.zcu.cz Telefonní seznam v příkladech Příklady hledání v telefonním seznamu jsou v tabulce 2. Jsou tam uvedeny filtry, tj. příklad vyzkoušíte příkazem: ldapsearch -h ldap.zcu.cz -b <filter> [ <žádané atributy> ] LDAP search filter (mail=sitera*) (sn=sitera*) (roomnumber=ul401) (departmentnumber=kiv) (telephonenumber=*2845) (&(employeetype=staff)(sn=novak)) (&(ou=students)(givenname=denisa)) význam hledání dle začátku u hledání dle začátku příjmení; vynechámeli hvězdičku jedná se o hledání přesného řetězce, hvězdička jako zástupný znak může být i na začátku kdo sedí v dané místnosti? všichni zaměstnanci katedry nebo organizační jednotky kdopak má tuhle linku? hledání všech zaměstnanců s daným příjmením hledání všech studentů s daným jménem Tabulka 2: Příklady hledání v telefonním seznamu 2.2 Informace o uživatelích Zde obsažená data primárně odpovídají ekvivalentu globálního passwd souboru projektu ORION dle RFC2307. Dále jsou zde vybrané skupiny uživatelů reprezentující jejich základní vlastnosti (vlastnost je vyjádřena tím, zda uživatel ve skupině je či není). Báze těchto dat je: ou=rfc2307,o=zcu,c=cz Schéma viz tab. 3. Význam hlavních skupin viz tab. 4, příklady využití viz dále Základní konfigurace pro použití dat jako NSS Pro distribuci informace o uživatelských kontech a skupinách /etc/passwd a /etc/groups lze data dle RFC2307 použít knihovnou NSS LDAP. Více viz literatura a projekt OPENORION ( 4

5 Jméno atributu cn sn givenname uid uidnumber gidnumber userpassword loginshell homedirectory mail význam jméno a příjmení osoby příjmení osoby jméno osoby uživatelské jméno (jednoznačný identifikátor) Unix ID uživatele (číslo), odpovídá uživatelskému jménu Unix číslo primární skupiny uživatele, odpovídá příslušné položce passwd příslušná položka passwd uživatele; v našem prostředí zde není heslo, předpokládá se použití Kerbera jméno implicitního Unix shellu uživatele včetně cesty tak jak se uvádí v passwd domovský adresář; v našem prostředí je zde cesta k domovskému adresáři v projektu ORION na AFS adresa elektronické pošty; zde uvedená adresa je primární adresa uživatele poskytovaná prostředím ORION Tabulka 3: Informace o uživatelích RFC2307 Jméno students staff etapa1 etapa2 jméno katedry acl$... význam uživatel je student uživatel je zaměstnanec uživatel je studentem první etapy uživatel je studentem druhé etapy zaměstnanec katedry přístupové skupiny dle managementu Tabulka 4: Datová část RFC2307 význam hlavních skupin 5

6 2.2.2 Příklady základních dotazů Následující příklady obsahují LDAP search filter a specifikaci atributů k vyzvednutí. Nejjednodušší využití je pomocí příkazu ldapserach takto: ldapsearch -h ldap.zcu.cz -b ou=rfc2307,o=zcu,c=cz <níže uvedené> Hledání Unix UID pro zadaný login: uid=<login> uidnumber Hledání Unix GID skupiny pro zadané jméno skupiny: (&(objectclass=posixgroup)(cn=<jméno skupiny>)) gidnumber Hledání všech skupin, ve kterých je daný uživatel: memberuid=<login> cn Výpis členů skupiny: (&(objectclass=posixgroup)(cn=<jméno skupiny>)) memberuid 3 Stav Informační infrastruktura je v plně provozním stavu s výše popsanou funkcionalitou a omezeními. 3.1 Datová základna Údržba datové základy a vazby na zdroje dat jsou složitým problémem informační infrastruktury. Základní platná omezení v tuto chvíli jsou popsána níže Informace o uživatelích Jak bylo již řečeno, pocházejí z managementu ORIONu. Zatím z toho vyplývá zejména: Vazba na studijní agendu Tato vazba je zajišt ována automaticky, jsou zde však jisté problémy. Tyto problémy se týkají zejména lidí, kteří studují více oborů či fakult a to jak současně či postupně, tak pokud mezi těmito přecházejí. Informace o zaměstnancích Jedná se o informace o zaměstnancích, které jsou pořizovány odděleně pro účely správy distribuovaného výpočetního prostředí. Není zde bohužel žádná vazba na ostatní zdroje takovýchto dat (např. telefonní seznam či JIS) natož pak na autoritativní zdroj typu mzdová agenda. Vylepšení tohoto stavu je cíl, který značně přesahuje rámec projektu Pleiades. Data jsou pořizována ručně na základě kontaktu uživatelů či kateder s pracovníky CIVu (HelpDesk). 6

7 3.1.2 Telefonní seznam Data o zaměstnancích pocházejí z databáze telefonního seznamu, což je také stejnojmenná aplikace sloužící k pořizování a údržbě této databáze. V současné době není databáze na nic navázána a údaje v ní jsou kompletně pořizovány. Pořizování a údržba dat je v kompetenci jednotlivých kateder, obvykle jejich sekretariátů. Více viz dokumentace této aplikace. Data o studentech pocházejí z managementu, platí pro ně informace uvedené výše. Pro účely telefonního seznamu se data o studentech vytvářejí spojením dat z managementu a STAGu (vazbou je klíč orion id), čímž se dosahuje jednak dostupnosti češtiny (v Moiře je vše ASCII) a jednak aktuálních jmen a příjmení (případné změny v těchto položkách se do Moiry nepropagují). 3.2 Doporučení Lze předpokládat, že výše popsaný datový model není definitivní. Vybudování jednotného rozhraní pro přístup k informacím v rámci distribuovaného výpočetního prostředí je dlouhodobý cíl, k jehož dosažení je nutné úsílí v mnoha oblastech. Jedním ze základních problémů je vlastní báze dat, její získávání a údržba. Proto je rozumné interakci s informační infrastrukturou v rámci aplikace realizovat tak, aby výsledkem byla funkční spolupráce s aktuálním stavem této infrastruktury a zároveň otevřené dveře pro změny implementace 2. Tento princip se týká i mnoha dalších dat spravovaných aplikacemi, tj. i těch, které momentálně nejsou dostupné prostřednictvím informační infrastruktury. U mnohých lze předpokládat jejich budoucí integraci do základních funkcí informační infrastruktury (např. autorizační údaje) a u mnohých lze považovat za rozumné umožnit jejich publikaci prostřednictvím jednotného rozhraní (specifická aplikační data, která mohou být využívána jinými aplikacemi). 3.3 Poznámky Pro účely managementu výpočetního prostředí a tohoto dokumentu jsou pod pojmem zaměstnanec myšleni i studenti doktorandského studia. 4 Vazby Tento dokument je poměrně úzce zaměřen. Pro získání celkového kontextu a dalších informací je k dispozici následující sekce odkazy a literatura. Dobrým vstupním bodem pro získání dalších informací o projektu Pleiades je [3]. Pro základní informace o adresářových službách lze použít např. [1, 2]. Výše uvedené příklady používají pro přístup k datům v adresářových službách protokolem LDAP utility příkazové řádky. Pro realizaci přístupu k těmto informacím prostřednictvím některého skriptovacího jazyka lze použít jako referenci [4]. 2 Zde se jeví výhodné např. definovat funkce pro přístup k těmto datům a sdružit je do zvláštního modulu, jehož implementační část je možno nezávisle měnit. 7

8 Odkazy a literatura [1] Jiří Sitera, Adresářové služby, únor [2] Jiří Sitera, Adresářové služby jako informační infrastruktura distribuovaného výpočetního prostředí, sborník konference EurOpen.CZ, listopad 1999, ISBN [3] Projekt Pleiades domovská stránka, [4] Jiří Sitera, Skriptovací jazyky a jejich využití pro přístup k adresářovým službám protokolem LDAP, březen 2000, 8