Ghidul Administratorilor de Reea Linux Olaf Kirch

Copyright 1992-1994 de Olaf Kirch

Cuprins 1. Introducere n reele;

Reele TCP/IP Alte tipuri de hardware Protocolul Internet Protocolul IP peste liniile seriale Protocolul de Control al Transmisiei (TCP) Protocolul Datagrame Utilizator (UDP) Mai multe despre porturi Biblioteca Socket Codul de Networking Diferite linii de dezvoltare De unde se poate obtine codul Intreinerea sistemului Securitatea sistemului Privire general peste capitolele urmtoare

2. Ideile principale pentru reelele TCPIP Interfee de reea Adrese IP Cutarea adreselor Rutarea IP Reele IP Subreele

3. IP pentru linie seriala Referinta pentru dip Comanda get Comanda print Nume de variabile Comenzile if si goto Comenzile send, wait si sleep Comenzile mode si default Rularea in Modul Server

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

5. Sistemul informational al retelei (NIS) S facem cunotin 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 tradiional

Cap. 1. Introducere n reele; Cuprins Reele TCP/IP Codul de Networking Intreinerea sistemului Privire general peste capitolele urmtoare

Reele 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 n-ar 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 BSD-ului.

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.

Intreinerea sistemului Pe tot cuprinsul acestei cri ne vom ocupa n principal cu chestiuni de instalare i configurare. Administrarea sistemului const din mult mai mult dect att. Dup configurarea unui anumit serviciu, trebuie s-l inei n funciune. Pentru cele mai multe servicii foarte puin munc este necesar, ns unele servicii, ca de exemplu serviciile de ???mail??? i de ???news??, necesit executarea unor aciuni de rutin pentru a ine sistemul la zi. Vom discuta aceste aciuni n capitolele ce vor urma.

Minimul absolut n ntreinerea sistemului este verificarea regulat de erori i de evenimente neobinuite a fiierelor log ale aplicaiilor. Foarte practic este s scriei nite scripturi administrative i s le rulai din cron periodic. Distribuia surs a unora din aplicaiile majore, ca de exemplu ???smail??? sau ???C-News???, conin asemenea scripturi. Tot ce v rmne de fcut este s le adaptai nevoilor i preferinelor dumneavoastr.

Ieirea oricrui job cron va fi trimis prin mail ctre un cont administrativ. Implicit, multe aplicaii vor trimite rapoarte de eroare sau statistici despre utilizare ctre contul de root. Aceasta are sens numai dac v logai ca root frecvent; o idee mult mai bun este s retrimitei mail-ul root-ului catre contul personal prin crearea unui alias, aa cum este descris n capitolul ???.

Ins orict de atent va-i configurat sistemul, legile lui Murphy garanteaz c vor aprea probleme. Astfel administrarea unui sistem nseamn i disponibilitatea pentru plngeri. De obicei utilizatorii se ateapt ca administratorul de sistem s fie de gsit prin mail ca i root, dar sunt i alte adrese care sunt folosite pentru a ajunge la persoane responsibile cu diferite aspecte ale administrrii. De exemplu, plngerile despre funcionarea incorect a serviciului de mail vor fi trimise de obicei ctre postmaster; iar problemele cu serverul de news vor fi trimise ctre newsmaster sau Usenet. Mail-ul ctre hostmaster va trebui redirecionat ctre persoana care se ocup cu servicile de reea de baz sau de serviciul DNS dac rulai un server de nume (name server).

Securitatea sistemului Un aspect foarte important al administrrii sistemului dintr-o reea este protejarea lui de intruderi. Sistemele administrate neatent ofer ruvoitorilor multe inte: atacurile merg de la ghicirea parolei pn la "spionarea" pachetelor dintr-o reea Ethernet i pagubele cauzate de aceste atacuri merg de la date pierdute la violarea intimitii utilizatorilor. Vom meniona unele probleme particulare cnd vom discuta contextul n care pot aprea i, n unele cazuri, posibile aprri mpotriva acestor atacuri.

In aceast seciune vom discuta cteva exemple i tehnici de baz referitoare la securitatea sistemului. Desigur, discuia nu poate trata toate problemele legate de securitate pe care le putei ntlni; ea folosete mai degrab la ilustrarea problemelor ce pot aprea. Astfel este absolut necesar citirea unei cri bune despre securitate n special pentru un sistem aflat n reea. Cartea lui Simon Garfinkel, "Practical UNIX Security" este recomandat.

Securitatea sistemului pornete de la o bun administrare a lui. Aceasta include verificarea proprietarului i permisiunilor pentru toate fiierele i directoarele vitale, monitorizarea folosirii conturilor privilegiate, etc. Programul COPS, de exemplu, v va verifica sistemul de fiiere precum i fiierele de configurare cele mai comune. De asemenea este recomandabil s obligai utilizatorii s-i seteze parole ct mai greu de ghicit. De exemplu programul uzual pentru schimbarea parolei cere ca parola s aib cel puin cinci caractere i s conin att litere ct i cifre sau caractere speciale.

Cnd facei un serviciu accesibil prin reea, asigurai-v c i dai cel mai mic privilegiu, adic c nu i permitei s fac lucruri ce nu-i sunt necesare pentru a funciona aa cum trebuie. De exemplu n-ar trebui s facei executabile setuidate??? root dect cnd este neaprat necesar. De asemenea, dac vrei s utilizai un serviciu pentru o aplicaie foarte limitat, nu ezitai s-l configurai ct mai restrictiv cu putin. De exemplu dac avei maini fr disk n reea i vrei s le lsai s booteze de pe maina dumneavoastr, trebuie s folosii serviciul TFTP (trivial file transfer protocol) astfel nct clienii s poat descrca fiierele de configurare de baz din directorul /boot. Ins, cnd nu este restricionat, TFTP las orice utilizator din lume s descarce orice fiier cu drept de citire. Dac nu vrei aceasta, de ce s nu restricionai serviciul TFTP numai la directorul /boot?

