17.5 Network File System

Unter Windows stehen Ihnen über Netzwerkfreigaben und SMB einzelne Dateien, Verzeichnisbäume und sogar ganze Laufwerke netzwerkweit zur Verfügung. Unter Linux kann man dies entweder mittels Samba auf die gleiche Art und Weise umsetzen, was jedoch nur sinnvoll ist, wenn man auch Windows-PCs mit diesen Netzwerkfreigaben verbinden möchte. Eine pure und saubere Unix-Lösung wäre hingegegen das Network File System.

Mit dem NFS kann praktisch jedes Unix-System, jedes BSD-System und jedes Linux-System arbeiten. Es gibt auch eine kostenpflichtige Implementierung für Windows. Das Network File System, im Folgenden nur noch NFS genannt, wurde von Sun Microsystems entwickelt. Daher findet man auf den Dokumentationsseiten von Sun (z. B. docs.sun.com) auch tonnenweise Informationsmaterial zum Thema.

NFS ermöglicht es also, Verzeichnisse – und das können in Form von Mountpoints auch ganze Partitionen sein – im Netzwerk bereitzustellen. Die Freigaben liegen dabei physisch auf dem NFS-Server. Die NFS-Clients können dann über entsprechende Software, die in der Regel bereits direkt in den Kernel implementiert ist, auf diese Freigaben zugreifen und sie ins eigene Dateisystem einhängen. Daher ist NFS für den Anwender völlig transparent.

Es macht keinen Unterschied, ob man unter Unix auf eine Diskette, eine Festplatte oder ein Netzwerk-Dateisystem schreibt. Ebenso kann die Netzwerkfreigabe beim Server auf einer Festplatte oder einem anderen Medium liegen. [Fn. Einmal abgesehen von erheblichen Performanceunterschieden.]

NFS kann dadurch den Bedarf an lokalem Festplattenspeicher in Workstations und damit effektiv Kosten senken. Für den Administrator ist es wiederum einfacher, Backups zu erstellen, da er diese nur noch von den Daten des NFS-Servers ziehen muss. Wie bei Client/Server-Architekturen üblich, besteht der Nachteil darin, dass bei einem Serverausfall niemand mehr an seine Daten herankommt.

17.5.1 NFS-Server aufsetzen

NFS verwendet den RPC-Dienst, daher muss zunächst der Portmapper gestartet werden. Wie dies funktioniert, haben Sie bereits in Kapitel 13, »Benutzerverwaltung«, erfahren. [Fn. In Abschnitt 13.5, NIS/NIS+.] Der restliche Teil der Konfiguration ist nicht sonderlich schwer.

Es gibt verschiedene Dienste, die alle miteinander kooperieren und erforderlich sind, um einen funktionsfähigen NFS-Server zu betreiben. Dazu zählen:

• nfsd
  Der nfsd nimmt NFS-Anfragen von Clients entgegen.
• (rpc.)mountd
  Der mountd verarbeitet die Mount-Anfragen der Clients.
• (rpc.)lockd
  Dieser Dienst kümmert sich um Anforderungen des File-Lockings.
• (rpc.)statd
  Dieser Dienst wird zum Monitoring und für lockd benötigt.

Die Dienste lockd und statd laufen übrigens auch auf Client-Systemen. In der Regel werden sie vom jeweiligen Derivat beziehungsweise von der jeweiligen Distribution über Shellskripts beim Startvorgang gestartet. Ist dies nicht der Fall, müssen Sie diese Dienste selbst starten.

Dateien freigeben

Nun sind aber noch gar keine Dateien freigegeben. Um dies zu ändern, gibt es zwei Wege: Entweder man verwendet ein Unix-System, das das Tool share zur Verfügung stellt (etwa Solaris), oder man verwendet die Datei /etc/exports. Da die zweite Variante unter Linux und BSD immer funktioniert, werden wir uns im Folgenden auf die exports-Datei beschränken.

Dort werden die freizugebenden Verzeichnisse sowie deren Zugriffsrechte [Fn. ... bei denen man eigentlich schon von Access Control Lists sprechen kann.] festgelegt. Zugriffsrechte können nämlich nicht nur wie im Unix-Dateisystem (von ACLs einmal abgesehen) konfiguriert, sondern bei Bedarf auch hostspezifisch gesetzt werden.

Die Einträge sind, wie unter Linux üblich, zuerst zeilenweise und anschließend spaltenweise zu interpretieren. In der ersten Spalte wird das Verzeichnis angegeben, das man freigeben möchte. Darauf folgen verschiedene Parameter, die den Zugriff auf die Freigabe regeln.

