t7c14ce
De acum incolo, in acest capitol vom aborda configurarea clienþilor NIS.

Primul pas este setarea in /etc/yp.conf a serverului NYS care va fi folosit. Ca exemplu, iata un fiºier foarte simplu pentru un host din reþeaua Winery:

Prima linie a fiºierului specifica toþi clienþii NIS care aparþin domeniului NIS winery. Daca omiteþi acesta linie NYS va folosi numele de domeniu pe care l-aþi setat cu comanda domainname. Mai departe se specifica serverul NIS care va fi folosit. Desigur, adresa IP a serverului vbardolino trebuie specificata in fiºierul hosts; puteþi dealtfel sa folosiþi direct adresa IP.

Din cauza comenzi server din fiºierul de configurare de mai sus, NYS va folosi serverul specificat indiferent de domeniul NIS curent. Daca in mod frecvent se intampla sa mutaþi calculatorul in mai multe domenii NIS probabil ca veþi dori sa pastraþi in fiºierul yp.conf informaþiile referitoare la mai multe domenii NIS. De exemplu, in cazul unui laptop fiºierul 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 aþi creat acest fiºier de configurare minimal ºi dupa ce aþi verificat ca poate fi citit de catre toþi utilizatorii, urmeaza sa faceþi primul test : prima conectare la server. Alegeþi orice map distribuit de server, de pilda hosts.byname, ºi incercaþi sa-l obþineþi 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 veþi obþine 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-aþi setat nu corespunde nici unui server definit in yp.conf, fie ca serverul este inaccesibil dintr-un motiv oarecare. In al doilea caz, verificaþi daca ping raporteaza ca poate accesa serverul ºi daca da, verificaþi daca este intr-adevar vorba de un server NIS. Pentru acesta folosiþi rpcinfo care ar trebui sa afiºeze un output.

Alegerea map-urilor corecte
Dupa ce v-aþi convins ca puteþi contacta serverul NIS, trebuie sa decideþi care fiºiere sa le inlocuiþi sau sa le intregiþi cu map-uri NIS. In mod tipic, probabil ca veþi dori sa folosiþi map-uri NIS pentru host ºi pentru passwd. Primul este util mai ales cand nu folosiþi BIND, iar al doilea permite tuturor utilizatorilor sa se conecteze de la orice host din reþea; acesta necesita existenþa unui director /home central, disponibil in toata reþeaua prin NFS. In secþiunea - puteþi gasi informaþii 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 instalaþi aplicaþii de reþea care folosesc un serviciu care nu este in fiºierul services standard.

Probabil ca doriþi sa puteþi alege daca o funcþie foloseºte fiºierul local sau serverul NIS. NYS va permite sa configuraþi ordinea in care o funcþie acceseaza aceste servicii. Fiºierul de configurare este /etc/nsswitch.conf (nss vine de lar Name Service Switch), dar bineinþeles ca nu este limitat doar la name service. Acest fiºier conþine cate o linie pentru fiecare funcþie suportata de NYS.

Ordinea corecta a serviciilor depinde de tipul datelor. Este improbabil ca map-ul services.byname sa conþina inregistrari diferite de cele din fiºierul services local; poate eventual sa conþina inregistrari in plus. Astfel, ar fi o alegere buna ca mai intai sa fie consultat fiºierul local doar daca nu este gasit serviciul dorit sa se apeleze la NIS. Pe de alta parte, informaþiile referitoare la hostnames se pot schimba foarte frecvent, astfel ca in general serverele DNS sau NIS deþin cele mai actualizate informaþii, pe cand fiºierul hosts local este pastrat doar ca rezerva pentru cazul in care serverul DNS sau NIS pica. Astfel ca in aceste condiþii este de dorit ca fiºierul local sa fie consultat ultimul.

Exemplul de mai jos arata cum se pot configura funcþiile gethostbyname(2), gethostbyaddr(2) ºi getservbyname(2) ca sa funcþioneze in modul descris mai sus. Ele vor incerca iniþial primul serviciu; in cazul unui succes se returneaza rezultatul, altfel este incercat urmatorul serviciu.

Mai jos se gaseºte lista completa a serviciilor care pot fi folosite cu o inregistrare in fiºierul nsswitch.conf. Map-urile, fiºierele, serverele ºi obiectele care vor fi consultate depind de numele inregistrarii.

