Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Linuxtopia - Red Hat Enterprise Linux Rerenzhandbuch- Netzwerk-Dateisystem (Network File System - NFS)

Kapitel 9. Netzwerk-Dateisystem (Network File System - NFS)

Mit dem Netzwerk-Dateisystem (NFS) k�nnen Dateisysteme �ber ein Netzwerk gemountet werden diese Dateisysteme verwenden, als w�ren diese lokal gemountet. Dies erm�glicht Systemadministratoren, Ressourcen auf zentralen Servern im Netzwerk zusammenzulegen.

Dieses Kapitel konzentriert sich auf fundamentale NFS-Konzepte und erg�nzende Informationen. F�r detaillierte Anweisungen bez�glich Konfiguration und Funktion von NFS-Servern und Client-Software siehe Kapitel Netzwerk-Dateisystem (NFS) im Red Hat Enterprise Linux Handbuch zur System-Administration.

9.1. Wie es funktioniert

Zur Zeit werden zwei Versionen von NFS verwendet. Die Version 2 von NFS (NFSv2) ist �lter, wird aber von vielen Systemen unterst�tzt. Die NFS-Version 3 (NFSv3) verf�gt �ber mehr Features, einschlie�lich einer variablen Dateigr��e und einem besseren Fehlerreport, ist aber mit NFSv2-Clients nicht vollst�ndig kompatibel. NFS Version 4 (NFSv4) beinhaltet Kerberos, arbeitet mittels Firewalls und im Internet, ben�tigt Portmapper nicht mehr l�nger, unterst�tzt ACLs und wendet statusbezogene Operationen an. Red Hat Enterprise Linux unterst�tzt NFSv2-, NFSv3- sowie auch NFSv4-Clients und wenn ein Dateisystem via NFS gemountet wird, verwendet Red Hat Enterprise Linux NFSv4 als Standard, wenn der Server es unterst�tzt.

Alle Versionen von NFS k�nnen das Transmission Control Protocol (TCP) verwenden, wenn es auf einem IP-Netzwerk abl�uft. Dies wird von NFSv4 ben�tigt. NFSv2 und NFSv3 k�nnen das User Datagram Protocol (UDP) benutzen, wenn es auf einem IP-Netzwerk abl�uft, um eine zustandslose Netzwerkverbindung zwischen Client und Server bereitzustellen.

Wenn Sie NFSv2 oder NFSv3 mit UDP verwenden, minimiert die statuslose UDP-Verbindung unter normalen Umst�nden den Netzwerkverkehr, da der NFS-Server dem Client ein Cookie sendet, nachdem der Client f�r den Zugriff auf die gemeinsamen Dateien authorisiert worden ist. Dieses Cookie ist ein zuf�lliger Wert, der im Server gespeichert ist und gemeinsam mit RPC-Anfragen vom Client �bermittelt wird. Der NFS-Server kann ohne Auswirkung auf die Clients neu gestartet werden, das Cookie bleibt dabei intakt. Da aber UDP statuslos ist, best�rmen die UD- Clients das Netzwerk weiterhin mit Anfragen f�r den Server, auch wenn der Server unerwarteterweise herunterf�hrt. Deswegen ist TCP das bevorzugte Protokoll beim Verbinden mit einem NFS-Server.

Mit NFSv4 erhalten Sie eine 'stateful' Verbindung und eine optionale Kerberos Benutzer- und Gruppen-Authentifizierung mit verschiedenen Sicherheitsstufen. NFSv4 interagiert nicht mit Portmapper, rpc.mountd, rpc.lockd und rpc.statd, das diese in den Kernel eingespeichert worden sind. NFSv4 horcht den bekannten TCP-Port 2049 ab.

AnmerkungAnmerkung
 

TCP ist das standardm��ige Transport-Protokoll f�r NFS unter Red Hat Enterprise Linux. Siehe Kapitel Network File System (NFS) im Red Hat Enterprise Linux Handbuch zur System-Administration f�r weitere Informationen �ber Verbindung zum Server mittels TCP. UDP kann je nach Bedarf f�r Kompatibilit�tszwecke eingesetzt werden, wird jedoch desweiteren nicht empfohlen.

NFS f�hrt Authentifizierungen nur dann durch, wenn ein Client versucht, die gemeinsame NFS-Ressource zu mounten. Um Zugriffe auf den NFS-Server zu limitieren werden TCP-Wrapper verwendet. Die TCP-Wrapper lesen die Dateien /etc/hosts.allow und /etc/hosts.deny, um festzulegen, ob einem bestimmten Client oder einem Netzwerk der Zugriff auf den NFS-Server erlaubt oder verwehrt wird. Weitere Informationen zum Konfigurieren der Zugriffssteuerung mit TCP-Wrapper finden Sie unter Kapitel 17.

