Ghidul Administratorilor de Reţea LinuxOlaf Kirch

Copyright © 1992-1994 de Olaf Kirch

Cuprins 1. Introducere în retele;

Retele 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 SocketCodul de Networking Diferite linii de dezvoltare De unde se poate obtine codulIntreţinerea sistemului Securitatea sistemuluiPrivire generală peste capitolele următoare

2. Ideile principale pentru retelele TCPIP Interfete de retea Adrese IP Cãutarea adreselor Rutarea IP Retele IP Subretele

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 cunostintã cu NIS NIS versus NIS+

NIS: Partea de Client Rularea unui server NIS Setarea unui client NIS cu NYS Alegerea map-urilor corecte Folosirea map-urilor passwd si group Folosirea NIS cu suport pentru Shadow Folosirea codului NIS traditional

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

Retele TCP/IPAlte tipuri de hardwareIn 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 InternetBine-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 serialeIn 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 porturiPorturile 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 SocketLa 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 NetworkingFiind 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 dezvoltareIntre 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 codulUltima 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 sistemuluiPe 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 sistemuluiUn 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ătoareCapitolele 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 si configurarea plãcii Ethernet. Configuratia porturilor seriale este tratatã într-un capitol separat, din cauzã cã discutia nu se aplicã numai retelelor TCP/IP dar este relevantã pentru UUCP.

Capitolul se ocupã cu configurarea unei masini pentru o retea TCP/IP. El contine informatii pentru instalarea unor gazde fãrã retea externa si a unor gazde conectate la o retea Ethernet.

Acesta este urmat de douã capitole care vã invatã cum sã folositi SLIP si PPP. Capitolul Cap. 3 explicã cum sã stabiliti o conexiune SLIP si vã oferã referinte detaliate despre dip, o unealtã care vã permite sã automatizati cei mai multi pasi. Capitolul Cap. 4 acoperã PPP si pppd, demonul PPP de care veti avea nevoie.

Capitolul vã oferã o scurtã introducere în configurarea celor mai importante aplicatii pentru retea precum rlogin,rcp, etc. De asemenea se discutã serviciile ce sunt manevrate de superserverul inetd si cum puteti restrictiona anumite servicii.

Capitolul vã oferã informatii pretioase despre administrarea programului Taylor UUCP care este o implementare free a suitei UUCP.

Restul cãrtii se ocupã cu un studiu detaliat al postei electronice si al serviciului de stiri. Capitolul introduce conceptele de bazã ale postei electronice precum forma unei adrese de mail si cum functioneazã sistemul furnizãrii e-mailurilor cãtre destinatie.

Capitolele si acoperã configurarea programelor smail si sendmail. Aceastã carte le explicã pe amândouã deoarece smail e mai usor de instalat pentru începãtori în vreme ce sendmail este mai flexibil.

Capitolele si explicã felul cum stirile sunt manevrate un Usenet si cum puteti instala si folosi C-news, un pachet software popular pentru manevrarea stirilor Usenet. Capitolul acoperã pe scurt configurarea demonului NNTP pentru a facilita accesarea stirilor din reteau dumneavoastrã localã. In sfârsit, capitolul vã învatã cum sã configurati si sã întretineti diferite programe de citit stiri.

Cap. 2. Ideile principale pentru retelele TCPIPCuprins Interfete de retea Adrese IP Cãutarea adreselor Rutarea IP

Vom intra acum in amanuntele de care veti avea nevoie când vã veti conecta calculatorul la o retea TCP/IP. Astfel vom discuta despre adrese IP, nume de gazdã precum vom discuta si câteva chestii despre rutare. Acest capitol vã va oferi informatiile de bazã de care aveti nevoie pentru a întelege configuratia pe care doriti sã o realizati, în timp ce capitolele urmãtoare se vor ocupa de instrumentele necesare pentru realizarea configuratiei dorite.

Interfete de reteaPentru a ascunde diversitea echipamentelor ce pot fi folosite intr-o retea, TCP/IP defineste o interfatã abstractã prin care sunt accesate dispozitivele fizice (hardware). Aceastã interfata oferã o multime de operatii care sunt identice pentru toate tipurile de dispozitive fizice si care în principal se ocupã cu primirea si trimiterea pachetelor.

Fiecãrui dispozitiv periferic pe care veti vrea sã-l folositi pentru retea, îi va corespunde o interfatã in nucleu. De exemplu interfetele Ethernet se numesc eth0 si eth1 iar interfetele SLIP se numesc sl0, sl1, etc. Aceste nume de interfete sunt folosite pentru configurare, si anume atunci când veti vrea sã vã referiti la un dispozitiv fizic particular. Ele nu au nici o însemnãtate mai presus de aceasta.

