Soluţii - PC Magazine Romania, Ianuarie  2003

Motto:
"- Bunicule, de ce nu vine Amelia Earhart?
- Amelia? A zburat peste Noua Guinee, uitându-şi antena, uitând că ... A zburat Dincolo.
- Ce a uitat, bunicule? Ce e dincolo de Noua Guinee?
- Dincolo? Dincolo, fetiţa mea... a uitat că dincolo e, însorit... doar Pacificul..."
Dintr-un film

Carnaval la Rio

Răzvan Sandu

Hei, fetelor, unde vă grăbiţi aşa? Şi de ce v-aţi îmbrăcat în rochii din paiete strălucitoare? Da, sigur, în episodul de azi e vorba despre Samba, dar nu despre măiestria dansatorilor din Brazilia, ci despre reţelele Microsoft, despre protocolul Session Message Block (SMB) folosit de ele şi despre ciudăţeniile care se întâmplă când o companie oarecare încearcă să reinventeze "roţile" internetului ...

Vremuri străvechi
Pe când se potcovea puricele cu nouăzecişinouă de ocale, iar noii dinozauri Windows 95 - abia născuţi din negura lui Windows 3.11 for Workgroups - începuseră să ne albăstrească ecranele, mulţi dintre noi, bieţii utilizatori din birouri, făceam cunoştinţă cu ceea ce înseamnă o reţea locală. Era acolo, pe desktop, un shortcut numit Network Neighborhood. Mai întâi, dădeam un click pe el şi aflam - după multe derulări de wizard-uri - că e o cale către nicăieri, fiindcă nici măcar nu aveam o placă Ethernet. Apoi, prin bunăvoinţa şefului, multdoritul adaptor îşi făcea apariţia. Ajutaţi de vreun coleg mai priceput, două-trei click-uri şi gata, învăţam să schimbăm fişiere cu cei de la etajul de deasupra, să tipărim ceva la imprimanta din biroul vecin... Urma dezamăgirea: nu puteam trimite e-mail-uri colegei de vis-ŕ-vis, LAN-ul nu ne permitea să folosim şi noi, pe ascuns, conexiunea internet dial-up din biroul şefului... Dar totuşi "Ai auzit, dragă, că ne-au instalat reţea la servici ?"

Pentru mulţi, simpaticele foldere galbene ale Windows-ului înseamnă un mister şi astăzi. Pentru alţii, au devenit ceva cotidian, dar nimeni nu-şi bate capul cu adrese IP, DNS-uri şi glume de-ale ăstora de la Tehnic ...

Şi totuşi ...
Şi totuşi reţeaua mondială de calculatoare, internetul, apăruse în germene încă din anii '70. Calculatoarele comunicau şi atunci, iar maşinile Unix din care s-a format mai apoi "coloana vertebrală" a Net-ului "ştiau" lucruri pe care PC-urile Windows nu le ştiu nici astăzi. Prin filme, prin instituţiile mari, vedem încă antice monitoare alb-negru pe care informaţia - prezentată în mod text, dar utilă - pare să răsară ca printr-o minune ... Cum aşa? Lumea TI nu începe de la Redmond?

Geamuri 95
Universul PC-urilor a crescut repede de la computerul singular de acasă la reţele locale şi, mai apoi, la internet. În cursul acestei evoluţii, Microsoft s-a găsit în faţa unei dileme. Pe de o parte, existau protocoalele vechilor reţele, stabile şi bine cunoscute. Pe de alta, trebuia găsit "ceva" care să permită unui utilizator oricât de netehnic să folosească o reţea de calculatoare. Începând cu Windows for Workgroups, compania americană a demarat dezvoltarea unui pachet de protocoale de nivel superior, proprietar, destinat interconectării computerelor din birouri. Acesta s-a numit întâi Session Message Block (SMB), mai apoi CIFS, iar "faţa sa vizibilă" este icon-ul Network Neigborhood de pe desktop-urile noastre.
De ce era nevoie de altă serie de protocoale? Nu ştiu. Poate că simplul TCP/IP folosit în internet nu era, pe atunci, la îndemâna "omului de pe stradă". Sau poate că Microsoft a dorit să izoleze utilizatorii de PC-uri de restul comunităţii TI, făcându-i prizonierii programelor sale. Abia odată cu Windows 2000, lucrurile s-au putut mişca în sensul adoptării pe reţelele locale a mecanismelor folosite în internet. Spre exemplu, numele unui computer nu mai este acum simplu (COMPUTER), ci s-a introdus structura ierarhică de domenii (computer.firma.com). Ca urmare, rezolvarea numelor nu se mai face prin ciudatele servere WINS (Windows Internet Naming Service), ci prin Domain Name Service (DNS), care este standardizat.

