Scrigroup - Documente si articole

Username / Parola inexistente      

Home Documente Upload Resurse Alte limbi doc  

CATEGORII DOCUMENTE




AccessAdobe photoshopAlgoritmiAutocadBaze de dateCC sharp
CalculatoareCorel drawDot netExcelFox proFrontpageHardware
HtmlInternetJavaLinuxMatlabMs dosPascal
PhpPower pointRetele calculatoareSqlTutorialsWebdesignWindows
WordXml


Linux: SSH, TCP/IP, DNS, WWW

linux

+ Font mai mare | - Font mai mic






DOCUMENTE SIMILARE

Trimite pe Messenger
Comenzi de lucru cu directoare
Conectarea statiilor Windows la Linux: telnet, putty
Linux
Executia pas cu pas a proceselor - UNIX
SISTEMUL DE OPERARE LINUX RED HAT
Evacuarea proceselor - UNIX
Asteptarea (wait) - UNIX
Linux Users and Sudo
Profiling - UNIX
Structuri de date pentru paginare la cerere - UNIX

Servicii Linux


  • Cuprins
  •  Servicii Linux
    • 1 Secure Shel (SSH)
      •  Functionarea SSH
    • 2 Forwardarea X si TCP/IP
      • B. Configurarea SSH (client)
      • C. Configurarea SSHD
    • 3 Domain Name System - DNS
      • A. Scurt istoric
      • B. Implementare DNS
      • C. Un server de nume caching-only
      • D. Un domeniu simplu
    • 4 Electronic Mail - e-mail
      • A. Scurt istoric
      • B. Arhitectura si functionare
      • C. Spam, relay, open-relay
      • D. Aplicatii
    • 5 World Wide Web
      • A. Scurt istoric
      • B. Ce este WWW si cum functioneaza?
      • C. Server-e si clienti Web
      • D. Instalarea si configurarea Apache Web Server
    • 6 NIS & NFS
      • A. RPC
      • B. NIS
      • C. NFS
    • 7 Studii de caz
      • A. Configurarea Qmail
      • B. 'Virtual Hosting' cu Apache
        • 1 Gazduire virtuala bazata pe adrese IP
        • 2 Gazduire virtuala bazata pe nume
    • 8 Intrebari

 Servicii Linux

In cadrul acestui capitol vor fi prezentate detalii legate de configurarea unor servicii de retea: SSH, DNS, Web, Mail, NFS.




1 Secure Shel (SSH)

Ssh (Secure Shell) e un program pentru logare la distanta si pentru executarea comenzilor pe masina de la distanta. A fost conceput pentru a inlocui rlogin si rsh si pentru a asigura comunicatie criptata intre doua gazde neincrezatoare dintr-o retea nesigura. Prin canalul oferit pot fi forwardate si conexiunile X11 si porturi arbitrare TCP/IP. Ssh utilizeaza tcp, componenta server ascultand pe portul 22.

Pachetul ssh este compus din server (sshd),client (ssh) si inca cateva utilitare, pentru manevrarea cheilor. In general sshd-ul se porneste din scripturile de initializare ale sistemului si ruleaza tot timpul in background.


Subsections

  • Functionarea SSH

 Functionarea SSH

Fiecare masina are o cheie RSA: host key (in mod normal pe 1024 de biti). In plus, atunci cand este pornit, demonul (sshd) genereaza automat o cheie: server key (pe 768 de biti). Aceasta este regenerata din ora in ora daca a fost folosita si nu este pastrata niciodata pe disc. De fiecare data cand un client initiaza o conexiune, demonul ii trimite host key si server key (care este publica). Clientul compara host key cu cea din baza lui de date, pentru a verifica daca nu s-a schimbat. Apoi clientul genereaza un numar aleator de 256 de biti. Cripteaza acest numar folosind host key si server key si trimite numarul criptat la server. In continuare ambele parti vor folosi acest numar aleator ca o cheie de criptare. Sunt suportate urmatoarele metode de criptare: IDEA, DES, 3DES, ARCFOUR si TSS, implicit folosindu-se IDEA

Urmatoarea etapa este autentificarea clientului care a initiat conexiunea. Acest proces se desfasoara astfel:

  • Mai intai, daca masina de pe care se logheaza utilizatorul este mentionata in fisierul /etc/hosts.equiv sau /etc/hosts.equiv de pe masina de la distanta si numele utilizatorului este acelasi pe ambele masini, acesta se logheaza imediat. In plus, daca in directorul home al utilizatorului de pe masina de la distanta exista fisierul .rhosts sau .shosts si contine o linie cu numele masinii client si numele utilizatorului pe acea masina, acesta se logheaza imediat. In mod normal, doar aceasta metoda de autentificare nu este permisa, fiind nesigura.
  • A doua (de fapt prima) metoda de autentificare este metoda rhost sau hosts.equiv combinata cu autentificarea prin RSA. Adica logarea se poate face doar daca este permisa prin .rhosts, .shosts, /etc/hosts.equiv sau /etc/shosts.equiv si in plus se verifica si cheia gazdei.
  • Ca o a treia metoda de autentificare, ssh suporta autentificarea RSA. Fiecare utilizator isi creeaza o pereche de chei: publica si privata. Serverul cunoaste cheia publica si doar utilizatorul cunoaste cheia privata. In fisierul $HOME/.ssh/authorized_keys se afla lista cheilor publice care se pot loga. Cand utilizatorul se logheaza, programul ssh spune serverului care pereche de chei va fi folosita pentru autentificare. Serverul verifica daca aceasta cheie se afla printre cele carora li se permite logarea si, in caz afirmativ, trimite utilizatorului (de fapt programului ssh rulat de utilizator) o intrebare, un numar aleator, criptat cu cheia publica a utilizatorului. Aceasta intrebare poate fi decriptata doar cu cheia privata potrivita. Utilizatorul decripteaza intrebarea folosind cheia potrivita, dovedind astfel ca e corect. Ssh-ul implementeaza protocolul de autentificare RSA automat. Utilizatorul creeaza perechea de chei RSA automat, ruland ssh-keygen. Acesta pune cheia privata in .ssh/identity si cheia publica in .ssh/identity.pub in directorul home al utilizatorului. Utilizatorul trebuie sa copieze identity.pub in .ssh/authorized_keys in directorul home de pe masina de la distanta (fisierul authorized_keys corespunde cu fisierul conventional .rhosts, avand o cheie pe o linie, chiar daca liniile sunt foarte lungi). Apoi utilizatorul se poate loga fara parola. Autentificarea prin RSA e mult mai sigura decat cea prin rhosts. Cel mai convenabil mod de a folosi autentificarea prin RSA este cu agent de autentificare, ssh-agent.
  • Ca o a 4-a metoda, ssh-ul suporta autentificarea printr-un server TIS. Ssh cere serverului de autentificare TIS sa autentifice utilizatorul. Uneori, numele utilizatorilor din baza de date TIS nu poate sa fie acelasi cu cel de pe masina locala. Aceasta se intampla cand utilizatorul se autentifica cu un smartcard sau Digipass. In acest caz, numele utilizatorului din baza de date este cunoscut ca numarul serial a device-ului de autentificare. Fisierul /etc/sshd_tis.map contine maparea intre utilizatorii locali si numele corespunzator lor din baza de date TIS. Daca fisierul nu exista sau utilizatorul nu este gasit, numele corespunzator din baza de date TIS e presupus acelasi.

Daca toate metodele de autentificare incercate esueaza, ssh cere utilizatorului o parola. Parola e trimisa gazdei de la distanta pentru verificare, criptata. Cand identitatea utilizatorului a fost acceptata de server, acesta fie executa comanda data, fie se logheaza si transmite utilizatorului un shell normal pe masina de la distanta. Comunicatia intre cele doua masini este acum criptata.

Dupa ce faza de autentificare se incheie cu succes urmeaza procesul de login, descris mai jos:

  1. Daca login-ul e pe un tty si nu a fost specificata nici o comanda, afiseaza ultima logare si /etc/motd
  2. Daca login-ul e pe un tty, inregistreaza momentul logarii
  3. Verifica /etc/nologin. Daca exista, ii afiseaza continutul si iese
  4. Schimba sa ruleze cu privilegii normale de utilizator
  5. Seteaza variabilele de mediu de baza
  6. Citeste /etc/environment (daca exista)
  7. Citeste $HOME/.ssh/environment (daca exista)
  8. Trece in directorul home al utilizatorului
  9. Daca exista $HOME/.ssh/rc, il ruleaza; altfel, daca exista /etc/sshrc il ruleaza; daca nici acesta nu exista, ruleaza xauth.
  10. Ruleaza shell-ul utilizatorului sau comanda

2 Forwardarea X si TCP/IP

Daca utilizatorul foloseste X11 (este setata variabila de mediu DISPLAY), conexiunea cu display-ul X11 e transferata automat la distanta in asa fel incat orice program X11 pornit de la shell (sau prin comanda) e trecut prin canalul criptat si conexiunea cu adevaratul server X va fi facuta de pe masina locala. Utilizatorul nu trebuie sa seteze manual variabila DISPLAY. Transferarea conexiunilor X11 poate fi configurata din linia de comanda sau din fisierele de configurare.

Transferarea unei conexiuni TCP/IP prin canalul sigur poate fi specificata fie din linia de comanda, fie din fisierele de configurare. O aplicatie posibila a forwardarii TCP/IP e trecerea de un firewall in vederea citirii postei electronice. Ssh mentine si verifica automat o baza de date cu identificarile bazate pe RSA ale tuturor masinilor pe care s-a facut logarea. Baza de date este tinuta in .ssh/known_hosts. In plus si fisierul /etc/ssh_known_hosts este verificat automat. Orice noua gazda este automat adaugata la fisierul utilizatorului. Daca informatia de identificare a unei gazde se schimba, ssh trimite un avertisment si dezactiveaza autentificarea parolei pentru a preveni un atentat la parola utilizatorului. Optiunea StrictHostKey-Checking poate fi folosita pentru a preveni logarile pe masini ale caror chei nu sunt cunoscute sau au fost schimbate.


Subsections

  • A. Configurarea SSH (client)
  • B. Configurarea SSHD

A. Configurarea SSH (client)

Ssh ia configurarile necesare din urmatoarele surse (in aceasta ordine):

  • de la linia de comanda
  • din fisierele de configurare ale utilizatorului ($HOME/.ssh/config)
  • din fisierul de configurare al sistemului (/etc/ssh_config).

Pentru fiecare parametru va fi folosita prima valoare obtinuta.


B. Configurarea SSHD

Fisierul de configurare utilizat de sshd este /etc/sshd_config. De asemenea, este posibila specificarea unor optiuni ca parametri la linia de comanda:

-b

- specifica numarul de biti pentru server key

-d

- modul depanare (debug). Sshd va trimite mesaje de debug, nu trece in background, nu face fork

-f

config - specifica locatia la care se gaseste fisierul de configurare

-k

keygentime - specifica cat de des va fi generat server key

-p

- specifica portul folosit de sshd

In fisierul sshd_config se pot utiliza urmatoarele cuvinte cheie:

AllowGroups

- urmat de unul sau mai multe grupuri, separate prin spatiu. Daca este specificata aceasta optiune, se pot loga doar utilizatorii din grupurile respective. Se pot folosi '*' si '?'.

AllowHosts

- urmat de unul sau mai multe nume de masini, separate prin spatiu, ca la AllowGroups. Daca nu se stie numele masinii, se foloseste IP-ul.

AccountExpireWarningDays

- specifica dupa cat timp vor incepe sa apara avertismente: contul va expira. Valoarea reprezinta numarul de zile inainte de expirare. Implicit este 14.

AllowSHosts

- urmat de unul sau mai multe nume de masini, separate prin spatiu. Daca este specificata optiunea, se pot loga cu .shosts (si .rhosts si /etc/hosts.equiv) doar utilizatorii de pe masinile specificate.

AllowTcpForwarding

 

AllowUsers

- urmat de user@host

CheckMail

- specifica daca sshd afiseaza un mesaj de fiecare data cand utilizatorul se logheaza, mesaj referitor la mail

DenyGroups

 

DenyHosts

 

DenySHosts

 

DenyUsers

 

FascistLogging

 

ForcedEmptyPasswdChange

- specifica daca este fortata schimbarea parolei daca aceasta este vida.

ForcedPasswdChange

- specifica daca e fortata schimbarea parolei daca aceasta expira

IgnoreRhosts

- specifica faptul ca nu poate fi folosita autentificarea cu rhosts sau shosts

KerberosAuthentication

- specifica daca e permisa autentificarea Kerberos V5. Daca PasswordAuthentication e 'yes', parola va fi validata cu Kerberos KDC sau DCE Security Server.

KeyRegenerationInterval

- specifica dupa cat timp va fi regenerata cheia serverului

ListenAddress

 

LoginGraceTime

- daca utilizatorul nu s-a logat, dupa acest timp serverul se deconecteaza. Implicit e 600s

PasswordAuthentication

 

PasswordExpireWarningsDays

 

PermitEmptyPasswords

 

PermitRootLogin

- poate fi 'yes', 'nopwd' sau 'no'. 'Nopwd' inseamna ca nu e permisa autentificarea cu parola

PidFile

- fisierul care contine ID-ul procesului demonului sshd (implicit /etc/ssh.pid sau /var/ run/ sshd.pid)

Port PrintMotd

- specifica daca sshd-ul afiseaza /etc/motd la logarea unui utilizator

QuietMode

 

RandomSeed

- implicit /etc/sshd_random_seed

RhostsAuthentication

- specifica daca este sau nu suficienta autentificarea cu rhosts sau /etc/hosts.equiv

RhostsRSAAuthentication

 

RSAAuthentication ServerKeyBits

- defineste numarul de biti din server key (implicit 768)

SilentDeny StrictModes

- specifica daca ssh-ul sa verifice permisiunile si proprietarul directorului home si al fisierului rhosts inainte de a aceepta logarea

SyslogFacility

- are valorile posibile DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL4, LOCAL5, LOCAL6, LOCAL7

X11Forwarding

 

X11DisplayOffset

- specifica primul numar de display disponibil pentru forwardarea X11. Previne conflictele cu serverele reale


3 Domain Name System - DNS


Subsections

  • A. Scurt istoric
  • B. Implementare DNS
  • C. Un server de nume caching-only
  • D. Un domeniu simplu




A. Scurt istoric

Domain Name System mapeaza numele de masini in adrese IP si invers. O astfel de mapare este o simpla asociere de genul ftp.linux.org - 199.249.150.4. Asa cum am vazut in capitolul 10, cel mai simplu mod de a realiza astfel de mapari este utilizarea unui fisier. Istoric, aceasta a fost prima modalitate de a realiza translatarea numelor in adrese. Exista un fisier care continea asocieri de genul nume - adresa pentru toate calculatoarele din Internet. Odata cu dezvoltarea vertiginoasa a retelei, aceasta abordare centralizata si-a dezvaluit neajunsurile:

  • fisierul devenea din ce in ce mai mare odata cu cresterea numarului de calculatoare conectate
  • server-ele folosite pentru distributia acestui fisier nu mai faceau fata incarcarii foarte mari, deoarece toate calculatoarele conectate descarcau periodic fisierul
  • un calculator care tocmai a descarcat fisierul, va afla de modificarile aduse fisierului abia la o noua descarcare

Solutia la aceste probleme a fost data in anul 1984 de catre Paul Mockapetris, inventatorul DNS in forma sa actuala.


B. Implementare DNS

DNS este o baza de date distribuita pe intregul Internet. Este foarte important sa aveti grija ce publicati in DNS, pentru ca ceilalti vor primi datele publicate de dumneavoastra exact cum faceti publicarea.

DNS are o structura ierarhica, ce porneste de la asa-numite TLD sau Top Level Domains (.com, .net, .org, .edu, .ro, .nl, .in-addr.arpa, etc.) si apoi cuprinde nume de domenii si de subdomenii, pe o structura de adancime variabila. La cererile pentru o rezolvare de nume (retineti termenul rezolvare, este consacrat) se ofera raspuns dupa un algoritm tipic unei baze de date distribuite ierarhice, aceasta cerere ajungand in final la serverul de nume care este desemnat (termenul consacrat este delegat) sa rezolve cererile pentru acel domeniu. Daca domeniul nu exista sau statia din domeniu nu exista, incercarea de rezolvare esueaza.

Serviciul de nume in Unix este gestionat de un daemon numit named, care in Linux este incluse in pachetul bind. Serviciul DNS foloseste portul 53, atat UDP, cat si TCP. Cererile de rezolvare DNS se fac prin UDP, iar update-urile de zone se transmit catre nivelele superioare prin TCP. Deci pentru ca serviciul de nume sa functioneze printr-un firewall, trebuie lasate sa treaca atat portul UDP 53, cat si portul TCP 53.


C. Un server de nume caching-only

In acest paragraf vom configura un server de nume care nu publica date efectiv, ci doar forwardeaza cererile catre nivelul ierarhic superior si implementeaza un cache (acest lucru este realizat implicit de catre daemon). Acest lucru inseamna ca o cerere ulterioara pentru rezolvarea aceluiasi nume primita de acelasi server va primi raspunsul din cache-ul local, fara a fi necesara trimiterea cererii catre nivelurile superioare.

Un astfel de server este extrem de util de exemplu pentru utilizatorii care folosesc o conexiune foarte lenta, de genul dial-up printr-un modem lent.

Fisierul de configurare pentru named este numit /etc/ named.conf. Acesta este citit de catre daemon la pornire. Pentru moment acest fisier trebuie sa contina doar urmatoarele intrari:

options ;

zone '.' ;

zone '0.0.127.in-addr.arpa' ;

Linia 'directory' specifica directorul unde sunt stocate fisierele pentru diferitele zone de care raspunde serverul. Conform Linux File System Standard, acesta este /var/named, insa o practica destul de raspandita este de a folosi /etc/named, pentru ca /var este uneori montat pe o alta partitie si este de dorit ca datele pentru bind sa fie disponibile chiar daca sunt probleme cu alte partitii. Fisierul /etc/named/root.hints (uneori /etc/named/named.ca) trebuie sa aiba urmatoarea structura:

______________________________________________________________________ 

; There might be opening comments here if you already have this file. 

; If not don't worry. 

6D IN NS G.ROOT-SERVERS.NET. 

6D IN NS J.ROOT-SERVERS.NET. 

6D IN NS K.ROOT-SERVERS.NET. 

6D IN NS L.ROOT-SERVERS.NET. 

6D IN NS M.ROOT-SERVERS.NET. 

6D IN NS A.ROOT-SERVERS.NET. 

6D IN NS H.ROOT-SERVERS.NET. 

6D IN NS B.ROOT-SERVERS.NET. 

6D IN NS C.ROOT-SERVERS.NET. 

6D IN NS D.ROOT-SERVERS.NET. 

6D IN NS E.ROOT-SERVERS.NET. 

6D IN NS I.ROOT-SERVERS.NET. 

6D IN NS F.ROOT-SERVERS.NET. 

G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4 

J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10 

K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129 

L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12 

M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33 



A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4 

H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53 

B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107 

C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12 

D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90 

E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10 

I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17 

F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241 

______________________________________________________________________

Acest fisier contine serverele root pentru rezolvari de nume in Internet. Acestea se schimba in timp si acest fisier trebuie mentinut corespunzator. Aceste servere rezolva cererile pentru TLD-uri, mai exact transmit mai departe aceste cereri catre serverul care gestioneaza TLD-ul respectiv. Urmatoarea sectiune in named.conf cuprinde numele fisierul pentru zona. Structura acestor fisiere (prezentata mai jos) va fi explicata mai tarziu.

______________________________________________________________________ 

@ IN SOA ns.subdomain.domain.tld.

hostmaster.subdomain.domain.tld. ( 

1 ; Serial 

8H ; Refresh 

2H ; Retry 

1W ; Expire 

1D) ; Minimum TTL 

NS ns.subdomain.domain.tld. 

1 PTR localhost. 

______________________________________________________________________ 

In continuare, este necesara crearea unui fisier /etc/resolv.conf care sa specifice ca server de nume localhost:

search subdomain.domain.tld domain.tld

nameserver 127.0.0.1

Linia care incepe cu 'search' va specifica care domenii vor fi cautate in mod implicit pentru statii cu nume date (fara domeniu aferent). Linia 'nameserver' contine adresa IP a masinii pe care ruleaza named. Fisierul poate contine mai multe intrari pentru mai multe nameserver-e.

In continuare trebuie modificat (probabil) fisierului /etc/nsswitch.conf (sau host.conf, in functie de versiune). Acesta contine o multime de intrari care specifica unde pot fi gasite informatii. De interes pentru noi este prezenta liniei care specifica de unde sunt culese date pentru rezolvarea de nume:

hosts: files dns 

In cele ce urmeaza trebui pornit daemonul named. In RedHat Linux, acest lucru se realizeaza cu ajutorul script-ului /etc/rc.d/named, specificand ca parametru start. In orice versiune de Unix, se poate folosi /usr/sbin/ndc start. Urmariti cu tail -f /var/log/messages evolutia logurilor in timp ce porniti daemonul. Aici vor furnizate eventualele erori de sintaxa sau alte erori. Oprirea daemonului se face cu scriptul de mai sus specificand parametrul stop (in RedHat) sau in Unix in genereal cu kill named.

Pentru testarea serverului de nume utilizati dig. Sintaxa de baza este foarte simpla:

dig nume.domeniu

In mod uzual, structura de server de nume urmeaza structura ierarhica a spatiului de nume, caz in care fiecare server are un server de nivel superior, ce poarta numele de forwarder. Daca in /etc/named.conf se specifica un astfel de forwarder, cererile se vor trimite la acesta si nu prin broadcast. Pot exista mai multi forwarderi pentru acelasi server. Pentru specificarea acestora, in cadrul sectiunii existente numita 'options', inserati urmatoarele linii:

forward first; 

forwarders ; 

Actualizati adresele IP cu cele date de catre administratorul domeniului din care faceti parte sau de catre furnizorul dumneavoastra de servicii Internet si reporniti named.


D. Un domeniu simplu

In continuare vom crea domeniul subdomain.domain.tld si vom defini fisierele pentru el. Un nume de domeniu este restrictionat la anumite caractere, mai exact: caracterele din alfabetul englez a-z, cifrele 0-9 si caracterul '-'. Un nume de domeniu este case-insesitive.

Originea unei zone in ierarhia DNS este specificata in sectiunea pentru zone din /etc/ named.conf. Fisierul de tip zona cuprinde trei tipuri de resurse inregistrare (RR, Resource Records): SOA, NS si PTR. SOA este prescurtarea de la Start of Authority. Caracterul '@' este o notatie speciala si este prescurtarea originii. NS este tipul de RR pentru Name Server si indica IP-ul masinii pe care ruleaza daemonul de rezolvare de nume pentru domeniul ce este reprezentat in zona respectiva. Inregistrarea SOA este preambulul pentru toate fisierele de zona si trebuie sa existe exact o intrare de acest gen in fiecare fisier pentru o zona. In aceasta inregistrare sunt descrisi parametri cum ar fi descrierea zonei, de cine este rezolvata (ca nume), cine este responsabil pentru zone, ce versiune de zona este si alte date care au de a face cu caching-ul si cu serverele DNS secundare. O intrare in /etc/ named. conf are urmatoarea sintaxa:

zone 'subdomain.domain.tld' ;

Fisierul subd.dom.tld va contine datele referitoare la numele de host-uri din acest domeniu:

;

; Zone file for subdomain.domain.tld

;

; The full zone file

;

@ IN SOA ns.subdomain.domain.tld. hostmaster.subdomain.domain.tld. (

2001121401 ; serial, todays date + todays serial #

8H ; refresh, seconds

2H ; retry, seconds

1W ; expire, seconds

1D ) ; minimum, seconds

;

NS ns ; Inet Address of name server

MX 10 mail.subdomain.domain.tld. ; Primary Mail Exchanger

MX 20 mail.friend.domain.tld. ; Secondary Mail Exchanger

;

localhost A 127.0.0.1

ns A 192.168.196.2

mail A 192.168.196.4

Doua observatii referitoare la inregistrarea SOA: ns.subdomain.domain.tld. trebuie sa fie o masina pentru care exista o inregistrare de tip A. Nu se permite o inregistrare CNAME pentru masina mentionata in SOA. In cel de-al doilea rand, hostmaster.subdomain.domain.tld. este de fapt o adresa de e-mail si trebuie citita ca hostmaster@subdomain.domain.tld. In acest exemplu exista un tip nou de RR si anume MX sau Mail eXchanger. Acesta spune sistemului unde sa trimita mailurile pentru someone@subdomain.domain.tld. Numerele care urmeaza dupa MX sunt prioritare pentru respectivul server SMTP, cu cat mai mic, cu atat mai prioritar fiind serverul respectiv.

Observatie: remarcati ca toate numele se termina cu caracterul '.' daca este specificat intregul nume (inclusiv domeniul), si fara acesta, daca este prezent doar numele unei masini (in acest caz, lipsa caracterului '.' duce la concatenarea numelui respectiv cu domeniul de ex mail -> mail.subdomain.domain.tld). Atentie, in cazul in care omiteti punctul de la sfarsit dar specificati si numele domeniului, se va ajunge la rezolvari incorecte, de exemplu mail. subdomain. domain. tld va fi rezolvat ca mail. subdomain. domain. tld. subdomain. domain. tld.!

O versiune mai completa a acestei zone:

;

; Zone file for subdomain.domain.tld

;

; The full zone file

;

@ IN SOA ns.subdomain.domain.tld. hostmaster.subdomain.domain.tld. (

199802151 ; serial, todays date + todays serial #

8H ; refresh, seconds

2H ; retry, seconds

1W ; expire, seconds

1D ) ; minimum, seconds

;

TXT 'subdomain.domain.tld, your DNS consultants'

NS ns ; Inet Address of name server

