Was passiert eigentlich, wenn man auf Daten entfernter Rechner per NFS zugreift? Ein Blick hinter die Theorie- und Praxiskulissen.

Bereits 1984, also lange, bevor Linus Torvalds auch nur annähernd an Linux dachte, und die Computer-Welt noch von Mainframes regiert wurde, machte sich das Unternehmen Sun Microsystems an die Aufgabe, ein System zu entwickeln, mit dem man über das Netzwerk auf Dateien anderer Rechner zugreifen und diese auslesen, verändern oder abspeichern konnte. 1985 war es schließlich soweit: Sun stellte “NFS Version 2” (NFS V2) der Öffentlichkeit vor. Mit der Veröffentlichung der Spezifikation selbst durchbrach Sun zum ersten Mal die geheiligte Tradition der Geheimhaltung solch technischer Einzelheiten – und ebnete damit letzten Endes den Siegeszug von NFS. Sun stellte allen anderen Firmen die Entwicklungsergebnisse als Lizenz zur Verfügung und ermöglichte somit einen De-facto-Standard in der Unix-Welt, der sich bis heute durchgesetzt hat und immer noch eine der erfolgreichsten Unix-Technologien darstellt.

Nach und nach wurde NFS auf alle möglichen Plattformen wie System V, BSD, AIX, HP-UX und später auch Linux portiert und ist heute Teil jeder Linux-Distribution. Doch was verbirgt sich hinter diesen drei Buchstaben? In erster Linie ein zustandsloses Protokoll, d. h., die beteiligten Programme müssen sich nicht merken, in welchem Zustand ihre Verhandlungen stehen, und sie müssen auch nicht dauernd miteinander reden.

Protokoll-Kollegen

1991 veröffentlichte SunSoft, eine Sun-Tochtergesellschaft, eine Protokoll-Suite namens ONC (“Open Network Computing”), in die alle an einem Datei-Zugriff über NFS beteiligten Protokolle integriert wurden.

Der NFS-Dienst vertritt dort die Applikationsebene, d. h., mit ihm wird direkt gearbeitet. Ein weiterer, wichtiger Kollege aus der ONC-Suite ist der “Remote Procedure Call”-Dienst (RPC), der die Empfangszentrale für Anfragen von Clients ist. Diese leitet er an die zugehörigen Ports und Server weiter, die die eigentliche Arbeit machen.

Da NFS verschiedenartige Plattformen, unabhängig von ihren Herstellern, verbinden möchte, gibt es bei der Verständigung oftmals Probleme. Diese löst der XDR-Dienst (“External Data Representation”) durch Konvertierung der Daten, d. h., er übersetzt alle eingehenden Daten in ein für das Betriebssystem des Rechners verständliches Format. Auf der Applikationsebene tummeln sich nicht nur der NFS-Dienst selbst, sondern auch das Mount-Protokoll oder der Lock-Manager. Ersteres koordiniert den “Einhängevorgang” eines NFS-Server-Dateisystems in den Dateibaum des Client-Rechners. Dabei wird der NFS-Server gefragt und die Berechtigungsnachricht an den Client weitergegeben. Der Lock-Manager sperrt Dateien bzw. Ordner bei bereits bestehenden Verbindungen, um Sicherheit bei der Bearbeitung der Daten zu gewährleisten und konsistente Dateien sicherzustellen.

Der Portier

Da eine Kommunikation zwischen zwei Rechnern über sogenannte Sockets, also die IP-Adresse und die zugehörige Port-Nummer eines Dienstes, läuft, muss der Client, der seine Anfrage an den Server richtet, auch den Port kennen. Dies übernimmt der Portmapper, von Sun auch RPC-Bind genannt.

Abbildung 1: So funktioniert eine Client-Server-Abfrage

Dieses Server-Programm sollte standardmäßig auf Ihrem System installiert sein; es wird beim Booten meist automatisch gestartet. Es pflegt eine kleine Datenbank, in der sich die RPC-Dienste nach dem Startvorgang registrieren. Sie geben unter anderem ihre interne Programm- und Versionsnummer an, durch die bei Anfragen an den Portmapper eine Zuordnung zum richtigen Dienst sichergestellt wird. Man kann den Portmapper mit einem Portier vergleichen, der Ihnen, vorausgesetzt, Sie nennen Ihren richtigen Namen, Ihren Schlüssel aushändigt, mit dem Sie Ihr Zimmer aufschließen können.

