Page 1

Cap. 1. Introducere în reţele; Cuprins Reţele TCP/IP Codul de Networking Intreţinerea sistemului Privire generală peste capitolele următoare

Reţele TCP/IP Alte tipuri de hardware In retelele mari, cum este cea a Universitatii Groucho Marx, de obicei nu se folosesc numai echipamente Ethernet. La Groucho Markx University, LAN-ul fiecarui departament este legat la magistrala campusului, care este un cablu de fibra optica pe care ruleaza FDDI (Fiber Distributed Data Interface). FDDI foloseste o abordare cu totul diferita de transmitere a datelor care presupune in esenta trimiterea unui numar de tokenuri, iar o statie de lucru poate trimite un frame numai daca captureaza un token. Principalul avantaj al FDDI este viteza de pina la 100-Mbps si lungimea maxima a cablului de 200 km. Pentru legaturile la distante foarte mari, echipamentele folosite cel mai frecvent se bazeaza pe standardul X.25. Multe retele publice numite Public Data Networks ofera acest serviciu, cum sunt Tymnet in SUA, sau Datex-P in Germania. X.25 necesita un echipament special, un Packet Assembler/Disassembler sau PAD. X.25 defineste un set de protocoale proprii, dar in general este folosit la legarea retelelor TCP/IP sau a altor tipuri de retele. Din moment ce pachetele IP nu pot fi trimise ca atare prin X.25 (si viceversa), pachetele IP sunt intii incapsulate in pachete X.25 si de-abia apoi trimise prin retea De obicei radio amatorii isi folosesc echipamentele si la legarea in retea a calculatoarelor; echipamantele se numesc packet radio sau ham radio. Protocolul folosit este AX.25, si are la origine X.25. O alta modalitate este folosirea liniilor seriale pentru dial-up, linii care, desi lente, sunt ieftine. Pentru transmiterea pachetelor se folosesc protocoalele SLIP sau PPP, care vor fi descrise putin mai incolo.

Protocolul Internet Bine-nteles, nu este de dorit ca o retea sa fie limitata la o singura retea Ethernet. Ideal ar fi ca o retea sa functioneze la fel indiferent de hardware, si de asemenea sa nu conteze din cite subunitati este constituita. De exemplu, in retelele mari cum este cea de la Groucho Marx University, exista de obicei mai multe retele Ethernet separate care trebuie conectate. La GMU, departamentul de matematica foloseste doua retele Ethernet separate: o retea de calculatoare rapide pentru profesori si absolventi, si o retea de calculatoare lente pentru studenti. Ambele sunt legate la magistrala FDDI a campusului.


Aceasta legatura este controlata de un host special destinat, asa-numitul gateway, care gestioneaza traficul pachetelor intre cele doua retele Ethernet si magistrala. De exemplu, daca sunteti la departamentul de matematica si vreti sa accesati hostul quark din reteaua departamentului de fizica, software-ul de retea nu poate trimite pachetele direct catre quark deoarece este intr-o alta retea. De aceea, gateway-ul trebuie sa indeplineasca functia de forwarding (trimiterea mai departe a pachetelor destinate altei retele). Gateway-ul (numit sophus) trimite pachetele catre gateway-ul pereche niels prin intermediul magistralei, iar niels le depune la destinatie. Fluxul datelor intre erdos si quark este ilustrat in figura Fig. 1-1 Fig. 1-1. Cei trei pasi ai trimiterii unei datagrame de la erdos la quark.

Aceasta schema de redirectare a datelor catre remote host se numeste routing, iar pachetele sunt numite in acest context datagrame. Pentru simplificare, traficul de datagrame este guvernat de un singur singur protocol, independent de hardware-ul folosit: IP, sau Internet Protocol. In capitolul Cap. 2, vom aborda mai in detaliu protocolul IP si routarea. Principalul avantaj al IP-ului este ca transforma retele diferite din punct de vedere al hardware-ului intr-o retea aparent omogena, de tip internet. Trebuie observata diferenta subtila dintre o retea internet and Internet. "Internet" este numele oficial al unei anumite retele globale de tip internet. Bine-nteles, IP necesita o schema de adresare independenta de hardware. Aceasta se realizeaza prin alocarea unui numar de 32 de biti fiecarui host, numar numit adresa IP. Adresele IP se scriu de obicei ca un set de patru numere de cite 8 biti, separate prin puncte. De examplu, quark ar putea avea adresa IP 0x954C0C04, care se poate scrie 149.76.12.4. Acest format este numit "dotted quad notation". Veti observa ca acum avem trei tipuri diferite de adrese: hostname-urile ( cum e quark ), apoi adresele IP, si in final adresele hardware (cum sunt adresele Ethernet de 6 bytes). Toate trebuie sa se potriveasca, astfel incit daca introduceti rlogin quark, software-ul de retea sa poata obtine adresa IP a lui quark; iar cind datele ajung in reteaua departamentului de fizica, trebuie cumva determinata adresa Ethernet care corespunde adresei IP. Aceasta poate produce o oarecare confuzie. Nu vom intra in detalii chiar acum, ci un pic mai incolo, in capitolul Cap. 2. Deocamdata este suficient sa retineti ca exista doi pasi ai regasirii adreselor : hostname resolution (determinarea adresei IP corespunzatoare unui hostname) si address resolution (gasirea adresei hardware care corespunde adresei IP).

Protocolul IP peste liniile seriale In cazul liniilor seriale cel mai adesea se foloseste standardul SLIP (Serial Line IP). O varianta a SLIP-ului este CSLIP (compressed SLIP) care realizeaza o compresie a headerelor IP pentru a folosi cit mai eficient liniile seriale cu o latime de banda relativ mica. Un alt protocol serial este PPP, sau Point-to-Point Protocol. PPP are multe optiuni in plus fata de SLIP, legatura incluzind si o faza de negociere. Principalul avantaj fata de SLIP este acela ca


nu este limitat la transportul datagramelor IP, ci a fost proiectat sa permita transmiterea si a altor tipuri de datagrame.

Protocolul de Control al Transmisiei (TCP) Trimiterea datagramelor de la un host la altul nu este singura problema. Daca va logati la quark, doriti bine-nteles ca legatura sa fie sigura intre procesul rlogin de pe erdos si shell-ul de pe quark. Informatiile transferate trebuie sa fie impartite in pachete de catre expeditor si reasamblate la loc la destinatie. De-ti pare banal, aceasta presupune o serie de operatii stufoase. Este important de stiut ca IP nu este, prin conceptie, un protocol sigur. Sa zicem ca zece useri de pe reteaua locala incep sa-si copieze de pe serevrul FTP de la GMU ultima versiune de XFree86. Traficul astfel generat s-ar putea sa fie prea mare pentru gateway, deoarece acesta poate sa fie prea lent sau sa nu aiba memorie suficienta. Daca in aceste conditii trimiteti un pachet catre quark, sophus poate sa nu aiba in acel moment spatiu in buffer si sa nu poata retransmite pachetul. IP rezolva acesta problema simplu: leapada pachetul, care este iremediabil pierdut. Responsabilitatea de a verifica integritatea datelor si de a le retransmite in caz de eroare cade tot in sarcina software-ului de retea. Acesta functie este indeplinita de un alt protocol : TCP, sau Transmission Control Protocol, care realizeaza un serviciu sigur pe baza lui IP. Caracteristica esentiala a TCP este aceea ca foloseste IP pentru a crea iluzia unei conexiuni simple intre procesul local si cel de pe remote host, astfel ca nu mai trebuie sa va intrebati cum si pe unde trec datele. O conexiune TCP este in esenta ca o conducta (pipe) bidirectionala la care procesele scriu si de la care citesc. Se aseamana cu o convorbire telefonica. Protocolul TCP identifica cele doua capete ale conexiunii cu ajutorul adreselor IP ale celor doua host-uri si al asa-numitelor port-uri folosite pe fiecare host. Orice conexiune de retea se leaga la un host prin intermediul unui port. Daca vom continua analogia cu convorbirea telefonica, putem compara adresele IP cu prefixele telefonice si porturile cu numerele de telefon. In exemplul cu rlogin, aplicatia client (rlogin) deschide un port la erdos si se conecteaza la quark folosind portul 513 pe care "asculta" serverul rlogind. Astfel se realizeaza o conexiune TCP. Pe baza acestei conexiuni rlogind verifica mai intii numele si parola, iar apoi lanseaza in executie shell-ul. Intrarea si iesirea standard a shell-ului sunt redirectate prin conexiunea TCP, astfel ca orice se introduce de la hostul local se transmite prin conexiune si ajunge ca intrare standard pentru shell.

Protocolul Datagrame Utilizator (UDP) TCP nu este singurul protocol folosit in retelele TCP/IP Desi este potrivit pentru aplicatii ca rlogin, pentru altele ( de exemplu NFS) se dovedeste a fi ineficient. In aceste cazuri este folosit un protocol pereche al TCP-ului, numit UDP, (de la User Datagram Protocol). La fel ca TCP, UDP permite unei aplicatii sa contacteze un serviciu de pe un anumit port al remote hostului, insa nu creaza o legatura permanenta, ci permite trimiterea unui singur pachet catre serviciul destinatie -- de unde si numele sau.