In aceeai ordine de idei, e bine s restricionai anumite servicii la utilizatori de pe anumite maini, de exemplu din reeaua local. In capitolul ???, vom introduce tcpd care face acest lucru pentru o mulime de aplicaii de reea.

Alt punct important este s evitai aplicaiile "periculoase". Desigur, orice aplicaie poate fi periculoas, deoarece poate avea "scame" pe care oamenii detepi le pot exploata pentru a cpta acces la sistemul dumneavoastr. Lucruri ca acestea se ntmpl i nu exist protecie complet mpotriva lor. Aceast problem afecteaz att software-ul liber ct i software-ul comercial. Ins programele care necesit privilegii sporite sunt mai periculoase dect celelalte din cauz c orice scam poate avea efecte drastice. Dac instlai un program pentru reea, setuidat, fii de dou ori mai atent c nu v scap nimic de la documentaie, astfel ncat s nu creai o ni de securitate din greeal.

Nu putei ti niciodat dac precauiile dumneavoastr vor da gre indiferent de ct de atent ai fost. Verificarea regulat a logurilor este un punct bun de plecare, dar intruderul este probabil suficient de detept nct s cread orice urm. Ins, exist unelte ca tripwire??? care v permit s verificai fiierele vitale pentru a vedea dac coninutul i permisiunile s-au schimbat. Tripwire calculeaz diferite sume de control pentru aceste fiiere i le pstreaz ntr-o baz de date. In timpul rulrilor succesive, sumele de control sunt recaluclate i comparate ce cele pstrate pentru a detecta orice modificare.

Privire general peste capitolele urmtoare Capitolele urmtoare se vor ocupa cu configurarea Linux-ului pentru reele TCP/IP i cu configurarea unor aplicaii majore. Inainte s; ne murdrim minile cu editarea fiierelor i alte chestii asem;ntoare, vom examina, n Cap. 2, mai cu atenie, protoculul IP. Dac tii deja cum funcioneaz routarea IP i cum se face gsirea adreselor, putei sri direct la capitolul urmtor.

Capitolul se ocup cu configurrile de baz, ca de exemplu compilarea unui kernel i configurarea plcii Ethernet. Configuraia porturilor seriale este tratat ntr-un capitol separat, din cauz c discuia nu se aplic numai reelelor TCP/IP dar este relevant pentru UUCP.

Capitolul se ocup cu configurarea unei maini pentru o reea TCP/IP. El conine informaii pentru instalarea unor gazde fr reea externa i a unor gazde conectate la o reea Ethernet.

Acesta este urmat de dou capitole care v inva cum s folosii SLIP i PPP. Capitolul Cap. 3 explic cum s stabilii o conexiune SLIP i v ofer referine detaliate despre dip, o unealt care v permite s automatizai cei mai muli pai. Capitolul Cap. 4 acoper PPP i pppd, demonul PPP de care vei avea nevoie.

Capitolul v ofer o scurt introducere n configurarea celor mai importante aplicaii pentru reea precum rlogin,rcp, etc. De asemenea se discut serviciile ce sunt manevrate de superserverul inetd i cum putei restriciona anumite servicii.

Capitolul v ofer informaii preioase despre administrarea programului Taylor UUCP care este o implementare free a suitei UUCP.

Restul crii se ocup cu un studiu detaliat al potei electronice si al serviciului de tiri. Capitolul introduce conceptele de baz ale potei electronice precum forma unei adrese de mail i cum funcioneaz sistemul furnizrii e-mailurilor ctre destinaie.

Capitolele i acoper configurarea programelor smail i sendmail. Aceast carte le explic pe amndou deoarece smail e mai uor de instalat pentru nceptori n vreme ce sendmail este mai flexibil.

Capitolele i explic felul cum tirile sunt manevrate un Usenet i cum putei 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 reeau dumneavoastr local. In sfrit, capitolul v nva cum s configurai i s ntreinei diferite programe de citit tiri.

Cap. 2. Ideile principale pentru reelele TCPIP Cuprins Interfee de reea Adrese IP Cutarea adreselor Rutarea IP

Vom intra acum in amanuntele de care vei avea nevoie cnd v vei conecta calculatorul la o reea TCP/IP. Astfel vom discuta despre adrese IP, nume de gazd precum vom discuta i cteva chestii despre rutare. Acest capitol v va oferi informaiile de baz de care avei nevoie pentru a nelege configuraia pe care dorii s o realizai, n timp ce capitolele urmtoare se vor ocupa de instrumentele necesare pentru realizarea configuraiei dorite.

Interfee de reea Pentru a ascunde diversitea echipamentelor ce pot fi folosite intr-o reea, TCP/IP definete o interfa abstract prin care sunt accesate dispozitivele fizice (hardware). Aceast interfaa ofer o mulime de operaii care sunt identice pentru toate tipurile de dispozitive fizice i care n principal se ocup cu primirea i trimiterea pachetelor.

Fiecrui dispozitiv periferic pe care vei vrea s-l folosii pentru reea, i va corespunde o interfa in nucleu. De exemplu interfeele Ethernet se numesc eth0 i eth1 iar interfeele SLIP se numesc sl0, sl1, etc. Aceste nume de interfee sunt folosite pentru configurare, i anume atunci cnd vei vrea s v referii la un dispozitiv fizic particular. Ele nu au nici o nsemntate mai presus de aceasta.

Pentru a putea fi folosit intr-o reea TCP/IP, o interfaa trebuie s aib asociat o adres IP care folosete pentru identificarea interfeei respective cnd comunic cu restul lumii. Aceast adres este diferit de numele interfeei pe care l-am menionat adineauri; dac comparm o interfa cu o u, atunci adresa ei este ca plcua cu numele lipit pe ea.

