NFS este extras din ambele tipuri de sisteme de fișiere server și client și există multe implementări ale serverelor și clienților NFS pentru diferite sisteme de operare și arhitecturi hardware. Cea mai matură versiune de NFS este v.4, care acceptă diverse mijloace de autentificare (în special, Kerberos și LIPKEY folosind protocolul RPCSEC GSS) și liste de control al accesului (atât tipurile POSIX, cât și Windows).

Organizarea generală a NFS

NFS oferă clienților acces transparent la fișiere și la sistemul de fișiere al serverului. Spre deosebire de FTP, protocolul NFS accesează doar acele părți ale fișierului accesate de proces, iar principalul său avantaj este că face acest acces transparent. Aceasta înseamnă că orice aplicație client care poate funcționa cu un fișier local poate funcționa la fel de bine și cu un fișier NFS, fără nicio modificare a programului în sine.

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 utilizator obișnuite - și anume, clientul NFS poate fi un proces utilizator care face apeluri RPC specifice către server, care poate fi și un proces utilizator.

O parte importantă a celei mai recente versiuni a standardului NFS (v4.1) este specificația pNFS, care își propune să ofere o implementare paralelă a partajării fișierelor care crește rata de transfer de date proporțional cu dimensiunea și gradul de paralelism al sistemului.

Poveste

Protocolul NFS are 4 versiuni în istoria sa.

Prima versiune a fost folosită doar intern la Sun în scopuri experimentale. Versiunea 2 a fost lansată în martie 1989, rulând inițial în întregime pe UDP. Dezvoltatorii au ales să nu stocheze date interne de stare în interiorul protocolului, cum ar fi blocarea implementată în afara protocolului de bază. Persoanele implicate în crearea NFS versiunea 2 sunt Rusty Sandberg, Bob Lyon, Bill Joy și Steve Kleiman.

NFSv3 a fost lansat în iunie 1995, a adăugat suport pentru descriptori de fișiere de dimensiune variabilă de până la 64 de octeți (în versiunea 2 - o matrice de dimensiune fixă ​​de 32 de octeți), a eliminat limita de 8192 de octeți în apelurile de citire și scriere RPC (astfel, dimensiunea al blocului transmis în apeluri este limitat doar de limita de datagramă UDP - 65535 octeți), este implementat suportul pentru fișiere mari, sunt acceptate apeluri asincrone pentru operațiuni de scriere, ACCESS (verificarea drepturilor de acces la fișiere), MKNOD (crearea unui fișier Unix special) , apelurile READDIRPLUS sunt adăugate la procedurile READ și WRITE (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 dinamice despre sistemul de fișiere), PATHCONF ( returnează informații POSIX.1 despre fișier) și COMMIT (commite înregistrări asincrone făcute anterior pentru stocare permanentă). La momentul introducerii versiunii 3, a existat o creștere a popularității în rândul dezvoltatorilor de protocol TCP. Unii dezvoltatori independenți au adăugat în mod independent suport pentru TCP la NFS versiunea 2 ca transport, Sun Microsystems a adăugat suport TCP la NFS într-un addendum versiunea 3. Suportul TCP a sporit caracterul practic al utilizării NFS peste WAN.

NFSv4 a fost lansat în decembrie 2000, influențat de AFS și CIFS și include îmbunătățiri de performanță și securitate. Versiunea 4 a fost prima versiune dezvoltată în colaborare cu Internet Engineering Task Force (IETF). NFS v4.1 a fost aprobat de IESG în ianuarie 2010 (noua specificație, de 612 pagini, a devenit cunoscută drept cel mai lung document aprobat de IETF). O inovație importantă în versiunea 4.1 este specificația pNFS - Parallel NFS, un mecanism pentru accesul paralel al clientului NFS la datele de pe mai multe servere NFS distribuite. Prezența unui astfel de mecanism în standardul sistemului de fișiere de rețea va ajuta la construirea de sisteme de stocare și informații în cloud distribuite.

Obiective de dezvoltare

Cerințele inițiale pentru dezvoltarea NFS au fost:

• suport potențial pentru diverse sisteme de operare (nu doar UNIX), astfel încât serverele și clienții NFS să poată fi implementați pe sisteme de operare diferite;
• protocolul nu ar trebui să depindă de niciun hardware anume;
• ar trebui implementate mecanisme simple de recuperare în cazul defecțiunilor serverului sau clientului;
• aplicațiile ar trebui să aibă acces transparent la fișierele de la distanță fără utilizarea de căi sau biblioteci speciale și fără recompilare;
• pentru clienții UNIX, semantica UNIX trebuie să fie suportată;
• Performanța NFS ar trebui să fie comparabilă cu performanța unităților locale;
• implementarea nu ar trebui să fie dependentă de vehicule.

Cum funcționează NFS

NFS este construit din cel puțin două părți principale: un server și unul sau mai mulți clienți. Clientul accesează datele aflate pe server în modul de acces la distanță. Pentru ca acest lucru să funcționeze corect, mai multe procese trebuie să fie configurate și rulate. Implementarea NFS constă din mai multe componente. Unele dintre ele sunt localizate fie pe server, fie pe client, iar unele sunt utilizate pe ambele părți ale conexiunii. Unele componente nu sunt necesare pentru funcționalitatea de bază, dar fac parte din interfața NFS extinsă.

Protocolul NFS definește un set de cereri (operații) care pot fi trimise de un client către un server, precum și un set de argumente și valori returnate pentru fiecare dintre aceste solicitări. Versiunea 1 a acestui protocol a existat doar în intestinele Sun Microsystems și nu a fost niciodată lansată. Toate implementările NFS (inclusiv NFSv3) acceptă NFS versiunea 2 (NFSv2), care a fost lansată pentru prima dată în 1985 cu SunOS 2.0. Versiunea 3 a protocolului a fost publicată în 1993 și implementată de mai mulți furnizori.

Protocolul Remote Procedure Call (RPC) definește formatul tuturor interacțiunilor dintre un client și un server. Fiecare cerere NFS este trimisă ca pachet RPC. Următorii demoni rulează pe server:

• rpc.nfsd - Daemonul principal al serverului NFS este nfsd (uneori numit nfsd4 în versiunile mai noi). Acest demon servește cererile clientului NFS. Opțiunea RPCNFSDCOUNT din /etc/default/nfs-kernel-server pe Debian și NFSDCOUNT pe /etc/sysconfig/nfs pe RedHat determină numărul de demoni de pornit (implicit este 8). (programul RPC 100003)
• rpc.mountd - Daemonul NFS mountd gestionează cererile clientului de a monta directoare. Daemonul mountd rulează pe servere NFS. (programul RPC 100005)
• rpc.statd - Daemon de monitorizare a stării rețelei (alias Network Status Monitor, alias NSM). Vă permite să anulați corect blocarea după o blocare/repornire. Utilizează programul /usr/sbin/sm-notify pentru notificarea erorilor. Daemonul statd rulează atât pe servere, cât și pe clienți. Anterior, acest server era necesar pentru ca rpc.lockd să funcționeze, dar acum nucleul este responsabil pentru blocări. (Programul RPC 100021 și 100024 - în versiuni noi)
• rpc.lockd - Demonul de blocare lockd (alias NFS lock manager (NLM)) gestionează cererile de blocare a fișierelor. Daemonul de blocare rulează atât pe servere, cât și pe clienți. Clienții solicită o blocare a fișierelor, iar serverele o acordă. (învechit și nu este folosit ca demon în distribuțiile noi. Funcțiile sale în distribuțiile moderne (cu un nucleu mai vechi de 2.2.18) sunt realizate de nucleu (lockd). (Programul RPC 100024)
• rpc.idmapd - Daemonul NFSv4 idmapd de pe server mapează uid-urile/gid-urile locale ale utilizatorului la formatul nume@domeniu, iar serviciul client mapează numele utilizatorilor/grupurilor din formularul nume@domeniu la ID-urile locale ale utilizatorului și grupului (conform fișierului de configurare /etc/idmapd .conf).

Clientul poate rula și un daemon numit nfsiod. nfsiod servește cererile venite de la server de la serverul NFS. Este opțional, crește performanța, dar nu este necesar pentru funcționarea normală și corectă. În NFSv4, atunci când utilizați Kerberos, demonii sunt lansati suplimentar:

• rpc.gssd - demonul NFSv4 oferă metode de autentificare prin GSS-API (autentificare Kerberos). Funcționează pe client și server.
• rpc.svcgssd - daemon server NFSv4 care oferă autentificare pe partea de server.

Daemoni din versiunile vechi (NFS v.3 și mai jos):

• nfslogd - Daemonul de jurnal NFS înregistrează activitatea pentru sistemele de fișiere exportate, funcționează pe servere NFS
• rpc.rquotad - serverul de cote la distanță oferă informații despre cotele utilizatorilor în sistemele de fișiere la distanță, poate funcționa atât pe servere, cât și pe clienți.

În plus față de pachetele de mai sus, NFSv2 și v3 necesită un pachet portmap suplimentar (înlocuit cu redenumit în rpcbind în distribuțiile mai noi) pentru funcționarea corectă a NFSv2 și v3. Sun RPC este un server care traduce numerele de program RPC (Remote Procedure Call) în numere de porturi TCP/UDP.

portmap operează pe mai multe entități:

• Apeluri sau solicitări RPC
• Porturi TCP/UDP, versiunea protocolului (tcp sau udp)
• numere de program și versiuni de program

Daemonul portmap este pornit de scriptul /etc/init.d/portmap înainte de a începe serviciile NFS.

Sarcina unui server RPC (Remote Procedure Call) este de a procesa apeluri RPC (așa-numitele proceduri RPC) din procesele locale și de la distanță. Folosind apeluri RPC, serviciile se înregistrează sau se șterg către/din portmapper (portmap, portmapper, alias, în versiuni noi, rpcbind), iar clienții care folosesc apeluri RPC trimit cereri către portmapper pentru a primi informațiile necesare.

Funcționarea serverului RPC poate fi reprezentată prin următorii pași:

1. Soluția de porturi ar trebui să pornească mai întâi, de obicei când sistemul pornește. Aceasta creează un punct final TCP și deschide portul TCP 111. De asemenea, creează un punct final UDP care așteaptă să ajungă o datagramă UDP pe portul UDP 111.
2. La pornire, un program care rulează printr-un server RPC creează un punct final TCP și un punct final UDP pentru fiecare versiune acceptată a programului. (Un server RPC poate suporta mai multe versiuni. Clientul specifică versiunea necesară atunci când efectuează un apel RPC.) Fiecărei versiuni a serviciului i se atribuie un număr de port alocat dinamic. Serverul înregistrează fiecare program, versiune, protocol și număr de port făcând apelul RPC corespunzător.
3. Când un program client RPC trebuie să obțină informațiile de care are nevoie, el invocă o procedură de rezoluție de porturi pentru a obține un număr de port alocat dinamic pentru programul, versiunea și protocolul dat.
4. Ca răspuns la această solicitare, serverul returnează numărul portului.
5. Clientul trimite un mesaj RPC Request la numărul portului obținut la pasul 4. Dacă se folosește UDP, clientul trimite pur și simplu o datagramă UDP care conține mesajul RPC Call către numărul portului UDP pe care rulează serviciul solicitat. Ca răspuns, serviciul trimite o datagramă UDP care conține un mesaj de răspuns RPC. Dacă se utilizează TCP, clientul se deschide în mod activ la numărul portului TCP al serviciului solicitat și apoi trimite un mesaj de provocare RPC prin conexiunea stabilită. Serverul răspunde cu un mesaj de răspuns RPC prin conexiune.

Pentru a obține informații de la serverul RPC, se folosește utilitarul rpcinfo, acesta afișează numărul programului înregistrat, versiunea, protocolul, portul și numele. De asemenea, puteți utiliza rpcinfo pentru a anula înregistrarea unui program sau pentru a obține informații despre un anumit serviciu RPC. Când specificați opțiunile de gazdă -p, programul afișează o listă cu toate programele RPC înregistrate pe gazda. Fără a specifica o gazdă, programul va afișa servicii pe localhost.

Serverul NFS (mai precis, demonul rpc.nfsd) primește cereri de la client sub formă de datagrame UDP pe portul 2049. Deși NFS funcționează cu un rezolutor de porturi, care permite serverului să utilizeze porturi alocate dinamic, portul UDP 2049 este conectat la NFS în majoritatea implementărilor.

Descrierea procesului de accesare a unui fișier aflat pe un server NFS:

• Clientului (procesului utilizatorului) nu îi pasă dacă accesează un fișier local sau un fișier NFS. Nucleul se ocupă de interacțiunea cu hardware-ul prin module de kernel sau apeluri de sistem încorporate.
• Modulul kernel kernel/fs/nfs/nfs.ko, care acționează ca un client 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 sub formă de 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 conectat la NFS în majoritatea implementărilor.
• Când un server NFS primește o solicitare de la un client, aceasta este transmisă rutinei locale de acces la fișiere, care oferă acces la unitatea locală de pe server.
• Rezultatul accesului la disc este returnat clientului.

Configurarea unui server NFS

Configurarea serverului în ansamblu constă în specificarea directoarelor locale care pot fi montate de sistemele de la distanță în fișierul /etc/exports. Această acțiune se numește exportarea unei ierarhii de directoare. Principalele surse de informații despre cataloagele exportate sunt următoarele fișiere:

Structura folderului rădăcină

1. /etc/exports - fișierul principal de configurare care stochează configurația directoarelor exportate. Folosit la pornirea NFS și la utilizarea utilitarului exportfs.
2. /var/lib/nfs/xtab - conține o listă de directoare montate de clienți la distanță. Folosit de demonul rpc.mountd când un client încearcă să monteze o ierarhie (este creată o intrare de montare).
3. /var/lib/nfs/etab - o listă de directoare care pot fi montate de sisteme la distanță, cu toți parametrii directoarelor exportate.
4. /var/lib/nfs/rmtab - listă de directoare care nu sunt neexportate în prezent.
5. /proc/fs/nfsd este un sistem de fișiere special (kernel 2.6) pentru gestionarea unui server NFS.
6. /proc/net/rpc - conține statistici „raw” (raw), care pot fi obținute folosind nfsstat, precum și diverse cache-uri.
7. /var/run/portmap_mapping - informații despre serviciile înregistrate în RPC.

Următoarele opțiuni generale sunt utilizate în fișierul de export:

• auth_nlm (no_auth_nlm) sau secure_locks (insecure_locks) specifică faptul că serverul ar trebui să necesite autentificarea solicitărilor de blocare (folosind protocolul NFS Lock Manager).
• nohide (ascunde) - dacă serverul exportă două ierarhii de directoare, cu una imbricată (montată) în cealaltă. Clientul trebuie să monteze în mod explicit a doua ierarhie (copil), altfel punctul de montare al ierarhiei copil va apărea ca un director gol. Opțiunea nohide are ca rezultat o a doua ierarhie de director fără o montare explicită.
• ro - Permite doar cereri de citire.
• rw - Permite cereri de scriere.
• sigur (nesigur) - Necesită ca cererile NFS să vină din porturi securizate (< 1024), чтобы программа без прав root не могла монтировать иерархию каталогов.
• subtree_check (no_subtree_check) - Dacă un subdirector al sistemului de fișiere este exportat, dar nu întregul sistem de fișiere, serverul verifică dacă fișierul solicitat se află în subdirectorul exportat. Dezactivarea verificării reduce securitatea, dar crește viteza de transfer al datelor.
• sync (async) Specifică faptul că serverul ar trebui să răspundă la solicitări numai după ce modificările făcute de acele cereri au fost scrise pe disc. Opțiunea asincronă îi spune serverului să nu aștepte ca informațiile să fie scrise pe disc, ceea ce îmbunătățește performanța, dar reduce fiabilitatea. Pierderea informațiilor este posibilă dacă conexiunea este întreruptă sau echipamentul eșuează.
• wdelay (no_wdelay) - Spune serverului să întârzie executarea cererilor de scriere dacă o cerere de scriere ulterioară este în așteptare, scriind datele în blocuri mai mari. Acest lucru îmbunătățește performanța la trimiterea unor cozi mari de comenzi de scriere. no_wdelay specifică să nu întârzie execuția comenzii de scriere, ceea ce poate fi util dacă serverul primește un număr mare de comenzi care nu au legătură între ele.

Administrarea serverului NFS

Serverul NFS este gestionat folosind următoarele utilitare:

• nfsstat
• showmnumăr sigur (nesigur).
• exportfs

Utilitarul nfsstat vă permite să vizualizați statisticile serverelor RPC și NFS.

showmount

Utilitarul showmount interogează demonul rpc.mountd de pe gazda la distanță pentru sistemele de fișiere montate. În mod implicit, este returnată o listă sortată de clienți. Echipe:

• --all - este afișată o listă de clienți și puncte de montare indicând locul unde clientul a montat directorul. Este posibil ca aceste informații să nu fie de încredere.
• --directories - listează punctele de montare.
• --exports - listează sistemele de fișiere exportate din punctul de vedere al nfsd.

Rularea showmount fără argumente va imprima pe consolă informații despre sistemele cărora li se permite să monteze directoare locale.

exportfs

Această comandă sincronizează directoarele exportate specificate în fișierul /etc/exports cu fișierul /var/lib/nfs/xtab și le elimină pe cele inexistente din xtab. exportfs este executat când demonul nfsd este pornit cu argumentul -r. Utilitarul exportfs în modul kernel 2.6 vorbește cu demonul rpc.mountd prin fișierele din directorul /var/lib/nfs/ și nu vorbește direct cu nucleul. Fără parametri, returnează o listă a sistemelor de fișiere exportate în prezent. opțiuni exportfs:

1. [client:dir-name] - adăugați sau eliminați sistemul de fișiere specificat pentru clientul specificat)
2. -v - afișează mai multe informații
3. -r - reexportă toate directoarele (sync /etc/exports și /var/lib/nfs/xtab)
4. -u - eliminați din lista de export
5. -a - adăugați sau eliminați toate sistemele de fișiere
6. -o - opțiuni separate prin virgule (similar cu opțiunile utilizate în /etc/exports; astfel, puteți modifica opțiunile sistemelor de fișiere deja montate)
7. -i - nu utilizați /etc/exports când adăugați, doar opțiunile liniei de comandă curente
8. -f - resetează lista sistemelor exportate în nucleul 2.6.

