Sistem de fișiere NFS. Sistemul de fișiere de rețea UNIX

Bună ziua, cititori și invitați. A fost o pauză foarte lungă între postări, dar am revenit în acțiune). În articolul de astăzi mă voi uita Operarea protocolului NFS, ș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ă, unde 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ță cu criptare - sshfs, SFTP etc...). securitatea de prim plan a informațiilor 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. Acest lucru permite aplicațiilor locale să lucreze cu un sistem de fișiere la distanță ca și cum ar fi unul local. Dar trebuie să fii atent (!) cu configurarea NFS, deoarece cu o anumită configurație este posibil să înghețe sistemul de operare al clientului în așteptarea unei I/O fără sfârșit. Protocolul NFS bazat pe muncă Protocolul RPC, care este încă dincolo de înțelegerea mea)) așa că materialul din articol va fi puțin vag... Înainte de a putea folosi NFS, fie că este 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 uitându-vă la prezența liniilor 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 vă va permite cel mai probabil să instalați module dependente de kernel pentru a suporta sistemele de fișiere necesare. Dacă, după instalarea pachetelor, suportul NFS nu este afișat în fișierul specificat, atunci va trebui să activați această funcție.

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, rulând pe 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ă nu fie citite 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 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). Versiunea NFS v4.1 a fost aprobat de IESG în 2010 și a primit numărul . O inovație importantă în versiunea 4.1 este specificarea pNFS - Parallel NFS, un mecanism pentru accesul clientului NFS paralel 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 nor” distribuite.

Server NFS

Din moment ce avem NFS- Acest reţea sistem de fișiere, atunci este necesar. (Puteți citi și articolul). Următorul este necesar. Pe Debian, acesta este un pachet nfs-kernel-serverȘi nfs-comun, în RedHat acesta este un pachet nfs-utils. Și, de asemenea, trebuie să permiteți demonului să ruleze la nivelurile de execuție ale sistemului de operare necesare (comandă în RedHat - /sbin/chkconfig nfs activat, în Debian - Valorile implicite ale /usr/sbin/update-rc.d nfs-kernel-server).

Pachetele instalate în Debian sunt lansate î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ă începe primul 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. Despre nfs-comun Site-ul web debian ne spune textul acesta: fișiere partajate pentru client și server NFS, acest pachet trebuie instalat pe mașina care va funcționa ca client sau server NFS. Pachetul include programe: lockd, statd, showmount, nfsstat, gssd și idmapd. Vizualizarea conținutului scriptului de lansare /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 parametrii care necesită rularea demonilor 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 fișiere 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ă având-l în fișier /proc/sisteme de fișiere), dacă totul are succes, începe /usr/sbin/rpc.idmapd . În plus, pentru demon /usr/sbin/rpc.gssd verificări modulul nucleului 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), apoi puteți urma 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 specificat NEED_SVCGSD(setat în fișierul de setări server /etc/default/nfs-kernel-server) și, dacă este dat, pornește demonul /usr/sbin/rpc.svcgssd , lansează demonul ultimul /usr/sbin/rpc.mountd . Din acest scenariu este clar că Operarea serverului NFS constă în demonii rpc.nfsd, rpc.mountd și dacă se folosește autentificarea Kerberos, atunci demonul rcp.svcgssd. În red hat, daemonul rpc.rquotad și nfslogd încă rulează (Din anumite motive în Debian nu am găsit informații despre acest demon și motivele absenței sale, se pare că a fost șters...).

De aici devine clar că Serverul Network File System este format din următoarele procese (a se citi: daemons), situat în directoarele /sbin și /usr/sbin:

În NFSv4, când utilizați Kerberos, sunt porniți daemoni suplimentari:

• rpc.gssd- Daemonul 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.

portmap și protocol RPC (Sun RPC)

Pe lângă pachetele de mai sus, este necesar un pachet suplimentar pentru ca NFSv2 și v3 să funcționeze corect portmap(înlocuit în distribuțiile mai noi cu redenumit în rpcbind). Acest pachet este de obicei instalat automat cu NFS ca pachet dependent și implementează funcționarea serverului RPC, adică este responsabil de alocarea dinamică a porturilor 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 lansat 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 elimină către/din portmapper (aka port mapper, aka portmap, aka portmapper, aka, în versiunile noi, rpcbind), iar clienții folosesc apelurile RPC pentru a trimite cereri către portmapper pentru a primi informațiile necesare . Numele ușor de utilizat ale serviciilor de program ș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, mapează serviciului porturile TCP și UDP pe care a pornit serviciul și stochează în kernel informațiile corespunzătoare despre serviciul care rulează (nume), un serviciu de număr unic (în conformitate cu /etc/rpc), despre protocolul și portul pe care rulează serviciul și despre versiunea serviciului și furnizează informațiile specificate clienților la cerere. Convertorul de porturi în sine are un număr de program (100000), numărul 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 că v-am confundat puțin cu acest paragraf, așa că voi spune o frază de bază care ar trebui să clarifice lucrurile: principala funcție a unui port mapper este de a reveni, la cererea unui client care a furnizat un număr de program RPC ( sau numărul programului RPC) și versiunea lui (client) a portului pe care rulează programul solicitat. În consecință, dacă un client trebuie să acceseze 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 de comunicație cu serviciul RPC de care are nevoie.

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

1. Convertorul de porturi ar trebui să pornească mai întâi, de obicei când sistemul pornește. Aceasta creează un punct final TCP și deschide 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ă la efectuarea apelului 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 programul client RPC trebuie să obțină informațiile necesare, apelează rutina de rezoluție de porturi pentru a obține un număr de port alocat dinamic pentru programul, versiunea și protocolul specificat.
4. Ca răspuns la această solicitare, nordul returnează un număr de port.
5. Clientul trimite un mesaj de solicitare RPC 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 de provocare RPC 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 folosește TCP, clientul se deschide activ la numărul portului TCP al serviciului dorit și apoi trimite un mesaj de provocare RPC prin conexiunea stabilită. Serverul răspunde cu un mesaj de răspuns RPC la conexiune.

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

ARCHIV ~ # rpcinfo -p prog-ma vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 59451 status 100024 1 tcp 608702 status 100002 ngr 14101014 2 1 3 udp 44310 nlockmgr 100021 4 udp 44310 nlockmgr 100021 1 tcp 44851 nlockmgr 100021 3 tcp 44851 nlockmgr 100021 4 tcp 44851 nlockmgr 100003 2 tcp 2049 nfs 100003 3 tcp 44851 nlockmgr 100003 2 tcp 2049 nfs 100003 3 tcp 20490 nfs 20490 nps 003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100005 1 udp 51306 mountd 100005 1 tcp 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. Folosind 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 sunt înregistrate pe porturile udp și tcp, rpc.statd versiunea 1 pe porturile udp și tcp, NFS lock manager versiunile 1,3,4, nfs server daemon versiunea 2,3,4, de asemenea ca demonul de montare versiunile 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 codificat în NFS în majoritatea implementărilor.