Ein Client, der einen RPC-Dienst nutzen will, übergibt den passenden Protokolltyp, die Programm- und die Versionsnummer des Dienstes, sodass der Portmapper seine Datenbank durchsuchen und die auf die Anfrage passende Port-Nummer mitteilen kann.

Abbildung 2: Ausgabe der vom Portmapper verwalteten Versionsnummern und Dienstinfos

Dies geschieht pro Sitzung in der Regel einmal: Der Client merkt sich die Port-Nummer und interagiert nun auf direktem Wege mit dem passenden Server-Daemon. Doch wie starten Sie nun eine NFS-Anfrage?

Nehmen wir an, Sie möchten ein freigegebenes Datenverzeichnis /export/RPMS auf dem NFS-Server (nennen wir ihn defiant und geben ihm die IP-Adresse 192.168.1.1), manuell ins Verzeichnis /mnt/nfs/ auf dem Client-Rechner einhängen. Dazu verwenden Sie den Befehl mount, der vom Einhängen lokaler Datenträger hinlänglich bekannt sein dürfte. Dessen Syntax lautet

mount eventuelle_optionen server:/pfad_zum_verzeichnis lokaler_mountpoint

…, in unserem Beispiel also

mount -t NFS defiant:/export/RPMS /mnt/nfs

Damit fragt der Client-Daemon beim RPC-Dienst und beim Portmapper an und übergibt diesem als Programmnummer 100005, als Version 2 und als Protokoll UDP. Programmnummer und Version entnimmt der mount-Client seinen eigenen, internen Daten, die diese standardisierten Nummern enthalten

Abbildung 3: Der NFS-Mount-Vorgang

Daraufhin gibt der Portmapper als Zugriffsport den Port 1033 an (vgl. Abbildung 2), eine Information, die unmittelbar an den Client-Daemon weitergegeben wird. Im nächsten Schritt greift der Client über das entsprechende Socket (192.168.1.1:1033, wobei vor dem Doppelpunkt die IP-Adresse des Servers, dahinter die Port-Nummer für diese NFS-Verbindung steht) auf den Server-Rechner zu, wo der dortige Mount-Daemon direkt angesprochen wird. Von dort aus kommt der NFS-Daemon ins Spiel, der die Berechtigungen prüft und ein sogenanntes File Handle erstellt. Dabei handelt es sich um ein Datenobjekt mit eindeutiger Zufallszahl, die die Identifikation der Datei gewährleisten soll und nur einmalig vergeben wird. Mit diesen Parametern versehen geht die Anfrage wieder zurück zum Client-Rechner, der seinen Aufruf wiederum an den NFS-Client weitergibt. Dieser baut die Verbindung auf, um mit den gewünschten Daten arbeiten zu können.

Vorbereitungen

Ehe jedoch entfernte Dateisysteme ins lokale Filesystem eingehängt werden können, bedarf es noch kleinerer Vorbereitungen – client- wie serverseitig. Als erstes wäre hier die Konfigurationsdatei /etc/exports auf dem freigebenden Rechner zu nennen, in der alle zu exportierenden Verzeichnisse aufgeführt werden. Dazu kommen Angaben, wer (welche Clients) wie (mit welchen Rechten) auf die Freigaben zugreifen dürfen. Abbildung 4 zeigt eine exports-Datei, in der das Verzeichnis /export/RPMS auf dem NFS-Server sowohl zum Lesen (“read”) als auch zum Schreiben (“write”) für alle (@L: *) Client-Rechner freigegeben wird. Auf eine auf dem NFS-Server unter /mnt/cdrom gemountete CD darf lediglich der Client stargazer lesend (“read only”) zugreifen.

Abbildung 4: Die Datei /etc/exports mit verschiedenen Freigaben