Sa zicem ca ati montat ierarhia de directoare ale lui TeX de pe serverul NFS central al departamentului, galois, si ca vreti sa cititi un document care descrie cum se foloseste LaTeX. Intrati intr-un editor care initial incarca tot fisierul. Stabilirea unei conexiuni TCP cu galois, trimiterea fisierului, si terminarea conexiunii ar dura prea mult timp, si atunci se trimite o cerere catre galois care trimite fisierul intr-un set de pachete UDP - ceea ce dureaza mult mai putin. UDP nu a fost gindit sa verifice pierderea sau coruperea pachetelor, asa ca aplicatia (in cazul acesta NFS) trebuie si se descurce singura.

Mai multe despre porturi Porturile pot fi vizualizate ca puncte de atasare ale conexiunilor de retea. Daca o aplicatie ofera un anumit serviciu, se ataseaza la un port si asteapta clienti (asta se numeste "ascultarea" portului - listening). Un client care vrea sa folosesca serviciul aloca un port de pe local host si se conecteaza la portul serverului de pe remote host. O proprietate importanta a porturilor este ca odata ce s-a facut conexiunea dintre client si server, o alta copie a serverului se poate atasa la port si poate primi noi clienti. Aceasta permite de pilda mai multe rlogin-uri la acelasi host, toate folosind portul 513. TCP poate distinge aceste conexiuni dupa host-ul de la care provin. De exemplu, daca se fac doua conectari la quark de la erdos, primul client rlogin foloseste, sa zicem, portul local 1023 iar al doilea portul 1022. Ambele se vor conecta insa la acelasi port 513 de pe quark. Acest exemplu arata folosirea porturilor ca puncte de intilnire unde clientul contacteaza un anumit port pentru a obtine un anumit serviciu. Pentru ca un client sa stie portul corect, este nevoie de o intelegere intre administratorii ambelor sisteme. Pentru serviciile folosite pe scara larga, ca rlogin, numerele porturilor trebuie administrate central. Acest lucru il face IETF (Internet Engineering Task Force), care lanseaza periodic un RFC intitulat Assigned Numbers in care sunt descrise, printre altele, porturile alocate serviciilor folosite frecvent. Linux foloseste un fisier de mapare a serviciilor cu numerele porturilor : /etc/services. Acest fisier este descris in sectiunea Desi atit conexiunile TCP cit si cele UDP de bazeaza pe aceleasi porturi, nu se creaza nici un conflict intre ele. Astfel, de exemplu portul TCP 513 este diferit de portul UDP 513 si corespund unor servicii diferite : rlogin (513/TCP) si rwho (513/UDP).

Biblioteca Socket La cele mai multe sisteme de operare, software-ul care realizeaza toate functiile legate de retea este inclus in kernel, si la fel se intimpla si in cazul Linux-ului. Interfata de programare cel mai des intilnita pe plan mondial este Berkeley Socket Library. Numele provine din analogia porturilor cu niste mufe (socket=mufa,fasung,racord) la care se racordeaza conexiunile de retea. Biblioteca Socket pune la dispozitie call-ul bind(2) pentru a specifica remote host-ul, protocolul de transport si un serviciu la care se poate conecta un program sau pe care poate "asculta" (folosind connect(2), listen(2), si accept(2)). Biblioteca socket are un caracter mai general, deoarece nu contine doar clasa de baza pentru TCP/IP-based sockets (socket-urile AF_INET ), ci si o clasa pentru conexiunile cu local host-ul (clasa AF_UNIX). Unele implementari mai includ si alte clase, protocolul XNS (Xerox Networking System), sau X.25.


In cazul de fata, biblioteca socket face parte din biblioteca standard libc. Acum suporta numai socket-urile AF_INET si AF_UNIX, dar se fac eforturi in directia suportarii protocoalelor Novell, asa ca in final vor mai fi adaugate citeva clase.

Codul de Networking Fiind rezultatul muncii a multor programatori din intreaga lume, sistemul de operare Linux nar fi putut fi realizat fara reteaua globala. Astfel nu are de ce sa ne surprinda faptul ca inca de la inceput s-a muncit la capacitatea sistemului de operare de a lucra in retea. O implementare UUCP a functionat chiar de la inceput, iar lucrul la suportul de TCP/IP a inceput in toamna anului 1992, cind Ross Biro si altii au creat ceea ce acum se cunoaste sub numele de Net-1. Dupa ce Ross si-a incetat participarea activa in mai 1993, Fred van Kempen a inceput munca la o noua implementare, rescriind partile principale ale codului. Efortul sau s-a materializat in versiunea Net-2. Prima lansare publica a avut loc in vara anului 1992 (odata cu kernelul 0.99.10), iar apoi codul a fost intretinut si extins de mai multi, printre care Alan Cox, versiunea rezultata fiind denumita Net-2Debugged. Dupa numeroase imbunatatiri si depanari, codul si-a schimbat numele in Net-3 dupa lansarea kernelului 1.0 . Aceasta este dealtfel versinea inclusa in kernelurile oficiale. Net-3 ofera drivere pentru o gama larga de placi Ethernet, pentru SLIP (destinat utilizarii liniilor seriale) si pentru PLIP (pentru liniile paralele). Net-3 vine cu o implementare TCP/IP care se comporta foarte bine in retelele locale (LAN). Dezvoltarea actuala se indreapta catre stabilizarea necesara pentru a putea fi rulat pe hosturi Internet. Pe linga aceste facilitati mai exista si alte proiecte. Un driver pentru PPP (point-to-point protocol, o alta modalitate pentru folosirea liniilor seriale), este acum in faza Beta, iar driverul AX.25 pentru ham radio este in faza Alpha. Alan Cox a mai implementat un driver pentru protocolul IPX de la Novell, insa efortul de a realiza un set de programe pentru compatibilitatea cu retelele Novell stagneaza deocamdata din cauza companiei Novell care nu pune la dispozitie documentatia necesara. Un alt proiect promitator este samba, un server NetBIOS pentru Un*x, scris de Andrew Tridgell.

Diferite linii de dezvoltare Intre timp, Fred si-a continuat munca, ajungind la versiunea Net-2e care se caracterizeaza printr-un design mult imbunatatit al interfetei de programare. Acum, in momentul in care scriu aceasta documentatie, Net-2e este inca in faza Beta. Una dintre cele mai interesante noutati cu care vine Net-2e este incorporarea DDI-ului ( Device Driver Interface ). DDI permite o metoda uniforma de acces si de configurare a tuturor driverelor si a protocoalelor de retea. O alta implementare TCP/IP a fost realizata de catre Matthias Urlichs, care a scris un driver ISDN pentru Linux si FreeBSD. El a inclus in kernel o parte din codul de networking al BSDului. Deocamdata se poate prevedea ca Net-3 va continua sa fie folosit inca mult timp de-acum incolo. Alan lucreaza la implementarea protocolului AX.25 folosit de catre radioamatori. Fara indoiala, introducerea suportului pentru module va imprima un nou impuls codului de networking. Modulele vor permite incarcarea driverelor din mers (la run-time).


Desi aceste implementari diferite ale codului de networking ofera aceleasi servicii, exista diferente majore intre ele la nivelul kernelului si al driverelor. De accea un sistem pe care ruleaza un kernel cu Net-2e nu poate fi configurat si folosit cu utilitarele destinate versiunii Net-2d sau Net-3. Aceasta se aplica numai pentru comenzile care folosesc indeaproape anumite particularitati ale kernelului; aplicatiile si comenzile obisnuite (ca rlogin sau telnet) functioneaza indiferent de implementare. Cu toate acestea, toate aceste versiuni diferite ale codului de networking n-ar trebui sa va nelinisteasca. Daca nu participati activ la dezvoltarea de cod, nu va faceti probleme in legatura cu ce versiune de TCP/IP folositi! Kernelurile lansate oficial vor fi insotite intotdeauna de un set de utilitare compatibile cu codul de networking inclus.

De unde se poate obtine codul Ultima versiune a codului de retea poate fi obtinuta prin anonymous FTP de pe numeroase site-uri. Site-ul FTP oficial pentru Net-3 este sunacm.swan.ac.uk, al carui mirror se poate gasi la sunsite. Ultimul kit Net-2e patch si executabilele sunt disponibile la ftp.aris.com. Codul derivat pentru BSD al lui Matthias Urlich se poate lua de aici. Ultimele kerneluri se gasesc aici; sunsite and tsx-11.mit.edu au mirror-uri ale acestui director.

Intreţinerea sistemului Pe tot cuprinsul acestei cărţi ne vom ocupa în principal cu chestiuni de instalare şi configurare. Administrarea sistemului constă din mult mai mult decât atât. După configurarea unui anumit serviciu, trebuie să-l ţineţi în funcţiune. Pentru cele mai multe servicii foarte puţină muncă este necesară, însă unele servicii, ca de exemplu serviciile de ???mail??? şi de ???news??, necesită executarea unor acţiuni de rutină pentru a ţine sistemul la zi. Vom discuta aceste acţiuni în capitolele ce vor urma. Minimul absolut în întreţinerea sistemului este verificarea regulată de erori şi de evenimente neobişnuite a fişierelor log ale aplicaţiilor. Foarte practic este să scrieţi nişte scripturi administrative şi să le rulaţi din cron periodic. Distribuţia sursă a unora din aplicaţiile majore, ca de exemplu ???smail??? sau ???C-News???, conţin asemenea scripturi. Tot ce vă rămâne de făcut este să le adaptaţi nevoilor şi preferinţelor dumneavoastră. Ieşirea oricărui job cron va fi trimisă prin mail către un cont administrativ. Implicit, multe aplicaţii vor trimite rapoarte de eroare sau statistici despre utilizare către contul de root. Aceasta are sens numai dacă vă logaţi ca root frecvent; o idee mult mai bună este să retrimiteţi mail-ul root-ului catre contul personal prin crearea unui alias, aşa cum este descris în capitolul ???. Insă oricât de atent va-ţi configurat sistemul, legile lui Murphy garantează că vor apărea probleme. Astfel administrarea unui sistem înseamnă şi disponibilitatea pentru plângeri. De obicei utilizatorii se aşteaptă ca administratorul de sistem să fie de găsit prin mail ca şi root, dar sunt şi alte adrese care sunt folosite pentru a ajunge la persoane responsibile cu diferite aspecte ale administrării. De exemplu, plângerile despre funcţionarea incorectă a serviciului de mail vor fi trimise de obicei către postmaster; iar problemele cu serverul de news vor fi trimise către newsmaster sau Usenet. Mail-ul către hostmaster va trebui redirecţionat către


