Het Network File Server (NFS)-protocol is: open standaard om de gebruiker te voorzien toegang op afstand naar bestandssystemen. De gecentraliseerde bestandssystemen maken het gemakkelijker om dagelijkse taken uit te voeren, zoals back-ups of virusscans, en geconsolideerde schijfpartities zijn gemakkelijker te onderhouden dan veel kleine en gedistribueerde partities.
Naast het bieden van gecentraliseerde opslagmogelijkheden, is NFS ook zeer nuttig gebleken voor andere toepassingen, waaronder schijfloze en thin clients, netwerkclustering en samenwerkende middleware.
Een beter begrip van zowel het protocol zelf als de details van de implementatie ervan zal het gemakkelijker maken om praktische taken uit te voeren. Dit artikel richt zich op NFS en bestaat uit twee logische delen: eerst beschrijft het het protocol zelf en de doelen die tijdens de ontwikkeling zijn gesteld, en vervolgens de implementatie van NFS op Solaris en UNIX.
WAAR HET ALLEMAAL BEGON MET...
NFS is ontwikkeld door Sun Microsystems en verscheen in 1989 op internet als RFC 1094 onder de titel Network File System Protocol Specification (NFS). Het is interessant om op te merken dat de strategie van Novell destijds was om de bestandsservices verder te verbeteren. Tot voor kort, voordat de open source-beweging aan kracht won, stond Sun niet te popelen om de geheimen van zijn netwerkoplossingen te onthullen, maar zelfs toen begreep het bedrijf het belang van interoperabiliteit met andere systemen.
RFC 1094 bevatte twee originele specificaties. Op het moment van publicatie was Sun al bezig met de ontwikkeling van de volgende, derde versie van de specificatie, die is uiteengezet in RFC 1813 NFS Versie 3 Protocolspecificatie. Versie 4 van dit protocol gedefinieerd in RFC 3010 NFS versie 4-protocol.
NFS wordt veel gebruikt op alle typen UNIX-hosts, Microsoft- en Novell-netwerken en IBM-oplossingen zoals de AS400 en OS/390. Onbekend buiten het netwerkrijk, is NFS misschien wel het meest gebruikte platformonafhankelijke netwerkbestandssysteem.
DE PROFESSOR WAS UNIX
Hoewel NFS een platformonafhankelijk systeem is, is UNIX de voorloper ervan. Met andere woorden, de hiërarchie van de architectuur en de methoden voor toegang tot bestanden, inclusief de structuur van het bestandssysteem, hoe gebruikers en groepen te identificeren en hoe met bestanden te werken, lijken allemaal erg op het UNIX-bestandssysteem. Het NFS-bestandssysteem, dat qua structuur identiek is aan het UNIX-bestandssysteem, wordt er bijvoorbeeld direct op gemount. Bij het werken met NFS op anderen besturingssystemen ah parameters voor gebruikersidentificatie en toegangsrechten voor bestanden worden in kaart gebracht.
NFS
NFS is ontworpen voor gebruik in client-server architectuur... De client heeft toegang tot het bestandssysteem dat door de NFS-server is geëxporteerd via een koppelpunt op de client. Deze toegang is meestal transparant voor de clienttoepassing.
In tegenstelling tot veel client-/serversystemen gebruikt NFS Remote Procedure Calls (RPC's) om informatie uit te wisselen. Gewoonlijk brengt de client een verbinding tot stand met een vooraf bepaalde poort en verzendt vervolgens, in overeenstemming met de specifieke kenmerken van het protocol, een verzoek om een specifieke actie uit te voeren. In het geval van een procedureaanroep op afstand, creëert de client een procedureaanroep en stuurt deze vervolgens naar de server voor uitvoering. Hieronder wordt een gedetailleerde beschrijving van NFS gegeven.
Stel bijvoorbeeld dat een client de usr2-directory heeft aangekoppeld op het lokale rootbestandssysteem:
/ root / usr2 / -> afstandsbediening: / root / usr /
Als een clienttoepassing de bronnen van deze map nodig heeft, stuurt deze eenvoudig een verzoek naar het besturingssysteem ervoor en voor de bestandsnaam, en deze laatste verleent toegang via de NFS-client. Overweeg als voorbeeld een eenvoudige UNIX-commando-cd, die "niets weet" over netwerkprotocollen. Team
Cd / root / usr2 /
zal de werkdirectory op het externe bestandssysteem plaatsen, "zonder zelfs maar te weten" (de gebruiker heeft dit ook niet nodig) dat het bestandssysteem op afstand is.
Na ontvangst van het verzoek zal de NFS-server controleren of de gegeven gebruiker het recht heeft om de gevraagde actie uit te voeren en, als het antwoord positief is, deze uitvoeren.
LATEN WE DICHTER komen
Vanuit het perspectief van een klant omvat het proces van het lokaal mounten van een extern bestandssysteem met behulp van NFS verschillende stappen. Zoals vermeld, zal de NFS-client een externe procedure-aanroep doen om op de server uit te voeren. Merk op dat op UNIX de client een enkel programma is (commando mount), terwijl de server feitelijk is geïmplementeerd als verschillende programma's met de volgende minimale set: port mapper, mount daemon en NFS-server ...
In eerste instantie werkt het client-mount-commando samen met de port-vertaalservice van de server, die luistert naar verzoeken op poort 111. De meeste client-mount-implementaties ondersteunen meerdere versies van NFS, wat de kans vergroot dat een gemeenschappelijke protocolversie tussen de client en de server wordt gevonden. De zoekopdracht wordt uitgevoerd vanaf de oudste versie, dus wanneer een gedeelde versie wordt gevonden, wordt deze automatisch de nieuwste versie die wordt ondersteund door de client en de server.
(Het gepresenteerde materiaal is gericht op de derde versie van NFS, aangezien dit momenteel de meest voorkomende is. De vierde versie wordt nog niet door de meeste implementaties ondersteund.)
De poortvertaalservice van de server reageert op verzoeken op basis van het ondersteunde protocol en de poort waarop de mount-daemon draait. Het mount-clientprogramma maakt eerst verbinding met de server-mount-daemon en stuurt vervolgens het mount-commando ernaartoe. Als deze procedure succesvol is, maakt de clienttoepassing verbinding met de NFS-server (poort 2049) en krijgt, met behulp van een van de 20 externe procedures die zijn gedefinieerd in RFC 1813 en vermeld in Tabel 1, toegang tot het externe bestandssysteem.
De betekenis van de meeste commando's is intuïtief en veroorzaakt geen problemen voor systeembeheerders. De onderstaande tcdump-lijst illustreert de leesopdracht die is gegenereerd door de UNIX cat-opdracht om een bestand met de naam test-file te lezen:
10:30: 16.012010 eth0> 192.168.1.254. 3476097947> 192.168.1.252.2049: 144 lookup fh 32.0 / 224145 "testbestand" 10: 30: 16.012010 eth0> 192.168.1.254. 3476097947> 192.168.1.252.2049: 144 lookup fh 32.0 / 224145 "test-file" 10: 30: 16.012729 eth0 192.168.1.254.3476097947: antwoord ok 128 lookup fh 32.0 / 224307 (DF) 10:30: 16.012729 eth0 192.168. 1.254.3476097947: antwoord ok 128 lookup fh 32.0 / 224307 (DF) 10: 30: 16.013124 eth0> 192.168.1.254. 3492875163> 192.168.1.252.2049: 140 lezen fh 32.0 / 224307 4096 bytes @ 0 10: 30: 16.013124 eth0> 192.168.1.254. 3492875163> 192.168.1.252.2049: 140 lezen fh 32.0 / 224307 4096 bytes @ 0 10: 30: 16.013650 eth0 192.168.1.254.3492875163: antwoord ok 108 lezen (DF) 10: 30: 16.013650 eth0 192.168.1.254.3492875163: antwoord ok 108 lezen (DF)
NFS is traditioneel geïmplementeerd via UDP. Sommige versies van NFS ondersteunen echter TCP (TCP-ondersteuning is gedefinieerd in de protocolspecificatie). Het belangrijkste voordeel van TCP is een efficiënter hertransmissiemechanisme in onbetrouwbare netwerken. (In het geval van UDP, als er een fout optreedt, dan volledig bericht Een RPC die uit meerdere UDP-pakketten bestaat, wordt opnieuw doorgestuurd. Met TCP wordt alleen het slechte fragment opnieuw verzonden.)
TOEGANG IN NFS
NFS-implementaties ondersteunen over het algemeen vier manieren om toegangsrechten toe te kennen: via gebruikers-/bestandskenmerken, op het niveau van gedeelde bronnen, op het niveau van de hoofdknooppunten en een combinatie van andere toegangsmethoden.
De eerste methode is gebaseerd op het ingebouwde systeem voor bestandspermissies van UNIX voor: individuele gebruiker of groep. Om het onderhoud te vereenvoudigen, moeten gebruikers- en groepsidentiteiten consistent zijn voor alle NFS-clients en -servers. Beveiliging moet zorgvuldig worden overwogen: NFS kan onbedoeld toegang verlenen tot bestanden die niet bedoeld waren toen ze werden gemaakt.
Met gedeelde toegang kunt u de rechten beperken tot alleen bepaalde acties ongeacht bestandseigendom of UNIX-privileges. Het werken met het NFS-bestandssysteem kan bijvoorbeeld worden beperkt tot alleen lezen. Bij de meeste NFS-implementaties kunt u de toegang tot gedeelde bronnen verder beperken tot specifieke gebruikers en/of groepen. De groep "Human Resources" mag bijvoorbeeld informatie bekijken en niets meer.
Met toegang tot hoofdknooppunten kan het bestandssysteem alleen op specifieke knooppunten worden gemount, wat over het algemeen een goed idee is, aangezien bestandssystemen eenvoudig kunnen worden gemaakt op elk NFS-compatibel knooppunt.
Combo-toegang combineert eenvoudig de bovenstaande typen (bijvoorbeeld toegang op het niveau van gedeelde bronnen met toegang verleend aan een specifieke gebruiker) of stelt gebruikers in staat om alleen met NFS te werken vanaf een specifiek knooppunt.
NFS IN DE PINGUNSTIJL
Linux-gerelateerd materiaal is gebaseerd op het systeem rode Hoed 6.2 met kernelversie 2.4.9 die wordt geleverd met het nfs-utils-pakketversie 0.1.6. Er zijn nieuwere versies: op het moment van schrijven is de meest recente update van het nfs-utils-pakket 0.3.1. Het is te downloaden op:.
Het pakket nfs-utils bevat de volgende binaire bestanden: exportfs, lockd, mountd, nfsd, nfsstat, nhfsstone, rquotad, showmount en statd.
Helaas is NFS-ondersteuning soms verwarrend Linux-beheerders omdat de beschikbaarheid van deze of gene functionaliteit direct afhankelijk is van de versienummers van zowel de kernel als het nfs-utils pakket. Gelukkig is de situatie op dit gebied momenteel aan het verbeteren: de nieuwste distributiekits bevatten de nieuwste versies van beide. Voor eerdere releases biedt Paragraaf 2.4 van de NFS-HOWTO een volledige lijst van systeemfunctionaliteit die beschikbaar is voor elke combinatie van kernel en nfs-utils-pakket. De ontwikkelaars handhaven de achterwaartse compatibiliteit van het pakket met eerdere versies met een sterke focus op beveiliging en bugfixes.
NFS-ondersteuning moet worden gestart tijdens het compileren van de kernel. Indien nodig moet de NFS versie 3 mogelijkheid ook aan de kernel worden toegevoegd.
Voor distributies die linuxconf ondersteunen, is het eenvoudig om NFS-services voor zowel clients als servers te configureren. Maar de snelle manier is NFS-installaties het gebruik van linuxconf geeft geen informatie over welke bestanden zijn gemaakt of bewerkt, wat erg belangrijk is voor de beheerder om te weten om de situatie te begrijpen in het geval van een systeemstoring. De NFS-architectuur van Linux is losjes gerelateerd aan BSD, dus de benodigde bestanden en ondersteuningsprogramma's zijn gemakkelijk te vinden voor beheerders met BSD, Sun OS 2.5 of eerdere versies van NFS.
Het bestand / etc / exports definieert, net als in eerdere BSD-versies, de bestandssystemen waartoe NFS-clients toegang hebben. Daarnaast bevat het de serie extra kansen met betrekking tot beheer- en beveiligingsproblemen, en biedt de beheerder een hulpmiddel voor fijnafstemming. Deze tekstbestand bestaande uit ingangen, lege of becommentarieerde regels (opmerkingen beginnen met een #-teken).
Laten we zeggen dat we klanten alleen-lezen toegang willen geven tot de / home-directory op de Lefty-node. Dit in / etc / export komt overeen met volgende post:
/ thuis (ro)
Hier moeten we het systeem vertellen welke mappen we beschikbaar gaan maken met behulp van de rpc.mountd mount-daemon:
# exportfs -r exportfs: Geen hostnaam opgegeven in / home (ro), typ * (ro) om waarschuwing te voorkomen #
Wanneer uitgevoerd, drukt de opdracht exportfs een waarschuwing af dat / etc / exports de toegang tot een bepaald knooppunt niet beperkt, en maakt een corresponderend item in / var / lib / nfs / etab van / etc / exports om aan te geven welke bronnen kunnen worden bekeken met cat :
# cat / var / lib / nfs / etab / home (ro, async, wdelay, hide, secure, root_ squash, no_all_squash, subtree_check, secure_locks, mapping = identiteit, anonuid = -2, anongid = -2)
Andere opties, vermeld in etab, omvatten de standaardwaarden die door NFS worden gebruikt. Details zullen hieronder worden beschreven. Om toegang te verlenen tot de / home-directory, moeten de juiste NFS-services worden gestart:
# portmap # rpc.mountd # rpc.nfsd # rpc.statd # rpc.rquotad
Op elk moment na het starten van de mount-daemon (rpc.mountd), kunt u meer te weten komen over de afzonderlijke bestanden die beschikbaar zijn voor uitvoer door naar de inhoud van het / proc / fs / nfs / exports-bestand te kijken:
# cat / proc / fs / nfs / exports # Version 1.0 # Path Client (Flags) # IPs / home 192.168.1.252 (ro, root_squash, async, wdelay) # 192.168.1.252 #
Hetzelfde kan worden bekeken met behulp van de opdracht showmount met de parameter -e:
# showmount -e Exportlijst voor lefty: / home (iedereen) #
Het showmount-commando loopt een beetje voor op mezelf en kan ook worden gebruikt om alle gemounte bestandssystemen te identificeren, of, met andere woorden, om uit te zoeken welke nodes NFS-clients zijn voor het systeem waarop het showmount-commando wordt uitgevoerd. De opdracht showmount -a geeft een lijst van alle client-aankoppelpunten:
# showmount -a Alle aankoppelpunten op lefty: 192.168.1.252:/home #
Zoals hierboven vermeld, ondersteunen de meeste NFS-implementaties verschillende versies van dit protocol. Met de Linux-implementatie kun je de lijst met NFS-versies die moeten worden uitgevoerd, beperken door de -N-switch voor de mount-daemon op te geven. Om bijvoorbeeld NFS versie 3 en alleen versie 3 te starten, voert u de volgende opdracht in:
# rpc.gemonteerd -N 1 -N 2
Veeleisende gebruikers vinden het misschien onhandig dat de NFS-daemon (rpc.nfsd) op Linux wacht op versie 1- en versie 2-pakketten, hoewel dit het gewenste effect bereikt van het niet ondersteunen van het corresponderende protocol. Laten we hopen dat de ontwikkelaars volgende versies zal de nodige correcties aanbrengen en een grotere consistentie van de pakketcomponenten kunnen bereiken met betrekking tot: verschillende versies protocol.
"ZWEMMEN MET PINGUNEN"
Toegang tot de Lefty die hierboven is geconfigureerd, een op Linux gebaseerd NFS-geëxporteerd bestandssysteem, is afhankelijk van het clientbesturingssysteem. Installatiestijl voor de meeste besturingssystemen UNIX-familie komt overeen met de stijl van de originele Sun OS- en BSD-systemen, of de nieuwere Solaris. Aangezien dit artikel zich richt op zowel Linux- als Solaris-systemen, laten we eens kijken naar de Solaris 2.6-clientconfiguratie in termen van het tot stand brengen van een verbinding met de Linux-versie van NFS die we hierboven hebben beschreven.
De functies die zijn overgenomen van Solaris 2.6 maken het gemakkelijk om het te configureren om als een NFS-client te fungeren. Dit vereist slechts één opdracht:
# mount -F nfs 192.168.1.254:/home / tmp / tmp2
Ervan uitgaande dat het vorige mount-commando succesvol was, zal het mount-commando zonder parameters het volgende uitvoeren:
# mount / on / dev / dsk / c0t0d0s0 lezen / schrijven / setuid / largefiles op ma sep 3 10:17:56 2001 ... ... / tmp / tmp2 op 192.168.1.254:/home lezen / schrijven / remote aan ma 3 sep 23:19:25 2001
Laten we de tcpdump-uitvoer van het Lefty-knooppunt analyseren nadat de gebruiker de opdracht ls / tmp / tmp2 op het Sunny-knooppunt heeft ingevoerd:
# tcpdump host lefty en host sunny -s512 06: 07: 43.490583 sunny.2191983953> lefty.mcwrite.n.nfs: 128 getattr fh Unknown / 1 (DF) 06: 07: 43.490678 lefty.mcwrite.n.nfs> zonnig. 2191983953: antwoord ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06: 07: 43.491397 sunny.2191983954> lefty.mcwrite.n.nfs: 132 toegang fh Unknown / 10001 (DF) 06: 07: 43.491463 lefty. mcwrite.n.nfs> sunny.2191983954: reply ok 120 access c0001 (DF) 06: 07: 43.492296 sunny.2191983955> lefty.mcwrite.n.nfs: 152 readdirplus fh 0,1 / 16777984 1048 bytes @ 0x00000000 (DF) 06: 07: 43.492417 lefty.mcwrite.n.nfs> zonnig.2191983955: antwoord ok 1000 readdirplus (DF)
We zien dat Sunny ls om een bestandsdescriptor (fh) vraagt, waarop Lefty antwoordt met OK en de directorystructuur teruggeeft. Sunny controleert vervolgens de toestemming voor het recht op de inhoud van de directory (132 access fh) en ontvangt een toestemmingsantwoord van Lefty. Sunny leest vervolgens de volledige directory-inhoud met behulp van de readdirplus-routine. Procedureaanroepen op afstand worden beschreven in RFC 1813 en waarnaar we aan het begin van dit artikel hebben verwezen.
Hoewel de opdrachtvolgorde voor toegang tot externe bestandssystemen heel eenvoudig is, kunnen een aantal omstandigheden leiden tot een onjuiste systeemaankoppeling. Voordat een directory wordt gemount, moet het koppelpunt al bestaan, in anders het moet worden gemaakt met de opdracht mkdir. Meestal de enige reden voor fouten op kant van de cliënt is het ontbreken van een lokale map om te mounten. De meeste problemen met NFS zijn te wijten aan een mismatch tussen de client en de server of een onjuiste serverconfiguratie.
De eenvoudigste manier om serverproblemen op te lossen is vanaf de site waar de server draait. Wanneer echter iemand anders de server beheert in plaats van u, is dit niet altijd mogelijk. Een snelle manier om ervoor te zorgen dat de juiste serverservices correct zijn geconfigureerd, is door de opdracht rpcinfo te gebruiken met de parameter -p. Vanaf de Solaris Sunny-host kunt u bepalen welke RPC-processen op de Linux-host zijn geregistreerd:
# rpcinfo -p 192.168.1.254 programma versus proto-poortservice 100000 2 tcp 111 rpcbind 100000 2 udp 111 rpcbind 100024 1 udp 692 status 100024 1 tcp 694 status 100005 3 udp 1024 gemonteerd / 100005 3 tcp 1024 gemonteerd 100003 2 udp 1000 2049 udp 2049 nfs 100021 1 udp 1026 nlockmgr 100021 3 udp 1026 nlockmgr 100021 4 udp 1026 nlockmgr #
Merk op dat hier ook versie-informatie wordt gegeven, wat erg handig is wanneer het systeem ondersteuning nodig heeft voor verschillende NFS-protocollen. Als een service niet op de server draait, moet deze situatie worden gecorrigeerd. Als het koppelen mislukt, geeft het volgende rpcinfo -p-commando aan dat de mountd-service op de server niet beschikbaar is:
# rpcinfo -p 192.168.1.254 programma versus proto-poortservice 100000 2 tcp 111 rpcbind ... ... 100021 4 udp 1026 nlockmgr #
De opdracht rpcinfo is erg handig om uit te zoeken of de ene of de andere actief is proces op afstand... De -p optie is de belangrijkste van de opties. Voor een compleet overzicht van de functies van rpcinfo, zie de man-pagina.
Een ander handig hulpmiddel is de opdracht nfsstat. Het kan worden gebruikt om erachter te komen of clients daadwerkelijk toegang hebben tot het geëxporteerde bestandssysteem, en om statistische informatie weer te geven volgens de protocolversie.
Eindelijk, nog een is genoeg bruikbaar gereedschap het bepalen van de oorzaak van systeemcrashes is tcpdump:
# tcpdump host lefty en host sunny -s512 tcpdump: luisteren op eth0 06: 29: 51.773646 sunny.2191984020> lefty.mcwrite.n.nfs: 140 lookup fh Unknown / 1 "test.c" (DF) 06: 29: 51.773819 lefty.mcwrite.n.nfs> sunny.2191984020: antwoord ok 116 lookup FOUT: Geen dergelijk bestand of map (DF) 06: 29: 51.774593 sunny.2191984021> lefty.mcwrite.n.nfs: 128 getattr fh Unknown / 1 ( DF) 06: 29: 51.774670 lefty.mcwrite.n.nfs> sunny.2191984021: antwoord ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06: 29: 51.775289 sunny.2191984022> lefty.mcwrite.n.nfs : 140 lookup fh Unknown / 1 "test.c" (DF) 06: 29: 51.775357 lefty.mcwrite.n.nfs> sunny.2191984022: reply ok 116 lookup FOUT: Geen dergelijk bestand of map (DF) 06:29: 51.776029 sunny.2191984023> lefty.mcwrite.n.nfs: 184 create fh Unknown / 1 "test.c" (DF) 06: 29: 51.776169 lefty.mcwrite.n.nfs> sunny.2191984023: reply ok 120 create FOUT: Toestemming geweigerd (DF)
De bovenstaande lijst, verkregen na het uitvoeren van de touch test.c-instructie, geeft de volgende reeks acties weer: eerst probeert het touch-commando toegang te krijgen tot het bestand met de naam test.c, dan zoekt het naar een map met dezelfde naam en na niet-succesvolle probeert, probeert het het bestand test.c te maken, wat ook niet tot succes leidt.
Als het bestandssysteem is gemount, dan zijn de meeste typische fouten gerelateerd aan normale UNIX-machtigingen. Sun's gebruik van uid of NIS + vermijdt het wereldwijd instellen van machtigingen op alle bestandssystemen. Sommige beheerders oefenen "open" mappen, waar leesrechten worden gegeven aan "de hele wereld". Om veiligheidsredenen moet dit echter worden vermeden. Afgezien van beveiligingsproblemen, moet je nog steeds toegeven dat dit een slechte gewoonte is, omdat gebruikers zelden gegevens maken met de bedoeling deze voor iedereen leesbaar te maken.
Toegang door de supergebruiker (root) tot aangekoppelde NFS-bestandssystemen wordt anders behandeld. Om te voorkomen dat een bevoorrechte gebruiker onbeperkte toegang wordt verleend, worden verzoeken van de rootgebruiker behandeld alsof ze afkomstig zijn van de niemand-gebruiker. Dit krachtige mechanisme beperkt geprivilegieerde gebruikerstoegang tot wereldwijd leesbare en beschrijfbare bestanden.
NFS SERVER SOLARIS VERSIE
Het configureren van Solaris als NFS-server is net zo eenvoudig als Linux. De opdrachten en bestandslocaties zijn echter iets anders. Wanneer Solaris opstart en runniveau 3 bereikt, worden NFS-services automatisch gestart en worden alle bestandssystemen geëxporteerd. Voer de opdracht in om deze processen handmatig te starten:
# / usr / lib / nfs / mountd
Om de mount-daemon en de NFS-server te starten, voert u het volgende in:
# / usr / lib / nfs / nfsd
Vanaf 2.6 gebruikt Solaris niet langer een exportbestand om geëxporteerde bestandssystemen te specificeren. De bestanden worden nu geëxporteerd met de opdracht share. Laten we zeggen dat we externe hosts willen toestaan om te mounten/exporteren/home. Laten we hiervoor het volgende commando invoeren:
Share -F nfs / export / home
Veiligheids maatregelen
VEILIGHEID IN LINUX
Sommige NFS-systeemservices aan op Linux gebaseerd hebben een extra mechanisme voor het beperken van toegang via controlelijsten of tabellen. Intern wordt dit mechanisme geïmplementeerd met behulp van de tcp_wrapper-bibliotheek, die twee bestanden gebruikt om toegangscontrolelijsten te genereren: /etc/hosts.allow en / etc / hosts / deny. Een uitgebreid overzicht van de regels voor het werken met tcp_wrapper valt buiten het bestek van dit artikel, maar het basisprincipe is als volgt: de mapping gebeurt eerst met etc / hosts.allow, en dan met / etc / hosts. ontkennen. Als de regel niet wordt gevonden, wordt de gevraagde systeemservice niet weergegeven. Om de laatste vereiste te omzeilen en een zeer hoog beveiligingsniveau te bieden, kunt u het volgende item toevoegen aan het einde van /etc/hosts.deny:
ALLES: Alles
Daarna kunt u / etc / hosts.allow gebruiken om deze of gene werkingsmodus in te stellen. Bijvoorbeeld het bestand / etc / hosts. De toestemming die ik gebruikte bij het schrijven van dit artikel bevatte de volgende regels:
Vergrendeld: 192.168.1.0/255.255.255.0 aangekoppeld: 192.168.1.0/255.255.255.0 portmap: 192.168.1.0/255.255.255.0 rquotad: 192.168.1.0/255.255.255.0 statd: 192.168.1.0/255.255.255.0
Dit maakt een bepaald soort toegang tot de knooppunten mogelijk voordat de toegang op applicatieniveau wordt verleend. Op Linux wordt de toegang op applicatieniveau geregeld door het /etc/exportbestand. Het bestaat uit records in het volgende formaat:
Geëxporteerde directory (spatie) node | netwerk (opties)
De "geëxporteerde map" is de map waarvoor de nfsd-daemon verzoeken mag verwerken. "Host | netwerk" is het knooppunt of netwerk dat toegang heeft tot het geëxporteerde bestandssysteem, en "opties" definiëren de beperkingen die de nfsd-daemon oplegt aan het gebruik van deze gedeelde bron - alleen-lezen toegang of gebruikers-ID-toewijzing ...
In het volgende voorbeeld krijgt het hele domein mcwrite.net alleen-lezen toegang tot /home/mcwrite.net:
/home/mcwrite.net * .mcwrite.net (ro)
Meer voorbeelden zijn te vinden in de export man-pagina.
NFS-BEVEILIGING IN SOLARIS
Op Solaris is de mogelijkheid om NFS-toegang te bieden vergelijkbaar met die van Linux, maar in dit geval worden beperkingen ingesteld met behulp van specifieke parameters in de share-opdracht met de -o-schakelaar. Het volgende voorbeeld laat zien hoe u alleen-lezen mount /export/mcwrite.net inschakelt op elke host in het mcwrite.net-domein:
#share -F nfs -o ro = .mcwrite.net / export / mcwrite.net
De man-pagina voor share_nfs beschrijft in detail hoe toegang te verlenen met behulp van controlelijsten op Solaris.
Internetbronnen
NFS en RPC zijn niet zonder gaten. Over het algemeen mag NFS niet op internet worden gebruikt. Firewalls mogen geen "gaten" zijn door enige vorm van NFS-toegang te bieden. Houd eventuele RPC- en NFS-patches in de gaten, en talrijke bronnen van beveiligingsinformatie kunnen helpen. De twee meest populaire bronnen zijn Bugtraq en CERT:
De eerste kan regelmatig bekeken worden op zoek naar de nodige informatie of gebruik een abonnement op een periodieke nieuwsbrief. De tweede biedt, in vergelijking met andere, misschien niet zo snel informatie, maar in een vrij volledig volume en zonder een vleugje sensatiezucht die inherent is aan sommige sites die zijn gewijd aan informatiebeveiliging.
NFS: een handig en toekomstbestendig netwerkbestandssysteem
Netwerk bestandssysteem Is een netwerkabstractie bovenop een gewoon bestandssysteem, waardoor een externe client er toegang toe heeft via het netwerk op dezelfde manier als bij toegang tot lokale bestandssystemen. Hoewel NFS niet het eerste netwerkbestandssysteem was, is het tegenwoordig uitgegroeid tot het meest functionele en meest gevraagde netwerkbestandssysteem in UNIX®. Met NFS kunnen meerdere gebruikers een gemeenschappelijk bestandssysteem delen en gegevens centraliseren om te minimaliseren schijfruimte nodig voor hun opslag.
Dit artikel begint met een kort overzicht van de geschiedenis van NFS en gaat vervolgens verder met het verkennen van de NFS-architectuur en hoe deze zal evolueren.
Een korte geschiedenis van NFS
Het eerste netwerkbestandssysteem heette FAL (File Access Listener) en werd in 1976 ontwikkeld door DEC (Digital Equipment Corporation). Het was een implementatie van het Data Access Protocol (DAP) en maakte deel uit van de DECnet-protocolsuite. Net als bij TCP/IP heeft DEC specificaties gepubliceerd voor zijn netwerkprotocollen, waaronder DAP.
NFS was het eerste moderne netwerkbestandssysteem dat over IP werd gebouwd. Het prototype kan worden beschouwd als een experimenteel bestandssysteem dat begin jaren tachtig door Sun Microsystems is ontwikkeld. Gezien de populariteit van deze oplossing, werd het NFS-protocol geïntroduceerd als een RFC-specificatie en vervolgens geëvolueerd naar NFSv2. NFS vestigde zich snel als een standaard vanwege zijn vermogen om samen te werken met andere clients en servers.
De standaard werd vervolgens bijgewerkt naar de NFSv3-versie die is gedefinieerd in RFC 1813. Deze versie van het protocol was schaalbaarder dan eerdere versies en ondersteunde grotere bestanden (meer dan 2 GB), asynchroon schrijven en TCP als transportprotocol. NFSv3 bepaalt de richting voor bestandssystemen voor wide area (WAN) netwerken. In 2000 werd NFS, als onderdeel van de RFC 3010-specificatie (herzien in de RFC 3530-versie), overgezet naar de bedrijfsomgeving. Sun introduceerde veiliger NFSv4 met stateful-ondersteuning (vorige versies van NFS ondersteunden statefulness niet, d.w.z. ze waren stateless). Momenteel is de nieuwste versie van NFS versie 4.1, gedefinieerd in RFC 5661, waarin het protocol door middel van de extensie pNFS ondersteuning voor parallelle toegang voor gedistribueerde servers is toegevoegd.
De geschiedenis van NFS-ontwikkeling, inclusief specifieke RFC's die de versies ervan beschrijven, wordt weergegeven in figuur 1.
Verrassend genoeg is NFS al bijna 30 jaar in ontwikkeling. Het is een extreem stabiel en draagbaar netwerkbestandssysteem met uitstekende schaalbaarheid, prestaties en servicekwaliteit. Met de toenemende snelheid en afnemende latentie van gegevensuitwisseling binnen het netwerk, blijft NFS een populaire manier om het bestandssysteem binnen het netwerk te implementeren. Zelfs met LAN's stimuleert virtualisatie het opslaan van gegevens op het netwerk om virtuele machines extra mobiliteit te bieden. NFS ondersteunt ook de nieuwste computeromgevingen die zijn ontworpen om virtuele infrastructuren te optimaliseren.
NFS-architectuur
NFS gebruikt een standaard client-server-architectuurmodel (zoals weergegeven in afbeelding 2). De server is verantwoordelijk voor het implementeren van het gedeelde bestandssysteem en de opslag waarmee clients verbinding maken. De client implementeert een gebruikersinterface naar een gedeeld bestandssysteem dat is gemonteerd in de lokale bestandsruimte van de client.
Figuur 2. Implementatie van het client-servermodel in de NFS-architectuur
Op Linux® biedt een virtuele bestandssysteemschakelaar (VFS) de mogelijkheid om meerdere bestandssystemen (zoals een bestandssysteem) tegelijkertijd op één host te ondersteunen. ISO-systemen 9660 op cd-rom en ext3fs-bestandssysteem op lokale harde schijf). De virtuele switch bepaalt naar welke schijf het verzoek wordt gedaan en dus welk bestandssysteem moet worden gebruikt om het verzoek te verwerken. Daarom heeft NFS dezelfde compatibiliteit als andere bestandssystemen die in Linux worden gebruikt. Het enige verschil met NFS is dat I/O-verzoeken, in plaats van lokaal op de host te worden verwerkt, voor uitvoering naar het netwerk kunnen worden gerouteerd.
De VFS stelt vast dat het verzoek dat het ontvangt NFS is en geeft het door aan de NFS-handler in de kernel. De NFS-handler verwerkt de I/O-request en vertaalt deze naar een NFS-procedure (OPEN, ACCESS, CREATE, READ, CLOSE, REMOVE, etc.). Deze procedures, beschreven in een aparte RFC-specificatie, definiëren het gedrag van het NFS-protocol. De vereiste procedure wordt geselecteerd op basis van het verzoek en uitgevoerd met behulp van RPC-technologie (Remote Procedure Call). Zoals de naam al doet vermoeden, maakt RPC het mogelijk om tussen verschillende systemen procedure-aanroepen te doen. De RPC-service verbindt het NFS-verzoek met zijn argumenten en stuurt het resultaat naar de juiste externe host, en bewaakt vervolgens de ontvangst en verwerking van het antwoord om het terug te sturen naar de aanvrager.
RPC bevat ook een belangrijke XDR-laag ( externe gegevensrepresentatie- onafhankelijke presentatie van data), die ervoor zorgt dat alle NFS-gebruikers hetzelfde formaat gebruiken voor dezelfde datatypes. Wanneer een platform een verzoek indient, kan het gegevenstype dat het gebruikt verschillen van het gegevenstype dat wordt gebruikt op de host die het verzoek verwerkt. XDR neemt het werk van typeconversie naar standaardweergave (XDR) over, zodat platforms die verschillende architecturen gebruiken, kunnen communiceren en bestandssystemen kunnen delen. XDR definieert een bitformaat voor typen zoals float, en bytevolgorde voor typen zoals arrays van constante en variabele lengte... Hoewel XDR vooral bekend staat om zijn gebruik in NFS, kan deze specificatie handig zijn wanneer je in dezelfde omgeving met verschillende architecturen moet werken.
Nadat XDR de gegevens heeft geconverteerd naar een standaardweergave, wordt het verzoek via een specifiek transportprotocol over het netwerk verzonden. Vroege implementaties van NFS gebruikten UDP, maar tegenwoordig wordt TCP gebruikt voor meer robuustheid.
Aan de kant van de NFS-server wordt een soortgelijk algoritme gebruikt. Het verzoek stijgt de netwerkstack via de RPC / XDR-laag (om gegevenstypen te converteren volgens de serverarchitectuur) en gaat naar de NFS-server, die verantwoordelijk is voor het verwerken van het verzoek. Daar wordt het verzoek doorgegeven aan de NFS-daemon om het doelbestandssysteem te bepalen waaraan het is geadresseerd, en gaat dan opnieuw de VFS binnen om toegang te krijgen tot dit bestandssysteem op de lokale schijf. Een volledig schema van dit proces wordt getoond in figuur 3. In dit geval is het lokale bestandssysteem van de server standaard voor: Linux-bestand systeem zoals ext4fs. In feite is NFS geen bestandssysteem in de traditionele zin van het woord, maar een protocol voor toegang op afstand tot bestandssystemen.
Voor netwerken met lange latentie biedt NFSv4 een speciale samengestelde procedure ( samengestelde procedure). Met deze procedure kunt u meerdere RPC-oproepen in één verzoek verpakken om de overhead van het verzenden van verzoeken via het netwerk te minimaliseren. Deze procedure implementeert ook het mechanisme van terugbelfuncties voor het ontvangen van antwoorden.
NFS-protocol
Wanneer een client opstart met NFS, is de eerste stap de mount-bewerking, namelijk het mounten van het externe bestandssysteem naar de lokale bestandssysteemruimte. Dit proces begint met een aanroep van de mount-procedure (een van systeemfuncties Linux), die via VFS wordt omgeleid naar de NFS-component. Vervolgens wordt met behulp van een RPC-aanroep naar de functie get_port op de externe server het poortnummer bepaald dat voor de montage zal worden gebruikt en verzendt de client een koppelverzoek via RPC. Dit verzoek aan de serverzijde wordt afgehandeld door een speciale rpc.mountd-daemon die verantwoordelijk is voor het mount-protocol ( mount-protocol). De daemon controleert of het door de client gevraagde bestandssysteem in de lijst met systemen beschikbaar is op deze server... Als het aangevraagde systeem bestaat en de client heeft er toegang toe, dan wordt de bestandssysteemdescriptor gespecificeerd in het antwoord van de mount RPC-procedure. De client behoudt informatie over de lokale en externe koppelpunten en kan I/O-verzoeken doen. Het mount-protocol is niet foutloos vanuit beveiligingsoogpunt, dus NFSv4 gebruikt in plaats daarvan interne RPC-aanroepen, die ook mount-punten kunnen manipuleren.
Om een bestand te lezen, moet u het eerst openen. Er is geen OPEN-procedure in RPC, in plaats daarvan controleert de client dat gewoon gespecificeerd bestand en de map bestaat op het aangekoppelde bestandssysteem. De client begint met het maken van een RPC GETATTR-verzoek voor de directory, die de attributen van de directory retourneert of een indicator dat de directory niet bestaat. Vervolgens doet de client een RPC LOOKUP-verzoek om te controleren op het bestaan van het bestand. Als het bestand bestaat, wordt een RPC GETATTR-verzoek gedaan om de bestandskenmerken te achterhalen. Met behulp van de informatie die is verkregen uit succesvolle LOOKUP- en GETATTR-aanroepen, maakt de client een bestandsdescriptor die aan de gebruiker wordt gepresenteerd voor toekomstige verzoeken.
Nadat het bestand is geïdentificeerd op het externe bestandssysteem, kan de client RPC READ-verzoeken uitgeven. Dit verzoek bestaat uit een bestandsdescriptor, status, offset en het aantal te lezen bytes. De client gebruikt de staat ( staat) om te bepalen of de operatie op dit moment kan worden uitgevoerd, d.w.z. of het bestand is vergrendeld. compensatie ( offset) geeft aan waar te beginnen met lezen, en de byteteller ( Graaf) bepaalt hoeveel bytes moeten worden gelezen. Als resultaat van een RPC READ-aanroep retourneert de server niet altijd zoveel bytes als gevraagd, maar verzendt hij altijd samen met de geretourneerde gegevens hoeveel bytes er naar de client zijn verzonden.
Innovatie in NFS
Van het grootste belang zijn de twee nieuwste versies van NFS - 4 en 4.1, die kunnen worden gebruikt om de belangrijkste aspecten van de evolutie van NFS-technologie te bestuderen.
Vóór de komst van NFSv4, voor het uitvoeren van bestandsbeheertaken zoals koppelen, vergrendelen, enz. er waren speciale aanvullende protocollen. In NFSv4 is het bestandsbeheerproces vereenvoudigd tot één enkel protocol; bovendien wordt UDP sinds deze versie niet meer als transportprotocol gebruikt. NFSv4 bevat ondersteuning voor UNIX en Windows® bestandstoegangssemantiek, waardoor NFS op natuurlijke wijze kan worden geïntegreerd in andere besturingssystemen.
NFSv4.1 introduceerde het concept van: parallelle NFS(parallelle NFS - pNFS). Om meer schaalbaarheid te bieden, implementeert NFSv4.1 een architectuur waarin data en metadata ( opmaak) worden verdeeld over apparaten op een manier die vergelijkbaar is met geclusterde bestandssystemen. Zoals geïllustreerd verdeelt pNFS het ecosysteem in drie pijlers: client, server en opslag. In dit geval verschijnen er twee kanalen: een voor het verzenden van gegevens en het andere voor het verzenden van besturingscommando's. pNFS scheidt gegevens van de metagegevens die het beschrijven, waardoor een tweekanaalsarchitectuur ontstaat. Wanneer een client toegang wil tot een bestand, stuurt de server het "opmaak"-metadata. De metadata bevat informatie over de locatie van het bestand op opslagapparaten. Met deze informatie heeft de klant rechtstreeks toegang tot opslag zonder interactie met de server, wat de schaalbaarheid en prestaties verbetert. Wanneer de klant klaar is met werken aan het bestand, bevestigt hij de wijzigingen die in het bestand zijn aangebracht en de "opmaak". Indien nodig kan de server de markup-metadata opvragen bij de client.
Met de introductie van pNFS zijn er verschillende nieuwe bewerkingen aan het NFS-protocol toegevoegd om dit mechanisme te ondersteunen. De LayoutGet-methode wordt gebruikt om metadata van de server op te halen, de LayoutReturn-methode "bevrijt" de metadata die door de client zijn "vastgelegd" en de LayoutCommit-methode laadt de "opmaak" die van de client is ontvangen in de repository, zodat deze beschikbaar is voor andere gebruikers. De server kan de metadata van de client intrekken met behulp van de LayoutRecall-methode. "Gemarkeerde" metadata wordt verspreid over meerdere opslagapparaten om gelijktijdige toegang en hoge prestaties te bieden.
Gegevens en metagegevens worden opgeslagen op opslagapparaten. Clients kunnen directe I/O-verzoeken doen op basis van de resulterende markup, en de NFSv4.1-server slaat de metadata op en beheert deze. Deze functionaliteit is op zich niet nieuw, maar ondersteuning voor verschillende methoden om toegang te krijgen tot opslagapparaten is toegevoegd aan pNFS. Tegenwoordig ondersteunt pNFS het gebruik van blokprotocollen (Fiber Channel), objectprotocollen en NFS zelf (zelfs niet in pNFS-vorm).
NFS blijft zich ontwikkelen en de vereisten voor NFSv4.2 werden in september 2010 gepubliceerd. Sommige innovaties houden verband met de waargenomen migratie van opslagtechnologieën naar virtualisatie. Bijvoorbeeld, in virtuele omgevingen met een hypervisor is gegevensduplicatie zeer waarschijnlijk (meerdere besturingssystemen lezen / schrijven en cachen dezelfde gegevens). Daarom is het wenselijk dat het opslagsysteem als geheel begrijpt waar duplicatie optreedt. Deze benadering kan helpen om de cacheruimte van de client en de algehele opslagcapaciteit te besparen. NFSv4.2 stelt voor om een "blokkaart van gedeelde blokken" te gebruiken om dit probleem op te lossen. Voor zover moderne systemen opslag wordt steeds meer uitgerust met zijn eigen interne rekenkracht, server-side kopiëren wordt geïntroduceerd, waardoor de belasting bij het kopiëren van gegevens naar intern netwerk wanneer het effectief kan worden gedaan op het opslagapparaat zelf. Andere innovaties zijn onder meer het cachen van subbestanden voor flash en aanbevelingen voor het aanpassen van client-side I/O (bijvoorbeeld met behulp van mapadvise).
NFS-alternatieven
Hoewel NFS het populairste netwerkbestandssysteem op UNIX en Linux is, zijn er naast het ook andere netwerkbestandssystemen. Het Windows®-platform maakt meestal gebruik van SMB, ook wel bekend als CIFS; Windows ondersteunt echter ook NFS, net als Linux SMB.
Een van de nieuwste door Linux ondersteunde gedistribueerde bestandssystemen, Ceph, is van de grond af ontworpen als een fouttolerant POSIX-compatibel bestandssysteem. Meer informatie over Ceph vindt u in de rubriek.
Het is ook het vermelden waard de bestandssystemen OpenAFS (de Open Source-versie van het Andrew Distributed File System ontwikkeld aan de Carnegie Mellon University en IBM Corporation), GlusterFS (het gedistribueerde bestandssysteem algemeen doel voor het organiseren van schaalbare datawarehouses) en Luster (netwerkbestandssysteem met enorm parallellisme voor clusteroplossingen). Al deze open source-systemen kunnen worden gebruikt om gedistribueerde opslag te bouwen.
Gevolgtrekking
De ontwikkeling van het NFS-bestandssysteem gaat door. Net als Linux, geschikt voor het ondersteunen van budget-, embedded en high-performance oplossingen, biedt NFS een architectuur van schaalbare opslagoplossingen die geschikt zijn voor zowel individuen als organisaties. Kijkend naar het pad dat NFS heeft afgelegd en de toekomstige ontwikkeling ervan, wordt het duidelijk dat dit bestandssysteem de manier waarop we denken over hoe technologieën voor bestandsopslag worden geïmplementeerd en gebruikt, zal blijven veranderen.
Netwerkbestandssysteem (NFS)- protocol netwerktoegang naar bestandssystemen, stelt u in staat om externe bestandssystemen te mounten.
Oorspronkelijk ontwikkeld door Sun Microsystems in 1984, is het gebaseerd op Sun RPC: Remote Procedure Call. NFS is onafhankelijk van de server- en clientbestandssysteemtypen. Er zijn veel implementaties van NFS-servers en clients voor verschillende besturingssystemen. Momenteel in gebruik NFS-versie v.4, die verschillende authenticatietools ondersteunt (met name Kerberos en LIPKEY met behulp van het RPCSEC GSS-protocol) en ACL's (zowel POSIX- als Windows-typen).
NFS biedt klanten transparante toegang tot de bestanden en het bestandssysteem van de server. In tegenstelling tot FTP, heeft NFS alleen toegang tot de delen van het bestand waartoe het proces toegang heeft gehad, en het belangrijkste voordeel is dat het deze toegang transparant maakt. Dankzij dit kan elke clienttoepassing die kan werken met lokaal bestand, met hetzelfde succes kan werken met een NFS-bestand, zonder het programma zelf te veranderen.
NFS-clients hebben toegang tot bestanden op de NFS-server door RPC-verzoeken naar de server te sturen. Dit kan worden geïmplementeerd met behulp van normale gebruikersprocessen - namelijk de NFS-client kan een gebruikersproces zijn dat specifieke RPC-aanroepen naar de server doet, wat ook een gebruikersproces kan zijn.
versies
NFSv1 was alleen voor intern gebruik voor experimentele doeleinden. Implementatiedetails zijn gedefinieerd in RFC 1094.
NFSv2 (RFC 1094, maart 1989) liep oorspronkelijk volledig over UDP.
NFSv3 (RFC 1813, juni 1995). Bestandsbeschrijvingen in versie 2 zijn een array van vaste grootte van 32 bytes. In versie 3 is het een array met variabele grootte tot 64 bytes. Een array met variabele lengte in XDR wordt gedefinieerd door een 4-byte-teller gevolgd door echte bytes. Dit verkleint de bestandsdescriptor op implementaties zoals UNIX, die slechts ongeveer 12 bytes nodig hebben, maar laat niet-Unix-implementaties toe om aanvullende informatie uit te wisselen.
Versie 2 beperkt het aantal bytes per READ of WRITE RPC tot 8192 bytes. Deze beperking is niet van toepassing in versie 3, wat op zijn beurt betekent dat bij gebruik van UDP de beperking alleen in de grootte van het IP-datagram ligt (65535 bytes). Hierdoor kunnen grote pakketten worden gebruikt bij het lezen en schrijven op snelle netwerken.
Bestandsgroottes en initiële byte-offset voor LEES- en SCHRIJF-procedures begonnen 64-bits adressering te gebruiken in plaats van 32-bits, waardoor het werken met grotere bestanden mogelijk wordt.
Bestandskenmerken worden geretourneerd in elke aanroep die van invloed kan zijn op de kenmerken.
Schrijfbewerkingen (WRITE) kunnen asynchroon zijn, terwijl ze in versie 2 synchroon moesten zijn.
Eén procedure is verwijderd (STATFS) en zeven zijn toegevoegd: ACCESS (bestandsrechten controleren), MKNOD (maken speciaal bestand Unix), READDIRPLUS (retourneert de namen van bestanden in een directory samen met hun attributen), FSINFO (retourneert statistische informatie over het bestandssysteem), FSSTAT (retourneert dynamische informatie over het bestandssysteem), PATHCONF (retourneert POSIX.1-informatie over een bestand) , en COMMIT (overdrachten die eerder asynchrone persistente schrijfbewerkingen hebben gemaakt).
Ten tijde van de introductie van versie 3 begonnen ontwikkelaars TCP meer als transportprotocol te gebruiken. Hoewel sommige ontwikkelaars al TCP voor NFSv2 hebben gebruikt, heeft Sun Microsystems TCP-ondersteuning toegevoegd aan NFS versie 3. Dit maakte het gebruik van NFS via internet haalbaarder.
NFSv4 (RFC 3010, december 2000, RFC 3530, herzien april 2003), beïnvloed door AFS en CIFS, bevatte prestatieverbeteringen, hoge beveiliging en kwam naar voren als een volwaardig protocol. Versie 4 was de eerste versie die werd ontwikkeld in samenwerking met de Internet Engineering Task Force (IETF) nadat Sun Microsystems de ontwikkeling van de NFS-protocollen had doorgegeven. NFS v4.1 werd in januari 2010 goedgekeurd door de IESG en ontving RFC 5661. Een belangrijke innovatie in versie 4.1 is de pNFS-specificatie - Parallel NFS, een mechanisme voor parallelle NFS-clienttoegang tot gegevens van meerdere gedistribueerde NFS-servers. De aanwezigheid van een dergelijk mechanisme in de netwerkbestandssysteemstandaard zal helpen om gedistribueerde "cloud" -opslag- en informatiesystemen te bouwen.
De NFS-structuur heeft drie componenten op verschillende niveaus:
De applicatielaag (NFS zelf) bestaat uit de externe procedureaanroepen (rpc) die de noodzakelijke bewerkingen uitvoeren op bestanden en mappen aan de serverzijde.
De functies van de presentatielaag worden uitgevoerd door het XDR-protocol (eXternal Data Representation), dat een platformonafhankelijke data-abstractiestandaard is. Het XDR-protocol beschrijft een uniforme, canonieke vorm van gegevensrepresentatie die niet afhankelijk is van de architectuur van het computersysteem. Bij het verzenden van pakketten zet de RPC-client de lokale gegevens om in canonieke vorm, en de server doet het tegenovergestelde.
De Remote Procedure Call (RPC)-service, waarmee een client procedures op afstand kan aanvragen en deze op de server kan uitvoeren, is een functie op sessieniveau. Netwerkbronnen verbinden
De procedure voor het verbinden van een netwerkbron met behulp van NFS wordt "exporteren" genoemd. De client kan de server vragen om een lijst van de geëxporteerde bronnen die hij vertegenwoordigt. De NFS-server zendt zelf geen lijst uit van zijn geëxporteerde bronnen.
Afhankelijk van de opgegeven opties, kan de geëxporteerde bron worden aangekoppeld (bijgevoegd) "alleen-lezen", u kunt een lijst definiëren van hosts die mogen worden aangekoppeld, het gebruik van beveiligde RPC (secureRPC) specificeren, enz. Een van de opties bepaalt de montagemethode: "hard" (hard) of "soft" (zacht).
Bij een "harde" koppeling zal de client koste wat kost proberen het bestandssysteem te mounten. Als de server niet beschikbaar is, zal dit ertoe leiden dat de hele NFS-service lijkt te bevriezen: processen die toegang hebben tot het bestandssysteem, gaan in een staat van wachten op de voltooiing van RPC-verzoeken. Vanuit het oogpunt van gebruikersprocessen zal het bestandssysteem verschijnen als een zeer trage lokale schijf. Wanneer de server weer online is, blijft de NFS-service functioneren.
In een soft mount zal de NFS-client verschillende pogingen doen om verbinding te maken met de server. Als de server niet reageert, geeft het systeem een foutmelding en stopt met proberen te koppelen. Vanuit het oogpunt van de logica van bestandsbewerkingen, emuleert een soft mount een storing van een lokale schijf wanneer een server uitvalt.
De keuze van de modus is afhankelijk van de situatie. Als de data op de client en server gesynchroniseerd moeten worden bij een tijdelijke uitval van de dienst, dan heeft een "harde" mount de voorkeur. Deze modus is ook onvervangbaar in gevallen waarin de aangekoppelde bestandssystemen programma's en bestanden bevatten die essentieel zijn voor de werking van de client, in het bijzonder voor schijfloze machines. In andere gevallen, vooral wanneer het komt op alleen-lezen systemen is soft mount handiger.
Gemengd netwerk delen
NFS is ideaal voor op UNIX gebaseerde netwerken, aangezien het wordt geleverd met de meeste versies van het besturingssysteem. Bovendien is NFS-ondersteuning geïmplementeerd op UNIX-kernelniveau. Het gebruik van NFS op Windows-clientcomputers zorgt voor bepaalde problemen die verband houden met de noodzaak om gespecialiseerde en vrij dure clientsoftware te installeren. In dergelijke netwerken lijkt het gebruik van op SMB/CIFS gebaseerde tools voor delen, met name Samba-software, de voorkeur te hebben.
normen
RFC 1094 NFS: Network File System Protocol-specificatie] (maart 1989)
RFC 1813 NFS versie 3 protocolspecificatie] (juni 1995)
RFC 2224 NFS URL-schema
RFC 2339 Een overeenkomst Tussen de Internet Society, de IETF en Sun Microsystems, Inc. in de kwestie van NFS V.4-protocollen
RFC 2623 NFS Versie 2 en Versie 3 Beveiligingsproblemen en het gebruik van RPCSEC_GSS en Kerberos V5 door het NFS-protocol
RFC 2624 NFS Versie 4 Ontwerpoverwegingen
RFC 3010 NFS versie 4 Protocol
RFC 3530 Network File System (NFS) versie 4 Protocol
RFC 5661 Network File System (NFS) versie 4 Minor versie 1 protocol
Gebruikte bronnen
1.ru.wikipedia.org
2.ru.science.wikia.com
3. phone16.ru
4.4stud.info
5.yandex.ru
6.gogle.com
De belangrijkste kenmerken van het NFS-bestandssysteem op het UNIX-platform.
Geluk is wanneer onze verlangens samenvallen met de mogelijkheden van andere mensen.
"Tijd"
Netwerkbestandssystemen hebben een belangrijke rol gespeeld, zijn en blijven een belangrijke rol spelen in informatie-infrastructuur... Ondanks de groeiende populariteit van applicatieservers, blijft de fileservice een universeel middel om de collectieve toegang tot informatie te organiseren. Bovendien fungeren veel applicatieservers tegelijkertijd als bestandsservers.
Het UNIX-besturingssysteem beleeft momenteel een soort renaissance, vanwege een groot deel van deze toename van interesse in het gratis Linux-besturingssysteem. Tegelijkertijd worden op desktopcomputers verschillende varianten van Windows gebruikt, in de eerste plaats Windows 9x en Windows NT / 2000, hoewel ook hier de gratis varianten van UNIX geleidelijk aan burgerschap winnen.
Voor veel organisaties is het hosten van een netwerkbestandsservice op UNIX-computers een aantrekkelijke oplossing, op voorwaarde dat de service voldoende prestaties en betrouwbaarheid heeft. Gezien de talrijke verschillen in UNIX- en Windows-bestandssystemen, voornamelijk in bestandsnaamschema's, eigenaardigheden van toegangsrechten, vergrendelingen en systeemaanroepen bij het openen van bestanden, is het waarborgen van transparantie van toegang in een heterogene UNIX / Windows-omgeving van bijzonder belang. Bovendien worden UNIX-bestandsservers vaak geïnstalleerd als een add-on voor bestaande Windows NT- en NetWare-servers.
Voor het UNIX-besturingssysteem zijn er implementaties van alle min of meer populaire netwerkbestandssystemen, inclusief die welke worden gebruikt in netwerken Microsoft (SMB), NetWare (NCP), Macintosh (AFP). Natuurlijk hebben UNIX-netwerken hun eigen protocollen, met name NFS en DFS. Houd er rekening mee dat elke UNIX-server tegelijkertijd NFS- en SMB-services kan bieden (evenals NCP en AFP) en dus extra flexibiliteit biedt bij het bouwen van uw netwerkinfrastructuur.
Ondanks de verscheidenheid aan UNIX-netwerkbestandssystemen, zijn de onbetwiste leiders NFS (Network File System) en SMB (Service Message Block). Dit artikel gaat in op de mogelijkheden van NFS. Tegelijkertijd zijn we van plan om in een van de volgende nummers de kenmerken van het MKB-werk op het UNIX-platform te bespreken en in de eerste plaats het Samba-product, dat zichzelf goed heeft bewezen in UNIX/Windows-netwerken.
NFS-VERSIES
De eerste implementatie van NFS werd in 1985 ontwikkeld door Sun Microsystems. Sindsdien is NFS wijdverbreid in de UNIX-wereld, met tientallen miljoenen installaties. Naast UNIX heeft het NFS-systeem als serverplatform toepassing gevonden in de VMS-, MVS- en zelfs Windows-besturingssystemen.
NFS is het oorspronkelijke bestandssysteem voor UNIX en volgt als geen ander de logica van UNIX-bestandsbewerkingen. Dit is van toepassing op bestandsnaamruimte en machtigingen. Bovendien is NFS-ondersteuning standaard ingebouwd in de kernel van alle populaire versies van UNIX-achtige besturingssystemen.
NFS is momenteel in zijn tweede en derde versie (de eerste versie van NFS is nooit op de markt gekomen). Ondanks een aantal beperkingen is NFS v2 erg populair; zij is het die is opgenomen in de gratis distributie van UNIX (in het bijzonder Linux), evenals een aantal commerciële UNIX.
Versie 3 van NFS is halverwege de jaren negentig gezamenlijk ontwikkeld door Sun, IBM, Digital en anderen om de prestaties, beveiliging en het beheer van het netwerkbestandssysteem te verbeteren. NFS v3 is achterwaarts compatibel met de vorige NFS-specificatie, wat betekent dat een NFS v3-server meer aankan dan NFS-clients v3, maar ook NFS v2-clients.
Ondanks zijn vrij lange aanwezigheid op de markt, is NFS v3 nog steeds inferieur aan NFS v2 wat betreft het aantal installaties. Op basis van deze overwegingen zullen we ons eerst concentreren op de belangrijkste kenmerken van NFS v2 en vervolgens kijken naar de innovaties in de derde versie van NFS.
Merk op dat specifieke implementaties van dezelfde versie van NFS enigszins van elkaar kunnen verschillen. De verschillen hebben in de eerste plaats betrekking op de samenstelling van daemons, hun namen, locatie en de naam van de NFS-configuratiebestanden. Bovendien zijn NFS-implementaties afhankelijk van de mogelijkheden en functies van UNIX zelf. NFS v2 ondersteunt bijvoorbeeld ACL's, maar alleen op smaken van UNIX waar dergelijke ondersteuning in de kernel is ingebouwd. Daarom zullen we bij het beschrijven van NFS het meest algemene geval beschouwen.
NFS V2-PROTOCOLLEN
Figuur 1 toont het NFS v2-netwerkmodel in overeenstemming met het OSI-referentiemodel. In tegenstelling tot de meeste TCP/IP-netwerkdiensten, gebruikt NFS expliciet presentatie- en sessieprotocollen. NFS is gebaseerd op het concept van Remote Procedure Call (RPC). Volgens dit concept, wanneer toegang tot externe bron(bijvoorbeeld naar een bestand) een programma op lokale computer voert een normale systeemaanroep uit (stel een aanroep van een functie om een bestand te openen), maar in werkelijkheid wordt de procedure op afstand uitgevoerd - op de bronserver. In dit geval kan het gebruikersproces niet bepalen hoe de oproep wordt gedaan - lokaal of op afstand. Nadat is vastgesteld dat een proces toegang heeft tot een bron op een externe computer die als server fungeert, pakt de kernel of een speciale systeemdaemon de argumenten van de procedure samen met zijn identifier in netwerk pakket, opent een communicatiesessie met de server en verzendt dit pakket ernaar. De server pakt het ontvangen pakket uit, bepaalt de gevraagde procedure en argumenten en voert vervolgens de procedure uit. Vervolgens stuurt de server de retourcode van de procedure naar de client en de client geeft deze door aan het gebruikersproces. RPC is dus volledig compatibel met: sessie niveau OSI-modellen.
Een terechte vraag rijst: waarom heeft het NFS-netwerkmodel een speciaal protocol op presentatieniveau nodig? Het punt is dat Sun voorzichtig rekende op het gebruik van NFS in heterogene netwerken, waar computers verschillende systeemarchitecturen hebben, inclusief verschillende bytevolgorde in het machinewoord, verschillende drijvende-komma-representaties, incompatibele structuuruitlijningsgrenzen, enz. Aangezien het RPC-protocol veronderstelt de overdracht van procedureargumenten, dat wil zeggen gestructureerde gegevens, de aanwezigheid van een protocol op presentatieniveau is een absolute must in een heterogene omgeving. Dit is het eXternal Data Representation (XDR)-protocol. Het beschrijft de zogenaamde canonieke vorm van datarepresentatie, die niet afhankelijk is van de systeemarchitectuur van de processor. Bij het verzenden van RPC-pakketten zet de client de lokale gegevens om in canonieke vorm, en de server doet het tegenovergestelde. Er moet rekening mee worden gehouden dat canonieke vorm XDR voldoet aan de gegevensrepresentatie die is geaccepteerd voor de SPARC- en Motorola-processorfamilies. Op servers waar een vergelijkbare vorm van gegevenspresentatie is geïmplementeerd, kunt u hierdoor enig (zij het hoogstwaarschijnlijk microscopisch) prestatievoordeel behalen ten opzichte van concurrenten in geval van intensieve toegang tot de bestandsserver.
In NFS v2 werd UDP gekozen als transportprotocol. De ontwikkelaars schrijven dit toe aan het feit dat de RPC-sessie van korte duur is. Bovendien, vanuit het oogpunt van het uitvoeren van procedures op afstand, is elk RPC-pakket op zichzelf staand, dat wil zeggen dat elk pakket volledige informatie bevat over wat er op de server moet worden gedaan, of over de resultaten van de procedure. RPC-services houden de status van de verbinding meestal niet bij (zonder verbinding), dat wil zeggen dat de server geen informatie opslaat over welke clientverzoeken in het verleden zijn verwerkt: bijvoorbeeld waar in een bestand de client gegevens van de laatste keer heeft gelezen . Voor een netwerkbestandssysteem is dit een absoluut voordeel in termen van betrouwbaarheid, aangezien de client de bestandsbewerkingen onmiddellijk na het opnieuw opstarten van de server kan voortzetten. Maar dit schema is beladen met problemen bij het schrijven en vergrendelen van bestanden, en om ze te omzeilen, werden de NFS-ontwikkelaars gedwongen om verschillende tijdelijke oplossingen te gebruiken (het gebruik van UDP creëert nog een reeks specifieke problemen, maar we zullen ze later bespreken).
Een belangrijk verschil tussen de NFS RPC-services en andere netwerkserverservices is dat ze geen gebruik maken van de inetd super daemon. Gewone netwerkdiensten zoals telnet of rlogin worden meestal niet als daemons gestart bij het opstarten van het systeem, hoewel dit niet verboden is. Meestal gebruiken ze de zogenaamde inetd super daemon, die "luistert" naar softwarepoorten. TCP-protocollen en UDP. Services worden gespecificeerd in het super daemon configuratiebestand (meestal /etc/inetd.conf). Wanneer een clientverzoek voor een programmapoort wordt ontvangen, start inetd de bijbehorende netwerkdienst(bijvoorbeeld in.rlogin), die het verzoek verwerkt.
RPC-services gebruiken de inetd super daemon niet omdat, zoals gezegd, een RPC-sessie van zeer korte duur is, in feite slechts voor de duur van een enkel verzoek. Dat wil zeggen dat inetd voor elk verzoek een nieuw kind-RPC-serviceproces zou moeten starten, wat erg duur is voor UNIX. Om soortgelijke redenen kan het RPC-proces geen nieuwe processen voortbrengen en kan het niet meerdere verzoeken tegelijk verwerken. Om de prestaties te verbeteren, worden RPC-services daarom uitgevoerd als meerdere, gelijktijdig draaiende daemon-instanties. Bovendien is het aantal instances van een bepaalde daemon niet direct gerelateerd aan het aantal clients. Zelfs één daemon kan veel clients bedienen, maar het kan één verzoek tegelijk afhandelen, de rest wordt in de wachtrij geplaatst.
Een ander belangrijk verschil tussen RPC-services en reguliere netwerkservices is dat ze geen vooraf gedefinieerde UDP-softports gebruiken. In plaats daarvan wordt het zogenaamde portmapper-systeem gebruikt. Om dit te ondersteunen, wordt tijdens het opstarten een speciale portmap-daemon geïnitialiseerd. Binnen het poortvertaalsysteem wordt aan elke RPC-service een programmanummer, versienummer, procedurenummer en protocol (UDP of TCP) toegewezen. Het programmanummer identificeert op unieke wijze een specifieke RPC-service. De relatie tussen RPC-servicenamen en programmanummers kan worden afgeleid uit de inhoud van de /etc/rpc. Elk RPC-programma ondersteunt veel routines, die worden geïdentificeerd door hun nummer. Procedurenummers zijn te vinden in de corresponderende header-bestanden: voor een NFS-service worden ze bijvoorbeeld gespecificeerd in het bestand /usr/include/nfs/nfs.h.
De NFS-service heeft met name programmanummer 100003 en omvat procedures zoals "een bestand openen", "een blok lezen", "een bestand maken", enz. Bij het aanroepen van externe procedures wordt het serviceprogrammanummer doorgegeven samen met de procedureargumenten in het RPC-pakket, het procedurenummer en het versienummer. Het versienummer wordt gebruikt om de mogelijkheden van de service te identificeren. Het feit is dat de ontwikkelaars de NFS-service voortdurend verbeteren en dat elke nieuwe versie volledig achterwaarts compatibel is met de vorige.
Het werkingsprincipe van de portmap-vertaler is vrij eenvoudig. Wanneer een RPC-service wordt geïnitialiseerd (met name wanneer het besturingssysteem opstart), wordt deze geregistreerd met behulp van de portmap-daemon. Bij het starten op de server zoekt de RPC-service naar een onbezette programmapoort, reserveert deze en rapporteert het poortnummer aan de portmap-daemon. Om met de server te kunnen communiceren, moet de RPC-client eerst naar de poortkaart van de server gaan en de server vragen welke softwarepoort een bepaalde RPC-service op de server gebruikt. Alleen dan kan de klant rechtstreeks contact opnemen met de dienst. In sommige gevallen communiceert de client indirect met de gewenste service, dat wil zeggen dat hij eerst de portmap-daemon benadert en die daemon namens de client de RPC-service aanvraagt. In tegenstelling tot RPC-services is de portmap-vertaler altijd gebonden aan de vooraf gedefinieerde poort 111, dus de client communiceert op de standaard manier met portmap.
NFS V2 SAMENSTELLING
In het algemeen bevat de NFS-server naast portmap de daemons rpc.mountd, nfsd, rpc.lockd, rpc.statd. De daemons biod (optioneel), rpc.lockd en rpc.statd moeten draaien op een NFS-clientcomputer die op een UNIX-platform draait.
Zoals eerder vermeld, is UNIX-ondersteuning voor NFS op kernelniveau, dus niet alle daemons zijn nodig, maar ze kunnen de prestaties van bestandsbewerkingen aanzienlijk verbeteren en bestandsvergrendeling bij schrijven mogelijk maken.
De rpc.mountd-daemon verwerkt clientverzoeken om bestandssystemen te koppelen. De mount-service is geïmplementeerd als een afzonderlijke daemon, aangezien het mount-protocol geen deel uitmaakt van NFS. De reden hiervoor is dat de mount-bewerking nauw verbonden is met de syntaxis van bestandsnamen, en de principes van bestandsnaamgeving verschillen voor UNIX en bijvoorbeeld voor VMS.
De nfsd-daemon accepteert en bedient NFS RPC-verzoeken. Doorgaans worden meerdere exemplaren van nfsd op de server uitgevoerd om de prestaties te verbeteren.
De rpc.lockd-daemon, die zowel op de client als op de server draait, is ontworpen om bestanden te vergrendelen, terwijl de rpc.statd-daemon (die ook op de server en op de client wordt uitgevoerd) vergrendelingsstatistieken bijhoudt voor het geval ze automatisch moeten worden hersteld als de NFS-service crasht.
De biod-daemon die op de client draait, is in staat tot zowel read-ahead- als lazy-write-bewerkingen, wat de prestaties drastisch kan verbeteren. De aanwezigheid van biod is echter niet vereist om de klant te laten werken. Om de prestaties verder te verbeteren, kunnen meerdere biod-daemons op de clientcomputer worden geladen.
Een andere daemon die op de server draait, is verantwoordelijk voor authenticatie en afdrukservice voor DOS / Windows-clients, op sommige systemen heet het pcnfsd, op andere wordt het in.pcnfsd genoemd.
Bovendien wordt NFS geleverd met verschillende systeemhulpprogramma's en diagnostische programma's (showmount, rpcinfo, exportfs, nfsstat).
EXPORTREGELS
De bestandssystemen en mappen die clients op afstand op de NFS-server kunnen aankoppelen, moeten expliciet worden gespecificeerd. Deze procedure wordt in NFS bronnen "exporteren" genoemd. Tegelijkertijd zendt een NFS-server, in tegenstelling tot bijvoorbeeld een SMB-server, zijn lijst met geëxporteerde bronnen niet uit. De client kan een dergelijke lijst echter opvragen bij de server. Aan de serverkant is de rpc.mountd-daemon verantwoordelijk voor het afhandelen van aankoppelverzoeken.
Het exporteren van NFS-bestandsshares volgt vier basisregels.
- Het bestandssysteem kan als geheel of in delen worden geëxporteerd, dit zijn mappen en bestanden. Houd er echter rekening mee dat het bestandssysteem de grootste geëxporteerde eenheid is. Als op de server een bepaald bestandssysteem (/ usr / bin) in een hiërarchie onder een ander bestandssysteem (/ usr) is aangekoppeld, heeft het exporteren van het / usr-systeem geen invloed op het / usr / bin-systeem.
- U kunt alleen lokale bestandsbronnen exporteren, met andere woorden, als een vreemd bestandssysteem op de server is aangekoppeld, dat wil zeggen, zich op een andere server bevindt, kan het niet opnieuw worden geëxporteerd.
- U kunt geen submappen exporteren van een reeds geëxporteerd bestandssysteem, tenzij het afzonderlijke bestandssystemen zijn.
- U kunt de bovenliggende mappen van een reeds geëxporteerde map niet exporteren, tenzij de bovenliggende map een onafhankelijk bestandssysteem is.
Elke overtreding van deze regels zal ertoe leiden dat NFS niet goed werkt.
De geëxporteerde resourcetabel bevindt zich in het bestand / etc / exports. Helaas is de syntaxis voor dit bestand UNIX-specifiek, dus we nemen Solaris als voorbeeld. Het bestand / etc / exports bestaat uit tekstregels in het formaat:
Enkele van de meer populaire opties staan vermeld in Tabel 1. In feite beschrijven opties de toegangsrechten van clients tot geëxporteerde bronnen. Het is belangrijk om te onthouden dat de machtigingen die tijdens het exporteren worden vermeld op geen enkele manier de machtigingen overschrijven die rechtstreeks van kracht zijn op het bestandssysteem. Als het bestandssysteem bijvoorbeeld als beschrijfbaar wordt geëxporteerd en een bepaald bestand is alleen-lezen, dan is het niet mogelijk om het te wijzigen. Bij het exporteren fungeren de toegangsrechten dus als een extra filter. Bovendien, als, laten we zeggen, het bestandssysteem wordt geëxporteerd met de ro (alleen lezen) optie, dan heeft de client het recht om het te mounten met de rw (lezen / schrijven) optie, maar een poging om te schrijven zal resulteren in een foutmelding .
Met de toegangsoptie kunt u hosts specificeren met het recht om de resource te koppelen. Dienovereenkomstig heeft geen enkele andere host, behalve degene die erin wordt genoemd, de mogelijkheid om de resource te mounten en daarom bewerkingen uit te voeren.
De lijst met hosts die informatie kunnen schrijven, wordt gespecificeerd met behulp van de rw-optie. Als de lijst met hosts niet is gespecificeerd in de rw-optie, kan elke host schrijven.
Met de root-optie kunt u de hosts specificeren waar de lokale root-superusers serverroot-privileges krijgen op de geëxporteerde bron. Anders, zelfs als de host rw-rechten krijgt, is de rootgebruiker erop gelijk aan de niemand (uid = -2) gebruiker, dat wil zeggen, aan de gebruiker met de minste toegangsrechten. Het bovenstaande verwijst specifiek naar de toegangsrechten tot de externe bron en heeft geen invloed op de toegangsrechten tot de lokale bronnen van de client.
De anon- en beveiligde opties worden behandeld bij het beschrijven van het NFS-authenticatieschema.
MONTAGE REGELS
Hoewel geëxporteerde bronnen kunnen fungeren als een bestandssysteem of een aparte map voor de server, zien ze er voor de client altijd uit als bestandssystemen. Omdat NFS-ondersteuning is ingebouwd in de UNIX-kernel, wordt de bewerking van het mounten van NFS-bestandssystemen uitgevoerd door het standaard mount-hulpprogramma (een aparte daemon voor NFS-mounting is niet vereist), terwijl het alleen nodig is om te bepalen dat het te mounten bestandssysteem is NFS. Een andere manier om te mounten is met het / etc / fstab bestand (/ etc / bestandssystemen op sommige UNIX-versies). V in dit geval externe NFS-systemen (evenals lokale) worden aangekoppeld in de opstartfase van het besturingssysteem. Aankoppelpunten kunnen elk zijn, ook als onderdeel van andere NFS-bestandssystemen, dat wil zeggen, NFS-systemen kunnen op elkaar worden "geregen".
De belangrijkste NFS-mount-opties staan vermeld in Tabel 2.
De bg-optie maakt montage op de achtergrond mogelijk, in welk geval andere mount-commando's kunnen worden uitgevoerd.
Een paar harde / zachte opties lijken best interessant. Bij een "harde" koppeling zal de client koste wat kost proberen het bestandssysteem te mounten. Als de server niet beschikbaar is, zal dit ertoe leiden dat de hele NFS-service lijkt te bevriezen: processen die toegang hebben tot het bestandssysteem, gaan in een staat van wachten op de voltooiing van RPC-verzoeken. Vanuit het oogpunt van gebruikersprocessen zal het bestandssysteem verschijnen als een zeer trage lokale schijf. Wanneer de server weer online wordt gebracht, blijft de NFS-service functioneren alsof er niets is gebeurd. Als u de optie intr gebruikt, kunt u gebruiken systeem signaal INTERRUPT om het harde mount-proces af te breken.
In een soft-mount zal de NFS-client verschillende pogingen doen om verbinding te maken met de server zoals gespecificeerd in de retans- en timeo-opties (sommige systemen ondersteunen ook een speciale retry-optie). Als de server niet reageert, geeft het systeem een foutmelding en stopt met proberen te koppelen. Vanuit het oogpunt van de logica van bestandsbewerkingen, emuleert een soft mount een storing van een lokale schijf wanneer een server uitvalt. Als de optie retrans (opnieuw proberen) niet is opgegeven, is het aantal nieuwe pogingen beperkt tot de standaardwaarde voor het gegeven UNIX-systeem. De retrans- en timeo-opties zijn niet alleen van toepassing op mounts, maar op alle RPC-bewerkingen die worden uitgevoerd op het NFS-bestandssysteem. Dat wil zeggen, als de client een schrijfbewerking uitvoert en er treedt op dat moment een storing op in het netwerk of op de server, dan zal de client proberen de verzoeken te herhalen.
De vraag welke van de regimes, "zacht" of "hard" beter is, kan niet eenduidig worden beantwoord. Als de gegevens op de server consistent moeten zijn wanneer deze tijdelijk uitvalt, heeft een "harde" mount de voorkeur. Deze modus is ook onvervangbaar in gevallen waarin de aangekoppelde bestandssystemen programma's en bestanden bevatten die essentieel zijn voor de werking van de client, in het bijzonder voor schijfloze machines. In andere gevallen, vooral als het gaat om alleen-lezen systemen, heeft soft mount de voorkeur.
AUTHENTICATIE EN VEILIGHEID
Zoals opgemerkt, staat elk RPC-pakket op zichzelf. Bovendien biedt NFS in het algemeen geen staatscontrole, dat wil zeggen, het houdt niet bij welke verzoeken eerder door klanten zijn gedaan, en houdt ook geen klantactiviteit bij. Daarom is het beveiligingsprobleem in systemen waar RPC wordt gebruikt uiterst urgent.
In NFS wordt authenticatie uitsluitend uitgevoerd in het stadium van het koppelen van het bestandssysteem en alleen op basis van de domeinnaam (of IP-adres) van de clientcomputer. Dat wil zeggen, als een NFS-client (hier bedoelen we een computer, geen computergebruiker) contact maakt met de server met een koppelverzoek, bepaalt de server de toegangsrechten uit de / etc / exports-tabel, terwijl de client wordt geïdentificeerd door de naam ( IP-adres) van de computer. Als de klant bepaalde bewerkingen op de geëxporteerde bron mag uitvoeren, krijgt hij een bepaald "magisch nummer" (magische cookie) te horen. In de toekomst moet de klant dit nummer opnemen in elk RPC-verzoek om zijn bevoegdheid te valideren.
Dat is in feite de hele eenvoudige set clientauthenticatietools, gebruikers worden op geen enkele manier geverifieerd. Elk RPC-verzoek bevat echter de uid van de gebruiker die het verzoek heeft geïnitieerd en een lijst van de gid waartoe de gebruiker behoort. Maar deze identifiers worden niet gebruikt voor authenticatie, maar om de toegangsrechten van een bepaalde gebruiker tot bestanden en mappen te bepalen.
Merk op dat uid en gid aan de clientzijde zijn gedefinieerd, niet aan de serverzijde. Daarom worden beheerders geconfronteerd met het probleem van het afstemmen van de inhoud van / etc / passwd (en / etc / groep) tussen clients en NFS-servers, zodat de gebruiker Vasya op de server niet de rechten van de gebruiker Petit krijgt. Dit levert ernstige problemen op voor grote netwerken. U kunt het netwerk gebruiken informatie Service(Network Information System, NIS), ontwikkeld door Sun in 1985 en opgenomen in de meeste versies van UNIX (de meer geavanceerde versie van NIS + is niet wijdverbreid gebruikt). NIS is een informatieservice die sterk lijkt op de Windows NT-directoryservice en waarmee u centraal kunt opslaan en verwerken systeembestanden... Trouwens, NIS is gebouwd op hetzelfde principe als NFS, in het bijzonder gebruikt het de RPC- en XDR-protocollen.
Een ander belangrijk kenmerk van NFS is dat elk RPC-verzoek een lijst met de gid-groepen van de gebruiker bevat. Om de grootte van het RFC-pakket te beperken, zijn de meeste NFS-implementaties beperkt tot groepen van 8 of 16. Als de gebruiker lid is van meer groepen, kan dit leiden tot fouten bij het bepalen van de toegangsrechten op de server. Dit probleem is zeer relevant voor bedrijfsbestandsservers. De radicale oplossing is om ACL's te gebruiken, maar helaas ondersteunen niet alle UNIX-smaken ze.
Het NFS-authenticatiesysteem is slecht en biedt geen betrouwbare beveiliging. Iedereen die met NFS heeft gewerkt, weet hoe hij het beveiligingssysteem gemakkelijk kan omzeilen. Om dit te doen, is het niet eens nodig om methoden te gebruiken om IP-adressen (IP-spoofing) of namen (DNS-spoofing) te vervalsen. Het is voldoende voor een aanvaller om het "magische getal" te onderscheppen, en in de toekomst kan hij namens de klant acties uitvoeren. Bovendien verandert het "magische nummer" pas bij de volgende herstart van de server.
Op tal van internetservers kun je andere, waaronder zeer exotische, manieren leren om NFS te hacken. Het aantal ontdekte gaten loopt in de duizenden. Daarom wordt aanbevolen om NFS v.2 alleen binnen beveiligde netwerken te gebruiken.
Met deze overwegingen in gedachten heeft Sun het SecureRPC-protocol ontwikkeld met zowel asymmetrische als symmetrische coderingssleutels. In dit geval worden cryptografische methoden gebruikt om niet alleen hosts, maar ook gebruikers te authenticeren. De gegevens zelf zijn echter niet versleuteld. Helaas worden vanwege exportbeperkingen van de Amerikaanse overheid niet alle UNIX geleverd met SecureRPC-ondersteuning. Daarom zullen we niet ingaan op de mogelijkheden van dit protocol. Als uw versie van UNIX echter SecureRPC ondersteunt, zal Hal Stein's boek "Managing NFS and NIS" door O "Reilly & Associates van onschatbare waarde zijn bij het opzetten ervan.
Een ander probleem houdt verband met NFS-clients op MS-DOS- en Windows 3.x / 9x-platforms. Deze systemen zijn voor één gebruiker en kunnen niet worden geverifieerd met normale NFS-tools. Voor de authenticatie van DOS / Windows-gebruikers wordt de pcnfsd-daemon op de server gestart. Bij het aansluiten (aankoppelen) van NFS-schijven op een clientcomputer, wordt om een gebruikersnaam en wachtwoord gevraagd, waarmee niet alleen gebruikers kunnen worden geïdentificeerd, maar ook kunnen worden geverifieerd.
Hoewel Windows NT multi-user is, zijn de gebruikersdatabase en het gebruikersauthenticatieschema niet compatibel met UNIX. Daarom worden op Windows NT gebaseerde NFS-clients gedwongen om ook te profiteren van de mogelijkheden van pcnfsd.
Naast gebruikersauthenticatie maakt pcnfs het afdrukken naar UNIX mogelijk vanaf DOS/Windows-clientlocaties. Toegegeven, Windows NT bevat in eerste instantie het programma LPR.EXE, waarmee ook op UNIX-servers kan worden afgedrukt.
Om toegang te krijgen tot de bestandsservice en de NFS-service op DOS / Windows-machines, moet u speciale clientsoftware installeren en de prijzen voor deze producten zijn erg hoog.
Laten we echter teruggaan naar de opties voor het exporteren van NFS-bestanden (zie Tabel 1). De anon-optie specificeert de uid voor de gebruiker wanneer de DOS / Windows-gebruiker zichzelf niet kon authenticeren (het verkeerde wachtwoord instellen) of wanneer de gebruiker op de host verbonden via SecureRPC niet was geverifieerd. Standaard heeft anon uid = -2.
De beveiligde optie is van toepassing bij gebruik van het SecureRPC-protocol.
ARCHITECTURALE KENMERKEN van NFS V2
NFS-bestandssystemen moeten aan twee voorwaarden voldoen (trouwens, dezelfde vereisten gelden niet alleen voor NFS, maar ook voor andere netwerkbestandssystemen).
- Vanuit het oogpunt van clientgebruikersprogramma's bevindt het NFS-bestandssysteem zich als het ware op een lokale schijf. Programma's kunnen NFS-bestanden niet onderscheiden van gewone bestanden.
- De NFS-client kan niet bepalen welk platform als server wordt gebruikt. Het kan UNIX, MVS en zelfs Windows NT zijn. Verschillen in serverarchitectuur hebben alleen invloed op het niveau van specifieke bewerkingen, en niet met betrekking tot de mogelijkheden van NFS. Voor klant bestandsstructuur NFS is vergelijkbaar met een lokaal systeem.
Het eerste niveau van transparantie wordt bereikt door het gebruik van een virtueel bestandssysteem (VFS) in UNIX. VFS is niet alleen verantwoordelijk voor de communicatie met NFS, maar ook met lokale systemen zoals UFS, ext2, VxFS, enz.
Het tweede niveau van transparantie wordt verschaft door het gebruik van zogenaamde virtuele knooppunten (vnodes), waarvan de structuur kan worden gecorreleerd met inodes in UNIX-bestandssystemen.
Bewerkingen op NFS-bestandssystemen zijn VFS-bewerkingen, terwijl interacties op individuele bestanden en mappen worden bepaald door vnode-bewerkingen. Het RPC-protocol van NFS v2 beschrijft 16 procedures die niet alleen betrekking hebben op bewerkingen op bestanden en mappen, maar ook op hun attributen. Het is belangrijk om te begrijpen dat RPC-aanroepen en de vnode-interface verschillende concepten zijn. De vnode-interfaces definiëren de OS-services voor toegang tot bestandssystemen, zowel lokaal als extern. NFS RPC is een specifieke implementatie van een van de vnode-interfaces.
Lees-/schrijfbewerkingen worden aan de clientzijde in de cache opgeslagen, dat wil zeggen dat de client de inhoud van bestanden en mappen in de cache opslaat. De typische NFS-cachebuffergrootte is 8 KB. Als de biod-daemons op de client draaien, wordt het lezen van tevoren uitgevoerd en wordt het schrijven in de uitgestelde modus uitgevoerd. Als een gebruikersproces bijvoorbeeld informatie schrijft, worden de gegevens verzameld in de cachebuffer en pas daarna verzonden, meestal in een enkel RPC-pakket. Op het moment van de schrijfbewerking geeft de kernel onmiddellijk de controle terug aan het proces en worden de functies voor het doorsturen van RPC-verzoeken overgedragen aan biod. Als de biod-daemons niet draaien en de kernel geen multithreaded RPC-verwerking ondersteunt, dan zou de kernel verantwoordelijk moeten zijn voor het verzenden van RPC-pakketten in single-threaded-modus, en het gebruikersproces komt in de wachtstatus voor het einde van de overdracht. Maar in dit geval is de NFS-cache nog steeds in gebruik.
Naast de inhoud van NFS-bestanden en -mappen, worden bestands- en mapkenmerken aan de clientzijde in de cache opgeslagen en wordt de kenmerkcache periodiek vernieuwd (meestal om de paar seconden). Dit komt door het feit dat de waarde van de attributen kan worden gebruikt om de status van een bestand of directory te beoordelen. Laten we deze aanpak uitleggen aan de hand van een voorbeeld. Wanneer een gebruiker een leesbewerking uitvoert vanuit een bestand, wordt de inhoud van het bestand in de NFS-cache geplaatst, maar tegelijkertijd worden de bestandsattributen (tijdstip van aanmaak/update, grootte, enz.) in de attributencache geplaatst. Als op dit moment een andere client naar hetzelfde bestand schrijft, kan dit leiden tot inconsistenties in de inhoud in de caches van verschillende clients. Aangezien de eerste client de attributencache om de paar seconden ververst, kan hij echter vaststellen dat de attributen zijn gewijzigd (in dit geval de tijd dat het bestand is bijgewerkt), dus moet de client een bewerking uitvoeren om de bestandsinhoudcache te vernieuwen (deze handeling wordt automatisch uitgevoerd).
De nfsd-daemons moeten op de server draaien om clientverzoeken te kunnen verwerken. In dit geval slaan de daemons informatie op in de cache bij het lezen van de serverschijven. Alle daemons bedienen dezelfde wachtrij voor clientverzoeken, wat een optimaal gebruik van processorbronnen mogelijk maakt.
Helaas is het erg moeilijk om het optimale aantal biod- en nfsd-daemons te bepalen. Aan de ene kant, hoe meer daemons draaien, hoe meer verzoeken tegelijkertijd kunnen worden verwerkt; aan de andere kant kan het verhogen van het aantal daemons de systeemprestaties negatief beïnvloeden vanwege de verhoogde overhead van schakelprocessen. NFS tweaken is een vervelende procedure en vereist niet alleen het aantal clients en gebruikersprocessen, maar ook kenmerken zoals schakeltijden tussen procescontexten (d.w.z. processorarchitectuurkenmerken), RAM-grootte, systeembelasting, enz. Het is beter om te bepalen dergelijke instellingen experimenteel, hoewel in de meeste gevallen de standaardinstellingen zullen werken (meestal worden 8 nfsd-daemons op de server gestart en 4 biod-daemons op clients).
| Afbeelding 2. NFS v2-schrijfbewerking. |
Heel belangrijk kenmerk NFS v2 is dat schrijfbewerkingen aan de serverzijde niet in de cache worden opgeslagen (zie afbeelding 2). Dit werd gedaan om de hoge betrouwbaarheid van de NFS-service te waarborgen en om de integriteit van de gegevens te waarborgen na een server-reboot in het geval van een serverstoring. Het gebrek aan caching van informatie tijdens het schrijven is het meest groot probleem NFS v2. Bij schrijfbewerkingen is NFS aanzienlijk inferieur aan concurrerende technologieën, hoewel het er bij leesbewerkingen weinig aan verliest. De enige manier om slechte schrijfprestaties te bestrijden, is door schijfsubsystemen te gebruiken met een stroomonafhankelijke ingebouwde cache, zoals het geval is bij vrij dure RAID-arrays.
Bij het werken in gedistribueerde en wereldwijde netwerken heeft NFS v2 nog een nadeel vanwege de keuze voor UDP als het transportprotocol voor de service. Zoals u weet, garandeert UDP de bezorging van pakketten niet; bovendien komt de volgorde waarin pakketten worden ontvangen mogelijk niet overeen met de volgorde waarin ze worden verzonden.
Dit kan leiden tot de volgende twee onaangename gevolgen: pakketverlies en een lange vertraging in de verwerking ervan. Stel je voor dat een klant een groot bestand aan het lezen is. In dit geval moet de server meerdere pakketten verzenden om de cachebuffer van de client te vullen. Als een van de pakketten verloren gaat, wordt de client gedwongen het verzoek opnieuw te herhalen en moet de server antwoorden genereren, enz.
De situatie van vertraging bij het verwerken van RPC-verzoeken als gevolg van bijvoorbeeld hoge serverbelasting of netwerkproblemen is ook behoorlijk onaangenaam. Als de gespecificeerde tijdslimiet wordt overschreden, zal de client van mening zijn dat het pakket verloren is gegaan en zal hij proberen het verzoek opnieuw te proberen. Dit is voor veel NFS-bewerkingen geen probleem, omdat zelfs de schrijfbewerking door de server kan worden herhaald. Maar hoe zit het met bewerkingen zoals "directory verwijderen" of "bestand hernoemen"? Gelukkig ondersteunen de meeste NFS-implementaties server-side dubbele aanvraagcaching. Als de server binnen korte tijd een herhaald verzoek voor een bewerking ontvangt, wordt een dergelijk verzoek genegeerd.
Het RPC-systeem houdt de status van de verbinding niet bij, wat problemen veroorzaakt wanneer meerdere clients tegelijkertijd toegang hebben tot hetzelfde bestand. Er zijn hier twee complicaties:
- hoe een bestand te vergrendelen, in het bijzonder wanneer er naar wordt geschreven;
- hoe de integriteit van de sloten te waarborgen in het geval van een NFS-server of client crash en opnieuw opstarten?
Om dit te doen, gebruikt NFS twee speciale daemons: rpc.lockd is verantwoordelijk voor het vergrendelen van bestanden en rpc.statd is verantwoordelijk voor het bewaken van de status van vergrendelingen (zie figuur 3). Deze daemons draaien zowel aan de client- als aan de serverkant. Aan de daemons rpc.lockd en rpc.statd zijn twee speciale mappen toegewezen (sm en sm.bak), waar informatie over sloten wordt opgeslagen.
Een eigenaardige en vrij handige extra service automounter stelt je in staat om automatisch bestandssystemen te mounten wanneer gebruikersprocessen er toegang toe hebben. In de toekomst probeert de automounter periodiek (standaard elke vijf minuten) het systeem te ontkoppelen. Als het druk is (er staat bijvoorbeeld een bestand open), dan blijft de dienst werken in normale modus... Als het bestandssysteem niet langer wordt gebruikt, wordt het automatisch ontkoppeld. De automounter-functie implementeert verschillende programma's, de meest populaire zijn amd en autofs.
NFS V3-FUNCTIES
De derde versie van NFS is volledig achterwaarts compatibel met de tweede versie, dat wil zeggen, de NFS v3-server "begrijpt" NFS v2- en NFS v3-clients. Evenzo kan een NFS v3-client toegang krijgen tot een NFS v2-server.
Een belangrijke innovatie in NFS v3 is de ondersteuning van het TCP-transportprotocol. UDP is geweldig voor LAN's, maar niet goed voor langzame en niet altijd betrouwbare WAN's. In NFS v3 wordt al het clientverkeer gemultiplext in een enkele TCP-verbinding.
In NFS v3 wordt de cachebuffer vergroot tot 64K, wat een gunstig effect heeft op de prestaties, vooral gezien het actieve gebruik van snelle netwerktechnologieën Fast Ethernet, Gigabit Ethernet en ATM. Bovendien kunt u met NFS v3 informatie op de client opslaan, niet alleen in RAM, maar ook op de lokale schijf van de client (om eerlijk te zijn moet worden opgemerkt dat sommige NFS v2-implementaties deze mogelijkheid ook bieden). Deze technologie staat bekend als CacheFS.
| Afbeelding 4. NFS v3-schrijfbewerking. |
Maar misschien kan een nog belangrijkere innovatie in NFS v3 worden beschouwd als een radicale verbetering van de prestaties bij schrijfbewerkingen. Nu wordt het cachen van de opgenomen informatie ook uitgevoerd aan de serverzijde, terwijl registratie en bevestiging van het schrijven van gegevens naar schijf worden uitgevoerd met behulp van een speciaal commit-verzoek (zie figuur 4). Deze technologie wordt veilig asynchroon schrijven genoemd. Nadat de gegevens naar de servercache zijn verzonden, stuurt de client deze een commit-verzoek, waarmee een schrijfbewerking naar de serverschijf wordt gestart. Op zijn beurt, wanneer de informatie naar de schijf wordt geschreven, stuurt de server de client een bevestiging van de succesvolle voltooiing ervan.
Nieuw in NFS v3 is ondersteuning voor 64-bit bestandssystemen en verbeterde ondersteuning voor ACL's.
Vooruitblikkend, promoot Sun nu WebNFS, waarmee bestandssystemen toegankelijk zijn vanuit elke webbrowser of Java-applicaties. In dit geval hoeft er geen clientsoftware te worden geïnstalleerd. WebNFS is (volgens Sun) drie tot vijf keer sneller dan ftp of HTTP.
GEVOLGTREKKING
De beheerder kent de principes van de NFS-protocollen en kan de service optimaal configureren. Het netwerkbestandssysteem NFS is ideaal voor UNIX-netwerken, aangezien het bij bijna alle versies van dit besturingssysteem wordt geleverd. Bovendien is NFS-ondersteuning geïmplementeerd op UNIX-kernelniveau. Naarmate Linux geleidelijk begint aan te komen bij desktop computers, dan heeft NFS ook hier een kans om geaccepteerd te worden. Helaas veroorzaakt het gebruik van NFS op Windows-clientcomputers bepaalde problemen die verband houden met de noodzaak om gespecialiseerde en vrij dure clientsoftware te installeren. In dergelijke netwerken lijkt het gebruik van de SMB-service, met name de Samba-software, de voorkeur te hebben. We zullen echter terugkeren naar SMB-producten voor UNIX in een van de dichtstbijzijnde LAN-nummers.
Op dit punt zou u een werkende TCP / IP-verbinding met uw netwerk moeten hebben. U zou andere computers op het netwerk moeten kunnen pingen en als u de gateway dienovereenkomstig hebt geconfigureerd, zou u ook computers op internet moeten kunnen pingen. Zoals u weet, is het belangrijkste doel van het aansluiten van een computer op een netwerk om toegang te krijgen tot informatie. Terwijl sommige mensen een computer zomaar op een netwerk kunnen aansluiten, willen de meeste mensen bestanden en printers delen en openen. Ze willen documenten op internet raadplegen of online games spelen. Geïnstalleerd in uw nieuw systeem Slackware TCP/IP ondersteuning en benodigde software, je krijgt het allemaal; door echter alleen TCP / IP-ondersteuning te installeren, zal de functionaliteit zeer beperkt zijn. Om bestanden te delen en te delen, moeten we ze heen en weer overbrengen via FTP of SCP. We kunnen niet door de bestandsstructuur op onze nieuwe Slackware-computer bladeren via de pictogrammen Netwerkomgeving of Volledig netwerk van Windows-computers. We zouden graag constant toegang willen hebben tot bestanden op andere Unix-machines.
Idealiter zouden we willen gebruiken netwerk bestandssysteem waardoor we transparante toegang hebben tot bestanden op computers. De programma's die we gebruiken om te werken met informatie die op computers is opgeslagen, hoeven niet eens te weten op welke computer het bestand is opgeslagen. Ze hoeven alleen te weten dat het bestand bestaat en de manier om het te krijgen. De rest is al de taak van het besturingssysteem en biedt toegang tot dit bestand met behulp van de beschikbare lokale en netwerkbestandssystemen. De twee meest gebruikte netwerkbestandssystemen zijn SMB (geïmplementeerd via Samba) en NFS.
5.6.1. SMB / Samba / CIFS
Server Message Block (SMB) is een afstammeling van het oudere NetBIOS-protocol dat oorspronkelijk door IBM is ontwikkeld voor hun LAN Manager-product. Microsoft op mijn beurt ben ik altijd geïnteresseerd geweest in NetBIOS en zijn erfgenamen (NetBEUI, SMB en CIFS). Het Samba-project begon in 1991 toen het werd geschreven om communicatie te bieden tussen een IBM-pc en een Unix-server. Tegenwoordig is het delen van bestanden en afdrukservices via een SMB-netwerk de voorkeursmethode voor bijna de hele beschaafde wereld, aangezien Windows dit ook ondersteunt.
Het Samba-configuratiebestand /etc/samba/smb.conf is een van de best gedocumenteerde configuratiebestanden die u kunt vinden. Er zijn kant-en-klare voorbeelden met instellingen voor gedeelde bronnen, zodat u deze kunt bekijken en aanpassen aan uw behoeften. Als je nog meer controle nodig hebt, staat de man-pagina van smb.conf tot je dienst. Aangezien Samba zulke goede documentatie heeft, zullen we het hier niet herschrijven. Laten we echter snel stilstaan bij de belangrijkste punten.
smb.conf is opgesplitst in verschillende secties: één sectie per aandeel, plus één algemene sectie voor het instellen van parameters die overal worden gebruikt. Sommige parameters zijn alleen geldig in de globale sectie en sommige zijn alleen daarbuiten geldig. Onthoud dat de algemene sectie kan worden overschreven door elke andere sectie. Raadpleeg de man-pagina's voor meer informatie.
U zult hoogstwaarschijnlijk uw smb.conf-bestand willen bewerken om uw lokale netwerkinstellingen weer te geven. We raden je aan om onderstaande items te wijzigen:
Dit is de beschrijving van uw Slackware-computer, weergegeven in de map Mijn netwerklocaties (of Alle netwerken).
U zult vrijwel zeker het gebruikersbeveiligingsniveau op uw Slackware-systeem willen gebruiken.
Als wachtwoordcodering niet is ingeschakeld, kunt u Samba niet gebruiken met NT4.0-, Win2k-, WinXP- en Win2003-systemen. Voor eerdere versies van Windows-besturingssystemen, om toegang te verlenen tot: gedeelde bronnen er was geen encryptie vereist.
SMB is een geauthenticeerd protocol, d.w.z. u kunt een gebruikersnaam en wachtwoord opgeven om van deze service te profiteren. We vertellen de samba-server dat de gebruikersnamen en wachtwoorden correct zijn via het smbpasswd-commando. smbpasswd staat toe dat vooraf gedeelde sleutels worden toegevoegd als gewone gebruikers en gebruikersmachines (voor SMB moet u NETBIOS-computernamen toevoegen als gebruikersmachines, waardoor het aantal computers waarop authenticatie kan worden uitgevoerd wordt beperkt).
Het is belangrijk op te merken dat de opgegeven gebruikersnaam of machinenaam al in het /etc/passwd-bestand moet staan. U kunt dit bereiken met het adduser-commando. Merk op dat wanneer u de opdracht adduser gebruikt, u een dollarteken ("$") aan de computernaam moet toevoegen om deze toe te voegen. Echter, dit niet moet worden gedaan bij het werken met smbpasswd. Het hulpprogramma smbpasswd voegt zelf een dollarteken toe. Schending van deze regel door adduser zal resulteren in een fout bij het toevoegen van de hostnaam aan samba.
|
#adduser-machine $ |
5.6.2. Netwerkbestandssysteem (NFS)
NFS (Network File System) is oorspronkelijk geschreven door Sun voor Solaris - hun implementaties Unix-systemen... Hoewel het veel gemakkelijker is om in te stellen en te configureren dan SMB, is NFS veel minder veilig. de belangrijkste zwak punt de veiligheidsfunctie is dat het gemakkelijk is om gebruikers- en groeps-ID's van de ene machine te vervangen door ID's van een andere machine. Authenticatie is niet geïmplementeerd in het NFS-protocol. Er is aangegeven dat de beveiliging in toekomstige versies van het NFS-protocol zal worden verbeterd, maar op het moment van schrijven is dit nog niet gebeurd.
NFS wordt geconfigureerd via het bestand / etc / exports. Wanneer u het standaard / etc / exports-bestand in een editor laadt, ziet u: leeg bestand met een opmerking in de bovenste twee regels. We moeten een regel toevoegen aan het exportbestand voor elk van de directory's die we willen exporteren, met een lijst van de clientwerkstations die toegang krijgen tot die directory. Als we bijvoorbeeld de directory / home / foo voor het Bar-werkstation willen exporteren, moeten we deze regel toevoegen aan ons / etc / exports-bestand:
Zoals u kunt zien, zijn er verschillende opties, maar de meeste zullen duidelijk zijn uit dit voorbeeld.
NFS gelooft dat gegeven gebruiker een van de machines op het netwerk heeft dezelfde ID op alle andere machines. Wanneer een NFS-client probeert te lezen of te schrijven naar een NFS-server, wordt de UID doorgegeven als onderdeel van het lees-/schrijfverzoek. Deze UID wordt beschouwd als hetzelfde alsof het verzoek was gedaan met lokaal apparaat... Zoals je kunt zien, als iemand willekeurig een bepaalde UID kan specificeren bij het benaderen van bronnen op een externe machine, kunnen er problemen optreden. Een deel van de manier om dit te voorkomen is om alle mappen te mounten met de root_squash parameter. Dit overschrijft de UID van elke gebruiker die beweert root te zijn naar een andere UID, en voorkomt zo dat root toegang krijgt tot nieuwe bestanden en mappen in de geëxporteerde map. Het lijkt erop dat root_squash standaard is ingeschakeld om veiligheidsredenen, maar de auteurs raden je nog steeds aan om dit expliciet op te geven in je / etc / exports-bestand.
U kunt een map op de server ook rechtstreeks vanaf de opdrachtregel exporteren met behulp van de opdracht exportfs, zoals hieronder wordt weergegeven:
|
# exportfs -o rw, no_root_squash Bar: / home / foo |
Deze opdracht exporteert de directory / home / foo voor de computer “Bar” en geeft deze lees-/schrijftoegang. Bovendien is de parameter root_squash niet ingeschakeld op de NFS-server, wat betekent dat elke gebruiker op Bar met UID "0" (UID root "a) dezelfde privileges op de server heeft als root. De syntaxis ziet er nogal vreemd uit (meestal wanneer u directory specificeert als computer: / directory / bestand, verwijst u naar een bestand in een directory op een bepaalde computer).
U kunt meer informatie over het exportbestand vinden in de man-pagina.