Erh�lt der Client die Berechtigung, die TCP-Wrapper zu passieren, verweist der NFS-Server auf die Konfigurationsdatei /etc/exports, um festzulegen, ob der Client �ber ausreichende Privilegien zum Zugreifen auf eine der exportierten Dateisysteme verf�gt. Wird der Zutritt gew�hrt, kann der User �ber alle Datei- und Verzeichnisvorg�nge verf�gen.

WarnungWarnung
 

NFS-Mount-Privilegien werden dem Client Host gew�hrt, nicht dem Benutzer, wenn Sie NFSv2 oder v3 benutzen, welche Kerberos Authenfifizierung nicht unterst�tzen. Deswegen kann jeder Benutzer auf einem Client Host mit Zugangsberechtigung auf die exportierten Dateisysteme zugreifen. Wenn Sie die gemeinsamen NFS- Dateien konfigurieren, seien Sie vorsichtig, welche Hosts eine Lese- und Schreibberechtigung erhalten (rw).

WichtigWichtig
 

Sodass NFS mit einer Standardinstallation von Red Hat Enterprise Linux und einer aktivierten Firewall einwandfrei funktioniert, muss IPTables mit dem Standard-TCP-Port 2049 konfiguriert sein. Ohne IPTables Konfiguration, kann NFS nicht ordentlich funktionieren.

Das NFS-Initialisierungsskript und der rpc.nfsd-Prozess erm�glichen nunmehr Bindungen zu jedem festgelegten Port w�hrend das System hochstartet. Dies kann jedoch sehr fehleranf�llig sein, im Falle von Konflikten mit einem anderen Daemon oder dass ein Port nicht zur Verf�gung steht.

9.1.1. Erforderliche Dienste

Red Hat Enterprise Linux verwendet f�r das NFS Datei-Sharing eine Kombination aus dem Kernel-Level-Support und den Daemon-Prozessen. NFS verl�sst sich auf Remote Procedure Calls (RPC), um Anfragen zwischen Clients und Servern zu routen. Bei Linux werden RPC-Dienste durch den portmap Dienst gesteuert. Beim gemeinsamen Verwenden oder mounten von NFS-Dateisystemen arbeiten folgende Dienste zusammen (abh�ngig von der verwendeten Version):

  • nfs — Startet die passenden RPC-Prozesse, um Anfragen f�r gemeinsame NFS-Dateisysteme zu handhaben.

  • nfslock — ein fakultativer Dienst, der die passenden RPC-Prozesse startet, damit NFS-Clients Dateien auf dem Server festmachen k�nnen.

  • portmap — Der RPC-Dienst f�r Linux; er reagiert auf Anfragen f�r RPC-Dienste und und baut Verbindungen zu den erfragten RPC-Diensten auf. Wird nicht mit NFSv4 verwendet.

Die folgenden RPC-Prozesse arbeiten im Hintergrund zusammen, um die NFS-Dienste zu unterst�tzen:

  • rpc.mountd — Dieser Prozess empf�ngt die Mount-Anfrage der NFS-Clients und kontrolliert, ob das erfragte Dateisystem zu diesem Zeitpunkt exportiert ist. Der Prozess wird automatisch durch den nfs Dienst gestartet und erfordert keine Benutzer- Konfiguration. Findet keine Verwendung in Zusammenhang mit NFSv4.

  • rpc.nfsd — Dieser Prozess ist der NFS-Server. Er arbeitet mit dem Linux-Kernel, um mit den dynamischen Vorgaben des NFS-Clients �bereinzustimmen. Zum Beispiel das Bereitstellen zus�tzlicher Server-Threads, immer wenn sich ein NFS-Client verbindet. Dieser Prozess korrespondiert mit dem nfs Dienst.

  • rpc.lockd — Ein fakultativer Prozess, der NFS-Clients erlaubt, Dateien am Server festzumachen. Dieser Prozess korrespondiert mit demnfslock Dienst. Findet keine Verwendung in Zusammenhang mit NFSv4.

  • rpc.statd — Implementiert das Network Status Monitor (NSM)-RPC- Protokoll. Dies verst�ndigt NFS-Clients, wenn ein NFS-Server neu gestartet wird, ohne dass er ordentlich heruntergefahren wurde. Dieser Prozess wird automatisch durch den nfslock Dienst gestartet und erfordert keine Benutzer-Konfiguration. Findet keine Verwendung in Zusammenhang mit NFSv4.

  • rpc.rquotad — Dieser Prozess stellt Information �ber Benutzerquoten f�r Remote-Benutzer zur Verf�gung. Der Prozess wird automatisch durch den nfs Dienst gestartet und erfordert keine Benutzer-Konfiguration.

  • rpc.idmapd — Dieser Prozess bietet NFSv4 Client- und Server-Upcalls, welche zwischen on-the-wire NFSv4 Namen (Strings in Form von user@domain) und lokalen UIDs und GIDs mappen. Sodass idmapd mit NFSv4 funktioniert, muss /etc/idmapd.conf konfiguriert sein. Ist nicht erforderlich in Zusammenhang mit NFSv4.

  • rpc.svcgssd — Dieser Prozess bietet den Server-Transportmechnanismus f�r den Authentifizierungsprozess (Kerberos Version 5) mit NFSv4. Dieser Service ist f�r die Benutzung mit NFSv4 erforderlich.

  • rpc.gssd — Dieser Prozess bietet den Client-Transportmechnanismus f�r den Authentifizierungsprozess (Kerberos Version 5) mit NFSv4. Dieser Service ist f�r die Benutzung mit NFSv4 erforderlich.