persoana care se ocupă cu servicile de reţea de bază sau de serviciul DNS dacă rulaţi un server de nume (name server).

Securitatea sistemului Un aspect foarte important al administrării sistemului dintr-o reţea este protejarea lui de intruderi. Sistemele administrate neatent oferă răuvoitorilor multe ţinte: atacurile merg de la ghicirea parolei până la "spionarea" pachetelor dintr-o reţea Ethernet şi pagubele cauzate de aceste atacuri merg de la date pierdute la violarea intimităţii utilizatorilor. Vom menţiona unele probleme particulare când vom discuta contextul în care pot apărea şi, în unele cazuri, posibile apărări împotriva acestor atacuri. In această secţiune vom discuta câteva exemple şi tehnici de bază referitoare la securitatea sistemului. Desigur, discuţia nu poate trata toate problemele legate de securitate pe care le puteţi întălni; ea foloseşte mai degrabă la ilustrarea problemelor ce pot apărea. Astfel este absolut necesară citirea unei cărţi bune despre securitate în special pentru un sistem aflat în reţea. Cartea lui Simon Garfinkel, "Practical UNIX Security" este recomandată. Securitatea sistemului porneşte de la o bună administrare a lui. Aceasta include verificarea proprietarului şi permisiunilor pentru toate fişierele şi directoarele vitale, monitorizarea folosirii conturilor privilegiate, etc. Programul COPS, de exemplu, vă va verifica sistemul de fişiere precum şi fişierele de configurare cele mai comune. De asemenea este recomandabil să obligaţi utilizatorii să-şi seteze parole cât mai greu de ghicit. De exemplu programul uzual pentru schimbarea parolei cere ca parola să aibă cel puţin cinci caractere şi să conţină atât litere cât şi cifre sau caractere speciale. Când faceţi un serviciu accesibil prin reţea, asiguraţi-vă că îi daţi cel mai mic privilegiu, adică că nu îi permiteţi să facă lucruri ce nu-i sunt necesare pentru a funcţiona aşa cum trebuie. De exemplu n-ar trebui să faceţi executabile setuidate??? root decât când este neapărat necesar. De asemenea, dacă vreţi să utilizaţi un serviciu pentru o aplicaţie foarte limitată, nu ezitaţi să-l configuraţi cât mai restrictiv cu putinţă. De exemplu dacă aveţi maşini fără disk în reţea şi vreţi să le lăsaţi să booteze de pe maşina dumneavoastră, trebuie să folosiţi serviciul TFTP (trivial file transfer protocol) astfel încât clienţii să poată descărca fişierele de configurare de bază din directorul /boot. Insă, când nu este restricţionat, TFTP lasâ orice utilizator din lume să descarce orice fişier cu drept de citire. Dacă nu vreţi aceasta, de ce să nu restricţionaţi serviciul TFTP numai la directorul /boot? In aceeaşi ordine de idei, e bine să restricţionaţi anumite servicii la utilizatori de pe anumite maşini, de exemplu din reţeaua locală. In capitolul ???, vom introduce tcpd care face acest lucru pentru o mulţime de aplicaţii de reţea. Alt punct important este să evitaţi aplicaţiile "periculoase". Desigur, orice aplicaţie poate fi periculoasă, deoarece poate avea "scame" pe care oamenii deştepţi le pot exploata pentru a căpăta acces la sistemul dumneavoastră. Lucruri ca acestea se întâmplă şi nu există protecţie completă împotriva lor. Această problemă afectează atât software-ul liber cât şi software-ul comercial. Insă programele care necesită privilegii sporite sunt mai periculoase decât celelalte din cauzâ câ orice scamă poate avea efecte drastice. Dacă instlaţi un program pentru reţea, setuidat, fiţi de două ori mai atent că nu vă scapă nimic de la documentaţie, astfel încâat să nu creaţi o nişă de securitate din greşeală.


Nu puteţi şti niciodată dacă precauţiile dumneavoastră vor da greş indiferent de cât de atent aţi fost. Verificarea regulată a logurilor este un punct bun de plecare, dar intruderul este probabil suficient de deştept încât să creadă orice urmă. Insă, există unelte ca tripwire??? care vă permit să verificaţi fişierele vitale pentru a vedea dacă conţinutul şi permisiunile s-au schimbat. Tripwire calculează diferite sume de control pentru aceste fiăiere şi le păstrează într-o bază de date. In timpul rulărilor succesive, sumele de control sunt recaluclate şi comparate ce cele păstrate pentru a detecta orice modificare.

Privire generală peste capitolele următoare Capitolele următoare se vor ocupa cu configurarea Linux-ului pentru reţele TCP/IP şi cu configurarea unor aplicaţii majore. Inainte să; ne murdărim măinile cu editarea fişierelor şi alte chestii asemă;nătoare, vom examina, în Cap. 2, mai cu atenţie, protoculul IP. Dacă ştiţi deja cum funcţionează routarea IP şi cum se face găsirea adreselor, puteţi sări direct la capitolul următor. Capitolul se ocupă cu configurările de bază, ca de exemplu compilarea unui kernel şi configurarea plăcii Ethernet. Configuraţia porturilor seriale este tratată într-un capitol separat, din cauză că discuţia nu se aplică numai reţelelor TCP/IP dar este relevantă pentru UUCP. Capitolul se ocupă cu configurarea unei maşini pentru o reţea TCP/IP. El conţine informaţii pentru instalarea unor gazde fără reţea externa şi a unor gazde conectate la o reţea Ethernet. Acesta este urmat de două capitole care vă invaţă cum să folosiţi SLIP şi PPP. Capitolul Cap. 3 explică cum să stabiliţi o conexiune SLIP şi vă oferă referinţe detaliate despre dip, o unealtă care vă permite să automatizaţi cei mai mulţi paşi. Capitolul Cap. 4 acoperă PPP şi pppd, demonul PPP de care veţi avea nevoie. Capitolul vă oferă o scurtă introducere în configurarea celor mai importante aplicaţii pentru reţea precum rlogin,rcp, etc. De asemenea se discută serviciile ce sunt manevrate de superserverul inetd şi cum puteţi restricţiona anumite servicii. Capitolul vă oferă informaţii preţioase despre administrarea programului Taylor UUCP care este o implementare free a suitei UUCP. Restul cărţii se ocupă cu un studiu detaliat al poştei electronice si al serviciului de ştiri. Capitolul introduce conceptele de bază ale poştei electronice precum forma unei adrese de mail şi cum funcţionează sistemul furnizării e-mailurilor către destinaţie. Capitolele şi acoperă configurarea programelor smail şi sendmail. Această carte le explică pe amândouă deoarece smail e mai uşor de instalat pentru începători în vreme ce sendmail este mai flexibil. Capitolele şi explică felul cum ştirile sunt manevrate un Usenet şi cum puteţi instala şi folosi C-news, un pachet software popular pentru manevrarea ştirilor Usenet. Capitolul acoperă pe scurt configurarea demonului NNTP pentru a facilita accesarea ştirilor din reţeau dumneavoastră locală. In sfârşit, capitolul vă învaţă cum să configuraţi şi să întreţineţi diferite programe de citit ştiri.


Cap. 2. Ideile principale pentru reţelele TCPIP Cuprins Interfeţe de reţea Adrese IP Căutarea adreselor Rutarea IP Vom intra acum in amanuntele de care veţi avea nevoie când vă veţi conecta calculatorul la o reţea TCP/IP. Astfel vom discuta despre adrese IP, nume de gazdă precum vom discuta şi câteva chestii despre rutare. Acest capitol vă va oferi informaţiile de bază de care aveţi nevoie pentru a înţelege configuraţia pe care doriţi să o realizaţi, în timp ce capitolele următoare se vor ocupa de instrumentele necesare pentru realizarea configuraţiei dorite.