Pentru a putea fi folositã intr-o retea TCP/IP, o interfata trebuie sã aibã asociatã o adresã IP care foloseste pentru identificarea interfetei respective când comunicã cu restul lumii. Aceastã adresã este diferitã de numele interfetei pe care l-am mentionat adineauri; dacã comparãm o interfatã cu o usã, atunci adresa ei este ca plãcuta cu numele lipitã pe ea.

Desigur sunt si alti parametri ai dispozitivului care pot fi setati; unul dintre acestia este mãrimea maximã a unei datagrame ce poate fi procesatã de un anumit dispozitiv hardware, care se mai numeste si MTU (Maximal Transfer Unit). Vom introduce mai târziu si alte caracteristici ale dispozitivelor de retea.

Adrese IPPrecum am mentionat în capitolul precedent, adresele folosite în protocolul IP sunt numere pe 32 de biti. Fiecare masonã trebuie sã aibã un numãr unic. Dacã aveti o retea localã ce nu are conexiune TCP/IP cu alte retele puteti sã vã alegeti numere dupã cum doriti. Insã, pentru masini legate la Internet, numerele sunt date de cãtre o organizatie centralã, si anume NIC (Network Information Center).

Pentru citirea mai usoarã, adresele IP sunt împãrtite în patru numere de 8 biti numite octeti. 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 foloseste aceastã notatie este cã adresele IP sunt împãrtite in numere de retea, care sunt continute in octetii din fatã, si numere de gazde, care reprezintã restul. Când cereti de la NIC adrese IP, nu veti obtine câte o adresã pentru fiecare gazdã pe care veti vrea sã o folositi ci veti obtine un numãr de retea si veti putea folosi toate adresele IP valide în cadrul acestui retele.

In functie de dimensiunea retelei, 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 retele, definind diferite impãrtiri ale adreselor IP:

Clasa A cuprinde retelele de la 1.0.0.0 pânã la 127.0.0.0. Numãrul de retea este continut în primul octet. Aceasta oferã un 24 de biti pentru numãrul gazdei, permitãnd în jur de 1,6 milioane de gazde.

Clasa B contine retelele de la 128.0.0.0 pâna la 191.255.0.0; numãrul de retea este în primii doi octeti. Aceasta permite 16320 retele cu câte 65024 gazde fiecare.

Clasa C contine retelele de la 192.0.0.0 pânã la 223.255.255.0 cu numãrul de retea fiind continut în primii trei octeti. Aceasta permite existenta a aproape 2 milioane de retele cu câte 254 de gazde fiecare.

Clasele D,E si F contin adrese între 224.0.0.0 pâna la 254.0.0.0 si sunt fie experimentale fie sunt rezervate pentru viitor si nu specificã nici o retea.

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ã ati 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 toti octetii 0 sau 255 sunt rezervate pentru scopuri speciale. O adresã unde toate pãrtile corespunzãtoare gazdei sunt zero se numeste adresã de retea iar dacã toate pãrtile corespunzãtoare gazdei sunt 1 se numeste adresã broadcast????. Aceasta din urmã se referã simultan la toate gazdele dintr-o anumitã retea. Astfel 149.76.255.255 nu este o adresã de gazdã validã, dar se referã la toate gazdele retelei 149.76.0.0.

Existã douã adrese de retea ce sunt rezervate, si anume 0.0.0.0 si 127.0.0.0. Prima se numeste ruta implicitã (default route), iar cea din urmã se numeste adresa loopbak????. Ruta implicitã are legãturã cu felul în care IP-ul ruteazã datagramele, despre care vom vorbi mai jos.

Reteaua 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 interfete speciale numitã interfatã loopback , care se comportã ca un circuit închis. Orice pachet IP trimis prin aceastã interfatã, va fi returnat

ca si cum ar fi venit de la o masinã din retea. Acesta vã oferã posibilitatea sã dezvoltati si sã testati software de retea farã sã folositi o retea realã. Altã aplicatie folositoare este când vreti sã folositi software de retea pe o masinã care nu este în retea. Aceasta nu este atât de neobisnuit pe cât sunã; de exemplu multe gazde UUCP nu au conectivitate IP de loc, însã vor rula serverul de news INN. Pentru a functiona bine, INN cere interfata loopback.

