NFS: Mrežni sistem datoteka. Postavljanje i montaža NFS-a

12.08.2019 Sigurnost

NFS: zgodan i obećavajući sistem mrežnih datoteka

Mrežni sistem datoteka je mrežna apstrakcija na vrhu redovnog sistema datoteka koja omogućava udaljenom klijentu da mu pristupi preko mreže na isti način kao kada pristupa lokalnim sistemima datoteka. Iako NFS nije bio prvi mrežni sistem datoteka, evoluirao je da postane najsposobniji i najpopularniji mrežni sistem datoteka u UNIX®-u danas. NFS omogućava više korisnika da dijele zajednički sistem datoteka i centralizira podatke kako bi se minimizirao prostor na disku koji je potreban za njihovo pohranjivanje.

Ovaj članak počinje kratkim pregledom istorije NFS-a, a zatim prelazi na istraživanje arhitekture NFS-a i kako bi se ona mogla razvijati u budućnosti.

Kratka istorija NFS-a

Prvi mrežni sistem datoteka zvao se FAL (File Access Listener) i razvio ga je 1976. godine DEC (Digital Equipment Corporation). To je bila implementacija DAP protokola (Data Access Protocol) i bio je dio DECnet paketa protokola. Kao i kod TCP/IP, DEC je objavio specifikacije za svoje mrežne protokole, uključujući DAP protokol.

NFS je bio prvi moderni mrežni sistem datoteka izgrađen na vrhu IP protokola. Njegov prototip se može smatrati eksperimentalnim sistemom datoteka razvijenim u Sun Microsystems-u ranih 80-ih. S obzirom na popularnost ovog rješenja, NFS protokol je uveden kao RFC specifikacija i kasnije evoluirao u NFSv2. NFS se brzo etablirao kao standard zbog svoje sposobnosti da interoperira sa drugim klijentima i serverima.

Standard je naknadno ažuriran na NFSv3, definisan u RFC 1813. Ova verzija protokola je bila skalabilnija od prethodnih verzija i podržavala je veće veličine datoteka (preko 2 GB), asinhrono pisanje i TCP kao transportni protokol. NFSv3 je postavio pravac za razvoj sistema datoteka za široke mreže (WAN). Godine 2000, RFC 3010 (revidiran kao RFC 3530) doveo je NFS u okruženje preduzeća. Sun je predstavio sigurniji NFSv4 sa podrškom za praćenje stanja (prethodne verzije NFS-a nisu podržavale pohranu podataka bez stanja, tj. bile su klasificirane kao bez stanja). Trenutno je najnovija verzija NFS-a verzija 4.1, definirana u RFC 5661, koja dodaje protokolu proširenjem pNFS dodana je podrška za paralelni pristup za distribuirane servere.

Istorija NFS-a, uključujući specifične RFC-ove koji opisuju njegove verzije, prikazana je na slici 1.

Iznenađujuće, NFS se razvija skoro 30 godina. To je izuzetno stabilan i prenosiv sistem mrežnih datoteka sa izvanrednom skalabilnosti, performansama i kvalitetom usluga. Kako se brzine povećavaju i latencija smanjuje prilikom komunikacije unutar mreže, NFS nastavlja biti popularan način implementacije sistema datoteka unutar mreže. Čak iu slučaju lokalnih mreža, virtuelizacija podstiče skladištenje podataka na mreži kako bi se virtuelnim mašinama obezbedila dodatna mobilnost. NFS takođe podržava najnovije modele računarskog okruženja koji imaju za cilj optimizaciju virtuelne infrastrukture.

NFS arhitektura

NFS koristi standardni klijent-server arhitektonski model (kao što je prikazano na slici 2). Server je odgovoran za implementaciju zajedničkog sistema datoteka i skladištenja na koje se klijenti povezuju. Klijent implementira korisnički interfejs na zajednički fajl sistem montiran unutar klijentovog lokalnog prostora datoteka.

Slika 2. Implementacija klijent-server modela u NFS arhitekturi

U Linux®, prekidač virtuelnog sistema datoteka (VFS) pruža sredstva za podršku više sistema datoteka (na primjer, ISO 9660 sistem datoteka na CD-ROM-u i ext3fs sistem datoteka na lokalnom tvrdom disku) istovremeno na jednom hostu . Virtuelni prekidač određuje kojem pogonu se šalje zahtjev i prema tome koji sistem datoteka treba koristiti za obradu zahtjeva. Stoga, NFS ima istu kompatibilnost kao i drugi sistemi datoteka koji se koriste u Linuxu. Jedina razlika u odnosu na NFS je u tome što se umjesto da se obrađuju lokalno na hostu, I/O zahtjevi mogu poslati mreži na izvršenje.

VFS utvrđuje da je primljeni zahtjev NFS i prosljeđuje ga NFS rukovatelju koji se nalazi u kernelu. NFS rukovalac obrađuje I/O zahtjev i prevodi ga u NFS proceduru (OTVARANJE, PRISTUP, CREATE, READ, CLOSE, REMOVE, itd.). Ove procedure, opisane u posebnoj RFC specifikaciji, definiraju ponašanje NFS protokola. Potrebna procedura se bira ovisno o zahtjevu i izvršava se korištenjem RPC (remote procedure call) tehnologije. Kao što mu ime govori, RPC omogućava da se pozivaju procedure između različitih sistema. RPC usluga spaja NFS zahtjev sa svojim argumentima i šalje rezultat odgovarajućem udaljenom hostu, zatim prati prijem i obradu odgovora kako bi ga vratio podnosiocu zahtjeva.

RPC takođe uključuje važan XDR sloj ( eksterno predstavljanje podataka- nezavisno predstavljanje podataka), osiguravajući da svi NFS korisnici koriste isti format za iste tipove podataka. Kada platforma pošalje zahtjev, tip podataka koji koristi može se razlikovati od tipa podataka koji se koristi na hostu koji obrađuje zahtjev. Tehnologija XDR brine se za posao pretvaranja tipova u standardnu reprezentaciju (XDR) tako da platforme koje koriste različite arhitekture mogu interoperirati i dijeliti sisteme datoteka. XDR definira format bita za tipove kao što je float i redoslijed bajtova za tipove kao što su nizovi konstantne i promjenjive dužine. Iako je XDR prvenstveno poznat po svojoj upotrebi u NFS-u, ova specifikacija može biti korisna u svim slučajevima kada morate raditi u istom okruženju sa različitim arhitekturama.

Nakon što je XDR preveo podatke u standardni prikaz, zahtjev se šalje preko mreže pomoću specifičnog transportnog protokola. Rane implementacije NFS-a koristile su UDP, ali se danas TCP koristi za veću pouzdanost.

Sličan algoritam se koristi na strani NFS servera. Zahtjev putuje gore kroz mrežni stog kroz RPC/XDR sloj (za konvertovanje tipova podataka prema arhitekturi servera) i do NFS servera, koji je odgovoran za obradu zahtjeva. Tamo se zahtjev prosljeđuje NFS demonu da odredi ciljni sistem datoteka kojem je adresiran, a zatim ponovo ide na VFS da pristupi tom sistemu datoteka na lokalnom disku. Kompletan dijagram ovog procesa prikazan je na slici 3. U ovom slučaju, lokalni sistem datoteka servera je standardni Linux sistem datoteka, na primjer, ext4fs. U suštini, NFS nije sistem datoteka u tradicionalnom smislu tog pojma, već protokol za daljinski pristup sistemima datoteka.

Za mreže sa velikim kašnjenjem, NFSv4 nudi posebnu složenu proceduru ( složena procedura). Ova procedura vam omogućava da postavite više RPC poziva unutar jednog zahtjeva kako biste minimizirali troškove slanja zahtjeva preko mreže. Ova procedura također implementira mehanizam funkcije povratnog poziva za primanje odgovora.

NFS protokol

Kada klijent počne da koristi NFS, prva radnja je izvođenje operacije montiranja, a to je montiranje udaljenog sistema datoteka u prostor lokalnog sistema datoteka. Ovaj proces počinje pozivom procedure montiranja (jedna od funkcija sistema Linux), koja se preko VFS-a preusmjerava na NFS komponentu. Zatim, RPC poziv funkciji get_port na udaljenom serveru određuje broj porta koji će se koristiti za montiranje, a klijent šalje zahtjev za montiranje putem RPC-a. Ovaj zahtjev na strani servera obrađuje poseban demon rpc.mountd, koji je odgovoran za mount protokol ( mount protokol). Demon provjerava da li je sistem datoteka koji je zahtijevao klijent na listi dostupnih sistema na datom serveru. Ako traženi sistem postoji i klijent ima pristup njemu, odgovor mount RPC navodi deskriptor sistema datoteka. Klijent zadržava informacije o lokalnim i udaljenim točkama montiranja i može napraviti I/O zahtjeve. Protokol montiranja nije siguran sa sigurnosnog stanovišta, tako da NFSv4 umjesto toga koristi interne RPC pozive, koji također mogu upravljati tačkama montiranja.

Da biste pročitali datoteku, prvo je morate otvoriti. U RPC-u ne postoji OPEN procedura; umjesto toga, klijent jednostavno provjerava da li navedena datoteka i direktorij postoje na montiranom sistemu datoteka. Klijent počinje postavljanjem GETATTR RPC zahtjeva direktoriju, koji vraća atribute direktorija ili indikator da direktorij ne postoji. Zatim, da provjeri prisutnost datoteke, klijent izdaje LOOKUP RPC zahtjev. Ako datoteka postoji, na njoj se postavlja GETATTR RPC zahtjev da se saznaju atributi datoteke. Koristeći informacije dobivene uspješnim pozivima LOOKUP i GETATTR, klijent kreira rukohvat datoteke koji se daje korisniku za buduće zahtjeve.

Nakon što je datoteka identificirana na udaljenom sistemu datoteka, klijent može izdati RPC READ zahtjeve. Ovaj zahtjev se sastoji od deskriptora datoteke, stanja, pomaka i broja bajtova za čitanje. Klijent koristi stanje ( stanje) da se utvrdi da li se operacija može izvršiti u ovom trenutku, tj. Da li je fajl zaključan? Offset ( offset) označava na kojoj poziciji treba započeti čitanje, a brojač bajtova ( count) određuje koliko bajtova treba pročitati. Kao rezultat RPC READ poziva, server ne vraća uvijek onoliko bajtova koliko je traženo, ali zajedno sa vraćenim podacima uvijek izvještava koliko je bajtova poslano klijentu.

Inovacija u NFS-u

Dvije najnovije verzije NFS-a su od najvećeg interesa - 4 i 4.1, kao primjeri kojih možete proučavati najvažnije aspekte evolucije NFS tehnologije.

Prije nego što je NFSv4 bio dostupan za obavljanje zadataka upravljanja datotekama kao što su montiranje, zaključavanje, itd. postojali su posebni dodatni protokoli. U NFSv4, proces upravljanja datotekama je pojednostavljen na jedan protokol; Osim toga, počevši od ove verzije, UDP se više ne koristi kao transportni protokol. NFSv4 uključuje podršku za UNIX i Windows® semantiku pristupa datotekama, omogućavajući NFS-u da se prirodno integriše u druge operativne sisteme.

NFSv4.1 je uveo koncept paralelni NFS(paralelni NFS - pNFS). Kako bi pružio veći nivo skalabilnosti, NFSv4.1 implementira arhitekturu u kojoj podaci i metapodaci ( obeležavanje) se distribuiraju po uređajima na sličan način kao što se to radi u grupisanim sistemima datoteka. Kao što je prikazano u , pNFS dijeli ekosistem na tri komponente: klijent, server i skladište. U ovom slučaju pojavljuju se dva kanala: jedan za prijenos podataka, a drugi za prijenos upravljačkih komandi. pNFS odvaja podatke od metapodataka koji ih opisuju, pružajući dvokanalnu arhitekturu. Kada klijent želi pristupiti datoteci, server joj šalje metapodatke sa "markupom". Metapodaci sadrže informacije o lokaciji datoteke na uređajima za pohranu. Kada klijent dobije ove informacije, može direktno pristupiti skladištu bez potrebe za interakcijom sa serverom, poboljšavajući skalabilnost i performanse. Kada klijent završi rad sa datotekom, on potvrđuje promjene napravljene u datoteci i njenu "oznaku". Ako je potrebno, server može od klijenta zatražiti metapodatke s markiranjem.

Sa pojavom pNFS-a, NFS protokolu je dodato nekoliko novih operacija koje podržavaju takav mehanizam. Metoda LayoutGet se koristi za dohvaćanje metapodataka sa servera, metoda LayoutReturn "oslobađa" metapodatke "uhvaćene" od strane klijenta, a metoda LayoutCommit učitava "izgled" primljen od klijenta u skladište tako da bude dostupan drugim korisnicima. Server može pozvati metapodatke od klijenta koristeći metodu LayoutRecall. "Označeni" metapodaci se distribuiraju na više uređaja za pohranu kako bi se omogućio paralelni pristup i visoke performanse.

Podaci i metapodaci se pohranjuju na uređajima za pohranu. Klijenti mogu izvoditi direktne I/O zahtjeve na osnovu primljenih oznaka, a NFSv4.1 server pohranjuje i upravlja metapodacima. Ova funkcionalnost sama po sebi nije nova, ali je pNFS dodao podršku za različite metode pristupa uređajima za skladištenje. Danas pNFS podržava upotrebu blok protokola (Fibre Channel), protokola objekata i sam NFS (čak ni u pNFS obliku).

Razvoj NFS-a se nastavlja, au septembru 2010. objavljeni su zahtjevi za NFSv4.2. Neke od inovacija se odnose na tekuću migraciju tehnologija za skladištenje podataka ka virtuelizaciji. Na primjer, u virtuelnim okruženjima sa hipervizorom, vrlo je vjerovatno da će doći do dupliciranja podataka (više operativnih sistema čita/upisuje i kešira iste podatke). Zbog toga je poželjno da sistem za skladištenje kao celina razume gde dolazi do dupliranja. Ovaj pristup će pomoći da se uštedi prostor predmemorije klijenta i ukupni kapacitet skladištenja. NFSv4.2 predlaže korištenje "mape blokova zajedničkih blokova" za rješavanje ovog problema. Kako moderni sistemi za skladištenje sve više dolaze opremljeni sopstvenom internom računarskom snagom, uvodi se kopiranje na strani servera kako bi se smanjio teret kopiranja podataka preko interne mreže kada se to može efikasno obaviti na samom uređaju za skladištenje. Ostale inovacije uključuju keširanje pod-datoteka za fleš memoriju i preporuke za podešavanje I/O na strani klijenta (kao što je korišćenje mapvise).

NFS Alternatives

Iako je NFS najpopularniji sistem mrežnih datoteka u UNIX-u i Linuxu, postoje i drugi mrežni sistemi datoteka. Na Windows® platformi najčešće se koristi SMB, poznat i kao CIFS; međutim, Windows OS takođe podržava NFS, kao i Linux podržava SMB.

Jedan od najnovijih distribuiranih sistema datoteka podržanih na Linuxu, Ceph, dizajniran je od samog početka da bude sistem datoteka koji je tolerantan na greške POSIX. Više informacija o Cephu možete pronaći u odjeljku.

Vrijedi spomenuti i sistem datoteka OpenAFS (Open Source verzija distribuiranog sistema datoteka Andrew, razvijen na Univerzitetu Carnegie Mellon i IBM Corporation), GlusterFS (distribuirani sistem datoteka opće namjene za organiziranje skalabilnog skladištenja podataka) i Luster (masovni paralelni mrežni sistem datoteka za klaster rješenja). Svi ovi sistemi otvorenog koda mogu se koristiti za izgradnju distribuiranog skladišta.

Zaključak

Razvoj NFS sistema datoteka se nastavlja. Slično Linux operativnom sistemu, koji može podržati i low-end, embedded i high-end rješenja, NFS pruža arhitekturu za skalabilna rješenja za skladištenje pogodna i za pojedince i za organizacije. Kada pogledate put koji je NFS već prošao i izglede za njegov budući razvoj, postaje jasno da će ovaj sistem datoteka nastaviti da mijenja način na koji razmišljamo o tome kako se implementiraju i koriste tehnologije za skladištenje datoteka.

Nisu svi upoznati s protokolima prijenosa podataka. Ali mnogi ljudi bi željeli povezati svoje računare u jednu mrežu ili koristiti server za pohranjivanje datoteka. Jedan od načina da se to uradi je NFS. Kako postaviti NFS server u Ubuntu - čitajte dalje.

Ispravnim konfigurisanjem NFS-a možete kombinovati računare na različitim operativnim sistemima u jednu mrežu.

Mrežni sistem datoteka je protokol za pristup mrežnim datotekama. Kao i obično, sastoji se od dva dijela. Jedan je klijentski, koji se nalazi na računaru sa kojeg se pregledavaju udaljeni podaci. Drugi - server - nalazi se na računaru na kojem se ti podaci čuvaju. Prilično je zgodno koristiti dodatni prostor na disku, posebno na lokalnoj mreži. A ako govorimo o nekim korporativnim računarima, onda je to jednostavno neophodno.

Koja je razlika?

Danas postoji veliki broj protokola i širok izbor softvera koji obavljaju iste funkcije. Šta izdvaja NFS?

Mogućnost povezivanja računara na različitim operativnim sistemima u jednu mrežu. Često je zgodno povezati Windows OS preko NFS-a na Unix sistem, na primjer, Ubuntu. Samba postoji i koristi se za iste svrhe, ali je NFS lakši, jednostavniji i brži od ovog programa, jer se implementira na nivou kernela. Stoga će postavljanje pristupa putem njega obično biti lakše.
NFS omogućava transparentan pristup datotekama. To znači da se svi udaljeni fajlovi reproduciraju potpuno isto kao i lokalni. Programi ne moraju biti nadograđeni za reprodukciju bilo koje datoteke koja se nalazi na serveru.
NFS šalje samo traženi dio datoteke, a ne cijeli fajl.

Da bi u potpunosti funkcionisao, mrežni sistem datoteka mora biti instaliran na najmanje dva računara: server i klijent. Naravno, početnik će se najviše morati pomučiti na serverskom dijelu, jer je tu potrebno “share” (otvoreni pristup) foldera. Međutim, sve se to radi prilično lako.

Kao i većina protokola za prijenos podataka, NFS nije nimalo mlad. Razvijen je 1984. godine i namijenjen je UNIX sistemima. Ovo je i dalje glavna uloga NFS-a, ali mnogi su otkrili da je vrlo zgodno povezati Windows računare sa Linux računarima. Osim toga, NFS je odličan za reprodukciju multimedijalnog sadržaja preko lokalne kućne mreže. Samba u ovoj ulozi često se zamrzava i usporava.

Instaliranje NFS pozadine

Instalirat ćemo serverski dio protokola na Ubuntu 16.04. Naravno, ako imate serversko izdanje, proces se ni na koji način ne razlikuje. Samo što se u tradicionalnoj verziji Ubuntua neke radnje mogu izvesti pomoću grafičkog sučelja.

Instalirajte program. Da biste to učinili, možete koristiti centar za preuzimanje aplikacija ili jednostavno unesite naredbu:

sudo apt install nfs-kernel-server

Nakon toga, bilo bi korisno provjeriti ispravnost instalacije. Nije potrebno ovo raditi, ali ćemo svejedno provjeriti. Unesite naredbu:

Luka bi svuda trebala biti 2049.

Sada provjeravamo da li kernel podržava NFS. Da biste to učinili, unesite:

cat /proc/filesystems | grep nfs
Rezultirajuća vrijednost bi trebala izgledati ovako: nodev nfsd
To znači da sve funkcioniše kako treba. Ako ne, onda unesite naredbu:
Koristeći ga, sami instaliramo modul kernela.
Dodajte protokol u automatsko pokretanje. To nije potrebno raditi, ali je vrlo nezgodno uključiti ga svaki put. Opet, možete ga dodati pomoću posebne stavke menija u postavkama ili ga možete dodati sami pomoću naredbe:
sudo systemctl omogući nfs

Dakle, instalirali smo serverski dio, ostaje samo da ga ispravno konfigurišemo i prijeđemo na klijentski dio.
Postavke
Postavljanje NFS-a u Ubuntu uključuje dijeljenje određenih foldera.
Osim jednostavnog dopuštanja pristupa, morate navesti i parametre koji određuju mogućnosti korisnika u odnosu na ovu mapu.
rw - čitanje i pisanje Ova opcija omogućava čitanje i pisanje datoteka u folderu.
ro - samo za čitanje - dozvoljava samo čitanje fascikle.
sync (podrazumevano) - parametar osigurava pouzdanost prenosa. Ako je omogućeno, nećete moći prenositi više datoteka u isto vrijeme ili na različite računare. Ova postavka će vas spriječiti da odgovorite na druge zahtjeve. Sprečava gubitak podataka, ali prijenos može biti sporiji.
async je inverzno od prethodnog parametra. Prijenos je brži, ali postoji rizik od gubitka informacija.
bezbedno - ova opcija vam omogućava da koristite samo portove ispod 1024. Omogućeno po podrazumevanoj vrednosti.
nesigurno - omogućava korištenje bilo kojeg porta.
nohide - ako montirate nekoliko direktorija, uključujući ugniježđene, tada će ugniježđeni direktoriji, za razliku od roditeljskog direktorija, biti prikazani kao prazni. Parametar će pomoći da se ovo popravi
anonuid - specificira uid za anonimne korisnike. Ovo je poseban korisnički ID.
anongid - specificira gid za anonimne korisnike. GID (ID grupe) - drugi identifikator korisnika.
no_subtree_check - funkcija onemogućuje kontrolu podstabla. Činjenica je da bez njega NFS dodatno provjerava da li korisnici pristupaju samo potrebnim dijelovima direktorija. Ovo usporava stvari. Ovaj parametar ga ubrzava, ali smanjuje sigurnost.

Koristit ćemo ih ovisno o tome šta je potrebno u određenoj situaciji.
Kreirajmo novi folder. Možete koristiti i novu. Naš folder će biti /var/network.
Sada morate dodati ovaj folder u /etc/exports datoteku. Tu se pohranjuju svi fajlovi i fascikle sa otvorenim pristupom mreži. Unos bi trebao izgledati ovako:
/var/network168.1.1(rw,async,no_subtree_check)

192.168.1.1 je IP preko kojeg prenosimo. Obavezno ga je navesti.
Ažurirajte tabelu za izvoz:
Pokušajmo sada pristupiti folderu sa strane klijenta.
Instalacija i konfiguracija NFS klijentskog dijela
Ubuntu
Na Ubuntu-u, povezivanje konfigurisanog servera nije teško. Ovo se radi u samo nekoliko naredbi.
Instalirajte poseban klijentski paket:
sudo apt install nfs-common

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

Mrežni folder je povezan. Koristeći df možete provjeriti sve povezane mrežne mape:
Svoj nivo pristupa možete provjeriti i posebnom komandom:
Onemogućite sistem datoteka na sljedeći način:
Komanda mount se koristi skoro svuda. On je odgovoran za proces montiranja, odnosno priprema prostora na tvrdom disku za korištenje od strane operativnog sistema. Zvuči komplikovano, ali ako pojednostavimo, ispada da jednostavno prenosimo mrežne datoteke na naš računar u novostvoreni folder. Ovdje se zove /mnt/.
Windows
Sa Windowsom je, po pravilu, sve mnogo komplikovanije. NFS klijent se može pokrenuti na svim Windows serverima bez ikakvih problema. Od standardnih, prisutan je na:
Windows 7 Ultimate/Enterprise
Windows 8/8.1 Enterprise
Windows 10 Enterprise

Ne mogu ga naći nigdje drugdje. Ako imate jednu od ovih verzija, učinite sljedeće:
Otvorite meni „Programi i funkcije“.
Kliknite na "Dodavanje komponenti".
Tamo nalazimo NFS i instaliramo samo "Klijent za NFS"; ne treba nam druga komponenta.

Nakon povezivanja, sve se montira istom komandom:
montirati 192.168.1.1:/var/network/ /mnt/

Možete ga demontirati na sljedeći način:
Komande se unose u komandnu liniju koja se pokreće kao administrator. Nakon toga možete lako pronaći željeni mrežni disk pomoću Explorera.
Šta učiniti ako na računaru nema NFS klijenta? Softver možete pokušati da preuzmete putem Microsoftove web stranice ili iz izvora treće strane. Moguće je da će ovdje biti potrebne druge naredbe ili radnje.
Sada imate osnovno razumijevanje o tome kako koristiti NFC i izvršiti osnovno podešavanje. Ovo znanje je dovoljno za uspostavljanje pristupa sa jednog računara na drugi. Štaviše, Windows PC takođe može delovati kao klijent.

Poglavlje 29 NFS: Mrežni sistem datoteka

Uvod

U ovom poglavlju ćemo pogledati mrežni sistem datoteka (NFS), popularnu aplikaciju koja klijentskim aplikacijama pruža transparentan pristup datotekama. Kamen temeljac NFS-a je Sun RPC: Remote Procedure Call, koji ćemo prvo pokriti.

Klijentskom programu nisu potrebni posebni alati da bi iskoristio prednosti NFS-a. Kernel detektuje da se datoteka nalazi na NFS serveru i automatski generiše RPC poziv da bi pristupio datoteci.

Nećemo detaljno razmatrati kako se implementira pristup fajlovima, već ćemo pogledati kako se koriste internet protokoli, posebno UDP.

Sun Remote Procedure Call

U većini slučajeva, problemi mrežnog programiranja se rješavaju pisanjem aplikativnih programa koji pozivaju funkcije koje pruža sistem za obavljanje specifičnih mrežnih operacija. Na primjer, jedna funkcija obavlja aktivno otvaranje TCP-a, druga pasivno otvaranje TCP-a, treća šalje podatke preko TCP veze, četvrta postavlja specifične opcije protokola (omogućava TCP tajmer "ostani živ") i tako dalje. U odeljku Aplikacioni programski interfejsi u poglavlju 1, spomenuli smo da postoje dva popularna skupa funkcija mrežnog programiranja (interfejsi za programiranje aplikacija, API-ji): utičnice i TLI. API koji koristi klijent i API koji koristi server mogu se razlikovati, kao i operativni sistemi koje klijent i server pokreću. Komunikacijski i aplikacijski protokoli određuju da li određeni klijent može komunicirati sa serverom. Unix klijent napisan u C-u koji koristi utičnice kao programsko sučelje i TCP kao komunikacijski protokol može komunicirati sa serverom glavnog računala napisanim u COBOL-u koristeći različite API-je i TCP ako su oba hosta povezana na mrežu i oba imaju TCP implementaciju. /IP.

Obično klijent šalje komande serveru, a server klijentu šalje odgovore. Sve aplikacije koje smo pregledali - Ping, Traceroute, demoni rutiranja, DNS klijenti i serveri, TFTP, BOOTP, SNMP, Telnet, FTP, SMTP - su napravljene na ovaj način.

RPC, poziv udaljene procedure, implementira drugačiji pristup mrežnom programiranju. Klijentski program jednostavno poziva funkcije u serverskom programu. Dakle, ovo je odlučeno sa stanovišta programera, ali u stvarnosti se odvija sljedeći redoslijed radnji.

Kada klijent pozove udaljenu proceduru, poziva se funkcija na lokalnom hostu koja je generirana od strane RPC paketa. Ova funkcija se zove klijentski stub. klijentski stub pakira argumente procedure u mrežnu poruku i šalje poruku serveru.
stub servera na hostu servera prima mrežnu poruku. Argumenti se preuzimaju iz mrežne poruke i poziva se na serversku proceduru koju je napisao programer aplikacije.
Funkcija servera vraća kontrolu serverskom stubu, koji zauzvrat uzima primljene vrijednosti, pakuje ih u mrežnu poruku i šalje poruku natrag klijentskom stubu.
klijentski stub vraća vrijednosti iz mrežne poruke klijentskoj aplikaciji.

Mrežno programiranje pomoću stubova i bibliotečkih RPC rutina koristi API-je (utičnice ili TLI), ali korisničke aplikacije (klijentski program i serverske procedure koje poziva klijent) nikada ne pristupaju API-ju. Klijentska aplikacija treba samo da pozove serversku proceduru, dok su svi detalji implementacije skriveni od strane RPC paketa, klijentskog stuba i serverskog stuba.

RPC paketi imaju sljedeće prednosti.

Programiranje postaje lakše jer ne morate rješavati probleme mrežnog programiranja (a ako to radite, vrlo je malo). Aplikacioni programeri jednostavno pišu klijentski program i serverske procedure koje klijent poziva.
Ako se koristi nepouzdan protokol kao što je UDP, svim detaljima, odnosno vremenskim ograničenjima i ponovnim prijenosima, rukuje RPC paket. Ovo zauzvrat pojednostavljuje korisničku aplikaciju.
RPC biblioteka obrađuje potrebnu konverziju argumenata i povratnih vrijednosti. Na primjer, ako se argumenti sastoje od cijelih brojeva i brojeva s pomičnim zarezom, RPC paket će upravljati svim razlikama između reprezentacije cijelih brojeva i brojeva s pokretnim zarezom na klijentu i serveru. Ovo pojednostavljuje implementaciju klijenata i servera za rad u heterogenim okruženjima.

RPC programiranje je detaljno obrađeno u Poglavlju 18. Dva najpopularnija RPC paketa su Sun RPC i RPC paket u Distributed Computing Environment (DCE) Open Software Foundation (OSF). Pogledat ćemo kako se zove procedura, kako izgleda povratna poruka i kako se to odnosi na Sun RPC paket, budući da se upravo ovaj paket koristi u mrežnom sistemu datoteka. Sun RPC verzija 2 je opisana u RFC 1057 [Sun Microsystems 1988a].

Postoje dvije vrste Sun RPC-a. Jedna verzija je napravljena koristeći socket API i radi sa TCP i UDP. Drugi se zove TI-RPC (nezavisan od transporta), izgrađen korišćenjem TLI API-ja i radi sa svim transportnim slojevima koje obezbeđuje kernel. Sa naše tačke gledišta, nema razlike između njih, jer u ovom poglavlju razmatramo samo TCP i UDP.

Slika 29.1 prikazuje format poruke poziva RPC procedure koristeći UDP.

Slika 29.1 Poruke poziva RPC procedure u UDP formatu datagrama.

Standardna IP i UDP zaglavlja su prikazana ranije (Slika 3.1 i Slika 11.2). Sve što slijedi iza UDP zaglavlja je određeno RPC paketom.

Identifikator transakcije (XID - ID transakcije) postavlja klijent i vraća ga server. Kada klijent primi odgovor, on upoređuje XID koji je vratio server sa XID-om poslanog zahtjeva. Ako se ne podudaraju, klijent odbacuje poruku i čeka da stigne sljedeća. Svaki put kada klijent izda novi RPC, on mijenja XID. Međutim, ako klijent ponovo prenese RPC (ako odgovor nije primljen), XID se ne mijenja.

Varijabla poziva je 0 za poziv i 1 za odgovor. Trenutna RPC verzija je 2. Sljedeće tri varijable, broj programa, broj verzije i broj procedure, identificiraju specifičnu proceduru koja će biti pozvana na poslužitelju.

Akreditivi identifikuju klijenta. U nekim primjerima ovo polje ostaje prazno, dok u drugim možete vidjeti digitalni identifikator korisnika i identifikator grupe kojoj on pripada. Server može pogledati vjerodajnice i odlučiti hoće li obraditi zahtjev ili ne. Verifier se koristi za Secure RPC, koji koristi DES enkripciju. Iako su polja ovlaštenja i validacije polja promjenljive dužine, njihova dužina se prosljeđuje kao dio polja.

Sljedeći su parametri procedure. Njihov format ovisi o tome kako aplikacija definira udaljenu proceduru. Kako prijemnik (server stub) zna veličinu parametara? Pošto se koristi UDP, veličina parametara se može izračunati kao veličina UDP datagrama minus dužina svih polja do polja za provjeru. Kada se TCP koristi umjesto UDP-a, ne postoji koncept fiksne dužine, jer je TCP tok bajtova bez graničnika zapisa. U takvom slučaju, između TCP zaglavlja i XID-a pojavljuje se 4-bajtno polje dužine iz kojeg primatelj uči dužinu RPC poziva u bajtovima. Ovo omogućava da se poruka RPC poziva pošalje preko više TCP segmenata ako je potrebno. (DNS koristi sličnu tehniku; vježba 4 u poglavlju 14.)

Slika 29.2 prikazuje format RPC odgovora. Šalje se sa serverskog stuba do klijentskog stuba kada izađe iz udaljene procedure.

Slika 29.2 Format poruke odgovora RPC procedure kao UDP datagram.

XID poziva se jednostavno kopira u XID odgovora. Polje za odgovor sadrži 1, ovo polje razlikuje izazov i odgovor. Statusno polje sadrži nultu vrijednost ako je pozivna poruka prihvaćena. (Poruka se može odbaciti ako broj RPC verzije nije 2 ili ako server ne može autentifikovati klijenta.) Polje za verifikaciju se koristi u slučaju bezbednog RPC-a za označavanje servera.

Polje statusa prihvatanja sadrži nultu vrijednost ako je sve u redu. Vrijednost različita od nule može ukazivati na, na primjer, netačan broj verzije ili pogrešan broj procedure. Ako se TCP koristi umjesto UDP-a, tada se, kao i kod RPC izazovne poruke, šalje 4-bajtno polje između TCP zaglavlja i XID-a.

XDR: Eksterno predstavljanje podataka

External Data Representation (XDR) je standard koji se koristi za kodiranje vrijednosti u RPC pozivnim i odgovornim porukama - RPC zaglavlja polja (XID, broj programa, status prijema, itd.), parametara procedure i rezultata procedure. Standardni način kodiranja podataka omogućava klijentu da pozove proceduru na sistemu sa različitom arhitekturom. XDR je definisan u RFC 1014 [Sun Microsystems 1987].

XDR definira određeni broj tipova podataka i tačan način na koji se prenose u RPC poruci (redoslijed bitova, redoslijed bajtova i tako dalje). Pošiljalac mora konstruisati RPC poruku u XDR formatu, a zatim primalac konvertuje XDR format u originalni prikaz. (U formatu koji je prihvaćen za njegov sistem.) Vidimo, na primjer, na slikama 29.1 i 29.2, da su sve cjelobrojne vrijednosti koje smo prikazali (XID, poziv, broj programa i tako dalje) 4-bajtni cijeli brojevi . Zaista, svi cijeli brojevi u XDR-u zauzimaju 4 bajta. XDR podržava druge tipove podataka, uključujući neoznačeni cijeli broj, boolean, pokretni zarez, nizove fiksne dužine, nizove promjenjive dužine i strukture.

Port Compliance

RPC serverski programi koji sadrže udaljene procedure koriste dinamički dodijeljene portove umjesto unaprijed poznatih portova. Ovo zahtijeva neki oblik "logiranja" kako bi uvijek znali koji dinamički dodijeljeni port koristi koji RPC program. U Sun RPC-u ovaj logger se naziva maper portova. (Maper portova je server koji pretvara brojeve RPC programa u brojeve portova DARPA protokola. Ovaj server mora biti pokrenut da bi mogao izvršiti RPC poziv.)

Termin "port" u nazivu dolazi od brojeva TCP i UDP portova, karakteristika porodice Internet protokola. Budući da TI-RPC pokreće bilo koji transportni sloj, ne samo TCP i UDP, mapiranje porta imena na sistemima koji koriste TI-RPC (SVR4 i Solaris 2.2, na primjer) je konvertirano u rpcbind. Međutim, nastavit ćemo koristiti poznatiji port maper.

U stvari, sam razrješavač portova mora imati poznati port: UDP port 111 i TCP port 111. Resolver portova je samo RPC serverski program. Ima broj programa (100000), broj verzije (2), TCP port 111 i UDP port 111. Serveri se međusobno registruju sa rezolučem portova koristeći RPC pozive, a klijenti zahtevaju razrešivač portova koristeći RPC pozive. Resolver portova pruža četiri serverske procedure:

PMAPPROC_SET. Poziva RPC server pri pokretanju da registruje broj programa, broj verzije i protokol sa razrješačem portova.
PMAPPROC_UNSET. Poziva server da ukloni prethodno registrovanu transformaciju.
PMAPPROC_GETPORT. Poziva RPC klijent pri pokretanju da dobije broj porta za dati broj programa, broj verzije i protokol.
PMAPPROC_DUMP. Vraća sve stavke (broj programa, broj verzije, protokol i broj porta) u bazu podataka razrješavača portova.

Kada se pokrene RPC serverski program i kasnije kada ga pozove RPC klijentski program, dešavaju se sljedeći koraci.

Pretvarač portova bi trebao početi prvi, obično kada se sistem pokrene. Ovo kreira TCP krajnju tačku i pasivno otvara TCP port 111. Takođe kreira UDP krajnju tačku koja čeka da UDP datagram stigne na UDP port 111.
Kada se RPC serverski program pokrene, on kreira TCP krajnju tačku i UDP krajnju tačku za svaku podržanu verziju programa. (RPC program može podržati više verzija. Klijent specificira potrebnu verziju kada poziva proceduru servera.) Svakoj krajnjoj točki se dodjeljuje dinamički dodijeljeni broj porta. (Nema razlike da li su brojevi TCP i UDP portova isti ili različiti.) Server registruje svaki program, verziju, protokol i broj porta tako što upućuje udaljeni poziv proceduri PMAPPROC_SET razrješavača porta.
Kada se RPC klijentski program pokrene, on poziva proceduru razrješača portova PMAPPROC_GETPORT da dobije dinamički dodijeljeni broj porta za specificirani program, verziju i protokol.
Klijent šalje RPC izazovnu poruku na broj porta dobijen u koraku 3. Ako se koristi UDP, klijent jednostavno šalje UDP datagram koji sadrži poruku RPC izazova (slika 29.1) na broj UDP porta servera. Kao odgovor, server šalje UDP datagram koji sadrži poruku RPC odgovora (slika 29.2). Ako se koristi TCP, klijent vrši aktivno otvaranje broja TCP porta servera i zatim šalje poruku RPC izazova preko veze. Server odgovara porukom RPC odgovora na vezu.

Program rpcinfo(8) ispisuje sve trenutne postavke mapiranja portova. (Ovdje se poziva rutina mapiranja portova PMAPPROC_DUMP.) Tipičan izlaz je prikazan ispod:

ned% /usr/etc/rpcinfo -p
program protiv proto porta
100005 1 tcp 702 montiran NFS demon za montiranje
100005 1 udp 699 mont
100005 2 tcp 702 mountd
100005 2 udp 699 mont

100003 2 udp 2049 nfs NFS sam

100021 1 tcp 709 nlockmgr NFS menadžer zaključavanja
100021 1 udp 1036 nlockmgr
100021 2 tcp 721 nlockmgr
100021 2 udp 1039 nlockmgr
100021 3 tcp 713 nlockmgr
100021 3 udp 1037 nlockmgr

Vidimo da neki programi podržavaju više verzija, a svaka kombinacija broja programa, broja verzije i protokola ima svoj vlastiti raspored broja porta, koji opslužuje razrješavač portova.

Objema verzijama demona za montiranje može se pristupiti preko istog broja TCP porta (702) i istog broja UDP porta (699), međutim svaka verzija menadžera blokiranja ima svoj vlastiti broj porta.

NFS protokol

NFS klijentima omogućava transparentan pristup fajlovima i sistemu datoteka servera. Ovo se razlikuje od FTP-a (Poglavlje 27), koji omogućava prijenos datoteka. Koristeći FTP, vrši se kompletna kopija datoteke. NFS pristupa samo onim dijelovima datoteke kojima je pristupio proces, a glavna prednost NFS-a je što ovaj pristup čini transparentnim. To znači da svaka klijentska aplikacija koja može raditi s lokalnom datotekom može jednako lako raditi sa NFS datotekom, bez ikakvih modifikacija samog programa.

NFS je klijent-server aplikacija napravljena pomoću Sun RPC-a. NFS klijenti pristupaju datotekama na NFS serveru tako što šalju RPC zahteve serveru. Ovo se može implementirati korištenjem normalnih korisničkih procesa – naime, NFS klijent može biti korisnički proces koji upućuje specifične RPC pozive serveru, što također može biti korisnički proces. Međutim, NFS se obično drugačije implementira iz dva razloga. Prvo, pristup NFS datotekama mora biti transparentan za klijenta. Stoga, NFS klijentski pozivi se obavljaju od strane operativnog sistema klijenta u ime klijentovog korisničkog procesa. Drugo, NFS serveri su implementirani unutar operativnog sistema kako bi se poboljšala efikasnost servera. Da je NFS server korisnički proces, svaki zahtjev klijenta i odgovor servera (uključujući podatke za čitanje ili pisanje) morali bi proći kroz separator između kernela i korisničkog procesa, što je općenito prilično skupo.

U ovom odeljku ćemo pogledati verziju 2 NFS-a kako je dokumentovano u RFC 1094 [Sun Microsystems 1988b]. Najbolji opis Sun RPC, XDR i NFS je dat u [X/Open 1991]. Detalji upotrebe i administracije NFS-a dati su u [Stern 1991]. Specifikacije verzije 3 NFS protokola implementirane su 1993. godine, o čemu ćemo raspravljati u dijelu ovog poglavlja.

Slika 29.3 prikazuje tipične postavke NFS klijenta i NFS servera. Na ovoj slici morate obratiti pažnju na sljedeće.

Klijenta nije briga hoće li pristupiti lokalnoj ili NFS datoteci. Kernel to detektuje kada je datoteka otvorena. Nakon otvaranja datoteke, kernel prosljeđuje sav pristup lokalnim datotekama u okvir označen kao "pristup lokalnoj datoteci", a sve veze ka NFS datotekama se prosljeđuju u okvir "NFS klijent".
NFS klijent šalje RPC zahtjeve NFS serveru preko TCP/IP modula. NFS obično koristi UDP, međutim novije implementacije mogu koristiti TCP.
NFS server prima zahtjeve od klijenta kao UDP datagrame na portu 2049. Iako NFS može raditi sa razrješačem portova, koji omogućava serveru da koristi dinamički dodijeljene portove, UDP port 2049 je tvrdo kodiran za NFS u većini implementacija.

Slika 29.3 Tipične postavke NFS klijenta i NFS servera.

Kada NFS server primi zahtjev od klijenta, on se prosljeđuje lokalnoj rutini za pristup datoteci, koja omogućava pristup lokalnom disku na serveru.

Serveru može biti potrebno vrijeme da obradi zahtjeve klijenata. Čak i pristup lokalnom sistemu datoteka može potrajati. Za to vrijeme, server ne želi blokirati zahtjeve drugih klijenata koji također trebaju biti opsluženi. Da bi se izborili sa ovom situacijom, većina NFS servera se pokreće više puta, što znači da postoji više NFS servera unutar kernela. Specifične metode rješenja zavise od operativnog sistema. Većina Unix kernela ne "živi" na više NFS servera, već umjesto toga pokreće više korisničkih procesa (obično nazvanih nfsd) koji vrše jedan sistemski poziv i ostaju unutar kernela kao proces kernela.

Slično, NFS klijentu je potrebno vrijeme da obradi zahtjev od korisničkog procesa na klijentskom hostu. RPC se izdaje hostu servera, nakon čega se očekuje odgovor. Kako bi se osiguralo da korisnički procesi na klijentskom hostu mogu iskoristiti prednosti NFS-a u bilo kojem trenutku, postoji nekoliko NFS klijenata koji rade unutar jezgre klijenta. Konkretna implementacija zavisi i od operativnog sistema. Unix sistemi obično koriste tehniku koja podseća na NFS server: korisnički proces koji se zove biod vrši jedan sistemski poziv i ostaje unutar kernela kao proces kernela.

Većina Unix hostova može funkcionirati kao NFS klijent i NFS server, ili oboje u isto vrijeme. Većina PC (MS-DOS) implementacija ima samo implementacije NFS klijenta. Većina IBM velikih računala pružaju samo funkcionalnost NFS poslužitelja.

NFS je zapravo više od NFS protokola. Slika 29.4 prikazuje različite RPC programe koji se koriste sa NFS-om.

Aplikacija	Broj programa	Broj verzije	Broj procedura
port converter
NFS
mount program
menadžer blokiranja
monitor statusa

Slika 29.4 Različiti RPC programi koji se koriste u NFS-u.

Verzije koje smo prikazali na ovoj slici kao jedinice nalaze se na sistemima kao što je SunOS 4.1.3. Nove implementacije pružaju novije verzije nekih programa. Solaris 2.2, na primjer, također podržava verzije 3 i 4 rezolvera portova i verziju 2 demona mount. SVR4 takođe podržava verziju 3 konvertera portova.

Demon za montiranje se poziva na klijentovom NFS hostu prije nego što klijent može pristupiti sistemu datoteka servera. U nastavku opisujemo ovaj proces.

Menadžer blokiranja i monitor statusa omogućavaju klijentu da blokira neke datoteke koje se nalaze na NFS serveru. Ova dva programa su nezavisna od NFS protokola jer blokiranje zahteva autentifikaciju klijenta i za host klijenta i za server, a sam NFS je "neutralan". (O NFS ravnodušnosti ćemo govoriti detaljnije u nastavku.) Poglavlja 9, 10 i 11 [X/Open 1991] dokumentuju procedure koje koriste menadžer zaključavanja i monitor statusa za zaključavanje u NFS.

Deskriptori fajlova

Jedna od osnova NFS-a je implementirana pomoću deskriptora datoteka. Za pristup datoteci ili direktoriju na poslužitelju objekata, koristi se opaque. Termin neproziran znači da server kreira rukohvat datoteke, prosljeđuje ga nazad klijentu, koji klijent zatim koristi kada pristupa datoteci. Klijent nikada ne gleda sadržaj deskriptora fajla - njegov sadržaj je od interesa samo za server.

NFS klijent prima rukohvat datoteke svaki put kada otvori datoteku koja se zapravo nalazi na NFS serveru. Kada NFS klijent čita ili piše u ovu datoteku (u ime korisničkog procesa), rukohvat datoteke se prosljeđuje nazad serveru. Ovo označava da je datoteci pristupljeno.

Obično korisnički proces ne radi s deskriptorima datoteka. Deskriptori datoteka se razmjenjuju između NFS klijenta i NFS servera. U verziji 2 NFS-a, deskriptor datoteke je 32 bajta, au verziji 3 narastao je na 64 bajta.

Unix serveri obično pohranjuju sljedeće informacije u deskriptoru datoteke: identifikator sistema datoteka (glavni i manji brojevi uređaja sistema datoteka), broj inode (i-čvor) (jedinstveni broj unutar sistema datoteka), broj generacije inode (broj koji se mijenja svaki put kada se inode ponovo koristi za drugu datoteku).

Montiraj protokol

Klijent koristi NFS protokol za montiranje da montira serverov sistem datoteka prije pristupa NFS datotekama. Ovo se obično dešava kada se klijent učitava. Kao rezultat toga, klijent prima rukohvat datoteke serverovom sistemu datoteka.

Slika 29.5 opisuje redoslijed akcija Unix klijenta prilikom izvršavanja naredbe mount(8).

Slika 29.5 Protokol montiranja koji koristi Unix naredba mount.

U tom slučaju se provode sljedeći koraci.

Kada se server pokrene, na njemu se pokreće pretvarač portova.
Nakon razrješavača portova, demon za montiranje (mountd) počinje na serveru. On kreira TCP krajnju tačku i UDP krajnju tačku, i svakoj dodeljuje dinamički dodeljeni broj porta. Zatim registruje ove brojeve sa maperom portova.
Klijent izvršava naredbu mount, koja izdaje RPC poziv serverovom port rezoluču da dobije broj porta od demona mount na serveru. I TCP i UDP se mogu koristiti za komunikaciju između klijenta i razrješača portova, ali se obično koristi UDP.
Resolver portova prijavljuje broj porta.
Komanda mount izdaje RPC poziv demonu mount da montira serverov sistem datoteka. Opet, može se koristiti ili TCP ili UDP, međutim UDP se obično koristi. Server sada može potvrditi klijenta na osnovu njegove IP adrese i broja porta da vidi da li klijent može montirati navedeni sistem datoteka.
Daemon za montiranje odgovara ručnikom datoteke na navedeni sistem datoteka.
Klijentova naredba mount izdaje sistemski poziv mount da poveže rukohvat datoteke dobiven u koraku 5 s lokalnom točkom montiranja na klijentovom hostu. Rukohvat datoteke je pohranjen u klijentovom NFS kodu, i od sada svaki pristup korisničkih procesa datotekama u sistemu datoteka servera koristit će ručicu datoteke kao početnu tačku.

Ova implementacija prepušta cijeli proces montiranja, osim poziva sistema mount na klijentu, korisničkim procesima, a ne kernelu. Tri programa koja smo prikazali - komanda za montiranje, rezolver portova i demon za montiranje - su korisnički procesi.

U ovom primjeru, na hostu sun (NFS klijent), naredba je izvršena

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

Ova naredba montira /usr direktorij na bsdi host (NFS server) kao lokalni sistem datoteka /nfs/bsdi/usr. Slika 29.6 prikazuje rezultat.

Slika 29.6 Montiranje bsdi:/usr direktorija kao /nfs/bsdi/usr na host sun.

Nakon toga, kada se pristupa datoteci /nfs/bsdi/usr/rstevens/hello.c na sun klijentu, pristupa se datoteci /usr/rstevens/hello.c na bsdi serveru.

NFS procedure

NFS server pruža 15 procedura koje ćemo sada opisati. (Brojevi koji se koriste u ovom opisu nisu isti kao brojevi NFS procedura, jer smo ih grupisali prema funkcionalnosti.) Iako je NFS dizajniran da radi na svim operativnim sistemima, a ne samo na Unix sistemima, neke od procedura su bazirane posebno na funkcionisanju Unixa , što zauzvrat možda neće biti podržano od strane drugih operativnih sistema (na primjer, čvrste veze, simboličke veze, grupno korištenje, prava pristupa izvršavanju itd.). Poglavlje 4 sadrži više informacija o karakteristikama sistema datoteka, od kojih neke koristi NFS.

GETATTR. Vraća atribute datoteke: tip datoteke (obična datoteka, direktorij, itd.), prava pristupa, veličina datoteke, vlasnik datoteke, vrijeme posljednjeg pristupa i tako dalje.
SETATTR. Postavlja atribute datoteke. Može se postaviti samo određeni skup atributa: prava pristupa, vlasnik, vlasništvo grupe, veličina, vrijeme posljednjeg pristupa i vrijeme posljednje izmjene.
STATFS. Vraća status sistema datoteka: količinu slobodnog prostora, optimalnu veličinu za prijenos i tako dalje. Koristi, na primjer, Unix df naredba.
POGLEDAJ GORE. "Procjenjuje" datoteku. Ovu proceduru klijent poziva svaki put kada korisnički proces otvori datoteku koja se nalazi na NFS serveru. Vraća se ručka datoteke, zajedno sa atributima datoteke.
PROČITAJTE. Čita iz datoteke. Klijent specificira rukohvat datoteke, početni pomak bajta i maksimalan broj bajtova za čitanje (do 8192).
PISATI. Upisuje u fajl. Klijent specificira rukohvat datoteke, početni pomak u bajtovima, broj bajtova za pisanje i podatke za pisanje.
NFS upisi moraju biti sinhroni (sa čekanjem). Server ne može odgovoriti OK sve dok podaci nisu uspješno zapisani (i sve druge informacije o fajlu koje treba ažurirati) na disk.
STVORITI. Kreira datoteku.
REMOVE. Briše datoteku.
RENAME. Preimenuje datoteku.
VEZA. Pravi čvrstu vezu do datoteke. Čvrsta veza je Unix koncept koji specificira da dati fajl na disku može imati bilo koji broj ulaznih tačaka (imena, koji se takođe nazivaju čvrste veze) koje upućuju na tu datoteku.
SYMLINK. Kreira simboličku vezu do datoteke. Simbolička veza je datoteka koja sadrži ime druge datoteke. Većina operacija koje se izvode na simboličkoj vezi (na primjer, otvaranje) zapravo se izvode na datoteci na koju simbolička veza upućuje.
READLINK. Čitanje simbolične veze vraća ime datoteke na koju simbolska veza ukazuje.
MKDIR. Kreira direktorij.
RMDIR. Briše direktorij.
READDIR. Čita imenik. Koristi se, na primjer, naredbom Unix ls.

U stvari, prikazana imena procedura počinju prefiksom NFSPROC_, koji smo izostavili.

UDP ili TCP?

NFS je prvobitno napisan da koristi UDP, a svi dobavljači pružaju ovu mogućnost. Međutim, novije implementacije takođe podržavaju TCP. TCP podrška se koristi za rad preko globalnih mreža, koje postaju sve brže. Stoga, upotreba NFS-a više nije ograničena na lokalne mreže.

Granice između lokalnih i globalnih mreža se brišu, a sve se to dešava vrlo brzo. Vremena povratka variraju u veoma širokom rasponu i prelivanje se dešava sve češće. Ove karakteristike globalnih mreža dovode do toga da one sve više koriste algoritme koje smo razmatrali za TCP - spor start i izbjegavanje zagušenja. Pošto UDP ne pruža ništa slično ovim algoritmima, oni ili slični moraju biti ugrađeni u NFS klijent i server, inače se mora koristiti TCP.

NFS preko TCP-a

Berkeley Net/2 NFS implementacija podržava i UDP i TCP. [Macklem 1991] opisuje ovu implementaciju. Pogledajmo kako se korištenje NFS-a razlikuje kada se radi preko TCP-a.

Kada se server pokrene, pokreće NFS server, koji se aktivno otvara na TCP portu 2049, čekajući da od klijenta stigne zahtjev za povezivanje. Ovo se obično radi pored redovnog NFS UDP-a, koji osluškuje dolazne datagrame na UDP portu 2049.
Kada klijent montira serverov sistem datoteka koristeći TCP, on vrši aktivno otvaranje na TCP portu 2049 na serveru. Ovo uspostavlja TCP vezu između klijenta i servera za ovaj sistem datoteka. Ako isti klijent montira drugi sistem datoteka na istom serveru, kreira se druga TCP veza.
I klijent i server postavljaju TCP opciju "ostani živ" na svojim krajevima veze (poglavlje 23). Ovo vam omogućava da odredite trenutak kvara ili ponovnog pokretanja jednog ili drugog učesnika u razmjeni.
Sve aplikacije na klijentu koje koriste serverov sistem datoteka dijele istu TCP vezu sa tim sistemom datoteka. Na primjer, da postoji na slici 29.6, postojao bi drugi direktorij na bsdi-u, pod nazivom smith, ispod direktorija /usr, pristupi datotekama u /nfs/bsdi/usr/rstevens i /nfs/bsdi/usr/smith bi dijelili ista stvar ista TCP veza.
Ako klijent utvrdi da se server srušio ili ponovo pokrenuo (nakon što je primio grešku TCP "veza je istekla" ili "veza je zatvorena od strane hosta"), pokušava se ponovo povezati sa serverom. Klijent izvodi još jedno aktivno otvaranje da ponovo uspostavi TCP vezu za ovaj sistem datoteka. Svaki zahtjev od klijenta kojem je isteklo vrijeme na prethodnoj vezi se ponovo izdaje na novoj vezi.
Ako klijent ne uspije, rade i aplikacije koje su bile pokrenute prije kvara. Kada se klijent ponovo pokrene, može ponovo montirati serverov sistem datoteka koristeći TCP, koristeći drugu TCP vezu sa serverom. Prethodna veza između klijenta i servera za ovaj sistem datoteka je u poluotvorenom stanju (server misli da je još uvijek otvorena), međutim, pošto je server postavio opciju "ostani živ", ova poluotvorena veza će biti zatvoreno kada TCP server pošalje sljedeću sondu." ostani živ."