Interfeţe de reţea Pentru a ascunde diversitea echipamentelor ce pot fi folosite intr-o reţea, TCP/IP defineşte o interfaţă abstractă prin care sunt accesate dispozitivele fizice (hardware). Această interfaţa oferă o mulţime de operaţii care sunt identice pentru toate tipurile de dispozitive fizice şi care în principal se ocupă cu primirea şi trimiterea pachetelor. Fiecărui dispozitiv periferic pe care veţi vrea să-l folosiţi pentru reţea, îi va corespunde o interfaţă in nucleu. De exemplu interfeţele Ethernet se numesc eth0 şi eth1 iar interfeţele SLIP se numesc sl0, sl1, etc. Aceste nume de interfeţe sunt folosite pentru configurare, şi anume atunci când veţi vrea să vă referiţi la un dispozitiv fizic particular. Ele nu au nici o însemnătate mai presus de aceasta. Pentru a putea fi folosită intr-o reţea TCP/IP, o interfaţa trebuie să aibă asociată o adresă IP care foloseşte pentru identificarea interfeţei respective când comunică cu restul lumii. Această adresă este diferită de numele interfeţei pe care l-am menţionat adineauri; dacă comparăm o interfaţă cu o uşă, atunci adresa ei este ca plăcuţa cu numele lipită pe ea. Desigur sunt şi alţi parametri ai dispozitivului care pot fi setaţi; unul dintre aceştia este mărimea maximă a unei datagrame ce poate fi procesată de un anumit dispozitiv hardware, care se mai numeşte şi MTU (Maximal Transfer Unit). Vom introduce mai târziu şi alte caracteristici ale dispozitivelor de reţea.

Adrese IP Precum am menţionat în capitolul precedent, adresele folosite în protocolul IP sunt numere pe 32 de biţi. Fiecare maşonă trebuie să aibă un număr unic. Dacă aveţi o reţea locală ce nu are conexiune TCP/IP cu alte reţele puteţi să vă alegeţi numere după cum doriţi. Insă, pentru maşini legate la Internet, numerele sunt date de către o organizaţie centrală, şi anume NIC (Network Information Center).


Pentru citirea mai uşoară, adresele IP sunt împărţite în patru numere de 8 biţi numite octeţi. De exemplu, quark.physics.groucho.edu are adresa IP 0x954C0C04 care este scrisă ca 149.76.12.4. Acest format este deseori numit ????dotted quad notation?????. Alt motiv pentru care se foloseşte această notaţie este că adresele IP sunt împărţite in numere de reţea, care sunt conţinute in octeţii din faţă, şi numere de gazde, care reprezintă restul. Când cereţi de la NIC adrese IP, nu veţi obţine câte o adresă pentru fiecare gazdă pe care veţi vrea să o folosiţi ci veţi obţine un număr de reţea şi veţi putea folosi toate adresele IP valide în cadrul acestui reţele. In funcţie de dimensiunea reţelei, partea din adresa IP care reprezintă numărul de gazdă (host number) poate fi mic sau mare. Pentru diferitele nevoi, există câteva clase de reţele, definind diferite impărţiri ale adreselor IP: •

• •

Clasa A cuprinde reţelele de la 1.0.0.0 până la 127.0.0.0. Numărul de reţea este conţinut în primul octet. Aceasta oferă un 24 de biţi pentru numărul gazdei, permiţănd în jur de 1,6 milioane de gazde. Clasa B conţine reţelele de la 128.0.0.0 pâna la 191.255.0.0; numărul de reţea este în primii doi octeţi. Aceasta permite 16320 reţele cu câte 65024 gazde fiecare. Clasa C conţine reţelele de la 192.0.0.0 până la 223.255.255.0 cu numărul de reţea fiind conţinut în primii trei octeţi. Aceasta permite existenţa a aproape 2 milioane de reţele cu câte 254 de gazde fiecare. Clasele D,E şi F conţin adrese între 224.0.0.0 pâna la 254.0.0.0 şi sunt fie experimentale fie sunt rezervate pentru viitor şi nu specifică nici o reţea.

Dacă ne întoarcem la exemplul din capitolul precedent, vedem că 149.76.12.4, adresa lui quark, este o adresa de clasă B. Poate că aţi observat că nu toate valorile din listele de mai sus se puteau folosi ca adrese de gazde. Aceasta este pentru că numerele de gazde cu toţi octeţii 0 sau 255 sunt rezervate pentru scopuri speciale. O adresă unde toate părţile corespunzătoare gazdei sunt zero se numeşte adresă de reţea iar dacă toate părţile corespunzătoare gazdei sunt 1 se numeşte adresă broadcast????. Aceasta din urmă se referă simultan la toate gazdele dintr-o anumită reţea. Astfel 149.76.255.255 nu este o adresă de gazdă validă, dar se referă la toate gazdele reţelei 149.76.0.0. Există două adrese de reţea ce sunt rezervate, şi anume 0.0.0.0 şi 127.0.0.0. Prima se numeşte ruta implicită (default route), iar cea din urmă se numeşte adresa loopbak????. Ruta implicită are legătură cu felul în care IP-ul rutează datagramele, despre care vom vorbi mai jos. Reţeaua 127.0.0.0 este rezervată pentru traficul IP local către gazda locală. De obicei, adresa 127.0.0.1 va fi asociată unei interfeţe speciale numită interfaţă loopback , care se comportă ca un circuit închis. Orice pachet IP trimis prin această interfaţă, va fi returnat ca şi cum ar fi venit de la o maşină din reţea. Acesta vă oferă posibilitatea să dezvoltaţi şi să testaţi software de reţea fară să folosiţi o reţea reală. Altă aplicaţie folositoare este când vreţi să folosiţi software de reţea pe o maşină care nu este în reţea. Aceasta nu este atât de neobişnuit pe cât sună; de exemplu multe gazde UUCP nu au conectivitate IP de loc, însă vor rula serverul de news INN. Pentru a funcţiona bine, INN cere interfaţa loopback.


Căutarea adreselor Acum că aţi văzut cum sunt construite adresele de reţea IP, poate vă veţi întreba cum sunt ele folosite intr-o reţea Ethernet pentru a comunica cu alte gazde. La urma urmei protocolul Ethernet identifică gazdele printr-un număr pe 6 octeţi care nu are nimic în comun cu o adresă IP. Din cauza aceasta este nevoie de un mecanism pentru a face legătura între adrese IP şi adrese Ethernet. Acesta este aşa numitul Adress Resolution Protocol (ARP) - protocol de căutare al adreselor . De fapt ARP nu este legat de Ethernet neapărat ci este folosit şi la alte tipuri de reţele ca de exemplu la reţelele radio. Ideea care stă la baza ARP este ceea ce fac cei mai mulţi oameni când vor să-l găsească pe dl X între 150 de oameni: merg şi îl strigă pe nume fiind sigur că acesta va răspunde dacă este acolo. Când ARP vrea să găsească adresa Ethernet corespunzătoare unei adrese IP, foloseşte o proprietate a protoculului Ethernet numită "răspândire" (broadcasting), când o datagramă este adresată simultan tuturor staţiilor din reţea. Diagrama aceasta conţine o întrebare pentru a afla adresa IP. Fiecare gazdă din reţea compară adresa IP din datagrama primită cu propria adresă IP, şi dacă se potrivesc îi întoarce un răspuns ARP gazdei care a făcut cererea. Această gazdă poate extrage acum, din răspuns, adresa Ethernet. Desigur vă puteţi întrba cum poate ştii o gazdă care din milioanele de maşini cu Ethernet din lume este gazda căutată şi cum poate ştii că aceasta posedă interfaţă Ethernet. Aceste intrebări îşi află răspunsul în ceea ce se numeşte rutare (routing), care se ocupă cu găsirea locaţiei fizice a unei gazde într-o reţea. Acesta va fi subiectul următoarelor secţiuni. Pentru moment să mai vorbim un pic despre ARP. Odată ce o gazdă a descoperit o adresă Ethernet, o va ţine minte astfel încât să nu mai trebuiască să întrebe din nou data viitoare când va vrea să trimită o datagramă gazdei cu pricina. Insă nu este bine să păstreze acestă informaţie totdeauna; de exemplu gazda de la distanţă îşi poate schimba placa de reţea din cauza problemelor tehnice, deci intrarea ARP devine invalidă. Pentru a forţa altă intrebare, intrările în memoria ARP trebuiesc şterse din când în când. Câteodată este necesară găsirea adresei IP asociate unei adrese Ethernet date. Aceasta se întâmplă când o maşină fără disc vrea să booteze de pe un server din reţea, situaţie des întâlnitâ în reţelele locale. On client fără disc nu are nici o informaţie despre el însuşi - în afară de adresa Ethernet! Aşa că va trimite un mesaj răspândit (broadcast) conţinând o rugăminte către serverul de boot pentru a-i spune adresa sa IP. Pentru aceasta există alt protocol numit Reverse Adress Resolution Protocol (RARP) . Impreună cu protocolul BOOTP, el defineşte metoda prin care clienţii fără disk pot boota de pe un server din reţea.

Rutarea IP Reţele IP Când scrieţi o scrisoare cuiva, de obicei puneţi adresa completă pe plic, specificând ţara, codul poştal, etc. După ce puneţi scrisoarea în cutia poştală, serviciul poştal o va duce la destinaţie: ea va fi trimisă în ţara indicată, ţară al cărei serviciu de poştă o va trimite în regiunea specificată, etc. Avantajul acestei scheme ierarhice este evident: oriunde veţi trimite


scrisoarea serviciul local va ştii în mare direcţia în care să trimită scrisoarea însă nu trebuie să se preocupe pe ce cale va ajunge scrisoarea până la distinaţie. Reţelele IP sunt structurate într-un mod analog. Intregul Internet este format dintr-un număr de reţele chemate sisteme autonome. Fiecare astfel de sistem realizează rutarea internă între membrii ei astfel încât sarcina trimiterii datagramei este redusă la găsirea unei căi către reţeaua din care face parte gazda destinatară. Aceasta înseamnă că îndată ce datagrama este înmânată oricărei gazde din reţeaua gazdei destinatare, rutarea va fi făcută mai departe de cărtre reţeaua însăşi.

