Cap. 5. Sistemul informational al retelei (NIS)

Cuprins
Să facem cunoștință cu NIS
NIS versus NIS+
NIS: Partea de Client
Rularea unui server NIS
Setarea unui client NIS cu NYS
Alegerea map-urilor corecte
Folosirea map-urilor passwd și group
Folosirea NIS cu suport pentru Shadow
Folosirea codului NIS tradițional

În cazul unei rețele locale (LAN), scopul final este de obicei crearea unui mediu în care utilizatorii să poată folosi rețeaua cât mai transparent. Un pas important în îndeplinirea acestui scop este sincronizarea între host-uri a informațiilor vitale (de exemplu informațiile legate de conturile utilizatorilor). Mai înainte am văzut că pentru "host name resolution" există deja un serviciu puternic și sofisticat -- și anume DNS, dar în alte cazuri nu există un astfel de serviciu. De asemenea, dacă rețeaua este mică și nici nu este legată la Internet s-ar putea ca instalarea DNS-ului să nu merite efortul.

Din aceste motive firma Sun a inventat NIS, Network Information System. NIS oferă funcții generice de acces la baze de date care pot fi folosite la distribuirea diferitelor informații, de pildă cele conținute în fișierele passwd și groups, acestea devenind accesibile pentru toate host-urile din rețea. Astfel, rețeaua apare ca un singur sistem, cu aceleași conturi pe toate host-urile. În același mod puteți folosi NIS pentru a distribui informațiile din /etc/hosts către toate calculatoarele din rețea.

NIS se bazează pe RPC și cuprinde un server, o bibliotecă pentru client și câteva utilitare de administrare. Inițial NIS era numit Yellow Pages, sau YP, denumire care mai este încă folosită (informal) pentru acest serviciu. Însă Yellow Pages este o marcă înregistrată a British Telecom, care a cerut ca Sun să renunțe la nume. În ciuda acestui lucru, oamenii renunță greu la denumirile cu care s-au obișnuit, așa că YP a rămas prefixul majorității comenzilor care se referă la NIS: ypserv, ypbind, etc.

Acum, NIS este disponibil pentru oricine, existînd chiar implementări free. Una dintre acestea face parte din BSD Net-2 și se bazează pe o implementare pusă la dispoziția publicului larg de către Sun. Biblioteca pentru client a existat în GNU libc de mult timp, în comparație cu utilitarele - care au fost portate relativ de curând de către Swen Thümmler. Din implementarea de referință lipsește însă serverul NIS. Tobias Reber a scris un alt pachet NIS (numit yps) care include toate utilitarele și un server.

În momentul de față Peter Eriksson lucrează la rescrierea completă a codului NIS, redenumit acum NYS, care suportă atât NIS cât și NIS+ (varianta revizuită). NYS nu oferă doar un set de utilitare NIS și un server, ci și un set complet nou de funcții de bibliotecă; acestea probabil că vor fi incluse și în varianta standard a libc. Este inclusă și o schemă nouă de configurare pentru "hostname resolution" care înlocuiește schema actuală care folosește host.conf. Aceste funcții vor fi descrise mai jos.

În acest capitol accentul va fi pus pe NYS și nu pe celelalte două pachete care vor fi numite codul NIS ``tradițional''. Dacă doriți să utilizați unul dintre acestea două, instrucțiunile din acest capitol ar putea fi suficiente, dar s-ar putea și să nu fie. Pentru informații suplimentare consultați un manual standard despre NIS, cum este NFS and NIS de Hal Stern (vezi-[]).

NYS este încă în faza de dezvoltare, și de aceea utilitarele standard (de exemplu utilitarele de rețea sau programul login) nu cunosc schema de configurare NYS. Atâta timp cât NYS nu este inclus în libc va trebui să recompilați programele care doriți folosească NYS. Pentru oricare dintre aceste aplicații, adăugați în Makefile opțiunea -lnsl chiar înainte de libc. Astfel în loc de funcțiile bibliotecii C standard vor fi link-ate funcțiile din libnsl -- biblioteca NYS.

Să facem cunoștință cu NIS

NIS păstrează informațiile bazei de date în așa numitele map-uri care conțin perechi de valori-cheie. Map-urile sunt stocate pe un anumit host pe care rulează serverul NIS, de unde clienții pot obține informațiile prin diferite call-uri RPC. Destul de frecvent, map-urile sunt stocate în fișiere DBM.