Cãutarea adreselorAcum cã ati vãzut cum sunt construite adresele de retea IP, poate vã veti întreba cum sunt ele folosite intr-o retea Ethernet pentru a comunica cu alte gazde. La urma urmei protocolul Ethernet identificã gazdele printr-un numãr pe 6 octeti 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 si adrese Ethernet. Acesta este asa numitul Adress Resolution Protocol (ARP) - protocol de cãutare al adreselor . De fapt ARP nu este legat de Ethernet neapãrat ci este folosit si la alte tipuri de retele ca de exemplu la retelele radio. Ideea care stã la baza ARP este ceea ce fac cei mai multi oameni când vor sã-l gãseascã pe dl X între 150 de oameni: merg si î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, foloseste o proprietate a protoculului Ethernet numitã "rãspândire" (broadcasting), când o datagramã este adresatã simultan tuturor statiilor din retea. Diagrama aceasta contine o întrebare pentru a afla adresa IP. Fiecare gazdã din retea comparã adresa IP din datagrama primitã cu propria adresã IP, si 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ã puteti întrba cum poate stii o gazdã care din milioanele de masini cu Ethernet din lume este gazda cãutatã si cum poate stii cã aceasta posedã interfatã Ethernet. Aceste intrebãri îsi aflã rãspunsul în ceea ce se numeste rutare (routing), care se ocupã cu gãsirea locatiei fizice a unei gazde într-o retea. Acesta va fi subiectul urmãtoarelor sectiuni.

Pentru moment sã mai vorbim un pic despre ARP. Odatã ce o gazdã a descoperit o adresã Ethernet, o va tine 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ã informatie totdeauna; de exemplu gazda de la distantã îsi poate schimba placa de retea din cauza problemelor tehnice, deci intrarea ARP devine invalidã. Pentru a forta altã intrebare, intrãrile în memoria ARP trebuiesc sterse 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 masinã fãrã disc vrea sã booteze de pe un server din retea, situatie des

întâlnitâ în retelele locale. On client fãrã disc nu are nici o informatie despre el însusi - în afarã de adresa Ethernet! Asa cã va trimite un mesaj rãspândit (broadcast) continâ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 defineste metoda prin care clientii fãrã disk pot boota de pe un server din retea.

Rutarea IPRetele IPCând scrieti o scrisoare cuiva, de obicei puneti adresa completã pe plic, specificând tara, codul postal, etc. Dupã ce puneti scrisoarea în cutia postalã, serviciul postal o va duce la destinatie: ea va fi trimisã în tara indicatã, tarã al cãrei serviciu de postã o va trimite în regiunea specificatã, etc. Avantajul acestei scheme ierarhice este evident: oriunde veti trimite scrisoarea serviciul local va stii în mare directia în care sã trimitã scrisoarea însã nu trebuie sã se preocupe pe ce cale va ajunge scrisoarea pânã la distinatie.

Retelele IP sunt structurate într-un mod analog. Intregul Internet este format dintr-un numãr de retele 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 reteaua din care face parte gazda destinatarã. Aceasta înseamnã cã îndatã ce datagrama este înmânatã oricãrei gazde din reteaua gazdei destinatare, rutarea va fi fãcutã mai departe de cãrtre reteaua însãsi.

SubreteleAceastã structurã este obtinutã prin împãrtirea adresei IP într-o parte corespunzãtoarei gazdei si într-o parete corespunzãtoare retelei, asa cum am arãtat mai sus. Implicit reteaua destinatarã este dedusã din partea de retea a adresei IP. Astfel, gazdele cu numere de retea identice ar trebui sã se gãseascã in interiorul aceleiasi retele.

Are sens sã folosim o schemã asemãnãtoare înãuntrul unei retele de vreme ce o retea poate fi formatã din sute de retele mai mici. Astfel protocolul IP, vã dã voie sã împãrtiti o retea IP în mai multe subretele .

O subretea are responsabilitate trimiterii datagramelor anumitor clase de adrese IP din reteaua IP din care face parte. La fel cu clasele A, B sau C ele sunt definite de o parte de retea din adresa IP. Insã acum partea de retea este extinsã astfel încât cuprinde câtiva biti

din parte de gazdã. Numãrul de biti ce sunt interpretati ca numãrul de subretea este dat de asa numita mascã de retea (subnet mask sau netmask) sa. Aceasta este un numãr pe 32 de biti care specificã masca de biti pentru partea de retea a adresei IP.

Figura Fig. 2-1 aratã cum 149.76.12.4, adresa lui quark este interpretatã diferit când este consideratã o retea obisnuitã de clasã B, sau când se folosesc subretele.

Fig. 2-1. Impãrtirea unei retele de clasã B în subretele

Dacã subretelele ar fi numai diviziuni interne ale retelei atunci acestea nu ar fi de mare folos. Subretelele sunt generate de proprietarul retelei pentru a reflecta granitele existente fie ele fizice (între douã retele Ethernet), administrative (între douã departamente) sau geografice. Insã aceastã structurã afecteazã numai comportarea internã a retelei, si este complet invizibilã lumii de afarã.

Cap. 3. IP pentru linie seriala Cuprins Referinta pentru dip Rularea in Modul Server

Referinta pentru dipComanda getComanda 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: 10get $locip remote

Comanda printAceasta 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 variabiledip 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 sleepAceste 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 defaultAceste 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 ServerSetarea 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 interfata 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-urilorLa 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 deschisDeschis, 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 cunostintã cu NIS NIS versus NIS+ NIS: Partea de Client Rularea unui server NIS Setarea unui client NIS cu NYS Alegerea map-urilor corecte Folosirea map-urilor passwd si group Folosirea NIS cu suport pentru Shadow Folosirea codului NIS traditional