Vremenom, drugi dobavljači planiraju da podrže NFS preko TCP-a.

NFS primjeri

Koristimo tcpdump da vidimo koje NFS rutine klijent poziva za normalne operacije sa datotekama. Kada tcpdump utvrdi da UDP datagram sadrži RPC poziv (poziv je 0 na slici 29.1) sa odredišnim portom 2049, dekodira datagram kao NFS zahtjev. Slično, ako UDP datagram sadrži RPC odgovor (odgovor je 1 na slici 29.2) sa izvornim portom 2049, on dekodira datagram kao NFS odgovor.

Jednostavan primjer: čitanje datoteke

U prvom primjeru kopirat ćemo datoteku koja se nalazi na NFS serveru na terminal pomoću naredbe cat(1):

ned% mačka /nfs/bsdi/usr/rstevens/hello.c kopiranje datoteke na terminal
main()
{
printf("zdravo, svijet\n");
}

/nfs/bsdi/usr sistem datoteka na hostu sun (NFS klijent) je zapravo /usr sistem datoteka na hostu bsdi (NFS server), kao što je prikazano na slici 29.6. Sun kernel detektuje ovo kada mačka otvori datoteku i koristi NFS za pristup datoteci. Slika 29.7 prikazuje izlaz naredbe tcpdump.

1 0.0 sun.7aa6 > bsdi.nfs: 104 getattr
2 0,003587 (0,0036) bsdi.nfs > sun.7aa6: odgovor ok 96

3 0,005390 (0,0018) sun.7aa7 > bsdi.nfs: 116 pretraga "rstevens"
4 0,009570 (0,0042) bsdi.nfs > sun.7aa7: odgovor ok 128

5 0,011413 (0,0018) sun.7aa8 > bsdi.nfs: 116 traži "hello.c"
6 0,015512 (0,0041) bsdi.nfs > sun.7aa8: odgovor ok 128

7 0.018843 (0.0033) sun.7aa9 > bsdi.nfs: 104 getattr
8 0,022377 (0,0035) bsdi.nfs > sun.7aa9: odgovor ok 96

9 0.027621 (0.0052) sun.7aaa > bsdi.nfs: 116 pročitano 1024 bajtova @ 0
10 0,032170 (0,0045) bsdi.nfs > sun.7aaa: odgovori ok 140

Slika 29.7 NFS rad pri čitanju datoteke.

Komanda tcpdump dekodira NFS zahtjev ili odgovor, a također ispisuje XID polje za klijenta umjesto broja porta. XID polje u redovima 1 i 2 je 0x7aa6.

Ime datoteke /nfs/bsdi/usr/rstevens/hello.c obrađuje open funkcija u klijentskom kernelu jedan po jedan element imena. Kada funkcija open dostigne /nfs/bsdi/usr, ona utvrđuje da je ovo tačka montiranja NFS sistema datoteka.

Na liniji 1, klijent poziva GETATTR da dobije atribute direktorija servera koji je klijent montirao (/usr). Ovaj RPC zahtjev sadrži 104 bajta podataka, pored IP i UDP zaglavlja. Odgovor na liniji 2 vraća OK i sadrži 96 bajtova podataka, pored IP i UDP zaglavlja. Na ovoj slici možemo vidjeti da minimalna NFS poruka sadrži približno 100 bajtova podataka.

Na liniji 3, klijent poziva LOOKUP na datoteci rstevens i prima odgovor OK na liniji 4. LOOKUP specificira ime datoteke rstevens i rukohvat datoteke koju je pohranilo kernel kada je udaljeni sistem datoteka montiran. Odgovor sadrži novu ručicu datoteke koja se koristi u sljedećem koraku.

Na liniji 5, klijent traži datoteku hello.c koristeći rukohvat datoteke iz reda 4. Prima drugačiji ručnik datoteke na liniji 6. Ovaj novi handle datoteke je upravo ono što klijent koristi na redovima 7 i 9 za pristup datoteci / nfs /bsdi/usr/rstevens/hello.c. Vidimo da klijent izvodi LOOKUP na svakoj komponenti imena u putanji do datoteke koja se otvara.

U redu 7, klijent ponovo izvršava GETATTR, nakon čega slijedi READ u redu 9. Klijent zahtijeva 1024 bajta počevši od pomaka 0, ali prima manje od 1024 bajta podataka. (Nakon oduzimanja veličine RPC polja i drugih vrijednosti koje vraća procedura READ, 38 bajtova podataka se vraća u red 10. To je upravo veličina datoteke hello.c.)

U ovom primjeru, korisnički proces ne zna ništa o ovim NFS zahtjevima i odgovorima koje izvršava kernel. Aplikacija samo poziva core open funkciju, koja uzrokuje razmjenu 3 zahtjeva i 3 odgovora (redovi 1-6), a zatim poziva funkciju čitanja jezgre, koja poziva 2 zahtjeva i 2 odgovora (redovi 7-10). Za klijentsku aplikaciju, datoteka koja se nalazi na NFS serveru je transparentna.

Jednostavan primjer: kreiranje direktorija

Kao drugi primjer, promijenimo radni direktorij u direktorij koji se nalazi na NFS serveru, a zatim kreiramo novi direktorij:

ned% cd /nfs/bsdi/usr/rstevens promijenite radni direktorij
sunce % mkdir Mail kreirajte direktorij

Slika 29.8 prikazuje izlaz naredbe tcpdump.

1 0.0 sun.7ad2 > bsdi.nfs: 104 getattr
2 0,004912 (0,0049) bsdi.nfs > sun.7ad2: odgovor ok 96

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

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

7 35.775236 (0.0018) sun.7ad5 > bsdi.nfs: 112 traži "Mail"
8 35.780914 (0.0057) bsdi.nfs > sun.7ad5: odgovor ok 28

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

Slika 29.8 NFS operacija kada se mijenja direktorij (cd) u NFS direktorij i zatim kreira direktorij (mkdir).

Prilikom promjene imenika, klijent dva puta poziva GETATTR (redovi 1-4). Kada kreiramo novi direktorij, klijent poziva GETATTR (redovi 5 i 6), zatim LOOKUP (redovi 7 i 8 da provjeri da direktorij ne postoji), zatim MKDIR da kreira direktorij (redovi 9 i 10). Odgovor OK na liniji 8 ne znači da direktorij postoji. To jednostavno znači da je procedura vratila neku vrijednost. tcpdump ne tumači vrijednost koju vraćaju NFS procedure. Komanda jednostavno ispisuje OK i broj bajtova podataka u odgovoru.

Indiferentnost

Jedna od karakteristika NFS-a (NFS kritičari to nazivaju bradavicom, a ne osobinom) je da je NFS server indiferentan. Server nije briga koji klijenti pristupaju kojim fajlovima. Imajte na umu da lista NFS procedura prikazana ranije ne uključuje otvorene ili zatvorene procedure. Procedura LOOKUP je slična otvaranju, ali server nikada ne zna da li je klijent pristupio datoteci nakon što je LOOKUP napravljen.

Razlog za ovakvo ponašanje "ne zanima me" je da se olakša oporavak od kvara servera nakon što se sruši i ponovo pokrene.

Primjer: greška servera

U sljedećem primjeru, čitamo datoteku sa NFS servera kada se server sruši i ponovo pokrene. Ovo će pokazati kako "ravnodušnost" servera omogućava klijentu da "ne zna" da je server otkazao. Sve vrijeme dok se server ruši i ponovo pokreće, klijent nije svjestan problema, a klijentska aplikacija radi isto kao i prije.

Na Sun klijentu smo pokrenuli cat sa veoma velikim fajlom kao argumentom (/usr/share/lib/termcap na svr4 NFS serveru), isključili Ethernet kabl usred prenosa, isključili i ponovo pokrenuli server, a zatim ponovo povezali kabl . Klijent je konfigurisan da čita 1024 bajta po NFS čitanju. Slika 29.9 prikazuje izlaz tcpdump.

Redovi 1-10 odgovaraju klijentu koji otvara datoteku. Ova operacija je slična onoj prikazanoj na slici 29.7. U redu 11 vidimo prvo čitanje (READ) iz datoteke od 1024 bajta podataka; odgovor se vratio na red 12. Ovo se nastavlja do reda 129 (čitanje 1024 bajta READ-a i zatim odgovor OK).

U redovima 130 i 131 vidimo dva zahtjeva koja su istekla i ponovo se podnose u redovima 132 i 133. Prvo pitanje: vidimo dva zahtjeva za čitanje, jedan počinje od pomaka 65536, a drugi počinje od pomaka 73728, zašto? Klijentsko jezgro je utvrdilo da klijentska aplikacija čita sekvencijalno i pokušalo je unaprijed dobiti blokove podataka. (Većina Unix kernela radi ovo čitanje unaprijed.) Klijentsko jezgro također pokreće nekoliko NFS blokova ulazno/izlaznih (I/O) demona (biod procesa) koji pokušavaju generirati više RPC zahtjeva u ime klijenta. Jedan demon čita 8192 bajta, počevši od 65536 (u lancima od 1024 bajta), a ostali čitaju naprijed 8192 bajta, počevši od 73728.

Retransmisije klijenata pojavljuju se na linijama 130-168. U redu 169 vidimo da se server ponovo pokrenuo i poslao ARP zahtjev prije nego što odgovori na klijentov NFS zahtjev na liniji 168. Odgovor na liniju 168 se šalje na liniji 171. Klijentovi READ zahtjevi se nastavljaju.

1 0.0 sun.7ade > svr4.nfs: 104 getattr
2 0,007653 (0,0077) svr4.nfs > sun.7ade: odgovori ok 96

3 0,009041 (0,0014) sun.7adf > svr4.nfs: 116 lookup "share"
4 0,017237 (0,0082) svr4.nfs > sun.7adf: odgovori ok 128

5 0,018518 (0,0013) sun.7ae0 > svr4.nfs: 112 traži "lib"
6 0,026802 (0,0083) svr4.nfs > sun.7ae0: odgovor ok 128

7 0,028096 (0,0013) sun.7ae1 > svr4.nfs: 116 traži "termcap"
8 0,036434 (0,0083) svr4.nfs > sun.7ae1: odgovori ok 128

9 0,038060 (0,0016) sun.7ae2 > svr4.nfs: 104 getattr
10 0,045821 (0,0078) svr4.nfs > sun.7ae2: odgovor ok 96

11 0,050984 (0,0052) sun.7ae3 > svr4.nfs: 116 pročitano 1024 bajtova @ 0
12 0,084995 (0,0340) svr4.nfs > sun.7ae3: odgovori ok 1124

Čitanje

128 3.430313 (0.0013) sun.7b22 > svr4.nfs: 116 pročitano 1024 bajtova @ 64512
129 3.441828 (0.0115) svr4.nfs > sun.7b22: odgovor ok 1124

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

132 4.993021 (0.1244) sun.7b23 > svr4.nfs: 116 pročitano 1024 bajtova @ 65536
133 5.732217 (0.7392) sun.7b24 > svr4.nfs: 116 pročitano 1024 bajtova @ 73728

134 6.732084 (0.9999) sun.7b23 > svr4.nfs: 116 pročitano 1024 bajtova @ 65536
135 7.472098 (0.7400) sun.7b24 > svr4.nfs: 116 pročitano 1024 bajtova @ 73728

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

138 17.171767 (6.2198) sun.7b23 > svr4.nfs: 116 pročitano 1024 bajtova @ 65536
139 17.911762 (0.7400) sun.7b24 > svr4.nfs: 116 pročitano 1024 bajtova @ 73728

140 31.092136 (13.1804) sun.7b23 > svr4.nfs: 116 pročitano 1024 bajtova @ 65536
141 31.831432 (0.7393) sun.7b24 > svr4.nfs: 116 pročitano 1024 bajtova @ 73728

142 51.090854 (19.2594) sun.7b23 > svr4.nfs: 116 pročitano 1024 bajtova @ 65536
143 51.830939 (0.7401) sun.7b24 > svr4.nfs: 116 pročitano 1024 bajtova @ 73728

144 71.090305 (19.2594) sun.7b23 > svr4.nfs: 116 pročitano 1024 bajtova @ 65536
145 71.830155 (0.7398) sun.7b24 > svr4.nfs: 116 pročitano 1024 bajtova @ 73728

Retransmisije

167 291.824285 (0.7400) sun.7b24 > svr4.nfs: 116 pročitano 1024 bajtova @ 73728
168 311.083676 (19.2594) sun.7b23 > svr4.nfs: 116 pročitano 1024 bajtova @ 65536

Server je ponovo pokrenut

169 311.149476 (0.0658) arp tko ima sunce reci svr4
170 311.150004 (0.0005) arp odgovor sunce je-at 8:0:20:3:f6:42

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

172 311.156671 (0.0018) sun.7b25 > svr4.nfs: 116 pročitano 1024 bajtova @ 66560
173 311.168926 (0.0123) svr4.nfs > sun.7b25: odgovori ok 1124
čitanje

Slika 29.9 Klijent čita datoteku kada se NFS server sruši i ponovo pokrene.

Klijentska aplikacija nikada neće znati da se server srušio i ponovo pokrenuo, osim što je između redova 129 i 171 bila pauza od 5 minuta, tako da je pad servera transparentan za klijenta.

Da biste procijenili dužinu vremenskog ograničenja ponovnog prijenosa u ovom primjeru, zamislite da postoje dva klijenta demona, svaki sa svojim vlastitim timeoutima. Intervali za prvi demon (čitanje od ofseta 65536) su otprilike sljedeći (zaokruženi na dvije decimale): 0,68; 0,87; 1,74; 3.48; 6.96; 13.92; 20.0; 20.0; 20.0 i tako dalje. Intervali za drugi demon (čitanje od ofseta 73728) su potpuno isti. To znači da ovi NFS klijenti koriste vremenska ograničenja koja su višekratna od 0,875 sekundi, sa gornjim ograničenjem od 20 sekundi. Nakon svakog vremenskog ograničenja, interval retransmisije se udvostručuje: 0,875; 1,75; 3.5; 7.0 i 14.0.

Koliko će vremena trebati klijentu da izvrši retransmisije? Klijent ima dvije opcije koje mogu utjecati na to. Prvo, ako je serverov sistem datoteka tvrdo montiran, klijent će ponovo prenositi zauvijek, ali ako je serverov sistem datoteka meko montiran, klijent će prestati pokušavati nakon fiksnog broja retransmisija. Također, u slučaju tvrdog montiranja, klijent ima opciju da dozvoli korisniku da prekine neuspjele retransmisije ili da ne prekine. Ako, prilikom montiranja serverskog sistema datoteka, klijentov host naznači da se može prekinuti, i ako ne želimo da čekamo 5 minuta da se server ponovo pokrene nakon pada, možemo unijeti simbol prekida da prekinemo klijentsku aplikaciju.

Nekoliko identičnih procedura

RPC procedure mogu biti izvršene od strane servera nekoliko puta, ali i dalje vraćaju isti rezultat. Na primjer, NFS procedura čitanja. Kao što smo videli na slici 29.9, klijent jednostavno ponovo izdaje READ poziv sve dok dobije odgovor. U našem primjeru, razlog za ponovnu transmisiju je bio taj što je server nestao. Ako server nije otkazao i poruke koje sadrže RPC odgovore su izgubljene (pošto je UDP nepouzdan protokol), klijent jednostavno ponovo šalje i server ponovo radi isto READ. Isti dio iste datoteke se ponovo čita i šalje klijentu.

Ovo funkcionira jer svaki READ zahtjev za čitanje sadrži početni pomak. Ako bi NFS procedura zatražila od servera da pročita sljedećih N bajtova datoteke, to ne bi funkcionisalo. Ako server nije bio ravnodušan (ovo je suprotno od indiferentnog) i odgovor je izgubljen i klijent ponovo izdaje READ za sljedećih N bajtova, rezultat bi bio drugačiji. Zbog toga procedure NFS READ i WRITE imaju početni pomak. Klijent je taj koji održava stanje (trenutni pomak za svaki fajl), a ne server.

Nažalost, ne mogu se sve operacije sistema datoteka izvesti više puta. Na primjer, zamislite sljedeće korake: NFS klijent izdaje REMOVE zahtjev za uklanjanje datoteke; NFS server briše datoteku i odgovara OK; odgovor servera izgubljen; NFS klijent istekne i ponovo šalje zahtjev; NFS server ne može pronaći datoteku i vraća grešku; Klijentska aplikacija prima grešku u kojoj se navodi da datoteka ne postoji. Ova greška se vraća klijentskoj aplikaciji, a ova greška nosi netačne informacije - datoteka nije postojala i izbrisana je.

Ispod je lista NFS procedura koje se mogu izvršiti više puta: GETATTR, STATFS, LOOKUP, READ, WRITE, READLINK i READDIR. Procedure koje se ne mogu izvršiti više puta: CREATE, REMOVE, RENAME, LINK, SYMLINK, MKDIR i RMDIR. SETATTR se obično izvršava više puta, osim ako se koristi za skraćivanje datoteke.

Budući da će se odgovori bez roditelja uvijek pojaviti kada se koristi UDP, NFS serveri moraju imati način za rukovanje operacijama koje se ne mogu izvoditi više puta. Većina servera ima predmemoriju nedavnih odgovora u koju pohranjuju posljednje primljene odgovore za takve operacije. Svaki put kada server primi zahtjev, prvo pregledava svoju keš memoriju i ako se pronađe podudaranje, vraća prethodni odgovor umjesto da ponovo poziva NFS proceduru. [Juszczak 1989] opisuje detalje ovih tipova keša.

Ovaj pristup serverskim procedurama primjenjuje se na sve aplikacije zasnovane na UDP-u, a ne samo na NFS. DNS, na primjer, pruža uslugu koja se može koristiti više puta bez boli. DNS server može upiti parser bilo koji broj puta, što neće dovesti do negativnih rezultata (možda, osim što će mrežni resursi biti zauzeti).

NFS verzija 3

Tokom 1994. godine objavljene su specifikacije za verziju 3 NFS protokola [Sun Microsystems 1993]. Očekuje se da će implementacije postati dostupne tokom 1994. godine.

Evo kratkog pregleda glavnih razlika između verzija 2 i 3. Nazvat ćemo ih V2 i V3.

Deskriptori datoteka u V2 su niz fiksne veličine od 32 bajta. U V3 to je niz varijabilne veličine sa veličinom do 64 bajta. Niz varijabilne dužine u XDR-u je definiran 4-bajtnim brojačem iza kojeg slijede stvarni bajtovi. Ovo smanjuje veličinu deskriptora datoteke u implementacijama kao što je Unix, gdje je potrebno samo oko 12 bajtova, ali omogućava implementacijama koje nisu Unix da razmjenjuju dodatne informacije.
V2 ograničava broj bajtova po RPC proceduri READ ili WRITE na 8192 bajta. Ovo ograničenje se ne primjenjuje u V3, što zauzvrat znači da će korištenje UDP-a ograničenje biti samo veličina IP datagrama (65535 bajtova). Ovo omogućava korištenje velikih paketa za čitanje i pisanje na brzim mrežama.
Veličine datoteka i pomaci početnih bajtova za procedure READ i WRITE prošireni su sa 32 na 64 bita, omogućavajući rukovanje većim veličinama datoteka.
Atributi datoteke se vraćaju u svakom pozivu koji može utjecati na atribute. Ovo smanjuje broj GETATTR poziva koje zahtijeva klijent.
Upisi (WRITE) mogu biti asinhroni, dok su u V2 trebali biti sinhroni. Ovo može poboljšati performanse WRITE procedure.
Jedna procedura je uklonjena (STATFS) i dodato je sedam: ACCESS (provjeri dozvole za fajlove), MKNOD (kreiraj poseban Unix fajl), READDIRPLUS (vraća imena fajlova u direktorijumu zajedno sa njihovim atributima), FSINFO (vraća statističke informacije o sistem datoteka), FSSTAT (vraća informacije o dinamičkom sistemu datoteka), PATHCONF (vraća informacije o datoteci POSIX.1) i COMMIT (urezuje prethodno napravljeno asinhrono upisivanje u trajno skladište).

Kratki zaključci

RPC je način da se izgradi klijent-server aplikacija na takav način da klijent jednostavno poziva procedure na serveru. Svi mrežni detalji su skriveni u klijentskim i serverskim stubovima, koji se generišu za aplikacije pomoću RPC paketa i u rutinama RPC biblioteke. Pokazali smo format RPC pozivnih i odgovornih poruka i spomenuli da se XDR koristi za kodiranje vrijednosti, omogućavajući RPC klijentima i serverima da rade na različitim arhitekturama mašina.

Jedna od najčešće korištenih RPC aplikacija je Sun NFS, heterogeni protokol za pristup datotekama koji se široko koristi na hostovima gotovo svih veličina. Pogledali smo NFS i kako on koristi UDP ili TCP. Protokol NFS verzije 2 definira 15 procedura.

Klijentski pristup NFS serveru počinje protokolom montiranja, nakon čega se klijentu vraća rukohvat datoteke. Klijent tada može pristupiti datotekama na serverovom sistemu datoteka koristeći ovu ručicu datoteke. Imena datoteka se traže na serveru jedan po jedan element imena, vraćajući novu oznaku datoteke za svaki element. Konačni rezultat je ručka datoteke kojoj se pristupilo, a koja se koristi za sekvencijalno čitanje i pisanje.

NFS pokušava da sve svoje procedure učini nezavisnim od broja izvršenja, tako da klijent može jednostavno ponovo izdati zahtev ako se odgovor izgubi. Vidjeli smo primjere ovoga gdje je klijent čitao datoteku dok se server srušio i ponovo pokrenuo.

Vježbe

Na slici 29.7, vidjeli smo da tcpdump tumači pakete kao NFS zahtjeve i odgovore i ispisuje XID. Može li tcpdump to učiniti za bilo koje RPC zahtjeve ili odgovore?

Zašto mislite da RPC serverski program na Unix sistemima koristi dinamički dodijeljene portove, a ne one unaprijed poznate?

RPC klijent je pozvao dvije serverske procedure. Prvi postupak je trajao 5 sekundi, a drugi - 1 sekundu. Klijent ima vremensko ograničenje od 4 sekunde. Nacrtajte vremenski dijagram onoga što se razmjenjuje između klijenta i servera. (Zamislite da nije bilo vremena utrošeno na prosljeđivanje poruke od klijenta do servera i obrnuto.)

U primjeru na slici 29.9, šta bi se dogodilo da se Ethernet kartica NFS servera ukloni dok je NFS server isključen?

Kada se server ponovo pokrenuo na slici 29.9, obradio je zahtjev počevši od pomaka 65536 (redovi 168 i 171), a zatim je obradio sljedeći zahtjev počevši od pomaka 66560 (redovi 172 i 173). Šta se događa s upitom koji počinje od pomaka 73728 (red 167)?

Kada smo opisali procedure neovisne o broju NFS izvršenja, pokazali smo primjer REMOVE odgovora koji je izgubljen u mreži. Šta se događa u ovom slučaju ako se umjesto UDP-a koristi TCP?

Ako NFS server koristi dinamički dodeljen port umesto porta 2049, šta se dešava sa NFS klijentom kada se server sruši i ponovo pokrene?

Postoji vrlo, vrlo malo rezerviranih brojeva portova (Poglavlje 1, odjeljak “Brojevi portova”), sa maksimalno 1023 po hostu. Ako NFS server zahteva da njegovi klijenti imaju rezervisane portove (što obično rade), a NFS klijent koji koristi TCP montira N fajl sistema na N različitih servera, da li klijent treba da ima različite rezervisane brojeve portova za svaku vezu?

NFS, ili Mrežni sistem datoteka, je popularan protokol mrežnog sistema datoteka koji omogućava korisnicima da montiraju udaljene mrežne direktorije na svoje računalo i prenose datoteke između servera. Možete koristiti prostor na disku na drugom stroju za svoje datoteke i raditi s datotekama koje se nalaze na drugim serverima. U suštini, ovo je alternativa Windows dijeljenju za Linux, za razliku od Sambe, implementirano je na nivou kernela i radi stabilnije.

Ovaj članak će pokriti instalaciju nfs-a na Ubuntu 16.04. Pogledat ćemo instalaciju svih potrebnih komponenti, postavljanje dijeljene mape i povezivanje mrežnih mapa.

Kao što je već pomenuto, NFS je mrežni sistem datoteka. Da biste radili, potreban vam je server koji će ugostiti dijeljeni folder i klijente koji mogu montirati mrežni folder kao običan disk u sistemu. Za razliku od drugih protokola, NFS omogućava transparentan pristup udaljenim datotekama. Programi će vidjeti datoteke kao u običnom sistemu datoteka i raditi s njima kao sa lokalnim datotekama, nfs vraća samo traženi dio datoteke, umjesto cijele datoteke, tako da će ovaj sistem datoteka savršeno raditi na sistemima sa brzim internetom ili na lokalna mreža.

Instaliranje NFS komponenti

Pre nego što budemo mogli da radimo sa NFS-om, moraćemo da instaliramo nekoliko programa. Na mašini koja će biti server, potrebno je da instalirate nfs-kernel-server paket, koji će se koristiti za otvaranje nfs deljenja u ubuntu 16.04. Da biste to učinili, pokrenite:

sudo apt install nfs-kernel-server

Sada provjerimo da li je server ispravno instaliran. NFS servis osluškuje veze za TCP i UDP na portu 2049. Možete vidjeti da li su ovi portovi zaista u upotrebi pomoću naredbe:

rpcinfo -p | grep nfs

Također je važno provjeriti da li je NFS podržan na nivou kernela:

cat /proc/filesystems | grep nfs

Vidimo da radi, ali ako ne, morate ručno učitati nfs kernel modul:

Dodajmo i nfs startupu:

sudo systemctl omogući nfs

Morate da instalirate nfs-common paket na klijentskom računaru da biste mogli da radite sa ovim sistemom datoteka. Ne morate instalirati serverske komponente, dovoljan je samo ovaj paket:

sudo apt install nfs-common

Postavljanje NFS servera na Ubuntu

Možemo otvoriti NFS pristup bilo kojem folderu, ali napravimo novi za tu svrhu:

klijent folder_address (opcije)

Adresa fascikle je fascikla kojoj treba omogućiti pristup preko mreže. Klijent - IP adresa ili mrežna adresa sa koje se može pristupiti ovoj fascikli. Ali s opcijama je malo složenije. Pogledajmo neke od njih:

rw- dozvoli čitanje i pisanje u ovoj fascikli
ro- dozvoli samo čitanje
sync- odgovorite na sljedeće zahtjeve samo kada su podaci spremljeni na disk (podrazumevano)
async- nemojte blokirati veze dok se podaci upisuju na disk
siguran- koristite samo portove ispod 1024 za povezivanje
nesiguran- koristite bilo koje portove
nohide- ne sakrivajte poddirektorije kada otvarate pristup nekoliko direktorija
root_squash- zamijenite zahtjeve iz root-a anonimnim
all_squash- pretvoriti sve zahtjeve u anonimnost
anonuid I anongid- specificira uid i gid za anonimnog korisnika.

Na primjer, za naš folder ovaj red može izgledati ovako:

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

Nakon što je sve bilo konfigurirano, ostalo je samo ažurirati NFS izvoznu tablicu:

sudo exportfs -a