Operarea protocolului sistemului de fișiere în rețea

Montarea NFS la distanță

Procesul de montare a unui sistem de fișiere NFS la distanță poate fi reprezentat prin următoarea diagramă:

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

1. Un server RPC este lansat pe server și client (de obicei la pornire), deservit de procesul portmapper și înregistrat pe portul tcp/111 și udp/111.
2. Sunt lansate servicii (rpc.nfsd, rpc.statd etc.), care sunt înregistrate pe serverul RPC și înregistrate 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 o solicitare către kernel pentru a monta un director de rețea, indicând tipul de sistem de fișiere, gazdă și directorul propriu-zis; nucleul trimite și formează o cerere RPC către procesul portmap de pe serverul NFS de pe portul udp /111 (dacă opțiunea de a lucra prin tcp nu este setată pe client)
4. Nucleul serverului NFS interoghează RPC-ul pentru 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 pe care rulează rpc.mountd. Serverul NFS poate valida acum un client pe baza adresei 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 de montare a clientului emite apelul de sistem de montare pentru a asocia mânerul de fișier obținut la pasul 5 cu punctul de montare local de pe gazda clientului. Hranul de fișier este stocat în codul NFS al clientului, iar de acum înainte orice acces de către procesele utilizatorului la fișierele din sistemul de fișiere al serverului va folosi handle-ul de fișier ca punct de plecare.

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 interacționează cu hardware-ul prin module de kernel sau apeluri de sistem încorporate.
2. Modul kernel kernel/fs/nfs/nfs.ko, care îndeplinește funcțiile unui 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 solicitări de la client ca datagrame UDP pe portul 2049. Deși NFS poate funcționa cu un rezolutor de porturi, care permite serverului să utilizeze porturi alocate dinamic, portul UDP 2049 este codificat în NFS în majoritatea implementărilor.
4. Când serverul NFS primește o solicitare de la un client, aceasta este trecută la o rutină locală de acces la fișiere, care oferă acces la discul local de pe server.
5. Rezultatul accesului la disc este returnat clientului.

Configurarea unui server NFS

Ajustarea serveruluiîn general constă în specificarea directoarelor locale care pot fi montate de sistemele de la distanță într-un fișier /etc/exports. Această acțiune se numește ierarhia directoarelor de export. 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 de utilitarul 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- o listă de directoare care nu sunt în prezent neexportate.
• /proc/fs/nfsd- un sistem de fișiere special (kernel 2.6) pentru gestionarea serverului NFS.
  • exporturi- o listă a ierarhiilor active exportate și a 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 „brute”, 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, pe internet există o mulțime de interpretări și formulări ale scopului fișierelor xtab, etab, rmtab, nu știu pe cine să cred.Chiar și pe http://nfs.sourceforge.net/ interpretarea este neclar.

Configurarea fișierului /etc/exports

În cel mai simplu caz, fișierul /etc/exports este singurul fișier care necesită editare pentru a configura serverul NFS. Acest fișier controlează următoarele aspecte:

• Ce fel de 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 fi afisat la nume de utilizator locale

Fiecare linie a fișierului de export are următorul format:

export_point 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 pt client, precizat mai înainte Opțiuni .

Iată una 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 fișierele gazdă au acces de citire/scriere, iar gazda 10.0.0.1 și subrețeaua 10.0.230.1/24 au acces numai pentru citire.

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

• Numele nodurilor individuale sunt descrise ca fișiere sau fișiere.DOMAIN.local.
• Masca de domeniu este descrisă î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 nodurile ale căror adrese încep cu 10.0.0.
• Specificarea numelui grupului de rețea @myclients care are acces la resursă (când se utilizează un server NIS)

Opțiuni generale pentru exportul ierarhiilor de directoare