În cazul unei retele locale (LAN), scopul final este de obicei crearea unui mediu în care utilizatorii sã poatã folosi reteaua cât mai transparent. Un pas important în îndeplinirea acestui scop este sincronizarea între host-uri a informatiilor vitale (de exemplu informatiile legate de conturile utilizatorilor). Mai înainte am vãzut cã pentru "host name resolution" existã deja un serviciu puternic si sofisticat -- si anume DNS, dar în alte cazuri nu existã un astfel de serviciu. De asemenea, dacã reteaua este micã si 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ã functii generice de acces la baze de date care pot fi folosite la distribuirea diferitelor informatii, de pildã cele continute în fisierele passwd si groups, acestea devenind

accesibile pentru toate host-urile din retea. Astfel, reteaua apare ca un singur sistem, cu aceleasi conturi pe toate host-urile. În acelasi mod puteti folosi NIS pentru a distribui informatiile din /etc/hosts cãtre toate calculatoarele din retea.

NIS se bazeazã pe RPC si cuprinde un server, o bibliotecã pentru client si câteva utilitare de administrare. Initial 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ã renunte la nume. În ciuda acestui lucru, oamenii renuntã greu la denumirile cu care s-au obisnuit, asa cã YP a rãmas prefixul majoritãtii 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 si se bazeazã pe o implementare pusã la dispozitia publicului larg de cãtre Sun. Biblioteca pentru client a existat în GNU libc de mult timp, în comparatie cu utilitarele - care au fost portate relativ de curând de cãtre Swen Thümmler. Din implementarea de referintã lipseste însã serverul NIS. Tobias Reber a scris un alt pachet NIS (numit yps) care include toate utilitarele si un server.

În momentul de fatã Peter Eriksson lucreazã la rescrierea completã a codului NIS, redenumit acum NYS, care suportã atât NIS cât si NIS+ (varianta revizuitã). NYS nu oferã doar un set de utilitare NIS si un server, ci si un set complet nou de functii de bibliotecã; acestea probabil cã vor fi incluse si în varianta standard a libc. Este inclusã si o schemã nouã de configurare pentru "hostname resolution" care înlocuieste schema actualã care foloseste host.conf. Aceste functii vor fi descrise mai jos.

În acest capitol accentul va fi pus pe NYS si nu pe celelalte douã pachete care vor fi numite codul NIS ``traditional''. Dacã doriti sã utilizati unul dintre acestea douã, instructiunile din acest capitol ar putea fi suficiente, dar s-ar putea si sã nu fie. Pentru informatii suplimentare consultati un manual standard despre NIS, cum este NFS and NIS de Hal Stern (vezi-[]).

NYS este încã în faza de dezvoltare, si de aceea utilitarele standard (de exemplu utilitarele de retea sau programul login) nu cunosc schema de configurare NYS. Atâta timp cât NYS nu este inclus în libc va trebui sã recompilati programele care doriti foloseascã NYS. Pentru oricare dintre aceste aplicatii, adãugati în Makefile optiunea -lnsl chiar înainte de libc. Astfel în loc de functiile bibliotecii C standard vor fi link-ate functiile din libnsl -- biblioteca NYS.

Sã facem cunostintã cu NISNIS pãstreazã informatiile bazei de date în asa numitele map-uri care contin perechi de valori-cheie. Map-urile sunt stocate pe un anumit host pe care ruleazã serverul NIS, de unde clientii pot obtine informatiile prin diferite call-uri RPC. Destul de frecvent, map-urile sunt stocate în fisiere DBM.

Map-urile în sine sunt de obicei generate din fisierele text originale cum sunt /etc/hosts si /etc/passwd. Pentru unele fisiere sunt create mai multe map-uri, câte unul pentru fiecare tip de cheie de cãutare. De exemplu, în fisierul 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 si hosts.byaddr. În tabela puteti vedea o listã cu map-urile tipice si fisierele din care sunt generate.

Table: Câteva map-uri NIS standard NIS si fisierele corespunzãtoare. ????????????????????

S-ar putea ca în unele pachete NIS sã gãsiti suport si pentru alte fisiere si map-uri. Acestea contin informatii pentru aplicatii care nu sunt abordate în acestã carte, de pildã bootparams folosit de unele servere BOOTP (map-urile corespunzãtoare sunt ethers.byname si ethers.byaddr).

De obicei, în loc de unele map-uri se folosesc nicknames (porecle), care sunt mai scurte si mai usor de tastat. Pentru a obtine lista completã a nicknames-urilor recunoscute de utilitarele NIS puteti folosi comanda:

Serverul NIS este numit, prin traditie, ypserv. Într-o retea de mãrime medie, un server NIS este în general suficient; în retelele mari însã, se poate sã fie necesare servere diferite pentru diferite hosturi si pentru diferite segmente ale retelei, pentru a nu suprasolicita serverele si routerele. Aceste servere sunt sincronizate: unul este master server, iar celelalte slave servers. Map-urile sunt create numai pe master server si de acolo sunt distribuite pe toate serverele slave.

Trebuie sã fi observat cã pânã acum am vorbit foarte vag despre ``retele''; În cadrul retelei, NIS vine cu un concept distinct: domeniul NIS care este totalitatea host-urilor care cu ajutorul NIS distribuie în cadrul retelei o parte din configuratia lor. Domeniile NIS nu au nimic comun cu domeniile întâlnite la DNS, asa cã pentru a evita orice ambiguitate, voi specifica de fiecare datã la care tip de domeniu mã refer.

Functia domeniilor NIS este una pur administrativã. Ele sunt aproape invizibile pentru utilizatori: acestia nu sezizeazã decât folosirea acelorasi 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 conditia sã fie unic în cadrul retelei locale. De exemplu, administratorul de la Virtual Brewery ar putea alege sã creeze douã domenii NIS, unul pentru Brewery si altul pentru Winery, pe care le va numi pur si

simplu brewery, respectiv winery. Destul de des, domeniul NIS este botezat la fel ca domeniul DNS. Pentru a vedea sau modifica numele domeniului NIS puteti folosi comanda domainname. Dacã nu precizati nici un argument, va afisa doar numele curent al domeniului NIS; pentru a schimba acest nume, trebuie sã fiti superuser si sã tastati:

În functie de domeniile NIS se stabileste serverul NIS pe care îl poate accesa o aplicatie. De exemplu, programul login de pe un host de la Winery trebuie, desigur, sã cearã informatiile 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 aplicatie 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ã solutie este folosirea unor fisiere de configurare locale, însã acestã solutie nu este flexibilã, pentru cã nu permite clientilor sã foloseascã mai multe servere (bineînteles în cadrul aceluiasi domeniu). De aceea, implementãrile NIS traditionale folosesc un daemon special - ypbind care detecteazã un server NIS potrivit din cadrul domeniului NIS. Înainte de a specifica orice cerere (query) NIS, aplicatiile trebuie sã afle mai întâi de la ypbind ce server sã folosescã.

ypbind detecteazã serverele prin broadcasting pe reteaua IP localã; primul server care rãspunde este considerat a fi cel mai rapid si 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ãsi 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ã, si în plus slãbeste gradul de securitate al retelei: ypbind nu e în stare sã deosebeascã un server NIS obisnuit de un intrus rãu intentionat. Acesta devine o problemã si mai gravã dacã bazele de date cu parole sunt administrate prin NIS. Din acestã cauzã, NYS nu foloseste în mod implicit ypbind, ci citeste hostname-ul serverului dintr-un fisier de configurare.

NIS versus NIS+NIS si NIS+ au putine lucruri în comun: asemãnarea numelor si destinatia. NIS+ este structurat într-o manierã complet diferitã. În locul unui spatiu format din domenii NIS separate, NIS+ foloseste un spatiu ierarhic similar celui folosit de DNS. În locul map-urilor existã asa-numitele tabele constituite din rânduri si coloane. Fiecare rând reprezintã un obiect în baza de date NIS+, iar coloanele sunt proprietãtile obiectelor gestionate de NIS+. Tabela fiecãrui domeniu NIS+ include tabelele domeniilor 'pãrinte'. De asemenea o înregistrare dintr-o tabelã poate contine un link cãtre o altã tabelã. Aceste facilitãti oferã posibilitãti multiple de organizare a informatiilor.

Varianta traditionalã 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 putin. (eh! nu se poate spune cã nu stiu chiar nimic) De aceea nu-l voi aborda în aceastã documentatie. Dacã doriti sã aflati mai multe despre NIS+ puteti consulta manualul de administrare NIS+ de la Sun. ([]).

NIS: Partea de ClientDacã sunteti familiarizati cu scrierea sau portarea aplicatiilor de retea veti observa cã majoritatea map-urilor NIS listate mai sus corespund unor functii din biblioteca C. De exemplu, pentru a obtine informatii din passwd se folosesc de obicei functiile getpwnam(3) si getpwuid(3) care returneazã informatiile despre contul unui utilizator regãsit dupã user name, respectiv user id. În mod obisnuit aceste functii cautã informatiile dorite în fisierul standard: /etc/passwd.

În cazul unei implementãri care utilizeazã NIS, aceste functii vor fi modificate în sensul cã trimit cãtre serverul NIS un call RPC prin care este localizat numele si id-ul utilizatorului. Acest comportament este total transparent pentru aplicatie. Functia poate fie sã adauge elemente în map-ul NIS, fie sã înlocuiascã cu totul fisierul original. Bineînteles, nu are loc o modificare realã a fisierului, ci doar este creatã iluzia cã acesta a fost înlocuit sau modificat.