Listing 17.21 Beispiel einer exports-Datei

/exports/pub_ftp (ro)
/exports/homes   192.168.0.0/24(rw)

In diesem Beispiel haben wir das Verzeichnis /exports/pub_ftp für alle Hosts aller Netzwerke freigegeben. Allerdings darf niemand auf diese Ressource schreiben (»ro« = read-only). Das Verzeichnis homes, in dem alle Heimatverzeichnisse der Nutzer enthalten sind, wird für das gesamte Netzwerk 192.168.0.0/24 mit Lese- und Schreibrechten freigegeben.

Netzmaske

Wie Ihnen sicher aufgefallen ist, können Netzwerke also in der Form Adresse/Netz- maske angegeben werden. Falls Ihnen die Bit-Schreibweise der Netzmaske nicht geläufig ist, kann sie auch ausgeschrieben werden. Im Beispiel wäre die Netzmaske also 255.255.255.0.

Wildcards

Außerdem können Wildcards verwendet werden. Sollen beispielsweise alle Hosts im Netz doomed-reality.org auf eine Ressource zugreifen können, so lässt sich auch *.doomed-reality.org schreiben.

(a)sync

Durch das Schlüsselwort async kann man die Performance von NFS-Netzwerken verbessern. Werden Daten verändert, so werden diese sofort auch im Netzwerk in veränderter Form verfügbar, selbst dann – und das ist der springende Punkt --, wenn sie noch nicht auf dem Datenträger abgespeichert worden sind. Es herrscht folglich kein synchroner Zustand zwischen Speicher und Medium.

async hat nicht nur den Vorteil der Performancesteigerung, sondern auch den Nachteil, dass bei Absturz des Servers die Daten im Speicher verloren gehen, bevor sie auf das Medium gespeichert wurden. Daher stellt ein möglicher Datenverlust ein großes Risiko dar. Um dies zu verhindern, kann man NFS dazu zwingen, die Daten synchron zu halten, und zwar mit dem Schlüsselwort sync. [Fn. Übrigens gibt es – unabhängig von NFS – auch das Dateisystem-Tool sync, das die Daten, die aktuell nur im Speicher sind, auf die eingehängten Speichermedien des Systems schreibt.]

(no)dev

Das Schlüsselwort dev bewirkt, dass auch Device-Dateien über das Netzwerk verfügbar gemacht werden dürfen oder eben nicht (nodev).

(no)exec

exec erlaubt das Ausführen von Dateien im Netzwerk-Dateisystem; noexec bewirkt das Gegenteil.

(no)suid

Bei gesetztem nosuid-Keyword dürfen keine Binaries mit setuid-Flag ausgeführt werden. Dies verbessert die Sicherheit von NFS. Das Keyword suid bewirkt natürlich wieder das Gegenteil.

(no)user

Falls nur root ein Dateisystem mounten dürfen soll, wird das Schlüsselwort nouser angegeben.

Weitere Optionen

Es gibt noch diverse weitere NFS-Optionen. Diese würden allerdings den Rahmen dieses Abschnitts sprengen und sind zudem oft systemabhängig. Wir verweisen daher auf die jeweilige exports-Manpage.

17.5.2 Clients konfigurieren

Auch auf dem Client wird RPC sowie (rpc.)lockd und (rpc.)statd gestartet. Anschließend kann ein Remote-Dateisystem mit mount eingehängt werden, wozu Sie den NFS-Server und die Freigabe angeben müssen. Unter Linux verwendet man für NFS den Parameter -t nfs; unter OpenBSD wird einfach mount_nfsd benutzt.

Listing 17.22 Dateisystem mounten unter Linux

# mount -t nfs 192.168.0.5:/exports/homes /home
# df -h | grep homes
192.168.0.5:/exports/home 6.6G 2.6G 3.7G 42 % /home

showmount

Um nun zu überprüfen, welche Freigaben auf einem Host verfügbar sind, nutzen Sie das Tool showmount.

Listing 17.23 showmount

# showmount -e localhost
Export list for localhost:
/exports/pub_ftp (everyone)
/exports/homes    192.168.0.0/24

[zB]NFS wird, wie Sie im Beispiel gesehen haben, häufig für die Verteilung von Home-Verzeichnissen eingesetzt. So kann gewährleistet werden, dass für einen Benutzer die Dateien samt Arbeitsumgebung auf allen Rechnern in einem Pool identisch sind. Um keine Konflikte mit der Rechtevergabe und der Benutzerverwaltung zu bekommen, wird NFS daher auch oft in Verbindung mit LDAP oder NIS eingesetzt.

Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.