Sistemul informational al retelei (NIS

Cuprins

Sa facem cunostinta 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 si group

Folosirea NIS cu suport pentru Shadow

Folosirea codului NIS traditional

In cazul unei retele locale (LAN), scopul final este de obicei crearea unui mediu in care utilizatorii sa poata folosi reteaua cat mai transparent. Un pas important in indeplinirea acestui scop este sincronizarea intre host-uri a informatiilor vitale (de exemplu informatiile legate de conturile utilizatorilor). Mai inainte am vazut ca pentru 'host name resolution' exista deja un serviciu puternic si sofisticat -- si anume DNS, dar in alte cazuri nu exista un astfel de serviciu. De asemenea, daca reteaua este mica si nici nu este legata la Internet s-ar putea ca instalarea DNS-ului sa nu merite efortul.

Din aceste motive firma Sun a inventat NIS, Network Information System. NIS ofera functii generice de acces la baze de date care pot fi folosite la distribuirea diferitelor informatii, de pilda cele continute in fisierele passwd si groups, acestea devenind accesibile pentru toate host-urile din retea. Astfel, reteaua apare ca un singur sistem, cu aceleasi conturi pe toate host-urile. In acelasi mod puteti folosi NIS pentru a distribui informatiile din /etc/hosts catre toate calculatoarele din retea.

NIS se bazeaza pe RPC si cuprinde un server, o biblioteca pentru client si cateva utilitare de administrare. Initial NIS era numit Yellow Pages, sau YP, denumire care mai este inca folosita (informal) pentru acest serviciu. Insa Yellow Pages este o marca inregistrata a British Telecom, care a cerut ca Sun sa renunte la nume. In ciuda acestui lucru, oamenii renunta greu la denumirile cu care s-au obisnuit, asa ca YP a ramas prefixul majoritatii comenzilor care se refera la NIS: ypserv, ypbind, etc.

Acum, NIS este disponibil pentru oricine, existind chiar implementari free. Una dintre acestea face parte din BSD Net-2 si se bazeaza pe o implementare pusa la dispozitia publicului larg de catre Sun. Biblioteca pentru client a existat in GNU libc de mult timp, in comparatie cu utilitarele - care au fost portate relativ de curand de catre Swen Thmmler. Din implementarea de referinta lipseste insa serverul NIS. Tobias Reber a scris un alt pachet NIS (numit yps) care include toate utilitarele si un server.

In momentul de fata Peter Eriksson lucreaza la rescrierea completa a codului NIS, redenumit acum NYS, care suporta atat NIS cat si NIS+ (varianta revizuita). NYS nu ofera doar un set de utilitare NIS si un server, ci si un set complet nou de functii de biblioteca; acestea probabil ca vor fi incluse si in varianta standard a libc. Este inclusa si o schema noua de configurare pentru 'hostname resolution' care inlocuieste schema actuala care foloseste host.conf. Aceste functii vor fi descrise mai jos.

In acest capitol accentul va fi pus pe NYS si nu pe celelalte doua pachete care vor fi numite codul NIS ``traditional''. Daca doriti sa utilizati unul dintre acestea doua, instructiunile din acest capitol ar putea fi suficiente, dar s-ar putea si sa nu fie. Pentru informatii suplimentare consultati un manual standard despre NIS, cum este NFS and NIS de Hal Stern (vezi-[]).

NYS este inca in faza de dezvoltare, si de aceea utilitarele standard (de exemplu utilitarele de retea sau programul login) nu cunosc schema de configurare NYS. Atata timp cat NYS nu este inclus in libc va trebui sa recompilati programele care doriti foloseasca NYS. Pentru oricare dintre aceste aplicatii, adaugati in Makefile optiunea -lnsl chiar inainte de libc. Astfel in loc de functiile bibliotecii C standard vor fi link-ate functiile din libnsl -- biblioteca NYS.

Sa facem cunostinta cu NIS

NIS pastreaza informatiile bazei de date in asa numitele map-uri care contin perechi de valori-cheie. Map-urile sunt stocate pe un anumit host pe care ruleaza serverul NIS, de unde clientii pot obtine informatiile prin diferite call-uri RPC. Destul de frecvent, map-urile sunt stocate in fisiere DBM.

Map-urile in sine sunt de obicei generate din fisierele text originale cum sunt /etc/hosts si /etc/passwd. Pentru unele fisiere sunt create mai multe map-uri, cate unul pentru fiecare tip de cheie de cautare. De exemplu, in fisierul hosts se poate cauta fie un host name, fie o adresa IP. Deci in acest caz sunt generate doua map-uri NIS numite hosts.byname si hosts.byaddr. In tabela puteti vedea o lista cu map-urile tipice si fisierele din care sunt generate.

Table: Cateva map-uri NIS standard NIS si fisierele corespunzatoare. ? ? ???????

S-ar putea ca in unele pachete NIS sa gasiti suport si pentru alte fisiere si map-uri. Acestea contin informatii pentru aplicatii care nu sunt abordate in acesta carte, de pilda bootparams folosit de unele servere BOOTP (map-urile corespunzatoare sunt ethers.byname si ethers.byaddr).

De obicei, in loc de unele map-uri se folosesc nicknames (porecle), care sunt mai scurte si mai usor de tastat. Pentru a obtine lista completa a nicknames-urilor recunoscute de utilitarele NIS puteti folosi comanda:

Serverul NIS este numit, prin traditie, ypserv. Intr-o retea de marime medie, un server NIS este in general suficient; in retelele mari insa, se poate sa fie necesare servere diferite pentru diferite hosturi si pentru diferite segmente ale retelei, pentru a nu suprasolicita serverele si routerele. Aceste servere sunt sincronizate: unul este master server, iar celelalte slave servers. Map-urile sunt create numai pe master server si de acolo sunt distribuite pe toate serverele slave.

Trebuie sa fi observat ca pana acum am vorbit foarte vag despre ``retele''; In cadrul retelei, NIS vine cu un concept distinct: domeniul NIS care este totalitatea host-urilor care cu ajutorul NIS distribuie in cadrul retelei o parte din configuratia lor. Domeniile NIS nu au nimic comun cu domeniile intalnite la DNS, asa ca pentru a evita orice ambiguitate, voi specifica de fiecare data la care tip de domeniu ma refer.

Functia domeniilor NIS este una pur administrativa. Ele sunt aproape invizibile pentru utilizatori: acestia nu sezizeaza decat folosirea acelorasi parole pe toate calculatoarele din domeniu. De aceea, numele dat domeniului NIS este important numai pentru administratori. In principiu se poate alege orice nume, cu conditia sa fie unic in cadrul retelei locale. De exemplu, administratorul de la Virtual Brewery ar putea alege sa creeze doua domenii NIS, unul pentru Brewery si altul pentru Winery, pe care le va numi pur si simplu brewery, respectiv winery. Destul de des, domeniul NIS este botezat la fel ca domeniul DNS. Pentru a vedea sau modifica numele domeniului NIS puteti folosi comanda domainname. Daca nu precizati nici un argument, va afisa doar numele curent al domeniului NIS; pentru a schimba acest nume, trebuie sa fiti superuser si sa tastati:

In functie de domeniile NIS se stabileste serverul NIS pe care il poate accesa o aplicatie. De exemplu, programul login de pe un host de la Winery trebuie, desigur, sa ceara informatiile referitoare la parola utilizatorului de la serverul NIS de la Winery (sau de la unul dintre serverele de la Winery, daca sunt mai multe); de asemenea, o aplicatie de pe un host de la Brewery trebuie sa acceseze numai serverul de la Brewery.

Acum nu mai ramane de dezlegat decat un singur mister : cum afla un client la care server sa se conecteze? Cea mai simpla solutie este folosirea unor fisiere de configurare locale, insa acesta solutie nu este flexibila, pentru ca nu permite clientilor sa foloseasca mai multe servere (bineinteles in cadrul aceluiasi domeniu). De aceea, implementarile NIS traditionale folosesc un daemon special - ypbind care detecteaza un server NIS potrivit din cadrul domeniului NIS. Inainte de a specifica orice cerere (query) NIS, aplicatiile trebuie sa afle mai intai de la ypbind ce server sa folosesca.

ypbind detecteaza serverele prin broadcasting pe reteaua IP locala; primul server care raspunde este considerat a fi cel mai rapid si va fi folosit pentru toate query-urile NIS urmatoare. Dupa un anumit timp sau daca serverul nu mai este disponibil, ypbind va incerca iarasi sa gaseasca un server activ.

Aceasta legare dinamica la diverse servere are o serie de aspecte discutabile. In primul rand este rareori necesara, si in plus slabeste gradul de securitate al retelei: ypbind nu e in stare sa deosebeasca un server NIS obisnuit de un intrus rau intentionat. Acesta devine o problema si mai grava daca bazele de date cu parole sunt administrate prin NIS. Din acesta cauza, NYS nu foloseste in mod implicit ypbind, ci citeste hostname-ul serverului dintr-un fisier de configurare.

NIS versus NIS+

NIS si NIS+ au putine lucruri in comun: asemanarea numelor si destinatia. NIS+ este structurat intr-o maniera complet diferita. In locul unui spatiu format din domenii NIS separate, NIS+ foloseste un spatiu ierarhic similar celui folosit de DNS. In locul map-urilor exista asa-numitele tabele constituite din randuri si coloane. Fiecare rand reprezinta un obiect in baza de date NIS+, iar coloanele sunt proprietatile obiectelor gestionate de NIS+. Tabela fiecarui domeniu NIS+ include tabelele domeniilor 'parinte'. De asemenea o inregistrare dintr-o tabela poate contine un link catre o alta tabela. Aceste facilitati ofera posibilitati multiple de organizare a informatiilor.

Varianta traditionala a NIS este versiunea 2 de RPC, in timp ce NIS+ este versiunea 3.

NIS+ nu pare sa fie folosit pe o scara larga, iar eu il cunosc destul de putin. (eh! nu se poate spune ca nu stiu chiar nimic) De aceea nu-l voi aborda in aceasta documentatie. Daca doriti sa aflati mai multe despre NIS+ puteti consulta manualul de administrare NIS+ de la Sun. ([]).

NIS: Partea de Client

Daca sunteti familiarizati cu scrierea sau portarea aplicatiilor de retea veti observa ca majoritatea map-urilor NIS listate mai sus corespund unor functii din biblioteca C. De exemplu, pentru a obtine informatii din passwd se folosesc de obicei functiile getpwnam(3) si getpwuid(3) care returneaza informatiile despre contul unui utilizator regasit dupa user name, respectiv user id. In mod obisnuit aceste functii cauta informatiile dorite in fisierul standard: /etc/passwd.

In cazul unei implementari care utilizeaza NIS, aceste functii vor fi modificate in sensul ca trimit catre serverul NIS un call RPC prin care este localizat numele si id-ul utilizatorului. Acest comportament este total transparent pentru aplicatie. Functia poate fie sa adauge elemente in map-ul NIS, fie sa inlocuiasca cu totul fisierul original. Bineinteles, nu are loc o modificare reala a fisierului, ci doar este creata iluzia ca acesta a fost inlocuit sau modificat.

In implementarile NIS traditionale existau mai multe conventii referitoare la care map-uri inlocuiesc si care se adauga la informatiile originale. Unele, cum sunt map-urile passwd, necesitau modificari ale fisierului passwd care daca nu erau facute corect afectau serios securitatea sistemului. Pentru a evita aceste capcane, NYS foloseste o schema generala de configurare care determina daca pentru un set de functii client de folosesc fisierele originale, NIS, sau NIS+, si in ce ordine. Capitolul curent include o sectiune speciala despre aceasta chestiune.