Fișierul de exporturi utilizează următoarele opțiuni generale(opțiunile utilizate implicit în majoritatea sistemelor sunt enumerate mai întâi, 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 solicitărilor de blocare (folosind protocolul NFS Lock Manager).
• nohide (ascunde)- dacă serverul exportă două ierarhii de directoare, cu una imbricată (montată) în interiorul celeilalte. 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 putut face ca această opțiune să funcționeze...)
• ro(rw)- Permite numai cereri de citire (scriere). (În cele din urmă, dacă este posibil să citiți/scrieți sau nu este determinat pe baza drepturilor sistemului de fișiere, iar serverul nu este capabil să distingă o solicitare de citire a unui fișier de o solicitare de executare, deci permite citirea dacă utilizatorul a citit sau executa drepturi.)
• sigur (nesigur)- necesită ca cererile NFS să provină din porturi securizate (< 1024), чтобы программа без прав root не могла монтировать иерархию каталогов.
• subtree_check (fără_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.
• sincronizare (async)- specifică că serverul ar trebui să răspundă la solicitări numai după ce modificările făcute de acele 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 deoarece În cazul unei întreruperi a conexiunii sau a unei defecțiuni a echipamentului, informațiile se pot pierde.
• 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 unei comenzi de scriere, ceea ce poate fi util dacă serverul primește un număr mare de comenzi care nu au legătură.

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

Fișierul dispozitivului aparține interfeței. Când exportați un fișier de dispozitiv, această interfață este exportată. Dacă sistemul client nu are un dispozitiv de același tip, dispozitivul exportat nu va funcționa. Pe sistemul client, atunci când montați obiecte NFS, puteți utiliza opțiunea nodev, astfel încât fișierele dispozitivului din directoarele montate să nu fie utilizate.

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

Opțiuni de afișare (potrivire) ID 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 presupune că sistemul de operare al gazdei 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 ar fi fost logați direct pe 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ă aceiași identificatori pe ambele sisteme și, prin urmare, poate să poată accesa fișierele altui utilizator.
• deoarece Dacă 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țiunea specificată 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ă afișarea TOȚI utilizatorii (nu doar root) ca anonim sau specificat în parametrul anonuid/anongid.
• anonuid= UID Și anongid= GID - Setează în mod explicit UID/GID pentru utilizatorul anonim.
• map_static= /etc/file_maps_users - Specifică un fișier în care puteți seta maparea UID/GID la distanță la UID/GID local.

Exemplu de utilizare a unui fișier de mapare utilizator:

ARCHIV ~ # cat /etc/file_maps_users # Maparea utilizatorului # 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 GID la distanță 0-50 la GID local 1002

Managementul serverului NFS

Serverul NFS este gestionat folosind următoarele utilitare:

• nfsstat
• showmmontare 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șează informații despre starea NFS

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

• --toate- 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.
• --directoare- este afișată o listă de puncte de montare
• --exporturi- este afișată o listă de sisteme de fișiere exportate din punctul de vedere al nfsd

Când rulați showmount fără argumente, informațiile despre sistemele cărora li se permite montarea vor fi tipărite pe consolă local cataloagele. De exemplu, gazda ARCHIV ne oferă o listă de directoare exportate cu adresele 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 numele de gazdă/IP în argument, vor fi afișate informații despre această gazdă:

ARCHIV ~ # showmount files clnt_create: RPC: Programul nu este înregistrat # acest mesaj ne spune că demonul NFSd nu rulează pe gazda FILES

exportfs: gestionați directoarele exportate

Această comandă servește directoarele exportate specificate în fișier /etc/exports, ar fi mai corect să scrieți că 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 comunică cu demonul rpc.mountd prin fișiere din directorul /var/lib/nfs/ și nu comunică direct cu nucleul. Fără parametri, afișează o listă a sistemelor de fișiere exportate în prezent.

parametrii exportfs:

• [client:nume-director] - 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 (sincronizează /etc/exports și /var/lib/nfs/xtab)
• -u - elimina din lista de exportate
• -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; adică 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 curente ale liniei de comandă
• -f - resetează lista sistemelor exportate în kernel 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 folosind unul dintre dispozitivele de montare automate în proliferare (amd, autofs, automount, supermount, superpupermount). Procesul de instalare este bine demonstrat în ilustrația de mai sus.

Pe Clienți NFS nu este nevoie să rulați niciun daemon, 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 folosind demonul autofs

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

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, dar totuși indică parametrul -t nfs 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 fara parametri, ne arata clar rezultatul montajului. Pe lângă opțiunea de numai citire (ro), este posibil să specificați și altele Opțiuni de bază la montarea NFS:

• nosuid- Această opțiune interzice executarea programelor din directorul montat.
• nodev(fără dispozitiv - nu dispozitiv) - Această opțiune interzice utilizarea caracterelor și blochează fișierele speciale ca dispozitive.
• blocare (nolock)- Permite blocarea NFS (implicit). nolock dezactivează blocarea NFS (nu pornește demonul lockd) și este util atunci când lucrați cu servere mai vechi care nu acceptă blocarea NFS.
• mounthost=nume- Numele gazdei pe care rulează demonul de montare NFS - 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 interogează harta port pe server pentru a determina portul.
• dimensiunea=n(citiți dimensiunea blocului - citiți dimensiunea blocului) - Numărul de octeți citiți la un moment dat de pe serverul NFS. Standard - 4096.
• wsize=n(write block size - write block size) - Numărul de octeți scriiți simultan pe serverul NFS. Standard - 4096.
• tcp sau udp- Pentru a monta NFS, utilizați protocolul TCP sau, respectiv, UDP.
• bg- Dacă pierdeți accesul la server, încercați din nou î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 repetarea încercărilor de montare. Din acest motiv, parametrul fg este folosit în primul rând pentru 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 puțin frecvent pentru directoare. Multe programe, cum ar fi ls, accesează fișierele doar î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 stocați în cache aceste atribute. 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 conformitate cu parametrii specificați:

• ac (noac) (cache de attribute- cache de atribute) - Permite memorarea în cache de atribute (implicit). Deși opțiunea noac încetinește serverul, evită învechirea 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 un fișier de director) - Numărul maxim de secunde pe care NFS le așteaptă înainte de a actualiza atributele de director (implicit 60 de secunde)
• acdirmin=n (directorul cache al atributului minim- memoria cache minimă a atributelor pentru un fișier de director) - Numărul minim de secunde pe care NFS le așteaptă înainte de a actualiza atributele de director (implicit 30 de secunde)
• acregmax=n (cache de atribute maxim fișier normal- cache maximă a atributelor pentru un fișier obișnuit) - Numărul maxim de secunde pe care NFS le așteaptă înainte de a actualiza atributele unui fișier obișnuit (implicit 60 sec.)
• acregmin=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 le așteaptă înainte de a actualiza atributele unui fișier obișnuit (implicit 3 secunde)
• actimeo=n (timeout cache-ul atributului- timeout caching atribute) - Înlocuiește valorile pentru toate opțiunile de mai sus. Dacă actimeo nu este specificat, atunci valorile de mai sus preiau valorile 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) - Încercările de a monta un NFS eșuat în prim-plan/fundal.
• greu moale)- afișează mesajul „serverul nu răspunde” la consolă când este atins timpul de expirare și continuă să încerce montarea. Cu opțiunea oferită moale- în timpul unui timeout, informează programul care a apelat operația despre o eroare I/O. (se recomandă să nu folosiți opțiunea soft)
• nointr (intr) (nicio întrerupere- nu întrerupeți) - Nu permite semnalelor să întrerupă operațiunile cu fișiere într-o ierarhie de directoare montată greu atunci când este atins un timeout mare. intr- permite întreruperea.
• retrans=n (valoarea de retransmisie- valoarea retransmisie) - După n timeout-uri mici, NFS generează un timeout mare (implicit 3). Un timeout mare oprește operațiunile sau tipărește un mesaj „serverul nu răspunde” pe consolă, în funcție de dacă este specificată opțiunea hard/soft.
• reîncercați=n (valoare de reîncercare- valoare de reîncercare) - Numărul de minute în care serviciul NFS va repeta operațiunile de montare înainte de a renunța (implicit 10000).
• timeo=n (valoarea timeout- valoare timeout) - numărul de zecimi de secundă pe care serviciul NFS le așteaptă înainte de a retransmite în cazul RPC sau un timeout mic (implicit 7). Această valoare crește cu fiecare timeout până la maximum 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 32776 octeți din archiv.domain.local (10.0.0.6): icmp_req=2 ttl=64 time=0,957 ms 32776 bytes de la archiv.domain.local (10.0.0.6): icmp_req=3 ttl=64 time=1.03 ms 32776 bytes din archiv.domain.local (10.0.0.6): icmp_req=4 ttl=64 time=1.00 ms 32776 bytes din arhivă .domain.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 depășește 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. Prin urmare, este recomandabil să faceți acest test în timpul sarcinii grele ale rețelei.

Lansarea NFS și configurarea paravanului de protecție

Nota a fost copiata de pe blogul http://bog.pp.ru/work/NFS.html, pentru care multumesc mult!!!

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

