NFS vam omogućava da delite direktorijume na Unix mašini. Nesigurnost NFS-a, a posebno NIS-a, povezana je sa RPC-om – u smislu broja raznih eksploatacija, RPC je izgleda nezvanični lider (osim Sendmaila). Budući da su ovi protokoli namijenjeni internim mrežama, morat će biti zaštićeni od “njihovih” korisnika. Iako prije upotrebe morate odlučiti jesu li zaista potrebni.
Na kućnoj mreži mogu biti prilično korisni, ali na korporativnoj mreži, iz sigurnosnih razloga, bolje je pronaći sigurniju alternativu.
NFS sistem datoteka.
Mrežni sistem datoteka (NFS) je razvio Sun kao sredstvo za pristup datotekama koje se nalaze na drugim Unix mašinama unutar lokalne mreže. NFS uopšte nije dizajniran sa sigurnošću na umu, što je dovelo do mnogih ranjivosti tokom godina.
NFS može da radi preko TCP ili UDP-a i koristi RPC sistem, što znači da se moraju pokrenuti sledeće često ranjive aplikacije: portmapper, nfs, nlockmgr (lockd), rquotad, statd i mountd.
Nema potrebe za pokretanjem NFS-a - morate pronaći alternativno rješenje. Ako je NFS i dalje potreban, ovdje ćemo govoriti o tome kako smanjiti rizik od njegovog korištenja.
/etc/exports
Prvi korak je odabir mašina koje će izvesti svoje sisteme datoteka. Tada možete odrediti kojim mašinama je dozvoljeno da se povežu na NFS servere (ili server, ako postoji) na mreži. Nema potrebe da koristite NFS na mašinama direktno (direktno) povezanim na Internet. Nakon što su mašine izabrane, potrebno je da izaberete direktorijume na tim mašinama koji će biti izvezeni.
Direktoriji za izvoz definirani su u datoteci /etc/exports. Format svakog unosa je jednostavan: ime imenika, lista korisnika kojima je dozvoljen pristup i način pristupa. npr.:
Puni pristup (čitanje/pisanje) direktoriju /home/user je dozvoljen mašini sa IP adresom 10.0.0.6. Najbolje je ne dati puni pristup, već ga ograničiti na pristup samo za čitanje (ro). Pored ovoga, možete odrediti i sljedeće opcije:
- Sigurno- zahtjev za montiranje mora doći sa privilegovanog porta (broja do 1024). To znači da je naredbu mount unio korisnik s root privilegijama.
- Root_squash- zahtjev root korisnika će se smatrati zahtjevom anonimnog korisnika. To vam omogućava da nanesete najmanju štetu sistemu. Ova opcija mora biti omogućena.
- All_squash- svi zahtjevi (ne samo od root korisnika) će se smatrati da dolaze od anonimnog korisnika. Korisno za javno izvezene direktorije.
Ako kreker sa root pristupom dobije pristup mašini kojoj je dat rw pristup direktorijumu navedenom u /etc/exports, dobiće potpunu kontrolu nad datotečnim sistemom, tako da ne može izvesti korenski direktorijum (/) i sistem- važni direktoriji, na primjer /usr, /bin, /sbin, /lib, /opt i /etc. Početni direktoriji korisnika su dobri za izvoz.
Na strani klijenta, montiranje dijeljenog sistema datoteka mora se obaviti navođenjem opcije -o nosuid:
# mount -t nfs -o nosuid 10.0.0.3:/home/user/files /mnt/home/frank
Ovo će spriječiti kreker koji ima pristup NFS serveru da dobije root pristup klijentima.
Ograničenje pristupa.
Bez obzira na uslugu, IPTables se moraju koristiti za ograničavanje pristupa mašini. U slučaju NFS servera, ovo je posebno važno. Kada koristite IPTables, morate zapamtiti da NFS demon koristi port 2049/TCP/UDP.
Neke RPC usluge, kao što su portmapper i NFS, koriste trajne portove (113 i 2049/tcp/udp, respektivno), ali druge RPC usluge imaju portove koji nisu postojani, što otežava filtriranje paketa pomoću IPTables. Jedino što se zna je da RPC-ovi koriste portove u rasponu 32768-65535.
Ako koristite kernel 2.4.13 ili noviji, onda koristite opciju -p<порт>možete odrediti tačan port za svaku RPC uslugu.
Pogledajmo funkciju start() iz /etc/rc.d/init.d/nfslock, koja se koristi za pokretanje nsflock-a:
start()(
#. Pokreni demone.
ako [ "$USERLAND_LOCKD" ]; onda
echo -n $"Pokretanje NFS zaključavanja: "
daemon rpc.lockd
echo -n $"Pokretanje NFS statd: "
daemon rpc.statd
echo [ $RETVAL -eq 0 ] && dodirnite /var/touch/lock/subsys/nfslock
vrati $RETVAL)
Da biste prisilili statd demona da koristi određeni port, možete koristiti opciju -p, na primjer daemon rpc.statd -p 32800 (ili bilo koji drugi - kako vam se najviše sviđa). Na isti način morate postaviti port za mountd, nfsd, rquotad - svi se pokreću iz /etc/rc.d/init.d/nfs skripte:
start()(
#Pokreni demone.
akcija -n $"Pokretanje NFS usluga: " /usr/sbin/exportfs -r
if t _x /usr/sbin/rpc.quotad ] ; zatim echo -n $"Pokretanje NFS kvota: " daemon rpc.rquotad echo
fi echo -n $"Pokretanje NFS mountd-a: "
daemon rpc.mountd 3RPCMOUNTDOPTS
echo -n $"Pokretanje NFS demona: " daemon rpc.nfsd $RPCNFSDOPTS echo touch /var/lock/subsys/nfs
Tehnologija za promjenu porta za lockd (nlockmgr) se razlikuje od gore navedene (nema potrebe da pokušavate promijeniti datoteku /etc/rc.d/init.d/nfslock - ništa neće raditi).
Lockd se ili implementira kao modul kernela ili statički kompajliran u kernel. Da biste promijenili broj porta, morate otvoriti datoteku /etc/modules i pronaći opcije proslijeđene modulu:
opcije lockd nlm_udpport=33000 nlm_tcpport=33000
Sada kada RPC usluge koriste statičke portove koji su poznati, moraju se koristiti IPTables. Sljedeći skup pravila pretpostavlja da je NFS jedini server koji radi na mašini i da mu je dozvoljen pristup samo mašinama navedenim u datoteci /usr/local/etc/nfsexports.hosts:
IPX = "/usr/sbin/iptables"
# Obriši sve lance
$IPT --ispiranje
$IPT -t nat --ispiranje $IPT -t mangle --ispiranje $IPT -X
# Dozvoli povratni promet $IPT -A INPUT -i lo -j PRIHVATI $IPT -A OUTPUT -o lo -j PRIHVATI
# Podrazumevana pravila $IPT -P INPUT DROP $IPT -P OUTPUT DROP $IPT -P NAPRIJED DROP
$IPT -A ULAZ -m stanje -stanje UTVRĐENO, POVEZANO -j PRIHVATI $IPT -A IZLAZ -m stanje -stanje NOVO, UTVRĐENO, POVEZANO -j PRIHVATI
# Dozvolite pristup svakom računaru
# navedeno u /usr/local/etc/nfsexports.hosts
za host u "cat /usr/local/etc/nfsexports.hosts"; uradi $IPT -I INPUT -s $host -p tcp -dport 111 -j PRIHVATI
$IPT -I INPUT -s $host -p udp -dport 111 -j PRIHVATI
$IPT -I INPUT -s $host -p udp -dport 2049 -j PRIHVATI
$IPT -I INPUT -s $host -p tcp --dport 32800 -j PRIHVATI
$IPT -I INPUT -s $host -p tcp --dport 32900 -j PRIHVATI
$IPT -I INPUT -s $host -p tcp -dport 33000 -j PRIHVATI
$IPT -I INPUT -s $host -p tcp --dport 33100 -j PRIHVATI
Naravno, ovo je samo kostur; trebat će dodati još mnogo pravila: barem dozvolite SSH i postavite neke parametre kernela pomoću /proc.
Tuneliranje NFS-a preko SSH-a.
Skraćenica NFS ponekad znači “No File Security” – ove tri riječi govore same za sebe. Zbog toga je veoma važno zaštititi NFS saobraćaj. Ovo je lako uraditi koristeći ssh.
Prvi korak je da uredite datoteku /etc/exports na NFS serveru tako da se sistem datoteka izvozi na lokalni čvor:
Zatim morate koristiti SSH za prosljeđivanje NFS i mountd portova. NFS koristi port 2049/udp, a mountd, kao što je navedeno, koristi broj porta 33000:
# ssh [email protected]-L 200: localhost:2049 -f spavanje 120m
# ssh [email protected]-L 200: localhost:33000 -f spavanje 120m
Ove dvije naredbe pružaju korisniku interaktivnu ljusku, ali pošto ona nije potrebna, SSH izvršava naredbu sleep 120: vraćamo se nazad na komandnu liniju, ali prosljeđivanje porta će trajati još 2 sata.
Montiranje sistema datoteka sa strane klijenta izgleda veoma neobično:
mount -t nfs -o nosuid port=200 mountport=210 nfsserver.test.net:/home/user /mnt/another
Ako su trikovi ssh tuneliranja previše komplikovani, možete koristiti projekt SHFS (Shell Filesystem) ( http: //shfs.sourceforge.net/ ), što omogućava automatizaciju cijele ove procedure.
Nakon instalacije, morate pristupiti SHFS-u pomoću naredbe mount -t shfs ili nove naredbe shfsmount. Sintaksa ove naredbe je slična prethodnoj:
shfsmount [email protected]:/home/user/mnt/user
CFS i TCFS
Kriptografski sistem datoteka koristi transparentno šifrovanje i dešifrovanje NFS saobraćaja koristeći DES algoritam. Osim toga, podržava automatsko upravljanje ključevima, što proces čini što transparentnijim za korisnika.
Iako je CFS razvijen za SunOS i BSD, prilično je zanimljiv jer se čini da je to prvi pokušaj transparentnog kodiranja zajedničkih datoteka. Transparentni kriptografski sistem datoteka (TCFS) pruža još transparentniji način šifriranja NFS prometa.
Pored kodiranja podataka, ovaj sistem datoteka podržava provjeru integriteta podataka.
Za distribuciju datoteka unutar lokalne mreže, mogu se razlikovati sljedeće tehnologije (razmatraju se sistemi zasnovani na Linuxu):
- Mrežni sistem datoteka (NFS) - protokol za pristup mreži za sisteme datoteka;
- Datoteke koje se prenose preko Shell protokola (FISH) je mrežni protokol koji koristi ili RSH za prijenos datoteka između računala;
- Secure Shell FileSystem (SSHFS) - klijent sistema datoteka za montiranje disk uređaja na udaljenim sistemima, koji se koristi za interakciju sa udaljenim sistemom SFTP;
- Samba je softverski paket koji vam omogućava pristup mrežnim diskovima i štampačima na različitim operativnim sistemima putem SMB/CIFS protokola;
U ovoj napomeni ćemo govoriti o tome NFS.
NFS (mrežni sistem datoteka) korisno kada trebate distribuirati datoteke/direktorije svima na mreži. Transparentnost pristupa sa NFS omogućava klijentima da montiraju udaljeni sistem datoteka kao lokalni direktorij, a sistemi datoteka mogu biti različitih tipova. To znači da svaka klijentska aplikacija koja može raditi s lokalnom datotekom može jednako lako raditi s datotekom povezanom putem NFS, bez ikakvih modifikacija samog programa.
U korist NFS može se pripisati:
Trenutno dostupno NFS v4.1, koji je uveo novu funkciju pNFS omogućavajući vam da paralelizirate implementaciju dijeljenja datoteka. Postoji i ekstenzija za NFS 2 i 3 - WebNFS, koji omogućavaju lakšu integraciju u web pretraživače i mogućnost rada kroz zaštitni zid.
Šema rada NFS protokol.
Instalacija i konfiguracija NFS servera pod Linuxom
Hajde da proverimo da li sistem podržava NFS
Cat /proc/filesystems | grep nfs
Ispod Arch Linux server i klijent su u istom paketu
Yaourt -S nfs-utils
Da instalirate server ( nfs-kernel-server) i klijent ( nfs-common) ispod Ubuntu potrebni paketi
Sudo apt-get install nfs-kernel-server nfs-common portmap
Dalje u ovoj napomeni, IP će se koristiti za server 192.168.1.100 . Da bi isti IP uvijek bio dodijeljen serveru, potrebno je na DHCP serveru (obično ruteru) navesti distribuciju određene IP adrese na određenu MAC adresu. Ili podignite svoj lokalni DNS server. Na primjer ili.
MAC adresa se može pronaći pomoću ifconfig (polje eter V Arch Linux).
NFSv4 pretpostavlja da postoji korijenski direktorij, unutar kojeg se već nalaze datoteke za distribuciju. Na primjer, /srv/nfs- korijen, /srv/nfs/audio- imenik za distribuciju muzike. Ako ne slijedite ove nove upute u verziji 4 , tada možete dobiti grešku prilikom povezivanja od strane klijenta:
Mount.nfs: server odbija pristup dok montira 192.168.1.100:/home/proft/torrents
Ako i dalje želite koristiti pristup na serveru bez korijenskog direktorija za NFS, onda kada montirate od strane klijenta, morate eksplicitno navesti verziju 3
# za naredbu mount mount -o "vers=3" 192.168.1.100:/home/proft/torrents /home/proft/nfs/torrents # za fstab 192.168.1.100:/home/proft/torrents /home/proft/nfs / torrents nfs soft,nfsvers=3 0 0
Ja ću koristiti NFSv4 sa osnovnim direktorijumom /srv/nfs/ i montiranje poddirektorija pomoću mount --bind.
Pretpostavimo da želimo
- distribuirati direktorij ~/torrents With rw pristup za svima unutar lokalne mreže;
- distribuirati direktorij ~/fotografije With ro pristup za host sa IP-om 192.168.1.101 ;
Prvo, napravimo korijenski direktorij i potrebne poddirektorije.
Sudo mkdir -p /srv/nfs/(torrenti,fotografije)
Montirajte postojeće direktorije torenti, fotografije V /srv/nfs.
# sudo vim /etc/fstab /home/proft/torrents /srv/nfs/torrents none bind 0 0 /home/proft/photos /srv/nfs/photos none bind 0 0
Hajde da uredimo /etc/exports, koji opisuje sve dijeljene direktorije
# sudo vim /etc/exports # format datoteke: direktorij dozvoljeni-hostovi(opcije) /srv/nfs/torrents 192.168.1.1/24(rw,async) /srv/nfs/photos 192.168.1.101(ro,async)
Imajte na umu da između njih nema razmaka dozvoljeni domaćini I (opcije). Prisustvo razmaka uvodi drugačije tumačenje pravila.
Dostupne opcije:
- ro (rw) - dozvoli pristup samo za čitanje (čitanje/pisanje);
- subtree_check (no_subtree_check) - u nekim slučajevima je potrebno izvesti ne cijeli odjeljak, već samo dio. U ovom slučaju, server NFS moraju izvršiti dodatne provjere na zahtjevima klijenta kako bi osigurali da oni samo pokušavaju pristupiti datotekama koje se nalaze u odgovarajućim poddirektorijumima. Ova kontrola podstabla ( provjere podstabla) donekle usporava interakciju sa klijentima, ali ako to odbijete, može doći do problema sa sigurnošću sistema. Pomoću opcije možete otkazati kontrolu podstabla no_subtree_check. Opcija subtree_check, koji uključuje takvu kontrolu, pretpostavlja se po defaultu. Provjera podstabla se može izostaviti ako je izvezeni direktorij isti kao particija diska;
- sync (async) - specificira da server treba da odgovori na zahtjeve tek nakon što se promjene koje su ti zahtjevi upisali na disk. Opcija async govori serveru da ne čeka da se informacije zapišu na disk, što poboljšava performanse, ali smanjuje pouzdanost, jer u slučaju kvara veze ili kvara opreme može doći do gubitka podataka;
- noaccess - odbija pristup navedenom direktoriju. Može biti korisno ako ste prethodno postavili pristup za sve korisnike mreže određenom direktoriju, a sada želite ograničiti pristup poddirektorijumu samo na neke korisnike;
- no_root_squash – zadani korisnik root na klijentskoj mašini neće imati ista prava na direktorijum na serveru. Ova opcija uklanja ovo ograničenje;
- nohide- NFS ne prikazuje automatski nelokalne resurse (na primjer, montirane pomoću mount --bind), ova opcija omogućava prikaz takvih resursa;
- nesigurno - korištenje neprivilegiranih portova (> 1024);
Pokretanje NFS servera
# pod archlinux sudo systemctl start rpc-idmapd.service rpc-mountd.service # pod ubuntu sudo /etc/init.d/nfs-kernel-server start
U budućnosti, kada promijenite konfiguracijsku datoteku, samo je ponovo pročitajte naredbom:
Sudo exportfs -rav
Naredba rpcinfo -p | grep nfs vam omogućava da proverite da li je server uspešno pokrenut.
Linux klijent
Instalacija
# pod archlinux yaourt -S nfs-utils # pod ubuntu sudo apt-get install portmap nfs-common
Kreirajmo direktorije za montiranje mrežnih resursa torrents I fotografije
Mkdir -p ~/nfs/(torrenti,fotografije)
Za ručnu montažu ćemo uraditi
Sudo mount -t nfs -o rw,soft 192.168.1.100:/srv/nfs/torrents /home/proft/nfs/torrents sudo mount -t nfs -o rw,soft 192.168.1.100:/srv/nfshome/ /proft/nfs/photos
Opcija soft specificira tiho otkazivanje pokušaja povezivanja dijeljenja nakon određenog vremena (vrijeme je određeno opcijom retrans). Više detalja u man nfs.
Ova metoda nije baš zgodna, jer ćete svaki put nakon ponovnog pokretanja morati izvršiti ove naredbe. Učinimo instalaciju automatskom.
Za automatsko montiranje, uredite datoteku /etc/fstab
# sudo vim /etc/fstab 192.168.1.100:/srv/nfs/torrents /home/proft/net/torrents nfs rw,soft 0 0 192.168.1.100:/srv/nfs/photos /home/proft/nfs/ ro,soft 0 0
Ali ova metoda ima i svoje nedostatke, na primjer, ako server nije dostupan, učitavanje klijenta može se zamrznuti zbog pokušaja povezivanja na NFS server. Da biste to popravili, pogledajte u nastavku o AutoFS.
AutoFS - automatsko povezivanje mrežnih resursa
Moguće je montirati udaljeni resurs koristeći AutoFS pri prvom pristupu i automatski isključite kada nema aktivnosti.
AutoFS koristi šablone koji se nalaze u /etc/autofs. Glavni šablon se zove auto.master, može ukazivati na jedan ili više drugih obrazaca za određene tipove medija.
Instalacija
# pod archlinux yaourt -S autofs # pod ubuntu sudo apt-get install autofs
Postoji nekoliko načina za određivanje metoda automatskog montiranja. Ja koristim ovaj: in /home/proft/nfs Automatski se kreira direktorij s imenom NFS servera, u kojem se automatski kreiraju dostupni direktoriji na serveru.
# sudo vim /etc/autofs/auto.master /home/proft/nfs /etc/autofs/auto.nfs --timeout=60
Dodatni parametar vrijeme je isteklo postavlja broj sekundi nakon kojih će uređaj biti isključen. Parametar duh specificira da će konfigurirani resursi uvijek biti prikazani, a ne samo kada su dostupni (ova opcija je po defaultu omogućena u AutoFS 5)
Opisaćemo u /etc/autofs/auto.nfs NFS server i korijenski direktorij.
# sudo vim /etc/autofs/auto.nfs nfsserver 192.168.1.100:/srv/nfs
Sada na prvom pozivu /home/proft/nfs/torrents NFS resurs će se automatski montirati.
Ponovo pokrenimo autofs uslugu:
# pod archlinux sudo systemctl restart autofs # pod ubuntu sudo /etc/init.d/autofs restart
Također možete odrediti vrijeme čekanja da NFS resurs postane dostupan. Da biste to učinili, morate promijeniti vrijednosti MOUNT_WAIT.
# pod archlinuxom # sudo vim /etc/conf.d/autofs MOUNT_WAIT=5 # pod ubuntu sudo /etc/default/autofs MOUNT_WAIT=5
Prisilno korištenje NFS v3
U nekim slučajevima NFSv4 može raditi sporo. Da biste to popravili, možete ga natjerati da koristi treću verziju.
Svi znaju da je na UNIX sistemima sistem datoteka logički skup fizičkih sistema datoteka povezanih na jednu tačku. Jedna od glavnih prednosti takve organizacije, po mom mišljenju, je mogućnost dinamičke modifikacije strukture postojećeg sistema datoteka. Također, zahvaljujući naporima programera, danas imamo priliku da povežemo sistem datoteka gotovo bilo kojeg tipa i na bilo koji prikladan način. Pod „metodom“ prije svega želim da istaknem sposobnost jezgra OS-a da radi sa sistemima datoteka putem mrežnih veza.
Mnogi mrežni protokoli pružaju nam mogućnost rada sa udaljenim datotekama, bilo da se radi o FTP, SMB, Telnet ili SSH. Zahvaljujući sposobnosti kernela da na kraju ne zavisi od tipa sistema datoteka koji se povezuje, imamo mogućnost da povežemo bilo šta i kako god želimo koristeći program za montiranje.
Danas bih želeo da pričam o NFS - sistemu mrežnih datoteka. Ova tehnologija vam omogućava da povežete pojedinačne tačke sistema datoteka na udaljenom računaru sa sistemom datoteka lokalnog računara. Sam NFS protokol vam omogućava da obavljate operacije sa datotekama prilično brzo, sigurno i pouzdano. Šta nam još treba? :-)
Šta je potrebno da ovo funkcioniše
Kako se ne bismo dugo buncali na temu NFS verzija i njihove podrške u raznim kernelima, odmah ćemo pretpostaviti da vaša verzija kernela nije niža od 2.2.18. U službenoj dokumentaciji programeri obećavaju punu podršku za funkcionalnost NFS verzije 3 u ovom kernelu i novijim verzijama.
Instalacija
Da bih pokrenuo NFS server u mom Ubuntu 7.10 - Gutsy Gibbon, morao sam da instaliram pakete nfs-common i nfs-kernel-server. Ako vam je potreban samo NFS klijent, onda nfs-kernel-server ne mora biti instaliran.
Podešavanje servera
Nakon što su svi paketi uspješno instalirani, morate provjeriti da li je NFS demon pokrenut:
/etc/init.d/nfs-kernel-server status
Ako demon nije pokrenut, morate ga pokrenuti naredbom
/etc/init.d/nfs-kernel-server start
Nakon što je sve uspješno započelo, možete započeti izvoz sistema datoteka. Sam proces je vrlo jednostavan i oduzima minimalno vrijeme.
Glavna konfiguracijska datoteka NFS servera nalazi se u /etc/exports i ima sljedeći format:
Imenik mašina1(opcija11,opcija12) mašina2(opcija21,opcija22)
imenik— apsolutna putanja do direktorija FS servera kojem trebate dati pristup
machineX— DNS ime ili IP adresa klijentskog računara sa kojeg je pristup dozvoljen
opcijaXX— FS izvozni parametri, najčešće korišteni od njih:
- ro- pristup fajlu je samo za čitanje
- rw— pristup za čitanje/pisanje je odobren
- no_root_squash— podrazumevano, ako se povežete na NFS resurs kao root, server će, radi bezbednosti, sa svoje strane pristupiti datotekama kao niko korisnik. Međutim, ako omogućite ovu opciju, datotekama na strani servera će se pristupati kao root. Budite oprezni s ovom opcijom.
- no_subtree_check— podrazumevano, ako ne izvozite celu particiju na serveru, već samo deo sistema datoteka, demon će proveriti da li se tražena datoteka fizički nalazi na istoj particiji ili ne. Ako izvozite cijelu particiju ili tačka montiranja izvezenog sistema datoteka ne utiče na datoteke iz drugih fizičkih volumena, tada možete omogućiti ovu opciju. Ovo će vam dati povećanje brzine servera.
- sync— omogućite ovu opciju ako postoji mogućnost iznenadnog gubitka veze ili nestanka struje servera. Ako ova opcija nije omogućena, postoji veoma visok rizik od gubitka podataka ako se NFS server iznenada zaustavi.
Dakle, recimo da treba da omogućimo pristup ashep-desktop računaru u /var/backups direktorijumu ashep-laptop računara. Pristup direktoriju je potreban za kopiranje datoteka sigurnosne kopije sa ashep-desktop-a. Moj fajl je ispao ovako:
/var/backups ashep-desktop(rw,no_subtree_check,sync)
Nakon što dodate red u /etc/exports, morate ponovo pokrenuti NFS server da bi promjene stupile na snagu.
/etc/init.d/nfs-kernel-server restart
To je sve. Možete započeti povezivanje izvezenog FS-a na klijentskom računaru.
Podešavanje klijenta
Na strani klijenta, udaljeni sistem datoteka se montira na isti način kao i svi ostali - komandom mount. Takođe, niko vam ne zabranjuje da koristite /etc/fstab ako treba da povežete FS automatski kada se OS pokrene. Dakle, opcija montiranja će izgledati ovako:
Mount -t nfs ashep-laptop:/var/backups/ /mnt/ashep-laptop/backups/
Ako je sve prošlo dobro i morate se automatski povezati na udaljeni FS pri pokretanju, samo dodajte red u /etc/fstab:
Ashep-laptop:/var/backups /mnt/ashep-laptop/backups nfs auto 0 0
Šta još
Dakle, imamo praktičan, mali pregled mogućnosti NFS-a. Naravno, ovo je samo mali dio onoga što NFS može učiniti. Ovo je dovoljno za upotrebu kod kuće ili u maloj kancelariji. Ako vam ovo nije dovoljno, preporučujem da prvo pročitate
Dakle, šta je sljedeće? Kako gledati filmove i slušati muzičke fajlove koji su preuzeti? Da li ih je zaista potrebno narezati na diskove i tako ih prebaciti na kompjuter sa GUI? Ili ću morati da ih kopiram preko sporog SFTP-a? Ne! NFS dolazi u pomoć! Ne, ovo nije serija trkačkih igara, već mrežni sistem datoteka.
Mrežni sistem datoteka (NFS) je mrežni sistem datoteka koji korisnicima omogućava pristup datotekama i direktorijima koji se nalaze na udaljenim računarima kao da su te datoteke i direktoriji lokalni. Glavna prednost ovakvog sistema je u tome što pojedinačne radne stanice mogu koristiti manje vlastitog prostora na disku, budući da se zajednički podaci pohranjuju na posebnoj mašini i dostupni su drugim mašinama na mreži. NFS je klijent-server aplikacija. Odnosno, NFS klijent mora biti instaliran na korisnikovom sistemu, a NFS server mora biti instaliran na računarima koji obezbjeđuju njihov prostor na disku.
Instaliranje i konfigurisanje NFS servera (192.168.1.2)
1. Instalirajte. Nakon povezivanja putem SSH-a na serverski računar ili jednostavno u njegovu konzolu, unesite:
Sudo apt-get install nfs-kernel-server nfs-common portmap
Ovo će instalirati NFS server kao i potreban portmap paket.
2. Postavite. Da konfigurišemo listu direktorijuma koje želimo da otvorimo i listu kojima želimo da ih otvorimo, uredimo datoteku /etc/exports :
Sudo nano /etc/exports /data 192.168.1.1/24(rw,no_root_squash,async)
U gornjem primjeru otvorili smo direktorij na serveru /data i njegove poddirektorije za zajedničko korištenje od strane svih računara sa IP-om: 192.168.1.1 - 192.168.1.255 sa pravima čitanja i pisanja.
Drugi primjer:
/home/serg/ 192.168.1.34 (ro, async)
Ovaj primjer čini početni direktorij korisničkog serga dostupnim u načinu samo za čitanje na računaru sa IP 192.168.1.34. Svi ostali računari na mreži neće imati pristup ovom direktorijumu.
Dostupne opcije:
- ro - prava samo za čitanje. Ne morate ga specificirati, pošto je instaliran po defaultu;
- rw - daje klijentima dozvolu za pisanje;
- no_root_squash - po defaultu, root korisnik na klijentskoj mašini neće imati pristup otvorenim direktorijumima na serveru. Ovom opcijom uklanjamo ovo ograničenje. Iz sigurnosnih razloga, bolje je to ne raditi;
- noaccess - odbija pristup navedenom direktoriju. Može biti korisno ako ste prethodno postavili pristup za sve korisnike mreže određenom direktoriju, a sada želite ograničiti pristup poddirektorijumu samo na neke korisnike.
Sada morate ponovo pokrenuti nfs-kernel-server:
Sudo /etc/init.d/nfs-kernel-server restart
Ako nakon ovoga želite nešto promijeniti u datoteci /etc/exports , zatim da bi promjene stupile na snagu, samo pokrenite sljedeću naredbu:
Sudo exportfs -a
Sve. NFS server je instaliran i konfigurisan. Možete se prebaciti na NFS klijenta.
Instalacija i konfiguracija NFS klijenta
1. Instalacija. U računarskom terminalu, koji će se povezati, radimo sljedeće:
Sudo apt-get install portmap nfs-common
2. Podešavanje. Prvo, napravimo direktorij u koji će biti montiran udaljeni folder:
Cd ~ mkdir podaci
Možete montirati na dva načina - svaki put ručno ili pisanjem opcija montiranja u datoteku /etc/fstab.
Metoda 1: Ručna montaža
Napravite tekstualnu datoteku na radnoj površini ili u nekom drugom folderu:
Nano ~/Desktop/nfs-server-connect
U njemu pišemo:
#! /bin/bash sudo mount -t nfs -o ro,soft,intr 192.168.1.2:/data ~/data
Učinimo ga izvršnim:
Chmod +x ~/Desktop\nfs-server-connect
Sada, kada trebam da se povežem sa serverom, pokrećem ovu skriptu u terminalu kako bih mogao da unesem lozinku za sudo.
Metod 2: Dodajte u /etc/fstab
Otvorite /etc/fstab:
Sudo nano /etc/fstab
I dodajte red na kraj datoteke:
192.168.1.2:/data ~/data nfs rw,hard,intr 0 0
Pažnja! Umjesto 192.168.1.2:/data, unesite IP ili ime servera i putanju do dijeljenog direktorija. Opcije montiranja se mogu mijenjati.
Opcija teško on striktno veže direktorij na klijentu za server, a ako server padne, vaš računar se takođe može zamrznuti. Opcija soft, kao što mu naziv govori, nije tako kategoričan.
Nakon što sačuvate datoteku, možete montirati udaljeni folder.
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.
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/usrOva 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šestruka 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?