In der zweiten Spalte können weitere Einschränkungen festgelegt werden. So lässt sich gezielt festlegen, dass in der ersten Spalte angegebene Verzeichnisse nur für Rechner mit bestimmten IP-Adressen oder aus bestimmten Domains zugänglich sind. Sogar Wildcards sind möglich.

Der Befehl exportfs zeigt alle freigegebenen Verzeichnisse an. Wenn Sie ihn mit der Option -r benutzen, synchronisiert er die Datei exports mit der NFS-Tabelle (bei Red Hat unter /var/lib/nfs/xtab, auf Solaris-Workstations unter /etc/dfs/sharetab zu finden). Neue exportfs-Einträge werden dabei in die NFS-Tabelle aufgenommen, während nicht mehr in der Export-Liste vorhandene Einträge gelöscht werden. Ein Blick in diese Datei verrät Neugierigen übrigens weitere interessante Parameter für die zweite exports-Spalte, von denen einige in Tabelle 1 aufgeführt sind.

Der lokale NFS-Daemon auf dem Client-Rechner bekommt nun alle erforderlichen Variablen und Daten geliefert, um mit dem NFS-Server zu kommunizieren. Von jetzt an können Sie mit dem externen Filesystem arbeiten, als ob es lokal zu Ihrem Rechner gehörte. Es ist nun ein Teil Ihres eigenen Systems.

Auch für den mount-Befehl gibt es weitere Optionen (vgl. Tabelle 2), zum Beispiel hard und soft. Bei einem “Hardmount” (der Normalfall) versucht der Client, auf Teufel-komm-raus Zugriff auf den NFS-Server zu erlangen. Bei einer Netzstörung oder der Nichtverfügbarkeit des Servers kann diese Hartnäckigkeit zum Erliegen des Systems führen. Beim “Softmount” dagegen schickt der Client Anfragen lediglich so lange ab, bis ein Timeout eintritt und der User eine Fehlermeldung erhält – auch nicht immer die optimale Lösung. Um bei diesen beiden Mount-Verfahren einen Abbruch zu erzwingen, gibt es die Option intr (ihr Gegenteil heißt nointr). Sie erlaubt es Ihnen, einen Mount-Versuch per Hand (meist mit [Strg-c]) frühzeitig zu unterbrechen. Per Default (oder bei Angabe der Mount-Option fg) gibt der Mount-Prozess nicht auf, wenn’s beim ersten Mal nicht klappt. Gibt man den entsprechenden Befehl in einer Shell ein, bleibt diese blockiert. Mit der Option bg versehen, reagiert mount auf einen missglückten Versuch entspannter: Der Prozess taucht in den Hintergrund ab und wird zu einer Art Daemon, der es später nochmal probiert, ohne die Shell zu blockieren. So versucht der Befehl

mount -t NFS -o bg,intr,retry=5 defiant:/export/RPMS /mnt/nfs

das auf dem Rechner defiant freigegebene Verzeichnis /export/RPMS in den lokalen Dateibaum unter /mnt/nfs einzuhängen. Geht der erste Versuch schief, taucht der mount-Prozess in den Hintergrund ab (bg), damit Sie weiter auf Ihrer Shell arbeiten können. Nach fünf Fehlversuchen soll er automatisch aufgeben (retry=5), während der Sie allerdings die Option zum Abbruch von Hand haben (intr).

[root@defiant /]# ls -al /usr/bin/passwd
-r-sr-xr-x root system passwd
[root@defiant /]# ls -al /etc/shadow
-rw-r--r-- root system passwd

Sysadmins sind bekanntlich sehr faule Menschen, die alles automatisieren möchten. Statt Dateisysteme per Hand einzuhängen, gibt es daher auch hier einen einfacheren Weg: den Eintrag in die Datei /etc/fstab des lokalen NFS-Client-Rechners. In dieser Datei stehen alle Dateisysteme, Schnittstellen und Devices, die irgendwann einmal gemountet werden bzw. werden können. Lassen Sie uns einen kurzen Blick auf Abbildung 5 werfen.

Abbildung 5: /etc/fstab