Subreţele Această structură este obţinută prin împărţirea adresei IP într-o parte corespunzătoarei gazdei şi într-o parete corespunzătoare reţelei, aşa cum am arătat mai sus. Implicit reţeaua destinatară este dedusă din partea de reţea a adresei IP. Astfel, gazdele cu numere de reţea identice ar trebui să se găsească in interiorul aceleiaşi reţele. Are sens să folosim o schemă asemănătoare înăuntrul unei reţele de vreme ce o reţea poate fi formată din sute de reţele mai mici. Astfel protocolul IP, vă dă voie să împărţiţi o reţea IP în mai multe subreţele . O subreţea are responsabilitate trimiterii datagramelor anumitor clase de adrese IP din reţeaua IP din care face parte. La fel cu clasele A, B sau C ele sunt definite de o parte de reţea din adresa IP. Insă acum partea de reţea este extinsă astfel încât cuprinde câţiva biţi din parte de gazdă. Numărul de biţi ce sunt interpretaţi ca numărul de subreţea este dat de aşa numita mască de reţea (subnet mask sau netmask) sa. Aceasta este un număr pe 32 de biţi care specifică masca de biţi pentru partea de reţea a adresei IP. Figura Fig. 2-1 arată cum 149.76.12.4, adresa lui quark este interpretată diferit când este considerată o reţea obişnuită de clasă B, sau când se folosesc subreţele. Fig. 2-1. Impărţirea unei reţele de clasă B în subreţele

Dacă subreţelele ar fi numai diviziuni interne ale reţelei atunci acestea nu ar fi de mare folos. Subreţelele sunt generate de proprietarul reţelei pentru a reflecta graniţele existente fie ele fizice (între două reţele Ethernet), administrative (între două departamente) sau geografice. Insă această structură afectează numai comportarea internă a reţelei, şi este complet invizibilă lumii de afară.

Cap. 3. IP pentru linie seriala


Cuprins Referinta pentru dip Rularea in Modul Server

Referinta pentru dip Comanda get Comanda get este calea cea mai usoara de a seta o variabila. Cea mai simpla forma de a seta o variabila ca si constanta, ca in exemplul de mai jos. Puteti, de altfel, sa folositi un cuvint cheie in loc de valoare: DIP> get $local ask Enter the value for $local:

A treia metoda este de a incerca sa obtinteti o valoare de la un host. Bizar cum pare la prima vedere, acest lucru e foarte folositor in unele cazuri: undel servere SLIP nu premit sa folositi propriul IP in link-ul SLIP, dar mai degraba va va asigna o adresa la fiecare conectare dial-in, afisind mesaje care va informeaza despre adresa pe care v-a asignat-o. Daca mesajul arata ceva de genul "Your address: 193.184.7.202" atunci urmatoarea parte de cod va va lasa sa luati adresa: wait address: 10 get $locip remote

Comanda print Aceasta comanda e utilizata pentru afisarea unui text de la consola. Orice variabila poate fi folosita in comanda print, cum ar fi: DIP>print Using port $port at speed $speed Using port cua3 at speed 38400

Nume de variabile dip intelege doar un set predefinit de variabile. Un nume de variabila intotdeauna incepe cu simbolul dollarului($) si trebuie scrisa cu litere mici (lower-case). Variabilele $local si $locip sunt numele si IP-ul hostului local. Setind numele hostului (numele calculatorului n.tr.) face ca dip-ul sa stocheze partea canonica a hostname-ului in $local, in acelasi timp asignind lui $locip adresa IP corespunzatoare. Analog se intimpla cind se seteaza $locip. Variabilele $remote si $rmtip fac acelasi lucru, doar ca se adreseaza unui host accesat de la distanta. $mtu contine valoarea MTU pentru conexiune.


Aceste cinci variabile sunt singurele la care se pot asigna valori direct din comanda get. Un host cu alte variabile se pot seta prin comenzile corespondente, dar trebuie utilizate argumetnele lui print; acestea sunt $modem, $port si $speed. $errlvl e o variabila prin care se poate vedea rezultatul ultimei comenzi executate. Un nivel de erroare egal cu 0 inseamna ca operatia s-a terminat cu succes, in timp ce o valoare non-zero indica o eroare.

Comenzile if si goto Comanda if este mai degraba o ramura a ceea ce usual face un if (C/C++). Sintaxa sa este: if var op numbergoto label

unde expresia trebuie sa fie o simpla comparatie intre una dintre variabilele $errlvl, $locip, si $rmtip. Al doilea operand trebuie sa fie un numar intreg, iar operatorul op poate fi unul dintre simbolurile: ==, !=, <, >, <=, si >=. Comanda goto face ca executia scriptului sa continue de la linia indicata de label (eticheta). O eticheta trebuie sa fie la inceputul unei linii, si trebuie urmata imediat de o coloana.

Comenzile send, wait si sleep Aceste comenzi ajuta in implementarea unor scripturi simple de chat la dip. send trimite argumentele sale la linia seriala. Nu suporta variabile, dar intelege toate backslash-urile stil C, cum ar fi n si b. Caracterul tilda este folosit ca abreviatie pentru CR/NL (carriage return/newline). wait ia ca argumente un cuvint, scanind toate intrarile seriale pina este recunoscut acest cuvint. Acest cuvint trebuie sa nu contia blank-uri (spatii). Optional, se poate da un timp de asteptare acestei comenzi ca al doilea argumente; daca cuvintul asteptat nu este receptionat in mai multe secunde, atunci comanda va intoarce o eroare cu valoarea stocata in $errlvl. Comanda sleep poate fi folosita pentru a astepta o perioada importanta de timp, de exemplu pentru a astepta rabdator ca orice secventa de login si se termine. Din nou, intervalul e specificat in secunde.

Comenzile mode si default Aceste comenzi sunt folosite a schimba linia seriala in modul SLIP si pentru a configura interfata. Comanda mode este ultima comanda executata de dip inainte de a intra in modul daemon. Daca nu apare nici o eroare, comanda nu intoarce nimic. mode ia ca argument un nume de protocol. dip recunoaste curent SLIP si CSLIP ca nume valide de protocol. Versiunea curenta de dip oricum nu intelege adaptarile SLIP.


Dupa ce s-a stabilit modul SLIP pe linia seriala, dip executa ifconfig pentru a configura interfata ca legatura point-to-point, si invoca route pentru a stabili o ruta catre hostul conectat. Daca, aditional, scriptul executa comanda default inaintea lui mode, dip va face deasemenea ruta implicita spre conexiunea SLIP.

Rularea in Modul Server Setarea in mode client a protocolului SLIP a fost partea ce-a mai grea. In opozitie, adica configurarea propriului host ca server SLIP, este mult mai usoara. O cale de a face acest lucru este setind dip-ul in server mode, care se poate face invocind-ul ca diplogin. Fisiele proprii de configuratie se gasesc in /etc/diphosts, care asociaza numele de login cu adresele pe care acest host le atribuie. Alternativ, se poate folosi sliplogin, o scula derivata din BDS care se caracterizeaza printr-o schema de configuratie mult mai flexibila care va lasa sa executati scripturi de shell oricind hostul se conecteaza sau deconecteaza. Este curent in faza Beta. Ambele programe au nevoie ca sa fie setat un singur cont de login pentru un clinet SLIP. De exemplu, sa presupunem ca dati acces la serviciul SLIP lui Arthur Dent la dent.beta.com, mai intii creati un cont numit dent si adaugind urmatoarea linie in fisierul passwd: dent:*:501:60:Arthur Dent's SLIP account:/tmp:/usr/sbin/diplologin

Dupa care setati parola lui dent utilizind utilitarul passwd. Acum, cind dent se va loga, dip va starta ca server. Pentru a gasi daca el are permisiunea de a utiliza SLIP, se va uita dupa username in /etc/diphosts. Acest fisier are detaliile pentru drepturile de accesare si conectare pentru fiecare user SLIP. O intrare simpla in fisier poate arata asa: dent::dent.beta.com:Arthur Dent:SLIP,296

Prima coloana a cimpului contine numele cu care userul trebuie sa se log-eze. A doua coloana contine o parola aditionala (vezi mai jos). A treia coloana este hostname-ul sau adresa IP a hostului chemat. Urmatorul cimp contine informatii fara semnificatie (inca). Ultimul cimp descrie parametrii conexiunii. Acesta este un cimp separat prin virgule, specificind protocolul (curent SLIP sau CSLIP), urmat de MTU. Cind dent se log-eaza, diplogin extrage informatiile despre el din fisierul diphosts si, daca al doilea cimp nu este gol, afiseaza "external security password" asteptind userul. Sirul de caractere introdus de user este comparat cu parola (criptata) din diphosts. Daca nu se potrivesc, atunci login-ul este refuzat. In caz contrar, diplogin incepe prin a schimba linia seriala cu modul CSLIP sau SLIP, si seteaza interfaĹŁa si rutarea. Aceasta conexiune ramine valabila pina cind userul se deconecteaza si modemul elibereaza linia. diplogin va intoarce linia pe modul normal si va iesi.


diplogin cere privilegii de super-useri. Daca nu aveti dip rulind cu setuid root, ar trebui sa faceti diplogin-ului o copie separata a lui dip in locul unui simple legaturi (link). diplogin poate atunci fi sigur facut setuid, fara a afecta statutul lui dip insusi.