9.1.2. NFS und portmap

AnmerkungAnmerkung
 

Der folgende Abschnitt trifft nur auf NFSv2- oder NFSv3-Implementationen zu, welche den portmap-Dienst aus Kompatibilit�tsgr�nden ben�tigen.

Der portmap Dienst von Linux wird ben�tigt, um die RPC-Anfragen den korrekten Diensten zuzuordnen. portmap wird von den RPC-Prozessen benachrichtigt, wenn sie starten. Des Weiteren teilen die Anfragen die �berwachte Port-Nummer sowie die Nummern des RPS-Programms mit, die aufgerufen werden. Der Client kontaktiert portmap auf dem Server mit einer bestimmten RPC-Programmnummer. Der portmap Dienst leitet dann den Client zur richtigen Port-Nummer um, damit er mit dem gew�nschten Dienst kommunizieren kann.

Da auf RPC-basierte Dienste sich auf portmap verlassen, alle Verbindungen mit eingehenden Client-Anfragen herzustellen, muss portmap verf�gbar sein, bevor irgendeiner dieser Dienste startet.

Der portmap-Dienst verwendet TCP-Wrapper f�r die Zugriffskontrolle, die Zugriffs-Kontrollregeln f�r portmap beeinflussen alle auf RPC basierenden Dienste. Als Alternative k�nnen Sie auch Zugriffs-Kontrollregeln f�r jeden der NFS-RPC-Daemonen einzeln bestimmen. Die man-Seiten f�r rpc.mountd und rpc.statd enthalten Informationen �ber die genaue Syntax dieser Regeln.

9.1.2.1. Probeml�sungen bei NFS mit portmap

Da portmap die Koordination zwischen RPC- Diensten und den Port-Nummern �bernimmt, die f�r die Kommunikation mit den Diensten verwendet werden, ist es sehr hilfreich, eine �bersicht �ber die aktuellen RPC- Dienste zu haben, die portmap verwenden. Der Befehl rpcinfo zeigt jeden auf RPC-basierenden Dienst mit Port-Nummern, RPC-Programmnummer, Version und dem Typ des IP- Protokolls (TCP oder UDP) an.

Um sicherzustellen, dass die richtigen NFS-RPC-basierten Dienste f�r portmap aktiviert sind, geben Sie den folgenden Befehl als Root ein:

rpcinfo -p

Im folgenden ein Probe-Output dieses Befehls:

   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100021    1   udp  32774  nlockmgr
    100021    3   udp  32774  nlockmgr
    100021    4   udp  32774  nlockmgr
    100021    1   tcp  34437  nlockmgr
    100021    3   tcp  34437  nlockmgr
    100021    4   tcp  34437  nlockmgr
    100011    1   udp    819  rquotad
    100011    2   udp    819  rquotad
    100011    1   tcp    822  rquotad
    100011    2   tcp    822  rquotad
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100005    1   udp    836  mountd
    100005    1   tcp    839  mountd
    100005    2   udp    836  mountd
    100005    2   tcp    839  mountd
    100005    3   udp    836  mountd
    100005    3   tcp    839  mountd

Im oben aufgef�hrten Output wird angezeigt, dass die richtigen NFS-Dienste ablaufen. Wenn einer der NFS-Dienste nicht korrekt startet, kann portmap die RPC-Anfragen von Clients f�r diesen Dienst nicht dem richtigen Port zuordnen. Wenn NFS im rpcinfo Output nicht vorhanden ist, f�hrt in vielen F�llen das Neustarten von NFS dazu, dass der Dienst korrekt in portmap registriert werden und arbeiten kann. Anweisungen f�r das Starten von NFS finden Sie unter Abschnitt 9.2.

Andere hilfreiche Optionen sind f�r den rpcinfo Befehl vorhanden. Siehe rpcinfo man Seite f�r weitere Informationen.

 
 
  Published under the terms of the GNU General Public License Design by Interspire