Auch hier sehen Sie wieder, dass es sich um eine reine ASCII-Datei handelt, in der Sie als root selbstständig Einträge vornehmen können. In der ersten Spalte findet das Gerät (die Festplattenpartition, das CD-Device etc.), das Sie mounten möchten, seinen Platz. Darauf folgt der Mountpoint, also das Verzeichnis, unterhalb dessen das “fremde” Dateisystem in den lokalen Dateibaum eingehängt wird. Die dritte Spalte enthält den Filesystem-Typ, in der vierten definiert man die Mount-Optionen (siehe Tabelle 2). Die letzten beiden Spalten enthalten die Information, ob ein Filesystem-Dump, d. h. eine Sicherung des Dateisystems oder Verzeichnisses, erzeugbar sein und ob das Dateisystem vor dem Mounten geprüft werden soll.

Ein für Sie zugängliches, von einem NFS-Server exportiertes Verzeichnis tragen Sie hier etwa folgendermaßen ein:

defiant:/export/RPMS   /mnt/nfs   nfs   noauto,user,bg,hard,intr   0   0

Dieser Eintrag ähnelt den bisherigen Konsoleneingaben sehr: Quell- und Zielverzeichnis, der Dateisystemtyp (nfs) und die verschiedenen Optionen sind leicht auszumachen. Das Beispielverzeichnis wird nicht automatisch beim Booten gemountet (noauto), kann aber von Normalbenutzern eingehängt werden (user). Dabei kommen die oben erwähnten NFS-Mount-Optionen bg, hard und intr zum Zuge. Nun lässt sich das von defiant exportierte Verzeichnis /export/RPMS mit einem einfachen mount /mnt/nfs ins lokale Dateisystem einhängen.

Automount

Das ist Ihnen noch nicht einfach genug? Dann brauchen Sie einen Automounter. Er hängt benötigte Verzeichnisse automatisch bei Bedarf (Zugriff) ein und entfernt sie nach einem bestimmten Zeitraum der Nichtnutzung wieder. Dies lässt sich über ein Kernel-Modul namens autofs realisieren, dass in vielen Fällen bereits im vorgefertigten Kernel integriert ist.

Das Autofs-Modul “belauscht” alle “Wechsel”-Vorgänge innerhalb des Dateisystems. Bei einem cd in ein Verzeichnis oder bei Aufruf einer Datei unterhalb des eingehängten Mountpoints gibt das Modul die Anfrage an den Automount-Daemon weiter. Dieser arbeitet nun die Konfigurationseinstellungen ab, die in den “auto-Dateien” unterhalb von /etc definiert sind. Die erste Datei, der er sich zuwendet, ist die /etc/auto.master, die die allgemeine Vorgehensweise beschreibt (Listing 1).

#/etc/auto.master
/export/RPMS     /etc/auto.rpms
/home            /etc/auto.home -intr,[…]
/xxx             /etc/auto.xxx  -nosuid,[…]

Die erste Spalte gibt die Mountpoints an, in der zweiten Spalte steht der Name einer sogenannten Map-Datei, und die dritte definiert die zugehörigen Mount-Optionen. Wenn Sie nun auf das Verzeichnis /xxx zugreifen wollen, erkennt dies das Autofs-Modul; der Automount-Daemon liest die auto.master-Datei aus und sieht, dass alle weiteren Informationen in der Datei /etc/auto.xxx abgelegt sind. Dort liest er die hinterlegte Vorgehensweise aus. Diese Map-Datei ist ähnlich aufgebaut wie die Master-Datei.

cdrom      -fstype=iso9660      :/dev/cdrom
dokus      -ro,intr,soft        ftp.bobcom.de:/pub/linux/HOWTO
win2k      -fstype=vfat,ro      :/dev/hdc1

Das erste Beispiel in Listing 2 verfügt, dass Daten-CDs mit dem ISO-9660-Dateisystem über die Gerätedatei /dev/cdrom ins Unterverzeichnis /xxx/cdrom eingebunden werden. Die zweite Zeile mountet das Verzeichnis /pub/linux/HOWTO vom NFS-Server ftp.bobcom.de nur lesbar (“read only”) per manuell unterbrechbarem Softmount ins lokale Verzeichnis /xxx/dokus (bei NFS-Mounts muss kein Filesystemtyp angegeben werden), während die lokale VFAT-Windows-Partition /dev/hdc ebenfalls nur lesbar bei Bedarf unter /xxx/win2k zu finden ist.