Desigur sunt i ali parametri ai dispozitivului care pot fi setai; unul dintre acetia este mrimea maxim a unei datagrame ce poate fi procesat de un anumit dispozitiv hardware, care se mai numete i MTU (Maximal Transfer Unit). Vom introduce mai trziu i alte caracteristici ale dispozitivelor de reea.

Adrese IP Precum am menionat n capitolul precedent, adresele folosite n protocolul IP sunt numere pe 32 de bii. Fiecare maon trebuie s aib un numr unic. Dac avei o reea local ce nu are conexiune TCP/IP cu alte reele putei s v alegei numere dup cum dorii. Ins, pentru maini legate la Internet, numerele sunt date de ctre o organizaie central, i anume NIC (Network Information Center).

Pentru citirea mai uoar, adresele IP sunt mprite n patru numere de 8 bii numite octei. 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 folosete aceast notaie este c adresele IP sunt mprite in numere de reea, care sunt coninute in octeii din fa, i numere de gazde, care reprezint restul. Cnd cerei de la NIC adrese IP, nu vei obine cte o adres pentru fiecare gazd pe care vei vrea s o folosii ci vei obine un numr de reea i vei putea folosi toate adresele IP valide n cadrul acestui reele.

In funcie de dimensiunea reelei, partea din adresa IP care reprezint numrul de gazd (host number) poate fi mic sau mare. Pentru diferitele nevoi, exist cteva clase de reele, definind diferite impriri ale adreselor IP:

Clasa A cuprinde reelele de la 1.0.0.0 pn la 127.0.0.0. Numrul de reea este coninut n primul octet. Aceasta ofer un 24 de bii pentru numrul gazdei, permind n jur de 1,6 milioane de gazde.

Clasa B conine reelele de la 128.0.0.0 pna la 191.255.0.0; numrul de reea este n primii doi octei. Aceasta permite 16320 reele cu cte 65024 gazde fiecare.

Clasa C conine reelele de la 192.0.0.0 pn la 223.255.255.0 cu numrul de reea fiind coninut n primii trei octei. Aceasta permite existena a aproape 2 milioane de reele cu cte 254 de gazde fiecare.

Clasele D,E i F conin adrese ntre 224.0.0.0 pna la 254.0.0.0 i sunt fie experimentale fie sunt rezervate pentru viitor i nu specific nici o reea.

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 ai 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 toi octeii 0 sau 255 sunt rezervate pentru scopuri speciale. O adres unde toate prile corespunztoare gazdei sunt zero se numete adres de reea iar dac toate prile corespunztoare gazdei sunt 1 se numete adres broadcast????. Aceasta din urm se refer simultan la toate gazdele dintr-o anumit reea. Astfel 149.76.255.255 nu este o adres de gazd valid, dar se refer la toate gazdele reelei 149.76.0.0.

Exist dou adrese de reea ce sunt rezervate, i anume 0.0.0.0 i 127.0.0.0. Prima se numete ruta implicit (default route), iar cea din urm se numete adresa loopbak????. Ruta implicit are legtur cu felul n care IP-ul ruteaz datagramele, despre care vom vorbi mai jos.

Reeaua 127.0.0.0 este rezervat pentru traficul IP local ctre gazda local. De obicei, adresa 127.0.0.1 va fi asociat unei interfee 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 main din reea. Acesta v ofer posibilitatea s dezvoltai i

s testai software de reea far s folosii o reea real. Alt aplicaie folositoare este cnd vrei s folosii software de reea pe o main care nu este n reea. Aceasta nu este att de neobinuit pe ct sun; de exemplu multe gazde UUCP nu au conectivitate IP de loc, ns vor rula serverul de news INN. Pentru a funciona bine, INN cere interfaa loopback.

Cutarea adreselor Acum c ai vzut cum sunt construite adresele de reea IP, poate v vei ntreba cum sunt ele folosite intr-o reea Ethernet pentru a comunica cu alte gazde. La urma urmei protocolul Ethernet identific gazdele printr-un numr pe 6 octei care nu are nimic n comun cu o adres IP. Din cauza aceasta este nevoie de un mecanism pentru a face legtura ntre adrese IP i adrese Ethernet. Acesta este aa numitul Adress Resolution Protocol (ARP) - protocol de cutare al adreselor . De fapt ARP nu este legat de Ethernet neaprat ci este folosit i la alte tipuri de reele ca de exemplu la reelele radio. Ideea care st la baza ARP este ceea ce fac cei mai muli oameni cnd vor s-l gseasc pe dl X ntre 150 de oameni: merg i l strig pe nume fiind sigur c acesta va rspunde dac este acolo.

Cnd ARP vrea s gseasc adresa Ethernet corespunztoare unei adrese IP, folosete o proprietate a protoculului Ethernet numit "rspndire" (broadcasting), cnd o datagram este adresat simultan tuturor staiilor din reea. Diagrama aceasta conine o ntrebare pentru a afla adresa IP. Fiecare gazd din reea compar adresa IP din datagrama primit cu propria adres IP, i dac se potrivesc i ntoarce un rspuns ARP gazdei care a fcut cererea. Aceast gazd poate extrage acum, din rspuns, adresa Ethernet.

Desigur v putei ntrba cum poate tii o gazd care din milioanele de maini cu Ethernet din lume este gazda cutat i cum poate tii c aceasta posed interfa Ethernet. Aceste intrebri i afl rspunsul n ceea ce se numete rutare (routing), care se ocup cu gsirea locaiei fizice a unei gazde ntr-o reea. Acesta va fi subiectul urmtoarelor seciuni.

Pentru moment s mai vorbim un pic despre ARP. Odat ce o gazd a descoperit o adres Ethernet, o va ine minte astfel nct s nu mai trebuiasc s ntrebe din nou data viitoare cnd va vrea s trimit o datagram gazdei cu pricina. Ins nu este bine s pstreze acest informaie totdeauna; de exemplu gazda de la distan i poate schimba placa de reea din cauza problemelor tehnice, deci intrarea ARP devine invalid. Pentru a fora alt intrebare, intrrile n memoria ARP trebuiesc terse din cnd n cnd.