• Este recomandabil să demontați mai întâi toate resursele de pe clienți
• opriți și dezactivați pornirea rpcidmapd dacă nu intenționați să utilizați NFSv4: chkconfig --level 345 rpcidmapd off service rpcidmapd stop
• dacă este necesar, permiteți pornirea serviciilor portmap, nfs și nfslock: chkconfig --levels 345 portmap/rpcbind on chkconfig --levels 345 nfs on chkconfig --levels 345 nfslock on
• dacă este necesar, opriți serviciile nfslock și nfs, 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 lansat 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 este necesar pentru versiunile mai vechi (totuși, trebuie să aveți pachetul de cotă 3.08 sau mai nou) adăugați la /etc/services rquotad 4003/tcp rquotad 4003/udp
• va verifica caracterul adecvat al /etc/exports
• rulați serviciile rpc.nfsd, mountd și rpc.rquota (rpcsvcgssd și rpc.idmapd sunt lansate în același timp, dacă vă amintiți să le ștergeți) service nfsd start sau în versiuni 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 serverul de blocare pentru sisteme mai vechi, adăugați direct în /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 comutatorul -p 4000 în /etc/init.d/nfslock) STATD_PORT=4000
• porniți serviciile lockd și rpc.statd service nfslock start
• asigurați-vă că toate porturile sunt legate în mod normal folosind „lsof -i -n -P” și „netstat -a -n” (unele dintre porturi sunt folosite de modulele kernel pe care lsof nu le vede)
• dacă înainte de „reconstruire” serverul era folosit de clienți și nu puteau fi demontați, atunci va trebui să reporniți serviciile de montare automată pe clienți (am-utils, autofs)

Exemplu de configurare pentru server și client NFS

Configurare server

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

ARCHIV ~ # cat /etc/exports # Acces de citire și scriere pentru client pe 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 pe 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.

Salutări, McSim!

1.4 Sistem de fișiere din rețea

Sistemul de fișiere CIFS domină piața sistemelor de fișiere de rețea pentru platforma Windows. Pe platforma UNIX, principalul este Network File System (NFS). În plus, NFS este considerat a fi primul sistem de fișiere adoptat pe scară largă, datând de la mijlocul anilor 1980. Cu toate acestea, în ciuda unor funcționalități comune între CIFS și NFS (sisteme de fișiere de rețea care permit clienților să acceseze resursele serverului), aceste sisteme au caracteristici arhitecturale complet diferite. Odată cu lansarea NFS versiunea 4, unele diferențe au fost revizuite.
Protocolul CIFS stochează date de serviciu specifice fiecărui client. Înainte de versiunea 3, sistemul de fișiere NFS nu păstra statutul de client, care sa schimbat în versiunea 4.
Clientul NFS nu „negociază” cu serverul NFS pentru a stabili o sesiune. Se iau măsuri de securitate pentru întreaga sesiune sau fiecare comunicare între client și server. Această din urmă opțiune este prohibitiv de costisitoare de implementat, așa că NFS lasă responsabilitatea de securitate în seama clientului. Serverul „presupune” că ID-urile utilizatorului de pe sistemele client și server sunt aceleași (și clientul a verificat identitatea utilizatorului înainte de a-i permite acestuia să se înregistreze sub ID-ul specificat). În plus, NFS oferă un anumit nivel de securitate prin controlul listei de sisteme de fișiere pe care le poate monta un client. De fiecare dată când un client CIFS deschide un fișier, primește un handle de fișier (adică date de serviciu pe care serverul trebuie să le stocheze) și îl folosește pentru a efectua operațiuni de citire sau scriere la nivelul clientului, serverul NFS interogează serverul, care returnează fișierul. mâner. Acest descriptor de fișier este procesat de clienții care acceptă standardele NFS 3 și NFS 2. Clientul memorează în cache descriptorul de fișier rezultat și se așteaptă ca descriptorul să indice întotdeauna același fișier.
Pentru cei familiarizați cu UNIX, un descriptor de fișier constă de obicei dintr-un număr de inoduri, un număr de generare de inoduri și ID-ul fișierului care este asociat cu partiția de disc. Este suficient să spunem că inodul este o structură de date extrem de importantă folosită în sistemele de fișiere UNIX. Sunt stocate suficiente informații pentru a elimina mânerele stocate în cache de clienți dacă fișierul corespunzător pentru mâner s-a schimbat și mânerul trebuie să indice un fișier diferit. De exemplu, dacă un fișier este șters și un fișier cu același nume este copiat în locul său, contorul de generare a inodului va fi modificat și descriptorul fișierului stocat în cache de client va fi invalid. Sistemul de fișiere NFS 4 are diferențe în implementare.
Unii clienți NFS realizează memorarea în cache pe partea client prin stocarea datelor pe discuri, ceea ce este similar cu memorarea în cache CIFS. De asemenea, unii clienți NFS modifică valoarea timeout-urilor în funcție de timpul de răspuns al serverului. Cu cât serverul răspunde mai lent, cu atât valoarea timeout este mai mare și invers.
Sistemul de fișiere NFS a fost conceput pentru a fi independent de transport și a folosit inițial protocolul de transport UDP. Diferite tipuri de NFS pot folosi TCP și alte protocoale.

1.4.1 Sistemul de fișiere de rețea versiunea 3

Sistemul de fișiere NFS 3 îmbunătățește performanța, în special pentru fișierele mari, permițând clientului și serverului să selecteze dinamic cantitatea maximă de date care este transferată într-un singur element de pachet logic atunci când scrie sau citește. În sistemul de fișiere NFS 2, dimensiunea pachetului a fost limitată la 8 KB. Cu alte cuvinte, clientul ar putea trimite maximum 8 KB într-o cerere de scriere, iar serverul ar putea trimite maximum 8 KB într-un răspuns la cerere de citire. În plus, NFS 3 a redefinit decalajele fișierelor și dimensiunile datelor. Acestea sunt acum valori de 64 de biți, în loc de 32 de biți în NFS 2.
Mai jos sunt câteva dintre caracteristicile NFS 3.
■ Descriptorii de fișiere în NFS 3 au dimensiuni variabile; dimensiunea lor maximă este de 64 de biți.
■ Sistemul de fișiere NFS 3 permite clienților și serverelor să aleagă dimensiunea maximă pentru numele fișierelor și directoarelor.
■ NFS 3 defineşte o listă de erori pe care serverul le poate returna clienţilor. Serverul trebuie să returneze una dintre erorile specificate sau să nu returneze nicio eroare.
■ În NFS 3, serverului i se permite să memoreze în cache datele pe care clientul le-a trimis cu o solicitare de scriere. Serverul poate stoca datele în cache și poate trimite un răspuns la cerere către client înainte ca datele să fie scrise pe disc. A fost adăugată și o comandă COMMIT, care permite clientului să se asigure că toate datele trimise au fost scrise pe disc. Acest lucru face posibilă atingerea unui echilibru între îmbunătățirea performanței și menținerea integrității datelor.
■ NFS 3 reduce numărul de operaţii de cerere/răspuns între client şi server. Pentru a face acest lucru, datele despre atributul fișierului sunt trimise împreună cu solicitarea inițială. În NFS 2, clientului i se cerea să obțină nume de fișiere și un descriptor pentru fiecare fișier, abia atunci au fost transmise atributele fișierului.

1.4.2 Sistemul de fișiere de rețea versiunea 4

NFS 4 a revizuit complet principiile fundamentale și a implementat multe caracteristici specifice CIFS, ceea ce i-a supărat foarte mult pe unii apologeți NFS. Dacă te uiți la istoria sistemelor de fișiere din rețea, poți vedea că NFS a devenit larg răspândit. Sistemul de fișiere SMB a fost conceput pentru a ține cont de punctele forte și punctele slabe ale NFS și acum, cel puțin în rândul clienților, CIFS/SMB este mai frecvent, iar NFS evoluează pentru a ține cont de avantajele și dezavantajele CIFS/SMB. Următoarele evidențiază funcțiile care au fost adăugate la NFS 4 pentru a îmbunătăți performanța, securitatea și interoperabilitatea cu CIFS.
■ NFS 4 a introdus cererea COMPOUND, care vă permite să pachetați mai multe cereri într-o singură cerere și mai multe răspunsuri într-un singur răspuns. Această inovație este concepută pentru a îmbunătăți performanța prin reducerea încărcării rețelei și reducerea latenței pe măsură ce cererile și răspunsurile circulă în rețea. Dacă aceasta sună oarecum ca caracteristica CIFS AndX SMB (vezi Secțiunea 3.3.5.1), atunci s-ar putea să nu fie o simplă coincidență.
■ Sistemul de fișiere de rețea versiunea 4 împrumută unele caracteristici de la WebNFS de la Sun. În special, NFS 4 acceptă unele protocoale secundare în specificația de bază, făcând NFS mai potrivit pentru utilizarea cu firewall-uri. NFS 3 și versiunile anterioare au folosit un protocol special pentru a monta o partajare de server în arborele sistemului de fișiere local. Deoarece serviciul de protocol de montare nu avea alocat un port TCP sau UDP, clientul a trimis mai întâi o solicitare către demonul portmapper, care furnizează numărul portului pe care serviciul de montare ascultă cereri. Astfel, pe lângă NFS, la proces au luat parte și protocoalele de montare și mapare a porturilor. Mai mult, deoarece serviciul de montare putea folosi un port arbitrar, configurarea firewall-ului a devenit foarte dificilă. În NFS 4, protocoalele de montare și mapare porturi au fost eliminate. În plus, blocarea a fost inclusă în specificația de bază a protocolului NFS, iar protocolul NLM (Network Lock Manager), care a fost folosit în versiunile anterioare ale NFS, a fost permanent depreciat.
■ Sistemul de fișiere NFS 4 necesită utilizarea unui protocol de transport care oferă capacitatea de a detecta congestionarea rețelei. Aceasta înseamnă că clienții și serverele NFS se vor muta treptat la TCP în loc de UDP, care este folosit în mod obișnuit cu NFS 3.
■ NFS 2 și NFS 3 au permis utilizarea setului de caractere din S.U.A. ASCII sau ISO Latin 1. Acest lucru a cauzat probleme atunci când un client care folosea un set de caractere a creat un fișier și acel fișier a fost accesat de un client folosind un set de caractere diferit. NFS 4 folosește setul de caractere UTF-8, care acceptă compresia compactă a caracterelor pe 16 și 32 de biți pentru transmisia prin rețea. În plus, setul de caractere UTF-8 conține suficiente informații pentru a evita problemele la crearea unui fișier folosind un set de caractere și accesarea unui fișier folosind un alt set de caractere.
■ Sistemul de fișiere NFS 4 necesită clientului să gestioneze descriptorii de fișiere separat. În NFS 3, clientul putea stoca în cache mânerul ca obiect, în timp ce serverul se asigura că mânerul indică întotdeauna un fișier. NFS 4 definește două tipuri de descriptori de fișiere. Unul se numește descriptori de fișiere persistente și are capabilitățile de descriptori de fișiere din NFS 3. Al doilea, descriptori de fișiere temporare, presupune că descriptorul expiră după o anumită perioadă de timp sau eveniment. Aceasta este o caracteristică pentru serverele ale căror sisteme de fișiere (cum ar fi NTFS) nu pot oferi o mapare coerentă între fișierele afișate și handle.
■ NFS 4 adaugă suport pentru operațiuni OPEN și CLOSE, a căror semantică permite interacțiunea cu clienții CIFS. Comanda OPEN creează date de stare pe server.
■ Suportul de solicitare OPEN al NFS 4 permite unui client să emită o cerere de deschidere a fișierului care este structurată în mod similar cu cererile de deschidere a aplicației Windows. De asemenea, este acceptată alegerea de a partaja fișierul cu alți clienți sau de acces exclusiv la fișier.

1.4.2.1 Securitate NFS 4

Sistemul de fișiere NFS 4 vă permite să îmbunătățiți securitatea datelor stocate. În special, NFS 4 adaugă suport pentru mai multe atribute de fișiere. Unul dintre aceste atribute este o listă de control al accesului (ACL) în stil Windows NT. Acest lucru permite o interoperabilitate îmbunătățită între sistemele de fișiere și o structură de securitate mai puternică.
În timp ce în NFS 2 și NFS 3 utilizarea caracteristicilor de securitate a fost doar recomandată, în NFS 4 a devenit obligatorie. Sistemul de fișiere NFS 4 necesită implementarea unui mecanism de securitate folosind interfața RPCSEC_GSS (Generic Security Services) în general și protocoalele Kerberos 5/LIPKEY în special. Rețineți că RPCSEC_GSS acționează pur și simplu ca un API și un mecanism de transport pentru etichetele și datele legate de securitate. Sistemul de fișiere NFS 4 permite mai multe scheme de autentificare și securitate și posibilitatea de a alege schema potrivită pentru clienți și servere.
Să acordăm puțină atenție studierii tehnologiei LIPKEY, care utilizează o combinație de criptare simetrică și asimetrică. Clientul criptează datele utilizatorului și parola folosind o cheie de 128 de biți generată aleatoriu. Criptarea se realizează folosind un algoritm simetric, adică. trebuie folosită aceeași cheie pentru decriptare. Deoarece serverul are nevoie de această cheie pentru a decripta mesajele, o cheie generată aleatoriu trebuie trimisă către server. Clientul criptează cheia (care este generată aleatoriu) folosind cheia publică a serverului. Serverul decriptează datele cu cheia sa privată, extrage cheia simetrică și decriptează datele utilizatorului și parola.
Clienții pot autentifica serverele folosind un certificat de server, iar serviciile de autoritate de certificare sunt folosite pentru a verifica certificatul. Una dintre metodele populare de hacking este interceptarea pachetelor de date „extraterestre” și apoi trimiterea lor după o anumită perioadă de timp. Când utilizați Kerberos, sistemul de fișiere NFS adaugă un marcaj temporal fiecărui pachet. Serverul înregistrează marcajele de timp primite recent și le compară cu marcajele de timp ale noilor pachete RPC. Dacă marcajele de timp ale pachetelor sunt mai vechi decât cele primite anterior de server, serverul ignoră pachetele primite

1.5 Probleme de acces la utilizarea mai multor protocoale

Mai multe companii au început să ofere sisteme care acceptă simultan CIFS, NFS și alți clienți de sistem de fișiere de rețea. Furnizorii au depus multă muncă încercând să depășească provocările tehnice care apar din cauza clienților care pot utiliza diferite sisteme de operare și sisteme de fișiere. Vă rugăm să rețineți că problemele nu apar cu datele în sine, ci cu metadatele fișierelor. Un simplu test pentru astfel de probleme ar fi să copiați un fișier de pe server pe client și înapoi pe server (sau invers). Odată ce fișierul este plasat în resursa inițială, metadatele ar trebui să conțină valorile de bază, adică Permisiunile pentru fișiere și marcajele de timp nu ar trebui să se schimbe. Dacă acest lucru nu este adevărat, atunci problema a fost detectată.
Următoarele sunt exemple ale unor posibile probleme tehnice.
■ Sistemele de operare diferite folosesc metode diferite pentru a urmări permisiunile de acces ale utilizatorilor și grupurilor.
■ Diferite sisteme de operare și sisteme de fișiere au o semantică diferită pentru deschiderea și blocarea fișierelor.
■ Convențiile de denumire a fișierelor sunt gestionate în moduri diferite. Diferite sisteme de fișiere au reprezentări diferite ale dimensiunii maxime a unui nume de fișier, valoarea majusculă a unui nume de fișier și setul de caractere permis în nume.
■ Datele și structura lor diferă în diferite sisteme de fișiere; de exemplu, unele sisteme de fișiere urmăresc două marcaje temporale, în timp ce altele urmăresc trei marcaje temporale (ora la care fișierul a fost accesat ultima dată, fișierul a fost modificat ultima dată și fișierul a fost creat). Chiar dacă ambele sisteme de fișiere urmăresc două marcaje temporale, unitățile de măsură pot diferi. Un alt exemplu este unitățile de măsurare a offset-urilor în fișiere. Unele sisteme de fișiere acceptă decalaje de 32 de biți, iar unele acceptă decalaje de 16 sau 64 de biți.
■ Probleme cu adresarea lacăturilor afișate. Serverul CIFS impune blocarea: dacă un client a blocat o regiune a unui fișier, atunci orice operație de scriere în acea regiune a fișierului de către un alt client va avea ca rezultat o eroare. Cu toate acestea, blocarea forțată nu este acceptată de serverele NFS. Prin urmare, trebuie să alegeți dacă blocarea va fi aplicată, ceea ce va duce la trimiterea unui mesaj de eroare către clientul NFS.

Servicii de rețea

Cursul 10

Se numește setul de părți server și client ale sistemului de operare care oferă acces la un anumit tip de resursă de computer prin intermediul unei rețele serviciu de rețea. Partea client face cereri de rețea către partea server a altui computer. Partea server satisface cererile către resursele serverului local. Partea client este activă, partea server este pasivă.

În comunicarea în rețea, accesul la rețea la sistemul de fișiere joacă un rol semnificativ. În acest caz, se formează părțile client și server, împreună cu sistemul de fișiere din rețea serviciul de fișiere

O componentă cheie a unui sistem de operare distribuit este sistemul de fișiere din rețea. Un sistem de fișiere de rețea este acceptat de unul sau mai multe computere care stochează fișiere (servere de fișiere)

Client computerele atașează sau montează aceste sisteme de fișiere la sistemele lor de fișiere locale

Serviciu de fișiere include programe server și programe client care interacționează prin rețea folosind un protocol.

Serviciile de fișiere includ serviciul de fișiere în sine (operațiuni cu fișiere) și serviciul de directoare (gestionarea directoarelor)

Modelul serviciului de fișiere de rețea include următoarele elemente:

Sistem de fișiere local (FAT, NTFS)

Interfață locală a sistemului de fișiere (apeluri de sistem)

Server de sistem de fișiere de rețea

Client sistem de fișiere de rețea (Windows Explorer, UNIX shell etc.)

Interfața sistemului de fișiere din rețea (repetă apelurile sistemului de fișiere local)

Network File System Protocol Client-Server (SMB-Server Message Block pentru Windows, NFS (Network File System) și FTP (File Transfer Protocol) pentru UNIX)

Interfața sistemului de fișiere de rețea

Există mai multe tipuri de interfețe, care se caracterizează prin:

Structura fișierului. Majoritatea sistemelor de fișiere din rețea acceptă fișiere plate

Modificarea fișierului. Majoritatea sistemelor de fișiere din rețea au capacitatea de a modifica un fișier. Unele sisteme de fișiere distribuite interzic operațiunile de modificare. Sunt posibile doar crearea și citirea. Pentru astfel de fișiere este mai ușor să organizați memorarea în cache și replicarea.

Semantica de separare a fișierelor:

Semantică UNIX (centralizat). Dacă o citire urmează mai multe scrieri, se citește cea mai recentă actualizare. Acest principiu este posibil și într-un sistem de fișiere distribuit, cu condiția să existe un server de fișiere și să nu existe memorare în cache a fișierelor pe client.

Semantica sesiunii. Modificările încep după deschiderea fișierului și se finalizează după închiderea fișierului. Cu alte cuvinte, pentru alte procese, modificările sunt vizibile numai după ce fișierul este închis. În acest caz, există o problemă la partajarea fișierului. Semantica fișierelor imuabile. Fișierul poate fi creat și citit doar. De asemenea, puteți recrea fișierul sub un alt nume. Prin urmare, fișierul nu poate fi modificat, dar poate fi înlocuit cu un fișier nou. Nu există nicio problemă de partajare.

Mecanismul tranzacției. Acesta este un mod de a lucra cu fișiere partajate folosind un mecanism de tranzacție (operații indivizibile)