Map-urile în sine sunt de obicei generate din fișierele text originale cum sunt /etc/hosts și /etc/passwd. Pentru unele fișiere sunt create mai multe map-uri, câte unul pentru fiecare tip de cheie de căutare. De exemplu, în fișierul hosts se poate căuta fie un host name, fie o adresă IP. Deci în acest caz sunt generate două map-uri NIS numite hosts.byname și hosts.byaddr. În tabela puteți vedea o listă cu map-urile tipice și fișierele din care sunt generate.

Table: Câteva map-uri NIS standard NIS și fișierele corespunzătoare. ????????????????????

S-ar putea ca în unele pachete NIS să găsiți suport și pentru alte fișiere și map-uri. Acestea conțin informații pentru aplicații care nu sunt abordate în acestă carte, de pildă bootparams folosit de unele servere BOOTP (map-urile corespunzătoare sunt ethers.byname și ethers.byaddr).

De obicei, în loc de unele map-uri se folosesc nicknames (porecle), care sunt mai scurte și mai ușor de tastat. Pentru a obține lista completă a nicknames-urilor recunoscute de utilitarele NIS puteți folosi comanda:

Serverul NIS este numit, prin tradiție, ypserv. Într-o rețea de mărime medie, un server NIS este în general suficient; în rețelele mari însă, se poate să fie necesare servere diferite pentru diferite hosturi și pentru diferite segmente ale rețelei, pentru a nu suprasolicita serverele și routerele. Aceste servere sunt sincronizate: unul este master server, iar celelalte slave servers. Map-urile sunt create numai pe master server și de acolo sunt distribuite pe toate serverele slave.

Trebuie să fi observat că până acum am vorbit foarte vag despre ``rețele''; În cadrul rețelei, NIS vine cu un concept distinct: domeniul NIS care este totalitatea host-urilor care cu ajutorul NIS distribuie în cadrul rețelei o parte din configurația lor. Domeniile NIS nu au nimic comun cu domeniile întâlnite la DNS, așa că pentru a evita orice ambiguitate, voi specifica de fiecare dată la care tip de domeniu mă refer.

Funcția domeniilor NIS este una pur administrativă. Ele sunt aproape invizibile pentru utilizatori: aceștia nu sezizează decât folosirea acelorași parole pe toate calculatoarele din domeniu. De aceea, numele dat domeniului NIS este important numai pentru administratori. În principiu se poate alege orice nume, cu condiția să fie unic în cadrul rețelei locale. De exemplu, administratorul de la Virtual Brewery ar putea alege să creeze două domenii NIS, unul pentru Brewery și altul pentru Winery, pe care le va numi pur și simplu brewery, respectiv winery. Destul de des, domeniul NIS este botezat la fel ca domeniul DNS. Pentru a vedea sau modifica numele domeniului NIS puteți folosi comanda domainname. Dacă nu precizați nici un argument, va afișa doar numele curent al domeniului NIS; pentru a schimba acest nume, trebuie să fiți superuser și să tastați:

În funcție de domeniile NIS se stabilește serverul NIS pe care îl poate accesa o aplicație. De exemplu, programul login de pe un host de la Winery trebuie, desigur, să ceară informațiile referitoare la parola utilizatorului de la serverul NIS de la Winery (sau de la unul dintre serverele de la Winery, dacă sunt mai multe); de asemenea, o aplicație de pe un host de la Brewery trebuie să acceseze numai serverul de la Brewery.

Acum nu mai rămâne de dezlegat decât un singur mister : cum află un client la care server să se conecteze? Cea mai simplă soluție este folosirea unor fișiere de configurare locale, însă acestă soluție nu este flexibilă, pentru că nu permite clienților să folosească mai multe servere (bineînțeles în cadrul aceluiași domeniu). De aceea, implementările NIS tradiționale folosesc un daemon special - ypbind care detectează un server NIS potrivit din cadrul domeniului NIS. Înainte de a specifica orice cerere (query) NIS, aplicațiile trebuie să afle mai întâi de la ypbind ce server să folosescă.

ypbind detectează serverele prin broadcasting pe rețeaua IP locală; primul server care răspunde este considerat a fi cel mai rapid și va fi folosit pentru toate query-urile NIS următoare. După un anumit timp sau dacă serverul nu mai este disponibil, ypbind va încerca iarăși să găsească un server activ.

Această legare dinamică la diverse servere are o serie de aspecte discutabile. În primul rând este rareori necesară, și în plus slăbește gradul de securitate al rețelei: ypbind nu e în stare să deosebească un server NIS obișnuit de un intrus rău intenționat. Acesta devine o problemă și mai gravă dacă bazele de date cu parole sunt administrate prin NIS. Din acestă cauză, NYS nu folosește în mod implicit ypbind, ci citește hostname-ul serverului dintr-un fișier de configurare.