| CATEGORII DOCUMENTE |
In cadrul acestui capitol vor fi prezentate detalii legate de configurarea unor servicii de retea: SSH, DNS, Web, Mail, NFS.
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
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:
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:
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
Ssh ia configurarile necesare din urmatoarele surse (in aceasta ordine):
Pentru fiecare parametru va fi folosita prima valoare obtinuta.
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
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
Subsections
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:
Solutia la aceste probleme a fost data in anul 1984 de catre Paul Mockapetris, inventatorul DNS in forma sa actuala.
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.
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. (
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
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.
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
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. (
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. (
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.
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
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.
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:
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
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:
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
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
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.
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.
Dupa cum am vazut in sectiunea 10.3.2, aplicatiile care intra in componenta sistemului de posta electronica sunt urmatoarele:
Mai multe detalii legate de configurarea Qmail vor fi prezentate in sectiunea dedicata studiilor de caz de la sfarsitul acestui capitol.
Subsections
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
Un moment deosebit de important pentru sistemul Web este anul
1993, an in care o echipa condusa de Marc Andreessen, student
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:
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>
Exista o multitudine de server-e/clienti pentru Web. In ceea ce priveste server-ele, situatia pe piata este urmatoarea:
Apache
NCSA
Netscape
Communications 7.25%
Netscape
Commerce 6.83%
CERN
Microsoft
Internet Information Server 5.49%
WebSite
WebSTAR
Apache SSL
Purveyor
WebSitePro
Cateva dintre cele mai utilizate aplicatii client WEB sunt Internet Explorer, Netscape, Mozilla si Opera.
Am ales pentru exemplificare server-ul Web Apache, acesta fiind cel mai raspandit. Motivele posibile pentru aceasta raspandire larga sunt:
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.
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
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
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
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
Subsections
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.
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
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:
<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>
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
|
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 2667
Importanta: 
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved
