NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
Linuxtopia - CentOS 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.
Anmerkung
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.
Warnung
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).
Wichtig
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
Anmerkung
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:
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.
