NFS: Sistem de fișiere de rețea. Configurarea și montarea NFS

12.08.2019 Siguranță

NFS: un sistem de fișiere de rețea convenabil și promițător

Sistem de fișiere în rețea este o abstractizare a rețelei peste un sistem de fișiere obișnuit care permite unui client la distanță să îl acceseze prin rețea în același mod ca atunci când accesează sistemele de fișiere locale. Deși NFS nu a fost primul sistem de fișiere de rețea, a evoluat pentru a deveni cel mai capabil și popular sistem de fișiere de rețea din UNIX® astăzi. NFS permite mai multor utilizatori să partajeze un sistem de fișiere comun și centralizează datele pentru a minimiza spațiul pe disc necesar pentru stocarea acestora.

Acest articol începe cu o scurtă prezentare a istoriei NFS și apoi trece la explorarea arhitecturii NFS și a modului în care ar putea evolua în viitor.

O scurtă istorie a NFS

Primul sistem de fișiere de rețea a fost numit FAL (File Access Listener) și a fost dezvoltat în 1976 de către DEC (Digital Equipment Corporation). Era o implementare a protocolului DAP (Data Access Protocol) și făcea parte din suita de protocoale DECnet. Ca și în cazul TCP/IP, DEC a publicat specificații pentru protocoalele sale de rețea, inclusiv protocolul DAP.

NFS a fost primul sistem modern de fișiere de rețea construit pe baza protocolului IP. Prototipul său poate fi considerat un sistem de fișiere experimental dezvoltat la Sun Microsystems la începutul anilor 80. Având în vedere popularitatea acestei soluții, protocolul NFS a fost introdus ca specificație RFC și a evoluat ulterior în NFSv2. NFS sa impus rapid ca standard datorită capacității sale de a interopera cu alți clienți și servere.

Standardul a fost ulterior actualizat la NFSv3, definit în RFC 1813. Această versiune a protocolului a fost mai scalabilă decât versiunile anterioare și a acceptat fișiere de dimensiuni mai mari (mai mari de 2 GB), scriere asincronă și TCP ca protocol de transport. NFSv3 a stabilit direcția pentru dezvoltarea sistemelor de fișiere pentru rețelele WAN. În 2000, RFC 3010 (revizuit ca RFC 3530) a adus NFS în mediul întreprinderii. Sun a introdus un NFSv4 mai sigur cu suport stateful (versiunile anterioare de NFS nu acceptau stocarea stateful, adică erau clasificate ca apatride). În prezent, cea mai recentă versiune a NFS este versiunea 4.1, definită în RFC 5661, care se adaugă la protocol prin extinderea pNFS a fost adăugat suport pentru acces paralel pentru serverele distribuite.

Istoricul NFS, inclusiv RFC-uri specifice care descriu versiunile sale, este prezentat în Figura 1.

În mod surprinzător, NFS a fost în dezvoltare de aproape 30 de ani. Este un sistem de fișiere de rețea extrem de stabil și portabil, cu caracteristici remarcabile de scalabilitate, performanță și calitate a serviciilor. Pe măsură ce vitezele cresc și latența scade la schimbul de date într-o rețea, NFS continuă să fie o modalitate populară de a implementa un sistem de fișiere într-o rețea. Chiar și în cazul rețelelor locale, virtualizarea încurajează stocarea datelor în rețea pentru a oferi mobilitate suplimentară mașinilor virtuale. NFS acceptă, de asemenea, cele mai recente modele de mediu de calcul care vizează optimizarea infrastructurilor virtuale.

Arhitectura NFS

NFS folosește un model arhitectural standard client-server (așa cum se arată în Figura 2). Serverul este responsabil pentru implementarea sistemului de fișiere partajat și stocarea la care se conectează clienții. Clientul implementează o interfață cu utilizatorul într-un sistem de fișiere partajat montat în spațiul de fișiere local al clientului.

Figura 2. Implementarea modelului client-server în arhitectura NFS

În Linux®, un comutator de sistem de fișiere virtual (VFS) oferă mijloacele de a accepta mai multe sisteme de fișiere (de exemplu, un sistem de fișiere ISO 9660 pe un CD-ROM și un sistem de fișiere ext3fs pe un hard disk local) simultan pe o singură gazdă . Comutatorul virtual determină la ce unitate se face cererea și, prin urmare, ce sistem de fișiere trebuie utilizat pentru a procesa cererea. Prin urmare, NFS are aceeași compatibilitate ca și alte sisteme de fișiere utilizate în Linux. Singura diferență cu NFS este că, în loc să fie procesate local pe gazdă, cererile I/O pot fi trimise în rețea pentru execuție.

VFS determină că cererea primită este NFS și o transmite handlerului NFS situat în kernel. Hander-ul NFS procesează cererea I/O și o traduce într-o procedură NFS (OPEN, ACCESS, CREATE, READ, CLOSE, REMOVE etc.). Aceste proceduri, descrise într-o specificație RFC separată, definesc comportamentul protocolului NFS. Procedura necesară este selectată în funcție de solicitare și este executată folosind tehnologia RPC (apel de procedură la distanță). După cum sugerează și numele, RPC permite efectuarea apelurilor de procedură între diferite sisteme. Serviciul RPC concatenează o solicitare NFS cu argumentele sale și trimite rezultatul gazdei la distanță corespunzătoare, apoi monitorizează primirea și procesarea răspunsului pentru a-l returna solicitantului.

RPC include, de asemenea, un strat XDR important ( reprezentarea datelor externe- reprezentarea independentă a datelor), asigurându-se că toți utilizatorii NFS utilizează același format pentru aceleași tipuri de date. Când o platformă trimite o solicitare, tipul de date pe care îl folosește poate fi diferit de tipul de date utilizat pe gazda care procesează cererea. Tehnologia XDR se ocupă de munca de conversie a tipurilor într-o reprezentare standard (XDR), astfel încât platformele care utilizează arhitecturi diferite să poată interopera și partaja sisteme de fișiere. XDR definește formatul de biți pentru tipuri precum float și ordinea octeților pentru tipuri precum matricele cu lungime constantă și variabilă. Deși XDR este cunoscut în primul rând pentru utilizarea sa în NFS, această specificație poate fi utilă în toate cazurile în care trebuie să lucrați în același mediu cu arhitecturi diferite.

După ce XDR a tradus datele într-o reprezentare standard, cererea este transmisă prin rețea folosind un protocol de transport specific. Implementările timpurii ale NFS foloseau UDP, dar astăzi TCP este folosit pentru o mai mare fiabilitate.

Un algoritm similar este utilizat pe partea serverului NFS. Solicitarea parcurge stiva de rețea prin stratul RPC/XDR (pentru a converti tipurile de date în funcție de arhitectura serverului) și în serverul NFS, care este responsabil de procesarea cererii. Acolo, cererea este transmisă demonului NFS pentru a determina sistemul de fișiere țintă căruia îi este adresată și apoi merge din nou la VFS pentru a accesa acel sistem de fișiere pe discul local. O diagramă completă a acestui proces este prezentată în Figura 3. În acest caz, sistemul de fișiere local al serverului este un sistem de fișiere Linux standard, de exemplu, ext4fs. În esență, NFS nu este un sistem de fișiere în sensul tradițional al termenului, ci un protocol pentru accesul de la distanță la sistemele de fișiere.

Pentru rețelele cu latență lungă, NFSv4 oferă o procedură compusă specială ( procedeu compus). Această procedură vă permite să plasați mai multe apeluri RPC într-o singură cerere pentru a minimiza costul trimiterii cererilor prin rețea. Această procedură implementează, de asemenea, un mecanism de funcție de apel invers pentru primirea răspunsurilor.

Protocolul NFS

Când un client începe să folosească NFS, prima acțiune este să efectueze o operație de montare, care este să monteze sistemul de fișiere la distanță în spațiul local al sistemului de fișiere. Acest proces începe cu un apel la procedura de montare (una dintre funcțiile sistemului Linux), care este redirecționată prin VFS către componenta NFS. Apoi, un apel RPC la funcția get_port de pe serverul la distanță determină numărul portului care va fi utilizat pentru montare, iar clientul trimite o cerere de montare prin RPC. Această solicitare pe partea serverului este procesată de un demon special rpc.mountd, care este responsabil pentru protocolul de montare ( protocol de montare). Daemonul verifică dacă sistemul de fișiere solicitat de client se află în lista de sisteme disponibile pe serverul dat. Dacă sistemul solicitat există și clientul are acces la el, răspunsul RPC de montare specifică un descriptor de sistem de fișiere. Clientul reține informații despre punctele de montare locale și la distanță și este capabil să facă cereri I/O. Protocolul de montare nu este sigur din punct de vedere al securității, așa că NFSv4 utilizează în schimb apeluri interne RPC, care pot gestiona și punctele de montare.

Pentru a citi un fișier, trebuie mai întâi să îl deschideți. În schimb, nu există o procedură OPEN în RPC, clientul pur și simplu verifică dacă fișierul și directorul specificat există pe sistemul de fișiere montat. Clientul începe prin a face o solicitare GETATTR RPC către director, care returnează atributele directorului sau un indicator că directorul nu există. Apoi, pentru a verifica prezența fișierului, clientul emite o solicitare LOOKUP RPC. Dacă fișierul există, se face o solicitare GETATTR RPC asupra acestuia pentru a afla atributele fișierului. Folosind informațiile obținute din apelurile de succes LOOKUP și GETATTR, clientul creează un handle de fișier care este furnizat utilizatorului pentru cereri viitoare.

Odată ce fișierul a fost identificat pe sistemul de fișiere la distanță, clientul poate emite solicitări RPC READ. Această solicitare constă dintr-un descriptor de fișier, o stare, un offset și numărul de octeți de citit. Clientul folosește starea ( stat) pentru a determina dacă operația poate fi efectuată în momentul de față, adică. Fișierul este blocat? Decalaj ( decalaj) indică în ce poziție să începeți citirea și contorul de octeți ( numara) determină câți octeți trebuie citiți. Ca urmare a apelului READ RPC, serverul nu returnează întotdeauna atât de mulți octeți cât au fost solicitați, dar împreună cu datele returnate raportează întotdeauna câți octeți au fost trimiși către client.

Inovație în NFS

Cele mai recente două versiuni de NFS sunt de cel mai mare interes - 4 și 4.1, ca exemple din care puteți studia cele mai importante aspecte ale evoluției tehnologiei NFS.

Înainte ca NFSv4 să fie disponibil pentru a efectua sarcini de gestionare a fișierelor, cum ar fi montarea, blocarea etc. existau protocoale suplimentare speciale. În NFSv4, procesul de gestionare a fișierelor a fost simplificat la un singur protocol; În plus, începând cu această versiune, UDP nu mai este folosit ca protocol de transport. NFSv4 include suport pentru semantica de acces la fișiere UNIX și Windows®, permițând NFS să se integreze în mod natural în alte sisteme de operare.

NFSv4.1 a introdus conceptul de NFS paralel(NFS paralel - pNFS). Pentru a oferi niveluri mai mari de scalabilitate, NFSv4.1 implementează o arhitectură în care datele și metadatele ( marcare) sunt distribuite pe dispozitive într-un mod similar cu modul în care se face în sistemele de fișiere în cluster. După cum se arată în , pNFS împarte ecosistemul în trei componente: client, server și stocare. În acest caz, apar două canale: unul pentru transmiterea datelor, iar celălalt pentru transmiterea comenzilor de control. pNFS separă datele de metadatele care le descriu, oferind o arhitectură cu două canale. Când un client dorește să acceseze un fișier, serverul îi trimite metadate cu „markup”. Metadatele conțin informații despre locația fișierului pe dispozitivele de stocare. Odată ce clientul are aceste informații, poate accesa stocarea direct, fără a fi nevoit să interacționeze cu serverul, îmbunătățind scalabilitatea și performanța. Când clientul termină de lucru cu fișierul, acesta confirmă modificările aduse fișierului și „markupul” acestuia. Dacă este necesar, serverul poate solicita metadate cu marcaj de la client.

Odată cu apariția pNFS, mai multe operațiuni noi au fost adăugate la protocolul NFS pentru a sprijini un astfel de mecanism. Metoda LayoutGet este folosită pentru a prelua metadatele de pe server, metoda LayoutReturn „eliberează” metadatele „capturate” de client, iar metoda LayoutCommit încarcă „aspectul” primit de la client în stocare, astfel încât să fie disponibil pentru alți utilizatori . Serverul poate rechema metadatele de la client folosind metoda LayoutRecall. Metadatele „etichetate” sunt distribuite pe mai multe dispozitive de stocare pentru a oferi acces paralel și performanță ridicată.

Datele și metadatele sunt stocate pe dispozitive de stocare. Clienții pot efectua solicitări I/O directe pe baza markupului primit, iar serverul NFSv4.1 stochează și gestionează metadatele. Această funcționalitate în sine nu este nouă, dar pNFS a adăugat suport pentru diferite metode de accesare a dispozitivelor de stocare. Astăzi, pNFS acceptă utilizarea protocoalelor bloc (Fibre Channel), a protocoalelor obiect și a NFS în sine (nici măcar în formă pNFS).

Dezvoltarea NFS continuă, iar în septembrie 2010 au fost publicate cerințele pentru NFSv4.2. Unele dintre inovații sunt legate de migrarea continuă a tehnologiilor de stocare a datelor către virtualizare. De exemplu, în mediile virtuale cu un hypervisor, este foarte probabil să apară duplicarea datelor (mai multe sisteme de operare care citesc/scriu și memorează în cache aceleași date). Din această cauză, este de dorit ca sistemul de stocare în ansamblu să înțeleagă unde are loc duplicarea. Această abordare va ajuta la economisirea spațiului cache al clientului și a capacității generale de stocare. NFSv4.2 propune utilizarea unei „hărți de blocuri a blocurilor partajate” pentru a rezolva această problemă. Pe măsură ce sistemele moderne de stocare sunt din ce în ce mai echipate cu propria lor putere de calcul internă, este introdusă copierea pe server pentru a reduce sarcina copierii datelor într-o rețea internă, atunci când aceasta poate fi realizată eficient pe dispozitivul de stocare în sine. Alte inovații includ stocarea în cache a sub-fișierului pentru memoria flash și recomandări de reglare I/O la nivelul clientului (cum ar fi utilizarea mapadvise).

