12.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 nützlich 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 (u.a. docs.sun.com) auch tonnenweise Informationsmaterial zum diesem 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 physikalisch 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 einfach 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.
Es macht natürlich auch keinen Unterschied, ob die Netzwerkfreigabe beim Server auf einer Festplatte oder einer Diskette liegt. <Einmal abgesehen von erheblichen Performanceunterschieden>
NFS kann dadurch natürlich auch den Bedarf an lokalem Festplattenspeicher in Workstations und damit effektiv Kosten senken. Für den Administrator hingegen ist es wiederum einfacher, Backups zu erstellen. Er muss schließlich nur Backups von den Daten des NFS-Servers ziehen. Wie bei Client/Server-Architekturen üblich, besteht der Nachteil natürlich darin, dass bei einem Serverausfall keiner mehr an seine Daten herankommt.
12.5.1 Einen NFS-Server aufsetzen
NFS verwendet den RPC-Dienst, daher muss zunächst der Portmapper gestartet werden. Wie dies funktioniert, erfuhren Sie bereits in Kapitel 8, »Benutzerverwaltung«. <In Abschnitt 8.5, NIS/NIS+.> Der restliche Teil der Konfiguration ist anschließend nicht sonderlich schwer.
Für NFS gibt es verschiedene Dienste, die sozusagen alle miteinander kooperieren und nötig 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 /etc/exports-Datei. Da die zweite Variante unter Linux und BSD immer funktioniert, werden wir uns im Folgenden auf die exports-Datei beschränken.
In dieser Datei werden die freizugebenden Verzeichnisse sowie deren Zugriffsrechte <... 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 werden, sondern können bei Bedarf auch hostspezifisch gesetzt werden.
Die Einträge sind, wie unter Linux üblich, 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.
/exports/pub_ftp (ro) /exports/homes 192.168.0.0/24(rw)
Listing 12.20 Beispiel einer exports-Datei
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 wohl aufgefallen ist, können Netzwerke also in der Form Adresse/Netzmaske angegeben werden. Falls Ihnen die Bit-Schreibweise der Netzmaske nicht geläufig ist, kann die Netzmaske 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, kann man *.doomed-reality.org schreiben.
(a)sync
Durch das Schlüsselwort async kann man die Performance von NFS-Netzwerken verbessern. Werden Daten verändert, werden diese sofort auch im Netzwerk in veränderter Form verfügbar, auch – und das ist der springende Punkt – wenn die Daten 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 Performance-Steigerung, sondern auch den Nachteil, dass, wenn z. B. der Server abstürzt, 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. Natürlich heißt das Schlüsselwort dafür »sync«. <Übrigens gibt es – unabhängig von NFS – auch das Dateisystem-Tool sync, das Ihnen die Daten, die momentan 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 SUID-Flag ausgeführt werden. Das verbessert die Sicherheit von NFS. »suid« bewirkt natürlich wieder das Gegenteil.
(no)user
Falls nur root ein Dateisystem mounten darf, wird »nouser« angegeben.
Weitere Optionen
Es gibt noch diverse weitere NFS-Optionen. Diese würden allerdings den Rahmen dieses NFS-Abschnitts sprengen und sind zudem oft systemabhängig. Wir verweisen daher auf die jeweilige exports-Manpage.
12.5.2 Den Client 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.
# 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
Listing 12.21 Dateisystem mounten unter Linux
showmount
Um nun zu überprüfen, welche Freigaben auf einem Host verfügbar sind, verwendet man das Tool showmount.
# showmount -e localhost Export list for localhost: /exports/pub_ftp (everyone) /exports/homes 192.168.0.0/24
Listing 12.22 showmount
NFS wird, wie Sie im Beispiel gesehen haben, häufig für die Verteilung der Homeverzeichnisse 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.