In momemtul de faþa, NYS suporta urmatoarele inregistrari in nsswitch.conf: hosts, networks, passwd, group, shadow, gshadow, services, protocols, rpc, ºi ethers. Probabil case vor mai adauga ºi altele.

Figura- ilustreaza un exemplu ºi mai complet care introduce o alta facilitate a nsswitch.conf: cuvantul-cheie aNOTFOUND=returni in inregistrarea hosts, datorita caruia daca nu este gasit elementul cautat, NYS va continua cu cautarea in fiºierele locale numai daca consultarea serverelor NIS ºi DNS a eºuat. Fiºierele locale vor fi astfel folosite numai la bootare ºi ca o copie de siguranþa pentru cazul cand serverul NIS nu este accesibil.

Folosirea map-urilor passwd ºi group
Unul dintre rolurile esenþiale pa cere le joaca NIS este sincronizarea informaþiilor despre utilizatori ºi conturile lor in cadrul domeniului NIS. In acest scop, se pastreaza de obicei un fiºier /etc/passwd minimal la care se adauga informaþiile din map-urile NIS (care sunt disponibile in tot domeniul). Simpla activare a acestora in nsswitch.conf nu este insa de ajuns.

Atunci cand folosiþi NIS pentru distribuirea informaþiilor referitoare la parole trebuie mai intai sa va asiguraþi ca user id-urile utilizatorilor din fiºierul 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 modificaþi proprietarul (owner) pentru toate fiºierele utilizatorului respectiv. Mai intai trebuie sa setaþi noile valori ale uid-urilor ºi gid-urilor in passwd respectiv group. Apoi localizaþi toate fiºierele utilizatorului ºi le schimbaþi 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 folosiþi urmatoarele comenzi:

Este important sa apelaþi aceste comenzi avind instalat noul fiºier passwd ºi sa colectaþi toate numele fiºierelor userului inainte de chown. Pentru a modifica apartenenþa la grupuri a fiºierelor se foloseºte o comanda similara.

Dupa de aþi facut aceasta, uid-urile ºi 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 informaþiilor despre utilizatori ºi grupuri:

Ca efect, atunci cand un utilizator incearca sa se conecteze, comanda login sau alte comenzi asemanatoare vor consulta mai intii map-urile NIS ºi doar in caz de nereuºita vor consulta fiºierele locale. In general probabil ca veþi scoate aproape toþi userii din fiºierele locale, lasind numai root ºi utilizatori generici cum este mail, ºi 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 ºi uucp nu exista in fiºierul passwd local exista riscul ca aceste joburi sa eºueze 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 funcþioneaza numai pentru suite login care nu folosesc shadow passwords ( cum este cea inclusa in pachetul util-linux ). Complicaþiile aduse de folosirea parolelor shadow vor fi abordate in secþiunea urmatoare. In al doilea rand, comenzile de genul login nu sunt singurele care acceseaza fiºierul passwd-- de pilda chiar ºi banalul ls face parte din aceasta categorie. De fiecare data cand este apelat ls cu opþiunea -l (long listing), vor fi afiºate numele simbolice pentru grupul ºi proprietarul fiecarui fiºier, 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 reþeaua este supraincarcata sau daca, mai grav, serverul NIS nu este in aceeaºi reþea fizica ºi datagramele trebuie sa treaca printr-un router.

ªi asta nu e totul. Imaginaþi-va ca un utilizator vrea sa-ºi schimbe parola. In mod normal, va apela passwd care citeºte noua parola ºi modifica fiºierul passwd local. Acest lucru este imposibil cand se foloseºte NIS, deoarece fiºierul nu mai este disponibil local, iar a permite utilizatorilor sa se conecteze la serverul NIS de fiecare data cand vor sa-ºi schimbe parola nu este o soluþie. 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, ºi comunica noile informaþii. Pentru a instala yppasswd peste programul passwd clasic se procedeaza in felul urmator:

De asemenea trebuie sa instalaþi pe server rpc.yppasswdd ºi sa-l porniþi din rc.inet2. Astfel li se va ascunde utilizatorilor aceasta ciudaþenie datorata NIS-ului.