Alternative NFS

Deși NFS este cel mai popular sistem de fișiere de rețea în UNIX și Linux, există și alte sisteme de fișiere de rețea. Pe platforma Windows®, SMB este cel mai frecvent utilizat, cunoscut și ca CIFS; cu toate acestea, sistemul de operare Windows acceptă și NFS, precum și Linux acceptă SMB.

Unul dintre cele mai noi sisteme de fișiere distribuite acceptate pe Linux, Ceph, este proiectat de la zero pentru a fi un sistem de fișiere compatibil POSIX tolerant la erori. Mai multe informații despre Ceph pot fi găsite în secțiunea.

De asemenea, merită menționate sistemele de fișiere OpenAFS (versiunea Open Source a sistemului de fișiere distribuit Andrew, dezvoltată la Carnegie Mellon University și IBM Corporation), GlusterFS (un sistem de fișiere distribuit de uz general pentru organizarea stocării de date scalabile) și Luster (un sistem masiv de fișiere distribuite). sistem de fișiere de rețea paralelă pentru soluții de cluster). Toate aceste sisteme open source pot fi folosite pentru a construi stocare distribuită.

Concluzie

Dezvoltarea sistemului de fișiere NFS continuă. Similar cu sistemul de operare Linux, care poate suporta atât soluții low-end, încorporate și high-end, NFS oferă o arhitectură pentru soluții de stocare scalabile potrivite atât pentru persoane fizice, cât și pentru organizații. Dacă te uiți la călătoria pe care a parcurs-o deja NFS și la perspectivele dezvoltării sale viitoare, devine clar că acest sistem de fișiere va continua să schimbe modul în care ne gândim la modul în care sunt implementate și utilizate tehnologiile de stocare a fișierelor.

Nu toată lumea este familiarizată cu protocoalele de transfer de date. Dar mulți ar dori să-și conecteze computerele într-o singură rețea sau să folosească un server pentru a stoca fișiere. O modalitate de a face acest lucru este NFS. Cum să configurați un server NFS în Ubuntu - citiți mai departe.

Prin configurarea corectă a NFS, puteți combina computere pe diferite sisteme de operare într-o singură rețea.

Network File System este un protocol de acces la fișiere de rețea. Ca de obicei, este format din două părți. Unul este cel client, care se află pe computerul de pe care sunt vizualizate datele de la distanță. Celălalt - serverul - se află pe computerul unde sunt stocate aceste date. Este destul de convenabil să utilizați spațiu suplimentar pe disc, în special într-o rețea locală. Și dacă vorbim despre unele PC-uri corporative, atunci acest lucru este pur și simplu necesar.

Care este diferența?

Astăzi există un număr mare de protocoale și o mare varietate de software care îndeplinesc aceleași funcții. Ce face ca NFS să iasă în evidență?

Posibilitatea de a conecta computere pe diferite sisteme de operare într-o singură rețea. Este adesea convenabil să conectați sistemul de operare Windows prin NFS la un sistem Unix, de exemplu, Ubuntu. Samba există și este folosit în aceleași scopuri, dar NFS este mai ușor, mai simplu și mai rapid decât acest program, deoarece este implementat la nivel de kernel. Prin urmare, configurarea accesului prin intermediul acestuia va fi de obicei mai ușoară.
NFS oferă acces transparent la fișiere. Aceasta înseamnă că toate fișierele de la distanță sunt redate exact la fel ca și cele locale. Programele nu trebuie să fie actualizate pentru a reda orice fișier aflat pe server.
NFS trimite doar porțiunea solicitată a fișierului, nu întregul fișier.

Pentru a funcționa pe deplin, Network File System trebuie să fie instalat pe cel puțin două computere: un server și un client. Desigur, un începător va trebui să lucreze cel mai mult la partea de server, deoarece aici este necesar să „partajeze” folderele (acces deschis). Totuși, toate acestea se fac destul de ușor.

Ca majoritatea protocoalelor de transfer de date, NFS nu este deloc tânăr. A fost dezvoltat în 1984 și a fost destinat sistemelor UNIX. Acesta este încă rolul principal al NFS, dar mulți au descoperit că este foarte convenabil să conectați computerele Windows la cele Linux. În plus, NFS este excelent pentru redarea conținutului multimedia într-o rețea locală de domiciliu. Samba în acest rol deseori îngheață și încetinește.

Instalarea backend-ului NFS

Vom instala partea de server a protocolului pe Ubuntu 16.04. Desigur, dacă aveți ediția Server, procesul nu este în niciun fel diferit. Doar că, în versiunea tradițională a Ubuntu, unele acțiuni pot fi efectuate folosind interfața grafică.

Instaleaza programul. Pentru a face acest lucru, puteți utiliza centrul de descărcare a aplicației sau puteți introduce pur și simplu comanda:

sudo apt install nfs-kernel-server

După aceasta, va fi util să verificați corectitudinea instalării. Nu este necesar să facem asta, dar vom verifica oricum. Introdu comanda:

Portul ar trebui să fie 2049 peste tot.

Acum verificăm dacă nucleul acceptă NFS. Pentru a face acest lucru, introduceți:

cat /proc/sisteme de fișiere | grep nfs
Valoarea rezultată ar trebui să arate astfel: nodev nfsd
Aceasta înseamnă că totul funcționează corect. Dacă nu, atunci introduceți comanda:
Folosind-o, instalăm singuri modulul kernel.
Adăugați protocolul la autorun. Nu este necesar să faci acest lucru, dar este foarte incomod să-l pornești de fiecare dată. Din nou, îl puteți adăuga folosind un element special de meniu din setări sau îl puteți adăuga singur folosind comanda:
sudo systemctl enable nfs

Deci, am instalat partea de server, tot ce rămâne este să o configuram corect și să trecem la partea client.
Setări
Configurarea NFS în Ubuntu implică partajarea anumitor foldere.
Pe lângă faptul că permiteți pur și simplu accesul, trebuie să specificați și parametrii care determină capabilitățile utilizatorului în raport cu acest folder.
rw - citire și scriere Această opțiune permite citirea și scrierea fișierelor din folder.
ro - doar citire - permite doar citirea folderului.
sync (implicit) - parametrul asigură fiabilitatea transmisiei. Dacă este activat, nu veți putea transfera mai multe fișiere în același timp sau pe computere diferite. Această setare vă va împiedica să răspundeți la alte solicitări. Previne pierderea datelor, dar transferul poate fi mai lent.
asincron este inversul parametrului anterior. Transferul este mai rapid, dar există riscul pierderii informațiilor.
securizat - această opțiune vă permite să utilizați numai porturi sub 1024. Activată implicit.
nesigur - permite utilizarea oricăror porturi.
nohide - dacă montați mai multe directoare, inclusiv cele imbricate, atunci directoarele imbricate, spre deosebire de directorul părinte, vor fi afișate ca goale. Parametrul va ajuta la remedierea acestui lucru
anonuid - specifică uid-ul pentru utilizatorii anonimi. Acesta este un ID de utilizator special.
anongid - specifică gid-ul pentru utilizatorii anonimi. GID (Group ID) - un alt identificator de utilizator.
no_subtree_check - funcția dezactivează controlul subtree. Faptul este că fără el, NFS verifică suplimentar dacă utilizatorii accesează numai secțiunile necesare ale directorului. Acest lucru încetinește lucrurile. Acest parametru accelerează, dar reduce securitatea.

Le vom folosi în funcție de ceea ce este necesar într-o anumită situație.
Să creăm un folder nou. Puteți folosi și unul nou. Dosarul nostru va fi /var/network.
Acum trebuie să adăugați acest folder în fișierul /etc/exports. Toate fișierele și folderele cu acces deschis la rețea sunt stocate acolo. Intrarea ar trebui să arate astfel:
/var/network168.1.1(rw,async,no_subtree_check)

192.168.1.1 este IP-ul prin care transmitem. Este obligatoriu să o indicați.
Actualizați tabelul de export:
Acum să încercăm să accesăm folderul din partea clientului.
Instalarea și configurarea părții client NFS
Ubuntu
Pe Ubuntu, conectarea unui server configurat nu este dificilă. Acest lucru se face în doar câteva comenzi.
Instalați un pachet client special:
sudo apt install nfs-common

sudo mount 192.168.1.1:/var/network/ /mnt/

Dosarul de rețea este conectat. Folosind df puteți verifica toate folderele de rețea conectate:
De asemenea, puteți verifica nivelul de acces cu o comandă specială:
Dezactivați sistemul de fișiere după cum urmează:
Comanda mount este folosită aproape peste tot. Este responsabil pentru procesul de montare, adică pregătirea spațiului pe hard disk pentru a fi utilizat de sistemul de operare. Sună complicat, dar dacă simplificăm, se dovedește că pur și simplu transferăm fișiere de rețea pe computerul nostru într-un folder nou creat. Aici se numește /mnt/.
Windows
Cu Windows, de regulă, totul este mult mai complicat. Clientul NFS poate fi rulat pe toate serverele Windows fără probleme. Dintre cele standard, este prezent pe:
Windows 7 Ultimate/Enterprise
Windows 8/8.1 Enterprise
Windows 10 Enterprise

Nu îl găsesc în altă parte. Dacă aveți una dintre aceste versiuni, faceți următoarele:
Deschideți meniul „Programe și caracteristici”.
Faceți clic pe „Adăugarea de componente”.
Găsim NFS acolo și instalăm doar „Client pentru NFS”; nu avem nevoie de altă componentă.

După conectare, totul este montat cu aceeași comandă:
montare 192.168.1.1:/var/network/ /mnt/

Îl puteți demonta după cum urmează:
Comenzile sunt introduse în linia de comandă lansată ca administrator. După aceasta, puteți găsi cu ușurință unitatea de rețea dorită folosind Explorer.
Ce să faci dacă nu există un client NFS pe computer? Puteți încerca să descărcați software-ul prin intermediul site-ului web Microsoft sau din resurse terță parte. Este posibil ca aici să fie necesare alte comenzi sau acțiuni.
Acum aveți o înțelegere de bază despre cum să utilizați NFC și să efectuați configurarea de bază. Aceste cunoștințe sunt suficiente pentru a stabili accesul de la un computer la altul. Mai mult, un PC Windows poate acționa și ca client.

Capitolul 29 NFS: Sistemul de fișiere în rețea

Introducere

În acest capitol, ne vom uita la Network File System (NFS), o aplicație populară care oferă aplicațiilor client acces transparent la fișiere. Piatra de temelie a NFS este Sun RPC: Remote Procedure Call, pe care o vom trata mai întâi.

Programul client nu necesită instrumente speciale pentru a profita de NFS. Nucleul detectează că fișierul se află pe un server NFS și generează automat un apel RPC pentru a accesa fișierul.

Nu ne vom uita în detaliu la modul în care este implementat accesul la fișiere, ci vom analiza modul în care sunt utilizate protocoalele de Internet, în special UDP.

Sun Remote Procedure Call

În cele mai multe cazuri, problemele de programare a rețelei sunt rezolvate prin scrierea unor programe de aplicație care apelează funcții furnizate de sistem pentru a efectua operațiuni specifice de rețea. De exemplu, o funcție realizează o deschidere TCP activă, alta deschidere TCP pasivă, o a treia trimite date printr-o conexiune TCP, a patra setează opțiuni specifice de protocol (activează cronometrul TCP „stay alive”) și așa mai departe. În secțiunea Interfețe de programare a aplicațiilor din Capitolul 1, am menționat că există două seturi populare de funcții de programare a rețelei (interfețe de programare a aplicațiilor, API-uri): socket-uri și TLI. API-ul folosit de client și API-ul utilizat de server pot diferi, la fel ca și sistemele de operare pe care le rulează clientul și serverul. Protocoalele de comunicare și de aplicație determină dacă un anumit client poate comunica cu serverul. Un client Unix scris în C folosind socket-uri ca interfață de programare și TCP ca protocol de comunicare poate comunica cu un server mainframe scris în COBOL folosind diferite API și TCP dacă ambele gazde sunt conectate la rețea și ambele au o implementare TCP.

De obicei, clientul trimite comenzi către server, iar serverul trimite răspunsuri către client. Toate aplicațiile pe care le-am analizat - Ping, Traceroute, demoni de rutare, clienți și servere DNS, TFTP, BOOTP, SNMP, Telnet, FTP, SMTP - sunt toate construite astfel.

RPC, apel de procedură la distanță, implementează o abordare diferită a programării rețelei. Programul client apelează pur și simplu funcții în programul server. Deci acest lucru se decide din punctul de vedere al programatorului, dar în realitate are loc următoarea secvență de acțiuni.

Când un client apelează o procedură la distanță, este apelată o funcție de pe gazda locală care este generată de pachetul RPC. Această funcție se numește client stub. client stub împachetează argumentele procedurii într-un mesaj de rețea și trimite mesajul către server.
server stub de pe serverul gazdă primește mesajul de rețea. Argumentele sunt preluate din mesajul de rețea și se efectuează un apel către procedura de server scrisă de programatorul aplicației.
Funcția de server returnează controlul stub-ului de server, care la rândul său preia valorile primite, le împachetează într-un mesaj de rețea și trimite mesajul înapoi către stub-ul clientului.
client stub returnează valori dintr-un mesaj de rețea către aplicația client.

Programarea în rețea care utilizează rutinele RPC de bibliotecă și stub utilizează API-uri (socket-uri sau TLI), dar aplicațiile utilizator (programul client și procedurile server numite de client) nu accesează niciodată API-ul. Aplicația client trebuie doar să apeleze procedura serverului, în timp ce toate detaliile de implementare sunt ascunse de pachetul RPC, client stub și server stub.

Pachetele RPC au următoarele avantaje.

Programarea devine mai ușoară pentru că nu trebuie să rezolvi problemele de programare în rețea (și dacă o faci, este foarte puțin). Programatorii de aplicații scriu pur și simplu programul client și procedurile de server pe care clientul le apelează.
Dacă se folosește un protocol nesigur precum UDP, toate detaliile, și anume timeout-uri și retransmisii, sunt gestionate de pachetul RPC.
Acest lucru, la rândul său, simplifică aplicația utilizatorului.

Biblioteca RPC se ocupă de conversia necesară a argumentelor și a valorilor returnate. De exemplu, dacă argumentele constau din numere întregi și numere în virgulă mobilă, pachetul RPC va gestiona orice diferență între reprezentarea numerelor întregi și a numerelor în virgulă mobilă pe client și pe server. Acest lucru simplifică implementarea clienților și serverelor pentru a opera în medii eterogene.

Programarea RPC este tratată în detaliu în Capitolul 18. Cele mai populare două pachete RPC sunt Sun RPC și pachetul RPC din DCE (Distributed Computing Environment) al Open Software Foundation (OSF). la pachetul Sun RPC, deoarece acest pachet este utilizat în Sun RPC Versiunea 2, care este descris în RFC 1057 [Sun Microsystems 1988a].

Există două tipuri de Sun RPC. O versiune este construită folosind API-ul sockets și funcționează cu TCP și UDP. Celălalt se numește TI-RPC (independent de transport), construit folosind API-ul TLI și funcționează cu orice nivel de transport furnizat de kernel. Din punctul nostru de vedere, nu există nicio diferență între ele, deoarece în acest capitol luăm în considerare doar TCP și UDP.

Figura 29.1 prezintă formatul unui mesaj de apel de procedură RPC folosind UDP.

Figura 29.1 Mesaje de apel de procedură RPC în format de datagramă UDP.

Identificatorul tranzacției (XID - ID tranzacție) este setat de client și returnat de server. Când clientul primește un răspuns, compară XID-ul returnat de server cu XID-ul cererii trimise. Dacă nu se potrivesc, clientul renunță la mesaj și așteaptă să sosească următorul. De fiecare dată când clientul emite un nou RPC, acesta schimbă XID-ul. Cu toate acestea, dacă clientul retransmite RPC (dacă nu a fost primit niciun răspuns), XID-ul nu se modifică.

Variabila de apel este 0 pentru un apel și 1 pentru un răspuns. Versiunea curentă RPC este 2. Următoarele trei variabile, numărul programului, numărul versiunii și numărul procedurii, identifică procedura specifică care trebuie apelată pe server.

Acreditările identifică clientul. În unele exemple acest câmp este lăsat necompletat, în timp ce în altele puteți vedea identificatorul digital al utilizatorului și identificatorul de grup din care face parte. Serverul poate analiza acreditările și poate decide dacă procesează cererea sau nu. Verifier este utilizat pentru Secure RPC, care utilizează criptarea DES. Chiar dacă câmpurile de autorizare și validare sunt câmpuri de lungime variabilă, lungimea lor este trecută ca parte a câmpului.

Urmează parametrii procedurii. Formatul lor depinde de modul în care aplicația definește procedura de la distanță. Cum știe receptorul (server stub) dimensiunea parametrilor? Deoarece este utilizat UDP, dimensiunea parametrilor poate fi calculată ca dimensiunea datagramei UDP minus lungimea tuturor câmpurilor până la câmpul de verificare. Când se folosește TCP în loc de UDP, nu există conceptul de lungime fixă, deoarece TCP este un flux de octeți fără separatori de înregistrări. Într-un astfel de caz, între antetul TCP și XID apare un câmp de lungime de 4 octeți, de la care receptorul învață lungimea apelului RPC în octeți. Acest lucru permite ca mesajul de apel RPC să fie trimis pe mai multe segmente TCP, dacă este necesar. (DNS folosește o tehnică similară; Exercițiul 4 din capitolul 14.)

Figura 29.2 prezintă formatul de răspuns RPC. Este trimis de la stub-ul serverului către stub-ul client atunci când procedura de la distanță iese.

Figura 29.2 Formatul mesajului de răspuns al procedurii RPC ca datagramă UDP.

Apelul XID este pur și simplu copiat în răspunsul XID. Câmpul de răspuns conține 1, acest câmp distinge între o provocare și un răspuns. Câmpul de stare conține o valoare nulă dacă mesajul de apel a fost acceptat. (Mesajul poate fi eliminat dacă numărul versiunii RPC nu este 2 sau dacă serverul nu poate autentifica clientul.) Câmpul de verificare este utilizat în cazul RPC securizat pentru a indica serverul.

Câmpul de stare de acceptare conține o valoare zero dacă totul este bine. O valoare diferită de zero ar putea indica, de exemplu, un număr de versiune incorect sau un număr de procedură incorect. Dacă se folosește TCP în loc de UDP, atunci, ca și în cazul mesajului de apel RPC, este trimis un câmp de lungime de 4 octeți între antetul TCP și XID.

XDR: Reprezentare externă a datelor

Reprezentarea datelor externe (XDR) este un standard utilizat pentru codificarea valorilor în mesajele de apel și răspuns RPC - câmpurile antet RPC (XID, numărul programului, starea primirii etc.), parametrii procedurii și rezultatele procedurii. Un mod standard de codificare a datelor permite unui client să apeleze o procedură pe un sistem cu o arhitectură diferită. XDR este definit în RFC 1014 [Sun Microsystems 1987].

XDR definește un anumit număr de tipuri de date și modul exact în care acestea sunt transportate într-un mesaj RPC (ordinea biților, ordinea octetilor și așa mai departe). Expeditorul trebuie să construiască mesajul RPC în format XDR, apoi destinatarul convertește formatul XDR în reprezentarea originală. (În formatul care este acceptat pentru sistemul său.) Vedem, de exemplu, în figurile 29.1 și 29.2, că toate valorile întregi pe care le-am arătat (XID, apel, număr de program și așa mai departe) sunt numere întregi de 4 octeți . Într-adevăr, toate numerele întregi din XDR ocupă 4 octeți. XDR acceptă alte tipuri de date, inclusiv numere întregi fără semn, boolean, virgulă mobilă, matrice cu lungime fixă, matrice cu lungime variabilă și structuri.

Conformitatea porturilor

Programele server RPC care conțin proceduri de la distanță folosesc mai degrabă porturi alocate dinamic decât porturi precunoscute. Acest lucru necesită o anumită formă de „înregistrare” pentru a ști întotdeauna care port alocat dinamic este utilizat de către ce program RPC. În Sun RPC, acest logger este numit port mapper. (Un port mapper este un server care convertește numerele de program RPC în numere de port de protocol DARPA. Acest server trebuie să ruleze pentru a efectua un apel RPC.)

Termenul „port” din nume provine de la numerele de porturi TCP și UDP, caracteristici ale familiei de protocoale Internet. Deoarece TI-RPC rulează peste orice nivel de transport, nu doar TCP și UDP, mapatorul de nume de port pe sistemele care utilizează TI-RPC (SVR4 și Solaris 2.2, de exemplu) a fost convertit în rpcbind. Cu toate acestea, vom continua să folosim mapatorul de porturi mai familiar.

De fapt, rezolutorul de porturi în sine trebuie să aibă un port cunoscut: portul UDP 111 și portul TCP 111. Rezolvatorul de porturi este doar un program server RPC. Are un număr de program (100000), un număr de versiune (2), portul TCP 111 și portul UDP 111. Serverele se înregistrează reciproc cu rezolutorul de porturi folosind apeluri RPC, iar clienții solicită rezolutorul de porturi folosind apeluri RPC. Soluția de porturi oferă patru proceduri de server:

PMAPPROC_SET. Apelat de serverul RPC la pornire pentru a înregistra numărul programului, numărul versiunii și protocolul cu soluția de porturi.
PMAPPROC_UNSET. Apelat de server pentru a elimina o transformare înregistrată anterior.
PMAPPROC_GETPORT. Apelat de clientul RPC la pornire pentru a obține numărul de port pentru numărul de program, numărul de versiune și protocolul dat.
PMAPPROC_DUMP. Returnează toate elementele (numărul programului, numărul versiunii, protocolul și numărul portului) în baza de date de rezoluție de porturi.

Când pornește programul server RPC și mai târziu când este apelat de programul client RPC, au loc următorii pași.

Convertorul de porturi ar trebui să pornească mai întâi, de obicei când sistemul pornește. Aceasta creează un punct final TCP și deschide pasiv portul TCP 111. De asemenea, creează un punct final UDP care așteaptă să ajungă o datagramă UDP pe portul UDP 111.
Când pornește programul server RPC, acesta creează un punct final TCP și un punct final UDP pentru fiecare versiune acceptată a programului. (Un program RPC poate suporta mai multe versiuni. Clientul specifică versiunea necesară atunci când apelează procedura serverului.) Fiecărui punct final i se atribuie un număr de port alocat dinamic. (Nu are nicio diferență dacă numerele de porturi TCP și UDP sunt aceleași sau diferite.) Serverul înregistrează fiecare program, versiune, protocol și număr de port efectuând un apel de la distanță la procedura de rezolvare a portului PMAPPROC_SET.
Când programul client RPC pornește, apelează procedura de rezoluție de porturi PMAPPROC_GETPORT pentru a obține numărul de port alocat dinamic pentru programul, versiunea și protocolul specificat.
Clientul trimite un mesaj de provocare RPC la numărul portului obținut la pasul 3. Dacă se folosește UDP, clientul trimite pur și simplu o datagramă UDP care conține mesajul de provocare RPC (Figura 29.1) către numărul portului UDP al serverului. Ca răspuns, serverul trimite o datagramă UDP care conține un mesaj de răspuns RPC (Figura 29.2). Dacă se folosește TCP, clientul face o deschidere activă a numărului de port TCP al serverului și apoi trimite un mesaj de provocare RPC prin conexiune.

Serverul răspunde cu un mesaj de răspuns RPC la conexiune.

Programul rpcinfo(8) imprimă toate setările curente ale cartografierii portului. (Aici este apelată rutina de cartografiere de porturi PMAPPROC_DUMP.) Ieșirea tipică este prezentată mai jos: Soare%
/usr/etc/rpcinfo -p
program vers proto port
100005 1 tcp 702 mountd demon de montare NFS
100005 1 udp 699 mountd
100005 2 tcp 702 montat

100005 2 udp 699 mountd

100003 2 udp 2049 nfs NFS propriu-zis
100021 1 tcp 709 nlockmgr Manager de blocare NFS
100021 1 udp 1036 nlockmgr
100021 2 tcp 721 nlockmgr
100021 2 udp 1039 nlockmgr
100021 3 tcp 713 nlockmgr

100021 3 udp 1037 nlockmgr

Vedem că unele programe acceptă mai multe versiuni și fiecare combinație de număr de program, număr de versiune și protocol are propriul aspect al numărului de port, deservit de un rezolutor de porturi.

Protocolul NFS

Ambele versiuni ale demonului de montare pot fi accesate prin același număr de port TCP (702) și același număr de port UDP (699), totuși fiecare versiune a managerului de blocare are propriul număr de port.

NFS este o aplicație client-server construită folosind Sun RPC. Clienții NFS accesează fișierele de pe un server NFS trimițând cereri RPC către server. Acest lucru poate fi implementat folosind procese normale ale utilizatorului - și anume, clientul NFS poate fi un proces utilizator care face apeluri RPC specifice către server, care poate fi și un proces utilizator. Cu toate acestea, NFS este de obicei implementat diferit din două motive. În primul rând, accesul la fișierele NFS trebuie să fie transparent pentru client. Prin urmare, apelurile clientului NFS sunt efectuate de sistemul de operare client în numele procesului utilizator al clientului. În al doilea rând, serverele NFS sunt implementate în sistemul de operare pentru a îmbunătăți eficiența serverului. Dacă serverul NFS ar fi un proces de utilizator, fiecare cerere client și răspuns de server (inclusiv datele de citit sau scris) ar trebui să treacă printr-un separator între kernel și procesul utilizator, care este în general destul de costisitor.

În această secțiune, ne vom uita la versiunea 2 a NFS așa cum este documentată în RFC 1094 [Sun Microsystems 1988b]. Cea mai bună descriere a Sun RPC, XDR și NFS este dată în [X/Open 1991]. Detalii despre utilizarea și administrarea NFS sunt date în [Stern 1991]. Specificațiile protocolului NFS versiunea 3 au fost implementate în 1993, despre care vom discuta într-o secțiune a acestui capitol.

Figura 29.3 prezintă setările tipice pentru client NFS și server NFS. În această figură, trebuie să acordați atenție la următoarele.

Clientului nu îi pasă dacă accesează un fișier local sau un fișier NFS. Nucleul detectează acest lucru atunci când fișierul este deschis. După deschiderea fișierului, nucleul trece tot accesul la fișierele locale casetei etichetate „acces fișier local”, iar toate linkurile către fișierele NFS sunt transmise casetei „client NFS”.
Clientul NFS trimite cereri RPC către serverul NFS prin modulul TCP/IP. NFS utilizează de obicei UDP, însă implementările mai noi pot folosi TCP.
Serverul NFS primește cereri de la client ca datagrame UDP pe portul 2049. Deși NFS poate funcționa cu un rezolutor de porturi, care permite serverului să utilizeze porturi alocate dinamic, portul UDP 2049 este codificat în NFS în majoritatea implementărilor.

Figura 29.3 Setări tipice pentru client NFS și server NFS.

Când serverul NFS primește o solicitare de la un client, aceasta este trecută la o rutină locală de acces la fișiere, care oferă acces la discul local de pe server.

Serverul poate dura timp pentru a procesa cererile clientului. Chiar și accesarea sistemului de fișiere local poate dura ceva timp. În acest timp, serverul nu dorește să blocheze cererile de la alți clienți care trebuie să fie de asemenea serviți. Pentru a face față acestei situații, majoritatea serverelor NFS sunt pornite de mai multe ori, ceea ce înseamnă că există mai multe servere NFS în nucleu.

Metodele specifice de soluție depind de sistemul de operare. Majoritatea nucleelor Unix nu „trăiesc” mai multe servere NFS, ci în schimb pornesc mai multe procese utilizator (numite de obicei nfsd) care fac un singur apel de sistem și rămân în interiorul nucleului ca proces de nucleu.

În mod similar, un client NFS are nevoie de timp pentru a procesa o solicitare de la un proces utilizator de pe gazda client. RPC-ul este emis gazdei serverului, după care se așteaptă un răspuns. Pentru a vă asigura că procesele utilizatorului de pe gazda clientului pot profita de NFS în orice moment, există mai mulți clienți NFS care rulează în interiorul nucleului clientului. Implementarea specifică depinde și de sistemul de operare. Sistemele Unix folosesc de obicei o tehnică care amintește de un server NFS: un proces utilizator numit biod efectuează un singur apel de sistem și rămâne în interiorul nucleului ca proces de nucleu.

Majoritatea gazdelor Unix pot funcționa ca client NFS și server NFS, sau ambele în același timp. Majoritatea implementărilor pentru PC (MS-DOS) au doar implementări client NFS. Majoritatea mainframe-urilor IBM oferă doar funcționalitate server NFS.

NFS este de fapt mai mult decât doar protocolul NFS. Figura 29.4 prezintă diferitele programe RPC care sunt utilizate cu NFS.	Aplicație	Numărul programului	Versiunea numarul
Numărul de proceduri
convertor de porturi
NFS
program de montare
manager de blocare

monitor de stare

Figura 29.4 Diverse programe RPC utilizate în NFS.

Versiunile pe care le-am arătat în această figură ca unități se găsesc pe sisteme precum SunOS 4.1.3. Noile implementări oferă versiuni mai noi ale unor programe. Solaris 2.2, de exemplu, acceptă și versiunile 3 și 4 ale rezolutorului de porturi și versiunea 2 a demonului de montare. SVR4 acceptă și versiunea 3 a convertorului de porturi.

Managerul de blocare și monitorul de stare permit clientului să blocheze unele fișiere care se află pe serverul NFS. Aceste două programe sunt independente de protocolul NFS, deoarece blocarea necesită autentificarea clientului atât la gazda client, cât și la server, iar NFS în sine este „neutru”. (Vom vorbi mai jos despre indiferența NFS mai detaliat.) Capitolele 9, 10 și 11 [X/Open 1991] documentează procedurile care sunt utilizate de managerul de blocare și de monitorul de stare pentru blocarea în NFS.

Descriptori de fișiere

Unul dintre elementele fundamentale ale NFS este implementat de descriptori de fișiere. Pentru a accesa un fișier sau un director de pe serverul de obiecte, se folosește opac. Termenul opac înseamnă că serverul creează un handle de fișier, îl transmite înapoi clientului, pe care clientul îl folosește atunci când accesează fișierul. Clientul nu se uită niciodată la conținutul descriptorului de fișier - conținutul acestuia este de interes doar pentru server.

Clientul NFS primește un handle de fișier de fiecare dată când deschide un fișier care se află de fapt pe serverul NFS. Când un client NFS citește sau scrie în acest fișier (în numele unui proces utilizator), un handle al fișierului este transmis înapoi serverului. Aceasta indică faptul că fișierul a fost accesat.

De obicei, procesul utilizatorului nu funcționează cu descriptori de fișiere. Descriptorii de fișiere sunt schimbați între clientul NFS și serverul NFS. În versiunea 2 a NFS, descriptorul fișierului este de 32 de octeți, iar în versiunea 3 a crescut la 64 de octeți.

Serverele Unix stochează în mod obișnuit următoarele informații în descriptorul de fișiere: identificatorul sistemului de fișiere (numerele dispozitivelor majore și minore ale sistemului de fișiere), numărul inodului (i-node) (un număr unic în sistemul de fișiere), numărul generației inodului (un număr care se modifică de fiecare dată când inodul este reutilizat pentru un alt fișier).

Protocol de montare

Clientul folosește protocolul de montare NFS pentru a monta sistemul de fișiere al serverului înainte de a accesa fișierele NFS. Acest lucru se întâmplă de obicei când clientul se încarcă. Ca rezultat, clientul primește un handle de fișier către sistemul de fișiere al serverului.

Figura 29.5 descrie secvența de acțiuni ale unui client Unix la executarea comenzii mount(8).

Figura 29.5 Protocolul de montare utilizat de comanda Unix mount.

În acest caz, se efectuează următorii pași.

Când serverul pornește, convertorul de porturi pornește pe el.
După soluția de porturi, demonul de montare (mountd) începe pe server. Acesta creează un punct final TCP și un punct final UDP și atribuie fiecăruia un număr de port alocat dinamic. Apoi înregistrează aceste numere cu mapatorul de porturi.
Clientul execută comanda mount, care emite un apel RPC către solutorul de porturi al serverului pentru a obține un număr de port de la demonul mount de pe server. Atât TCP, cât și UDP pot fi utilizate pentru comunicarea între client și rezolutorul de porturi, dar UDP este de obicei utilizat.
Resolutorul portului raportează numărul portului.
Comanda mount lansează un apel RPC către demonul mount pentru a monta sistemul de fișiere al serverului. Din nou, poate fi folosit fie TCP, fie UDP, totuși UDP este utilizat de obicei.
Serverul poate valida acum un client pe baza adresei sale IP și a numărului de port pentru a vedea dacă clientul poate monta sistemul de fișiere specificat.
Daemonul de montare răspunde cu un handle de fișier la sistemul de fișiere specificat.

Comanda de montare a clientului emite apelul de sistem de montare pentru a asocia mânerul de fișier obținut la pasul 5 cu punctul de montare local de pe gazda clientului. Hranul de fișier este stocat în codul NFS al clientului, iar de acum înainte orice acces de către procesele utilizatorului la fișierele din sistemul de fișiere al serverului va folosi handle-ul de fișier ca punct de plecare.

Această implementare lasă întregul proces de montare, cu excepția apelului de sistem de montare pe client, mai degrabă proceselor utilizatorului decât nucleului. Cele trei programe pe care le-am arătat - comanda mount, rezolutorul de porturi și demonul mount - sunt procese utilizator.

În acest exemplu, pe soarele gazdă (client NFS), comanda a fost executată soare

# mount -t nfs bsdi:/usr /nfs/bsdi/usr

Această comandă montează directorul /usr pe gazda bsdi (server NFS) ca sistem de fișiere local /nfs/bsdi/usr. Figura 29.6 arată rezultatul.

Figura 29.6 Montarea directorului bsdi:/usr ca /nfs/bsdi/usr pe soarele gazdă.

După aceea, la accesarea fișierului /nfs/bsdi/usr/rstevens/hello.c pe clientul sun, este accesat fișierul /usr/rstevens/hello.c de pe serverul bsdi.

Serverul NFS oferă 15 proceduri, pe care le vom descrie acum. (Numerele utilizate în această descriere nu sunt aceleași cu numerele procedurii NFS, deoarece le-am grupat în funcție de funcționalitate.) Deși NFS a fost proiectat să funcționeze peste sisteme de operare, nu doar sisteme Unix, unele dintre proceduri se bazează în mod special pe funcționarea Unix , care, la rândul său, poate să nu fie acceptat de alte sisteme de operare (de exemplu, legături rigide, legături simbolice, utilizare în grup, drepturi de acces la execuție și așa mai departe). Capitolul 4 conține mai multe informații despre caracteristicile sistemelor de fișiere, dintre care unele le utilizează NFS.

GETATTR. Returnează atributele fișierului: tipul fișierului (fișier obișnuit, director etc.), drepturi de acces, dimensiunea fișierului, proprietarul fișierului, ora ultimului acces și așa mai departe.
SETATTR. Setează atributele fișierului.
Numai un anumit set de atribute poate fi setat: drepturi de acces, proprietar, proprietate a grupului, dimensiune, ora ultimului acces și ora ultimei modificări.
STATFS. Returnează starea sistemului de fișiere: cantitatea de spațiu liber, dimensiunea optimă pentru transfer și așa mai departe. Folosit, de exemplu, de comanda Unix df.
PRIVEŞTE ÎN SUS. „Evaluează” fișierul. Această procedură este apelată de client de fiecare dată când un proces utilizator deschide un fișier care se află pe serverul NFS. Este returnat un handle de fișier, împreună cu atributele fișierului.
CITIT. Citește dintr-un fișier. Clientul specifică un mâner de fișier, un decalaj de octeți de pornire și numărul maxim de octeți de citit (până la 8192).
SCRIE. Scrie într-un fișier. Clientul specifică mânerul fișierului, offset-ul de pornire în octeți, numărul de octeți de scris și datele de scris.
Este necesar ca scrierile NFS să fie sincrone (cu o așteptare). Serverul nu poate răspunde OK până când datele au fost scrise cu succes (și orice alte informații despre fișier care trebuie actualizate) pe disc.
CREA. Creează un fișier.
ELIMINA. Șterge un fișier.
RENUMIRE. Redenumește fișierul.
SYMLINK. Creează o legătură simbolică către un fișier.
O legătură simbolică este un fișier care conține numele altui fișier. Majoritatea operațiunilor care sunt efectuate pe o legătură simbolică (de exemplu, deschiderea) sunt de fapt efectuate pe fișierul către care indică legătura simbolică.
READLINK. Citirea unui link simbolic returnează numele fișierului indicat de linkul simbolic.
MKDIR. Creează un director.
RMDIR. Șterge un director.

READDIR. Citește directorul. Folosit, de exemplu, de comanda Unix ls.

De fapt, numele procedurilor afișate încep cu prefixul NFSPROC_, pe care l-am omis.

UDP sau TCP?

NFS a fost scris inițial pentru a utiliza UDP și toți furnizorii oferă această capacitate. Cu toate acestea, implementările mai noi acceptă și TCP. Suportul TCP este folosit pentru a opera prin rețele globale, care devin din ce în ce mai rapide. Prin urmare, utilizarea NFS nu se mai limitează la rețelele locale.

Granițele dintre rețelele locale și cele globale se estompează și toate acestea se întâmplă foarte repede. Timpii de întoarcere variază într-un interval foarte larg și depășirea are loc din ce în ce mai frecvent. Aceste caracteristici ale rețelelor globale duc la faptul că folosesc din ce în ce mai mult algoritmii pe care i-am considerat pentru TCP - slow start and congestion avoidance. Deoarece UDP nu oferă nimic similar cu acești algoritmi, aceștia sau alții similari trebuie să fie încorporați în clientul și serverul NFS, altfel trebuie utilizat TCP.

NFS peste TCP

Implementarea Berkeley Net/2 NFS acceptă atât UDP, cât și TCP. [Macklem 1991] descrie această implementare. Să ne uităm la modul în care utilizarea NFS diferă atunci când rulează peste TCP.
Când serverul pornește, pornește serverul NFS, care se deschide activ pe portul TCP 2049, așteptând să sosească o solicitare de conectare de la client. Acest lucru se face de obicei în plus față de NFS UDP obișnuit, care ascultă datagramele primite pe portul UDP 2049.
Atât clientul, cât și serverul setează opțiunea TCP „stay alive” la capetele conexiunii (Capitolul 23). Acest lucru vă permite să determinați momentul eșecului sau repornirii unuia sau altuia participant la schimb.
Toate aplicațiile de pe client care utilizează sistemul de fișiere al serverului partajează aceeași conexiune TCP la acel sistem de fișiere.
De exemplu, dacă ar exista în Figura 29.6, ar exista un alt director pe bsdi, numit smith, sub directorul /usr, apeluri la fișierele din /nfs/bsdi/usr/rstevens și /nfs/bsdi/usr/smith ar partaja același lucru, aceeași conexiune TCP.
Dacă clientul stabilește că serverul s-a prăbușit sau a repornit (după ce a primit o eroare TCP „conexiune expirată” sau „conexiune închisă de gazdă”), încearcă să se reconnecteze la server. Clientul efectuează o altă deschidere activă pentru a restabili conexiunea TCP pentru acest sistem de fișiere. Orice solicitare de la un client care a expirat la o conexiune anterioară este reemisă la o nouă conexiune.

Dacă un client eșuează, la fel și aplicațiile care rulau înainte de eșec. Când clientul repornește, acesta poate remonta sistemul de fișiere al serverului folosind TCP, folosind o conexiune TCP diferită la server.

Conexiunea anterioară dintre client și server pentru acest sistem de fișiere este într-o stare pe jumătate deschisă (serverul crede că este încă deschisă), totuși, deoarece serverul a setat opțiunea „stay alive”, această conexiune pe jumătate deschisă va fi închis când serverul TCP trimite următoarea sondă." rămâne în viață."

De-a lungul timpului, alți furnizori plănuiesc să accepte NFS prin TCP.

Exemple NFS

Să folosim tcpdump pentru a vedea ce rutine NFS sunt invocate de client pentru operațiuni normale cu fișiere. Când tcpdump determină că o datagramă UDP conține un apel RPC (apelul este 0 în Figura 29.1) cu portul de destinație 2049, decodifică datagrama ca o cerere NFS. În mod similar, dacă o datagramă UDP conține un răspuns RPC (răspunsul este 1 în Figura 29.2) cu un port sursă de 2049, aceasta decodifică datagrama ca răspuns NFS.

Programul rpcinfo(8) imprimă toate setările curente ale cartografierii portului. (Aici este apelată rutina de cartografiere de porturi PMAPPROC_DUMP.) Ieșirea tipică este prezentată mai jos: Exemplu simplu: citirea unui fișierÎn primul exemplu, vom copia un fișier aflat pe serverul NFS pe terminal folosind comanda cat(1):
cat /nfs/bsdi/usr/rstevens/hello.c
{
copierea unui fișier pe terminal
}

Sistemul de fișiere /nfs/bsdi/usr de pe gazda sun (client NFS) este de fapt sistemul de fișiere /usr de pe gazda bsdi (server NFS), așa cum se arată în Figura 29.6. Sunkernel-ul detectează acest lucru atunci când cat deschide un fișier și folosește NFS pentru a accesa fișierul. Figura 29.7 arată rezultatul comenzii tcpdump.