În implementãrile NIS traditionale existau mai multe conventii referitoare la care map-uri înlocuiesc si care se adaugã la informatiile originale. Unele, cum sunt map-urile passwd, necesitau modificãri ale fisierului passwd care dacã nu erau fãcute corect afectau serios securitatea sistemului. Pentru a evita aceste capcane, NYS foloseste o schemã generalã de configurare care determinã dacã pentru un set de functii client de folosesc fisierele originale, NIS, sau NIS+, si în ce ordine. Capitolul curent include o sectiune specialã despre aceastã chestiune.

Rularea unui server NISPoate cã v-ati plictisit de teoria de pânã acum, asa cã hai sã ne punem pe treabã si sã ne apucãm de configurarea propriu-zisã. În acestã sectiune vom discuta despre configurarea unui server NIS. Dacã în reteaua dumneavoastrã functioneazã deja un server NIS, nu mai este nevoie sã setati nimic ( si puteti sãri fãrã grijã peste acestã sectiune ).

Dacã nu doriti altceva decât sã experimentati, sã "vã jucati" cu setarea serverului, aveti grijã sã nu folositi un nume al domeniului NIS care existã deja în retea. Altfel s-ar putea sã destabilizati întregul serviciu de retea, iar multi oameni ar putea deveni nemultumiti si chiar foarte nervosi.

În momentul de fatã existã douã servere NIS disponibile: unul în cadrul pachetului yps al lui Tobias Reber, si altul în cadrul pachetului ypserv al lui Peter Eriksson. În principiu nu conteazã pe care îl folositi. În momentul acesta, când scriu, codul pentru manipularea serverelor NIS de tip slave pare sã fie mai complet în yps. Deci dacã aveti nevoie de servere slave, probabil cã yps este o alegere mai bunã.

Dupã instalarea severului (programul ypserv) în /usr/sbin, urmeazã sã creati directorul care va contine fiserele map pe care le va distribui serverul. Când setati domeniul NIS pentru brewery map-urile vor fi puse în /var/yp/brewery. Serverul determinã dacã deserveste un anumit domeniu NIS dupã existenta directorului cu map-uri. Dacã la un moment dat doriti sã dezactivati un domeniu NIS, asigurati-vã cã ati sters si directorul.

În general, map-urile sunt pãstrate în fisiere DBM, care sunt generate din fisierele master cu ajutorul programului makedbm (pentru serverul lui Tobias) sau dbmload (pentru severul lui Peter). Acestea s-ar putea sã nu fie interschimbabile. Formatarea unui fisier master pentru a putea fi procesat cu dbmload necesitã de obicei folosirea lui sed sau awk, ceea ce tinde sã fie cam anost si greu de retinut. De aceea pachetul ypserv al lui Peter Eriksson contine un Makefile (numit ypMakefile) care face toatã acestã muncã în locul dumneavoastrã. Trebuie sã instalati acest fisier sub numele Makefile în directorul cu map-uri, apoi sã-l editati pentru a alege map-urile pe care doriti sã le distribuiti. Pe la începutul fisierului se targetul all care contine toate serviciile pe care le poate oferi ypserv. În mod implicit, linia aratã cam asa :

Dacã de pildã nu aveti nevoie de map-urile ethers.byname si ethers.byaddr, pur si simplu stergeti ethers din acest rule. Pentru a testa configuratia probabil cã este suficientã pornirea a una sau douã map-uri, de exemplu services.*.

Dupã ce ati editat Makefile, rãmâneti în directorul cu map-uri si tastati ``make''. Map-urile vor fi generate si instalate automat. Trebuie sã refaceti map-urile la fiecare modificare a fisierelor master, altfel schimbãrile nu vor fi disponibile în retea.

În sectiunea urmãtoare puteti afla cum se configureazã codul NIS pentru client. Dacã setãrile dumnevoastrã nu merg, trebuie sã aflati mai întâi dacã cererile ajung sau nu la

server. Dacã la pornirea serverului specificati optiunea -D, acesta va tipãri la consolã mesaje referitoare toate cererile NIS primite si la rezultatele acestora. Aceste mesaje ar trebui sã vã ajute sã aflati de unde provine problema. Serverul lui Tobias nu are aceastã optiune.

Setarea unui client NIS cu NYSDe acum încolo, în acest capitol vom aborda configurarea clientilor NIS.

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

Prima linie a fisierului specificã toti clientii NIS care apartin domeniului NIS winery. Dacã omiteti acestã linie NYS va folosi numele de domeniu pe care l-ati setat cu comanda domainname. Mai departe se specificã serverul NIS care va fi folosit. Desigur, adresa IP a serverului vbardolino trebuie specificatã în fisierul hosts; puteti dealtfel sã folositi direct adresa IP.

