|
|
|
Cuprins
Retele TCP/IP
Codul de Networking
Intreinerea sistemului
Privire generala peste capitolele urmatoare
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.
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).
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.
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.
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.
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).
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.
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.
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.
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.
Pe tot cuprinsul acestei cari ne vom ocupa in principal cu chestiuni de instalare si configurare. Administrarea sistemului consta din mult mai mult decat atat. Dupa configurarea unui anumit serviciu, trebuie sa-l inei in funciune. Pentru cele mai multe servicii foarte puina munca este necesara, insa unele servicii, ca de exemplu serviciile de ???mail??? si de ???news??, necesita executarea unor aciuni de rutina pentru a ine sistemul la zi. Vom discuta aceste aciuni in capitolele ce vor urma.
Minimul absolut in intreinerea sistemului este verificarea regulata de erori si de evenimente neobisnuite a fisierelor log ale aplicaiilor. Foarte practic este sa scriei niste scripturi administrative si sa le rulai din cron periodic. Distribuia sursa a unora din aplicaiile majore, ca de exemplu ???smail??? sau ???C-News???, conin asemenea scripturi. Tot ce va ramane de facut este sa le adaptai nevoilor si preferinelor dumneavoastra.
Iesirea oricarui job cron va fi trimisa prin mail catre un cont administrativ. Implicit, multe aplicaii vor trimite rapoarte de eroare sau statistici despre utilizare catre contul de root. Aceasta are sens numai daca va logai ca root frecvent; o idee mult mai buna este sa retrimitei mail-ul root-ului catre contul personal prin crearea unui alias, asa cum este descris in capitolul ???.
Insa oricat de atent va-i configurat sistemul, legile lui Murphy garanteaza ca vor aparea probleme. Astfel administrarea unui sistem inseamna si disponibilitatea pentru plangeri. De obicei utilizatorii se asteapta ca administratorul de sistem sa fie de gasit prin mail ca si root, dar sunt si alte adrese care sunt folosite pentru a ajunge la persoane responsibile cu diferite aspecte ale administrarii. De exemplu, plangerile despre funcionarea incorecta a serviciului de mail vor fi trimise de obicei catre postmaster; iar problemele cu serverul de news vor fi trimise catre newsmaster sau Usenet. Mail-ul catre hostmaster va trebui redirecionat catre persoana care se ocupa cu servicile de reea de baza sau de serviciul DNS daca rulai un server de nume (name server).
Un aspect foarte important al administrarii sistemului dintr-o reea este protejarea lui de intruderi. Sistemele administrate neatent ofera rauvoitorilor multe inte: atacurile merg de la ghicirea parolei pana la 'spionarea' pachetelor dintr-o reea Ethernet si pagubele cauzate de aceste atacuri merg de la date pierdute la violarea intimitaii utilizatorilor. Vom meniona unele probleme particulare cand vom discuta contextul in care pot aparea si, in unele cazuri, posibile aparari impotriva acestor atacuri.
In aceasta seciune vom discuta cateva exemple si tehnici de baza referitoare la securitatea sistemului. Desigur, discuia nu poate trata toate problemele legate de securitate pe care le putei intalni; ea foloseste mai degraba la ilustrarea problemelor ce pot aparea. Astfel este absolut necesara citirea unei cari bune despre securitate in special pentru un sistem aflat in reea. Cartea lui Simon Garfinkel, 'Practical UNIX Security' este recomandata.
Securitatea sistemului porneste de la o buna administrare a lui. Aceasta include verificarea proprietarului si permisiunilor pentru toate fisierele si directoarele vitale, monitorizarea folosirii conturilor privilegiate, etc. Programul COPS, de exemplu, va va verifica sistemul de fisiere precum si fisierele de configurare cele mai comune. De asemenea este recomandabil sa obligai utilizatorii sa-si seteze parole cat mai greu de ghicit. De exemplu programul uzual pentru schimbarea parolei cere ca parola sa aiba cel puin cinci caractere si sa conina atat litere cat si cifre sau caractere speciale.
Cand facei un serviciu accesibil prin reea, asigurai-va ca ii dai cel mai mic privilegiu, adica ca nu ii permitei sa faca lucruri ce nu-i sunt necesare pentru a funciona asa cum trebuie. De exemplu n-ar trebui sa facei executabile setuidate??? root decat cand este neaparat necesar. De asemenea, daca vrei sa utilizai un serviciu pentru o aplicaie foarte limitata, nu ezitai sa-l configurai cat mai restrictiv cu putina. De exemplu daca avei masini fara disk in reea si vrei sa le lasai sa booteze de pe masina dumneavoastra, trebuie sa folosii serviciul TFTP (trivial file transfer protocol) astfel incat clienii sa poata descarca fisierele de configurare de baza din directorul /boot. Insa, cand nu este restricionat, TFTP lasa orice utilizator din lume sa descarce orice fisier cu drept de citire. Daca nu vrei aceasta, de ce sa nu restricionai serviciul TFTP numai la directorul /boot?
In aceeasi ordine de idei, e bine sa restricionai anumite servicii la utilizatori de pe anumite masini, de exemplu din reeaua locala. In capitolul ???, vom introduce tcpd care face acest lucru pentru o mulime de aplicaii de reea.
Alt punct important este sa evitai aplicaiile 'periculoase'. Desigur, orice aplicaie poate fi periculoasa, deoarece poate avea 'scame' pe care oamenii destepi le pot exploata pentru a capata acces la sistemul dumneavoastra. Lucruri ca acestea se intampla si nu exista protecie completa impotriva lor. Aceasta problema afecteaza atat software-ul liber cat si software-ul comercial. Insa programele care necesita privilegii sporite sunt mai periculoase decat celelalte din cauza ca orice scama poate avea efecte drastice. Daca instlai un program pentru reea, setuidat, fii de doua ori mai atent ca nu va scapa nimic de la documentaie, astfel incaat sa nu creai o nisa de securitate din greseala.
Nu putei sti niciodata daca precauiile dumneavoastra vor da gres indiferent de cat de atent ai fost. Verificarea regulata a logurilor este un punct bun de plecare, dar intruderul este probabil suficient de destept incat sa creada orice urma. Insa, exista unelte ca tripwire??? care va permit sa verificai fisierele vitale pentru a vedea daca coninutul si permisiunile s-au schimbat. Tripwire calculeaza diferite sume de control pentru aceste fiaiere si le pastreaza intr-o baza de date. In timpul rularilor succesive, sumele de control sunt recaluclate si comparate ce cele pastrate pentru a detecta orice modificare.
Capitolele urmatoare se vor ocupa cu configurarea Linux-ului pentru reele TCP/IP si cu configurarea unor aplicaii majore. Inainte sa; ne murdarim mainile cu editarea fisierelor si alte chestii asema;natoare, vom examina, in Cap. 2, mai cu atenie, protoculul IP. Daca stii deja cum funcioneaza routarea IP si cum se face gasirea adreselor, putei sari direct la capitolul urmator.
Capitolul se ocupa cu configurarile de baza, ca de exemplu compilarea unui kernel si configurarea placii Ethernet. Configuratia porturilor seriale este tratata intr-un capitol separat, din cauza ca discutia nu se aplica numai retelelor TCP/IP dar este relevanta pentru UUCP.
Capitolul se ocupa cu configurarea unei masini pentru o retea TCP/IP. El contine informatii pentru instalarea unor gazde fara retea externa si a unor gazde conectate la o retea Ethernet.
Acesta este urmat de doua capitole care va invata cum sa folositi SLIP si PPP. Capitolul Cap. 3 explica cum sa stabiliti o conexiune SLIP si va ofera referinte detaliate despre dip, o unealta care va permite sa automatizati cei mai multi pasi. Capitolul Cap. 4 acopera PPP si pppd, demonul PPP de care veti avea nevoie.
Capitolul va ofera o scurta introducere in configurarea celor mai importante aplicatii pentru retea precum rlogin,rcp, etc. De asemenea se discuta serviciile ce sunt manevrate de superserverul inetd si cum puteti restrictiona anumite servicii.
Capitolul va ofera informatii pretioase despre administrarea programului Taylor UUCP care este o implementare free a suitei UUCP.
Restul cartii se ocupa cu un studiu detaliat al postei electronice si al serviciului de stiri. Capitolul introduce conceptele de baza ale postei electronice precum forma unei adrese de mail si cum functioneaza sistemul furnizarii e-mailurilor catre destinatie.
Capitolele si acopera configurarea programelor smail si sendmail. Aceasta carte le explica pe amandoua deoarece smail e mai usor de instalat pentru incepatori in vreme ce sendmail este mai flexibil.
Capitolele si explica felul cum stirile sunt manevrate un Usenet si cum puteti instala si folosi C-news, un pachet software popular pentru manevrarea stirilor Usenet. Capitolul acopera pe scurt configurarea demonului NNTP pentru a facilita accesarea stirilor din reteau dumneavoastra locala. In sfarsit, capitolul va invata cum sa configurati si sa intretineti diferite programe de citit stiri.