To je sve, otvaranje nfs dionica u ubuntu 16.04 je završeno. Pokušajmo sada konfigurirati klijenta i pokušati ga montirati.

NFS veza

U današnjem članku nećemo se detaljnije zadržavati na ovom pitanju. Ovo je prilično velika tema koja zaslužuje svoj članak. Ali ipak ću reći nekoliko riječi.

Da biste montirali mrežnu mapu, nije vam potreban nikakav Ubuntu nfs klijent, samo koristite naredbu mount:

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

Sada možete pokušati kreirati datoteku u povezanom direktoriju:

Takođe ćemo pogledati montirane sisteme datoteka koristeći df:

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

Da biste onemogućili ovaj sistem datoteka, samo koristite standardni umount:

sudo umount /mnt/

zaključci

U ovom članku se govorilo o postavljanju nfs ubuntu 16.04, kao što vidite, sve se radi vrlo jednostavno i transparentno. Povezivanje NFS deljenja se vrši u nekoliko klikova pomoću standardnih komandi, a otvaranje nfs deljenja u ubuntu 16.04 nije mnogo komplikovanije od povezivanja. Ako imate pitanja, pišite u komentarima!

Povezani postovi:

Mrežni server datoteka (NFS) protokol je otvoreni standard za pružanje udaljenog korisničkog pristupa sistemima datoteka. Centralizirani sistemi datoteka izgrađeni na njemu olakšavaju svakodnevne zadatke kao što su sigurnosne kopije ili skeniranje virusa, a konsolidirane particije diska se lakše održavaju od mnogih manjih, distribuiranih.

Osim što obezbjeđuje centraliziranu pohranu, NFS se pokazao vrlo korisnim za druge aplikacije, uključujući klijente bez diska i tanke klijente, mrežno klasterisanje i međuversku saradnju.

Bolje razumijevanje samog protokola i detalja njegove implementacije će olakšati suočavanje s praktičnim problemima. Ovaj članak je posvećen NFS-u i sastoji se iz dva logična dela: prvo opisuje sam protokol i ciljeve postavljene tokom njegovog razvoja, a zatim i implementaciju NFS-a u Solarisu i UNIX-u.

GDJE SVE POČE...

NFS protokol je razvio Sun Microsystems i pojavio se na Internetu 1989. godine kao RFC 1094 pod sljedećim naslovom: Specifikacija protokola mrežnog sistema datoteka (NFS). Zanimljivo je napomenuti da je strategija Novell-a u to vrijeme bila usmjerena na dalje poboljšanje servisa datoteka. Sve do nedavno, prije nego što je pokret otvorenog koda uzeo maha, Sun nije bio voljan dijeliti tajne svojih mrežnih rješenja, ali je čak i tada kompanija shvatila važnost interoperabilnosti sa drugim sistemima.

RFC 1094 je sadržavao dvije originalne specifikacije. U vrijeme objavljivanja, Sun je već razvijao sljedeću, treću verziju specifikacije, koja je navedena u RFC 1813 “NFS Version 3 Protocol Specification”. Verzija 4 ovog protokola definisana je u RFC 3010, NFS Verzija 4 protokola.

NFS se široko koristi na svim tipovima UNIX hostova, na Microsoft i Novell mrežama i na IBM rješenjima kao što su AS400 i OS/390. Iako nepoznat izvan kraljevstva mreže, NFS je možda najrasprostranjeniji sistem mrežnih datoteka nezavisan od platforme.

UNIX JE BIO POSTANAK

Iako je NFS sistem nezavisan od platforme, njegov predak je UNIX. Drugim riječima, hijerarhijska arhitektura arhitekture i metode pristupa datotekama, uključujući strukturu sistema datoteka, načine identifikacije korisnika i grupa, i tehnike rukovanja datotekama, vrlo su slični UNIX sistemu datoteka. Na primjer, NFS sistem datoteka, koji je strukturno identičan UNIX sistemu datoteka, montira se direktno na njega. Kada radite sa NFS-om na drugim operativnim sistemima, parametri identifikacije korisnika i prava pristupa datotekama podliježu mapiranju.

NFS

NFS je dizajniran za upotrebu u klijent-server arhitekturi. Klijent pristupa sistemu datoteka koji izvozi NFS server preko tačke montiranja na klijentu. Ovaj pristup je obično transparentan za klijentsku aplikaciju.

Za razliku od mnogih klijent-server sistema, NFS koristi Remote Procedure Calls (RPC) za razmenu informacija. Obično klijent uspostavlja vezu sa prethodno poznatim portom, a zatim, u skladu sa protokolom, šalje zahtev za izvođenje određene radnje. U slučaju udaljenih poziva procedura, klijent kreira poziv procedure i zatim ga šalje serveru na izvršenje. Detaljan opis NFS će biti predstavljen u nastavku.

Kao primjer, pretpostavimo da je klijent montirao usr2 direktorij na lokalni korijenski sistem datoteka:

/root/usr2/ -> daljinski:/root/usr/

Ako su klijentskoj aplikaciji potrebni resursi iz ovog direktorija, ona jednostavno šalje zahtjev operativnom sistemu za nju i ime datoteke, koji odobrava pristup preko NFS klijenta. Kao primjer, razmotrite jednostavnu UNIX cd naredbu, koja "ne zna ništa" o mrežnim protokolima. Tim

CD /root/usr2/

će radni direktorij postaviti na udaljeni sistem datoteka, "a da čak i ne shvati" (korisnik također nema potrebe za tim) da je sistem datoteka udaljen.

Po prijemu zahteva, NFS server će proveriti da li korisnik ima pravo da izvrši traženu radnju i, ako je odgovor pozitivan, izvršiće je.

UPOZNAJMO SE BOLJE

Sa stanovišta klijenta, proces lokalnog montiranja udaljenog sistema datoteka pomoću NFS-a sastoji se od nekoliko koraka. Kao što je spomenuto, NFS klijent će izdati poziv udaljene procedure za izvršenje na serveru. Imajte na umu da je u UNIX-u klijent jedan program (komanda mount), dok je server zapravo implementiran kao nekoliko programa sa sljedećim minimalnim skupom: usluga mapiranja porta, demon za montiranje i NFS server. .

Komanda za montiranje klijenta prvo komunicira sa serverskom uslugom prevođenja porta, koja osluškuje zahteve na portu 111. Većina implementacija naredbe za montiranje klijenta podržava više verzija NFS-a, što povećava verovatnoću pronalaženja zajedničke verzije protokola za klijenta i servera. Pretraga se vrši počevši od najviše verzije, tako da kada se pronađe zajednička, ona će automatski postati najnovija verzija koju podržavaju klijent i server.

(Predstavljeni materijal je fokusiran na treću verziju NFS-a, budući da je trenutno najraširenija. Četvrta verzija još nije podržana u većini implementacija.)

Usluga prevođenja portova servera odgovara na zahtjeve na osnovu podržanog protokola i porta na kojem je pokrenut demon za montiranje. Program klijenta za montiranje prvo uspostavlja vezu sa demonom za montiranje servera, a zatim mu izdaje naredbu za montiranje preko RPC-a. Ako je ova procedura uspješna, tada se klijentska aplikacija povezuje na NFS server (port 2049) i, koristeći jednu od 20 udaljenih procedura koje su definirane u RFC 1813 i navedene u Tabeli 1, dobija pristup udaljenom sistemu datoteka.

Značenje većine naredbi je intuitivno i ne izaziva nikakve poteškoće sistemskim administratorima. Sljedeći popis, dobiven korištenjem tcdump, ilustruje naredbu za čitanje koju generiše UNIX cat naredba za čitanje datoteke pod nazivom test-file:

10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 traženje fh 32.0/ 224145 "test-file" 10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 traženje fh 32.0/ 224145 "test-file" 10:30:16.012729 eth0 192.168.1.254.791 fh 32.0/ 224145 "test-file" 10:30:16.012729 eth0 192.168.1.254.791 fh 32.0/224145 22 4307 (DF) 10:30: 16.012729 eth0 192.168.1.254.3476097947: odgovor ok 128 traži fh 32.0/224307 (DF) 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 čitanje fh 32.0/ 224307 4096 bajtova @ 0 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 čitanje fh 32.0/ 224307 4096 bajtova @ 0 10:30:16.013650 eth0 192.168.1.252.2049: čitanje fh 32.0/ 224307 4096 bajtova @ 0 10:30:16.013650 eth0 192.168.1.2580 reply. : 30:16.013650 eth0 192.168.1.254.3492875163 : odgovori ok 108 pročitaj (DF)

NFS se tradicionalno implementira preko UDP-a. Međutim, neke verzije NFS-a podržavaju TCP (TCP podrška je definirana u specifikaciji protokola). Glavna prednost TCP-a je efikasniji mehanizam retransmisije u nepouzdanim mrežama. (Kod UDP-a, ako dođe do greške, kompletna RPC poruka koja se sastoji od nekoliko UDP paketa se ponovo šalje. Sa TCP-om se ponovo šalje samo razbijeni fragment.)

NFS ACCESS

NFS implementacije obično podržavaju četiri načina za dodjelu prava pristupa: putem atributa korisnika/datoteke, na nivou zajedničkog resursa, na nivou glavnog čvora i kao kombinacija drugih metoda pristupa.

Prvi metod je zasnovan na UNIX-ovom ugrađenom sistemu dozvola za fajlove za pojedinačnog korisnika ili grupu. Da bi se pojednostavilo održavanje, identifikacija korisnika i grupe treba da bude konzistentna na svim NFS klijentima i serverima. Sigurnost se mora pažljivo razmotriti: NFS može nenamjerno omogućiti pristup datotekama koje nisu bile predviđene kada su kreirane.

Pristup na nivou dijeljenja vam omogućava da ograničite prava da dozvolite samo određene radnje, bez obzira na vlasništvo nad fajlom ili UNIX privilegije. Na primjer, rad sa NFS sistemom datoteka može biti ograničen na samo čitanje. Većina NFS implementacija vam omogućava da dodatno ograničite pristup na nivou zajedničkih resursa na određene korisnike i/ili grupe. Na primjer, grupi ljudskih resursa je dozvoljeno da vidi informacije i ništa više.

Pristup na nivou glavnog čvora omogućava vam da montirate sistem datoteka samo na određene čvorove, što je generalno dobra ideja jer se sistem datoteka lako može kreirati na bilo kojem NFS-omogućenom čvoru.

Kombinovani pristup jednostavno kombinuje gore navedene tipove (na primer, zajednički pristup sa pristupom dodeljenim određenom korisniku) ili omogućava korisnicima da pristupe NFS-u samo sa određenog čvora.

NFS U PINGVINSKOM STILU

Materijal vezan za Linux baziran je na Red Hatu 6.2 sa verzijom kernela 2.4.9, koji se isporučuje sa nfs-utils verzijom 0.1.6. Postoje i novije verzije: u vrijeme pisanja, najnovije ažuriranje paketa nfs-utils je 0.3.1. Može se preuzeti sa: .

Paket nfs-utils sadrži sljedeće izvršne datoteke: exportfs, lockd, mountd, nfsd, nfsstat, nhfsstone, rquotad, showmount i statd.

Nažalost, podrška za NFS ponekad predstavlja izvor zabune za Linux administratore jer dostupnost određene funkcije direktno zavisi od brojeva verzija i kernela i nfs-utils paketa. Srećom, stvari se poboljšavaju u ovoj oblasti, s najnovijim distribucijama uključujući najnovije verzije oba. Za prethodna izdanja, Odjeljak 2.4 NFS-HOWTO-a pruža potpunu listu sistemskih funkcionalnosti dostupnih za svaku kombinaciju paketa kernela i nfs-utils. Programeri održavaju kompatibilnost paketa sa prethodnim verzijama, poklanjajući veliku pažnju osiguranju sigurnosti i eliminaciji softverskih grešaka.

NFS podršku treba pokrenuti tokom kompilacije kernela. Ako je potrebno, kernelu treba dodati mogućnost rada sa NFS verzijom 3.

Za distribucije koje podržavaju linuxconf, lako je konfigurirati NFS usluge i za klijente i za servere. Međutim, brz način instaliranja NFS-a pomoću linuxconf-a ne pruža informacije o tome koje datoteke su kreirane ili uređene, što je veoma važno da administrator zna situaciju u slučaju kvara sistema. NFS arhitektura na Linuxu je slabo povezana sa BSD verzijom, tako da je potrebno lako pronaći potrebne datoteke podrške i programe za administratore koji koriste BSD, Sun OS 2.5 ili starije verzije NFS-a.

Datoteka /etc/exports, kao iu ranijim verzijama BSD-a, definira sisteme datoteka kojima je NFS klijentima dozvoljen pristup. Osim toga, sadrži niz dodatnih funkcija koje se odnose na pitanja upravljanja i sigurnosti, pružajući administratoru sredstva za fino podešavanje. Ovo je tekstualna datoteka koja se sastoji od unosa, praznih ili komentiranih redova (komentari počinju simbolom #).

Recimo da želimo klijentima dati pristup samo za čitanje /home direktoriju na Lefty čvoru. Ovo bi odgovaralo sljedećem unosu u /etc/exports:

/home (ro)

Ovdje moramo reći sistemu koje direktorije ćemo učiniti dostupnim pomoću demona za montiranje rpc.mountd:

# exportfs -r exportfs: Nema navedenog imena hosta u /home (ro), unesite *(ro) da biste izbjegli upozorenje #

Kada se pokrene, naredba exportfs izdaje upozorenje da /etc/exports ne ograničava pristup određenom čvoru i kreira odgovarajući unos u /var/lib/nfs/etab iz /etc/exports koji govori koji se resursi mogu vidjeti pomoću 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)

Ostale opcije navedene u etab uključuju zadane vrijednosti koje koristi NFS. Detalji će biti opisani u nastavku. Da biste omogućili pristup /home direktorijumu, morate pokrenuti odgovarajuće NFS usluge:

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

U bilo kom trenutku nakon pokretanja demona za montiranje (rpc.mountd), možete pogledati pojedinačne datoteke dostupne za izlaz gledanjem sadržaja datoteke /proc/fs/nfs/exports:

# cat /proc/fs/nfs/exports # Verzija 1.0 # Putanja Klijent (Zastavice) # IP-ovi /home 192.168.1.252(ro,root_squash,async, wdelay) # 192.168.1.252 #

Isto se može pogledati pomoću naredbe showmount s parametrom -e:

# showmount -e Izvezi listu za ljevaka: /home (svi) #

Napred, naredba showmount se također može koristiti za određivanje svih montiranih sistema datoteka, ili drugim riječima, da se otkrije koji su čvorovi NFS klijenti za sistem koji pokreće naredbu showmount. Naredba showmount -a će ispisati sve klijentske tačke montiranja:

# showmount -a Sve tačke montiranja na lijevoj strani: 192.168.1.252:/home #

Kao što je gore navedeno, većina NFS implementacija podržava različite verzije ovog protokola. Linux implementacija vam omogućava da ograničite listu verzija NFS-a koje se mogu pokrenuti specificiranjem -N prekidača za demona mount. Na primjer, da pokrenete NFS verziju 3, i to samo verziju 3, unesite sljedeću naredbu:

# rpc.mountd -N 1 -N 2

Česti korisnici mogu smatrati da je nezgodno što Linuxov NFS demon (rpc.nfsd) čeka pakete verzije 1 i verzije 2, iako to ima željeni efekat da ne podržava odgovarajući protokol. Nadajmo se da će programeri budućih verzija izvršiti potrebne korekcije i da će moći postići veću konzistentnost između komponenti paketa u odnosu na različite verzije protokola.

"PLIVANJE SA PINGVINIMA"

Pristup gore konfigurisanom Leftyju, NFS baziranom na Linux sistemu datoteka, zavisi od operativnog sistema klijenta. Stil instalacije za većinu operativnih sistema UNIX porodice je isti kao i kod originalnih Sun OS i BSD sistema ili novijeg Solarisa. Pošto se ovaj članak bavi i Linuxom i Solarisom, pogledajmo konfiguraciju klijenta Solaris 2.6 sa stanovišta uspostavljanja veze sa Linux verzijom NFS-a koju smo opisali gore.

Zahvaljujući karakteristikama naslijeđenim od Solarisa 2.6, može se lako konfigurirati da djeluje kao NFS klijent. Ovo zahtijeva samo jednu naredbu:

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

Pod pretpostavkom da je prethodna naredba mount bila uspješna, tada će naredba mount bez parametara dati sljedeće:

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

Hajde da analiziramo tcpdump izlaz primljen na Lefty čvoru nakon što je korisnik izdao naredbu ls /tmp/tmp2 na Sunny čvoru:

# tcpdump host lefty i host sunny -s512 06:07:43.490583 sunny.2191983953 > lefty.mcwrite.n.nfs: 128 getattr fh Unknown/1 (DF) 06:07:43.490678 sunny.nfcw > lefty.nfs 2191983953: odgovor ok 112 getattr DIR 40755 id 0/0 sz 0x000001000 (DF) 06:07:43.491397 sunny.2191983954 > lefty.mcwrite.n.nfs: Unknown :43.491463 ljevak. mcwrite.n.nfs > sunny.2191983954: odgovor u redu 120 pristup c0001 (DF) 06:07:43.492296 sunny.2191983955 > lefty.mcwrite.n.nfs: 152 readdirplus1/186 od 152 0 000000 (DF) 06 :07:43.492417 lefty.mcwrite.n.nfs > sunny.2191983955: odgovor ok 1000 readdirplus (DF)

Vidimo da čvor Sunny traži rukohvat datoteke (fh) za ls, na koji čvor Lefty odgovara sa OK i vraća strukturu direktorija. Sunny tada provjerava dozvolu za pristup sadržaju direktorija (132 pristup fh) i prima odgovor na dozvolu od Leftyja. Sunny čvor zatim čita cijeli sadržaj direktorija koristeći readdirplus rutinu. Pozivi udaljenih procedura opisani su u RFC 1813 i navedeni su na početku ovog članka.

Iako je redoslijed naredbi za pristup udaljenim sistemima datoteka vrlo jednostavan, brojne okolnosti mogu dovesti do toga da sistem ne bude pravilno montiran. Prije montiranja direktorija, tačka montiranja već mora postojati, inače se mora kreirati pomoću naredbe mkdir. Obično je jedini uzrok grešaka na strani klijenta nedostatak lokalnog direktorija za montiranje. Većina problema povezanih sa NFS-om nastaje zbog neusklađenosti između klijenta i servera ili neispravne konfiguracije servera.

Najlakši način za rješavanje problema na serveru je iz čvora na kojem server radi. Međutim, kada neko drugi administrira server umjesto vas, to nije uvijek moguće. Brz način da osigurate da su odgovarajuće serverske usluge ispravno konfigurisane je da koristite naredbu rpcinfo sa opcijom -p. Sa Solaris Sunny hosta možete odrediti koji su RPC procesi registrirani na Linux hostu:

# 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 status 100024 p1 0 0 0 udp 4 mountd /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 #

Imajte na umu da su informacije o verziji takođe navedene ovdje, što je prilično korisno kada sustav zahtijeva podršku za različite NFS protokole. Ako bilo koja usluga ne radi na serveru, onda se ova situacija mora ispraviti. Ako montiranje ne uspije, sljedeća naredba rpcinfo -p će vam pomoći da utvrdite da mountd servis na serveru nije pokrenut:

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

Komanda rpcinfo je vrlo korisna za otkrivanje da li je određeni udaljeni proces aktivan. Parametar -p je najvažniji od prekidača. Da vidite sve karakteristike rpcinfo, pogledajte stranicu sa uputstvom.

Još jedan koristan alat je naredba nfsstat. Uz njegovu pomoć možete saznati da li klijenti zaista pristupaju izvezenom sistemu datoteka, kao i prikazati statističke podatke u skladu s verzijom protokola.

Konačno, još jedan prilično koristan alat za određivanje uzroka grešaka sistema je tcpdump:

# tcpdump host lefty i host sunny -s512 tcpdump: slušanje na eth0 06:29:51.773646 sunny.2191984020 > lefty.mcwrite.n.nfs: 140 pretraga fh Unknown/1"test.c":179:59 lefty.mcwrite.n.nfs > sunny.2191984020: odgovor ok 116 traži GREŠKA: Nema takve datoteke ili direktorija (DF) 06:29:51.774593 sunny.2191984021 > lefty.mcwrite.n.nfs: 12 Nepoznato (fh8) DF) 06:29:51.774670 lefty.mcwrite.n.nfs > sunny.2191984021: odgovori ok 112 getattr DIR 40755 id 0/0 sz 0x000001000 (DF) 06:29.0001000 (DF) 06:29.1984021 sunny. mcwrite.n.nfs : 140 lookup fh Unknown/1"test.c" (DF) 06:29:51.775357 lefty.mcwrite.n.nfs > sunny.2191984022: odgovor ok 116 traži GREŠKA: Nema takve datoteke ili direktorija (DF) 06:29: 51.776029 sunny.2191984023 > lefty.mcwrite.n.nfs: 184 kreiraj fh Unknown/1 "test.c" (DF) 06:29:51.776169 lefty.mcwrite.n.nfs > sunny.2291984 kreiraj ERROR: 229198 Dozvola odbijena (DF)

Gornji listing, proizveden izvršavanjem naredbe touch test.c, pokazuje sljedeći slijed radnji: prvo touch komanda pokušava pristupiti datoteci pod nazivom test.c, zatim traži direktorij s istim imenom, a nakon neuspješnih pokušaja pokušava da kreira datoteku test.c, što takođe ne dovodi do uspeha.

Ako je sistem datoteka montiran, najčešće greške se odnose na normalne UNIX dozvole. Korišćenje uid-a ili NIS+ na Sun-u pomaže da se izbegne globalno postavljanje dozvola na svim sistemima datoteka. Neki administratori praktikuju "otvorene" direktorije, gdje se pristup za čitanje daje "cijelom svijetu". Međutim, ovo treba izbjegavati iz sigurnosnih razloga. Bezbjednosne brige na stranu, ovaj pristup je još uvijek loša praksa, budući da korisnici rijetko kreiraju podatke s namjerom da ih učine čitljivim svima.

Pristup privilegovanog korisnika (root) montiranim NFS sistemima datoteka tretira se drugačije. Kako bi se izbjeglo davanje privilegovanog korisnika neograničenog pristupa, zahtjevi privilegovanog korisnika se tretiraju kao da dolaze od korisnika niko. Ovaj moćni mehanizam ograničava pristup privilegovanih korisnika globalno čitljivim i pisanim datotekama.

NFS SERVER SOLARIS VERZIJA

Konfigurisanje Solarisa da radi kao NFS server je lako kao i sa Linuxom. Međutim, naredbe i lokacije datoteka se malo razlikuju. Kada se Solaris pokrene, nakon dostizanja nivoa pokretanja 3, NFS usluge se automatski pokreću i svi sistemi datoteka se izvoze. Za ručno pokretanje ovih procesa unesite naredbu:

#/usr/lib/nfs/mountd

Da pokrenete demona za montiranje i NFS server, unesite:

#/usr/lib/nfs/nfsd

Počevši od verzije 2.6, Solaris više ne koristi datoteku za izvoz da odredi koje sisteme datoteka treba izvesti. Fajlovi se sada izvoze pomoću naredbe share. Recimo da želimo dozvoliti udaljenim hostovima da montiraju /export/home. Da biste to učinili, unesite sljedeću naredbu:

Dijeli -F nfs /export/home

Sigurnosne mjere

SIGURNOST U LINUX-u

Neke NFS sistemske usluge zasnovane na Linuxu imaju dodatni mehanizam ograničenja pristupa putem kontrolnih lista ili tabela. Na internom nivou, ovaj mehanizam se implementira pomoću biblioteke tcp_wrapper, koja koristi dva fajla za generisanje lista kontrole pristupa: /etc/hosts.allow i /etc/hosts/deny. Iscrpni pregled pravila za rad sa tcp_wrapper je izvan okvira ovog članka, ali osnovni princip je sljedeći: poređenje se prvo vrši sa etc/hosts.allow, a zatim sa /etc/hosts. poricati. Ako pravilo nije pronađeno, tražena sistemska usluga se ne prikazuje. Da biste zaobišli ovaj posljednji zahtjev i pružili vrlo visok nivo sigurnosti, možete dodati sljedeći unos na kraj /etc/hosts.deny:

SVI: Svi

Nakon toga, možete koristiti /etc/hosts.allow da postavite jedan ili drugi način rada. Na primjer, datoteka /etc/hosts. allow, koji sam koristio prilikom pisanja ovog članka, sadržavao je sljedeće redove:

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:191.255.255.0 rquotad:191.25.5. 92. 168.1.0/255.255.255.0

Ovo omogućava specifičan tip pristupa hostovima prije nego što se odobri pristup na razini aplikacije. Na Linuxu, pristup na razini aplikacije kontrolira /etc/exports fajl. Sastoji se od unosa u sljedećem formatu:

Izvoz direktorija (prostor) host|mreža(opcije)

"Izvozni direktorij" je direktorij za koji je nfsd demonu dozvoljeno da obrađuje zahtjeve. "Čvor|mreža" je čvor ili mreža koja ima pristup izvezenom sistemu datoteka, a "opcije" definiraju ograničenja koja nfsd demon nameće na korištenje ovog zajedničkog resursa - pristup samo za čitanje ili mapiranje korisničkog id-a. .

Sljedeći primjer daje cijeloj domeni mcwrite.net pristup samo za čitanje na /home/mcwrite.net:

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

Više primjera možete pronaći na stranici upravljanja izvozom.

NFS SIGURNOST U SOLARISU

U Solarisu, mogućnost pružanja pristupa NFS-u je slična Linuxu, ali u ovom slučaju ograničenja se postavljaju korištenjem određenih parametara u naredbi za dijeljenje s prekidačem -o. Sljedeći primjer pokazuje kako omogućiti montiranje /export/mcwrite.net samo za čitanje na bilo kojem hostu u domeni mcwrite.net:

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

Man stranica za detalje share_nfs koja odobravaju pristup korištenjem kontrolnih lista na Solarisu.

Internet resursi

NFS i RPC nisu bez rupa. Uopšteno govoreći, NFS ne bi trebalo koristiti kada surfujete internetom. Ne možete napraviti rupe u zaštitnim zidovima da biste dozvolili bilo kakav pristup putem NFS-a. Važno je pažljivo pratiti sve nove RPC i NFS zakrpe, a brojni izvori sigurnosnih informacija mogu pomoći. Dva najpopularnija izvora su Bugtraq i CERT:

Prvi se može redovno pregledavati u potrazi za potrebnim informacijama ili pretplatom na periodične biltene. Drugi pruža, možda, ne tako brze informacije u odnosu na druge, ali u prilično cjelovitom obimu i bez nijanse senzacionalizma karakteristične za neke stranice posvećene informacionoj sigurnosti.

NFS: Mrežni sistem datoteka. Postavljanje i montaža NFS-a

Kratka istorija NFS-a

NFS arhitektura

Slika 2. Implementacija klijent-server modela u NFS arhitekturi

NFS protokol

Inovacija u NFS-u

NFS Alternatives

Zaključak

Koja je razlika?

Instaliranje NFS pozadine

Postavke

Instalacija i konfiguracija NFS klijentskog dijela

Ubuntu

Windows

Instaliranje NFS komponenti

Postavljanje NFS servera na Ubuntu

NFS veza

zaključci

GDJE SVE POČE...

UNIX JE BIO POSTANAK

NFS

UPOZNAJMO SE BOLJE

NFS ACCESS

NFS U PINGVINSKOM STILU

"PLIVANJE SA PINGVINIMA"

NFS SERVER SOLARIS VERZIJA

Sigurnosne mjere

SIGURNOST U LINUX-u

SVI: Svi

NFS SIGURNOST U SOLARISU

Internet resursi

Najbolji članci na ovu temu