Cteodat este necesar gsirea adresei IP asociate unei adrese Ethernet date. Aceasta se ntmpl cnd o main fr disc vrea s booteze de pe un server din reea, situaie des

ntlnit n reelele locale. On client fr disc nu are nici o informaie despre el nsui - n afar de adresa Ethernet! Aa c va trimite un mesaj rspndit (broadcast) coninnd o rugminte ctre 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 definete metoda prin care clienii fr disk pot boota de pe un server din reea.

Rutarea IP Reele IP Cnd scriei o scrisoare cuiva, de obicei punei adresa complet pe plic, specificnd ara, codul potal, etc. Dup ce punei scrisoarea n cutia potal, serviciul potal o va duce la destinaie: ea va fi trimis n ara indicat, ar al crei serviciu de pot o va trimite n regiunea specificat, etc. Avantajul acestei scheme ierarhice este evident: oriunde vei trimite scrisoarea serviciul local va tii n mare direcia n care s trimit scrisoarea ns nu trebuie s se preocupe pe ce cale va ajunge scrisoarea pn la distinaie.

Reelele IP sunt structurate ntr-un mod analog. Intregul Internet este format dintr-un numr de reele chemate sisteme autonome. Fiecare astfel de sistem realizeaz rutarea intern ntre membrii ei astfel nct sarcina trimiterii datagramei este redus la gsirea unei ci ctre reeaua din care face parte gazda destinatar. Aceasta nseamn c ndat ce datagrama este nmnat oricrei gazde din reeaua gazdei destinatare, rutarea va fi fcut mai departe de crtre reeaua nsi.

Subreele Aceast structur este obinut prin mprirea adresei IP ntr-o parte corespunztoarei gazdei i ntr-o parete corespunztoare reelei, aa cum am artat mai sus. Implicit reeaua destinatar este dedus din partea de reea a adresei IP. Astfel, gazdele cu numere de reea identice ar trebui s se gseasc in interiorul aceleiai reele.

Are sens s folosim o schem asemntoare nuntrul unei reele de vreme ce o reea poate fi format din sute de reele mai mici. Astfel protocolul IP, v d voie s mprii o reea IP n mai multe subreele .

O subreea are responsabilitate trimiterii datagramelor anumitor clase de adrese IP din reeaua IP din care face parte. La fel cu clasele A, B sau C ele sunt definite de o parte de

reea din adresa IP. Ins acum partea de reea este extins astfel nct cuprinde civa bii din parte de gazd. Numrul de bii ce sunt interpretai ca numrul de subreea este dat de aa numita masc de reea (subnet mask sau netmask) sa. Aceasta este un numr pe 32 de bii care specific masca de bii pentru partea de reea a adresei IP.

Figura Fig. 2-1 arat cum 149.76.12.4, adresa lui quark este interpretat diferit cnd este considerat o reea obinuit de clas B, sau cnd se folosesc subreele.

Fig. 2-1. Imprirea unei reele de clas B n subreele

Dac subreelele ar fi numai diviziuni interne ale reelei atunci acestea nu ar fi de mare folos. Subreelele sunt generate de proprietarul reelei pentru a reflecta graniele existente fie ele fizice (ntre dou reele Ethernet), administrative (ntre dou departamente) sau geografice. Ins aceast structur afecteaz numai comportarea intern a reelei, 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 $speedUsing 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: ==, !=, , =.

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 interfaa 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.

PPP deschis Deschis, functionalitatea PPP este impartita in doua parti, un driver low-level HDLC locat in kernel, un daemon pppd locat in spatiul utilizator care se ocupa de diversele protocoale de control. Versiunea curenta de PPP pentru linux este ppp-1.0.0 si contine modului PPP pentru kernel, pppd si un program numit chat utilizat pentru a stabili conexiunea catre calculatorul server (dial-up).

Driverul PPP pentru kernel a fost scris de Michael Callahan. pppd este derivat din implementarea libera PPP pentru masinile Sun si 386BSD, scris de Drew Pekins si altii, si mentinut de Paul Mackerras. A fost portat de Al Longyear. ( link )

La fel ca si SLIP, PPP este implementat conform unei discipline speciale de linie. Pentru a folosi o linie seriala ca si legatura PPP, intii trebuie si stabiliti o conexiune cu un

modem uzual, apoi sa convertiti linia la modul PPP. In acest mod, toate datele primite vor fi trecute driverul PPP, care verifica cadrele HDLC care vin pentru validitate (fiecare cadru HDLC duce cu el un checksum pe 16 biti), dupa care le despacheteaza si le trimite mai departe. In mod curent, el este abil sa se ocupe de datagramele IP, optional utilizind algoritmul Van-Jacobson pentru compresia headerului. Suportind protocolul IPX, driverul PPP se va extinde pentru a manipula si pachetele IPX, deasemenea.

Driverul de kernel este ajutat de pppd, daemon-ul PPP, care face intreaga initializare si faza de autentificare care este necesara inainte ca traficul de pe retea sa fie trimis prin legatura. Comportamentul daemon-ului pppd poate fi setat fin utilizind un numar de optiuni. Cum PPP e cam complex, este imposibil de explicat totul despre el intr-un singur capitol. Aceasta carte nu poate acoperi toate aspectele lui pppd, dar va poate da un punct de plecare. Pentru mai multe informatii va recomand paginile manualului si README-ul din codul sursa al distributiei pppd, care ar trebui sa va ajute rapid in majoritatea problemelor pe care acest capitol nu le-a putut atinge. Daca problema persista si dupa ce ati citit toata documentatia, ar tebui sa va abonati la newsgroup-ul comp.protocols.ppp pentru mai mult ajutor, care este locul unde majoritatea celor implicati in dezvoltarea pppd sunt de gasit.