Mai nou, conflictul între open şi proprietary pare a se fi mutat pe un alt teren. Cu Windows XP, Microsoft ne impune noul Microsoft Passport, care joacă rolul de "buletin de identitate" electronic al unei persoane. În acest timp, o alianţă largă, Liberty Alliance, în frunte cu Sun Microsystems, încearcă să ne scutească de obligaţia oricărui bun "cetăţean al planetei" de a ne stoca toate informaţiile personale la Microsoft. Nu ştiu de ce, dar aş prefera să-mi pot cumpăra o maşină de spălat, folosind un credit-card, fără ştirea lor ...
Închid paranteza.

Brazilieni, australieni şi care alegorice ...
Prăpastia apărută între reţelele de PC-uri şi ... toţi ceilalţi trebuia umplută cumva. La nivelul reţea, Microsoft a adoptat, odată cu Windows 95, TCP/IP-ul. Dar pentru partajarea fişierelor şi imprimantelor între o maşină Windows şi una Unix, ca şi pentru realizarea autentificării prin nume şi parolă, mai trebuia scris un program. Acesta este Samba, rezultat al eforturilor echipei de programatori australieni grupaţi în jurul proiectului cu acelaşi nume (http://www.samba.org)
La urma urmei, ce face Samba? Iată:

• permite PC-urilor dintr-o reţea Microsoft să "vadă" o maşină Unix ca şi cum ar fi o maşină Windows "obişnuită", adică să listeze şi să folosească folderele şi imprimantele care sunt partajate (shared) pe aceasta;
  
• reciproc, permite maşinii Unix să "vadă" maşinile Windows;
  
• permite maşinii Unix să devină membră a unui domeniu controlat de un server Windows 2000 sau Windows NT sau a unui grup de lucru;
  
• dacă se doreşte, maşina Unix poate prelua funcţiile serverului Windows 2000 sau NT, realizand autentificarea clienţilor Windows prin nume de utilizator şi parolă;
  
• se pot defini exact drepturile pe care fiecare utilizator al reţelei le are asupra folderelor şi imprimantelor oferite de (partajate pe) maşina Unix;
  
• cu ajutorul daemon-ului winbindd, serverul Unix poate importa ("citi") baza de date cu utilizatori de pe un alt computer Windows 2000 sau NT prezent în reţea;
  
• în fine, prin intermediul Samba se pot "regla fin" toate detaliile de comunicare între aceste două tipuri de maşini atât de diferite.

Din experienţa personală vă pot povesti că un server Linux cu Samba bine configurată este un sistem de o extraordinară robusteţe - practic, utilizatorii Dvs. nici nu vor şti vreodată că serverul de pe care îşi iau datele este o maşină Unix şi nu una Windows.

Grozav ! Vreau Şi eu !
Dacă v-aţi hotărat să încercaţi, Samba se găseşte în aproape orice distribuţie de Linux. În distribuţia Red Hat, pe care o folosesc eu, pachetele .rpm pe care trebuie să le instalaţi sunt samba, samba-client şi samba-swat.

Documentaţia Samba este deosebit de "stufoasă" şi necesită o lectură integrală, atentă. Frustrarea unui utilizator neglijent poate fi foarte mare, pentru că, oricum, veţi petrece aproape o săptămână cu lectura şi apoi încă una cu implementarea şi cu testarea. Piesele de documentaţie sunt diversele fişiere ce se găsesc în /usr/share/doc/samba, fişierele de configurare din directorul /etc/samba şi paginile man ale componentelor (man smb.conf, man smbd, man nmbd, man lmhosts, man winbindd). Din punct de vedere al programelor propriu-zise, pachetul Samba instalează trei daemoni, care, dacă se doreşte, pot rula implicit la pornirea sistemului: smbd, nmbd şi winbindd. Primul este programul Samba propriu-zis, iar nmbd şi winbindd se ocupă, respectiv, de rezolvarea numelor în stil Microsoft şi de citirea bazelor de date cu utilizatori de la alte servere NT din reţea. Componenta swat este o interfaţă Web comodă pentru configurarea Samba, pe care o puteţi accesa la adresa IP a maşinii, pe portul 901.

Descrierea detaliată a utilizării parametrilor din /etc/smb.conf depăşeşte, din păcate, ca volum, spaţiul disponibil aici. Voi încerca, totuşi, să enumăr măcar parametrii relevanţi pentru funcţionarea sistemului, în scopul de a vă uşura studiul.
Deci, cum începem? Dacă aveţi distribuţia Red Hat, vă recomand ca, înainte de toate, să tipăriţi la imprimantă o copie a fişierului text de configurare /etc/samba/smb.conf, în varianta implicită dată de autorii distribuţiei. Apoi, aveţi nevoie neapărat de o copie tipărită a paginii manual a Samba, adică a fişierului /usr/share/man/man5/ smb.conf.5.gz, care conţine descrierea fiecăruia dintre zecile de parametri ce comandă acest program. În fine, pentru lămurirea unor aspecte punctuale - în special cele legate de autentificarea utilizatorilor - vă sugerez să parcurgeţi măcar câteva dintre fişierele din directorul cu documentaţie, anume /usr/ share/doc/samba. Şi, bineinţeles, să vizitaţi http://www.samba.org/ <../../>

"Două fire, două paie ..."
Pentru a înţelege funcţionarea Samba, trebuie, mai întâi, să ne imaginăm cum funcţionează o reţea Microsoft (în generaţia Windows 95/Windows 98)

Într-o asemenea reţea, fiecare calculator este identificat printr-un nume simplu, neierarhic, cum ar fi STATIA1. Acesta este numele pe care îl asignaţi calculatorului Dvs. la instalarea Windows, în Control Panel -> System -> Identification. Tot aici vi se cere ca maşina Dvs. să facă parte dintr-o structură cum ar fi:

• un grup de lucru (workgroup). Acesta înseamnă, pur şi simplu, o mulţime de calculatoare Windows ierarhic egale (peers) care partajează informaţii - de exemplu într-un birou;
  
• un domeniu (domain). Domeniul extinde noţiunea de workgroup adăugându-i un server Windows 2000 Server sau Windows NT însărcinat să păstreze centralizat baza de date cu numele şi parolele utilizatorilor şi alte informaţii despre maşinile-client aflate sub autoritatea sa.

De asemenea, fiecare maşină din reţea are nevoie de propria sa adresă IP, pentru a putea comunica cu celelalte. În cazul cel mai frecvent, această adresă nu este stabilită de utilizator la instalarea Windows - cei mai mulţi utilizatori neprofesionişti nici nu ştiu despre ce vorbesc eu acum ;-) - ci se atribuie dinamic maşinii, în momentul pornirii, printr-un mecanism tip DHCP.