1 0.0 sun.7aa6 > bsdi.nfs: 104 getattr
2 0.003587 (0.0036) bsdi.nfs > sun.7aa6: răspuns ok 96

3 0,005390 (0,0018) sun.7aa7 > bsdi.nfs: 116 căutare „rstevens”
4 0.009570 (0.0042) bsdi.nfs > sun.7aa7: răspuns ok 128

5 0,011413 (0,0018) sun.7aa8 > bsdi.nfs: 116 căutare „hello.c”
6 0.015512 (0.0041) bsdi.nfs > sun.7aa8: răspuns ok 128

7 0.018843 (0.0033) sun.7aa9 > bsdi.nfs: 104 getattr
8 0.022377 (0.0035) bsdi.nfs > sun.7aa9: răspuns ok 96

9 0.027621 (0.0052) sun.7aaa > bsdi.nfs: 116 citiți 1024 octeți @ 0
10 0.032170 (0.0045) bsdi.nfs > sun.7aaa: raspunde ok 140

Figura 29.7 Operarea NFS la citirea unui fișier.

Comanda tcpdump decodifică cererea sau răspunsul NFS și, de asemenea, tipărește câmpul XID pentru client în loc de numărul portului. Câmpul XID din rândurile 1 și 2 este 0x7aa6.

Numele de fișier /nfs/bsdi/usr/rstevens/hello.c este procesat de funcția de deschidere din nucleul clientului, câte un element de nume. Când funcția deschisă ajunge la /nfs/bsdi/usr, determină că acesta este un punct de montare a sistemului de fișiere NFS.

Pe linia 1, clientul apelează GETATTR pentru a obține atributele directorului serverului pe care clientul l-a montat (/usr). Această solicitare RPC conține 104 octeți de date, în plus față de anteturile IP și UDP. Răspunsul de pe linia 2 returnează OK și conține 96 de octeți de date, în plus față de anteturile IP și UDP. Putem vedea în această figură că mesajul NFS minim conține aproximativ 100 de octeți de date.

Pe linia 3, clientul apelează LOOKUP pe fișierul rstevens și primește un răspuns OK pe linia 4. LOOKUP specifică numele fișierului rstevens și un handle pentru fișierul care a fost stocat de kernel când a fost montat sistemul de fișiere la distanță. Răspunsul conține un nou handle de fișier care este utilizat în pasul următor.

Pe linia 5, clientul caută fișierul hello.c folosind mânerul de fișier de la linia 4. Primește un mâner de fișier diferit pe linia 6. Acest nou mâner de fișier este exact ceea ce clientul folosește pe liniile 7 și 9 pentru a accesa fișierul / nfs /bsdi/usr/rstevens/hello.c. Vedem că clientul efectuează o CĂUTARE pe fiecare componentă de nume din calea către fișierul care este deschis.

Pe linia 7, clientul execută din nou GETATTR, urmat de READ pe linia 9. Clientul solicită 1024 de octeți începând cu offset-ul 0, dar primește mai puțin de 1024 de octeți de date. (După scăderea dimensiunilor câmpurilor RPC și a altor valori returnate de procedura READ, 38 de octeți de date sunt returnați pe linia 10. Aceasta este exact dimensiunea fișierului hello.c.)

În acest exemplu, procesul utilizatorului nu știe nimic despre aceste solicitări și răspunsuri NFS care sunt efectuate de kernel. Aplicația apelează doar funcția de bază deschisă, care face ca 3 cereri și 3 răspunsuri să fie schimbate (liniile 1-6), apoi apelează funcția de citire de bază, care apelează 2 cereri și 2 răspunsuri (liniile 7-10). Pentru aplicația client, fișierul aflat pe serverul NFS este transparent.

Exemplu simplu: crearea unui director

Ca un alt exemplu, să schimbăm directorul de lucru într-un director care se află pe serverul NFS și apoi să creăm un nou director:

Programul rpcinfo(8) imprimă toate setările curente ale cartografierii portului. (Aici este apelată rutina de cartografiere de porturi PMAPPROC_DUMP.) Ieșirea tipică este prezentată mai jos: cd /nfs/bsdi/usr/rstevens schimba directorul de lucru
soare % mkdir Mail creați un director

Figura 29.8 arată rezultatul comenzii tcpdump.

1 0.0 sun.7ad2 > bsdi.nfs: 104 getattr
2 0.004912 (0.0049) bsdi.nfs > sun.7ad2: răspuns ok 96

3 0.007266 (0.0024) sun.7ad3 > bsdi.nfs: 104 getattr
4 0.010846 (0.0036) bsdi.nfs > sun.7ad3: răspuns ok 96

5 35.769875 (35.7590) sun.7ad4 > bsdi.nfs: 104 getattr
6 35.773432 (0.0036) bsdi.nfs > sun.7ad4: raspunde ok 96

7 35.775236 (0.0018) sun.7ad5 > bsdi.nfs: 112 căutare „Mail”
8 35.780914 (0.0057) bsdi.nfs > sun.7ad5: raspunde ok 28

9 35.782339 (0.0014) sun.7ad6 > bsdi.nfs: 144 mkdir „Mail”
10 35.992354 (0.2100) bsdi.nfs > sun.7ad6: raspunde ok 128

Figura 29.8 Operarea NFS la schimbarea directorului (cd) în directorul NFS și apoi la crearea directorului (mkdir).

La schimbarea directorului, clientul apelează GETATTR de două ori (liniile 1-4). Când creăm un nou director, clientul apelează GETATTR (liniile 5 și 6), apoi LOOKUP (liniile 7 și 8 pentru a verifica dacă directorul nu există), apoi MKDIR pentru a crea directorul (liniile 9 și 10). Răspunsul OK de pe linia 8 nu înseamnă că directorul există. Înseamnă pur și simplu că procedura a returnat o anumită valoare. tcpdump nu interpretează valoarea returnată de procedurile NFS. Comanda imprimă pur și simplu OK și numărul de octeți de date din răspuns.

Indiferenţă

Una dintre caracteristicile NFS (criticii NFS o numesc un neg, nu o caracteristică) este că serverul NFS este indiferent. Serverului nu îi pasă ce clienți accesează ce fișiere. Observați că lista procedurilor NFS prezentată mai devreme nu include o procedură de deschidere sau de închidere. Procedura LOOKUP este similară cu cea deschisă, dar serverul nu știe niciodată dacă clientul a accesat fișierul după ce a fost efectuată CĂUTAREA.

Motivul acestui „comportament nu-mi pasă” este acela de a facilita recuperarea după o defecțiune a serverului după ce acesta se blochează și repornește.

Exemplu: eroare de server

În exemplul următor, citim un fișier de pe un server NFS când serverul se blochează și repornește. Aceasta va arăta cum „indiferența” serverului îi permite clientului „să nu știe” că serverul a eșuat. În tot timpul când serverul se blochează și repornește, clientul nu este conștient de problemă, iar aplicația client funcționează la fel ca înainte.

Pe clientul Sun, am rulat cat cu un fișier foarte mare ca argument (/usr/share/lib/termcap pe serverul svr4 NFS), am deconectat cablul Ethernet la mijlocul transferului, am oprit și repornit serverul, apoi am reconectat cablul . Clientul a fost configurat să citească 1024 de octeți per citire NFS. Figura 29.9 arată rezultatul tcpdump.

Rândurile 1-10 corespund cu clientul care deschide fișierul. Această operație este similară cu cea prezentată în Figura 29.7. Pe linia 11 vedem prima citire (READ) din fișierul de 1024 de octeți de date; răspunsul a revenit pe linia 12. Aceasta continuă până la linia 129 (citind 1024 de octeți de READ și apoi răspunzând OK).

În rândurile 130 și 131 vedem două cereri care expiră și sunt retrimise în rândurile 132 și 133. Prima întrebare: vedem două solicitări de citire, una începe cu offset 65536 și cealaltă începe cu offset 73728, de ce? Nucleul clientului a determinat că aplicația client citea secvențial și a încercat să obțină blocuri de date în avans. (Majoritatea nucleelor Unix fac această citire înainte.) Nucleul client rulează, de asemenea, mai multe daemoni de intrare/ieșire (I/O) bloc NFS (procese biod) care încearcă să genereze mai multe cereri RPC în numele clientului. Un demon citește 8192 de octeți, începând de la 65536 (în lanțuri de 1024 de octeți), iar ceilalți citesc înainte 8192 de octeți, începând de la 73728.

Retransmisiunile clientului apar pe liniile 130-168. Pe linia 169 vedem că serverul a repornit și a trimis o solicitare ARP înainte de a răspunde la cererea NFS a clientului pe linia 168. Răspunsul la linia 168 este trimis pe linia 171. Cererile READ ale clientului continuă.

1 0.0 sun.7ade > svr4.nfs: 104 getattr
2 0.007653 (0.0077) svr4.nfs > sun.7ade: răspuns ok 96

3 0,009041 (0,0014) sun.7adf > svr4.nfs: 116 căutare „share”
4 0.017237 (0.0082) svr4.nfs > sun.7adf: răspuns ok 128

5 0,018518 (0,0013) sun.7ae0 > svr4.nfs: 112 căutare „lib”
6 0.026802 (0.0083) svr4.nfs > sun.7ae0: răspuns ok 128

7 0,028096 (0,0013) sun.7ae1 > svr4.nfs: 116 căutare „termcap”
8 0.036434 (0.0083) svr4.nfs > sun.7ae1: răspuns ok 128

9 0.038060 (0.0016) sun.7ae2 > svr4.nfs: 104 getattr
10 0.045821 (0.0078) svr4.nfs > sun.7ae2: răspuns ok 96

11 0,050984 (0,0052) sun.7ae3 > svr4.nfs: 116 citire 1024 octeți @ 0
12 0.084995 (0.0340) svr4.nfs > sun.7ae3: raspunde ok 1124

Citind

128 3.430313 (0.0013) sun.7b22 > svr4.nfs: 116 citire 1024 octeți @ 64512
129 3.441828 (0.0115) svr4.nfs > sun.7b22: raspunde ok 1124

130 4.125031 (0.6832) soare.7b23 >
131 4.868593 (0.7436) soare.7b24 >

132 4.993021 (0.1244) sun.7b23 > svr4.nfs: 116 citiți 1024 octeți @ 65536
133 5.732217 (0.7392) sun.7b24 > svr4.nfs: 116 citire 1024 octeți @ 73728

134 6.732084 (0.9999) sun.7b23 > svr4.nfs: 116 citiți 1024 octeți @ 65536
135 7.472098 (0.7400) sun.7b24 > svr4.nfs: 116 citire 1024 octeți @ 73728

136 10.211964 (2.7399) soare.7b23 >
137 10.951960 (0.7400) soare.7b24 >

138 17.171767 (6.2198) sun.7b23 > svr4.nfs: 116 citire 1024 octeți @ 65536
139 17.911762 (0.7400) sun.7b24 > svr4.nfs: 116 citiți 1024 octeți @ 73728

140 31.092136 (13.1804) sun.7b23 > svr4.nfs: 116 citire 1024 octeți @ 65536
141 31.831432 (0.7393) sun.7b24 > svr4.nfs: 116 citiți 1024 octeți @ 73728

142 51.090854 (19.2594) sun.7b23 > svr4.nfs: 116 citire 1024 octeți @ 65536
143 51.830939 (0.7401) sun.7b24 > svr4.nfs: 116 citiți 1024 octeți @ 73728

144 71.090305 (19.2594) sun.7b23 > svr4.nfs: 116 citire 1024 octeți @ 65536
145 71.830155 (0.7398) sun.7b24 > svr4.nfs: 116 citiți 1024 octeți @ 73728

Retransmisii

167 291.824285 (0.7400) sun.7b24 > svr4.nfs: 116 citiți 1024 octeți @ 73728
168 311.083676 (19.2594) sun.7b23 > svr4.nfs: 116 citire 1024 octeți @ 65536

Serverul a fost repornit

169 311.149476 (0.0658) arp cine-are soare spune svr4
170 311.150004 (0.0005) arp răspuns soarele este la 8:0:20:3:f6:42

171 311.154852 (0.0048) svr4.nfs > sun.7b23: raspunde ok 1124

172 311.156671 (0.0018) sun.7b25 > svr4.nfs: 116 citire 1024 octeți @ 66560
173 311.168926 (0.0123) svr4.nfs > sun.7b25: raspunde ok 1124
citind

Figura 29.9 Clientul citește un fișier atunci când serverul NFS se blochează și repornește.

Aplicația client nu va ști niciodată că serverul s-a prăbușit și a repornit, cu excepția faptului că a existat o pauză de 5 minute între liniile 129 și 171, astfel încât blocarea serverului este transparentă pentru client.

Pentru a estima durata timpului de retransmisie din acest exemplu, imaginați-vă că există doi daemoni client, fiecare cu propriile timeout-uri. Intervalele pentru primul demon (citirea de la offset 65536) sunt aproximativ după cum urmează (rotunjit la două zecimale): 0,68; 0,87; 1,74; 3,48; 6,96; 13,92; 20,0; 20,0; 20.0 și așa mai departe. Intervalele pentru cel de-al doilea demon (citirea de la offset 73728) sunt exact aceleași. Aceasta înseamnă că acești clienți NFS folosesc timeout-uri care sunt multipli de 0,875 secunde, cu o limită superioară de 20 de secunde. După fiecare timeout, intervalul de retransmisie se dublează: 0,875; 1,75; 3,5; 7.0 și 14.0.

Cât timp va dura clientului să facă retransmisii? Clientul are două opțiuni care pot afecta acest lucru. În primul rând, dacă sistemul de fișiere al serverului este montat greu, clientul va retransmite pentru totdeauna, dar dacă sistemul de fișiere al serverului este montat soft, clientul nu va mai încerca după un număr fix de retransmisii. De asemenea, în cazul unui hard mount, clientul are opțiunea de a permite utilizatorului să anuleze retransmisiile eșuate sau să nu anuleze. Dacă, la montarea sistemului de fișiere al serverului, gazda clientului indică faptul că acesta poate fi întrerupt și dacă nu dorim să așteptăm 5 minute ca serverul să se repornească după crash, putem introduce un simbol de întrerupere pentru a termina aplicația client.