Controlul accesului. De exemplu, pentru Windows NT/2000 există două mecanisme: la nivel de director (pentru FAT) și la nivel de fișier (NTFS)

Unitate de acces. Model complet de încărcare/descărcare a fișierelor (FTP). Al doilea model este utilizarea operațiunilor cu fișiere.

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

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

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

UNDE A ÎNCEPUT TOTUL...

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

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

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

UNIX A FOST GENEZA

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

NFS

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

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

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

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

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

Cd /root/usr2/

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

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

SĂ CUNOAȘM MAI BINE

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

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

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

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

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

10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 lookup fh 32.0/ 224145 "test-file" 10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 lookup fh 32.0/ 224145 "test-file" 10:30:16.012729 eth0 192.168.1.254.341722:254.341.254.300000000000000000000000 07 (DF) 10:30: 16.012729 eth0 192.168 .1.254.3476097947: răspuns ok 128 lookup fh 32.0/224307 (DF) 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 citiți fh 32.0/ 224307 4096 octeți @ 0 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 citiți fh 32.0/ 224307 4096 octeți @ 0 10:30:16.013650 eth0 192.168.1.25250 eth0 192.168.1.254 192.168.1.254: ok: 3492875163 3492875163 :16.013650 eth0 192.168.1.254.3492875163 : raspunde ok 108 citire (DF)

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

ACCES NFS

Implementările NFS acceptă de obicei patru moduri de a acorda drepturi de acces: prin atribute utilizator/fișier, la nivel de resurse partajate, la nivel de nod principal și ca o combinație a altor metode de acces.

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

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

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

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

NFS ÎN STIL PINGUIN

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

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

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

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

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

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

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

/home (ro)

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

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

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

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

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

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

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

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

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

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

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

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

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

# rpc.mountd -N 1 -N 2

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

„ÎNOT CU PINGUINI”

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

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

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

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

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

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

# tcpdump gazdă lefty și gazdă sunny -s512 06:07:43.490583 sunny.2191983953 > lefty.mcwrite.n.nfs: 128 getattr fh Necunoscut/1 (DF) 06:07:43.490678 lefty.nnny.mcwrite > 2191983953: raspuns ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:07:43.491397 sunny.2191983954 > lefty.mcwrite.mcwrite.n.nfs: fh 013/nfs: acces necunoscut: 013/nfs: 3.491463 stângaci .mcwrite.n.nfs > sunny.2191983954: răspuns ok 120 acces c0001 (DF) 06:07:43.492296 sunny.2191983955 > lefty.mcwrite.n.nfs: 152 readdirplus/fh817070719/fh870 0 0000 (DF) 06:07:43.492417 lefty.mcwrite.n.nfs > sunny.2191983955: răspuns ok 1000 readdirplus (DF)

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

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

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

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

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

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

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

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

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

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

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

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

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

VERSIUNEA SOLARIS SERVER NFS

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

#/usr/lib/nfs/mountd

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

#/usr/lib/nfs/nfsd

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

Partajați -F nfs /export/home

Masuri de securitate

SECURITATE ÎN LINUX

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

TOȚI: Toate

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

Lockd:192.168.1.0/255.255.255.0 mountd:192.168.1.0/255.255.255.0 portmap:192.168.1.0/255.255.255.0 rquotad:192.168.1.0/255.255.255.0 rquotad:192.168.1.0/255.255.255.0 6 8.1.0/255.255.255.0

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

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

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

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

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

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

SECURITATE NFS ÎN SOLARIS

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

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

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

Resurse Internet

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

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

Cea mai importantă componentă a oricărui sistem distribuit este sistemul de fișiere, care în acest caz este și distribuit. Ca și în sistemele centralizate, funcția unui sistem de fișiere este de a stoca programe și date și de a oferi acces clienților. Un sistem de fișiere distribuit este întreținut de unul sau mai multe computere care stochează fișiere. Serverele de fișiere conțin de obicei sisteme de fișiere ierarhice, fiecare cu un director rădăcină și directoare de nivel inferior. În multe sisteme de fișiere din rețea, un computer client poate atașa și monta aceste sisteme de fișiere la sistemele sale de fișiere locale, oferind utilizatorului acces convenabil la directoare și fișiere la distanță. În acest caz, datele fișierelor montate nu se mută fizic nicăieri, rămânând pe servere.

Din punct de vedere software, un sistem de fișiere distribuit (FS) este un serviciu de rețea care include programe server și programe client care interacționează între ele folosind un protocol specific. Serviciul de fișiere din sistemele de fișiere distribuite are două părți distincte funcțional: serviciul de fișiere însuși și serviciul de director al sistemului de fișiere. Prima se ocupă cu operațiunile asupra fișierelor individuale, precum citirea, scrierea sau adăugarea (modificarea), iar a doua se ocupă cu crearea și gestionarea directoarelor, adăugarea și ștergerea fișierelor din directoare etc.

Într-un sistem distribuit bine organizat, utilizatorii nu știu cum este implementat sistemul de fișiere (câte servere de fișiere, unde se află, cum funcționează). În mod ideal, pentru un utilizator, un sistem de fișiere de rețea ar trebui să arate ca al lui pe computerul său, adică să fie complet transparent. Cu toate acestea, în realitate, sistemele de fișiere din rețea nu se ridică încă pe deplin la acest ideal.

Un sistem de fișiere de rețea include, în general, următoarele elemente:

Sisteme de fișiere locale;

Interfețe locale ale sistemului de fișiere;

Servere de sistem de fișiere de rețea;

Clienți de sistem de fișiere de rețea;

Interfețe de sistem de fișiere de rețea;

Protocolul client-server al sistemului de fișiere de rețea.

Clienții Network FS sunt programe care rulează pe numeroase computere conectate la rețea. Aceste programe servesc cereri de aplicații pentru a accesa fișierele stocate pe computere la distanță. Clientul FS de rețea transmite cereri prin rețea către o altă componentă software - serverul FS de rețea care rulează pe un computer la distanță. Serverul, la primirea unei cereri, o poate executa singur sau, ceea ce este mai frecvent, poate transmite cererea sistemului de fișiere local pentru procesare. După primirea unui răspuns de la FS local, serverul îl transmite prin rețea__

Clientul și serverul FS de rețea interacționează unul cu celălalt prin intermediul rețelei folosind un protocol specific. Dacă interfețele FS locale și de rețea se potrivesc, acest protocol poate fi destul de simplu. Un mecanism utilizat în acest scop poate fi mecanismul RPC.

În sistemele de operare Windows, principalul serviciu de fișiere de rețea este protocolul SMB (Server Message Block), care a fost dezvoltat în comun de Microsoft, Intel și IBM. Cele mai recente versiuni extinse ale sale se numesc Common Internet File System, CIFS.