Ce se întâmplă, de fapt? În momentul pornirii calculatoarelor din reţea, fiecare îşi "strigă" propriul nume, folosind adresa IP de broadcast şi anunţându-şi astfel prezenţa. Între staţii are loc un proces de "vot", prin care una - şi numai una - este aleasă drept Local Master Browser (LMB). În această calitate, staţia LMB va primi şi păstra o copie a informaţiilor despre folderele şi imprimantele oferite spre partajare de toate celelalte staţii - acea "listă" de foldere galbene pe care utilizatorul o vede dând un click pe icon-ul Network Neighborhood.

În cazul unei reţele complexe, în care segmentele sunt separate prin routere, procesul de "anunţare publică" (broadcast) şi alegere a LMB are loc pe fiecare segment de reţea în parte. Asta deoarece broadcast-urile nu se propagă "prin" router, în segmentele învecinate. Pentru a unifica lista de partajări din întreaga reţea, sunt necesari încă doi "pioni". Primul este un Domain Master Browser (DMB), computer însărcinat cu "însumarea" listelor de partajări primite de la fiecare LMB în parte (de menţionat că maşina desemnată ca Domain Master Browser este, de obicei, şi Local Master Browser-ul pentru propriul segment local de reţea). Al doilea este serverul WINS (Windows Internet Name Server), care realizează conversii între adresele IP ale staţiilor şi numele lor (şi reciproc), analog cu DNS.

Deci, ce trebuie să facă un LMB în momentul în care a fost desemnat în această funcţie pe propriul segment de reţea? El va trebui să găsească DMB-ul, pentru a sincroniza lista sa de partajări cu cea a întregii reţele. Cum DMB poate să fie situat pe un alt segment de reţea, acesta nu va fi accesibil în mod direct. Pentru a-l găsi, LMB va trebui să "întrebe" serverul WINS, care îi va furniza adresa IP a DMB-ului. Dar de unde o cunoaşte WINS pe aceasta din urmă? Chiar DMB i-a comunicat-o, în momentul bootării.

Complicat, nu? Nu era mai drăguţ, mai uman, serviciul DNS pe care l-am descris într-o conversaţie anterioară? Ba daaaaaaaaa...

În urma sincronizării între un LMB oarecare şi DMB-ul întregii reţele, primul ajunge să cunoască întreaga listă de partajări pe care o are la dispoziţie Domain Master Browser-ul în acel moment.