NS ns.friend.bogus.

MX 10 mail ; Primary Mail Exchanger

MX 20 mail.friend.bogus. ; Secondary Mail Exchanger

localhost A 127.0.0.1

gw A 192.168.196.1

HINFO 'Cisco' 'IOS'

TXT 'The router'

ns A 192.168.196.2

MX 10 mail

MX 20 mail.friend.bogus.

HINFO 'Pentium' 'Linux 2.0'

www CNAME ns

donald A 192.168.196.3

MX 10 mail

MX 20 mail.friend.bogus.

HINFO 'i486' 'Linux 2.0'

TXT 'DEK'

mail A 192.168.196.4

MX 10 mail

MX 20 mail.friend.bogus.

HINFO '386sx' 'Linux 1.2'

ftp A 192.168.196.5

MX 10 mail

MX 20 mail.friend.bogus.

HINFO 'P6' 'Linux 2.1.86'

Au aparut un numar de noi RR-uri, prezentate in output-ul de mai sus. Primul dintre acestea este HINFO (Host INFOrmation), care are doua partii. Prima parte indica platforma hardware a masinii respective, cea de-a doua, pe cea software. CNAME (Canonical NAME) este o cale de a da mai multe nume aceleiasi masini. Astfel, in exemplul de mai sus, www si ns sunt aceeasi masina. Folosirea lui CNAME este destul de controversata, dar trebuie retinut ca o inregistrare MX, CNAME sau SOA nu trebuie niciodata sa se refere la un alt CNAME, ci intotdeauna la o intrare de tip A.




4 Electronic Mail - e-mail

Serviciul de mesaje electronice, e-mail, a fost inventat acum mai bine de doua decenii. In acest capitol se vor prezenta pe scurt cateva detalii legate de istoricul evolutiei acestui sistem, arhitectura, protocoalele si aplicatiile utilizate.


Subsections

  • A. Scurt istoric
  • B. Arhitectura si functionare
  • C. Spam, relay, open-relay
  • D. Aplicatii

A. Scurt istoric

Ideea de mesagerie electronica dateaza din anul 1971, cand Ray Tomlinson dezvolta prima aplicatie e-mail pentru ARPANET. Aceasta era formata din doua programe, SNDMSG, utilizat pentru a trimite mesaje, respectiv READMAIL, folosit pentru citirea mesajelor. In anul 1972, comenzile MAIL si MLFL au fost adaugate programului FTP. Aceasta a fost modalitatea de transmitere a mesajelor in reteaua ARPANET pana la inceputul anilor '80 cand a fost dezvoltat protocolul SMTP.


B. Arhitectura si functionare

In componenta sistemului pentru posta electronica intra urmatoarele componente:

MTA

- Mail Transfer Agent - asigura transportul mesajelor de la sursa la destinatie

MUA

- Mail User Agent - programul folosit de utilizatori pentru a citi/compune mesaje de posta electronica

LDA

- Local Delivery Agent - program ce se ocupa de distributia mesajelor de posta electronica la nivel de utilizator

SMTP

- Simple Mail Transfer Protocol - protocol de nivel aplicatie utilizat de catre MTA

POP3

- Post Office Protocol - protocol utilizat de MUA pentru a ridica mesajele de posta electronica de pe un server

IMAP

- Internet Message Access Protocol

O descriere simpla a functionarii acestor componente ar fi:

  1. utilizatorul compune mesajul utilizand un program de tip MUA. Mesajul trebuie sa respecte un anumit format (specificat in RFC 822).
  2. mesajul este transmis catre MTA-ul local
  3. transmiterea mesajului are loc in urma stabilirii unei conexiuni intre MTA-ul sursa si MTA-ul destinatie portul 25, folosind protocolul SMTP. Dar cum se determina serverul care gestioneaza mesajele de posta electronica pentru destinatie?
  4. la destinatie, LDA este componenta care realizeaza distributia mesajelor in casuta de posta electronica a utilizatorului caruia ii este destinat mesajul
  5. utilizatorul isi poate citi mesajele fie conectandu-se pe masina pe care are casuta de posta electronica, fie folosind protocolul POP3 pentru a transfera mesajele pentru a le citi offline pe orice alt calculator

Formatul unui mesaj asa cum este specificat de RFC 822 este simplu: mesajul este compus dintr-un antet si continut. Dat fiind faptul ca la momentul elaborarii acestor specificatii nu se punea problema de a transmite altceva decat text, nu s-a definit exact forma continutului unui mesaj. Nevoia de a transmite si altceva decat text in cadrul unui mesaj (audio/video) a dus la aparitia unei probleme. Solutia a fost MIME - Multipurpose Internet Mail Extensions. Datorita largii raspandiri a sistemului definit de RFC 822 MIME nu putea sa fie gandit decat ca o adaugire la aceste specificatii. Mai multe informatii depspre MIME se pot gasi in RFC-urile care il descriu: 2045 pana la 2049.

Dupa cum am mentionat mai sus, protocolul utilizat pentru comunicatia intre MTA-uri este SMTP. Acesta este un protocol simplu (asa cum spune si numele) care transmite text ASCII pe 7 biti.

Un mod simplu de a transmite un mesaj este prin conectarea la un server SMTP pe portul 25 utilizand telnet, ca in exemplul ce urmeaza:

[root@home root]# telnet 0 25

Trying 0.0.0.0

Connected to 0.

Escape character is ']'.

220 home.top-technologies.ro ESMTP Sendmail 8.11.6/8.11.6; Sat, 13 Sep

2003 20:25:46 +0300

HELO test

250 home.top-technologies.ro Hello home.top-technologies.ro [127.0.0.1],

pleased to meet you

MAIL FROM: test@test.ro -> se specifica sursa mesajului

250 2.1.0 test@test.ro Sender ok

RCPT TO: alttest@test.ro -> destinatia

250 2.1.5 alttest@test.ro Recipient ok (will queue)

DATA -> urmeaza textul mesajului

354 Enter mail, end with '.' on a line by itself

Un mesaj simplu.

.  -> caracterul '.' singur pe linie semnaleaza sfarsitul mesajului

250 2.0.0 h8DHQ5o02151 Message accepted for delivery

QUIT

221 2.0.0 home.top-technologies.ro closing connection

Connection closed by foreign host.

Pentru a rezolva unele din limitarile protocolului SMTP, un nou protocol a fost definit: ESMTP (SMTP extins). Odata cu acest nou protocol, a fost definita si o modalitate de a determina versiunea de SMTP suportata de un server. Astfel un client capabil ESMTP isi va incepe dialogul cu serverul utilizand comanda EHLO in loc de HELO. Daca raspunsul primit de la server nu este unul de eroare, clientul va folosi in continuare ESMTP, in caz contrar revenindu-se la folosirea SMTP.




Un alt protocol des utilizat este POP3 (Post Office Protocol), specificat in RFC 1939. Acesta este utilizat de aplicatiile de tip MUA pentru a ridica posta electronica de pe un server. Acest serviciu ruleaza pe portul tcp 110. Protocolul este destul de simplu si functioneaza astfel:

  • intr-o prima faza, clientul (un Mail User Agent) conectat la serverul POP3 trebuie sa se autentifice; aceasta se realizeaza prin utilizarea comenzilor USER si PASS
  • dupa autentificare, se poate obtine o lista a mesajelor din casuta postala utilizand comanda LIST; pentru a transfera aceste mesaje pe calculatorul pe care ruleaza clientul, acesta va folosi comanda RETR.
  • Dupa ce mesajele au fost transferate de pe server, acestea pot fi sterse utilizand comanda DELE
  • Sesiunea se incheie utilizand comanda QUIT

Exemplu de functionare a protocolului POP3:

cristi@crystal:$ telnet pop31.xnet.ro 110

Trying 217.10.192.236

Connected to pop31.xnet.ro.

Escape character is ']'.

+OK Sendmail Proxy v2.1.0 POP3 ready.

USER arpy@xnet.ro

+OK password please

PASS ******

+OK Maildrop locked and ready

LIST

+OK scan listing follows

1 2887

2 723

.

RETR 2

+OK Message follows

Return-Path: <arpy@xnet.ro>

Received: from localhost by xsams2 with LMTP for <arpy@xnet.ro>; Sun, 14 

Sep 2003 00:43:42 +0300

Received: from mta3.xnet.ro (mta3.xnet.ro [217.10.192.251])