Cap. 5. Sistemul informational al retelei (NIS) Cuprins S facem cunotin 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 tradiional

n cazul unei reele locale (LAN), scopul final este de obicei crearea unui mediu n care utilizatorii s poat folosi reeaua ct mai transparent. Un pas important n ndeplinirea acestui scop este sincronizarea ntre host-uri a informaiilor vitale (de exemplu informaiile legate de conturile utilizatorilor). Mai nainte am vzut 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 reeaua 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 funcii generice de acces la baze de date care pot fi folosite la distribuirea diferitelor informaii, de pild cele coninute n fiierele passwd i groups, acestea devenind accesibile pentru toate host-urile din reea. Astfel, reeaua apare ca un singur sistem, cu aceleai conturi pe toate host-urile. n acelai mod putei folosi NIS pentru a distribui informaiile din /etc/hosts ctre toate calculatoarele din reea.

NIS se bazeaz pe RPC i cuprinde un server, o bibliotec pentru client i cteva utilitare de administrare. Iniial 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 renune la nume. n ciuda acestui lucru, oamenii renun greu la denumirile cu care s-au obinuit, aa c YP a rmas prefixul majoritii comenzilor care se refer la NIS: ypserv, ypbind, etc.

Acum, NIS este disponibil pentru oricine, existnd chiar implementri free. Una dintre acestea face parte din BSD Net-2 i se bazeaz pe o implementare pus la dispoziia publicului larg de ctre Sun. Biblioteca pentru client a existat n GNU libc de mult timp, n comparaie cu utilitarele - care au fost portate relativ de curnd de ctre Swen Thmmler. Din implementarea de referin lipsete 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 att NIS ct i NIS+ (varianta revizuit). NYS nu ofer doar un set de utilitare NIS i un server, ci i un set complet nou de funcii 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 nlocuiete schema actual care folosete host.conf. Aceste funcii 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 ``tradiional''. Dac dorii s utilizai unul dintre acestea dou, instruciunile din acest capitol ar putea fi suficiente, dar s-ar putea i s nu fie. Pentru informaii suplimentare consultai 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 reea sau programul login) nu cunosc schema de configurare NYS. Atta timp ct NYS nu este inclus n libc va trebui s recompilai programele care dorii foloseasc NYS. Pentru oricare dintre aceste aplicaii, adugai n Makefile opiunea -lnsl chiar nainte de libc. Astfel n loc de funciile bibliotecii C standard vor fi link-ate funciile din libnsl -- biblioteca NYS.

S facem cunotin cu NIS NIS pstreaz informaiile bazei de date n aa numitele map-uri care conin perechi de valori-cheie. Map-urile sunt stocate pe un anumit host pe care ruleaz serverul NIS, de unde clienii pot obine informaiile prin diferite call-uri RPC. Destul de frecvent, map-urile sunt stocate n fiiere DBM.

Map-urile n sine sunt de obicei generate din fiierele text originale cum sunt /etc/hosts i /etc/passwd. Pentru unele fiiere sunt create mai multe map-uri, cte unul pentru fiecare tip de cheie de cutare. De exemplu, n fiierul hosts se poate cuta 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 putei vedea o list cu map-urile tipice i fiierele din care sunt generate.

Table: Cteva map-uri NIS standard NIS i fiierele corespunztoare. ????????????????????

S-ar putea ca n unele pachete NIS s gsii suport i pentru alte fiiere i map-uri. Acestea conin informaii pentru aplicaii care nu sunt abordate n acest carte, de pild bootparams folosit de unele servere BOOTP (map-urile corespunztoare sunt ethers.byname i ethers.byaddr).

De obicei, n loc de unele map-uri se folosesc nicknames (porecle), care sunt mai scurte i mai uor de tastat. Pentru a obine lista complet a nicknames-urilor recunoscute de utilitarele NIS putei folosi comanda:

Serverul NIS este numit, prin tradiie, ypserv. ntr-o reea de mrime medie, un server NIS este n general suficient; n reelele mari ns, se poate s fie necesare servere diferite pentru diferite hosturi i pentru diferite segmente ale reelei, 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 pn acum am vorbit foarte vag despre ``reele''; n cadrul reelei, NIS vine cu un concept distinct: domeniul NIS care este totalitatea host-urilor care cu ajutorul NIS distribuie n cadrul reelei o parte din configuraia lor. Domeniile NIS nu au nimic comun cu domeniile ntlnite la DNS, aa c pentru a evita orice ambiguitate, voi specifica de fiecare dat la care tip de domeniu m refer.

Funcia domeniilor NIS este una pur administrativ. Ele sunt aproape invizibile pentru utilizatori: acetia nu sezizeaz dect folosirea acelorai 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 condiia s fie unic n cadrul

reelei 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 putei folosi comanda domainname. Dac nu precizai nici un argument, va afia doar numele curent al domeniului NIS; pentru a schimba acest nume, trebuie s fii superuser i s tastai:

n funcie de domeniile NIS se stabilete serverul NIS pe care l poate accesa o aplicaie. De exemplu, programul login de pe un host de la Winery trebuie, desigur, s cear informaiile 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 aplicaie de pe un host de la Brewery trebuie s acceseze numai serverul de la Brewery.

Acum nu mai rmne de dezlegat dect un singur mister : cum afl un client la care server s se conecteze? Cea mai simpl soluie este folosirea unor fiiere de configurare locale, ns acest soluie nu este flexibil, pentru c nu permite clienilor s foloseasc mai multe servere (bineneles n cadrul aceluiai domeniu). De aceea, implementrile NIS tradiionale folosesc un daemon special - ypbind care detecteaz un server NIS potrivit din cadrul domeniului NIS. nainte de a specifica orice cerere (query) NIS, aplicaiile trebuie s afle mai nti de la ypbind ce server s folosesc.

