Page 19

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.

NIS versus NIS+ NIS şi NIS+ au puţine lucruri în comun: asemănarea numelor şi destinaţia. NIS+ este structurat într-o manieră complet diferită. În locul unui spaţiu format din domenii NIS separate, NIS+ foloseşte un spaţiu ierarhic similar celui folosit de DNS. În locul map-urilor există aşa-numitele tabele constituite din rânduri şi coloane. Fiecare rând reprezintă un obiect

ccc  

ccc ccccasasasasasa

ccc  

ccc ccccasasasasasa

Advertisement