Setarea unui client NIS cu NYS

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 :

Alegerea map-urilor corecte

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.????????????/

Folosirea map-urilor passwd si group

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.

Folosirea NIS cu suport pentru Shadow

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.

Folosirea codului NIS traditional

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.