Mai multe proceduri identice

Procedurile RPC pot fi executate de server de mai multe ori, dar totuși returnează același rezultat. De exemplu, procedura de citire NFS. După cum am văzut în Figura 29.9, clientul pur și simplu reemite apelul READ atâta timp cât primește un răspuns. În exemplul nostru, motivul retransmisiei a fost faptul că serverul era oprit. Dacă serverul nu a eșuat și mesajele care conțin răspunsuri RPC s-au pierdut (deoarece UDP este un protocol nesigur), clientul pur și simplu retransmite și serverul face din nou același READ. Aceeași parte a aceluiași fișier este citită din nou și trimisă clientului.

Acest lucru funcționează deoarece fiecare cerere de citire READ conține un offset de pornire. Dacă procedura NFS ar cere serverului să citească următorii N octeți ai fișierului, nu ar funcționa. Dacă serverul nu ar fi indiferent (acesta este opusul indiferentului) și răspunsul a fost pierdut și clientul a reemis READ pentru următorii N octeți, rezultatul ar fi diferit. Acesta este motivul pentru care procedurile NFS READ și WRITE au un offset de pornire. Clientul este cel care menține starea (offset-ul curent pentru fiecare fișier), nu serverul.

Din păcate, nu toate operațiunile sistemului de fișiere pot fi efectuate de mai multe ori. De exemplu, imaginați-vă următorii pași: clientul NFS emite o solicitare REMOVE pentru a elimina un fișier; Serverul NFS șterge fișierul și răspunde OK; răspunsul serverului a fost pierdut; Clientul NFS expiră și retransmite cererea; Serverul NFS nu poate găsi fișierul și returnează o eroare; Aplicația client primește o eroare care spune că fișierul nu există. Această eroare este returnată aplicației client și această eroare conține informații incorecte - fișierul nu a existat și a fost șters.

Mai jos este o listă de proceduri NFS care pot fi executate de mai multe ori: GETATTR, STATFS, LOOKUP, READ, WRITE, READLINK și READDIR. Proceduri care nu pot fi executate de mai multe ori: CREATE, REMOVE, RENAME, LINK, SYMLINK, MKDIR și RMDIR. SETATTR este de obicei executat de mai multe ori, cu excepția cazului în care a fost folosit pentru a trunchia un fișier.

Deoarece răspunsurile orfane sunt întotdeauna probabil să apară atunci când se utilizează UDP, serverele NFS trebuie să aibă o modalitate de a gestiona operațiuni care nu pot fi efectuate de mai multe ori. Majoritatea serverelor au un cache de răspuns recent în care stochează cele mai recente răspunsuri primite pentru astfel de operațiuni. De fiecare dată când serverul primește o solicitare, mai întâi se uită prin cache-ul său și, dacă se găsește o potrivire, returnează răspunsul anterior, în loc să apeleze din nou procedura NFS. [Juszczak 1989] descrie detaliile acestor tipuri de cache.

Această abordare a procedurilor serverului se aplică tuturor aplicațiilor bazate pe UDP, nu doar NFS. DNS, de exemplu, oferă un serviciu care poate fi folosit de mai multe ori fără durere. Serverul DNS poate interoga analizatorul de orice număr de ori, ceea ce nu va duce la rezultate negative (poate, cu excepția faptului că resursele de rețea vor fi ocupate).

NFS versiunea 3

În 1994, au fost lansate specificațiile pentru versiunea 3 a protocolului NFS [Sun Microsystems 1993]. Se preconizează că implementările vor deveni disponibile în cursul anului 1994.

Iată o scurtă prezentare a principalelor diferențe dintre versiunile 2 și 3. Le vom numi V2 și V3.

Descriptorii de fișiere din V2 sunt o matrice de dimensiune fixă de 32 de octeți. În V3 este o matrice de dimensiune variabilă cu o dimensiune de până la 64 de octeți. O matrice cu lungime variabilă în XDR este definită de un numărător de 4 octeți urmat de octeți reali. Acest lucru reduce dimensiunea descriptorului de fișier în implementări precum Unix, unde sunt necesari doar aproximativ 12 octeți, dar permite implementărilor non-Unix să schimbe informații suplimentare.
V2 limitează numărul de octeți per procedură RPC READ sau WRITE la 8192 de octeți. Această limitare nu se aplică în V3, ceea ce înseamnă, la rândul său, că folosind UDP limita va fi doar dimensiunea datagramei IP (65535 octeți). Acest lucru permite utilizarea pachetelor mari pentru citirea și scrierea în rețele rapide.
Dimensiunile fișierelor și decalajele de octeți de pornire pentru procedurile de CITIRE și SCRIERE au fost extinse de la 32 la 64 de biți, permițând gestionarea dimensiunilor mai mari ale fișierelor.
Atributele fișierului sunt returnate în fiecare apel care poate afecta atributele. Acest lucru reduce numărul de apeluri GETATTR solicitate de client.
Scrierile (WRITE) pot fi asincrone, în timp ce în V2 trebuiau să fie sincrone.
A fost eliminată o procedură (STATFS) și au fost adăugate șapte: ACCESS (verificați permisiunile fișierelor), MKNOD (creați un fișier special Unix), READDIRPLUS (returnează numele fișierelor dintr-un director împreună cu atributele acestora), FSINFO (returnează informații statistice despre sistemul de fișiere), FSSTAT (returnează informații despre sistemul de fișiere dinamic), PATHCONF (returnează informații despre fișierul POSIX.1) și COMMIT (commite scrieri asincrone făcute anterior pe stocarea persistentă).

Scurte concluzii

RPC este o modalitate de a construi o aplicație client-server în așa fel încât clientul să apeleze pur și simplu proceduri de pe server. Toate detaliile rețelei sunt ascunse în stub-urile client și server, care sunt generate pentru aplicații de pachetul RPC și în rutinele bibliotecii RPC. Am arătat formatul mesajelor de apel și răspuns RPC și am menționat că XDR este folosit pentru a codifica valori, permițând clienților și serverelor RPC să ruleze pe diferite arhitecturi de mașini.

Una dintre cele mai utilizate aplicații RPC este Sun NFS, un protocol eterogen de acces la fișiere care este utilizat pe scară largă pe gazde de aproape toate dimensiunile. Ne-am uitat la NFS și cum folosește UDP sau TCP. Protocolul NFS Versiunea 2 definește 15 proceduri.

Accesul clientului la un server NFS începe cu un protocol de montare, după care un handle de fișier este returnat clientului. Clientul poate accesa apoi fișierele de pe sistemul de fișiere al serverului folosind acest handle de fișier. Numele fișierelor sunt căutate pe server câte un element de nume, returnând un nou handle de fișier pentru fiecare element. Rezultatul final este un handle pentru fișierul care a fost accesat și care este folosit pentru citiri și scrieri secvențiale.

NFS încearcă să facă toate procedurile sale independente de numărul de execuții, astfel încât clientul să poată pur și simplu reemite cererea dacă răspunsul este pierdut. Am văzut exemple în acest sens în care un client citea un fișier în timp ce serverul s-a prăbușit și a repornit.

Exerciții

În Figura 29.7, am văzut că tcpdump interpretează pachetele ca cereri și răspunsuri NFS și tipărește XID-ul. Poate tcpdump să facă acest lucru pentru orice cereri sau răspunsuri RPC?

De ce crezi că programul server RPC de pe sistemele Unix folosește mai degrabă porturi alocate dinamic decât cele precunoscute?

Clientul RPC a apelat două proceduri de server. Prima procedură a durat 5 secunde, iar a doua - 1 secundă. Clientul are un timeout de 4 secunde. Desenați o diagramă de timp a ceea ce este schimbat între client și server. (Imaginați-vă că nu a fost petrecut timp pentru a transmite un mesaj de la client la server și invers.)

În exemplul din Figura 29.9, ce s-ar întâmpla dacă placa Ethernet a serverului NFS ar fi îndepărtată în timp ce serverul NFS a fost oprit?

Când serverul a repornit în Figura 29.9, a procesat cererea începând cu offset-ul 65536 (liniile 168 și 171), apoi a procesat următoarea cerere începând cu offset-ul 66560 (liniile 172 și 173). Ce se întâmplă cu interogarea care începe cu offset 73728 (linia 167)?

Când am descris proceduri independente de numărul de execuții NFS, am arătat un exemplu de răspuns REMOVE care a fost pierdut în rețea. Ce se întâmplă în acest caz dacă se folosește TCP în loc de UDP?

Dacă serverul NFS utilizează un port alocat dinamic în loc de portul 2049, ce se întâmplă cu clientul NFS atunci când serverul se blochează și repornește?

Există foarte, foarte puține numere de porturi rezervate (Capitolul 1, secțiunea „Numere de port”), cu maximum 1023 per gazdă. Dacă un server NFS solicită clienților săi porturi rezervate (ceea ce fac de obicei), iar un client NFS care utilizează TCP montează N sisteme de fișiere pe N servere diferite, este necesar ca clientul să aibă numere de porturi rezervate diferite pentru fiecare conexiune?

NFS, sau Network File System, este un protocol de sistem de fișiere de rețea popular, care permite utilizatorilor să monteze directoare de rețea la distanță pe mașina lor și să transfere fișiere între servere. Puteți utiliza spațiul pe disc de pe o altă mașină pentru fișierele dvs. și puteți lucra cu fișiere aflate pe alte servere. În esență, aceasta este o alternativă la partajarea Windows pentru Linux, spre deosebire de Samba, este implementată la nivel de kernel și funcționează mai stabil.

Acest articol va acoperi instalarea nfs pe Ubuntu 16.04. Ne vom uita la instalarea tuturor componentelor necesare, la configurarea unui folder partajat și la conectarea folderelor de rețea.

După cum am menționat deja, NFS este un sistem de fișiere de rețea. Pentru a funcționa, aveți nevoie de un server care va găzdui folderul partajat și clienți care pot monta folderul de rețea ca un disc obișnuit în sistem. Spre deosebire de alte protocoale, NFS oferă acces transparent la fișierele de la distanță. Programele vor vedea fișierele ca într-un sistem de fișiere obișnuit și vor lucra cu ele ca și cu fișierele locale, nfs returnează doar partea solicitată a fișierului, în loc de întregul fișier, astfel încât acest sistem de fișiere va funcționa perfect pe sisteme cu Internet rapid sau pe o retea locala.

Instalarea componentelor NFS

Înainte de a putea lucra cu NFS, va trebui să instalăm mai multe programe. Pe mașina care va fi serverul, trebuie să instalați pachetul nfs-kernel-server, care va fi folosit pentru a deschide share-uri nfs în ubuntu 16.04. Pentru a face acest lucru, rulați:

sudo apt install nfs-kernel-server

Acum să verificăm dacă serverul a fost instalat corect. Serviciul NFS ascultă conexiunile atât pentru TCP, cât și pentru UDP pe portul 2049. Puteți vedea dacă aceste porturi sunt de fapt utilizate cu comanda:

rpcinfo -p | grep nfs

De asemenea, este important să verificați dacă NFS este acceptat la nivel de kernel:

cat /proc/sisteme de fișiere | grep nfs

Vedem că funcționează, dar dacă nu, trebuie să încărcați manual modulul kernel nfs:

Să adăugăm și nfs la pornire:

sudo systemctl enable nfs

Trebuie să instalați pachetul nfs-common pe computerul client pentru a putea lucra cu acest sistem de fișiere. Nu trebuie să instalați componentele serverului, doar acest pachet va fi suficient:

sudo apt install nfs-common

Configurarea unui server NFS pe Ubuntu

Putem deschide accesul NFS la orice folder, dar haideți să creăm unul nou în acest scop:

client folder_address (opțiuni)

Adresa folderului este folderul care trebuie să fie accesibil prin rețea. Client - adresa IP sau adresa de rețea din care poate fi accesat acest folder. Dar cu opțiuni este puțin mai complicat. Să ne uităm la unele dintre ele:

rw- permite citirea și scrierea în acest folder
ro- permite numai citire
sincronizare- răspunde la următoarele solicitări numai atunci când datele sunt salvate pe disc (implicit)
asincron- nu blocați conexiunile în timp ce datele sunt scrise pe disc
sigur- utilizați numai porturi sub 1024 pentru conectare
nesigur- utilizați orice porturi
nohide- nu ascundeți subdirectoare când deschideți accesul la mai multe directoare
rădăcină_dovleac- înlocuiți cererile de la root cu altele anonime
all_squash- transformați toate cererile în anonimat
anonuidȘi anongid- specifică uid-ul și gid-ul pentru utilizatorul anonim.

De exemplu, pentru folderul nostru, această linie ar putea arăta astfel:

/var/nfs 127.0.0.1(rw,sync,no_subtree_check)

Odată ce totul a fost configurat, tot ce a rămas a fost actualizarea tabelului de export NFS:

sudo exportfs -a

Asta e tot, deschiderea acțiunilor nfs în ubuntu 16.04 este finalizată. Acum să încercăm să configuram clientul și să încercăm să-l montem.

conexiune NFS

Nu ne vom opri asupra acestei probleme în detaliu în articolul de astăzi. Acesta este un subiect destul de amplu care merită propriul articol. Dar tot voi spune câteva cuvinte.

Pentru a monta un folder de rețea, nu aveți nevoie de niciun client Ubuntu nfs, trebuie doar să utilizați comanda mount:

sudo mount 127.0.0.1:/var/nfs/ /mnt/

Acum puteți încerca să creați un fișier în directorul conectat:

Ne vom uita, de asemenea, la sistemele de fișiere montate folosind df:

127.0.0.1:/var/nfs 30G 6.7G 22G 24% /mnt

Pentru a dezactiva acest sistem de fișiere, trebuie doar să utilizați umountul standard:

sudo umount /mnt/

concluzii

Acest articol a discutat despre configurarea nfs ubuntu 16.04, după cum puteți vedea, totul se face foarte simplu și transparent. Conectarea partajărilor NFS se face în câteva clicuri folosind comenzi standard, iar deschiderea partajărilor NFS în ubuntu 16.04 nu este mult mai complicată decât conectarea. Dacă aveți întrebări, scrieți în comentarii!

Postări asemănatoare:

Protocolul Network File Server (NFS) este un standard deschis pentru furnizarea accesului utilizatorilor de la distanță la sistemele de fișiere. Sistemele de fișiere centralizate construite pe acesta facilitează activitățile de zi cu zi, cum ar fi backup-urile sau scanările de viruși, iar partițiile consolidate ale discurilor sunt mai ușor de întreținut decât multe dintre cele mai mici, distribuite.

Pe lângă furnizarea de stocare centralizată, NFS s-a dovedit a fi foarte util pentru alte aplicații, inclusiv pentru clienții fără disc și thin, clustering de rețea și colaborarea middleware.

O mai bună înțelegere atât a protocolului în sine, cât și a detaliilor implementării acestuia va face mai ușor să faceți față problemelor practice. Acest articol este dedicat NFS și constă din două părți logice: mai întâi, descrie protocolul în sine și obiectivele stabilite în timpul dezvoltării sale, iar apoi implementarea NFS în Solaris și UNIX.

UNDE A ÎNCEPUT TOTUL...

Protocolul NFS a fost dezvoltat de Sun Microsystems și a apărut pe Internet în 1989 ca RFC 1094 sub următorul nume: Network File System Protocol Specification (NFS). Este interesant de remarcat faptul că strategia Novell la acea vreme viza îmbunătățirea în continuare a serviciilor de fișiere. Până de curând, înainte de a decola mișcarea open source, Sun a fost reticent în a împărtăși secretele soluțiilor sale de rețea, dar chiar și atunci compania a înțeles importanța interoperabilității cu alte sisteme.

RFC 1094 conținea două specificații originale. Până la data publicării sale, Sun dezvolta deja următoarea, a treia versiune a specificației, care este stabilită în RFC 1813 „NFS Version 3 Protocol Specification”. Versiunea 4 a acestui protocol este definită în RFC 3010, NFS Version 4 Protocol.

NFS este utilizat pe scară largă pe toate tipurile de gazde UNIX, pe rețelele Microsoft și Novell și pe soluții IBM, cum ar fi AS400 și OS/390. Deși necunoscut în afara regnului rețelelor, NFS este probabil cel mai răspândit sistem de fișiere de rețea independent de platformă.

UNIX A FOST GENEZA

Deși NFS este un sistem independent de platformă, strămoșul său este UNIX. Cu alte cuvinte, arhitectura ierarhică și metodele de acces la fișiere ale arhitecturii, inclusiv structura sistemului de fișiere, modalitățile de identificare a utilizatorilor și a grupurilor și tehnicile de gestionare a fișierelor, sunt toate foarte asemănătoare cu sistemul de fișiere UNIX. De exemplu, sistemul de fișiere NFS, fiind structural identic cu sistemul de fișiere UNIX, este montat direct pe acesta. Când lucrați cu NFS pe alte sisteme de operare, parametrii de identificare a utilizatorului și drepturile de acces la fișiere sunt supuse maparii.

NFS

NFS este conceput pentru a fi utilizat într-o arhitectură client-server. Clientul accesează sistemul de fișiere exportat de serverul NFS printr-un punct de montare pe client. Acest acces este de obicei transparent pentru aplicația client.

Spre deosebire de multe sisteme client-server, NFS utilizează Remote Procedure Calls (RPC) pentru a face schimb de informații. De obicei, clientul stabilește o conexiune la un port cunoscut și apoi, în conformitate cu protocolul, trimite o solicitare pentru a efectua o anumită acțiune. În cazul apelurilor de procedură la distanță, clientul creează un apel de procedură și apoi îl trimite către server pentru execuție. O descriere detaliată a NFS va fi prezentată mai jos.

De exemplu, să presupunem că un client a montat directorul usr2 pe sistemul de fișiere rădăcină local:

/root/usr2/ -> remote:/root/usr/

Dacă o aplicație client are nevoie de resurse din acest director, pur și simplu trimite o cerere către sistemul de operare pentru aceasta și numele fișierului, care acordă acces prin clientul NFS. Ca exemplu, luați în considerare comanda simplă UNIX cd, care „nu știe nimic” despre protocoalele de rețea. Echipă

Cd /root/usr2/

va plasa directorul de lucru pe un sistem de fișiere la distanță, „fără să-și dea seama” (de asemenea, utilizatorul nu are nevoie de acest lucru) că sistemul de fișiere este la distanță.

După ce a primit cererea, serverul NFS va verifica dacă utilizatorul are dreptul de a efectua acțiunea solicitată și, dacă răspunsul este pozitiv, o va efectua.

SĂ CUNOAȘM MAI BINE

Din punctul de vedere al clientului, procesul de montare locală a unui sistem de fișiere la distanță folosind NFS constă din mai mulți pași. După cum sa menționat, clientul NFS va emite un apel de procedură de la distanță pentru a-l executa pe server. Rețineți că în UNIX, clientul este un singur program (comanda mount), în timp ce serverul este implementat ca mai multe programe cu următorul set minim: un serviciu de cartografiere de porturi, un demon de montare și un server NFS.

Comanda client mount comunică mai întâi cu serviciul de traducere a portului al serverului, care ascultă cererile pe portul 111. Cele mai multe implementări ale comenzii client mount acceptă versiuni multiple de NFS, ceea ce crește probabilitatea de a găsi o versiune de protocol comun pentru client și server. Căutarea se efectuează începând cu cea mai înaltă versiune, astfel încât atunci când se găsește una comună, aceasta va deveni automat cea mai nouă versiune suportată de client și server.

(Materialul prezentat este axat pe a treia versiune a NFS, deoarece este cea mai răspândită în acest moment. A patra versiune nu este încă susținută de majoritatea implementărilor.)

Serviciul de traducere porturi al serverului răspunde solicitărilor pe baza protocolului acceptat și a portului pe care rulează demonul de montare. Programul client de montare stabilește mai întâi o conexiune la demonul de montare al serverului și apoi îi lansează comanda de montare prin RPC. Dacă această procedură are succes, atunci aplicația client se conectează la serverul NFS (port 2049) și, folosind una dintre cele 20 de proceduri la distanță care sunt definite în RFC 1813 și enumerate în Tabelul 1, obține acces la sistemul de fișiere la distanță.

Semnificația majorității comenzilor este intuitivă și nu provoacă dificultăți administratorilor de sistem. Următoarea listă, obținută folosind tcdump, ilustrează comanda de citire produsă de comanda UNIX cat pentru a citi un fișier numit test-file:

10:30:16.012010 eth0 > 192.168.1.254.

3476097947 > 192.168.1.252.2049: 144 lookup fh 32.0/ 224145 "test-file" 10:30:16.012010 eth0 > 192.168.1.254.

3476097947 > 192.168.1.252.2049: 144 de căutare fh 32.0/ 224145 „fișier de testare” 10:30:16.012729 eth0 192.168.1.254.3476.254.3472.2002.2002 307 (DF) 10:30: 16.012729 eth0 192.168 .1.254.3476097947: răspuns ok 128 lookup fh 32.0/224307 (DF) 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 citiți fh 32.0/ 224307 4096 octeți @ 0 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 citiți fh 32.0/ 224307 4096 octeți @ 0 10:30:16.013650 eth0 192.168.1.254: rep. 81 DF 0:16.013650 eth0 192.168.1.254.3492875163 : răspuns ok 108 citit (DF)

NFS a fost implementat în mod tradițional prin UDP. Cu toate acestea, unele versiuni ale NFS acceptă TCP (suportul TCP este definit în specificația protocolului). Principalul avantaj al TCP este un mecanism de retransmisie mai eficient în rețelele nesigure. (Cu UDP, dacă apare o eroare, mesajul RPC complet, constând din mai multe pachete UDP, este retrimis. Cu TCP, numai fragmentul rupt este retrimis.)

Prima metodă se bazează pe sistemul încorporat UNIX de permisiuni de fișiere pentru un utilizator individual sau un grup. Pentru a simplifica întreținerea, identificarea utilizatorilor și a grupului ar trebui să fie consecventă pe toți clienții și serverele NFS. Securitatea trebuie luată în considerare cu atenție: NFS poate oferi din neatenție acces la fișiere care nu au fost destinate când au fost create.

Accesul la nivel de partajare vă permite să restricționați drepturile pentru a permite numai anumite acțiuni, indiferent de proprietatea fișierului sau privilegiile UNIX. De exemplu, lucrul cu sistemul de fișiere NFS poate fi limitat la doar citire. Majoritatea implementărilor NFS vă permit să restricționați și mai mult accesul la nivel de resurse partajate la anumiți utilizatori și/sau grupuri. De exemplu, grupului de Resurse Umane i se permite să vizualizeze informații și nimic mai mult.

Accesul la nodul principal vă permite să montați un sistem de fișiere numai pe anumite noduri, ceea ce este, în general, o idee bună, deoarece sistemele de fișiere pot fi create cu ușurință pe orice nod compatibil NFS.

Accesul combinat combină pur și simplu tipurile de mai sus (de exemplu, acces la nivel partajat cu acces acordat unui anumit utilizator) sau permite utilizatorilor să acceseze NFS numai de la un anumit nod.

NFS ÎN STIL PINGUIN

Materialul legat de Linux se bazează pe Red Hat 6.2 cu versiunea de nucleu 2.4.9, care este livrat cu versiunea nfs-utils 0.1.6. Există și versiuni mai noi: la momentul scrierii, cea mai recentă actualizare a pachetului nfs-utils este 0.3.1. Poate fi descărcat de pe: .

Pachetul nfs-utils conține următoarele executabile: exportfs, lockd, mountd, nfsd, nfsstat, nhfsstone, rquotad, showmount și statd.

Din păcate, suportul NFS este uneori o sursă de confuzie pentru administratorii Linux, deoarece disponibilitatea unei anumite caracteristici depinde direct de numerele de versiune ale nucleului și ale pachetului nfs-utils. Din fericire, lucrurile se îmbunătățesc în acest domeniu, cele mai recente distribuții incluzând cele mai recente versiuni ale ambelor. Pentru versiunile anterioare, Secțiunea 2.4 din NFS-HOWTO oferă o listă completă de funcționalități de sistem disponibile pentru fiecare nucleu și combinație de pachet nfs-utils. Dezvoltatorii mențin compatibilitatea inversă a pachetului cu versiunile anterioare, acordând multă atenție asigurării securității și eliminării erorilor software.

Suportul NFS ar trebui să fie inițiat în timpul compilării nucleului. Dacă este necesar, capacitatea de a lucra cu NFS versiunea 3 ar trebui adăugată la kernel.

Pentru distribuțiile care acceptă linuxconf, este ușor să configurați serviciile NFS atât pentru clienți, cât și pentru servere. Cu toate acestea, modalitatea rapidă de a instala NFS folosind linuxconf nu oferă informații despre ce fișiere au fost create sau editate, ceea ce este foarte important pentru administrator să cunoască situația în cazul unei defecțiuni a sistemului. Arhitectura NFS pe Linux este cuplată la versiunea BSD, astfel încât fișierele și programele necesare sunt ușor de găsit pentru administratorii care rulează BSD, Sun OS 2.5 sau versiuni anterioare ale NFS.