by xsams2.xnet.ro (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8DLhgE31265

for <arpy@xnet.ro>; Sun, 14 Sep 2003 00:43:42 +0300

From: arpy@xnet.ro

Received: from x (crystal.Bucharest.roedu.net [141.85.128.75])

by mta3.xnet.ro (Switch-3.1.0/Switch-3.1.0) with SMTP id h8DLgoSi027399

for arpy@xnet.ro; Sun, 14 Sep 2003 00:43:21 +0300

Date: Sun, 14 Sep 2003 00:42:50 +0300

Message-Id: <200309132143.h8DLgoSi027399@mta3.xnet.ro>

Subject: Test

X-RAVMilter-Version: 8.4.3(snapshot 20030212) (mta3.xnet.ro)

X-Wilter: on xsams2.

.

DELE 1

+OK message deleted

LIST

+OK scan listing follows

2 723

.

QUIT

+OK

Connection closed by foreign host.

Protocolul POP este utilizat in special pentru transferarea mesajelor de pe server pe orice alt calculator pentru a le citi offline. In cazul in care se doreste accesarea unui singur cont de posta electronica de la mai multe locatii (acasa/birou), protocolul POP3 este limitat. Acest dezavantaj a dus la dezvoltarea unui alt protocol, IMAP - Internet Message Access Protocol, specificat in RFC 2060. In mod asemanator cu POP3, si IMAP permite transferarea mesajelor catre un alt calculator. Atunci cand IMAP este utilizat in modul online clientul nu transfera mesajele si nici nu le sterge de pe server. Clientul poate cere insa sa primeasca antetele mesajelor sau anumite parti din mesaje, sau chiar mesaje care se potrivesc unui criteriu de cautare. De fapt, IMAP permite manipularea mesajelor dintr-o casuta postala aflata pe un server ca si cand acestea ar fi stocate local.


C. Spam, relay, open-relay

In cele ce urmeaza vom incerca sa definit cativa termeni legati direct de sistemul de posta electronica:

Spam = mesaje nesolicitate

In prezent trimiterea de mesaje nesolicitate este foarte des intalnita. Exista aplicatii care actioneaza ca filtre anti-spam.

Relay = din punctul de vedere al unui server SMTP, relaying inseamna actiunea de a primi un mesaj care nu este destinat unei adrese din domeniul de care respectivul server raspunde, si a-l transmite mai departe catre destinatie.

Open relay - un server SMTP este 'open relay' atunci cand accepta si forwardeaza mesaje catre alte domenii decat cel local fara sa tina cont de sursa acestora.

In zilele de inceput ale sistemului de posta electronica, majoritatea serverelor SMTP erau configurate ca open-relay. Larga raspandire a mesajelor de tip spam la care s-a ajuns in prezent a schimbat aceasta practica, serverele open-relay fiind usor de utilizat pentru a trimite spam.


D. Aplicatii

Dupa cum am vazut in sectiunea 10.3.2, aplicatiile care intra in componenta sistemului de posta electronica sunt urmatoarele:

  • Mail Transfer Agent
    • Exista in momentul de fata trei competitori in cadrul acestei categorii: Sendmail, Qmail si Postfix, Sendmail fiind serverul SMTP cu cea mai mare utilizare. Atat Qmail cat si Postfix au aparut din acelasi motiv: nevoie de a rezolva problemele de securitate cu care se confrunta Qmail, Postfix neajungand inca la nivelul de utilizare atins de Qmail. In cele ce urmeaza vom compara succint Sendmail si Qmail:
    • Unul din avantajele Sendmail este ca este cel mai matur dintre cele trei enumerate mai sus, si in consecinta, cel mai bine documentat.
    • Un dezavantaj al Sendmail este complexitatea fisierului de configurare; exista insa unelte pentru generarea acestui fisier de configurare
    • De asemenea, numeroasele probleme de securitate intalnit de-a lungul timpului la Sendmail constituie un dezavantaj; exista bineinteles si un aspect pozitiv al acestei probleme, faptul ca aceste probleme au fost descoperite si rezolvate confirma faptul ca Sendmail este un produs matur
    • Dimensiune si complexitatea la care a ajuns Sendmail il fac suspect de posibile probleme de securitate nedescoperite inca
    • Pe de alta parte, Qmail nu este atat de complex ca Sendmail, dar totusi ofera toate faciltitatile necesare pentru majoritatea utilizatorilor; in plus, configurarea este mai usoara
    • Documentatia pentru Qmail nu este atat de sofisticata ca cea pentru Sendmail
  • Mail User Agent
    • Mutt
    • Mail
    • Pine - este cel mai utilizat MUA dintre cele prezentate
    • Elm
    • Mailx
  • Local Delivery Agent
    • Procmail
    • Qmail-local

Mai multe detalii legate de configurarea Qmail vor fi prezentate in sectiunea dedicata studiilor de caz de la sfarsitul acestui capitol.


5 World Wide Web


Subsections

  • A. Scurt istoric
  • B. Ce este WWW si cum functioneaza?
  • C. Server-e si clienti Web
  • D. Instalarea si configurarea Apache Web Server

A. Scurt istoric

Istoria World Wide Web, mai exact istoria modului de organizare a informatiei folosit de WWW, incepe in 1945, cand se lansa ideea unui sistem de organizare asociativa a informatiei numit memex (Vannevar Bush). In 1965 s-a conturat ideea de hipertext (Ted Nelson). Se pornea de la premisa ca legaturile intre documente faciliteaza intelegerea unui text.

Aceste idei au fost puse in practica de Tim Berners-Lee, un cercetator de la CERN, Elvetia, astfel ca in 1990 se rula un prim prototip al sistemului WWW. In 1992, interfata WWW a devenit disponibila public pe calculatoarele de la CERN.

Un moment deosebit de important pentru sistemul Web este anul 1993, an in care o echipa condusa de Marc Andreessen, student la Universitatea Illinois (mai tarziu, unul dintre fondatorii companiei Netscape Communications), a dezvoltat primul browser Web, Mosaic. Acest fapt a dus la o crestere remarcabila a interesului pentru WWW, ajungandu-se la dezvoltarea actuala.


B. Ce este WWW si cum functioneaza?

World Wide Web (WWW) este un sistem de comunicare a informatiilor care functioneaza pe baza unui model client/server, la baza acestei comunicatii intre client si server aflandu-se protocolul HTTP (Hyper Text Transfer Protocol).

HTTP este un protocol simplu de nivel aplicatie, care specifica atat modul in care un client (un program de tip browser) formuleaza o cerere catre un server cat si modul in care serverul raspunde unei cereri. HTTP utilizeaza TCP, ascultand pe portul 80.

Modul de functionare este simplu. Cea mai potrivita modalitate de prezentare este un exemplu:

  • Dupa ce lansati un program de tip browser si tastati o adresa web, de exemplu cs. pub. ro/ index.html , au loc urmatoarele:
    • Se va contacta serverul DNS pentru a obtine adresa IP corespunzatoare numelui cs.pub.ro,
    • Se va deschide o conexiune cu 141.85.37.1 pe portul 80
    • Se va trimite o cerere HTTP pentru fisierul index.html; o astfel de cerere are urmatoarea structura: GET /cale/nume_fis HTTP/1.x (unde 1.x reprezinta versiunea de HTTP utilizata 1.0 sau 1.1)
    • Rezultatul primit de la server este interpretat de catre browser si rezultatul este afisat

Exemplu:

[root@home root]# telnet 0 80

Trying 0.0.0.0

Connected to 0.

Escape character is ']'.

GET /index.html HTTP/1.0

HTTP/1.1 200 OK

Date: Sat, 13 Sep 2003 23:35:20 GMT

Server: Apache/1.3.23 (Unix) (Red-Hat/Linux) mod_ssl/2.8.7 OpenSSL

/0.9.6b DAV/1.0.3 PHP/4.1.2 mod_perl/1.26

Last-Modified: Tue, 09 Apr 2002 18:56:58 GMT

ETag: 'fffe-b4a-3cb3397a'

Accept-Ranges: bytes

Content-Length: 2890

Connection: close

Content-Type: text/html

<!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 3.2 Final//EN'>

<HTML>

<HEAD>

<TITLE>Test Page for the Apache Web Server on Red Hat Linux</TITLE>

</HEAD>


C. Server-e si clienti Web

Exista o multitudine de server-e/clienti pentru Web. In ceea ce priveste server-ele, situatia pe piata este urmatoarea:

Apache

35.68%

NCSA

18.25%

Netscape

Communications 7.25%

Netscape

Commerce 6.83%

CERN

6.22%

Microsoft

Internet Information Server 5.49%

WebSite

3.40%

WebSTAR

1.95%

Apache SSL US

1.43%

Purveyor

1.38%

WebSitePro

1.07%

Cateva dintre cele mai utilizate aplicatii client WEB sunt Internet Explorer, Netscape, Mozilla si Opera.


D. Instalarea si configurarea Apache Web Server

Am ales pentru exemplificare server-ul Web Apache, acesta fiind cel mai raspandit. Motivele posibile pentru aceasta raspandire larga sunt:

  • este Open Source
  • este usor de instalat
  • este usor de configurat
  • exista versiune precompilata pentru orice fel de platforma
  • este foarte rapid
  • ofera suport pentru autentificarea userilor
  • permite 'virtual hosting'
  • ofera securitate mai buna decat alte servere WEB

Procedura de instalare este foarte simpla si este inclusa in distributie. Odata instalat, pentru a putea folosit server-ul Web sunt necesare cateva mici configurari. Fisierul de configurare utilizat de Apache este de obicei localizat in /etc/ httpd/ conf/ si se numeste httpd.conf. Cele mai importante directive utilizate in cadrul acestui fisier sunt:

ServerType

- standalone/inetd - specifica modul in care va rule server-ul; in general se recomanda standalone, pornirea utilizand inetd nu este recomandata decat in cazul server-elor Web cu incarcare foarte mica

ServerRoot

- specifica calea catre directorul care va fi folosit de server pentru stocarea fisierelor de configurare si de jurnalizare.

User/Group

- utilizator/grup ale caror permisiuni vor fi mostenite de server dupa initializare; in nici un caz root, valoarea implicita este apache

ServerAdmin

- specifica adresa de e-mail a administratorului sitului respectiv; aceasta adresa apare in cadrul paginilor generate in urma unei erori

ServerName

- numele acestui server; nu poate fi orice, trebuie sa existe in DNS

DocumentRoot

- calea catre directorul de unde server-ul va servi pagini; de obicei /var/ www/ html

DirectoryIndex

- numele fisierelor pe care server-ul le va considera ca index pentru o pagina

UserDir

- numele directorului care este concatenat cu numele directorului home al unui utilizator atunci cand se primeste o cerere de forma user; se permite astfel fiecarui utilizator sa mentina o pagina web proprie;valoarea implicita este public_html; Atentie la permisiuni! Pentru /home/user 711 iar pentru /home/user/public_html 755. Continutul directorului /home/user/public_html trebuie sa fie accesibil pentru citire.

<Directory

'cale'> se incheie cu </Directory> - permite stabilirea unor parametri pentru un anumit director:

Options

optiuni, unde optiuni poate fi o lista cu urmatoarele elemente:

Indexes

- in cazul in care directorul respectiv nu contine un fisier considerat index, se va lista continutul directorului

FollowSymLinks

- activeaza urmarirea legaturilor simbolice

ExecCGI

- activeaza executia de script-uri CGI (Common Gateway Interface) din acest director; aceste script-uri sunt executate de catre server, rezultatul executiei fiind generarea unei pagini care este trimisa inapoi catre browser; o utilizare a acestor script-uri este validarea/prelucrarea datelor introduse de un vizitator intr-un formular

Dupa ce s-au realizat configurarile de baza este necesara pornirea server-ului. Aceasta se poate face utilizand apachectl, care are urmatoarea sintaxa:

apachectl start | stop| restart

Apache mentine si niste jurnale care contin informatii legate de functionarea sa. Acestea se numesc access_log, respectiv error_log si se gasesc in directorul /var/log/httpd. Primul contine informatii legate de cererile primite de server-ul Web, iar cel din urma, informatii referitoare la erori, acesta fiind foarte util in cazul in care tentativa de a porni server-ul nu are succes.

O capabilitate foarte utila a server-ului Web Apache este 'virtual hosting'. Mai multe detalii cu privire la aceasta sunt incluse in sectiunea dedicata studiilor de caz de la sfarsitul acestui capitol.


6 NIS & NFS

Atat NIS (Network Information Service) cat si NFS (Network File System) au fost dezvoltate de catre Sun Microsystems pentru a oferi un mijloc simplificat/centralizat de administrare a mai multor statii UNIX. Ele au devenit un standard de facto in lumea UNIX. Sunt extrem de utile atunci cand administram un numar mare de statii UNIX si alaturi de MPI au fost folosite cu succes in HPC (High Performance Computing), compilation farm, rendering farm datorita faptului ca PC-urile ``off the shelf'' tind sa devina din ce in ce mai ieftine, si un ansamblu de mai multe asemenea PC-uri - denumit Cluster of Workstations sau COW, ofera adeseori puterea de calcul echivalenta cu cea oferita de hardware dedicat dar mult mai scump.


Subsections

  • A. RPC
  • B. NIS
  • C. NFS

A. RPC

Ambele protocoale folosesc Remote Procedure Calling pentru a schimba informatii intre client si server. Remote Procedure Calling este un alt protocol propus de catre Sun Microsystems si acceptat ca standard de facto in lumea UNIX.

Acest protocol are ca efect executia unui proceduri de catre o masina pe alta masina prin retea in mod transparent. Pentru ca masinile din retea pot avea arhitecturi diferite cu implicatii asupra functionarii apelurilor de proceduri la distanta (big/little endian, 16/32/64 biti) functionarea protocolului se bazeaza pe o descriere a datelor independenta de arhitectura (XDR). RPC permite ca o procedura sa fie apelata un numar oarecare de operanzi de diverse tipuri cu anumite limitari. De exemplu, in implementarea C, sunt permise tipurile care descriu intregi, structuri, dar nu pointeri.

Arhitectura RPC este una client-server. Avem un server ce ofera servicii - in cazul nostru executa o anumita procedura, si un client ce foloseste serviciile oferite de server - in cazul nostru se apeleaza o procedura de la distanta cu anumiti parametri si se asteapta executia acesteia pe server si intoarcerea rezultatului.

Pentru a oferi un ajutor programatorului care doreste sa dezvolte aplicatii RPC, exista posibilitatea ca acesta sa descrie interfata dintre client si server (practic un fel de declaratie forward a procedurii) si apoi sa foloseasca un compilator care sa genereze programe (unul pentru client si unul pentru server) care sa se ocupe cu translatarea parametrilor intr-un format independent de arhitectura, sa trimita parametri si valoarea de return a procedurii prin retea si eventual, cu tratarea erorilor, daca protocolul de transport folosit nu este reliable. Tot ce mai are de facut programatorul este sa scrie codul pentru executia procedurii (pe server), codul pentru client (in care apelul RPC este practic o functie generata automat) si in general linkarea cu o anumita biblioteca.

Protocolul RPC este relativ simplu, poate sa lucreze cu mai multe protocoale de transport (sunt suportate cel putin TPC si UDP), ceea ce il face flexibil si eficient (pentru ca nu introduce overhead). O problema a protocolului este faptul ca este nesigur. Aceasta problema a fost corectata in versiunile mai noi, dar oricum in mod normal aceste protocoale se folosesc intr-un mediu despre care se presupune ca nu este ostil. In general serviciile bazate pe RPC sunt folosite doar in interiorul retelei locale, si o configurare corecta a unui firewall rezolva de cele mai multe ori problema. Daca mediul este ostil (sa presupunem ca un utilizator remote se conecteaza prin Internet in reteaua locala), se pot gasi solutii ca VPN pentru evitarea problemelor de securitate.

Pentru ca overhead-ul introdus de protocol sa fie cat mai mic (de exemplu daca atat serverul cat si clientul se afla in cadrul aceleasi retele ar trebuie sa se foloseasca UDP) dar in acelasi timp protocolul sa fie sigur (daca serverul si clientul se afla in retele diferite ar trebuie sa se foloseasca TCP) cat si datorita faptului ca protocoalele care folosesc RPC evolueaza, a fost inclusa in specifica RPC un serviciu care mapeaza serviciile oferite de server-e (server, versiune) in informatii pentru nivelul transport (TPC/UDP, port). Astfel un server se va inregistra la portmapper-ul care ruleaza pe masina locala, iar un client se va conecta mai intai la portmapper-ul de pe masina ce ofera servicii si va afla informatiile de nivel transport necesare. Din acest motiv portmapper-ul trebuie sa ruleze pe masina care ofera servicii RPC, si sa fie pornit inaintea acestor servicii.

/etc/rc.d/init.d/portmap

porneste/opreste portmapper-ul; portmapper-ul trebuie pornit inaintea oricarui server RPC; daca portmapper-ul este restartat trebuie restartate si serverele RPC

rpcinfo -p



afiseaza maparea dintre protocolul RPC si protocolulul de nivel transport

rpcinfo -d prognum versnum

sterge din mapare protoculul prognum cu versiunea versnum

rpcgen

compilator ce genereaza cod C pentru implementarea unui protocol RPC; genereaza atat serverul cat si clientul


2 NIS

NIS este un protocol RPC, deci are o arhitectura client server. In implementarea sa initiala NIS s-a numit YP, de la Yellow Pages, dar pentru ca Yellow Pages este o marca inregistrata a British Telecom, Sun a convertit YP la NIS; in ciuda aceste redenumiri, urmele inca mai persista (serverul se cheama ypserv, clientul ypbind). NIS este folosit pentru ``distribuirea'' fisierelor de configurare pe mai multe statii UNIX.

Exista unul sau mai multe server-e care deserversc unul sau mai multe domenii. Intr-un domeniu exista intotdeauna un singur server master si pot exista si servere slave. Serverul NIS tine harti ale fisierelor de configurare. Aceste harti sunt practic niste baze de date (DBM) ce contin informatiile din fisierele de configurare (nume si parole utilizatori, nume si adrese de hosturi, nume de servicii si informatii pentru nivelul transport) sortate dupa unul din campuri. Pentru un fisier de configurare avem una sau mai multe harti corespunzatoare (daca avem mai multe harti pentru un fisier, atunci acestea sunt sortate dupa campuri diferite pentru a putea gasi rapid informatiile cerute).

Hartile sunt create si distribuite catre serverele slave de catre master. Serverele (atat master cat si slave) sunt interogate de catre clienti. Interogarea este specifica pentru fiecare fisier de configurare in parte, dar in general putem privi cererea clientului ca un select cu whereis intr-o baza de date (de exemplu, clientul cere informatii despre userul gigel - parola, directorul home, etc., cere numele host-ului care are adresa 141.85.99.78, sau cere adresa host-ului cu numele cygnus).

Versiunile mai vechi de clienti erau nesigure pentru ca trimiteau cereri catre servere prin broadcast. La versiunile actuale se poate configura si serverul la care sa se trimita cererile pentru a nu crea brese de securitate. A fost dezvoltata si o versiune mai noua de NIS de catre Sun, NIS+ ce suporta secure RPC si data encryption si un sistem mai avansat de numire (un arbore multicai).

/etc/rc.d/init.d/ypbind

porneste/opreste clientul NIS

rpc.ypbind

clientul NIS

/etc/yp.conf

fisier de configurare pentru clientul NIS; trebuie setate numele/adresa serverului de NIS precum si domeniul NIS

/etc/nsswitch.conf

Name Service Switch Configuration file; seteaza comportarea masinii locale pentru fiecare fisier de configurare in parte: fisier text, fisier DBM, informatiile sunt tinute de catre un server NIS/NIS+

/etc/rc.d/init.d/ypserv

porneste/opreste serverul NIS

rpc.ypserv

serverul NIS

/etc/ypserv.conf

fisier de configurare pentru serverul NIS; defineste ce host-uri au acces la ce harti

/usr/lib/ypinit -m

converteste fisierele de configurare in harti NIS pe serverul master;

/var/yp/Makefile

fisier care contine descrierea hartilor ce vor fi generate de catre ypinit; acest fisier poate sa nu existe daca ypinit nu a mai fost rulat

/etc/rc.d/init.d/yppasswd

porneste/opreste serverul NIS folosit de passwd atunci cand utilizatorul doreste sa-si schimbe parola, iar statia foloseste NIS pentru /etc/passwd (si /etc/shadow)

rpc.yppasswd

serverul de schimbat parole NIS


C. NFS

NFS este un alt protocol RPC dezvoltat de Sun Microsystems, avand aceeasi arhitectura client-server. Serverele au rolul de a distribui clientilor sisteme de fisiere si nu doar fisiere, in sensul ca utilizatorul vede sistemul de fisiere exportat de catre server si montat pe masina locala ca fiind local. Din acest motiv partea de client a NFS-ului este strans legata de sistemul de operare, fiind implementata in nucleul acestuia.

NFS este ca si alte protocoale bazate pe RPC un protocol simplu ce introduce un overhead foarte mic. Practic, serverul ofera clientului proceduri de genul readdir, read, write, etc la distanta. Ceea ce difera fata de functiile similare care sunt folosite local, este faptul ca pentru un fisier nu exista proceduri de genul open sau close, fisierul este deschis/inchis in momentul executiei procedurii. Acest lucru face protocolul NFS fiabil in situatia in care serverul dintr-un motiv sau altul este oprit/repornit: clientul va continua sa citeasca/scrie fisierul in momentul cand serverul este repornit.

Tratarea de catre client a situatiilor in care serverul devine indisponibil se face prin blocarea neintreruptibila a procesului care incearca sa execute operatii pe sistemul de fisiere exportat de respectivul server. Acest comportament poate fi schimbat, fie prin specificarea unui timeout dupa care operatia sa esueze (nerecomandat), fie prin blocarea intreruptibila a procesului.

mount -t nfs nfs_server:/path_to_exported_fs local_path

monteaza sistemul de fisiere exportat de catre server in directorul local_path

/etc/rc.d/init.d/nfs

porneste/opreste serverul de NFS

/etc/exports

lista cu directoarele de exportat, optiuni (read/write) si host-urile care au voie sa monteze directoarele de pe server, folosita de scriptul de pornire al serviciului NFS

exportfs

adaugare/stergere/vizualizare lista de exportat (nu /etc/exports)

rpc.mountd

parte din serverul NFS ce se ocupa de gestionarea cererilor de mount catre server

rpc.nfsd

parte din serverul NFS ce implementeaza procedurile RPC read, write, readdir, etc.; in mod normal acest server ruleaza in spatiul utilizator, dar versiunile mai noi implementeaza aceasta parte direct in nucleu pentru performante mai bune

rpc.lockd

parte din serverul NFS ce implementeaza proceduri RPC de lock/unlock pe fisierele exportate de server; in mod normal acest server ruleaza in spatiul utilizator, dar versiunile mai noi implementeaza aceasta parte direct in nucleu pentru performante mai bune

showmount host

afiseaza lista de directoare care pot fi montate de statii, cine poate monta aceste directoare precum si ce host-uri au monate ce directoare de pe host


7 Studii de caz


Subsections

  • A. Configurarea Qmail
  • B. 'Virtual Hosting' cu Apache
    • 1 Gazduire virtuala bazata pe adrese IP
    • 2 Gazduire virtuala bazata pe nume

A. Configurarea Qmail

Qmail este disponibil atat in forma binara cat si ca sursa. Dat fiind faptul ca intructiunile de instalare incluse in pachetele Qmail sunt usor de urmarit, nu am considerat necesara includerea lor in aceasta sectiune.

La instalarea Qmail se va crea directorul /var/qmail/ care contine pe langa altele urmatoarele subdirectoare:

alias/

- utilizat pentru a defini alias-uri

bin/

- contine fisierele executabile

control/

- contine fisiere de configurare pentru Qmail

queue/

- directorul pentru coada de mesaje

Dintre fisierele continute de /var/qmail/control, cele mai importante sunt:

default_domain

- acest fisier trebuie sa contina numele de domeniu

locals

- contine numele domeniilor pentru care posta electronica este colectata pe acest server

me

- numele FQDN (Fully Qualified Domain Name), adica nume.domeniu pentru server-ul respectiv

rcpthosts

- domenii pentru care se accepta mesaje

smtpgreeting

- contine textul care va fi afisat ca mesaj de intampinare de catre server

badmailfrom

- lista cu adresele de la care nu se accepta mail

Am definit anterior relaying ca fiind actiunea de a accepta si de a transmite mai departe catre destinatie un mesaj care are ca destinatie o adresa care nu este locala. Modul in care Qmail realizeaza functia de relay este controlat de fisierul /var/qmail/control/rcpthosts. Pentru ca server-ul dvs. sa nu fie open-relay, va trebui sa listati aici domeniile pentru care server-ul respectiv pastreaza mesajele. Sa presupunem ca sunteti un ISP (Internet Service Provider); veti lista in /var/qmail/control/rcpthosts numele de domeniu ale clientilor dvs. Totusi atunci cand un client va incerca sa trimita un mesaj va primi un mesaj de genul 'Sorry, that domain isn't in my list of allowed rcpthosts'. De ce se intampla acest lucru? Adresa destinatie este verificata pentru a testa daca face parte din domeniile listate in /var/qmail/control/rcpthosts. Este evident ca nu putem lista in respectivul fisier toate domeniile catre care clientii ar dori sa trimita mesaje. Componenta Qmail care implementeaza SMTP, qmail-smtpd, dispune de o modalitate de a ocoli cautarea in rcpthosts: daca este setata variabila de mediu RELAYCLIENT, qmail-smtpd va ignora rcpthosts.

O noua problema apare: cum identificam clientii pentru care facem relaying? In functie de adresa sursa specificata de campul From din mesaj? Raspunsul este nu, identificarea se va face in functie de adresa IP. Identificarea dupa adresa specificata de campul From nu este deloc sigura, neexistand nici un mod de a verifica daca aceasta este reala.

Pentru a putea realiza setarea selectiva a acestei variabile de mediu trebuie sa utilizati doua aplicatii suplimentare: tcprules si tcpserver, care se gasesc in pachetul ucspi.

Pasii necesari pentru a configura relaying selectiv sunt:

1. Adaugati in fisierul /etc/tcp.smtp cate o intrare cu sintaxa prezentata mai jos pentru fiecare client de la care server-ul ar trebui sa accepte si sa transmita mai departe mesaje.

Adresa client: allow, RELAYCLIENT = ''

2. Dupa fiecare modificare, reconstruiti baza de date pentru acces creata pe baza acestui fisier:

tcprules /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp < /etc/tcp.smtp

3. Qmail-smtpd va fi pornit utilizand tcpserver, inserand o linie asemanatoare cu cea de mai jos in /etc/inittab.

Qm:345:respawn: /usr/local/bin/tcpserver -x/etc/tcp.smtp.cdb -u1003 

-g102 0 smtp /var/qmail/bin/qmail-smtpd

unde -u -g specifica valoarea User ID pentru userul qmaild si grupul din care acesta face parte.

Tcpserver este cel care monitorizeaza conexiunile la server-ul SMTP si seteaza variabila de mediu RELAYCLIENT pentru conexiunile initiate de surse a caror adresa este listata in /etc/tcp.smtp.

Un alt aspect des intalnit legat de configurarea Qmail il constituie crearea de alias-uri. Un alias ofera posibilitatea de a primi mesaje pentru un utilizator care nu exista, mesajul fiind trimis catre un utilizator real specificat. Aceasta facilitate este implementata de componenta Qmail numita qmail-local, care este un Local Delivery Agent.

Un caz in care veti avea nevoie sa folositi un alias este utilizatorul root, deoarece atunci cand se utilizeaza qmail-local, acest utilizator nu poate primi mesaje. Un astfel de alias se defineste prin crearea unui fisier de forma .qmail-nume_utilizator in directorul /var/qmail/alias, fisier care contine numele utilizatorului in a carui casuta de mesaje vor ajunge mesajele destinatele utilizatorului pentru care a fost creat alias-ul.

Este important de mentionat ca si utilizatorul are la dispozitie un mecanism de a redirecta mesajele catre alta adresa: fisierul .qmail din directorul home al utilizatorului; acesta va contine adresa la care vor fi trimise mesajele.


B. 'Virtual Hosting' cu Apache

Termenul de 'gazduire virtuala' (virtual hosting) se refera posibilitatea mentinerii de pagini web pentru mai multe domenii pe acelasi server.

Exista doua moduri de a implementa gazduirea virtuala a paginilor web, gazduire virtuala bazata pe adrese IP sau pe nume.


Subsections

  • 1 Gazduire virtuala bazata pe adrese IP
  • 2 Gazduire virtuala bazata pe nume

1 Gazduire virtuala bazata pe adrese IP

Asa cum spune si numele, pentru aceasta metoda este necesara cate o adresa IP pentru fiecare host virtual. Aceste adrese se asigneaza de obicei pe interfetele fizice existente.

Exista doua abordari posibile in cadrul acestei metode:

  • Pornirea unui demon httpd pentru fiecare host
    • Se utilizeaza atunci cand sunt necesare configurari diferite pentru fiecare host virtual in parte
    • Necesita multa memorie
  • Utilizarea unei singure instante a httpd pentru toate host-urile virtuale
    • Aceasta metoda este mai des utilizata
    • Resursele necesare sunt mai mici
    • Un exemplu:

<VirtualHost www.smallco.com>

ServerAdmin webmaster@mail.smallco.com

DocumentRoot /groups/smallco/www

ServerName www.smallco.com

ErrorLog /groups/smallco/logs/error_log

TransferLog /groups/smallco/logs/access_log

</VirtualHost>

<VirtualHost www.baygroup.org>

ServerAdmin webmaster@mail.baygroup.org

DocumentRoot /groups/baygroup/www

ServerName www.baygroup.org

ErrorLog /groups/baygroup/logs/error_log

TransferLog /groups/baygroup/logs/access_log

</VirtualHost>




2 Gazduire virtuala bazata pe nume

Am vazut in sectiunea anterioara ca pentru gazduirea virtuala bazata pe adrese IP, este nevoie de cate o adresa IP pentru fiecare host virtual. In cazul gazduirii virtuale bazate pe nume, serverul se bazeaza pe faptul ca clientul va raporta numele in cadrul antetelului HTTP, serverul folosind pentru gazduire virtuala determinand pagina care trebuie trimisa clientului pe baza acestui nume.

Sa presupunem ca server-ul dvs. Web gazduieste www.test1.ro si www.test2.ro, acesta din urma indicand catre aceiasi adresa IP cu primul. Fisierul httpd.conf pentru acest server trebuie sa contina urmatoarele:

NameVirtualHost *

<VirtualHost *>

ServerName www.test1.ro

DocumentRoot /www/test1

</VirtualHost>

<VirtualHost *>

ServerName www.test2.ro

DocumentRoot /www/test2

</VirtualHost>

unde * poate fi inlocuit cu o adresa IP.

Aceasta metoda de a implementa gazduire virtuala, este evident mai avantajoasa, deoarece se economisesc adrese IP. Trebuie avut in vedere urmatorul aspect atunci cand se utilizeaza aceasta metoda: exsita browser-e mai vechi care nu suporta extensiile adaugate la HTTP 1.0, necesare pentru a utiliza aceasta facilitate.


8 Intrebari

  1. Secure Shell utilizeaza:
    1. tcp, portul 22
    2. udp, portul 22
    3. tcp portul 222
    4. udp portul 222
  2. Sistemul DNS foloseste:
    1. Tcp, portul 53
    2. Udp, portul 53
    3. O baza de date centralizata
    4. O baza de date distribuita
  3. In cadrul fisierului de configurare pentru o zona DNS o intrare de tip A:
    1. realizeaza o asocierea intre o adresa IP si un nume
    2. realizeaza o asociere intre un nume si o adresa IP
    3. nu este valida
    4. specifica serverul SMTP care gestioneaza transmiterea de mesaje pentru domeniul respectiv
  4. Care afirmatii sunt adevarate in ceea ce priveste sistemul de posta electronica?
    1. SMTP este protocolul utilizat intre MTA (Mail Transfer Agent)
    2. SMTP este protocolul utilizat de catre o aplicatie de tip MUA (Mail User Agent) pentru a transfera mesajele de pe server
    3. SMTP utilizeaza portul 25
    4. SMTP nu este folosit pentru posta electronica
  5. Pentru un server SMTP relaying reprezinta:
    1. A primi un mesaj care nu este destinat unui utilizator din domeniile gestionate de server si a-l transmite mai departe catre destinatie.
    2. A primi un mesaj care este destinat unui utilizator din domeniile gestionate de server si a-l transmite mai departe catre destinatie.
    3. Termenul de relaying are sens in contextul unui Mail User Agent, nu al unui server SMTP
    4. Nici unul din raspunsurile de mai sus
  6. Sistemul WWW se bazeaza pe un model client/server, modul de comunicare intre client si server fiind definit de protocolul HTTP. Cum arata cererea generata de browser-ul dvs. atunci cand incercati sa accesati www.test.com/file.html?
    1. GET www.test.com/file.html HTTP
    2. GIVE ME www.test.com/file.html HTTP/1.0
    3. GET www.test.com/file.html HTTP/1.0
    4. GET /file.html HTTP/1.0
  7. Unde sunt localizate fisierele utilizate pentru configurarea Qmail?
    1. /etc/qmail/
    2. /var/qmail/control
    3. /var/qmail/conf
    4. Nici unul din raspunsurile de mai sus
  8. Server-ul Web Apache dispune capabilitatea de Virtual Hosting. Selectati afirmatiile corecte din cele de mai jos:
    1. Exista doua modalitati de configurare: IP based virtual hosting si name based virtual hosting
    2. Un numar maxim de 64 de host-uri virtuale poate fi definit
    3. Name based virtual hosting este mai avantajos decat IP based virtual hosting, deoarece se conserva adrese IP
    4. Pentru functionarea Name based virtual hosting este necesar ca clientul sa foloseasca anumite extensii HTTP 1.0
  9. Selectati afirmatiile adevarate referitoare la NFS.
    1. NFS este un protocol RPC cu arhitectura client/server
    2. Serverul NFS pune la dispozitia clientilor sisteme de fisiere
    3. Din punctul de vedere al clientului NFS, accesul la un sistem de fisiere exportat de server se face ca si cand acesta ar fi local
    4. NFS nu este protocol de retea, ci doar un joc (Need For Speed) produs de Sun Microsystems








Politica de confidentialitate

DISTRIBUIE DOCUMENTUL

Comentarii


Vizualizari: 1417
Importanta: rank

Comenteaza documentul:

Te rugam sa te autentifici sau sa iti faci cont pentru a putea comenta

Creaza cont nou

Termeni si conditii de utilizare | Contact
© SCRIGROUP 2019 . All rights reserved

Distribuie URL

Adauga cod HTML in site