Cap. 4. Protocolul Punct la Punct (PPP) Cuprins Descilcirea P-urilor PPP deschis

Descilcirea P-urilor La fel ca SLIP, PPP este un protocol de transmisie a datelor pe o conexiune seriala, dar rezolva o serie de deficiente ale precedentului. Acest protocol lasa partile comunicante sa negocieze optinui ca adresa IP si viteza de transfer la inceputul conectarii si suporta autorizarea clientului. Pentru fiecare dintre aceste capabilitati, PPP are un protocol separat. In cele ce urmeaza vom prezenta sumar primele notiuni ale PPP-ului. Aceasta discutie e pe departe de a fi completa; daca doriti sa aflati mai multe despre PPP, va sfatuiesc sa cititi specificatiile RFC-1548 sau specificatiile insotitoare RFC-ului. ( link ) In partea ce-a mai de jos a PPP-ului este High-Level Data Link Control Protocol, abreviata HDLC, ( link ) care defineste limitarile din jurul cadrelor individuale PPP si este prevazut cu un checksum pe 16 biti. in opozitie cu mai primitiva incapsulare SLIP, un cadru PPP este capabil sa tina pachetele pentru alte protocoale decit IP, cum ar fi Novell IPX, MS NetBUI sau Appletalk. PPP realizeaza acestea prin adaugarea unui cimp de protocol cadrului primar HDLC care identifica tipul de pachet care este carat de cadru. LCP, Link Control Protocol sau Controlul Protocolului de Legaturi, este utilizat in fata HDLC-ului pentru optiuni de negociere apartinind legaturii de date, cum ar fi Maximum Receive Unit (MRU) sau Unitatea Maxima de Receptie care seteaza marimea datagramei maxime pe care una dintre parti e de acord sa o receptioneze. Un pas important al configurarii unei legaturi PPP este autorizarea clientului. Desi nu este imperativ, este o adevarata nevoie pentru liniile telefonice (dial-up). Uzual, hostul chemat (serverul) cere clientului sa se autorizeze dindu-i o cheie secreta. Daca cel ce cheama (suna) nu reuseste sa produca secretul corect, conexiunea este terminata. Cu PPP, autorizarea merge in ambele sensuri; asa ca cel ce cheama (suna) poate de asemenea sa ceara serverului sa se autentifice. Aceste procedee de autorizare sunt total independente una de cealalta. Sunt doua protocoale pentru diferitele tipuri de autorizare, pe care le vom discuta In cele ce urmeaza. Ele se numesc Password Authentification Protocol sau Protocol de Autentificare a Parolei (PAP) si Challange Handshake Authentification Protocol sau Protocol de Autentificare Challange Handshake (CHAP). Fiecare protocol de retea care este rutat peste legatura de date, ca IP, AppleTalk, etc., este configurat dinamic, utilizind o corespondentul Network Control Protocol (NCP), De exemplu, pentru a trimite datagrame IP prin legatura, ambele PPP-uri trebuie prima data sa negocieze ce adrese de IP foloseste fiecare dintre ele. Protocolul de control utilizat pentru aceasta este IPCP, Internet Protocol Control Protocol sau Protocolul de Control al Protocolului Internet.


Pe linga trimiterea de datagrame IP standard prin legatura, PPP suporta de asemenea comprimarea Van-Jacobson a headerului datagramelor IP. Aceasta este o metoda de a micsora headerele pachetelor TCP pina la trei octeti. Este de asemenea utilizata in CSLIP si este mult mai colocvial referita la compresia headerului VJ. Pentru a utiliza compresia se poate negociind la startul prin IPCP la fel de bine.

Cap. 5. Sistemul informational al retelei (NIS) Cuprins Să facem cunoştinţă 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 şi group Folosirea NIS cu suport pentru Shadow Folosirea codului NIS tradiţional În cazul unei reţele locale (LAN), scopul final este de obicei crearea unui mediu în care utilizatorii să poată folosi reţeaua cât mai transparent. Un pas important în îndeplinirea acestui scop este sincronizarea între host-uri a informaţiilor vitale (de exemplu informaţiile legate de conturile utilizatorilor). Mai înainte am văzut că pentru "host name resolution" există deja un serviciu puternic şi sofisticat -- şi anume DNS, dar în alte cazuri nu există un astfel de serviciu. De asemenea, dacă reţeaua este mică şi nici nu este legată la Internet s-ar putea ca instalarea DNS-ului să nu merite efortul. Din aceste motive firma Sun a inventat NIS, Network Information System. NIS oferă funcţii generice de acces la baze de date care pot fi folosite la distribuirea diferitelor informaţii, de pildă cele conţinute în fişierele passwd şi groups, acestea devenind accesibile pentru toate host-urile din reţea. Astfel, reţeaua apare ca un singur sistem, cu aceleaşi conturi pe toate hosturile. În acelaşi mod puteţi folosi NIS pentru a distribui informaţiile din /etc/hosts către toate calculatoarele din reţea. NIS se bazează pe RPC şi cuprinde un server, o bibliotecă pentru client şi câteva utilitare de administrare. Iniţial NIS era numit Yellow Pages, sau YP, denumire care mai este încă folosită (informal) pentru acest serviciu. Însă Yellow Pages este o marcă înregistrată a British Telecom, care a cerut ca Sun să renunţe la nume. În ciuda acestui lucru, oamenii renunţă greu la denumirile cu care s-au obişnuit, aşa că YP a rămas prefixul majorităţii comenzilor care se referă la NIS: ypserv, ypbind, etc. Acum, NIS este disponibil pentru oricine, existînd chiar implementări free. Una dintre acestea face parte din BSD Net-2 şi se bazează pe o implementare pusă la dispoziţia publicului larg de către Sun. Biblioteca pentru client a existat în GNU libc de mult timp, în comparaţie cu utilitarele - care au fost portate relativ de curând de către Swen Thümmler. Din implementarea de referinţă lipseşte însă serverul NIS. Tobias Reber a scris un alt pachet NIS (numit yps) care include toate utilitarele şi un server.


În momentul de faţă Peter Eriksson lucrează la rescrierea completă a codului NIS, redenumit acum NYS, care suportă atât NIS cât şi NIS+ (varianta revizuită). NYS nu oferă doar un set de utilitare NIS şi un server, ci şi un set complet nou de funcţii de bibliotecă; acestea probabil că vor fi incluse şi în varianta standard a libc. Este inclusă şi o schemă nouă de configurare pentru "hostname resolution" care înlocuieşte schema actuală care foloseşte host.conf. Aceste funcţii vor fi descrise mai jos. În acest capitol accentul va fi pus pe NYS şi nu pe celelalte două pachete care vor fi numite codul NIS ``tradiţional''. Dacă doriţi să utilizaţi unul dintre acestea două, instrucţiunile din acest capitol ar putea fi suficiente, dar s-ar putea şi să nu fie. Pentru informaţii suplimentare consultaţi un manual standard despre NIS, cum este NFS and NIS de Hal Stern (vezi-[]). NYS este încă în faza de dezvoltare, şi de aceea utilitarele standard (de exemplu utilitarele de reţea sau programul login) nu cunosc schema de configurare NYS. Atâta timp cât NYS nu este inclus în libc va trebui să recompilaţi programele care doriţi folosească NYS. Pentru oricare dintre aceste aplicaţii, adăugaţi în Makefile opţiunea -lnsl chiar înainte de libc. Astfel în loc de funcţiile bibliotecii C standard vor fi link-ate funcţiile din libnsl -- biblioteca NYS.

Să facem cunoştinţă cu NIS NIS păstrează informaţiile bazei de date în aşa numitele map-uri care conţin perechi de valoricheie. Map-urile sunt stocate pe un anumit host pe care rulează serverul NIS, de unde clienţii pot obţine informaţiile prin diferite call-uri RPC. Destul de frecvent, map-urile sunt stocate în fişiere DBM. Map-urile în sine sunt de obicei generate din fişierele text originale cum sunt /etc/hosts şi /etc/passwd. Pentru unele fişiere sunt create mai multe map-uri, câte unul pentru fiecare tip de cheie de căutare. De exemplu, în fişierul hosts se poate căuta fie un host name, fie o adresă IP. Deci în acest caz sunt generate două map-uri NIS numite hosts.byname şi hosts.byaddr. În tabela puteţi vedea o listă cu map-urile tipice şi fişierele din care sunt generate. Table: Câteva map-uri NIS standard NIS şi fişierele corespunzătoare. ???????????????????? S-ar putea ca în unele pachete NIS să găsiţi suport şi pentru alte fişiere şi map-uri. Acestea conţin informaţii pentru aplicaţii care nu sunt abordate în acestă carte, de pildă bootparams folosit de unele servere BOOTP (map-urile corespunzătoare sunt ethers.byname şi ethers.byaddr). De obicei, în loc de unele map-uri se folosesc nicknames (porecle), care sunt mai scurte şi mai uşor de tastat. Pentru a obţine lista completă a nicknames-urilor recunoscute de utilitarele NIS puteţi folosi comanda: Serverul NIS este numit, prin tradiţie, ypserv. Într-o reţea de mărime medie, un server NIS este în general suficient; în reţelele mari însă, se poate să fie necesare servere diferite pentru diferite hosturi şi pentru diferite segmente ale reţelei, pentru a nu suprasolicita serverele şi routerele. Aceste servere sunt sincronizate: unul este master server, iar celelalte slave servers. Map-urile sunt create numai pe master server şi de acolo sunt distribuite pe toate serverele slave.


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