Trebuie adăugat că fiecare calculator din reţea trebuie să cunoască aprioric adresa IP a serverului WINS, analog cu modul în care este necesar ca Dvs. să introduceţi manual adresele serverelor DNS în caseta Properties a TCP/IP-ului. Pe o reţea în care utilizatorii nu fac asta, puteţi spera măcar că aceşti parametri se transmit, la bootare, printr-un mecanism DHCP.
Dacă tot acest proces vi se pare destul de complicat, aveţi dreptate. Nu numai că este complex, dar volumul mare de broadcast-uri generează o încărcare mare a reţelei, diminuând lăţimea de bandă disponibilă efectiv pentru transferul datelor utile. În plus, dacă una dintre legături nu funcţionează - să zicem, unul dintre routerele amplasate între două segmente de reţea "cade" - actualizarea listelor se face încet. În Network Neighborhood veţi continua să vedeţi partajările de "dincolo" de routerul defect, care, în realitate, nu mai sunt accesibile, pentru încă aproximativ o jumătate de oră. Dacă daţi un click pe un asemenea folder, încercând să-l deschideţi, aveţi toate şansele să vă blocaţi computerul.

Fenomene la fel de ciudate se întâmplă şi în cazul în care, dintr-un motiv sau altul, serverul WINS nu mai este disponibil - de exemplu, secretara care lucra pe el l-a închis şi a plecat acasă ;-) Lucrurile se petrec cam ca în cazul în care clienţii rămân izolaţi faţă de serverul lor DNS - nu va mai funcţiona aproape nimic. Dacă ţineţi seama şi de faptul că, într-un birou, staţiile se închid şi se deschid în mod aleator, veţi înţelege cât de mare este traficul generat de acest proces, repetat periodic, de căutare, de broadcasting, de alegere a LMB-urilor ...

Ritmuri latino
Dacă aţi înţeles procesul de mai sus, vă întrebaţi, desigur, cu ce vă poate fi de folos maşina Dvs. Linux în acest mediu Microsoft-only. Iată, am să vă dau nişte veşti bune ...

Mai întâi, vom începe cu setările elementare. În fişierul /etc/samba/smb. conf, stabiliţi numele NETBIOS pe care îl va purta computerul Dvs, grupul de lucru din care face parte şi un mic comentariu care vă va ajuta să-l identificaţi:

netbios name = COMPUTERULMEU
workgroup = FIRMA
server string = Computerul de la parter
interfaces = 192.168.0.1
Apoi, Linux poate prelua funcţia serverului WINS. Este suficient să editaţi fişierul /etc/samba/lmhosts şi să adăugaţi acolo linii forma:

192.168.0.1 COMPUTER1
192.168.0.2 COMPUTER2

prin care veţi stabili asocieri între adresele IP şi numele NETBIOS ale staţiilor din reţea. Vă sfătuiesc să utilizaţi capacităţile WINS ale Samba numai dacă nu există un server Windows NT sau 2000 care să îndeplinească această funcţie. În plus, o singură maşină Samba trebuie să fie configurată ca server WINS. Ideal, în reţeaua Dvs. ar trebui să existe mai multe servere WINS, situate pe segmente diferite, care să îşi împartă sarcinile de a răspunde clienţilor şi să îşi diminueze reciproc încărcarea (un mecanism de redundanţă şi de load-balancing). Desigur, toate serverele prezente trebuie să conţină aceeaşi bază de date lmhosts, pe care trebuie să o poată sincroniza între ele. Din nefericire, spre deosebire de serverele WINS de la Microsoft, Samba nu ştie încă să participe la un asemenea mecanism de replicare. Şi asta numai datorită faptului că Microsoft refuză să ofere chiar şi cel mai mic detaliu despre protocolul prin care se execută sincronizarea. Aşa că, momentan, nu aveţi decât două altenative: să configuraţi un singur server WINS Samba sau să vă bazaţi pe capacităţile serverelor native existente în reţea. Calitatea de server sau de client WINS poate fi stabilită cu ajutorul parametrilor:

wins server = 192.168.0.3
(indică adresa IP a serverului WINS, deci maşina Samba este client)
wins support = yes/no

(stabileşte dacă maşina Samba este ea însăşi server)
Computerul poate îndeplini rolul de server sau cel de client, dar nu simultan. Ordinea în care se încearcă utilizarea diverselor mecanisme de rezolvare a numelor este dată de parametrul name resolve order =.
Mai departe, Samba poate prelua rolul de Local Master Browser sau cel de Domain Master Browser. Parametrii booleeni din /etc/smb.conf:

domain master =
local master =
controlează acest lucru, împreună cu opţiunile:
preferred master =
os level =

Trebuie să acordaţi atenţie prezenţei altor servere Microsoft în reţea. Nu trebuie să uitaţi că procesul de selecţie al browserelor se repetă periodic - o "luptă" prea îndârjită între două servere care îşi dispută acest rol poate încetini sau bloca întreaga reţea. Desigur, nu trebuie să existe mai mult de un LMB pentru fiecare segment de reţea sau mai mult de un DMB. Cu ajutorul programului-client smbclient puteţi verifica cum sunt asignate aceste roluri. Comanda:

smbclient -L \\COMPUTERULMEU

va afişa lista partajărilor oferite de COMPUTERULMEU, numele workgroup-ului din care acesta face parte şi pe acela al LMB-ului care controlează întregul workgroup. Parametrul os level = stabileşte nivelul priorităţii de care se va bucura Samba în elecţia pentru LMB.

Odată ajunşi în această fază, vă recomand să citiţi documentul /usr/doc /samba/DIAGNOSIS.txt şi să parcurgeţi minuţios paşii de verificare sugeraţi acolo.

Halt ! Papiere ... ?!
Nu în ultimul rând, serverul Linux poate îndeplini funcţia santinelei germane care păzeşte bariera: autentificarea celor ce se loghează de la staţiile Windows ;-)

Principala diferenţă între un workgroup şi un domeniu Windows NT este aceea că, în timp ce fiecare maşină dintr-un grup de lucru are propria sa bază de date cu utilizatori, într-un domeniu baza de date există pe server (Primary Domain Controller - PDC) şi este "consultată" de toate maşinile, în momentul logării. Pentru redundanţă, pot exista alte servere NT, Backup Domain Controllers (BDC), care preiau încărcarea sau înlocuiesc PDC când acesta nu este disponibil.
Într-un mediu mixt, Windows/Linux, Samba poate juca rolul de PDC, dacă nu există un server Microsoft. Din aceleaşi motive de proprietarism arătate înainte, Linux nu poate participa la sincronizarea bazelor de date cu utilizatori, adică nu poate lucra (deocamdată) ca BDC.

Autentificarea utilizatorilor se poate face direct sau prin intermediul unui server NT/2000 auxiliar. Puteţi controla aceste aspecte folosind următorii parametri din /etc/smb.conf:

security = (vă recomand security=user sau security=domain)
domain master =
local master =
domain logons =
password server =
encrypted passwords =
logon drive =
logon path =
logon script =
username map =

Înainte de a începe să lucraţi într-un asemenea mediu mixt, asiguraţi-vă că aţi instalat ultimele Service Pack-uri pe serverele Dvs. Windows 2000 sau NT. Altfel, vă veţi confrunta cu probleme de interoperabilitate care nu au de a face, propriu-zis, cu Samba.

În cazul în care utilizatorii Dvs. poartă nume diferite pe maşina Unix şi pe staţiile Windows, puteţi stabili corespondenţele folosind fişierul /etc /samba/smbusers. Liniile din acest fişier sunt de forma:

nume_unix = nume_windows1 nume_windows2 nume_windows3 ...

Pentru folosirea bazei de date a unui server NT/2000 în scopul autentificării utilizatorilor, trebuie să folosiţi programul daemon winbindd, care realizează această funcţie. Utilitarul auxiliar wbinfo vă permite să verificaţi ce nume de utilizator sunt definite şi "exportate" în domeniul Dvs. - paginile manual ale celor două programe vă vor fi de folos.

După serbare
Sunt sigur că punerea la punct a unei reţele bazate pe Samba, cu particularităţile dorite de Dvs., vă va lua un timp mai lung decât în cazul altor programe. Şefii nu trebuie, însă, să devină nerăbdători - bine configurat, Samba este unul dintre programele care vă va scuti de foarte multe probleme în reţeaua firmei şi va economisi taxele de licenţă consistente pentru un Windows 2000 Server sau Advanced Server.

De mare ajutor vă poate fi şi cartea apărută în traducere, în româneşte: Carter, G.; Sharpe, R. - "Samba". Dacă sunteţi programator, puteţi încerca să contribuiţi şi Dvs. la dezvoltarea suitei Samba cu câteva secvenţe de cod. Dacă nu, situl www.samba.org vă oferă indicaţii detaliate despre cum puteţi menţine buna dispoziţie şi cheful de muncă ale lui Andrew Tridgell şi ale echipei sale, trimiţând o pizza pe adresa lor din Australia.

Cât despre mine, vă stau la dispoziţie, ca de obicei, pe http://www.linuxwill.go.ro