Montarea sistemului de fișiere de rețea cu comanda mount

Un exemplu de comandă mount pentru a monta un sistem de fișiere NFS pe Debian:

Prima comandă montează directorul exportat /archiv-small pe serverul de arhivare la punctul de montare local /archivs/archiv-small cu opțiuni implicite (adică citire/scriere). A doua comandă montează directorul exportat /archiv-big de pe serverul de arhive în directorul local /archivs/archiv-big cu opțiunea de numai citire (ro). Comanda de montare fără parametri afișează clar rezultatul monturii. În plus față de opțiunea de numai citire (ro), este posibil să specificați și alte opțiuni de bază pe o montură NFS:

• nosuid - Această opțiune interzice execuția programelor setuid din directorul montat.
• nodev (fără dispozitiv) - Această opțiune dezactivează caracterele și blochează fișierele speciale ca dispozitive.
• lock (nolock) - Activează blocarea NFS (implicit). nolock dezactivează blocarea NFS (nu pornește demonul lockd) și este util atunci când aveți de-a face cu servere mai vechi care nu acceptă blocarea NFS.
• mounthost=name - Numele gazdei care rulează demonul de montare NFS - mountd.
• mountport=n - Portul folosit de demonul mountd.
• port=n - portul folosit pentru a se conecta la serverul NFS (implicit este 2049 dacă daemonul rpc.nfsd nu este înregistrat pe serverul RPC). Dacă n=0 (implicit), atunci NFS trimite o solicitare către portmap de pe server pentru a determina portul.
• rsize=n (mărimea blocului de citire) - numărul de octeți citiți la un moment dat de pe serverul NFS. Valoarea implicită este 4096.
• wsize=n (mărimea blocului de scriere) - Numărul de octeți scriși la un moment dat pe serverul NFS. Valoarea implicită este 4096.
• tcp sau udp - Utilizați protocolul TCP sau UDP pentru a monta NFS.
• bg - Dacă pierdeți accesul la server, reîncercați în fundal pentru a nu bloca procesul de pornire a sistemului.
• fg - Dacă accesul la server este pierdut, reîncercați în prim-plan. Această opțiune poate bloca procesul de pornire a sistemului prin reîncercări de montare. Din acest motiv, opțiunea fg este folosită în primul rând în scopuri de depanare.
• Opțiuni care afectează memorarea în cache a atributelor pe monturile NFS
• Atributele fișierelor stocate în inod-uri (inode), cum ar fi timpul de modificare, dimensiunea, legăturile hard, proprietarul, se schimbă de obicei rar pentru fișierele obișnuite și chiar mai rar pentru directoare. Nucleul folosește timpul de modificare a unui fișier pentru a determina dacă memoria cache este învechită, comparând timpul de modificare din cache și timpul de modificare a fișierului însuși.

Cache-ul de atribute este actualizat periodic în funcție de parametrii specificați:

1. ac (noac) (attribute cache) - Activați memorarea în cache a atributelor (implicit). Deși opțiunea noac încetinește serverul, evită îmbătrânirea atributelor atunci când mai mulți clienți scriu în mod activ informații într-o ierarhie comună.
2. acdirmax=n (fișierul directorului cache al atributelor maxim) - Numărul maxim de secunde de așteptare NFS înainte de a actualiza atributele directorului (implicit 60 sec.)
3. acdirmin=n (fișierul directorului cache al atributelor minim) - Numărul minim de secunde de așteptare NFS înainte de a actualiza atributele directorului (30 secunde în mod implicit)
4. acregmax=n (maximum pentru fișierul obișnuit în cache de atribute) - Numărul maxim de secunde pe care NFS așteaptă înainte de a actualiza atributele normale ale fișierului (implicit 60 de secunde)
5. acregmin=n (minimum al fișierului obișnuit din memoria cache a atributului) - Numărul minim de secunde pe care NFS așteaptă înainte de a actualiza atributele normale ale fișierului (implicit este de 3 secunde)
6. actimeo=n (atribut cache timeout) - Supliniază valorile pentru toate opțiunile de mai sus. Dacă actimeo nu este setat, atunci valorile de mai sus sunt implicite.

Opțiuni de tratare a erorilor NFS

Următoarele opțiuni controlează ce face NFS atunci când nu există niciun răspuns de la server sau când apar erori I/O:

• fg (bg) (prim-plan - prim-plan, fundal - fundal) - Încercați să montați un NFS eșuat în prim-plan/fond.
• hard (soft) - Imprimă un mesaj „serverul nu răspunde” pe consolă când este atins timpul de expirare și continuă încercările de montare. Dacă opțiunea este setată, soft - informează programul care a apelat operația despre o eroare I/O la expirarea timpului.
• nointr (intr) (fără întrerupere) - Nu permite semnalelor să întrerupă operațiunile fișierelor într-o ierarhie de directoare montată pe hard atunci când este atins un timeout mare. intr - activare întrerupere.
• retransmission=n (valoare de retransmisie) - După n timeout-uri mici, NFS generează un timeout mare (implicit este 3). Un timeout mare încheie operațiunile sau tipărește un mesaj „serverul nu răspunde” pe consolă, în funcție de opțiunea hard/soft specificată.
• retry=n (valoare de reîncercare) - Numărul de minute în care NFS reîncercă montarea înainte de a renunța (implicit 10000).
• timeo=n (valoarea timeout) - Numărul de zecimi de secundă pe care serviciul NFS le așteaptă înainte de a retransmite în cazul RPC sau timeout scăzut (implicit 7). Această valoare este incrementată la fiecare timeout până la o valoare maximă de 60 de secunde sau până când apare un timeout mare. Dacă rețeaua este ocupată, serverul este lent sau cererea trece prin mai multe routere sau gateway-uri, creșterea acestei valori poate îmbunătăți performanța.

Îmbunătățirea performanței NFS

Mai mulți parametri pot afecta performanța NFS, în special atunci când se lucrează la conexiuni lente. Când lucrați cu conexiuni lente și cu sarcină mare, este recomandabil să utilizați parametrul hard, astfel încât timeout-urile să nu conducă la terminarea programelor. Dar trebuie să știți că dacă montați sistemul de fișiere prin NFS cu opțiunea hard prin fstab și gazda la distanță nu este disponibilă, atunci sistemul se va îngheța la pornire.

O modalitate de a îmbunătăți performanța NFS este creșterea numărului de octeți transferați la un moment dat. Dimensiunea de 4096 de octeți este prea mică pentru conexiunile rapide de astăzi, creșterea acestei valori la 8192 sau mai mult poate găsi experimental viteza optimă.

De asemenea, nu treceți cu vederea setările de timeout. NFS așteaptă un răspuns pentru a trimite date în perioada de timp specificată în opțiunea timeo, dacă nu se primește niciun răspuns în acest timp, atunci se efectuează un retransfer. În conexiunile ocupate și lente, acest timp poate fi mai mic decât timpul de răspuns al serverului și capacitatea conexiunii, ceea ce duce la retransmisii inutile care încetinesc lucrurile. În mod implicit, timeo este de 0,7 secunde (700 de milisecunde). după detectarea faptului unei conexiuni întrerupte în 700 ms, serverul va retransmite și va dubla timeout-ul la 1,4 secunde, creșterea timeo va continua până la o valoare maximă de 60 de secunde.

Pentru distribuirea fișierelor într-o rețea locală, se pot distinge următoarele tehnologii (se iau în considerare sistemele bazate pe Linux):

• Network File System (NFS) - protocol pentru accesul în rețea la sistemele de fișiere;
• Fișierele transferate prin protocolul Shell (FISH) - un protocol de rețea care utilizează sau RSH pentru a transfera fișiere între computere;
• Secure SHell FileSystem (SSHFS) - un client de sistem de fișiere pentru montarea dispozitivelor de disc pe sisteme la distanță, folosit pentru a interacționa cu un sistem la distanță SFTP;
• Samba - un pachet software care vă permite să accesați unități de rețea și imprimante pe diverse sisteme de operare folosind protocolul SMB / CIFS;

În această notă, vom vorbi despre NFS.

NFS (sistem de fișiere de rețea) util atunci când trebuie să distribuiți fișiere/directoare tuturor din rețea. Transparența accesului prin NFS permite clienților să monteze un sistem de fișiere la distanță ca director local, iar sistemele de fișiere pot fi de diferite tipuri. Aceasta înseamnă că orice aplicație client care poate funcționa cu un fișier local poate funcționa la fel de bine cu un fișier conectat prin intermediul NFS fără nicio modificare a programului în sine.

La beneficii NFS pot fi atribuite:

Disponibil acum NFS v4.1, care a introdus o nouă caracteristică pNFS permițând paralelizarea implementării partajării fișierelor. Există, de asemenea, o extensie pentru NFS 2 și 3 - WebNFS, care permit integrarea mai ușoară în browserele web și capacitatea de a lucra printr-un firewall.

Schema de lucru NFS protocol.

Instalarea și configurarea unui server NFS sub Linux

Verificați dacă sistemul acceptă NFS

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

Sub Arch Linux serverul și clientul sunt în același pachet

Yaourt -S nfs-utils

Pentru a instala serverul nfs-kernel-server) și client ( nfs-comun) sub ubuntu pachetele necesare

sudo apt-get install nfs-kernel-server nfs-common portmap

Mai departe, în notă, IP-ul va fi folosit pentru server 192.168.1.100 . Pentru ca serverul să aibă întotdeauna același IP alocat, este necesar să specificați distribuția unui anumit IP la o anumită adresă MAC în serverul DHCP (cel mai adesea un router). Sau ridicați-vă serverul DNS local. De exemplu sau .

Puteți afla adresa MAC folosind ifconfig (câmp eterîn Arch Linux).

NFSv4 presupune că există un director rădăcină, în interiorul căruia sunt deja localizate fișierele pentru distribuire. De exemplu, /srv/nfs- radacina, /srv/nfs/audio- director pentru distribuirea muzicii. Dacă nu urmați această nouă direcție în versiune 4 , atunci puteți primi o eroare la conectarea de către client:

Mount.nfs: acces refuzat de server în timpul instalării 192.168.1.100:/home/proft/torrents

Dacă totuși doriți să utilizați abordarea no-root-directory pe server pentru NFS, apoi la montare de către client, trebuie să specificați în mod explicit versiunea 3

# pentru comanda de montare mount -o "vers=3" 192.168.1.100:/home/proft/torrents /home/proft/nfs/torrents # pentru fstab 192.168.1.100:/home/proft/torrents /home/proft/nfs/ torrents nfs soft,nfsvers=3 0 0

voi folosi NFSv4 cu directorul rădăcină în /srv/nfs/și montarea directoarelor imbricate cu mount --bind .

Să presupunem că vrem

• directorul de distribuție ~/torrenți Cu rw acces pentru toateîn cadrul rețelei locale;
• directorul de distribuție ~/fotografii Cu ro acces pentru gazdă cu IP 192.168.1.101 ;

Mai întâi, să creăm directorul rădăcină și subdirectoarele necesare.

Sudo mkdir -p /srv/nfs/(torrenți, fotografii)

Montați directoarele existente torrente, fotografiiîn /srv/nfs.

# sudo vim /etc/fstab /home/proft/torrents /srv/nfs/torrents none bind 0 0 /home/proft/photos /srv/nfs/photos none bind 0 0

Editați | × /etc/exports, care descrie toate directoarele partajate

# sudo vim /etc/exports # format de fișier: directorul permit-hosts(opțiuni) /srv/nfs/torrents 192.168.1.1/24(rw,async) /srv/nfs/photos 192.168.1.101(ro,async)

Observați că nu există spațiu între gazde permiseși (Opțiuni). Prezența unui spațiu introduce o interpretare diferită a regulilor.

Optiuni Disponibile:

• ro (rw) - permite accesul numai în citire (citire/scriere);
• subtree_check (no_subtree_check) - în unele cazuri, trebuie să exportați nu întreaga secțiune, ci doar o parte a acesteia. În același timp, serverul NFS trebuie să efectueze verificări suplimentare asupra solicitărilor clienților pentru a se asigura că aceștia încearcă doar să acceseze fișierele din subdirectoarele corespunzătoare. Un astfel de control subarboresc ( verificări subarbore) încetinește oarecum interacțiunea cu clienții, dar dacă o refuzați, este posibil să aveți probleme cu securitatea sistemului. Puteți anula controlul unui subarboresc folosind opțiunea no_subtree_check. Opțiune subtree_check, care include un astfel de control, se presupune implicit. Controlul subarboresc poate fi omis dacă directorul exportat este același cu o partiție de disc;
• sync (async) Specifică faptul că serverul ar trebui să răspundă la solicitări numai după ce modificările făcute de acele cereri au fost scrise pe disc. Opțiune asincron instruiește serverul să nu aștepte ca informațiile să fie scrise pe disc, ceea ce îmbunătățește performanța, dar reduce fiabilitatea, deoarece în caz de întrerupere a conexiunii sau defecțiune a echipamentului, datele se pot pierde;
• noaccess - Interzice accesul la directorul specificat. Poate fi util dacă anterior ați setat accesul pentru toți utilizatorii rețelei la un anumit director, iar acum doriți să restricționați accesul într-un subdirector doar la unii utilizatori;
• no_root_squash - utilizator implicit rădăcină pe computerul client nu va avea aceleași drepturi la directorul de pe server. Această opțiune elimină această limitare;
• ascunde- NFS nu afișează automat resurse non-locale (de exemplu, montate cu mount --bind), această opțiune permite afișarea acestor resurse;
• nesigur - folosirea porturilor neprivilegiate (> 1024);

Pornirea serverului NFS

# sub archlinux sudo systemctl start rpc-idmapd.service rpc-mountd.service # sub ubuntu sudo /etc/init.d/nfs-kernel-server start

În viitor, la schimbarea fișierului de configurare, este suficient să-l recitiți cu comanda:

sudo exportfs -rav

comanda rpcinfo -p | grep nfs vă permite să verificați dacă serverul a pornit cu succes.

Client pentru Linux

Instalare

# sub archlinux yaourt -S nfs-utils # sub ubuntu sudo apt-get install portmap nfs-common

Creați directoare pentru montarea resurselor de rețea torrenteși fotografii

Mkdir -p ~/nfs/(torrenți, fotografii)

Pentru a monta manual, rulați

sudo mount -t nfs -o rw,soft 192.168.1.100:/srv/nfs/torrents /home/proft/nfs/torrents sudo mount -t nfs -o rw,soft 192.168.1.100:/srv/nfs/photos /proft/nfs/photos

Opțiune moale specifică anularea în tăcere a încercărilor de a conecta partajarea după o anumită perioadă de timp (ora este setată de opțiunea retrans). Citiți mai multe în man nfs.

Această metodă nu este foarte convenabilă, deoarece de fiecare dată după repornire va trebui să rulați aceste comenzi. Să facem montura automată.

Pentru a monta automat, editați fișierul /etc/fstab

# sudo vim /etc/fstab 192.168.1.100:/srv/nfs/torrents /home/proft/net/torrents nfs rw,soft 0 0 192.168.1.100:/srv/nfs/photos /home/proft/net/photos ro,soft 0 0

Dar această metodă are și dezavantajele sale, de exemplu, dacă serverul nu este disponibil, atunci încărcarea clientului se poate îngheța din cauza încercărilor de conectare la serverul NFS. Pentru a remedia acest lucru, consultați mai jos despre AutoFS.

AutoFS - conectarea automată a resurselor de rețea

Este posibil să montați o resursă la distanță folosind AutoFS la primul acces și demontează automat când nu există activitate.

AutoFS folosește șabloane situate în /etc/autofs. Modelul principal este numit auto.master, poate indica unul sau mai multe alte șabloane pentru anumite tipuri de media.

Instalare

# sub archlinux yaourt -S autofs # sub ubuntu sudo apt-get install autofs

Există mai multe moduri de a specifica metodele de montare automată. Eu il folosesc pe acesta: /home/proft/nfs este creat automat un director cu numele serverului NFS, în care sunt create automat directoarele disponibile pe server.

# sudo vim /etc/autofs/auto.master /home/proft/nfs /etc/autofs/auto.nfs --timeout=60

Parametru suplimentar pauză setează numărul de secunde după care dispozitivul va fi demontat. Parametru fantomă specifică că resursele configurate vor fi întotdeauna afișate, nu numai când sunt disponibile (această opțiune este activată implicit în AutoFS 5)

Vom descrie în /etc/autofs/auto.nfs Server NFS și director rădăcină.

# sudo vim /etc/autofs/auto.nfs nfsserver 192.168.1.100:/srv/nfs

Acum la primul apel /home/proft/nfs/torrents partajarea NFS va fi montată automat.

Reporniți serviciul autofs:

# sub archlinux sudo systemctl restart autofs # sub ubuntu sudo /etc/init.d/autofs restart

De asemenea, puteți specifica timpul de așteptare pentru disponibilitatea unei resurse NFS. Pentru a face acest lucru, trebuie să modificați valorile MOUNT_WAIT.

# sub archlinux # sudo vim /etc/conf.d/autofs MOUNT_WAIT=5 # sub ubuntu sudo /etc/default/autofs MOUNT_WAIT=5

Forțarea utilizării NFS v3

In unele cazuri NFSv4 poate rula încet. Pentru a remedia acest lucru, puteți forța utilizarea a treia versiune.

Timp bun, cititori și oaspeți. A fost o pauză foarte lungă între postări, dar am revenit în luptă). În articolul de astăzi, mă voi uita operarea protocolului NFS, precum și configurarea serverului NFS și a clientului NFS pe Linux.

Introducere în NFS

NFS (Sistem de fișiere de rețea - sistem de fișiere de rețea) după părerea mea - o soluție ideală într-o rețea locală în care este necesar schimbul de date rapid (mai rapid în comparație cu SAMBA și mai puțin consumator de resurse în comparație cu sistemele de fișiere la distanță criptate - sshfs, SFTP etc...) și nu este în prim-plan. securitatea informatiilor transmise. Protocolul NFS permite montați sisteme de fișiere la distanță în rețea într-un arbore de directoare local, ca și cum ar fi un sistem de fișiere pe disc montat. Astfel, aplicațiile locale pot funcționa cu sistemul de fișiere la distanță ca și cu cel local. Dar trebuie să fii atent (!) cu configurarea NFS, deoarece cu o anumită configurație, puteți suspenda sistemul de operare client în așteptarea I/O fără sfârșit. Protocolul NFS pe baza muncii Protocolul RPC, ceea ce este dincolo de înțelegerea mea încă)) deci materialul din articol va fi puțin vag... Înainte de a putea folosi NFS, fie el un server sau un client, trebuie să vă asigurați că nucleul dumneavoastră are suport pentru fișierul NFS sistem. Puteți verifica dacă nucleul acceptă sistemul de fișiere NFS căutând liniile corespunzătoare în fișier /proc/sisteme de fișiere:

ARCHIV ~ # grep nfs /proc/filesystems nodev nfs nodev nfs4 nodev nfsd

Dacă liniile specificate în fișier /proc/sisteme de fișiere nu apare, atunci trebuie să instalați pachetele descrise mai jos. Acest lucru va instala cel mai probabil module de nucleu dependente pentru a suporta sistemele de fișiere dorite. Dacă, după instalarea pachetelor, suportul NFS nu este afișat în fișierul specificat, atunci va fi necesar să activați această caracteristică.

Poveste Sistem de fișiere de rețea

Protocolul NFS dezvoltat de Sun Microsystems și are 4 versiuni în istoria sa. NFSv1 a fost dezvoltat în 1989 și a fost experimental, a lucrat la protocolul UDP. Versiunea 1 este descrisă în . NFSv2 a fost lansat în același 1989, descris de același RFC1094 și, de asemenea, bazat pe protocolul UDP, permițând în același timp să citească nu mai mult de 2 GB dintr-un fișier. NFSv3 finalizat în 1995 și descris în . Principalele inovații ale celei de-a treia versiuni au fost suportul pentru fișiere mari, suport adăugat pentru protocolul TCP și pachete TCP mari, care au accelerat semnificativ performanța tehnologiei. NFSv4 finalizat în 2000 și descris în RFC 3010, revizuit în 2003 și descris în . A patra versiune a inclus îmbunătățiri de performanță, suport pentru diverse instrumente de autentificare (în special, Kerberos și LIPKEY folosind protocolul RPCSEC GSS) și liste de control al accesului (atât tipurile POSIX, cât și Windows). Versiunea NFS v4.1 a fost aprobat de IESG în 2010 și a primit . O inovație importantă în versiunea 4.1 este specificația pNFS - Parallel NFS, un mecanism pentru accesul paralel al clientului NFS la datele de pe mai multe servere NFS distribuite. Prezența unui astfel de mecanism în standardul sistemului de fișiere de rețea va ajuta la construirea de sisteme de stocare și informații distribuite „cloud” („cloud”).

Server NFS

Din moment ce avem NFS- aceasta este reţea sistem de fișiere, aveți nevoie de . (Puteți citi și articolul). Următorul este necesar. Pe Debian, acesta este pachetul nfs-kernel-serverși nfs-comun, în RedHat este un pachet nfs-utils. De asemenea, este necesar să se permită lansarea demonului la nivelurile de rulare necesare ale sistemului de operare (comanda din RedHat este /sbin/chkconfig nfs activat, în Debian - Valorile implicite ale /usr/sbin/update-rc.d nfs-kernel-server).

Pachetele instalate în Debian sunt rulate în următoarea ordine:

ARCHIV ~ # ls -la /etc/rc2.d/ | grep nfs lrwxrwxrwx 1 root root 20 oct 18 15:02 S15nfs-common -> ../init.d/nfs-common lrwxrwxrwx 1 root root 27 oct 22 01:23 S16nfs-kernel-server -> kernel-server /nfs-kernel-server

Adică prima alergare nfs-comun, apoi serverul în sine nfs-kernel-server. În RedHat situația este similară, cu singura excepție că se apelează primul script nfslock, iar serverul este numit simplu nfs. Pro nfs-comun Site-ul debian ne spune literalmente următoarele: fișiere comune pentru un client și server NFS, acest pachet trebuie instalat pe mașina care va acționa ca client sau server NFS. Pachetul include programe: lockd, statd, showmount, nfsstat, gssd și idmapd. Prin vizualizarea conținutului scriptului de pornire /etc/init.d/nfs-common puteți urmări următoarea secvență de lucru: scriptul verifică prezența unui fișier binar executabil /sbin/rpc.statd, verifică prezența în fișiere /etc/default/nfs-common, /etc/fstabși /etc/exports opțiuni care necesită demoni pentru a porni idmapd și gssd , pornește demonul /sbin/rpc.statd , apoi înainte de lansare /usr/sbin/rpc.idmapdși /usr/sbin/rpc.gssd verifică prezența acestor binare executabile, apoi pentru demonul /usr/sbin/rpc.idmapd verifică disponibilitatea sunrpc, nfsși nfsd, precum și suport pentru sistemul de fișiere rpc_pipefsîn nucleu (adică prezența acestuia în fișier /proc/sisteme de fișiere), dacă totul are succes, atunci se lansează /usr/sbin/rpc.idmapd . În plus, pentru demon /usr/sbin/rpc.gssd verificări modulul kernel rpcsec_gss_krb5și pornește demonul.

Dacă vizualizați conținutul Scriptul de pornire a serverului NFS pe Debian ( /etc/init.d/nfs-kernel-server), atunci se poate urmări următoarea secvență: la pornire, scriptul verifică existența fișierului /etc/exports, Disponibilitate nfsd, disponibilitatea suportului Sistem de fișiere NFSîn (adică în dosar /proc/sisteme de fișiere), dacă totul este la locul lui, atunci demonul începe /usr/sbin/rpc.nfsd , apoi verifică dacă parametrul este setat NEED_SVCGSSD(setat în fișierul de setări server /etc/default/nfs-kernel-server) și, dacă este dat, pornește demonul /usr/sbin/rpc.svcgssd , ultimul care pornește demonul /usr/sbin/rpc.mountd . Acest script arată că Funcționarea unui server NFS constă în demonii rpc.nfsd, rpc.mountd, iar dacă se folosește autentificarea Kerberos, atunci demonul rcp.svcgssd. Demonii rpc.rquotad și nfslogd încă rulează în red hat (Din anumite motive, nu am găsit informații despre acest demon și motivele absenței sale în Debian, aparent eliminate...).

De aici devine clar că Serverul Network File System este format din următoarele procese (citire - demoni) situat în directoarele /sbin și /usr/sbin:

În NFSv4, atunci când utilizați Kerberos, demonii sunt lansati suplimentar:

• rpc.gssd- Daemonul NFSv4 oferă metode de autentificare prin GSS-API (autentificare Kerberos). Funcționează pe client și server.
• rpc.svcgssd- Un daemon server NFSv4 care oferă autentificare pe partea de server.

portmap și protocol RPC (Sun RPC)

În plus față de pachetele de mai sus, NFSv2 și v3 necesită un pachet suplimentar pentru a funcționa corect. portmap(în distribuțiile mai noi înlocuite cu redenumit în rpcbind). Acest pachet este de obicei instalat automat cu NFS ca dependență și implementează munca serverului RPC, adică este responsabil pentru alocarea dinamică a portului pentru unele servicii înregistrate în serverul RPC. Literal, conform documentației, acesta este un server care convertește numerele de program RPC (Remote Procedure Call) în numere de porturi TCP / UDP. portmap operează pe mai multe entități: Apeluri sau solicitări RPC, porturi TCP/UDP,versiunea protocolului(tcp sau udp), numere de programși versiuni de software. Daemonul portmap este pornit de scriptul /etc/init.d/portmap înainte de a începe serviciile NFS.

Pe scurt, sarcina unui server RPC (Remote Procedure Call) este de a procesa apeluri RPC (așa-numitele proceduri RPC) din procesele locale și de la distanță. Folosind apeluri RPC, serviciile se înregistrează sau se șterg în / din portmapper (aka portmapper, aka portmap, aka portmapper, aka, în versiuni noi, rpcbind), iar clienții care folosesc apeluri RPC solicitările directe către portmapper primesc informațiile necesare. Numele de servicii de program ușor de utilizat și numerele lor corespunzătoare sunt definite în fișierul /etc/rpc. De îndată ce orice serviciu a trimis cererea corespunzătoare și s-a înregistrat pe serverul RPC în port mapper, serverul RPC atribuie serviciului TCP și UDP porturile pe care a pornit serviciul și stochează în nucleu informațiile relevante despre serviciul care rulează. (despre nume), un serviciu de număr unic (conform /etc/rpc), protocolul și portul pe care rulează serviciul și versiunea serviciului și oferă clienților informațiile specificate la cerere. Resolutorul de porturi în sine are un număr de program (100000), un număr de versiune 2, portul TCP 111 și portul UDP 111. Mai sus, când am specificat compoziția demonilor serverului NFS, am indicat principalele numere de program RPC. Probabil te-am confundat puțin cu acest paragraf, așa că voi spune fraza principală, care ar trebui să clarifice: funcția principală a port mapper este de a returna lui (clientului) portul pe care rulează programul solicitat. În consecință, dacă un client trebuie să contacteze RPC cu un anumit număr de program, trebuie să contacteze mai întâi procesul portmap de pe computerul server și să determine numărul portului pentru a comunica cu serviciul RPC de care are nevoie.

Funcționarea serverului RPC poate fi reprezentată prin următorii pași:

1. Soluția de porturi ar trebui să pornească mai întâi, de obicei când sistemul pornește. Aceasta creează un punct final TCP și deschide portul TCP 111. De asemenea, creează un punct final UDP care așteaptă să ajungă o datagramă UDP pe portul UDP 111.
2. La pornire, un program care rulează printr-un server RPC creează un punct final TCP și un punct final UDP pentru fiecare versiune acceptată a programului. (Un server RPC poate suporta mai multe versiuni. Clientul specifică versiunea necesară atunci când efectuează un apel RPC.) Fiecărei versiuni a serviciului i se atribuie un număr de port alocat dinamic. Serverul înregistrează fiecare program, versiune, protocol și număr de port făcând apelul RPC corespunzător.
3. Când un program client RPC trebuie să obțină informațiile de care are nevoie, el invocă o procedură de rezoluție de porturi pentru a obține un număr de port alocat dinamic pentru programul, versiunea și protocolul dat.
4. Ca răspuns la această solicitare, serverul returnează numărul portului.
5. Clientul trimite un mesaj RPC Request la numărul portului obținut la pasul 4. Dacă se folosește UDP, clientul trimite pur și simplu o datagramă UDP care conține mesajul RPC Call către numărul portului UDP pe care rulează serviciul solicitat. Ca răspuns, serviciul trimite o datagramă UDP care conține un mesaj de răspuns RPC. Dacă se utilizează TCP, clientul se deschide în mod activ la numărul portului TCP al serviciului solicitat și apoi trimite un mesaj de provocare RPC prin conexiunea stabilită. Serverul răspunde cu un mesaj de răspuns RPC prin conexiune.

Pentru a obține informații de la serverul RPC, utilizați utilitarul rpcinfo. La specificarea parametrilor -p gazdă programul listează toate programele RPC înregistrate pe gazda gazdă. Fără a specifica o gazdă, programul va afișa servicii pe localhost. Exemplu:

Archiv ~ # rpcInfo -p пoрог -ма п пoрото порт 100000 2 TCP 111 PORTMAPPER 100000 2 UDP 111 PORTMAPPER 100024 1 UDP 59451 Status 100024 1 TCP 60872 Status 100021 1 UDP 44310 NLOCKMGR 100021 3 UDP 44311 44851 nlockmgr 100021 3 TCP 44851 Nlockmgr 100021 4 TCP 44851 NLOCKMGR 100003 2 TCP 2049 NFS 100003 3 TCP 2049 NFS 100003 4 TCP 2049 NFS 100003 2 UDP 2049 NFS 100003 3 UDP 2049 NFS 10000 3003300 1 41405 mountd 100005 2 udp 51306 mountd 100005 2 tcp 41405 mountd 100005 3 udp 51306 mountd 100005 3 tcp 41405 mountd

După cum puteți vedea, rpcinfo afișează (în coloane de la stânga la dreapta) numărul programului înregistrat, versiunea, protocolul, portul și numele. Cu rpcinfo puteți elimina înregistrarea unui program sau puteți obține informații despre un anumit serviciu RPC (mai multe opțiuni în man rpcinfo). După cum puteți vedea, demonii portmapper versiunea 2 pe porturile udp și tcp, demonii rpc.statd versiunea 1 pe porturile udp și tcp, versiunile managerului de blocare NFS 1,3,4, daemon server nfs versiunea 2,3,4, precum și demonul de montare sunt versiunile înregistrate 1,2,3.

Serverul NFS (mai precis, demonul rpc.nfsd) primește cereri de la client sub formă de datagrame UDP pe portul 2049. Deși NFS funcționează cu un rezolutor de porturi, care permite serverului să utilizeze porturi alocate dinamic, portul UDP 2049 este conectat la NFS în majoritatea implementărilor.

Operarea protocolului de sistem de fișiere de rețea

Montare NFS la distanță

Procesul de montare a unui sistem de fișiere NFS la distanță poate fi reprezentat după cum urmează:

Descrierea protocolului NFS la montarea unui director la distanță:

1. Un server RPC este pornit pe server și client (de obicei la boot), menținut de procesul portmapper și înregistrat pe porturile tcp/111 și udp/111.
2. Sunt lansate servicii (rpc.nfsd, rpc.statd etc.), care se înregistrează pe serverul RPC și se înregistrează pe porturi de rețea arbitrare (dacă nu este specificat un port static în setările serviciului).
3. comanda mount de pe computerul client trimite nucleului o solicitare pentru a monta directorul de rețea indicând tipul de sistem de fișiere, gazdă și directorul în sine, nucleul trimite o solicitare RPC procesului portmap de pe serverul NFS de pe udp/111 port (dacă opțiunea de a lucra prin tcp nu este setată pe client)
4. Nucleul serverului NFS solicită RPC prezența demonului rpc.mountd și returnează nucleului clientului portul de rețea pe care rulează demonul.
5. mount trimite o cerere RPC către portul în care rulează rpc.mountd. Serverul NFS poate valida acum clientul pe baza adresei sale IP și a numărului de port pentru a vedea dacă clientul poate monta sistemul de fișiere specificat.
6. Daemonul de montare returnează o descriere a sistemului de fișiere solicitat.
7. Comanda mount a clientului emite apelul de sistem mount pentru a asocia descriptorul de fișier obținut la pasul 5 cu un punct de montare local pe gazda clientului. Descriptorul de fișier este stocat în codul NFS al clientului și, de atunci, orice proces de utilizator care accesează fișierele din sistemul de fișiere al serverului va folosi descriptorul de fișier ca punct de plecare.

Comunicare între client și serverul NFS

Un acces tipic la un sistem de fișiere la distanță poate fi descris după cum urmează:

Descrierea procesului de accesare a unui fișier aflat pe un server NFS:

1. Clientului (procesului utilizatorului) nu îi pasă dacă accesează un fișier local sau un fișier NFS. Nucleul se ocupă de interacțiunea cu hardware-ul prin module de kernel sau apeluri de sistem încorporate.
2. modulul kernelului kernel/fs/nfs/nfs.ko, care acționează ca un client 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.
3. Serverul NFS primește cereri de la client sub formă de 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 conectat la NFS în majoritatea implementărilor.
4. Când un server NFS primește o solicitare de la un client, aceasta este transmisă rutinei locale de acces la fișiere, care oferă acces la unitatea locală de pe server.
5. Rezultatul accesului la disc este returnat clientului.

Configurarea unui server NFS

Ajustarea serveruluiîn general, este de a specifica directoarele locale care pot fi montate de sistemele de la distanță într-un fișier /etc/exports. Această acțiune se numește exportul ierarhiei directoarelor. Principalele surse de informații despre cataloagele exportate sunt următoarele fișiere:

• /etc/exports- fișierul principal de configurare care stochează configurația directoarelor exportate. Folosit la pornirea NFS și la utilizarea utilitarului exportfs.
• /var/lib/nfs/xtab- conține o listă de directoare montate de clienți la distanță. Folosit de demonul rpc.mountd când un client încearcă să monteze o ierarhie (este creată o intrare de montare).
• /var/lib/nfs/etab- o listă de directoare care pot fi montate de către sistemele de la distanță, indicând toți parametrii directoarelor exportate.
• /var/lib/nfs/rmtab- lista directoarelor care nu sunt neexportate în acest moment.
• /proc/fs/nfsd- un sistem de fișiere special (kernel 2.6) pentru gestionarea serverului NFS.
  • exporturi- lista ierarhiilor active exportate și clienților către care au fost exportați, precum și parametrii. Nucleul primește aceste informații de la /var/lib/nfs/xtab.
  • fire- conține numărul de fire (de asemenea, poate fi schimbat)
  • folosind filehandle puteți obține un pointer către un fișier
  • si etc...
• /proc/net/rpc- conține statistici „raw” (raw), care pot fi obținute folosind nfsstat, precum și diverse cache-uri.
• /var/run/portmap_mapping- informatii despre serviciile inregistrate in RPC

Notă: În general, există o mulțime de interpretări și formulări ale scopului fișierelor xtab, etab, rmtab pe Internet, nu știu pe cine să cred Nici pe http://nfs.sourceforge.net/ interpretarea nu este clară .

Configurarea fișierului /etc/exports

În cel mai simplu caz, /etc/exports este singurul fișier care trebuie editat pentru a configura un server NFS. Acest fișier controlează următoarele aspecte:

• Care clienți poate accesa fișierele de pe server
• Care ierarhii? directoarele de pe server pot fi accesate de fiecare client
• Cum vor fi numele personalizate de clienți afișat la nume de utilizator locale

Fiecare linie din fișierul de export are următorul format:

exportpoint client1(opțiuni) [client2(opțiuni) ...]

Unde punct_export calea absolută a ierarhiei directoarelor exportate, client1 - n numele unuia sau mai multor clienți sau adrese IP, separate prin spații, cărora li se permite montarea punct_export . Opțiuni descrie regulile de montare pentru client inainte de Opțiuni .

Iată un tipic exemplu de configurare a fișierelor de export:

ARCHIV ~ # cat /etc/exports /archiv1 files(rw,sync) 10.0.0.1(ro,sync) 10.0.230.1/24(ro,sync)

În acest exemplu, fișierele computerelor și 10.0.0.1 au acces la punctul de export /archiv1, în timp ce gazda fișierelor este de citire/scriere, iar gazda 10.0.0.1 și subrețeaua 10.0.230.1/24 sunt doar pentru citire.

Descrierile gazdelor din /etc/exports sunt permise în următorul format:

• Numele de noduri individuale sunt descrise ca fișiere sau fișiere.DOMAIN.local.
• Descrierea măștii de domeniu se face în următorul format: *DOMAIN.local include toate nodurile domeniului DOMAIN.local.
• Subrețelele sunt specificate ca perechi adresă IP/mască. De exemplu: 10.0.0.0/255.255.255.0 include toate gazdele ale căror adrese încep cu 10.0.0.
• Specificarea numelui netgroup @myclients care are acces la resursă (atunci când se utilizează un server NIS)

Opțiuni generale de export pentru ierarhiile de catalog

Următoarele opțiuni generale sunt utilizate în fișierul de exporturi(în primul rând, sunt indicate opțiunile utilizate implicit în majoritatea sistemelor, cele care nu sunt implicite între paranteze):

• auth_nlm (nu_auth_nlm) sau secure_locks (blocuri_nesigure)- specifică faptul că serverul ar trebui să necesite autentificarea cererilor de blocare (folosind protocolul NFS Lock Manager).
• ascunde (ascunde)- dacă serverul exportă două ierarhii de directoare, cu una imbricată (montată) în cealaltă. Clientul trebuie să monteze în mod explicit a doua ierarhie (copil), altfel punctul de montare al ierarhiei copil va apărea ca un director gol. Opțiunea nohide are ca rezultat o a doua ierarhie de director fără o montare explicită. ( Notă: Nu am reușit să fac această opțiune să funcționeze...
• ro(rw)- Permite numai cereri de citire (scriere). (În cele din urmă, dacă citirea/scrierea este posibilă sau nu este determinată pe baza permisiunilor sistemului de fișiere, în timp ce serverul nu este capabil să distingă între o solicitare de citire a fișierului și o solicitare de execuție, deci permite citirea dacă utilizatorul are permisiuni de citire sau executare .)
• sigur (nesigur)- necesită ca cererile NFS să provină din porturi securizate (< 1024), чтобы программа без прав root не могла монтировать иерархию каталогов.
• subtree_check (fără_subtree_check)- Dacă este exportat un subdirector al sistemului de fișiere, dar nu întregul sistem de fișiere, serverul verifică dacă fișierul solicitat se află în subdirectorul exportat. Dezactivarea verificării reduce securitatea, dar crește viteza de transfer al datelor.
• sincronizare (async) Specifică faptul că serverul trebuie să răspundă la solicitări numai după ce modificările făcute de aceste solicitări au fost scrise pe disc. Opțiunea asincronă îi spune serverului să nu aștepte ca informațiile să fie scrise pe disc, ceea ce îmbunătățește performanța, dar reduce fiabilitatea. Pierderea informațiilor este posibilă dacă conexiunea este întreruptă sau echipamentul eșuează.
• wdelay (fără_wdelay)- instruiește serverul să întârzie executarea cererilor de scriere dacă o cerere de scriere ulterioară este în așteptare, scriind datele în blocuri mai mari. Acest lucru îmbunătățește performanța la trimiterea unor cozi mari de comenzi de scriere. no_wdelay specifică să nu întârzie execuția comenzii de scriere, ceea ce poate fi util dacă serverul primește un număr mare de comenzi care nu au legătură între ele.

Exportați linkuri simbolice și fișiere de dispozitiv. Când exportați o ierarhie de directoare care conțin legături simbolice, obiectul link trebuie să fie disponibil pentru sistemul client (la distanță), adică una dintre următoarele reguli trebuie să fie adevărată:

Fișierul dispozitivului se referă la interfață. Când exportați un fișier de dispozitiv, această interfață este exportată. Dacă sistemul client nu are un dispozitiv de același tip, atunci dispozitivul exportat nu va funcționa. Pe sistemul client, la montarea obiectelor NFS, opțiunea nodev poate fi utilizată, astfel încât fișierele dispozitivului din directoarele montate să nu fie folosite.

Opțiunile implicite variază de la sistem la sistem și pot fi găsite în /var/lib/nfs/etab. După descrierea directorului exportat în /etc/exports și repornirea serverului NFS, orice opțiuni lipsă (a se citi: opțiuni implicite) vor fi reflectate în fișierul /var/lib/nfs/etab.

Opțiuni de afișare (potrivire) pentru ID-urile de utilizator

Pentru o mai bună înțelegere a celor de mai jos, vă sfătuiesc să citiți articolul. Fiecare utilizator Linux are propriul său UID și GID principal, care sunt descrise în fișiere /etc/passwdși /etc/group. Serverul NFS consideră că sistemul de operare al gazdei de la distanță a autentificat utilizatorii și le-a atribuit UID-ul și GID-ul corect. Exportarea fișierelor oferă utilizatorilor sistemului client același acces la acele fișiere ca și cum s-ar conecta direct la server. În consecință, atunci când un client NFS trimite o solicitare către server, serverul folosește UID și GID pentru a identifica utilizatorul pe sistemul local, ceea ce poate duce la unele probleme:

• este posibil ca un utilizator să nu aibă aceleași identități pe ambele sisteme și, prin urmare, poate să poată accesa fișierele altui utilizator.
• deoarece Deoarece ID-ul utilizatorului root este întotdeauna 0, atunci acest utilizator este mapat la utilizatorul local, în funcție de opțiunile specificate.

Următoarele opțiuni stabilesc regulile pentru afișarea utilizatorilor de la distanță în cei locali:

• root_squash (fără_root_squash)- Cu opțiuni setate rădăcină_dovleac, solicitările de la utilizatorul root sunt mapate la uid/gid anonim sau la utilizatorul specificat în parametrul anonuid/anongid.
• no_all_squash (tot_squash)- Nu modifică UID/GID-ul utilizatorului care se conectează. Opțiune all_squash setează TOȚI utilizatorii (nu doar root) să fie afișați ca anonimi sau specificați în parametrul anonuid/anongid.
• anonuid= UID și anongid= GID - Setează în mod explicit UID/GID pentru un utilizator anonim.
• map_static= /etc/file_maps_users - Specifică un fișier care poate fi utilizat pentru a mapa UID-uri/GID-uri la distanță la UID-uri/GID-uri locale.

Un exemplu de utilizare a unui fișier de mapare utilizator:

ARCHIV ~ # cat /etc/file_maps_users # Maparea utilizatorilor # uid comentariu local la distanță 0-50 1002 # maparea utilizatorilor cu UID la distanță 0-50 la UID local 1002 gid 0-50 1002 # maparea utilizatorilor cu/interval la GID la distanță 0-50 la GID local 1002

Administrarea serverului NFS

Serverul NFS este gestionat folosind următoarele utilitare:

• nfsstat
• showmnumăr sigur (nesigur).

nfsstat: statistici NFS și RPC

Utilitarul nfsstat vă permite să vizualizați statisticile serverelor RPC și NFS. Opțiunile de comandă pot fi găsite în man nfsstat.

showmount: afișați informații despre starea NFS

utilitarul showmount interogează demonul rpc.mountd de pe gazda la distanță pentru sistemele de fișiere montate. În mod implicit, este returnată o listă sortată de clienți. Chei:

• --toate- este dată o listă de clienți și puncte de montare, indicând unde clientul a montat directorul. Este posibil ca aceste informații să nu fie de încredere.
• --directoare- lista punctelor de montare
• --exporturi- o listă a sistemelor de fișiere exportate este dată din punctul de vedere al nfsd

Rularea showmount fără argumente va imprima pe consolă informații despre sistemele care au voie să se monteze local directoare. De exemplu, host ARCHIV ne oferă o listă de directoare exportate cu adrese IP ale gazdelor cărora li se permite să monteze directoarele specificate:

FIȘIERE ~ # showmount --exports archive Exportați lista pentru arhivă: /archiv-big 10.0.0.2 /archiv-small 10.0.0.2

Dacă specificați un nume de gazdă/IP în argument, atunci vor fi afișate informații despre această gazdă:

ARCHIV ~ # showmount files clnt_create: RPC: Program not registered # acest mesaj ne spune că demonul NFSd nu rulează pe gazdă FILES

exportfs: gestionarea directoarelor exportate

Această comandă servește directoarele exportate specificate în fișier /etc/exports, ar fi mai precis să scrieți nu servește, ci se sincronizează cu fișierul /var/lib/nfs/xtabși le elimină pe cele inexistente din xtab. exportfs este executat când demonul nfsd este pornit cu argumentul -r. Utilitarul exportfs în modul kernel 2.6 vorbește cu demonul rpc.mountd prin fișierele din directorul /var/lib/nfs/ și nu vorbește direct cu nucleul. Fără parametri, returnează o listă a sistemelor de fișiere exportate în prezent.

opțiuni exportfs:

• [client:dir-name] - adăugați sau eliminați sistemul de fișiere specificat pentru clientul specificat)
• -v - afișează mai multe informații
• -r - reexportă toate directoarele (sync /etc/exports și /var/lib/nfs/xtab)
• -u - eliminați din lista de export
• -a - adăugați sau eliminați toate sistemele de fișiere
• -o - opțiuni separate prin virgule (similar cu opțiunile utilizate în /etc/exports; astfel, puteți modifica opțiunile sistemelor de fișiere deja montate)
• -i - nu utilizați /etc/exports când adăugați, doar opțiunile liniei de comandă curente
• -f - resetează lista sistemelor exportate în nucleul 2.6;

Client NFS

Înainte de a accesa un fișier pe un sistem de fișiere la distanță, clientul (OS client) trebuie să montați-lși primiți de la server indicatorul spre ea. Montare NFS se poate face cu sau cu ajutorul unuia dintre prolificiele montatoare automate (amd, autofs, automount, supermount, superpupermount). Procesul de montare este bine demonstrat în ilustrația de mai sus.

Pe Clienți NFS nu trebuie porniți demoni, funcțiile clientului execută un modul kernel kernel/fs/nfs/nfs.ko, care este utilizat la montarea unui sistem de fișiere la distanță. Directoarele exportate de pe server pot fi montate pe client în următoarele moduri:

• manual folosind comanda mount
• automat la pornire, la montarea sistemelor de fișiere descrise în /etc/fstab
• automat cu demonul autofs

Nu voi lua în considerare a treia metodă cu autofs în acest articol, din cauza informațiilor sale voluminoase. Poate că în articolele următoare va fi o descriere separată.

Montarea sistemului de fișiere de rețea cu comanda mount

Un exemplu de utilizare a comenzii mount este prezentat în postare. Aici mă voi uita la un exemplu de comandă mount pentru montarea unui sistem de fișiere NFS:

FIȘIERE ~ # mount -t nfs arhiv:/archiv-small /archivs/archiv-small FIȘIERE ~ # mount -t nfs -o ro arhiv:/archiv-big /archivs/archiv-big FIȘIERE ~ # mount ..... .. arhiv:/archiv-small pe /archivs/archiv-small tip nfs (rw,addr=10.0.0.6) arhiv:/archiv-big pe /archivs/archiv-big tip nfs (ro,addr=10.0.0.6)

Prima comandă montează directorul exportat /arhiv-mic pe server Arhiva la punctul de montare local /archivs/archiv-small cu opțiuni implicite (adică citire și scriere). Cu toate că comanda de montareîn cele mai recente distribuții, poate înțelege ce tip de sistem de fișiere este utilizat chiar și fără a specifica tipul, totuși specifica parametrul -tnfs de dorit. A doua comandă montează directorul exportat /arhiv-mare pe server Arhiva la directorul local /archivs/archiv-big cu opțiune numai pentru citire ( ro). comanda de montare fără parametri afișează clar rezultatul monturii. Pe lângă opțiunea de numai citire (ro), este posibil să specificați și altele opțiuni de bază de montare NFS:

• nosuid- Această opțiune dezactivează execuția programelor din directorul montat.
• nodev(fără dispozitiv) - Această opțiune dezactivează caracterele și blochează fișierele speciale ca dispozitive.
• blocare (fara blocare)- Activează blocarea NFS (implicit). nolock dezactivează blocarea NFS (nu pornește demonul lockd) și este util atunci când aveți de-a face cu servere mai vechi care nu acceptă blocarea NFS.
• mounthost=nume- Numele gazdei care rulează demonul de montare NFS este mountd.
• mountport=n - Portul folosit de demonul mountd.
• port=n- portul folosit pentru conectarea la serverul NFS (implicit este 2049 dacă demonul rpc.nfsd nu este înregistrat pe serverul RPC). Dacă n=0 (implicit), atunci NFS trimite o solicitare către portmap de pe server pentru a determina portul.
• dimensiune=n(citiți dimensiunea blocului - citiți dimensiunea blocului) - Numărul de octeți citiți la un moment dat de pe serverul NFS. Valoarea implicită este 4096.
• wsize=n(mărimea blocului de scriere - dimensiunea blocului de scriere) - Numărul de octeți scriși la un moment dat pe serverul NFS. Valoarea implicită este 4096.
• tcp sau udp- Pentru a monta NFS, utilizați TCP sau, respectiv, UDP.
• bg- Dacă pierdeți accesul la server, reîncercați în fundal pentru a nu bloca procesul de pornire a sistemului.
• fg- Dacă pierdeți accesul la server, încercați din nou în modul prioritar. Această opțiune poate bloca procesul de pornire a sistemului prin reîncercări de montare. Din acest motiv, opțiunea fg este folosită în primul rând în scopuri de depanare.

Opțiuni care afectează memorarea în cache a atributelor pe monturile NFS

Atributele fișierului, stocate în (inoduri), cum ar fi timpul de modificare, dimensiunea, legăturile hard, proprietarul, se schimbă de obicei rar pentru fișierele obișnuite și chiar mai rar pentru directoare. Multe programe, cum ar fi ls, accesează fișiere numai în citire și nu modifică atributele sau conținutul fișierelor, ci risipesc resursele sistemului cu operațiuni costisitoare de rețea. Pentru a evita irosirea resurselor, poți atributele datelor din cache. Nucleul folosește timpul de modificare a unui fișier pentru a determina dacă memoria cache este învechită, comparând timpul de modificare din cache și timpul de modificare a fișierului însuși. Cache-ul de atribute este actualizat periodic în funcție de parametrii specificați:

• ac (noac) (cache de atribute- attribute caching) - Activați attribute caching (implicit). Deși opțiunea noac încetinește serverul, evită îmbătrânirea atributelor atunci când mai mulți clienți scriu în mod activ informații într-o ierarhie comună.
• acdirmax=n (directorul cache al atributelor maxim- cache maximă a atributelor pentru fișierul director) - Numărul maxim de secunde pe care NFS așteaptă înainte de a actualiza atributele directorului (implicit 60 sec.)
• acdirmin=n (directorul cache al atributului minim- cache minimă a atributelor pentru fișierul director) - Numărul minim de secunde de așteptare NFS înainte de a actualiza atributele directorului (30 de secunde în mod implicit)
• accregmax=n (cache de atribute maxim fișier normal- cache maximă a atributelor pentru un fișier normal) - Numărul maxim de secunde pe care NFS așteaptă înainte de a actualiza atributele unui fișier normal (implicit 60 sec.)
• aregmin=n (cache de atribute fișier obișnuit minim- cache minimă a atributelor pentru un fișier obișnuit) - Numărul minim de secunde pe care NFS așteaptă înainte de a actualiza atributele unui fișier obișnuit (implicit 3 sec.)
• actimeo=n (timeout cache-ul atributului- timeout caching atribute) - Suprascrie valorile pentru toate opțiunile de mai sus. Dacă actimeo nu este setat, atunci valorile de mai sus sunt implicite.

Opțiuni de tratare a erorilor NFS

Următoarele opțiuni controlează ce face NFS atunci când nu există niciun răspuns de la server sau când apar erori I/O:

• fg (bg) (prim plan- prim plan, fundal- fundal) - Încercați să montați un NFS eșuat în prim-plan/în fundal.
• greu moale)- afișează mesajul „serverul nu răspunde” la consolă când este atins timeout-ul și continuă încercările de montare. Cu opțiunea dată moale- on timeout informează programul care a apelat operația despre o eroare I/O. (se recomandă să nu utilizați opțiunea soft)
• nointr(intr) (nicio întrerupere- nu anulați) - Împiedică semnalele de la anularea operațiunilor de fișiere într-o ierarhie de directoare montată greu atunci când este atins un timeout mare. intr- activați întreruperea.
• retrans=n (valoarea de retransmisie- valoarea retransmisie) - După n timeout-uri mici, NFS generează un timeout mare (implicit 3). Un timeout mare încheie operațiunile sau tipărește un mesaj „serverul nu răspunde” pe consolă, în funcție de opțiunea hard/soft specificată.
• reîncercați=n (valoare de reîncercare- valoare de reîncercare) - Numărul de minute în care NFS reîncercă montarea înainte de a renunța (implicit 10000).
• timeo=n (valoarea timeout- valoarea timeout) - numărul de zecimi de secundă pe care serviciul NFS le așteaptă înainte de a retransmite în cazul RPC sau timeout scăzut (implicit 7). Această valoare este incrementată la fiecare timeout până la o valoare maximă de 60 de secunde sau până când apare un timeout mare. Dacă rețeaua este ocupată, serverul este lent sau cererea trece prin mai multe routere sau gateway-uri, creșterea acestei valori poate îmbunătăți performanța.

Montare automată NFS la pornire (descrierea sistemelor de fișiere în /etc/fstab)

Puteți selecta timpul optim pentru o anumită valoare a pachetului transmis (valori rsiize / wsize) folosind comanda ping:

FIȘIERE ~ # ping -s 32768 arhiv PING arhiv.DOMAIN.local (10.0.0.6) 32768(32796) octeți de date. 32776 octeți din archiv.domain.local (10.0.0.6): icmp_req=1 ttl=64 time=0,931 ms de archiv.domain.local (10.0.0.6): icmp_req=3 ttl=64 time=1,03 ms 32776 bytes .local (10.0.0.6): icmp_req=5 ttl=64 time=1.08 ms ^C --- archive.DOMAIN.local statistics ping --- 5 pachete transmise, 5 primite, 0% pierdere de pachete, timp 4006ms rtt min/ avg/max/mdev = 0,931/1,002/1,083/0,061 ms

După cum puteți vedea, atunci când trimiteți un pachet de dimensiunea 32768 (32Kb), timpul său de călătorie de la client la server și înapoi plutește în jur de 1 milisecundă. Dacă acest timp iese din scară pentru 200 ms, atunci ar trebui să vă gândiți la creșterea valorii timeo, astfel încât să depășească valoarea de schimb de trei până la patru ori. În consecință, este recomandabil să faceți acest test în timpul unei sarcini grele de rețea.

Pornirea NFS și configurarea paravanului de protecție

Nota a fost copiată de pe blogul http://bog.pp.ru/work/NFS.html, pentru care îi mulțumesc mult!!!

Porniți serverul NFS, montați, blocați, cota și starea cu porturile „corecte” (pentru firewall)

• este de dorit să se prealeze toate resursele de pe clienți
• opriți și dezactivați pornirea rpcidmapd dacă NFSv4 nu este planificat: chkconfig --level 345 rpcidmapd off service rpcidmapd stop
• dacă este necesar, activați serviciile portmap, nfs și nfslock să pornească: chkconfig --levels 345 portmap/rpcbind pe chkconfig --levels 345 nfs pe chkconfig --levels 345 nfslock pe
• opriți serviciile nfslock și nfs dacă este necesar, porniți portmap/rpcbind, descărcați modulele service nfslock stop service nfs stop service portmap start # service rpcbind start umount /proc/fs/nfsd service rpcidmapd stop rmmod nfsd service autofs stop # undeva mai târziu trebuie să rulați it rmmod nfs rmmod nfs_acl rmmod lockd
• deschide porturi în
  • pentru RPC: UDP/111, TCP/111
  • pentru NFS: UDP/2049, TCP/2049
  • pentru rpc.statd: UDP/4000, TCP/4000
  • pentru blocare: UDP/4001, TCP/4001
  • pentru mountd: UDP/4002, TCP/4002
  • pentru rpc.rquota: UDP/4003, TCP/4003
• pentru serverul rpc.nfsd, adăugați linia RPCNFSDARGS="--port 2049" la /etc/sysconfig/nfs
• pentru serverul de montare, adăugați linia MOUNTD_PORT=4002 la /etc/sysconfig/nfs
• pentru a configura rpc.rquota pentru versiuni noi, trebuie să adăugați linia RQUOTAD_PORT=4003 la /etc/sysconfig/nfs
• pentru a configura rpc.rquota necesar pentru versiunile mai vechi (cu toate acestea, trebuie să aveți pachetul quota 3.08 sau mai nou) adăugați la /etc/services rquotad 4003/tcp rquotad 4003/udp
• verificați /etc/exports pentru valabilitate
• porniți serviciile rpc.nfsd, mountd și rpc.rquota (în același timp sunt pornite rpcsvcgssd și rpc.idmapd dacă vă amintiți să le ștergeți) service nfsd start sau în versiunile mai noi service nfs start
• pentru serverul de blocare pentru sisteme noi, adăugați liniile LOCKD_TCPPORT=4001 LOCKD_UDPPORT=4001 la /etc/sysconfig/nfs
• pentru un server de blocare pentru sisteme mai vechi adăugați direct la /etc/modprobe[.conf]: opțiuni lockd nlm_udpport=4001 nlm_tcpport=4001
• legați serverul de stare rpc.statd la portul 4000 (pentru sisteme mai vechi rulați rpc.statd cu -p 4000 în /etc/init.d/nfslock) STATD_PORT=4000
• start lockd și rpc services.statd service nfslock start
• asigurați-vă că toate porturile sunt legate corect cu „lsof -i -n -P” și „netstat -a -n” (unele porturi sunt folosite de modulele kernel pe care lsof nu le vede)
• dacă înainte de „reconstruire” serverul a fost folosit de clienți și nu au putut fi demontați, atunci va trebui să reporniți serviciile de montare automată pe clienți (am-utils , autofs)

Exemplu de configurare a serverului și clientului NFS

Configurare server

Dacă doriți să faceți directorul dvs. partiționat NFS deschis și inscriptibil, puteți utiliza opțiunea all_squashîn combinație cu opțiuni anonimși anonim. De exemplu, pentru a seta permisiuni pentru utilizatorul „nimeni” din grupul „nimeni”, puteți face următoarele:

ARCHIV ~ # cat /etc/exports # Acces de citire/scriere pentru client la 192.168.0.100, cu acces rw pentru utilizatorul 99 cu gid 99 /fișiere 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99) ) # Acces de citire și scriere pentru client la 192.168.0.100, cu acces rw pentru utilizatorul 99 cu gid 99 /fișiere 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99))

Aceasta înseamnă, de asemenea, că, dacă doriți să permiteți accesul la directorul specificat, nobody.nobody trebuie să fie proprietarul directorului partajat:

man mount
omul exportă
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/nfs_perf.htm - Performanță NFS de la IBM.

Cu stimă, Mc.Sim!

Direcționez instrucțiuni pentru instalarea și configurarea NFS (Network File System). NFS este un sistem de fișiere de rețea care vă permite să accesați fișiere și directoare de pe un computer (server) la distanță ca și cum acele fișiere și directoare ar fi locale. Principalul avantaj al unui astfel de sistem este că stațiile de lucru individuale pot folosi mai puțin spațiul pe disc, deoarece datele partajate sunt stocate pe o mașină separată (magazin de date) și sunt disponibile pentru alte mașini din rețea. NFS este o aplicație client-server în care rolul de stocare este atribuit serverului. Fiecare membru al rețelei este un client NFS care montează unitatea de rețea a serverului în sistemul său de fișiere.

Să luăm Ubuntu 12.04 ca server.
Vom folosi și testa Centos și Winows 7 ca clienți.

Server principal: 192.168.2.213 (Ubuntu)

Clienți: 192.168.2.72 (Centos), 192.168.2.180 (Windows)

Ajustarea serverului

Mai întâi trebuie să configurați serverul. Deoarece vom folosi Ubuntu ca server, trebuie să instalăm pachetul corespunzător

[email protected]:~# apt-get install nfs-kernel-server

După instalarea pachetului necesar, am creat două fișiere de configurare. Din jurnalul de instalare:

… Se creează fișierul de configurare /etc/idmapd.conf cu noua versiune. Se creează fișierul de configurare /etc/default/nfs-common cu noua versiune...

Primul fișier descrie utilizatorul (creat la instalarea pachetului) și grupul, pentru a participa la mapping-e (identificarea utilizatorului).

[email protected]:~# cat /etc/idmapd.conf Verbosity = 0 Pipefs-Directory = /run/rpc_pipefs # setează-ți propriul domeniu aici, dacă id-ul diferă de FQDN minus hostname # Domain = localdomain Nimeni-Utilizator = nimeni Nimeni-Grup = niciun grup

După cum știm, în Linux, fiecare fișier aparține unui anumit utilizator care are propriul său (UID, GID), dar pe sistemele Windows, schema este ușor diferită. Și în acest sens, a fost inventat mecanismul de mapare, care face ca traducerea diferiților utilizatori din diferite sisteme de operare într-o formă să fie ușor de înțeles pentru sistemul de fișiere Linux.
Al doilea fișier este necesar pentru a configura autentificarea Kerberos și a configura un port non-standard pe care demonul va asculta. Încă nu avem nevoie de el. Configurația Kerberos va fi discutată în articolul următor.

[email protected]:~# cat /etc/default/nfs-common # Dacă nu setați valori pentru opțiunile NEED_, acestea vor fi încercate # autodetectate; acest lucru ar trebui să fie suficient pentru majoritatea oamenilor. Alternativele valide # pentru opțiunile NEED_ sunt „da” și „nu”. # Doriți să porniți demonul statd? Nu este necesar pentru NFSv4. NEED_STATD= # Opțiuni pentru rpc.statd. # Ar trebui rpc.statd să asculte pe un anumit port? Acest lucru este util mai ales # când aveți un firewall bazat pe porturi. Pentru a utiliza un port fix, setați această # variabilă la un argument statd precum: „--port 4000 --outgoing-port 4001”. # Pentru mai multe informații, consultați rpc.statd(8) sau http://wiki.debian.org/SecuringNFS STATDOPTS= # Doriți să porniți demonul gssd? Este necesar pentru monturile Kerberos. NEED_GSSD=

Acum să continuăm cu configurarea.
Toate directoarele pentru partajare trebuie să fie înregistrate în fișierul /etc/exports. Pentru început, să creăm 2 foldere în directorul principal și să aruncăm fișierele în ele. Arborele directoarelor și fișierelor pentru export:

[email protected]:~# arbore /home/alex/ /home/alex/

Acum trebuie să atribuiți un utilizator și un grup pentru aceste directoare (le luăm din fișierul /etc/idmapd.conf).

[email protected]:~# chown -R nimeni:nogroup nfs_dir1/ [email protected]:~# chown -R nimeni:nogroup nfs_dir2/

Mai întâi, să exportăm directorul nfs_dir1 pentru un anumit IP. Editarea fișierului /etc/exprots.

[email protected]:~# vim /etc/exports # Pentru o anumită gazdă (Windows) /home/alex/nfs_dir1 192.168.2.180(rw,sync,all_squash,no_subtree_check,insecure) # Pentru orice gazdă de pe subrețea /home/alex/nfs_dir2 192. .2.0/ 24(rw,no_root_squash,sync,no_subtree_check)

Aici puteți vedea setul minim de opțiuni pentru funcționarea corectă a stocării cu sistemul de operare Windows.

• /home/alex/nfs_dir1– calea către folderul pentru care se distribuie accesul;
• 192.168.2.180 – Adresa IP la care este distribuit accesul la folder (puteți specifica întreaga rețea, apoi intrarea va arăta ca 192.168.2.0/24)
• (rw,sync,all_squash,no_subtree_check)- un set de opțiuni.

Opțiuni populare:

• rw–read/write (poate lua valoarea ro-read-only);
• no_root_squash– implicit, utilizatorul root de pe computerul client nu va avea acces la directorul partajat al serverului. Cu această opțiune, eliminăm această limitare. Din motive de securitate, este mai bine să nu faci asta;
• sincronizare- mod de acces sincron (poate lua valoarea opusă - asincron);
• fără acces– Interzice accesul la directorul specificat. Poate fi util dacă ați setat anterior accesul pentru toți utilizatorii rețelei la un anumit director, iar acum doriți să restricționați accesul într-un subdirector doar la unii utilizatori.
• all_squash- implică faptul că toate conexiunile vor fi făcute de la un utilizator anonim (necesar pentru un client Windows)
• anonuid= 1000 - leagă un utilizator anonim de un utilizator „local”;
• anongid= 1000 - leagă utilizatorul anonim de grupul de utilizator „local”.
• no_subtree_check(subtree_check)– dacă se exportă un subdirector al sistemului de fișiere, dar nu întregul sistem de fișiere, serverul verifică dacă fișierul solicitat se află în subdirectorul exportat. Dezactivarea verificării reduce securitatea, dar crește viteza de transfer al datelor.
• De obicei, Linux (și alte sisteme de operare asemănătoare Unix) rezervă porturile TCP și UDP de la 1-1023 (așa-numitele porturi securizate) pentru a fi utilizate de către procesele utilizatorului root. Pentru a se asigura că root a fost cel care a inițiat conexiunea la distanță NFS, serverul NFS solicită de obicei clienților la distanță să folosească porturi securizate. Această convenție, însă, nu este respectată de unele sisteme de operare (de ex. Windows). În astfel de cazuri, opțiunea nesigur permite clientului NFS să utilizeze orice port TCP/UDP. De obicei, este necesar atunci când deserviți clienții Windows.

Toate opțiunile și sintaxa disponibile pentru înregistrarea gazdelor, a grupurilor de gazde etc. poate fi citit in manual

[email protected]:~# exportfs -a

Acum verificăm ce am exportat.

[email protected]:~# exportfs -v /home/alex/nfs_dir1 192.168.2.180(rw,wdelay,all_squash,no_subtree_check,necure) /home/alex/nfs_dir2 192.168.2.0/24(rw,wdelay,wdelay)subtree_check,no_rot_check,nesigur

Serverul este configurat.

Stabilirea clienților

Configurare client Windows

Dacă nu ar exista mesaje de eroare. Puteți începe montarea pe partea clientului.
Mai întâi, trebuie să adăugați serviciul (serviciu client) NFS. Pentru a face acest lucru, accesați Start —> Panou de control —> Programe și caracteristiciși faceți clic pe elementul de meniu din stânga Activați sau dezactivați funcțiile Windows. În fereastra care apare, selectați Client pentru NFSși faceți clic O.K(Fig. 1).

Poza 1

Apoi, trebuie să montați unitatea. Pentru a face acest lucru, puteți utiliza linia de comandă sau pur și simplu faceți clic Faceți clic dreapta pe My Computer și selectați Map Network Drive. Și introduceți linia \\192.168.2.213\home\alex\nfs_dir1. Acesta este IP-ul serverului și calea către folder (Fig. 2).

Figura 2

Dacă totul este în regulă, vom vedea discul (Fig. 3).

Figura 3

Același lucru se poate face folosind linia de comandă (Fig. 4).

Figura 4

Posibile greșeli:

Nu veți putea mapa o unitate de rețea NFS la sistemul de operare Windows (Figura 5) dacă
1. Clientul NFS nu este instalat
2. Firewall activat (neconfigurat).
3. Fără acces la rețea la server
4. Au fost introduse opțiuni de montare incorecte
5. Export neconfigurat (setări neaplicate) pe server.
6. Adăugați opțiunea nesigură în setările de export

Figura 5 - Eroare la conectarea unei unități NFS de rețea

Nu veți putea adăuga un fișier la un sistem de fișiere montat (Figura 6) dacă:
1. Drepturile asupra folderului nu sunt setate pe server (nobody:nogroup)
2. Opțiunea all_squash nu este setată în setările de export
3. Opțiunea rw nu este setată în setările de export

Figura 6 - Eroare la adăugarea unui fișier pe un disc NFS

Configurarea clientului Centos

Configurarea sistemelor Linux este destul de simplă și nedureroasă. Trebuie doar să instalați pachetele necesare și să montați discul. Centos are nevoie de următoarele pachete

# yum install nfs-utils nfs-utils-lib

# mkdir -p /mnt/nfs # mount 192.168.2.213:/home/alex/nfs_dir1 /mnt/nfs # mount /dev/mapper/vg_slave-lv_root on / type ext4 (rw) proc on /proc type proc (rw) sysfs pe /sys tip sysfs (rw) devpts pe /dev/pts tip devpts (rw,gid=5,mode=620) tmpfs pe /dev/shm tip tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0" ) /dev/sda1 pe /boot tip ext4 (rw) niciunul pe /proc/sys/fs/binfmt_misc tip binfmt_misc (rw) sunrpc pe /var/lib/nfs/rpc_pipefs tip rpc_pipefs (rw) 192.218./16. alex/nfs_dir1 pe /mnt/nfs tip nfs (rw,vers=4,addr=192.168.2.213,clientaddr=192.168.2.72)

În acest caz, putem adăuga orice fișier și director în folderul montat nfs_dir1 în numele oricărui utilizator de sistem ( all_squash). Dar dacă montam al doilea folder nfs_dir2, atunci DOAR root poate scrie în el, deoarece există o opțiune no_root_squash. Verificăm.

# mkdir /mnt/dir1 # mkdir /mnt/dir2 # mount 192.168.2.213:/home/alex/nfs_dir1 /mnt/dir1 # mount 192.168.2.213:/home/alex/nfs_dir2 /mnt/dir2 sau # mount -t -o rw,hard,intr,bg 192.168.2.213:/home/alex/nfs_dir2 /mnt/dir2 # echo "Hello" > /mnt/dir1/file1 # echo "Hello" > /mnt/dir2/file1 # su alex $ echo "Bună ziua" > /mnt/dir1/file1 $ echo "Bună ziua" > /mnt/dir2/file1 bash: /mnt/dir2/file1: Permisiune refuzată

Posibile steaguri de montare.

De asemenea, puteți verifica din consolă dacă serverul a exportat corect sistemul de fișiere.

[email protected]~# showmount -e 192.168.2.213 Exportați lista pentru 192.168.2.213: /home/alex/nfs_dir2 192.168.2.0/24 /home/alex/nfs_dir1 192.168.2.180

Adăugați suport la încărcarea automată

# cat /etc/fstab ... 192.168.2.213:/home/alex/nfs_dir2 /mnt/dir2 nfs4 rw,bg,intr,hard,nodev,nosuid 0 0

[email protected]~# mount -a -t nfs4

Posibile greșeli.

[email protected]~# mount -a -t nfs4 mount.nfs4: punctul de montare /mnt/dir2 nu există [email protected]~# mount -a -t nfs4 mount.nfs4: partajarea la distanță nu este în format „gazdă:dir”

În primul caz, trebuie să creați un folder. În al doilea - erori de sintaxă în fstab.
Dacă întâmpinați erori la montarea partițiilor NFS, parcurgeți lista Posibile greșeli din secțiunea anterioară.
De asemenea, puteți utiliza autofs pentru a monta partiții NFS. Ce se va discuta în.

O soluție convenabilă pentru accesarea unui sistem de fișiere distribuit

Sistemul de fișiere este o necesitate. Lucrăm pe computere care oferă acces la imprimante, camere, baze de date, senzori de la distanță, telescoape, compilatoare și telefoane mobile. Aceste dispozitive au puține în comun - în special, multe dintre ele au devenit realitate după ce internetul a devenit omniprezent (de exemplu, camerele electronice și dispozitivele mobile care acționează ca computere mici). Cu toate acestea, toți au nevoie de un sistem de fișiere pentru a stoca și a accesa în siguranță informațiile.

De obicei, nu ne interesează cum datele, aplicațiile care le folosesc și interfețele care ni le prezintă, sunt stocate în computerele în sine. Majoritatea utilizatorilor ar dori să vadă (și pe bună dreptate) sistemul de fișiere ca pe un perete care îi separă de metalul gol care stochează biți și octeți. Prin urmare, stivele de protocoale care conectează sistemele de fișiere rămân de obicei cutii negre pentru majoritatea utilizatorilor și, de fapt, programatori. Cu toate acestea, în cele din urmă, organizarea conectării în rețea a tuturor acestor dispozitive se reduce la a permite schimbul de date între sistemele de fișiere.

Sisteme de fișiere de rețea și alte sacramente

În multe privințe, schimbul de date nu este altceva decât copierea informațiilor pe distanțe lungi. Protocoalele de rețea nu au fost singurele mijloace prin care comunicarea universală a devenit posibilă. La urma urmei, fiecare sistem informatic trebuie să transforme datagramele în ceva de înțeles de sistemul de operare de la celălalt capăt. TCP este un protocol de transfer foarte eficient, dar nu este optimizat pentru acces rapid la fișiere sau control de la distanță al aplicației software.

Computing distribuit vs. în rețea

Protocoalele de rețea tradiționale au puțin de oferit pentru organizarea calculatoarelor distribuite între calculatoare și, cu atât mai mult, între rețele. Doar programatorii nesăbuiți s-ar baza pe protocolul de transfer de date și pe cablurile optice pentru calculul paralel. De obicei ne bazăm pe un model serial, în care, după ce se stabilește o conexiune, protocoalele de nivel de legătură încep să funcționeze, efectuând o procedură de salut destul de complicată între NIC-uri. Calculul paralel și sistemele de fișiere distribuite nu mai depind de IP sau Ethernet. În prezent, pur și simplu le putem ignora când vorbim despre performanță. Cu toate acestea, problemele de securitate sunt o altă problemă.

O piesă a puzzle-ului este modul în care fișierele sunt accesate pe un sistem informatic. Acum, pentru sistemul care accesează fișierele, este lipsit de importanță dacă fișierele necesare sunt disponibile pe un singur computer sau sunt localizate dintr-un anumit motiv pe mai multe computere. În prezent, semantica sistemului de fișiere și structurile de date ale sistemului de fișiere sunt două subiecte foarte diferite. Semantica unui sistem de fișiere Plan 9 sau a unui sistem de fișiere distribuit în stil AFS (Andrew File System) ascunde modul în care fișierele sunt organizate sau modul în care sistemul de fișiere este mapat la hardware și rețea. NFS nu ascunde neapărat modul în care fișierele și directoarele sunt stocate pe sistemele de fișiere la distanță, dar nici nu dezvăluie modul în care sunt stocate sistemele de fișiere, directoarele și fișierele hardware real.

NFS: Rezolvarea problemei UNIX

Accesarea unui sistem de fișiere distribuit, totuși, necesită mai mult de câteva comenzi pentru a permite utilizatorilor să monteze un director care se află pe un alt computer din rețea. Sun Microsystems a întâlnit această problemă acum câțiva ani, când a început să distribuie ceva numit Apeluri de procedură de la distanță(RPC-uri) și NFS.

Principala problemă pe care Sun încerca să o rezolve era cum să conecteze mai multe mașini UNIX pentru a crea un singur mediu de operare distribuit fără a fi nevoie să rescrie semantica sistemului de fișiere UNIX și să adauge prea multe structuri de date distribuite specifice sistemului de fișiere - integritatea fiecărui sistem trebuia păstrată, permițând în același timp utilizatorilor să lucreze cu catalogul pe un computer diferit, fără a întâmpina întârzieri sau limitări nedorite în fluxul lor de lucru.

Desigur, NFS face mai mult decât să ofere acces la fișierele text. De asemenea, puteți distribui aplicații „în rulare” pe NFS. Procedurile de securitate servesc la protejarea rețelei de interferența rău intenționată a fișierelor executabile. Dar cum se întâmplă exact asta?

NFS este RPC

NFS a fost definit în mod tradițional ca o aplicație RPC care necesită TCP pentru serverul NFS și fie TCP, fie un alt protocol prietenos cu rețea pentru clientul NFS. Internet Engineering Task Force (IETF) a publicat un Request for Comments (RFC) pentru RPC în RFC 1832. Un alt standard vital pentru funcționarea unei implementări NFS descrie formatele de date utilizate de NFS; a fost publicat în RFC 1831 ca document „External Data Representation” (XDR).

Alte RFC-uri se ocupă de algoritmii de securitate și de criptare utilizați în schimbul de informații de autentificare în timpul sesiunilor NFS, dar ne vom concentra mai întâi pe mecanismele de bază. Unul dintre protocoalele care ne interesează este Protocolul de montare, descris în Anexa 1 la RFC 1813.

Acest RFC descrie ce protocoale fac NFS să funcționeze, dar nu descrie cum funcționează NFS timp prezent. Ați învățat deja ceva important și anume că protocoalele NFS sunt documentate sub forma standardelor IETF. După ce cea mai recentă versiune a NFS s-a blocat la numărul 3, protocoalele RPC nu au trecut de faza informațională a RFC și au fost în mare parte văzute ca în afara intereselor (probabil) imensului grup de lucru de inginerie Sun Microsystems și aromelor proprietare ale UNIX. Din 1985, Sun a lansat mai multe versiuni de NFS, precedând cu câțiva ani majoritatea sistemelor de fișiere actuale. Sun Microsystems a transferat controlul NFS către IETF în 1998, iar cea mai mare parte a lucrărilor privind versiunea 4 a NSF (NFSv4) a fost realizată sub auspiciile IETF.

Deci, atunci când lucrați cu RPC și NFS astăzi, lucrați cu o versiune care reflectă interesele companiilor și grupurilor din afara Sun. Cu toate acestea, mulți ingineri Sun rămân profund interesați de dezvoltarea NFS.

NFS versiunea 3

Implementarea NFS în versiunea sa 3 (NFSv3) este fără stat (nu cu stare), dar NFSv4 este. Această expresie fundamentală nu surprinde pe nimeni astăzi, deși lumea TCP/IP pe care este construit NFS este în mare parte apatridă, fapt care ajută companiile de analiză a traficului și software de securitate să se simtă destul de bine.

Protocolul NFSv3 a trebuit să se bazeze pe mai multe protocoale suplimentare pentru a monta în mod transparent directoarele pe computere la distanță, astfel încât să nu depindă de mecanismele sistemului de fișiere utilizate pe acestea. NFS nu a fost întotdeauna bun la asta. Un bun exemplu este că protocolul Mount a numit ID-ul inițial al unui fișier, în timp ce protocolul Network Lock Manager s-a ocupat de blocarea fișierului. Ambele operațiuni aveau nevoie de starea curentă, pe care protocolul NFSv3 nu a furnizat-o. În consecință, au existat interacțiuni complexe între straturile de protocol care nu au reflectat mecanisme similare de flux de date. În plus, dacă adăugați faptul că crearea fișierelor și a directoarelor în Microsoft® Windows® este complet diferită de cea în UNIX, situația devine și mai complicată.

Protocolul NFSv3 a trebuit să folosească porturi pentru a expune unele dintre protocoalele sale auxiliare; acest lucru creează o imagine destul de complexă a porturilor, a straturilor de protocol și a problemelor de securitate care vin odată cu aceasta. Astăzi, acest model de funcționare a fost abandonat, iar toate operațiunile care au fost efectuate anterior prin implementări de protocoale auxiliare prin porturi individuale sunt controlate de protocolul NFSv4 printr-un singur port binecunoscut.

Protocolul NFSv3 era, de asemenea, gata să funcționeze cu sisteme de fișiere care acceptau Unicode, un avantaj care a rămas oarecum pur teoretic până la sfârșitul anilor 1990. Se potrivea bine cu semantica sistemului de fișiere UNIX și a fost motivul pentru crearea unor implementări concurente ale sistemelor de fișiere, cum ar fi AFS și Samba. Nu este surprinzător că suportul Windows a fost slab, dar serverele de fișiere Samba au oferit partajarea fișierelor pentru sistemele UNIX și Windows.

NFS versiunea 4

Protocolul NFSv4 este, după cum am observat, un protocol cu ​​stare. Acest comportament a făcut posibile câteva schimbări radicale. Am menționat deja că protocoalele de ajutor ar trebui apelate, deoarece procesele la nivel de utilizator au fost eliminate. În schimb, toate operațiunile de deschidere a fișierelor și destul de multe apeluri RPC au fost implementate ca operațiuni de sistem de fișiere la nivel de kernel.

Toate versiunile NFS au definit fiecare unitate de lucru în ceea ce privește operațiunile client și server RPC. Fiecare cerere NFSv3 a necesitat un număr destul de semnificativ de apeluri RPC și apeluri de port deschis pentru a produce un rezultat. Versiunea 4 a simplificat acest lucru prin introducerea conceptului de așa-numit compozit operație (compusă), care include un număr mare de operații asupra obiectelor sistemului de fișiere. Efectul direct, desigur, a fost semnificativ mai puține apeluri RPC și mai puține date de transferat prin rețea, chiar dacă fiecare apel RPC a transportat, de fapt, mai multe date, în timp ce lucra mult mai mult. S-a estimat aproximativ că apelurile RPC în NFSv3 au necesitat de cinci ori mai multă cantitate de interacțiuni client/server în comparație cu procedurile RPC compuse.

RPC nu mai are atât de multă importanță și, în esență, servește ca un wrapper pentru mai multe operațiuni încapsulate în stiva NFSv4. De asemenea, această modificare a făcut ca stiva de protocoale să fie mult mai puțin dependentă de semantica sistemului de fișiere utilizat. Dar acest lucru nu înseamnă că operațiunile sistemului de fișiere ale altor sisteme de operare au fost ignorate: de exemplu, partajarea resurselor Windows necesită păstrarea stării în timpul apelurilor pentru a deschide resursa. Nu numai că starea facilitează analiza traficului, dar atunci când este implementată la nivel de semantică a sistemului de fișiere, face operațiunile sistemului de fișiere mult mai controlabile. Apelurile pentru deschiderea resurselor cu stare le permit clienților să memoreze în cache datele și starea fișierelor - ceva care altfel s-ar întâmpla pe server. În viața reală (unde clienții Windows sunt omniprezenti), ca serverele NFS să funcționeze în mod transparent și uniform cu resursele partajate Windows merită timpul petrecut pentru configurarea NFS.

Folosind NFS

Instalarea NFS este practic aceeași cu instalarea Samba. Pe partea de server, definiți sisteme de fișiere sau directoare de exportat sau partajarea; partea client montează aceste directoare. Odată ce un director NFS este montat de către un client la distanță, directorul devine accesibil la fel ca orice alt director din sistemul de fișiere local. Configurarea NFS pe un server este un proces simplu. Cel puțin, trebuie să creați sau să editați fișierul /etc/exports și să porniți demonul NFS. Pentru a configura un serviciu NFS mai sigur, trebuie să editați și fișierele /etc/hosts.allow și /etc/hosts.deny. Clientul NFS necesită doar executarea comenzii mount. Pentru mai multe informații și opțiuni, consultați documentația online Linux® (pagina de manual).

Server NFS

Intrările din fișierul /etc/exports au un format prietenos. Pentru a partaja un sistem de fișiere, modificați fișierul /etc/exports și descrieți sistemul de fișiere (cu opțiuni) în următorul format general:

Parametri comuni

Sunt disponibile mai multe opțiuni generale pentru a vă personaliza implementarea NFS. Acestea includ:

• sigur: Această opțiune (implicit) folosește un port TCP/IP disponibil mai mic de 1024 pentru conexiunea NFS. Sugestia nesigură împiedică acest lucru.
• rw: Această opțiune permite clienților NFS acces de citire/scriere. Accesul implicit este doar pentru citire.
• asincron: Această opțiune poate îmbunătăți performanța, dar poate provoca și pierderi de date dacă reporniți serverul NFS fără a opri mai întâi demonul NFS. Setarea implicită este sincronizare.
• no_wdelay: Această opțiune dezactivează întârzierea înregistrării. Dacă modul este setat la asincron, NFS ignoră această setare.
• ascunde: Dacă montați un director peste altul, directorul vechi este de obicei ascuns sau apare gol. Pentru a preveni acest comportament, activați parametrul ascundere.
• no_subtree_check: Această opțiune dezactivează controlul subdirectorului pentru unele verificări de securitate pe care este posibil să nu doriți să le ignorați. Setarea implicită este de a permite controlul subdirectorului.
• no_auth_nlm: Această opțiune, când este setată la insecure_locks, îi spune demonului NFS să nu se autentifice în timpul solicitărilor de blocare. Setarea implicită este auth_nlm sau secure_locks .
• mp (mountpoint=cale): Când se declară în mod explicit această opțiune, NSF solicită ca directorul exportat să fie montat.
• fsid=num: Această opțiune este utilizată de obicei atunci când se organizează un sistem de recuperare după o eroare NFS. Dacă doriți să implementați failoverul pentru NFS, consultați documentația NFS.

Afișează utilizatori

Prin maparea utilizatorilor la NFS, puteți identifica un pseudo-utilizator sau un utilizator real și grupați cu un utilizator care lucrează cu un volum NFS. Utilizatorul NFS are permisiuni de utilizator sau de grup pe care le permite maparea. Utilizarea unui singur utilizator (generic) și a unui grup pentru volumele NFS oferă un nivel de securitate și flexibilitate fără efort administrativ semnificativ.

Atunci când utilizați fișiere pe un sistem de fișiere montat pe NFS, accesul utilizatorului este de obicei „comprimat”. Aceasta înseamnă că utilizatorul accesează fișierele ca un utilizator anonim care are acces numai în citire la acele fișiere. Acest comportament este deosebit de important pentru utilizatorul root. Cu toate acestea, există situații în care doriți ca un utilizator să acceseze fișierele de pe sistemul de la distanță ca root sau alt utilizator specific. NFS vă permite să specificați un utilizator (prin numărul de identificare a utilizatorului (UID) și numărul de identificare a grupului (GID)) pentru a accesa fișierele de la distanță și puteți dezactiva comportamentul normal implicit de „suprimare”.

Opțiunile de afișare pentru utilizator includ:

• root_squash: Această setare împiedică utilizatorul root să acceseze un volum montat pe NFS.
• no_root_squash: Această opțiune permite utilizatorului root să acceseze volumul NFS montat.
• all_squash: Această setare, utilă pentru volumele NFS accesate public, suprimă toate UID-urile și GID-urile și utilizează numai contul de utilizator anonim. Setarea implicită este no_all_squash .
• anonuid și anongid: Aceste opțiuni schimbă UID-ul și GID-ul utilizatorului anonim în contul specificat.

Lista 1 prezintă exemple de intrări /etc/exports.

Listare 1. Exemple de intrări /etc/exports

Prima intrare exportă directorul /opt/files pentru toate gazdele din rețeaua 192.168.0. Următoarea intrare exportă /opt/fișiere pentru o gazdă: 192.168.0.120. A treia intrare specifică gazda 192.168.0.125 și acordă acces de citire/scriere la fișierele cu drepturi ale unui utilizator cu user id=210 și grup id=100. Ultima intrare este pentru directorul public și permite accesul numai în citire și numai sub contul de utilizator anonim.

Client NFS

Atenționări

Odată ce NFS este utilizat pentru a monta un sistem de fișiere la distanță, acesta va face, de asemenea, parte din orice copie de rezervă a sistemului partajată pe care o efectuați pe computerul client. Acest comportament poate avea rezultate potențial dăunătoare dacă nu excludeți directoarele montate atunci când faceți backup.

Pentru a utiliza NFS ca client, rpc.statd și portmap trebuie să ruleze pe computerul client. Puteți rula ps -ef pentru a verifica prezența acestor doi demoni. Dacă funcționează (cum ar trebui), puteți monta directorul exportat de server cu următoarea comandă generică:

În general, atunci când montați un sistem de fișiere, trebuie să rulați ca utilizator root. Pe computerul de la distanță, puteți utiliza următoarea comandă (presupunând că serverul NFS are o adresă IP de 192.168.0.100):

Distribuția sistemului dumneavoastră vă poate solicita să specificați tipul sistemului de fișiere atunci când îl montați. Dacă da, utilizați comanda:

Directorul de la distanță ar trebui să se monteze fără probleme dacă ați configurat corect serverul. Acum rulați comanda cd pentru a trece în directorul /mnt, apoi comanda ls pentru a vizualiza fișierele. Pentru a face o astfel de montare permanentă, trebuie să modificați fișierul /etc/fstab și să creați o intrare similară cu următoarea:

Notă: Pentru mai multe informații despre intrările /etc/fstab, consultați ajutorul online fstab.

Critica la adresa NFS

Critica conduce la îmbunătățire

Critica de securitate NFS a fost cauza multor îmbunătățiri ale NSFv4. Creatorii noii versiuni au luat măsuri reale pentru a consolida securitatea interacțiunilor client-server. De fapt, au decis să implementeze un model complet nou al sistemului de protecție.

Pentru a înțelege modelul sistemului de protecție, trebuie să fiți familiarizat cu interfața de programare a aplicației Servicii de securitate generice (GSS-API) versiunea 2, revizuirea 1. GSS-API este descris pe deplin în RFC 2743, care, din păcate, este unul dintre RFC-urile mai dificil de înțeles.

Știm din experiența noastră cu NFSv4 că nu este foarte ușor să faci un sistem de fișiere de rețea independent de sistemul de operare. Dar este și mai dificil să faci toate zonele sistemului de securitate independente de sistemul de operare și de protocoalele de rețea. Avem nevoie de amândouă, deoarece NFS trebuie să fie capabil să gestioneze un număr destul de mare de operațiuni ale utilizatorului și să facă acest lucru fără a ține cont de specificul comunicării protocolului de rețea.

Conexiunile dintre clienții NFS și servere sunt protejate de un așa-numit sistem de securitate (mai degrabă superficial). puternic RPC. NFSv4 folosește standardul ONCRPC (Open Network Computing Remote Procedure Call) definit în RFC 1831. Sistemul de securitate a trebuit să fie consolidat, așa că în loc de autentificare simplă (cunoscută ca AUTH_SYS) ca parte obligatorie a protocolului NFSv4, o variantă a sistemului de securitate bazat pe GSS-API cunoscută ca RPCSEC_GSS. Cele mai importante mecanisme de securitate disponibile în NFSv4 sunt Kerberos versiunea 5 și LIPKEY.

Dacă Kerberos are limitări atunci când este utilizat pe Internet, atunci LIPKEY are un avantaj frumos - acționând ca Secure Sockets Layer (SSL), solicită utilizatorilor numele de utilizator și parolele, evitând, în același timp, dependența TCP de SSL - o dependență pe care NFSv4 nu îl partajează. Puteți configura NFS pentru a implementa o formă de securitate dacă RPCSEC_GSS nu este necesar. Versiunile anterioare de NFS nu aveau această capacitate și, prin urmare, nu puteau oferi securitate de calitate, integritatea datelor, cerințe de autentificare sau tipuri de criptare.

Protocolul NFSv3 a fost supus unor critici semnificative în domeniul securității. Dacă serverele NFSv3 rulau peste TCP, era absolut fezabil să ruleze rețele NFSv3 pe Internet. Din păcate, au trebuit să fie deschise și mai multe porturi, rezultând mai multe găuri de securitate bine mediatizate. Făcând portul 2049 obligatoriu pentru NFS, a devenit posibil să se utilizeze NFSv4 cu firewall-uri fără a fi nevoie să acorde prea multă atenție la care porturi ascultau alte protocoale, cum ar fi protocolul Mount. Astfel, excepția protocolului Mount a avut mai multe efecte pozitive:

• Mecanisme de autentificare puternică obligatorii: NFSv4 a făcut ca mecanismele de autentificare puternice să fie obligatorii. Soiurile de Kerberos sunt destul de comune. Mecanismul de cheie publică a infrastructurii inferioare (LIPKEY) trebuie, de asemenea, să fie sprijinit. NFSv3 nu a suportat niciodată mai mult decât criptarea standard UNIX pentru autentificarea accesului - acest lucru a creat probleme majore de securitate în rețelele mari.
• Liste obligatorii de control al accesului (ACL) Scheme în stil Microsoft Windows NT Notă: Deși NFSv3 a permis criptarea puternică pentru autentificare, nu a folosit scheme de acces ACL în stil Windows NT. ACL-urile de tip Portable Operating System Interface (POSIX) au fost uneori implementate, dar nu au fost niciodată acceptate în general. NFSv4 a făcut ca ACL-urile în stil Windows NT să fie obligatorii.
• Mecanisme contractuale și stiluri de autentificare: NFSv4 a oferit capacitatea de a negocia mecanisme și stiluri de autentificare. În NSFv3, nu a fost posibil să se facă mai mult decât să se determine manual ce stil de criptare să folosească. Administratorul de sistem a trebuit apoi să negocieze protocoale de criptare și securitate.

NFS este încă în afara competiției?

NFSv4 înlocuiește NFSv3 pe majoritatea sistemelor UNIX și Linux. Ca sistem de fișiere de rețea, NSFv4 are puțini concurenți. Un concurent viabil ar fi Common Internet File System (CIFS)/Server Message Block (SMB), având în vedere că este prezent în toate variantele de Windows și (în prezent) Linux. AFS nu a avut niciodată un impact comercial prea mare; a subliniat elementele sistemelor de fișiere distribuite care au facilitat migrarea și replicarea datelor.

Versiunile Linux gata de utilizare ale NFS au fost lansate după ce nucleul a ajuns la versiunea 2.2, dar una dintre cele mai frecvente eșecuri ale versiunilor de nucleu Linux a fost că Linux a adoptat NFSv3 destul de târziu. De fapt, a trecut mult timp până când Linux a acceptat pe deplin NSFv3. Odată cu apariția NSFv4, acest neajuns a fost eliminat rapid, iar suportul complet pentru NSFv4 a fost implementat nu numai în Solaris, AIX și FreeBSD.

NFS este acum considerată o tehnologie matură care are un avantaj destul de mare: este sigură și convenabilă - majoritatea utilizatorilor au considerat convenabil să folosească o singură conectare securizată pentru a accesa rețeaua și a folosi funcțiile acesteia, chiar și atunci când fișierele și aplicațiile sunt localizate pe sisteme diferite. Deși acest lucru poate părea un dezavantaj în comparație cu sistemele de fișiere distribuite care ascund structurile de sistem de utilizatori, rețineți că multe aplicații folosesc fișiere care se află pe sisteme de operare diferite și, prin urmare, pe computere diferite. NFS facilitează lucrul cu diferite sisteme de operare fără a fi nevoie să vă faceți prea multe griji cu privire la semantica sistemelor de fișiere și la caracteristicile lor de performanță.