ypbind detecteaz serverele prin broadcasting pe reeaua IP local; primul server care rspunde este considerat a fi cel mai rapid i va fi folosit pentru toate query-urile NIS urmtoare. Dup un anumit timp sau dac serverul nu mai este disponibil, ypbind va ncerca iari s gseasc un server activ.

Aceast legare dinamic la diverse servere are o serie de aspecte discutabile. n primul rnd este rareori necesar, i n plus slbete gradul de securitate al reelei: ypbind nu e n stare s deosebeasc un server NIS obinuit de un intrus ru intenionat. Acesta devine o problem i mai grav dac bazele de date cu parole sunt administrate prin NIS. Din acest cauz, NYS nu folosete n mod implicit ypbind, ci citete hostname-ul serverului dintr-un fiier de configurare.

NIS versus NIS+ NIS i NIS+ au puine lucruri n comun: asemnarea numelor i destinaia. NIS+ este structurat ntr-o manier complet diferit. n locul unui spaiu format din domenii NIS separate, NIS+ folosete un spaiu ierarhic similar celui folosit de DNS. n locul map-urilor exist aa-numitele tabele constituite din rnduri i coloane. Fiecare rnd reprezint un obiect n baza de date NIS+, iar coloanele sunt proprietile obiectelor gestionate de NIS+. Tabela fiecrui domeniu NIS+ include tabelele domeniilor 'printe'. De asemenea

o nregistrare dintr-o tabel poate conine un link ctre o alt tabel. Aceste faciliti ofer posibiliti multiple de organizare a informaiilor.

Varianta tradiional 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 puin. (eh! nu se poate spune c nu tiu chiar nimic) De aceea nu-l voi aborda n aceast documentaie. Dac dorii s aflai mai multe despre NIS+ putei consulta manualul de administrare NIS+ de la Sun. ([]).

NIS: Partea de Client Dac suntei familiarizai cu scrierea sau portarea aplicaiilor de reea vei observa c majoritatea map-urilor NIS listate mai sus corespund unor funcii din biblioteca C. De exemplu, pentru a obine informaii din passwd se folosesc de obicei funciile getpwnam(3) i getpwuid(3) care returneaz informaiile despre contul unui utilizator regsit dup user name, respectiv user id. n mod obinuit aceste funcii caut informaiile dorite n fiierul standard: /etc/passwd.

n cazul unei implementri care utilizeaz NIS, aceste funcii vor fi modificate n sensul c trimit ctre serverul NIS un call RPC prin care este localizat numele i id-ul utilizatorului. Acest comportament este total transparent pentru aplicaie. Funcia poate fie s adauge elemente n map-ul NIS, fie s nlocuiasc cu totul fiierul original. Bineneles, nu are loc o modificare real a fiierului, ci doar este creat iluzia c acesta a fost nlocuit sau modificat.

n implementrile NIS tradiionale existau mai multe convenii referitoare la care map-uri nlocuiesc i care se adaug la informaiile originale. Unele, cum sunt map-urile passwd, necesitau modificri ale fiierului passwd care dac nu erau fcute corect afectau serios securitatea sistemului. Pentru a evita aceste capcane, NYS folosete o schem general de configurare care determin dac pentru un set de funcii client de folosesc fiierele originale, NIS, sau NIS+, i n ce ordine. Capitolul curent include o seciune special despre aceast chestiune.

Rularea unui server NIS Poate c v-ai plictisit de teoria de pn acum, aa c hai s ne punem pe treab i s ne apucm de configurarea propriu-zis. n acest seciune vom discuta despre configurarea unui server NIS. Dac n reeaua dumneavoastr funcioneaz deja un server NIS, nu mai este nevoie s setai nimic ( i putei sri fr grij peste acest seciune ).

Dac nu dorii altceva dect s experimentai, s "v jucai" cu setarea serverului, avei grij s nu folosii un nume al domeniului NIS care exist deja n reea. Altfel s-ar putea s destabilizai ntregul serviciu de reea, iar muli oameni ar putea deveni nemulumii i chiar foarte nervoi.

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 folosii. n momentul acesta, cnd scriu, codul pentru manipularea serverelor NIS de tip slave pare s fie mai complet n yps. Deci dac avei nevoie de servere slave, probabil c yps este o alegere mai bun.

Dup instalarea severului (programul ypserv) n /usr/sbin, urmeaz s creai directorul care va conine fierele map pe care le va distribui serverul. Cnd setai domeniul NIS pentru brewery map-urile vor fi puse n /var/yp/brewery. Serverul determin dac deservete un anumit domeniu NIS dup existena directorului cu map-uri. Dac la un moment dat dorii s dezactivai un domeniu NIS, asigurai-v c ai ters i directorul.

n general, map-urile sunt pstrate n fiiere DBM, care sunt generate din fiierele 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 fiier 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 reinut. De aceea pachetul ypserv al lui Peter Eriksson conine un Makefile (numit ypMakefile) care face toat acest munc n locul dumneavoastr. Trebuie s instalai acest fiier sub numele Makefile n directorul cu map-uri, apoi s-l editai pentru a alege map-urile pe care dorii s le distribuii. Pe la nceputul fiierului se targetul all care conine toate serviciile pe care le poate oferi ypserv. n mod implicit, linia arat cam aa :

Dac de pild nu avei nevoie de map-urile ethers.byname i ethers.byaddr, pur i simplu tergei ethers din acest rule. Pentru a testa configuraia probabil c este suficient pornirea a una sau dou map-uri, de exemplu services.*.

Dup ce ai editat Makefile, rmnei n directorul cu map-uri i tastai ``make''. Map-urile vor fi generate i instalate automat. Trebuie s refacei map-urile la fiecare modificare a fiierelor master, altfel schimbrile nu vor fi disponibile n reea.