Fișierul /etc/exports, ca și în versiunile anterioare ale BSD, definește sistemele de fișiere pe care clienții NFS au voie să le acceseze. În plus, conține o serie de caracteristici suplimentare legate de probleme de management și securitate, oferind administratorului un mijloc de reglare fină. Acesta este un fișier text format din intrări, rânduri goale sau comentate (comentariile încep cu simbolul #).

Să presupunem că vrem să oferim clienților acces numai în citire la directorul /home de pe nodul Lefty. Aceasta ar corespunde următoarei intrări din /etc/exports:

/home (ro)

Aici trebuie să spunem sistemului ce directoare vom face accesibile utilizând demonul de montare rpc.mountd:

# exportfs -r exportfs: Nu este specificat niciun nume de gazdă în /home (ro), introduceți *(ro) pentru a evita avertismentul #

Când este rulată, comanda exportfs emite un avertisment că /etc/exports nu restricționează accesul la un anumit nod și creează o intrare corespunzătoare în /var/lib/nfs/etab din /etc/exports care spune ce resurse pot fi vizualizate folosind cat :

# cat /var/lib/nfs/etab /home (ro,async,wdelay,hide,secure,root_squash, no_all_squash,subtree_check, secure_locks, mapping=identity,anonuid=-2,anongid=-2)

Alte opțiuni enumerate în etab includ valorile implicite utilizate de NFS. Detaliile vor fi descrise mai jos. Pentru a oferi acces la directorul /home, trebuie să porniți serviciile NFS corespunzătoare:

# portmap # rpc.mountd # rpc.nfsd # rpc.statd # rpc.rquotad

În orice moment după pornirea demonului de montare (rpc.mountd), puteți vizualiza fișierele individuale disponibile pentru ieșire, vizualizând conținutul fișierului /proc/fs/nfs/exports:

# cat /proc/fs/nfs/exports # Versiunea 1.0 # Path Client(Flags) # IP-uri /home 192.168.1.252(ro,root_squash,async, wdelay) # 192.168.1.252 #

Același lucru poate fi vizualizat folosind comanda showmount cu parametrul -e:

# showmount -e Exportați lista pentru stângaci: /home (toți) #

Având un pic înainte, comanda showmount poate fi folosită și pentru a determina toate sistemele de fișiere montate sau, cu alte cuvinte, pentru a afla care noduri sunt clienți NFS pentru sistemul care rulează comanda showmount. Comanda showmount -a va lista toate punctele de montare client:

# showmount -a Toate punctele de montare pe stânga: 192.168.1.252:/home #

După cum sa menționat mai sus, majoritatea implementărilor NFS acceptă diferite versiuni ale acestui protocol. Implementarea Linux vă permite să limitați lista de versiuni NFS care pot fi lansate prin specificarea comutatorului -N pentru demonul de montare. De exemplu, pentru a rula NFS versiunea 3 și numai versiunea 3, introduceți următoarea comandă:

# rpc.mountd -N 1 -N 2

Utilizatorii frecvenți pot considera incomod ca demonul NFS al Linux (rpc.nfsd) să aștepte pachetele versiunii 1 și 2, deși acest lucru are efectul dorit de a nu suporta protocolul corespunzător. Să sperăm că dezvoltatorii versiunilor viitoare vor face corecțiile necesare și vor putea obține o mai mare consistență între componentele pachetului în raport cu diferite versiuni ale protocolului.

„ÎNOT CU PINGUINI”

Accesul la Lefty configurat mai sus, un sistem de fișiere exportabil NFS bazat pe Linux, depinde de sistemul de operare client. Stilul de instalare pentru majoritatea sistemelor de operare din familia UNIX este același cu cel al sistemelor Sun OS și BSD originale sau al celui mai nou Solaris. Deoarece acest articol este despre Linux și Solaris, să ne uităm la configurația clientului Solaris 2.6 din punctul de vedere al stabilirii unei conexiuni cu versiunea Linux a NFS pe care am descris-o mai sus.

Datorită caracteristicilor moștenite de la Solaris 2.6, acesta poate fi ușor configurat pentru a acționa ca client NFS. Aceasta necesită o singură comandă:

# mount -F nfs 192.168.1.254:/home /tmp/tmp2

Presupunând că comanda de montare anterioară a avut succes, atunci comanda de montare fără parametri va scoate următoarele:

# mount / on /dev/dsk/c0t0d0s0 read/write/setuid/ largefiles on Mon Sep 3 10:17:56 2001 ... ... /tmp/tmp2 on 192.168.1.254:/home read/ write/remote on Luni, 3 septembrie 23:19:25 2001

Să analizăm ieșirea tcpdump primită pe nodul Lefty după ce utilizatorul a lansat comanda ls /tmp/tmp2 pe nodul Sunny:

# tcpdump gazdă lefty și gazdă sunny -s512 06:07:43.490583 sunny.2191983953 > lefty.mcwrite.n.nfs: 128 getattr fh Necunoscut/1 (DF) 06:07:43.490678 lefty.nnny.mcwrite > 2191983953: raspuns ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:07:43.491397 sunny.2191983954 > lefty.mcwrite.n.nfs: fh 13/20:00 43,491463 stângaci. mcwrite.n.nfs > sunny.2191983954: răspuns ok 120 acces c0001 (DF) 06:07:43.492296 sunny.2191983955 > lefty.mcwrite.n.nfs: 152 readdirplus/fh 07008/167008. 00000 (DF) 06 :07:43.492417 lefty.mcwrite.n.nfs > sunny.2191983955: răspuns ok 1000 readdirplus (DF)

Vedem că nodul Sunny solicită un handle de fișier (fh) pentru ls, la care nodul Lefty răspunde cu OK și returnează structura directorului. Sunny verifică apoi permisiunea de a accesa conținutul directorului (132 access fh) și primește un răspuns de permisiune de la Lefty. Nodul Sunny citește apoi întregul conținut al directorului folosind rutina readdirplus. Apelurile de procedură de la distanță sunt descrise în RFC 1813 și sunt enumerate la începutul acestui articol.

Deși secvența de comandă pentru accesarea sistemelor de fișiere de la distanță este foarte simplă, o serie de circumstanțe pot face ca sistemul să se monteze incorect. Înainte de a monta un director, punctul de montare trebuie să existe deja, altfel trebuie creat folosind comanda mkdir. De obicei, singura cauză a erorilor din partea clientului este lipsa unui director de montare local. Cele mai multe probleme asociate cu NFS se datorează unei nepotriviri între client și server sau configurării incorecte a serverului.

Cel mai simplu mod de a depana problemele pe un server este de la nodul pe care rulează serverul. Cu toate acestea, atunci când altcineva administrează serverul pentru tine, acest lucru nu este întotdeauna posibil. O modalitate rapidă de a vă asigura că serviciile de server corespunzătoare sunt configurate corect este să utilizați comanda rpcinfo cu opțiunea -p. Din gazda Solaris Sunny, puteți determina ce procese RPC sunt înregistrate pe gazda Linux:

# rpcinfo -p 192.168.1.254 program vers proto port service 100000 2 tcp 111 rpcbind 100000 2 udp 111 rpcbind 100024 1 udp 692 status 100024 1904 100024 100024 udp mount d /100005 3 tcp 1024 mountd 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100021 1 udp 1026 nlockmgr 100021 3 udp 1026 nlockmgr 100021 4 udp 1026 nlockmgr #

Rețineți că aici sunt furnizate și informații despre versiune, ceea ce este destul de util atunci când sistemul necesită suport pentru diferite protocoale NFS. Dacă vreun serviciu nu rulează pe server, atunci această situație trebuie corectată. Dacă montarea eșuează, următoarea comandă rpcinfo -p vă va ajuta să determinați că serviciul mountd de pe server nu rulează:

# rpcinfo -p 192.168.1.254 program vers proto port service 100000 2 tcp 111 rpcbind ... ... 100021 4 udp 1026 nlockmgr #

Comanda rpcinfo este foarte utilă pentru a afla dacă un anumit proces de la distanță este activ. Parametrul -p este cel mai important dintre comutatoare. Pentru a vedea toate caracteristicile rpcinfo, consultați pagina de manual.

Un alt instrument util este comanda nfsstat. Cu ajutorul acestuia, puteți afla dacă clienții accesează efectiv sistemul de fișiere exportat și, de asemenea, puteți afișa informații statistice în conformitate cu versiunea protocolului.

În cele din urmă, un alt instrument destul de util pentru a determina cauzele defecțiunilor sistemului este tcpdump:

# tcpdump gazdă lefty și gazdă sunny -s512 tcpdump: ascultare pe eth0 06:29:51.773646 sunny.2191984020 > lefty.mcwrite.n.nfs: 140 căutare fh Necunoscut/1"test.c" (DF): 581:7293:58. lefty.mcwrite.n.nfs > sunny.2191984020: răspuns ok 116 căutare EROARE: Nu există un astfel de fișier sau director (DF) 06:29:51.774593 sunny.2191984021 > lefty.mcwrite.n.nfs: 128 Unknown getattr (fh28) DF) 06:29:51.774670 lefty.mcwrite.n.nfs > sunny.2191984021: răspuns ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06.775:2891 lefty > sunny. mcwrite.n.nfs : 140 căutare fh Unknown/1"test.c" (DF) 06:29:51.775357 lefty.mcwrite.n.nfs > sunny.2191984022: răspuns ok 116 căutare EROARE: Nu există un astfel de fișier sau director (DF) 06:29: 51.776029 sunny.2191984023 > lefty.mcwrite.n.nfs: 184 create fh Unknown/1 "test.c" (DF) 06:29:51.776169 lefty.mcwrite.n.nfs > sunny.21931984 ERROR create ok: ERROR Permisiune refuzată (DF)

Lista de mai sus, produsă prin executarea instrucțiunii touch test.c, arată următoarea secvență de acțiuni: mai întâi comanda touch încearcă să acceseze un fișier numit test.c, apoi caută un director cu același nume și după încercări nereușite încearcă să creeze un fișier test.c , care, de asemenea, nu duce la succes.

Dacă sistemul de fișiere este montat, cele mai frecvente erori sunt legate de permisiunile UNIX normale. Utilizarea unui uid sau NIS+ pe Sun vă ajută să evitați setarea globală a permisiunilor pentru toate sistemele de fișiere. Unii administratori practică directoare „deschise”, unde accesul de citire este dat „întregii lumi”. Cu toate acestea, acest lucru ar trebui evitat din motive de siguranță. Pe lângă preocupările de securitate, această abordare este încă o practică proastă, deoarece utilizatorii rareori creează date cu intenția de a le face lizibile de către toată lumea.

Accesul unui utilizator privilegiat (rădăcină) la sistemele de fișiere NFS montate este tratat diferit. Pentru a evita acordarea unui utilizator privilegiat acces nelimitat, cererile de la utilizatorul privilegiat sunt tratate ca și cum ar veni de la utilizatorul nimeni. Acest mecanism puternic limitează accesul utilizatorilor privilegiați la fișiere care pot fi citite și inscriptibile la nivel global.

VERSIUNEA SOLARIS SERVER NFS

Configurarea Solaris pentru a funcționa ca server NFS este la fel de ușoară ca și cu Linux. Cu toate acestea, comenzile și locațiile fișierelor sunt ușor diferite. Când Solaris pornește, la atingerea nivelului de rulare 3, serviciile NFS sunt pornite automat și toate sistemele de fișiere sunt exportate. Pentru a porni aceste procese manual, introduceți comanda:

#/usr/lib/nfs/mountd

Pentru a porni demonul de montare și serverul NFS, introduceți:

#/usr/lib/nfs/nfsd

Începând cu versiunea 2.6, Solaris nu mai utilizează un fișier de export pentru a specifica ce sisteme de fișiere să exporte. Fișierele sunt acum exportate folosind comanda share. Să presupunem că vrem să permitem gazdelor de la distanță să monteze /export/home. Pentru a face acest lucru, introduceți următoarea comandă:

Partajați -F nfs /export/home

Masuri de securitate

SECURITATE ÎN LINUX

Unele servicii de sistem NFS bazate pe Linux au un mecanism suplimentar pentru restricționarea accesului prin liste de control sau tabele. La nivel intern, acest mecanism este implementat folosind biblioteca tcp_wrapper, care folosește două fișiere pentru a genera liste de control acces: /etc/hosts.allow și /etc/hosts/deny. O privire de ansamblu cuprinzătoare a regulilor de lucru cu tcp_wrapper depășește scopul acestui articol, dar principiul de bază este următorul: comparația se face mai întâi cu etc/hosts.allow și apoi cu /etc/hosts. nega. Dacă regula nu este găsită, atunci serviciul de sistem solicitat nu este prezentat. Pentru a ocoli această ultimă cerință și pentru a oferi un nivel foarte ridicat de securitate, puteți adăuga următoarea intrare la sfârșitul /etc/hosts.deny:

TOȚI: Toate

După aceasta, puteți utiliza /etc/hosts.allow pentru a seta unul sau altul mod de operare. De exemplu, fișierul /etc/hosts. allow, pe care l-am folosit când am scris acest articol, conținea următoarele rânduri:

Lockd:192.168.1.0/255.255.255.0 mountd:192.168.1.0/255.255.255.0 portmap:192.168.1.0/255.255.255.0 rquotad:192.255.0525.255.0525. 1 68.1.0/255.255.255.0

Acest lucru permite un anumit tip de acces la gazde înainte de a acorda acces la nivel de aplicație. Pe Linux, accesul la nivel de aplicație este controlat de fișierul /etc/exports. Constă din intrări în următorul format:

Export director (spațiu) gazdă|rețea (opțiuni)

Un „director de export” este un director pentru care demonul nfsd îi este permis să proceseze cereri. Un „nod|rețea” este nodul sau rețeaua care are acces la sistemul de fișiere exportat, iar „opțiunile” definesc restricțiile pe care demonul nfsd le impune utilizării acestei resurse partajate - acces numai în citire sau mapare a ID-ului utilizatorului. .

Următorul exemplu oferă întregului domeniu mcwrite.net acces numai în citire la /home/mcwrite.net:

/home/mcwrite.net *.mcwrite.net(ro)

Mai multe exemple pot fi găsite în pagina de manual pentru exporturi.

SECURITATE NFS ÎN SOLARIS

În Solaris, capacitatea de a oferi acces la NFS este similară cu Linux, dar în acest caz, restricțiile sunt setate folosind anumiți parametri din comanda share cu comutatorul -o. Următorul exemplu arată cum să activați montarea numai în citire a /export/mcwrite.net pe orice gazdă din domeniul mcwrite.net:

#share -F nfs -o ro=.mcwrite.net/ export/ mcwrite.net

Pagina de manual pentru detaliile share_nfs care acordă acces folosind liste de control pe Solaris.

Resurse Internet

NFS și RPC nu sunt lipsite de găuri. În general, NFS nu ar trebui să fie folosit atunci când navigați pe internet. Nu puteți face găuri în firewall-uri pentru a permite orice fel de acces prin NFS. Urmăriți îndeaproape orice patch-uri RPC și NFS emergente, iar numeroase surse de informații de securitate vă pot ajuta. Cele mai populare două surse sunt Bugtraq și CERT:

Primul poate fi vizualizat regulat în căutarea informațiilor necesare sau prin abonarea la buletine informative periodice. Al doilea oferă, poate, informații nu la fel de prompte în comparație cu altele, dar într-un volum destul de complet și fără nuanța de senzaționalism caracteristică unor site-uri dedicate securității informaționale.

NFS: Sistem de fișiere de rețea. Configurarea și montarea NFS

O scurtă istorie a NFS

Arhitectura NFS

Figura 2. Implementarea modelului client-server în arhitectura NFS

Protocolul NFS

Inovație în NFS

Alternative NFS

Concluzie

Care este diferența?

Instalarea backend-ului NFS

Setări

Instalarea și configurarea părții client NFS

Ubuntu

Windows

Instalarea componentelor NFS

Configurarea unui server NFS pe Ubuntu

conexiune NFS

concluzii

UNDE A ÎNCEPUT TOTUL...

UNIX A FOST GENEZA

NFS

SĂ CUNOAȘM MAI BINE

NFS ÎN STIL PINGUIN

„ÎNOT CU PINGUINI”

VERSIUNEA SOLARIS SERVER NFS

Masuri de securitate

SECURITATE ÎN LINUX

TOȚI: Toate

SECURITATE NFS ÎN SOLARIS

Resurse Internet

Cele mai bune articole pe această temă