în baza de date NIS+, iar coloanele sunt proprietăţile obiectelor gestionate de NIS+. Tabela fiecărui domeniu NIS+ include tabelele domeniilor 'părinte'. De asemenea o înregistrare dintro tabelă poate conţine un link către o altă tabelă. Aceste facilităţi oferă posibilităţi multiple de organizare a informaţiilor. Varianta tradiţională a NIS este versiunea 2 de RPC, în timp ce NIS+ este versiunea 3. NIS+ nu pare să fie folosit pe o scară largă, iar eu îl cunosc destul de puţin. (eh! nu se poate spune că nu ştiu chiar nimic) De aceea nu-l voi aborda în această documentaţie. Dacă doriţi să aflaţi mai multe despre NIS+ puteţi consulta manualul de administrare NIS+ de la Sun. ([]).

NIS: Partea de Client Dacă sunteţi familiarizaţi cu scrierea sau portarea aplicaţiilor de reţea veţi observa că majoritatea map-urilor NIS listate mai sus corespund unor funcţii din biblioteca C. De exemplu, pentru a obţine informaţii din passwd se folosesc de obicei funcţiile getpwnam(3) şi getpwuid(3) care returnează informaţiile despre contul unui utilizator regăsit după user name, respectiv user id. În mod obişnuit aceste funcţii caută informaţiile dorite în fişierul standard: /etc/passwd. În cazul unei implementări care utilizează NIS, aceste funcţii vor fi modificate în sensul că trimit către serverul NIS un call RPC prin care este localizat numele şi id-ul utilizatorului. Acest comportament este total transparent pentru aplicaţie. Funcţia poate fie să adauge elemente în map-ul NIS, fie să înlocuiască cu totul fişierul original. Bineînţeles, nu are loc o modificare reală a fişierului, ci doar este creată iluzia că acesta a fost înlocuit sau modificat. În implementările NIS tradiţionale existau mai multe convenţii referitoare la care map-uri înlocuiesc şi care se adaugă la informaţiile originale. Unele, cum sunt map-urile passwd, necesitau modificări ale fişierului passwd care dacă nu erau făcute corect afectau serios securitatea sistemului. Pentru a evita aceste capcane, NYS foloseşte o schemă generală de configurare care determină dacă pentru un set de funcţii client de folosesc fişierele originale, NIS, sau NIS+, şi în ce ordine. Capitolul curent include o secţiune specială despre această chestiune.

Rularea unui server NIS Poate că v-aţi plictisit de teoria de până acum, aşa că hai să ne punem pe treabă şi să ne apucăm de configurarea propriu-zisă. În acestă secţiune vom discuta despre configurarea unui server NIS. Dacă în reţeaua dumneavoastră funcţionează deja un server NIS, nu mai este nevoie să setaţi nimic ( şi puteţi sări fără grijă peste acestă secţiune ). Dacă nu doriţi altceva decât să experimentaţi, să "vă jucaţi" cu setarea serverului, aveţi grijă să nu folosiţi un nume al domeniului NIS care există deja în reţea. Altfel s-ar putea să destabilizaţi întregul serviciu de reţea, iar mulţi oameni ar putea deveni nemulţumiţi şi chiar foarte nervoşi. În momentul de faţă există două servere NIS disponibile: unul în cadrul pachetului yps al lui Tobias Reber, şi altul în cadrul pachetului ypserv al lui Peter Eriksson. În principiu nu


contează pe care îl folosiţi. În momentul acesta, când scriu, codul pentru manipularea serverelor NIS de tip slave pare să fie mai complet în yps. Deci dacă aveţi nevoie de servere slave, probabil că yps este o alegere mai bună. După instalarea severului (programul ypserv) în /usr/sbin, urmează să creaţi directorul care va conţine fişerele map pe care le va distribui serverul. Când setaţi domeniul NIS pentru brewery map-urile vor fi puse în /var/yp/brewery. Serverul determină dacă deserveşte un anumit domeniu NIS după existenţa directorului cu map-uri. Dacă la un moment dat doriţi să dezactivaţi un domeniu NIS, asiguraţi-vă că aţi şters şi directorul. În general, map-urile sunt păstrate în fişiere DBM, care sunt generate din fişierele master cu ajutorul programului makedbm (pentru serverul lui Tobias) sau dbmload (pentru severul lui Peter). Acestea s-ar putea să nu fie interschimbabile. Formatarea unui fişier master pentru a putea fi procesat cu dbmload necesită de obicei folosirea lui sed sau awk, ceea ce tinde să fie cam anost şi greu de reţinut. De aceea pachetul ypserv al lui Peter Eriksson conţine un Makefile (numit ypMakefile) care face toată acestă muncă în locul dumneavoastră. Trebuie să instalaţi acest fişier sub numele Makefile în directorul cu map-uri, apoi să-l editaţi pentru a alege map-urile pe care doriţi să le distribuiţi. Pe la începutul fişierului se targetul all care conţine toate serviciile pe care le poate oferi ypserv. În mod implicit, linia arată cam aşa : Dacă de pildă nu aveţi nevoie de map-urile ethers.byname şi ethers.byaddr, pur şi simplu ştergeţi ethers din acest rule. Pentru a testa configuraţia probabil că este suficientă pornirea a una sau două map-uri, de exemplu services.*. După ce aţi editat Makefile, rămâneţi în directorul cu map-uri şi tastaţi ``make''. Map-urile vor fi generate şi instalate automat. Trebuie să refaceţi map-urile la fiecare modificare a fişierelor master, altfel schimbările nu vor fi disponibile în reţea. În secţiunea următoare puteţi afla cum se configurează codul NIS pentru client. Dacă setările dumnevoastră nu merg, trebuie să aflaţi mai întâi dacă cererile ajung sau nu la server. Dacă la pornirea serverului specificaţi opţiunea -D, acesta va tipări la consolă mesaje referitoare toate cererile NIS primite şi la rezultatele acestora. Aceste mesaje ar trebui să vă ajute să aflaţi de unde provine problema. Serverul lui Tobias nu are această opţiune.

Setarea unui client NIS cu NYS De acum încolo, în acest capitol vom aborda configurarea clienţilor NIS. Primul pas este setarea în /etc/yp.conf a serverului NYS care va fi folosit. Ca exemplu, iată un fişier foarte simplu pentru un host din reţeaua Winery: Prima linie a fişierului specifică toţi clienţii NIS care aparţin domeniului NIS winery. Dacă omiteţi acestă linie NYS va folosi numele de domeniu pe care l-aţi setat cu comanda domainname. Mai departe se specifică serverul NIS care va fi folosit. Desigur, adresa IP a serverului vbardolino trebuie specificată în fişierul hosts; puteţi dealtfel să 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. Dacă în mod frecvent se întâmplă să mutaţi


calculatorul în mai multe domenii NIS probabil că veţi dori să păstraţi în fişierul yp.conf informaţiile referitoare la mai multe domenii NIS. De exemplu, în cazul unui laptop fişierul de mai sus ar putea fi modificat astfel: Astfel laptopul va putea face parte din oricare dintre cele două domenii, singura setare necesară fiind alegerea domeniului NIS cu ajutorul comenzii domainname. După ce aţi creat acest fişier de configurare minimal şi după ce aţi verificat că poate fi citit de către toţi utilizatorii, urmează să faceţi primul test : prima conectare la server. Alegeţi orice map distribuit de server, de pildă hosts.byname, şi încercaţi să-l obţineţi folosind utilitarul ypcat. La fel ca toate celelalte utilitare de adminstrare, ypcat ar trebui să se găsească în /usr/sbin. Output-ul pe care îl veţi obţine ar trebui să arate în genul celui de mai sus. Însă, dacă apare un mesaj de eroare ca ``Can't bind to server which serves domain'' sau altceva asemănător, înseamnă că fie numele domeniului NIS pe care l-aţi setat nu corespunde nici unui server definit în yp.conf, fie că serverul este inaccesibil dintr-un motiv oarecare. În al doilea caz, verificaţi dacă ping raportează că poate accesa serverul şi dacă da, verificaţi dacă este întradevăr vorba de un server NIS. Pentru acesta folosiţi rpcinfo care ar trebui să afişeze un output de genul :

Alegerea map-urilor corecte După ce v-aţi convins că puteţi contacta serverul NIS, trebuie să decideţi care fişiere să le înlocuiţi sau să le întregiţi cu map-uri NIS. În mod tipic, probabil că veţi dori să folosiţi mapuri NIS pentru host şi pentru passwd. Primul este util mai ales când nu folosiţi BIND, iar al doilea permite tuturor utilizatorilor să se conecteze de la orice host din reţea; acesta necesită existenţa unui director /home central, disponibil în toată reţeaua prin NFS. În secţiunea puteţi găsi informaţii detaliate despre cum se realizează aceasta. Alte map-uri, cum este services.byname, nu sunt la fel de spectaculoase, dar vă pot scăpa de ceva muncă de editare în cazul în care instalaţi aplicaţii de reţea care folosesc un serviciu care nu este în fişierul services standard. Probabil că doriţi să puteţi alege dacă o funcţie foloseşte fişierul local sau serverul NIS. NYS vă permite să configuraţi ordinea în care o funcţie accesează aceste servicii. Fişierul de configurare este /etc/nsswitch.conf (nss vine de lar Name Service Switch), dar bineînţeles că nu este limitat doar la name service. Acest fişier conţine câte o linie pentru fiecare funcţie suportată de NYS. Ordinea corectă a serviciilor depinde de tipul datelor. Este improbabil ca map-ul services.byname să conţină înregistrări diferite de cele din fişierul services local; poate eventual să conţină înregistrări în plus. Astfel, ar fi o alegere bună ca mai întâi să fie consultat fişierul local doar dacă nu este găsit serviciul dorit să se apeleze la NIS. Pe de altă parte, informaţiile referitoare la hostnames se pot schimba foarte frecvent, astfel că în general serverele DNS sau NIS deţin cele mai actualizate informaţii, pe când fişierul hosts local este păstrat doar ca rezervă pentru cazul în care serverul DNS sau NIS pică. Astfel că în aceste condiţii este de dorit ca fişierul local să fie consultat ultimul.


