|
|
|
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 Thümmler. 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.
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 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. ([]).
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.
Poate ca v-ati plictisit de teoria de pana acum, asa ca hai sa ne punem pe treaba si sa ne apucam de configurarea propriu-zisa. In acesta sectiune vom discuta despre configurarea unui server NIS. Daca in reteaua dumneavoastra functioneaza deja un server NIS, nu mai este nevoie sa setati nimic ( si puteti sari fara grija peste acesta sectiune ).
Daca nu doriti altceva decat sa experimentati, sa 'va jucati' cu setarea serverului, aveti grija sa nu folositi un nume al domeniului NIS care exista deja in retea. Altfel s-ar putea sa destabilizati intregul serviciu de retea, iar multi oameni ar putea deveni nemultumiti si chiar foarte nervosi.
In momentul de fata exista doua servere NIS disponibile: unul in cadrul pachetului yps al lui Tobias Reber, si altul in cadrul pachetului ypserv al lui Peter Eriksson. In principiu nu conteaza pe care il folositi. In momentul acesta, cand scriu, codul pentru manipularea serverelor NIS de tip slave pare sa fie mai complet in yps. Deci daca aveti nevoie de servere slave, probabil ca yps este o alegere mai buna.
Dupa instalarea severului (programul ypserv) in /usr/sbin, urmeaza sa creati directorul care va contine fiserele map pe care le va distribui serverul. Cand setati domeniul NIS pentru brewery map-urile vor fi puse in /var/yp/brewery. Serverul determina daca deserveste un anumit domeniu NIS dupa existenta directorului cu map-uri. Daca la un moment dat doriti sa dezactivati un domeniu NIS, asigurati-va ca ati sters si directorul.
In general, map-urile sunt pastrate in fisiere DBM, care sunt generate din fisierele master cu ajutorul programului makedbm (pentru serverul lui Tobias) sau dbmload (pentru severul lui Peter). Acestea s-ar putea sa nu fie interschimbabile. Formatarea unui fisier master pentru a putea fi procesat cu dbmload necesita de obicei folosirea lui sed sau awk, ceea ce tinde sa fie cam anost si greu de retinut. De aceea pachetul ypserv al lui Peter Eriksson contine un Makefile (numit ypMakefile) care face toata acesta munca in locul dumneavoastra. Trebuie sa instalati acest fisier sub numele Makefile in directorul cu map-uri, apoi sa-l editati pentru a alege map-urile pe care doriti sa le distribuiti. Pe la inceputul fisierului se targetul all care contine toate serviciile pe care le poate oferi ypserv. In mod implicit, linia arata cam asa :
Daca de pilda nu aveti nevoie de map-urile ethers.byname si ethers.byaddr, pur si simplu stergeti ethers din acest rule. Pentru a testa configuratia probabil ca este suficienta pornirea a una sau doua map-uri, de exemplu services.*.
Dupa ce ati editat Makefile, ramaneti in directorul cu map-uri si tastati ``make''. Map-urile vor fi generate si instalate automat. Trebuie sa refaceti map-urile la fiecare modificare a fisierelor master, altfel schimbarile nu vor fi disponibile in retea.
In sectiunea urmatoare puteti afla cum se configureaza codul NIS pentru client. Daca setarile dumnevoastra nu merg, trebuie sa aflati mai intai daca cererile ajung sau nu la server. Daca la pornirea serverului specificati optiunea -D, acesta va tipari la consola mesaje referitoare toate cererile NIS primite si la rezultatele acestora. Aceste mesaje ar trebui sa va ajute sa aflati de unde provine problema. Serverul lui Tobias nu are aceasta optiune.
De acum incolo, in acest capitol vom aborda configurarea clientilor NIS.
Primul pas este setarea in /etc/yp.conf a serverului NYS care va fi folosit. Ca exemplu, iata un fisier foarte simplu pentru un host din reteaua Winery:
Prima linie a fisierului specifica toti clientii NIS care apartin domeniului NIS winery. Daca omiteti acesta linie NYS va folosi numele de domeniu pe care l-ati setat cu comanda domainname. Mai departe se specifica serverul NIS care va fi folosit. Desigur, adresa IP a serverului vbardolino trebuie specificata in fisierul hosts; puteti dealtfel sa folositi direct adresa IP.
Din cauza comenzi server din fisierul de configurare de mai sus, NYS va folosi serverul specificat indiferent de domeniul NIS curent. Daca in mod frecvent se intampla sa mutati calculatorul in mai multe domenii NIS probabil ca veti dori sa pastrati in fisierul yp.conf informatiile referitoare la mai multe domenii NIS. De exemplu, in cazul unui laptop fisierul de mai sus ar putea fi modificat astfel:
Astfel laptopul va putea face parte din oricare dintre cele doua domenii, singura setare necesara fiind alegerea domeniului NIS cu ajutorul comenzii domainname.
Dupa ce ati creat acest fisier de configurare minimal si dupa ce ati verificat ca poate fi citit de catre toti utilizatorii, urmeaza sa faceti primul test : prima conectare la server. Alegeti orice map distribuit de server, de pilda hosts.byname, si incercati sa-l obtineti folosind utilitarul ypcat. La fel ca toate celelalte utilitare de adminstrare, ypcat ar trebui sa se gaseasca in /usr/sbin.
Output-ul pe care il veti obtine ar trebui sa arate in genul celui de mai sus. Insa, daca apare un mesaj de eroare ca ``Can't bind to server which serves domain'' sau altceva asemanator, inseamna ca fie numele domeniului NIS pe care l-ati setat nu corespunde nici unui server definit in yp.conf, fie ca serverul este inaccesibil dintr-un motiv oarecare. In al doilea caz, verificati daca ping raporteaza ca poate accesa serverul si daca da, verificati daca este intr-adevar vorba de un server NIS. Pentru acesta folositi rpcinfo care ar trebui sa afiseze un output de genul :
Dupa ce v-ati convins ca puteti contacta serverul NIS, trebuie sa decideti care fisiere sa le inlocuiti sau sa le intregiti cu map-uri NIS. In mod tipic, probabil ca veti dori sa folositi map-uri NIS pentru host si pentru passwd. Primul este util mai ales cand nu folositi BIND, iar al doilea permite tuturor utilizatorilor sa se conecteze de la orice host din retea; acesta necesita existenta unui director /home central, disponibil in toata reteaua prin NFS. In sectiunea - puteti gasi informatii detaliate despre cum se realizeaza aceasta. Alte map-uri, cum este services.byname, nu sunt la fel de spectaculoase, dar va pot scapa de ceva munca de editare in cazul in care instalati aplicatii de retea care folosesc un serviciu care nu este in fisierul services standard.
Probabil ca doriti sa puteti alege daca o functie foloseste fisierul local sau serverul NIS. NYS va permite sa configurati ordinea in care o functie acceseaza aceste servicii. Fisierul de configurare este /etc/nsswitch.conf (nss vine de lar Name Service Switch), dar bineinteles ca nu este limitat doar la name service. Acest fisier contine cate o linie pentru fiecare functie suportata de NYS.
Ordinea corecta a serviciilor depinde de tipul datelor. Este improbabil ca map-ul services.byname sa contina inregistrari diferite de cele din fisierul services local; poate eventual sa contina inregistrari in plus. Astfel, ar fi o alegere buna ca mai intai sa fie consultat fisierul local doar daca nu este gasit serviciul dorit sa se apeleze la NIS. Pe de alta parte, informatiile referitoare la hostnames se pot schimba foarte frecvent, astfel ca in general serverele DNS sau NIS detin cele mai actualizate informatii, pe cand fisierul hosts local este pastrat doar ca rezerva pentru cazul in care serverul DNS sau NIS pica. Astfel ca in aceste conditii este de dorit ca fisierul local sa fie consultat ultimul.
Exemplul de mai jos arata cum se pot configura functiile gethostbyname(2), gethostbyaddr(2) si getservbyname(2) ca sa functioneze in modul descris mai sus. Ele vor incerca initial primul serviciu; in cazul unui succes se returneaza rezultatul, altfel este incercat urmatorul serviciu.
Mai jos se gaseste lista completa a serviciilor care pot fi folosite cu o inregistrare in fisierul nsswitch.conf. Map-urile, fisierele, serverele si obiectele care vor fi consultate depind de numele inregistrarii.
In momemtul de fata, NYS suporta urmatoarele inregistrari in nsswitch.conf: hosts, networks, passwd, group, shadow, gshadow, services, protocols, rpc, si ethers. Probabil case vor mai adauga si altele.
Figura- ilustreaza un exemplu si mai complet care introduce o alta facilitate a nsswitch.conf: cuvantul-cheie [NOTFOUND=return] in inregistrarea hosts, datorita caruia daca nu este gasit elementul cautat, NYS va continua cu cautarea in fisierele locale numai daca consultarea serverelor NIS si DNS a esuat. Fisierele locale vor fi astfel folosite numai la bootare si ca o copie de siguranta pentru cazul cand serverul NIS nu este accesibil.
Figure: Sample nsswitch.conf file.????????????/
Unul dintre rolurile esentiale pa cere le joaca NIS este sincronizarea informatiilor despre utilizatori si conturile lor in cadrul domeniului NIS. In acest scop, se pastreaza de obicei un fisier /etc/passwd minimal la care se adauga informatiile din map-urile NIS (care sunt disponibile in tot domeniul). Simpla activare a acestora in nsswitch.conf nu este insa de ajuns.
Atunci cand folositi NIS pentru distribuirea informatiilor referitoare la parole trebuie mai intai sa va asigurati ca user id-urile utilizatorilor din fisierul passwd local corespund cu cele de pe serverul NIS.
Daca unul dintre id-urile numerice din /etc/passwd sau /etc/group difera de cel din map-uri va trebui sa modificati proprietarul (owner) pentru toate fisierele utilizatorului respectiv. Mai intai trebuie sa setati noile valori ale uid-urilor si gid-urilor in passwd respectiv group. Apoi localizati toate fisierele utilizatorului si le schimbati proprietarul (cu chown). Sa zicem ca news avea user id-ul 9, iar okir avea 103; daca aceasta valoare a fost modificata ar urma sa folositi urmatoarele comenzi:
Este important sa apelati aceste comenzi avind instalat noul fisier passwd si sa colectati toate numele fisierelor userului inainte de chown. Pentru a modifica apartenenta la grupuri a fisierelor se foloseste o comanda similara.
Dupa de ati facut aceasta, uid-urile si gid-urile numerice locale vor corespunde cu cele din intregul domeniu NIS. Urmatorul pas este adaugarea in nsswitch.conf a liniilor care activeaza localizarea prin NIS a informatiilor despre utilizatori si grupuri:
Ca efect, atunci cand un utilizator incearca sa se conecteze, comanda login sau alte comenzi asemanatoare vor consulta mai intii map-urile NIS si doar in caz de nereusita vor consulta fisierele locale. In general probabil ca veti scoate aproape toti userii din fisierele locale, lasind numai root si utilizatori generici cum este mail, si aceasta deoarece unele taskuri vitale ale sistemului ar putea necesita maparea uid-urilor cu numele utilizatorilor sau invers. De exemplu, uneori job-urile cron administrative executa comanda su pentru a deveni temporar news, iar subsistemul UUCP ar putea trimite prin mail un raport. Daca news si uucp nu exista in fisierul passwd local exista riscul ca aceste joburi sa esueze foarte urat daca NIS nu este disponibil in acel moment.
Ma simt dator sa dau aici doua avertismente importante: in primul rand, configurarile descrise mai sus functioneaza numai pentru suite login care nu folosesc shadow passwords ( cum este cea inclusa in pachetul util-linux ). Complicatiile aduse de folosirea parolelor shadow vor fi abordate in sectiunea urmatoare. In al doilea rand, comenzile de genul login nu sunt singurele care acceseaza fisierul passwd-- de pilda chiar si banalul ls face parte din aceasta categorie. De fiecare data cand este apelat ls cu optiunea -l (long listing), vor fi afisate numele simbolice pentru grupul si proprietarul fiecarui fisier, ceea ce implica de fiecare data o conectare la serverul NIS. Se poate intampla ca din acesta cauza viteza sa scada foarte mult, mai ales daca reteaua este supraincarcata sau daca, mai grav, serverul NIS nu este in aceeasi retea fizica si datagramele trebuie sa treaca printr-un router.
Si asta nu e totul. Imaginati-va ca un utilizator vrea sa-si schimbe parola. In mod normal, va apela passwd care citeste noua parola si modifica fisierul passwd local. Acest lucru este imposibil cand se foloseste NIS, deoarece fisierul nu mai este disponibil local, iar a permite utilizatorilor sa se conecteze la serverul NIS de fiecare data cand vor sa-si schimbe parola nu este o solutie. Din aceste motive NIS vine cu o versiune proprie a passwd numit yppasswd. Pentru a schimba parola pastrata pe server, yppasswd contacteza daemonul yppasswdd de pe server via RPC, si comunica noile informatii. Pentru a instala yppasswd peste programul passwd clasic se procedeaza in felul urmator:
De asemenea trebuie sa instalati pe server rpc.yppasswdd si sa-l porniti din rc.inet2. Astfel li se va ascunde utilizatorilor aceasta ciudatenie datorata NIS-ului.
Deocamdata nu exista suport NIS pentru site-uri care folosesc shadow pentru login. John F.-Haugh, autorul pachetului shadow, a lansat de curand pe comp.sources.misc o noua versiune a bibliotecii de functii shadow care suporta partial NIS, deci e incompleta si nu a fost inca in biblioteca C standard libc. Pe de alta parte, publicarea cu NIS a informatiilor din /etc/shadow contravine scopului pe care il are shadow !
Desi functiile NYS referitoare la password nu folosesc map-ul shadow.byname sau ceva similar, NYS permite in mod transparent folosirea unui fisier /etc/shadow. Cand este apelata implementarea NYS a functiei getpwnam sunt utilizate specificatiile din campul passwd din nsswitch.conf. Serviciul NIS va localiza informatiile cerute in map-ul passwd.byname de pe serverul NIS. Totusi, serviciul files va verifica existenta fisierului /etc/shadow, si daca il gaseste va incerca sa-l deschida. Daca nu exista sau daca userul nu este root, se va reveni la comportamentul clasic: cautarea informatiilor numai in /etc/passwd. Daca /etc/shadow exista si poate fi deschis, NYS va lua din shadow parola utlizatorului. Functia getpwuid este implementata in mod similar. Astfel, executabilele compilate cu NYS se vor descurca in mod transparent cu o configurare care foloseste shadow.
Daca folositi codul client inclus in versiunea standard curenta a libc, configurarea clientului NIS este un pic diferita. In primul rand, in loc sa obtina informatiile despre serverele NIS dintr-un fisier de configuratie, foloseste daemonul ypbind pentru localizarea serverelor active. Deci trebuie sa va asigurati ca ypbind este incarcat la bootare. ypbind trebuie rulat dupa setarea domeniului NIS si dupa ce a fost pornit portmapper-ul RPC. Apoi ar trebui sa testarea serverului cu ypcat.
De curand s-a raportat multe ori un bug care se manifesta prin aceea ca NIS esueaza returnind ``clntudp_create: RPC: portmapper failure - RPC: unable to receive''. Aceasta eroare se datoreaza unei modificari incompatibile a modului cum ypbind returneaza informatiile catre functiile de biblioteca. Daca obtineti ultimele surse ale utilitarelor NIS si le compilati ar trebui sa scapati de acesta problema.
De asemenea, modul in care NIS-ul traditional decide daca si cum sa faca imbinarea informatiilor NIS cu cele din fisierele locale difera fata de NYS. De exemplu, pentru a folosi map-uri password va trebui sa includeti urmatoarea linie in /etc/passwd:
Aceasta marcheaza locul unde functiile de localizare pentru password insereaza map-urile NIS. Inserarea unei linii similare (mai putin ultimele doua puncte) in /etc/group face acelati lucru pentru map-urile group.* . Pentru a distribui prin NIS map-urile hosts.* trebuie sa schimbati ordinea liniilor in host.conf file. De pilda, daca ordinea pe care o doriti este NIS, DNS, /etc/hosts s-ar putea sa fie nevoie sa modificati linia in
Implementarea NIS clasica nu suporta alte map-uri la acest moment.