n seciunea urmtoare putei afla cum se configureaz codul NIS pentru client. Dac setrile dumnevoastr nu merg, trebuie s aflai mai nti dac cererile ajung sau nu la server. Dac la pornirea serverului specificai opiunea -D, acesta va tipri la consol mesaje referitoare toate cererile NIS primite i la rezultatele acestora. Aceste mesaje ar trebui s v ajute s aflai de unde provine problema. Serverul lui Tobias nu are aceast opiune.

Setarea unui client NIS cu NYS De acum ncolo, n acest capitol vom aborda configurarea clienilor NIS.

Primul pas este setarea n /etc/yp.conf a serverului NYS care va fi folosit. Ca exemplu, iat un fiier foarte simplu pentru un host din reeaua Winery:

Prima linie a fiierului specific toi clienii NIS care aparin domeniului NIS winery. Dac omitei acest linie NYS va folosi numele de domeniu pe care l-ai setat cu comanda domainname. Mai departe se specific serverul NIS care va fi folosit. Desigur, adresa IP a serverului vbardolino trebuie specificat n fiierul hosts; putei dealtfel s folosii direct adresa IP.

Din cauza comenzi server din fiierul de configurare de mai sus, NYS va folosi serverul specificat indiferent de domeniul NIS curent. Dac n mod frecvent se ntmpl s mutai calculatorul n mai multe domenii NIS probabil c vei dori s pstrai n fiierul yp.conf informaiile referitoare la mai multe domenii NIS. De exemplu, n cazul unui laptop fiierul 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 ai creat acest fiier de configurare minimal i dup ce ai verificat c poate fi citit de ctre toi utilizatorii, urmeaz s facei primul test : prima conectare la server. Alegei orice map distribuit de server, de pild hosts.byname, i ncercai s-l obinei folosind utilitarul ypcat. La fel ca toate celelalte utilitare de adminstrare, ypcat ar trebui s se gseasc n /usr/sbin.

Output-ul pe care l vei obine 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 asemntor, nseamn c fie numele domeniului NIS pe care l-ai setat nu corespunde nici unui server definit n yp.conf, fie c serverul este inaccesibil dintr-un motiv oarecare. n al doilea caz, verificai dac ping raporteaz c poate accesa serverul i dac da,

verificai dac este ntr-adevr vorba de un server NIS. Pentru acesta folosii rpcinfo care ar trebui s afieze un output de genul :

Alegerea map-urilor corecte Dup ce v-ai convins c putei contacta serverul NIS, trebuie s decidei care fiiere s le nlocuii sau s le ntregii cu map-uri NIS. n mod tipic, probabil c vei dori s folosii map-uri NIS pentru host i pentru passwd. Primul este util mai ales cnd nu folosii BIND, iar al doilea permite tuturor utilizatorilor s se conecteze de la orice host din reea; acesta necesit existena unui director /home central, disponibil n toat reeaua prin NFS. n seciunea - putei gsi informaii detaliate despre cum se realizeaz aceasta. Alte map-uri, cum este services.byname, nu sunt la fel de spectaculoase, dar v pot scpa de ceva munc de editare n cazul n care instalai aplicaii de reea care folosesc un serviciu care nu este n fiierul services standard.

Probabil c dorii s putei alege dac o funcie folosete fiierul local sau serverul NIS. NYS v permite s configurai ordinea n care o funcie acceseaz aceste servicii. Fiierul de configurare este /etc/nsswitch.conf (nss vine de lar Name Service Switch), dar bineneles c nu este limitat doar la name service. Acest fiier conine cte o linie pentru fiecare funcie suportat de NYS.

Ordinea corect a serviciilor depinde de tipul datelor. Este improbabil ca map-ul services.byname s conin nregistrri diferite de cele din fiierul services local; poate eventual s conin nregistrri n plus. Astfel, ar fi o alegere bun ca mai nti s fie consultat fiierul local doar dac nu este gsit serviciul dorit s se apeleze la NIS. Pe de alt parte, informaiile referitoare la hostnames se pot schimba foarte frecvent, astfel c n general serverele DNS sau NIS dein cele mai actualizate informaii, pe cnd fiierul hosts local este pstrat doar ca rezerv pentru cazul n care serverul DNS sau NIS pic. Astfel c n aceste condiii este de dorit ca fiierul local s fie consultat ultimul.

Exemplul de mai jos arat cum se pot configura funciile gethostbyname(2), gethostbyaddr(2) i getservbyname(2) ca s funcioneze n modul descris mai sus. Ele vor ncerca iniial primul serviciu; n cazul unui succes se returneaz rezultatul, altfel este ncercat urmtorul serviciu.

Mai jos se gsete lista complet a serviciilor care pot fi folosite cu o nregistrare n fiierul nsswitch.conf. Map-urile, fiierele, serverele i obiectele care vor fi consultate depind de numele nregistrrii.

n momemtul de fa, NYS suport urmtoarele nregistrri n nsswitch.conf: hosts, networks, passwd, group, shadow, gshadow, services, protocols, rpc, i ethers. Probabil cse vor mai aduga i altele.

Figura- ilustreaz un exemplu i mai complet care introduce o alt facilitate a nsswitch.conf: cuvntul-cheie [NOTFOUND=return] n nregistrarea hosts, datorit cruia dac nu este gsit elementul cutat, NYS va continua cu cutarea n fiierele locale numai dac consultarea serverelor NIS i DNS a euat. Fiierele locale vor fi astfel folosite numai la bootare i ca o copie de siguran pentru cazul cnd serverul NIS nu este accesibil.

Figure: Sample nsswitch.conf file.????????????/

Folosirea map-urilor passwd i group Unul dintre rolurile eseniale pa cere le joac NIS este sincronizarea informaiilor despre utilizatori i conturile lor n cadrul domeniului NIS. n acest scop, se pstreaz de obicei un fiier /etc/passwd minimal la care se adaug informaiile din map-urile NIS (care sunt disponibile n tot domeniul). Simpla activare a acestora n nsswitch.conf nu este ns de ajuns.