Protocolul operează la nivelul de aplicație al modelului OSI. SMB utilizează diverse protocoale de transport pentru a-și transmite mesajele prin rețea. Din punct de vedere istoric, primul astfel de protocol a fost NetBIOS (și versiunea sa ulterioară NetBEUI), dar acum mesajele SMB pot fi transmise folosind alte protocoale (TCP/UDP și IPX).

SMB aparține clasei de protocoale orientate spre conexiune. Lucrul său începe cu clientul care trimite un mesaj special către server care solicită o conexiune. Dacă serverul este pregătit să stabilească o conexiune, acesta răspunde cu un mesaj de confirmare. Odată stabilită conexiunea, clientul poate contacta serverul trimițând comenzi pentru a manipula fișierele și directoarele din mesajele SMB. În timpul funcționării, pot apărea o serie de situații care pot afecta eficacitatea accesului la fișiere de la distanță:

1. Eșecul computerului care rulează serverul sistemului de fișiere din rețea în timpul unei sesiuni de comunicare cu clientul. FS-ul local reține starea operațiilor succesive pe care aplicația le efectuează asupra aceluiași fișier prin menținerea unui tabel intern de fișiere deschise (apelurile de sistem deschise, citite, scrise modifică starea acestui tabel). Când sistemul se blochează, tabelul fișierelor deschise se pierde după ce computerul server este repornit. În acest caz, aplicația care rulează pe computerul client nu poate continua să lucreze cu fișiere care au fost deschise înainte de accident.

O soluție la problemă se bazează pe transferul funcției de menținere și stocare a unui tabel de fișiere deschise de la server la client. Cu această organizare, protocolul client-server este simplificat, deoarece repornirea serverului duce doar la o pauză în serviciu.

2. Întârzieri mari în serviciu din cauza solicitărilor de rețea și a repornirii serverului de fișiere atunci când un număr mare de clienți se conectează. O soluție la problemă poate fi stocarea fișierelor în cache (parțial sau în întregime) pe partea clientului. Cu toate acestea, în acest caz, protocolul trebuie să țină cont de posibilitatea formării mai multor copii ale aceluiași fișier, care pot fi modificate independent de utilizatori diferiți, adică protocolul trebuie să asigure coerența între copiile fișierelor disponibile pe computere diferite.

3. Pierderea datelor și distrugerea integrității sistemului de fișiere în timpul defecțiunilor și defecțiunilor computerelor care joacă rolul de servere de fișiere. Pentru a crește toleranța la erori a unui FS de rețea, puteți stoca mai multe copii ale fiecărui fișier (sau întreg FS) pe mai multe servere. Astfel de copii ale unui fișier se numesc replici.

Replicarea fișierelor nu numai că îmbunătățește toleranța la erori, dar rezolvă și problema supraîncărcării serverelor de fișiere prin distribuirea cererilor de fișiere pe mai multe servere, ceea ce îmbunătățește performanța sistemului de fișiere.

4. Autentificarea se realizează pe un computer, de exemplu, pe client, iar autorizarea, adică verificarea drepturilor de acces la directoare sau fișiere, se realizează pe un altul, acționând ca un server de fișiere. Această problemă comună a tuturor serviciilor de rețea trebuie luată în considerare de protocolul de comunicare între clienții și serverele serviciului de fișiere.

Problemele enumerate sunt rezolvate cuprinzător prin crearea unui serviciu de autentificare centralizată, replicare, cache etc. Aceste servicii suplimentare se reflectă în protocolul de interacțiune între clienți și servere, în urma căruia sunt create diverse protocoale de acest tip care suportă unul. sau alt set de funcții suplimentare. Prin urmare, pentru același FS local pot exista protocoale FS de rețea diferite (Fig. 5.30). Astfel, astăzi sistemul de fișiere NTFS poate fi accesat folosind SMB, NCP (NetWare Control Protocol) și NFS (Network File System - protocol de sistem de fișiere de rețea de la Sun Microsystems, utilizat în diferite versiuni ale sistemului de operare UNIX).

Pe de altă parte, folosind același protocol, poate fi implementat accesul de la distanță la sistemele de fișiere locale de diferite tipuri. De exemplu, protocolul SMB este folosit pentru a accesa nu numai sistemele de fișiere FAT, ci și sistemele de fișiere NTFS și HPFS (Fig. 5.31). Aceste sisteme de fișiere pot fi localizate pe un computer diferit sau pe același computer.__

Întrebări de test pentru capitolul 5

1. Ce avantaje au rețelele față de utilizarea separată a computerelor?

2. Topologiile rețelei fizice și logice sunt întotdeauna aceleași?

3. Cum sunt clasificate rețelele în funcție de dimensiunea zonei acoperite?

4. Ce computer poate acționa ca server în rețea?

5. Ce este un server de fișiere și un server de imprimare?

6. Ce funcții îndeplinesc serverele de înregistrare?

7. Ce funcții îndeplinesc serverele de acces la distanță?

8. Ce este un server proxy?

9. Listați posibilii clienți ai rețelei de calculatoare.

10. Ce sunt clienții „groși” și „subțiri” într-o rețea de calculatoare?

11. Cum înțelegeți termenul „segmentare” a unei rețele?

12. Ce este o adresă MAC?

13. Cum diferă un sistem de operare distribuit de unul în rețea? Există sisteme de rețea cu adevărat distribuite astăzi?

14. Enumerați componentele principale ale unui sistem de operare de rețea. Ce este un serviciu de rețea? Ce servicii de rețea poți numi?

15. Unele servicii de rețea sunt destinate nu utilizatorului, ci administratorului. Ce servicii sunt acestea?

16. Care au fost primele sisteme de operare în rețea? Ce abordări pentru crearea sistemelor de operare în rețea sunt utilizate în prezent?

17. Numiți trăsăturile caracteristice ale rețelelor peer-to-peer. Care este caracteristica principală a unei rețele multi-peer?

18. Ce este un sistem de operare server? Ce sunt ei? Cum diferă un sistem de operare server de un sistem de operare client?

19. Câte variante de scheme cu două niveluri sunt utilizate pentru procesarea distribuită a aplicațiilor?

20. Ce este bun la procesarea aplicațiilor pe două niveluri atunci când serverul și clientul cooperează?

21. Există avantaje ale schemei de procesare a cererilor pe trei niveluri, care sunt acestea?

22. Cum pot interacționa procesele în sistemele distribuite?

23. Care sunt principalele primitive utilizate în sistemul de transport OS de rețea?

24. Cum este organizată sincronizarea proceselor în rețea?

25. Ce se înțelege prin apeluri de procedură la distanță?