Anhand der Erkenntnisse aus dieser Map setzt der Automounter den Mount-Vorgang in Gang, und kurz darauf können Sie sich im implizit angeforderten neuen Verzeichnis bewegen. Wenn Sie längere Zeit (Defaultwert ist fünf Minuten) nicht mehr darin befinden, erfolgt ein automatischer Unmount.

Manche fragen sich jetzt sicher, was bei gleichzeitigem Schreibzugriff mehrerer Clients auf eine Datei passiert. Hier werden – ähnlich einer Datenbank – die Files gelockt, d. h. für den weiteren Gebrauch gesperrt, und selbst in eine Datenbank eingetragen. Hierbei erhält der verantwortliche “Network Lock Manager” (NLM) Schützenhilfe vom “Network State Monitor” (NSM), der die Aktivitäten der am NFS-Zugriff beteiligten Maschinen überwacht. Hat ein Client einen Zugriff beendet oder muss neu booten, entsperrt der Lock Manager die Dateien und gibt sie für die Öffentlichkeit wieder frei.

Die Zukunft

Obwohl NFS V2 schon vor mehreren Jahren einen neuen Bruder in Gestalt der Version 3 (NFS V3) erhielt, wird es immer noch vorherrschend eingesetzt. Dennoch findet langsam aber sicher der Umstieg auf NFS V3 statt, die aus Kompatibilitätsgründen fast alle alten Prozeduren übernimmt, aber neue Features einbringt. So kann man bei Version 3 zwischen den beiden Transport-Protokollen UDP und TCP wählen. Der Einsatz von TCP entlastet den Dienst, da es die Fehlerbehandlung übernimmt und somit eine sichere Leitung gewährleistet. Der Preis dafür ist eine erhöhte Netzbelastung. Die Größenlimits werden heutigen Verhältnissen angemessener gestaltet bzw. ganz aufgehoben, sodass nun auch Dateien größer als zwei GB und Dateisysteme größer als 4 GB vorkommen dürfen. Zudem gibt es einen zusätzlichen asynchronen Schreib- und Lesemodus, der die Geschwindigkeit deutlich erhöht. Dabei wird nicht wie beim synchronen Zugriff ein Arbeitsvorgang komplett abgeschlossen, sondern die bearbeiteten Daten beim Server zwischengespeichert und bei geeigneter Gelegenheit gesammelt festgeschrieben. Abbildung 6 zeichnet die entsprechenden Vorgänge schematisch nach.

Abbildung 6: Der neue, asynchrone Schreibmodus von NFS V3

Auch bei den Lesezugriffen kommen neue Prozeduren zum Zuge. So werden bei einem ls -al o. ä. klassischerweise zuerst alle Daten übertragen und anschließend die Attribute der Objekte (Größe, Speicherstelle im Dateisystem, Verlinkungen oder Besitzrechte). Bei Version 3 erledigt eine vollständig neue Prozedur dies alles in einem Aufwasch und sorgt so für eine Performancesteigerung.

Seit Mitte 2001 arbeiten Sun und die Universität von Michigan an der vierten Version (NFS V4). Die Tests sind weitestgehend abgeschlossen, sodass der Standard voraussichtlich noch 2002 verabschiedet wird.

Augen auf im Datenverkehr!

Bei aller Freude über die Möglichkeiten von NFS sollten Sie Ihre Schritte und Einstellungen wohl überdenken, da jede Öffnung Ihres Systems eine potentielle Gefahrenquelle in sich birgt. Nehmen Sie lieber ein paar Unannehmlichkeiten mehr in Kauf, als Ihr System von Beginn an sperrangelweit zu öffnen. Vermeiden Sie allzuviele Wildcards in Ihren Berechtigungen, passen Sie auf root-Rechte auf, und planen Sie Ihre Netzzugriffe genauestens, denn Angreifer von außen können bei entsprechender Rechtevergabe ebenfalls auf Ihren Server zugreifen.