Exemplul de mai jos arată cum se pot configura funcţiile gethostbyname(2), gethostbyaddr(2) şi getservbyname(2) ca să funcţioneze în modul descris mai sus. Ele vor încerca iniţial primul serviciu; în cazul unui succes se returnează rezultatul, altfel este încercat următorul serviciu. Mai jos se găseşte lista completă a serviciilor care pot fi folosite cu o înregistrare în fişierul nsswitch.conf. Map-urile, fişierele, serverele şi obiectele care vor fi consultate depind de numele înregistrării. În momemtul de faţă, NYS suportă următoarele înregistrări în nsswitch.conf: hosts, networks, passwd, group, shadow, gshadow, services, protocols, rpc, şi ethers. Probabil căse vor mai adăuga şi altele. Figura- ilustrează un exemplu şi mai complet care introduce o altă facilitate a nsswitch.conf: cuvântul-cheie [NOTFOUND=return] în înregistrarea hosts, datorită căruia dacă nu este găsit elementul căutat, NYS va continua cu căutarea în fişierele locale numai dacă consultarea serverelor NIS şi DNS a eşuat. Fişierele locale vor fi astfel folosite numai la bootare şi ca o copie de siguranţă pentru cazul când serverul NIS nu este accesibil. Figure: Sample nsswitch.conf file.????????????/

Folosirea map-urilor passwd şi group Unul dintre rolurile esenţiale pa cere le joacă NIS este sincronizarea informaţiilor despre utilizatori şi conturile lor în cadrul domeniului NIS. În acest scop, se păstrează de obicei un fişier /etc/passwd minimal la care se adaugă informaţiile din map-urile NIS (care sunt disponibile în tot domeniul). Simpla activare a acestora în nsswitch.conf nu este însă de ajuns. Atunci când folosiţi NIS pentru distribuirea informaţiilor referitoare la parole trebuie mai întâi să vă asiguraţi că user id-urile utilizatorilor din fişierul passwd local corespund cu cele de pe serverul NIS. Dacă unul dintre id-urile numerice din /etc/passwd sau /etc/group diferă de cel din map-uri va trebui să modificaţi proprietarul (owner) pentru toate fişierele utilizatorului respectiv. Mai întâi trebuie să setaţi noile valori ale uid-urilor şi gid-urilor în passwd respectiv group. Apoi localizaţi toate fişierele utilizatorului şi le schimbaţi proprietarul (cu chown). Să zicem că news avea user id-ul 9, iar okir avea 103; dacă această valoare a fost modificată ar urma să folosiţi următoarele comenzi: Este important să apelaţi aceste comenzi avînd instalat noul fişier passwd şi să colectaţi toate numele fişierelor userului înainte de chown. Pentru a modifica apartenenţa la grupuri a fişierelor se foloseşte o comandă similară. După de aţi făcut aceasta, uid-urile şi gid-urile numerice locale vor corespunde cu cele din întregul domeniu NIS. Următorul pas este adăugarea în nsswitch.conf a liniilor care activează localizarea prin NIS a informaţiilor despre utilizatori şi grupuri: Ca efect, atunci când un utilizator încearcă să se conecteze, comanda login sau alte comenzi asemănătoare vor consulta mai întîi map-urile NIS şi doar în caz de nereuşită vor consulta fişierele locale. În general probabil că veţi scoate aproape toţi userii din fişierele locale, lăsînd


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 execută comanda su pentru a deveni temporar news, iar subsistemul UUCP ar putea trimite prin mail un raport. Dacă news şi uucp nu există în fişierul passwd local există riscul ca aceste joburi să eşueze foarte urât dacă NIS nu este disponibil în acel moment. Mă simt dator să dau aici două avertismente importante: în primul rând, configurările descrise mai sus funcţionează numai pentru suite login care nu folosesc shadow passwords ( cum este cea inclusă în pachetul util-linux ). Complicaţiile aduse de folosirea parolelor shadow vor fi abordate în secţiunea următoare. În al doilea rând, comenzile de genul login nu sunt singurele care accesează fişierul passwd-- de pildă chiar şi banalul ls face parte din această categorie. De fiecare dată când este apelat ls cu opţiunea -l (long listing), vor fi afişate numele simbolice pentru grupul şi proprietarul fiecărui fişier, ceea ce implică de fiecare dată o conectare la serverul NIS. Se poate întâmpla ca din acestă cauză viteza să scadă foarte mult, mai ales dacă reţeaua este supraîncărcată sau dacă, mai grav, serverul NIS nu este în aceeaşi reţea fizică şi datagramele trebuie să treacă printr-un router. Şi asta nu e totul. Imaginaţi-vă că un utilizator vrea să-şi schimbe parola. În mod normal, va apela passwd care citeşte noua parolă şi modifică fişierul passwd local. Acest lucru este imposibil când se foloseşte NIS, deoarece fişierul nu mai este disponibil local, iar a permite utilizatorilor să se conecteze la serverul NIS de fiecare dată când vor să-ş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 păstrată pe server, yppasswd contacteză daemonul yppasswdd de pe server via RPC, şi comunică noile informaţii. Pentru a instala yppasswd peste programul passwd clasic se procedează în felul următor: De asemenea trebuie să instalaţi pe server rpc.yppasswdd şi să-l porniţi din rc.inet2. Astfel li se va ascunde utilizatorilor această ciudăţenie datorată NIS-ului.

Folosirea NIS cu suport pentru Shadow Deocamdată nu există suport NIS pentru site-uri care folosesc shadow pentru login. John F.Haugh, autorul pachetului shadow, a lansat de curând pe comp.sources.misc o nouă versiune a bibliotecii de funcţii shadow care suportă parţial NIS, deci e incompletă şi nu a fost încă în biblioteca C standard libc. Pe de altă parte, publicarea cu NIS a informaţiilor din /etc/shadow contravine scopului pe care îl are shadow ! Deşi funcţiile NYS referitoare la password nu folosesc map-ul shadow.byname sau ceva similar, NYS permite în mod transparent folosirea unui fişier /etc/shadow. Când este apelată implementarea NYS a funcţiei getpwnam sunt utilizate specificaţiile din câmpul passwd din nsswitch.conf. Serviciul NIS va localiza informaţiile cerute în map-ul passwd.byname de pe serverul NIS. Totuşi, serviciul files va verifica existenţa fişierului /etc/shadow, şi dacă îl găseşte va încerca să-l deschidă. Dacă nu există sau dacă userul nu este root, se va reveni la comportamentul clasic: căutarea informaţiilor numai în /etc/passwd. Dacă /etc/shadow există şi poate fi deschis, NYS va lua din shadow parola utlizatorului. Funcţia getpwuid este implementată în mod similar. Astfel, executabilele compilate cu NYS se vor descurca în mod transparent cu o configurare care foloseşte shadow.


Folosirea codului NIS tradiţional Dacă folosiţi codul client inclus în versiunea standard curentă a libc, configurarea clientului NIS este un pic diferită. În primul rând, în loc să obţină informaţiile despre serverele NIS dintr-un fişier de configuraţie, foloseşte daemonul ypbind pentru localizarea serverelor active. Deci trebuie să vă asiguraţi că ypbind este încărcat la bootare. ypbind trebuie rulat după setarea domeniului NIS şi după ce a fost pornit portmapper-ul RPC. Apoi ar trebui să testarea serverului cu ypcat. De curând s-a raportat multe ori un bug care se manifestă prin aceea că NIS eşuează returnînd ``clntudp_create: RPC: portmapper failure - RPC: unable to receive''. Această eroare se datorează unei modificări incompatibile a modului cum ypbind returnează informaţiile către funcţiile de bibliotecă. Dacă obţineţi ultimele surse ale utilitarelor NIS şi le compilaţi ar trebui să scăpaţi de acestă problemă. De asemenea, modul în care NIS-ul tradiţional decide dacă şi cum să facă îmbinarea informaţiilor NIS cu cele din fişierele locale diferă faţă de NYS. De exemplu, pentru a folosi map-uri password va trebui să includeţi următoarea linie în /etc/passwd: Aceasta marchează locul unde funcţiile de localizare pentru password inserează map-urile NIS. Inserarea unei linii similare (mai puţin ultimele două puncte) în /etc/group face acelaţi lucru pentru map-urile group.* . Pentru a distribui prin NIS map-urile hosts.* trebuie să schimbaţi ordinea liniilor în host.conf file. De pildă, dacă ordinea pe care o doriţi este NIS, DNS, /etc/hosts s-ar putea să fie nevoie să modificaţi linia în Implementarea NIS clasică nu suportă alte map-uri la acest moment.

ccc  
ccc  

ccc ccccasasasasasa

Advertisement