Din cauza comenzi server din fisierul de configurare de mai sus, NYS va folosi serverul specificat indiferent de domeniul NIS curent. Dacã în mod frecvent se întâmplã sã mutati calculatorul în mai multe domenii NIS probabil cã veti dori sã pãstrati în fisierul yp.conf informatiile referitoare la mai multe domenii NIS. De exemplu, în cazul unui laptop fisierul 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 ati creat acest fisier de configurare minimal si dupã ce ati verificat cã poate fi citit de cãtre toti utilizatorii, urmeazã sã faceti primul test : prima conectare la server. Alegeti orice map distribuit de server, de pildã hosts.byname, si încercati sã-l obtineti 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 veti obtine 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-ati setat nu corespunde nici unui server definit în yp.conf, fie cã serverul este inaccesibil dintr-un motiv oarecare. În al doilea caz, verificati dacã ping raporteazã cã poate accesa serverul si dacã da, verificati dacã este într-adevãr vorba de un server NIS. Pentru acesta folositi rpcinfo care ar trebui sã afiseze un output de genul :

Alegerea map-urilor corecteDupã ce v-ati convins cã puteti contacta serverul NIS, trebuie sã decideti care fisiere sã le înlocuiti sau sã le întregiti cu map-uri NIS. În mod tipic, probabil cã veti dori sã folositi map-uri NIS pentru host si pentru passwd. Primul este util mai ales când nu folositi BIND, iar al doilea permite tuturor utilizatorilor sã se conecteze de la orice host din retea; acesta necesitã existenta unui director /home central, disponibil în toatã reteaua prin NFS. În sectiunea - puteti gãsi informatii 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 instalati aplicatii de retea care folosesc un serviciu care nu este în fisierul services standard.

Probabil cã doriti sã puteti alege dacã o functie foloseste fisierul local sau serverul NIS. NYS vã permite sã configurati ordinea în care o functie acceseazã aceste servicii. Fisierul de configurare este /etc/nsswitch.conf (nss vine de lar Name Service Switch), dar bineînteles cã nu este limitat doar la name service. Acest fisier contine câte o linie pentru fiecare functie suportatã de NYS.

Ordinea corectã a serviciilor depinde de tipul datelor. Este improbabil ca map-ul services.byname sã continã înregistrãri diferite de cele din fisierul services local; poate eventual sã continã înregistrãri în plus. Astfel, ar fi o alegere bunã ca mai întâi sã fie consultat fisierul local doar dacã nu este gãsit serviciul dorit sã se apeleze la NIS. Pe de altã parte, informatiile referitoare la hostnames se pot schimba foarte frecvent, astfel cã în general serverele DNS sau NIS detin cele mai actualizate informatii, pe când fisierul hosts local este pãstrat doar ca rezervã pentru cazul în care serverul DNS sau NIS picã. Astfel cã în aceste conditii este de dorit ca fisierul local sã fie consultat ultimul.

Exemplul de mai jos aratã cum se pot configura functiile gethostbyname(2), gethostbyaddr(2) si getservbyname(2) ca sã functioneze în modul descris mai sus. Ele vor încerca initial primul serviciu; în cazul unui succes se returneazã rezultatul, altfel este încercat urmãtorul serviciu.

Mai jos se gãseste lista completã a serviciilor care pot fi folosite cu o înregistrare în fisierul nsswitch.conf. Map-urile, fisierele, serverele si obiectele care vor fi consultate depind de numele înregistrãrii.

În momemtul de fatã, NYS suportã urmãtoarele înregistrãri în nsswitch.conf: hosts, networks, passwd, group, shadow, gshadow, services, protocols, rpc, si ethers. Probabil cãse vor mai adãuga si altele.

Figura- ilustreazã un exemplu si 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 fisierele locale numai dacã consultarea serverelor NIS si DNS a esuat. Fisierele locale vor fi astfel folosite numai la bootare si ca o copie de sigurantã pentru cazul când serverul NIS nu este accesibil.

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

Folosirea map-urilor passwd si groupUnul dintre rolurile esentiale pa cere le joacã NIS este sincronizarea informatiilor despre utilizatori si conturile lor în cadrul domeniului NIS. În acest scop, se pãstreazã de obicei un fisier /etc/passwd minimal la care se adaugã informatiile 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 folositi NIS pentru distribuirea informatiilor referitoare la parole trebuie mai întâi sã vã asigurati cã user id-urile utilizatorilor din fisierul 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ã modificati proprietarul (owner) pentru toate fisierele utilizatorului respectiv. Mai întâi trebuie sã setati noile valori ale uid-urilor si gid-urilor în passwd respectiv group. Apoi localizati toate fisierele utilizatorului si le schimbati 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ã folositi urmãtoarele comenzi:

Este important sã apelati aceste comenzi avînd instalat noul fisier passwd si sã colectati toate numele fisierelor userului înainte de chown. Pentru a modifica apartenenta la grupuri a fisierelor se foloseste o comandã similarã.

Dupã de ati fãcut aceasta, uid-urile si 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 informatiilor despre utilizatori si 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 si doar în caz de nereusitã vor consulta fisierele locale. În general probabil cã veti scoate aproape toti userii din fisierele locale, lãsînd numai root si utilizatori generici cum este mail, si aceasta deoarece unele taskuri vitale ale sistemului ar putea necesita maparea uid-urilor cu numele utilizatorilor sau invers. De exemplu, uneori job-urile cron administrative executã comanda su pentru a deveni temporar news, iar subsistemul UUCP ar putea trimite prin

mail un raport. Dacã news si uucp nu existã în fisierul passwd local existã riscul ca aceste joburi sã esueze 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 functioneazã numai pentru suite login care nu folosesc shadow passwords ( cum este cea inclusã în pachetul util-linux ). Complicatiile aduse de folosirea parolelor shadow vor fi abordate în sectiunea urmãtoare. În al doilea rând, comenzile de genul login nu sunt singurele care acceseazã fisierul passwd-- de pildã chiar si banalul ls face parte din aceastã categorie. De fiecare datã când este apelat ls cu optiunea -l (long listing), vor fi afisate numele simbolice pentru grupul si proprietarul fiecãrui fisier, 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ã reteaua este supraîncãrcatã sau dacã, mai grav, serverul NIS nu este în aceeasi retea fizicã si datagramele trebuie sã treacã printr-un router.

ªi asta nu e totul. Imaginati-vã cã un utilizator vrea sã-si schimbe parola. În mod normal, va apela passwd care citeste noua parolã si modificã fisierul passwd local. Acest lucru este imposibil când se foloseste NIS, deoarece fisierul nu mai este disponibil local, iar a permite utilizatorilor sã se conecteze la serverul NIS de fiecare datã când vor sã-si schimbe parola nu este o solutie. 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, si comunicã noile informatii. Pentru a instala yppasswd peste programul passwd clasic se procedeazã în felul urmãtor:

De asemenea trebuie sã instalati pe server rpc.yppasswdd si sã-l porniti din rc.inet2. Astfel li se va ascunde utilizatorilor aceastã ciudãtenie datoratã NIS-ului.

Folosirea NIS cu suport pentru ShadowDeocamdatã 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 functii shadow care suportã partial NIS, deci e incompletã si nu a fost încã în biblioteca C standard libc. Pe de altã parte, publicarea cu NIS a informatiilor din /etc/shadow contravine scopului pe care îl are shadow !

Desi functiile NYS referitoare la password nu folosesc map-ul shadow.byname sau ceva similar, NYS permite în mod transparent folosirea unui fisier /etc/shadow. Când este apelatã implementarea NYS a functiei getpwnam sunt utilizate specificatiile din câmpul passwd din nsswitch.conf. Serviciul NIS va localiza informatiile cerute în map-ul passwd.byname de pe serverul NIS. Totusi, serviciul files va verifica existenta fisierului /etc/shadow, si dacã îl gãseste va încerca sã-l deschidã. Dacã nu existã sau dacã userul nu este root, se va reveni la comportamentul clasic: cãutarea informatiilor numai în /etc/passwd. Dacã /etc/shadow existã si poate fi deschis, NYS va lua din shadow parola

utlizatorului. Functia getpwuid este implementatã în mod similar. Astfel, executabilele compilate cu NYS se vor descurca în mod transparent cu o configurare care foloseste shadow.

Folosirea codului NIS traditionalDacã folositi codul client inclus în versiunea standard curentã a libc, configurarea clientului NIS este un pic diferitã. În primul rând, în loc sã obtinã informatiile despre serverele NIS dintr-un fisier de configuratie, foloseste daemonul ypbind pentru localizarea serverelor active. Deci trebuie sã vã asigurati cã ypbind este încãrcat la bootare. ypbind trebuie rulat dupã setarea domeniului NIS si 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 esueazã returnînd ``clntudp_create: RPC: portmapper failure - RPC: unable to receive''. Aceastã eroare se datoreazã unei modificãri incompatibile a modului cum ypbind returneazã informatiile cãtre functiile de bibliotecã. Dacã obtineti ultimele surse ale utilitarelor NIS si le compilati ar trebui sã scãpati de acestã problemã.

De asemenea, modul în care NIS-ul traditional decide dacã si cum sã facã îmbinarea informatiilor NIS cu cele din fisierele locale diferã fatã de NYS. De exemplu, pentru a folosi map-uri password va trebui sã includeti urmãtoarea linie în /etc/passwd:

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

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