Atunci cnd folosii NIS pentru distribuirea informaiilor referitoare la parole trebuie mai nti s v asigurai c user id-urile utilizatorilor din fiierul 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 modificai proprietarul (owner) pentru toate fiierele utilizatorului respectiv. Mai nti trebuie s setai noile valori ale uid-urilor i gid-urilor n passwd respectiv group. Apoi localizai toate fiierele utilizatorului i le schimbai 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 folosii urmtoarele comenzi:

Este important s apelai aceste comenzi avnd instalat noul fiier passwd i s colectai toate numele fiierelor userului nainte de chown. Pentru a modifica apartenena la grupuri a fiierelor se folosete o comand similar.

Dup de ai fcut aceasta, uid-urile i gid-urile numerice locale vor corespunde cu cele din ntregul domeniu NIS. Urmtorul pas este adugarea n nsswitch.conf a liniilor care activeaz localizarea prin NIS a informaiilor despre utilizatori i grupuri:

Ca efect, atunci cnd un utilizator ncearc s se conecteze, comanda login sau alte comenzi asemntoare vor consulta mai nti map-urile NIS i doar n caz de nereuit vor consulta fiierele locale. n general probabil c vei scoate aproape toi userii din fiierele

locale, lsnd 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 fiierul passwd local exist riscul ca aceste joburi s eueze foarte urt dac NIS nu este disponibil n acel moment.

M simt dator s dau aici dou avertismente importante: n primul rnd, configurrile descrise mai sus funcioneaz numai pentru suite login care nu folosesc shadow passwords ( cum este cea inclus n pachetul util-linux ). Complicaiile aduse de folosirea parolelor shadow vor fi abordate n seciunea urmtoare. n al doilea rnd, comenzile de genul login nu sunt singurele care acceseaz fiierul passwd-- de pild chiar i banalul ls face parte din aceast categorie. De fiecare dat cnd este apelat ls cu opiunea -l (long listing), vor fi afiate numele simbolice pentru grupul i proprietarul fiecrui fiier, ceea ce implic de fiecare dat o conectare la serverul NIS. Se poate ntmpla ca din acest cauz viteza s scad foarte mult, mai ales dac reeaua este suprancrcat sau dac, mai grav, serverul NIS nu este n aceeai reea fizic i datagramele trebuie s treac printr-un router.

i asta nu e totul. Imaginai-v c un utilizator vrea s-i schimbe parola. n mod normal, va apela passwd care citete noua parol i modific fiierul passwd local. Acest lucru este imposibil cnd se folosete NIS, deoarece fiierul nu mai este disponibil local, iar a permite utilizatorilor s se conecteze la serverul NIS de fiecare dat cnd vor s-i schimbe parola nu este o soluie. Din aceste motive NIS vine cu o versiune proprie a passwd numit yppasswd. Pentru a schimba parola pstrat pe server, yppasswd contactez daemonul yppasswdd de pe server via RPC, i comunic noile informaii. Pentru a instala yppasswd peste programul passwd clasic se procedeaz n felul urmtor:

De asemenea trebuie s instalai pe server rpc.yppasswdd i s-l pornii din rc.inet2. Astfel li se va ascunde utilizatorilor aceast ciudenie 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 curnd pe comp.sources.misc o nou versiune a bibliotecii de funcii shadow care suport parial NIS, deci e incomplet i nu a fost nc n biblioteca C standard libc. Pe de alt parte, publicarea cu NIS a informaiilor din /etc/shadow contravine scopului pe care l are shadow !

Dei funciile NYS referitoare la password nu folosesc map-ul shadow.byname sau ceva similar, NYS permite n mod transparent folosirea unui fiier /etc/shadow. Cnd este apelat implementarea NYS a funciei getpwnam sunt utilizate specificaiile din cmpul passwd din nsswitch.conf. Serviciul NIS va localiza informaiile cerute n map-ul

passwd.byname de pe serverul NIS. Totui, serviciul files va verifica existena fiierului /etc/shadow, i dac l gsete va ncerca s-l deschid. Dac nu exist sau dac userul nu este root, se va reveni la comportamentul clasic: cutarea informaiilor numai n /etc/passwd. Dac /etc/shadow exist i poate fi deschis, NYS va lua din shadow parola utlizatorului. Funcia getpwuid este implementat n mod similar. Astfel, executabilele compilate cu NYS se vor descurca n mod transparent cu o configurare care folosete shadow.

Folosirea codului NIS tradiional Dac folosii codul client inclus n versiunea standard curent a libc, configurarea clientului NIS este un pic diferit. n primul rnd, n loc s obin informaiile despre serverele NIS dintr-un fiier de configuraie, folosete daemonul ypbind pentru localizarea serverelor active. Deci trebuie s v asigurai c ypbind este ncrcat 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 curnd s-a raportat multe ori un bug care se manifest prin aceea c NIS eueaz returnnd ``clntudp_create: RPC: portmapper failure - RPC: unable to receive''. Aceast eroare se datoreaz unei modificri incompatibile a modului cum ypbind returneaz informaiile ctre funciile de bibliotec. Dac obinei ultimele surse ale utilitarelor NIS i le compilai ar trebui s scpai de acest problem.

De asemenea, modul n care NIS-ul tradiional decide dac i cum s fac mbinarea informaiilor NIS cu cele din fiierele locale difer fa de NYS. De exemplu, pentru a folosi map-uri password va trebui s includei urmtoarea linie n /etc/passwd:

Aceasta marcheaz locul unde funciile de localizare pentru password insereaz map-urile NIS. Inserarea unei linii similare (mai puin ultimele dou puncte) n /etc/group face acelai lucru pentru map-urile group.* . Pentru a distribui prin NIS map-urile hosts.* trebuie s schimbai ordinea liniilor n host.conf file. De pild, dac ordinea pe care o dorii este NIS, DNS, /etc/hosts s-ar putea s fie nevoie s modificai linia n

Implementarea NIS clasic nu suport alte map-uri la acest moment.