Unter den Netzwerk-Dateisystemen ist NFS das bekannteste und verbreitetste. Verzeichnisse entfernter Rechner vermag es so einzubinden, dass sie aus Benutzerperspektive wie lokale Ressourcen erscheinen.

Ein entferntes Dateisystem ist immer zugleich ein zentralisiertes – das macht zum großen Teil seinen Nutzen aus: Von vielen Anwendern benötigte Daten werden an einem Ort, auf dem Server, gepflegt und gesichert. Nutznießer sind die Clients, die weder Kopien noch Plattenkapazität dafür brauchen, keine verschiedenen Versionen synchronisieren müssen und sich nicht mit Backups oder Ausfallsicherheit belasten.

Dennoch arbeiten sie mit den entfernten Files so wie mit lokalen. Hat ein Benutzer sein Homeverzeichnis auf dem Fileserver, darf er von Arbeitsstation zu Arbeitsstation laufen und hat dennoch stets seine Daten und die eigenen Programmeinstellungen zur Hand.

Ein Benutzer sieht einem Verzeichnis auch nicht ohne weiteres an, ob es sich auf einem lokalen oder entfernten Dateisystem befindet. Für ihn macht das beim Lesen, Schreiben, Löschen, Verschieben oder Kopieren keinen Unterschied. Hinter den Kulissen spielen sich in beiden Fällen allerdings grundverschiedene Dinge ab.

Lokal gespeicherte Dateien, die in untereinander verketteten Datenblöcken eines Filesystems residieren, sind über den Wurzelblock der Kette, den so genannten Inode erreichbar. Er speichert neben der Adresse des ersten Datenblocks eine Reihe weiterer Informationen: Eine unverwechselbare Nummer, die Größe des File, die Zugriffsrechte oder verschiedene Zeitstempel. Diese Angaben gibt das Kommando »stat« aus, zum Beispiel »stat /etc/hosts«:

File: `/etc/hosts'
Size: 193          Blocks: 8 
IO Block: 4096     reguläre Datei
Device: 306h/774d  Inode: 99758  Links: 1
Access: (0644/-rw-r--r--) 
Uid: (    0/    root) 
Gid: (    0/    root)
Access: 2004-10-21 15:39:32.170288696
Modify: 2004-10-21 14:49:24.964453472
Change: 2004-10-21 14:49:24.985450280

Dateioperationen auf einem entfernten NFS-Dateisystem erledigt dagegen der Server stellvertretend für den Client. Der entfernte Rechner adressiert das gewünschte File über ein Handle, das er vom Server auf Nachfrage erhält. Zusammen mit dem Handle kann er danach eine von 18 Aktionen in Auftrag geben, die zum Leistungsangebot des NFS-Servers gehören.

Protokoll-Suite

Als Sun im Jahr 1984 NFS auf den Markt brachte, erschien zeitgleich eine ganze Sammlung verwandter Protokolle unter dem Namen ONC (Open Network Computing). Abbildung 1 zeigt die ONC-Architektur im Vergleich zu anderen Modellen, von denen sich letztlich nur TCP/IP durchgesetzt hat. NFS liegt im ONC-Modell mit anderen Protokollen in der Anwendungsschicht. Dazu gehören das Protokoll für das File-Locking NLM (Network-Lock-Manager) sowie NSM (Network-Status-Monitor).

Aufgabe des XDR-Protokolls (External Data Representation) eine Schicht darunter ist es, die zu übertragenden Daten in ein einheitliches Format zu konvertieren. So lassen sich Dateien unabhängig von der eingesetzten Hardware und vom Betriebssystem verarbeiteten. Wieder eine Schicht tiefer befindet sich das RPC-Protokoll (Remote Procedure Call,[2]). Mittels RPC können Programme Funktionen anderer Programme auf einem entfernten Rechner nutzen.

Jedes Programm, das Funktionen via RPC anbieten will, muss sich bei einem besonderen Service registrieren, dem Portmapper. Als Kontaktvermittler sammelt er die Dienstangebote inklusive der Informationen zu Protokoll und dynamisch vergebener Portnummer für die Kontaktaufnahme in einer Datenbank und gibt sie auf Anfrage an die Clients weiter. Der Ablauf ist in Abbildung 2 dargestellt.

Abbildung 1: Im ONC-Modell ist NFS auf der Anwendungsschicht angesiedelt (OSI-Schicht 7), XDR auf Schicht 6 des OSI-Modells. Das klassische TCP/IP-Modell fasst die Schichten 5 bis 7 zusammen.

Vermittlerdienste

Besonders ältere Versionen des Portmappers können leicht Sicherheitsprobleme heraufbeschwören. Neuere lassen sich zumindest darauf verpflichteten, nur Anfragen aus dem lokalen Netz zu beantworten. Diese Einstellung ist auf jeden Fall angeraten. Eingerichtet wird sie mit Einträgen im Format »portmap: Hosts« in einer der beiden Dateien »/etc/hosts.deny« oder »/etc/hosts.allow«. Welche Programme der Portmapper kennt und vermittelt, zeigt »rpcinfo -p«. Das Beispiel eines NFS-Servers zeigt das Listing 1.

Die Arbeit eines NFS-Servers teilen sich üblicherweise die beiden Daemons »mountd« und »nfsd« im Duett. Ersterer prüft die Mount-Requests der Clients auf Machbarkeit und Zulässigkeit, Letzterer startet eine konfigurierbare Anzahl Kernel-Threads, die dann die eigentlichen NFS-Operationen übernehmen.

Abbildung 2: Der Portmapper fungiert als Kontaktvermittler zwischen RPC-Server und -Client. Der Client erfragt den Port, über den er sich direkt mit dem Server verbinden kann.

Daemons im Duett

Manchmal gibt es noch einen speziellen Daemon »rquotad«, der Höchstgrenzen für den belegbaren Plattenplatz pro User überwacht. Ein Linux-System startet diese Dienste gewöhnlich durch ein Init-Skript »nfs« oder »nfsserver«. Abhängig von Distribution, NFS- und Kernelversion müssen unter Umständen die beiden Daemons für das Locking – »lockd« und »statd« – separat gestartet werden. Ob alle Dienste ordnungsgemäß laufen, kann man mit »ps -A | grep rpc« und »ps -A | grep nfs« kontrollieren.

Da aktuelle Distributionen mit einem Nfsd arbeiten, der hauptsächlich im Kernel integriert ist, muss sichergestellt sein, dass die entsprechenden Kernelmodule geladen sind. Das lässt sich sehr leicht mit einem Aufruf von »lsmod | grep nfs« feststellen:

nfsd             172769  9
exportfs           6593  1 nfsd
lockd             53256  2 nfsd
sunrpc           140325  19 nfsd,lockd

Neben dem »nfsd« in Form eines Kernelmoduls gibt es auch eine Version, die komplett im Userspace läuft. Sie ist jedoch mit Nachteilen behaftet: Ihre Performance ist wesentlich schlechter als die des Kernelmoduls und sie unterstützt die Protokolle des Network-Status-Managers (NSM) und des Network-Lock- Managers (NLM) ebenso wenig wie Dateien, die größer als 2 GByte sind.

01    Program Vers Proto   Port
02     100000    2   tcp    111  portmapper
03     100000    2   udp    111  portmapper
04     100024    1   udp  32768  status
05     100024    1   tcp  32769  status
06     100011    1   udp    958  rquotad
07     100011    2   udp    958  rquotad
08     100011    1   tcp    961  rquotad
09     100011    2   tcp    961  rquotad
10     100003    2   udp   2049  nfs
11     100003    3   udp   2049  nfs
12     100003    4   udp   2049  nfs
13     100003    2   tcp   2049  nfs
14     100003    3   tcp   2049  nfs
15     100003    4   tcp   2049  nfs
16     100021    1   udp  32816  nlockmgr
17     100021    3   udp  32816  nlockmgr
18     100021    4   udp  32816  nlockmgr
19     100021    1   tcp  33142  nlockmgr
20     100021    3   tcp  33142  nlockmgr
21     100021    4   tcp  33142  nlockmgr
22     100005    1   udp    980  mountd
23     100005    1   tcp    983  mountd
24     100005    2   udp    980  mountd
25     100005    2   tcp    983  mountd
26     100005    3   udp    980  mountd
27     100005    3   tcp    983  mountd

Ein Verzeichnis, das ein Client in seinen lokalen Dateibaum einbinden möchte, muss der Server zuvor exportieren. Die Einstellungen dafür liegen in der Datei »/etc/exports«, die Mountd und Nfsd lesen. Es ist auch möglich, Verzeichnisse temporär mit dem Kommando »exportfs« freizugeben:

exportfs -o ro,sync 
server1.example.com:/var/ftp/pub

Das Kommando würde beispielsweise das komplette Verzeichnis »/var/ftp/pub« lesend für den Rechner »server1.example.com« freigeben. Möchte der Administrator das Verzeichnis wieder von der Freigabe ausschließen, muss er »exportfs« mit der Option »-u« aufrufen:

exportfs -u 
server1.example.com:/var/ftp/pub

Sind Freigaben aktiv, egal ob mit dem Kommando »exportfs« oder durch einen Eintrag in der Datei »/etc/exports«, zeigt der Befehl Showmount sie anschließend an. Für den Rechner Tiffy produziert »showmount -e tiffy« zum Beispiel:

Export list for tiffy:
/var/ftp/pub/rhel3-es 
192.168.0.0/255.255.255.0

/var/ftp/pub/rhel3-es/  
192.168.0.0/255.255.255.0(ro,sync) 
192.168.1.0/255.255.255.0(rw,sync)

Showmount listet zwar die exportierten Verzeichnisse und die zugelassenen Clients, es fehlt allerdings eine genaue Übersicht der gesetzten Export-Optionen. Diese Information steht auf dem Server in der Datei »/var/lib/nfs/etab«:

/var/ftp/pub/rhel3-es
192.168.0.0/255.255.255.0(ro,sync,wdelay,
hide,nocrossmnt,secure,root_squash,
no_all_squash,subtree_check,
secure_locks,anonuid=-2,anongid=-2)

Abbildung 3: Wer seinen Server gerne grafisch konfigurieren möchte, kann bei Fedora auf »system-config-nfs« zurückgreifen.

Ein Linux-System verwaltet User intern nicht anhand der User- und Gruppennamen, sondern anhand der numerischen User- und Gruppen-IDs. Gehört eine Datei auf dem NFS-Server beispielsweise dem User »tscherf« mit der UID 500 und hat dieser User Lese- und Scheibrechte für diese Datei, dann erhielte nach dem Importieren der Datei via NFS ein Benutzer auf dem Client, der dort lokal unter der UID 500 geführt wird, dieselben Rechte an der Datei. Sind Server- und Client-Benutzer trotz gleicher UID verschiedene Leute, wäre dies sicher nicht wünschenswert.

Einen Ausweg bietet das so genannte Squashing, das schon im Zusammenhang mit den Export-Einstellungen erwähnt wurde. Die Option »root_ squash« bewirkt, dass jeder Zugriff von dem Benutzer Root auf ein mit diesem Flag exportiertes Filesystem tatsächlich unter der UID des Benutzers »nobody« oder »nfsnobody« erfolgt. All-squash ist dagegen dafür zuständig, dass NFS alle Zugriffe von beliebigen Usern auf »nobody» oder »nfsnobody« umsetzt.

Abbildung 4: Auch für NFS-Clients gibt es grafische Tools, hier ein Beispiel aus der Suse-Distribution. Neben dem Namen des Servers, des exportierten Verzeich-nisses und des lokalen Mountpoints können auch Optionen angegeben werden .

Squashing hilft nicht immer

Squashing ist allerdings nicht in jedem Fall ein gangbarer Weg, beispielsweise wenn NFS Homeverzeichnisse exportiert. Würde man die Zugriffe auf sie immer auf die User-ID eines einzigen Users umleiten, der in diesen Verzeichnissen dann Lese- und Schreibberechtigung haben müsste, dann gäbe es keine Privatsphäre im Heimatverzeichnis mehr: Jeder könnte bei jedem alles ändern und keiner nachvollziehen, wer welchen Eingriff zu verantworten hat.

Diese Fälle zwingen daher zu identischen User- und Gruppen-IDs auf Server und Clients. Da das manuell schwer realisierbar und fehlerträchtig wäre, haben sich verschiedene Systeme entwickelt, die Benutzerinformationen zentral verwalten. Sun komplettierte ihr NFS schon in der Anfangszeit mit NIS (Network Information System) und später NIS+, eine andere Option wäre LDAP.

Prozesskette

Greift der Client auf eine freigegebene Datei zu, läuft im Hintergrund eine ganze Kette aufeinander aufbauender Aktionen ab. Zunächst muss er beim ersten Zugriff auf den NFS-Server ermitteln, unter welchen Ports er »mountd« und »nfsd« erreichen kann. Diese Informationen erfragt er beim Portmapper. Möchte der Client die Datei exklusiv bearbeiten, benötigt er ebenfalls die Adressen von »lockd« und »statd«.

Im nächsten Schritt benutzt der Client die eben erfragte Portnummer, um sich nun direkt an den Mountd auf dem Server zu wenden. Dieser durchsucht die Datei »/var/lib/nfs/etab« danach, ob das angefragte Verzeichnis überhaupt exportiert wird und ob der Client berechtigt ist darauf zuzugreifen. Gehen beide Prüfungen positiv aus, besorgt »mountd« von seinem Kompagnon »nfsd« ein Dateihandle, das die vom Client gewünschte Datei eindeutig referenziert.

Mountd schickt das Handle zurück an den anfragenden Client. Der Client kann nun direkt Handle und Arbeitsanweisung an den »nfsd« auf Server-Seite senden und damit die fragliche Datei zum Beispiel lesen, schreiben oder auch löschen. Der gesamte Vorgang ist in Abbildung 5 dargestellt.

Eine Liste der Verzeichnisse, die der Server exportiert, kann sich der Client mit Hilfe des Kommandos »showmount -e« besorgen. Das Mount-Kommando dient anschließend dazu, die gewünschte Freigabe einzubinden. Ein Beispiel dafür wäre:

mount -t nfs -o ro 
tiffy:/var/ftp/pub/rhel3-es/ /mnt/daten/

Zu beachten ist, dass der lokale Mountpoint existiert, bevor das Mount-Kommando ausgeführt wird. Die möglichen Parameter sind im Kasten “Mount-Optionen” zusammengestellt.

Verschieden eingebunden

Das Einbinden externer Dateisysteme mittels »mount« auf der Kommandozeile hat allerdings den entscheidenden Nachteil, dass die Informationen über die Verknüpfung zwischen externem Dateisystem und lokalem Mountpoint nur bis zum nächsten Neustart erhalten bleibt. Deshalb ermöglicht die Datei »/etc/fstab«, die während des Bootens gelesen wird, dauerhafte Verknüpfungen. Sie wird auch konsultiert, wenn ein Anwender auf der Client-Seite »mount -a« eingibt. Doch Vorsicht: Hat sich lediglich eine Mount-Option geändert, ist »mount -o remount /Mountpoint« nötig. Dagegen bindet ein einfaches »mount -a« nur neue Dateisysteme ein, ändert aber nicht die Optionen von bereits eingehängten Filesystemen.

Eine weitere Möglichkeit für das automatische Einbinden bietet der Automounter. Er initiiert den Mountvorgang, sobald ein beliebiger Prozess auf den Mountpoint zugreift. Die Konfiguration findet sich in den Dateien »/etc/auto.master« und »/etc/auto.misc«. Damit diese Automatik auch funktioniert, muss der entsprechende Automount-Daemon laufen.

Exklusivrechte

In einem verteilten Dateisystem können mehrere Clients gleichzeitig auf dieselbe Datei zugreifen. In der Regel möchte man diese problematischen Aktionen verhindern und reserviert die Datei oder Teile von ihr für einen Client. Unter Linux löst der Kernel diese Aufgabe. Implementiert wird diese Funktion innerhalb einer Anwendung durch den Systemaufruf »fcntl()« (File Control).

Möchte ein Client exklusiven Zugriff auf eine Datei haben, sendet er diese Anforderung an der Kernel. Wenn sich die zu sperrende Datei innerhalb einer NFS-Freigabe befindet, leitet der Kernel die Anforderung an den lokalen Network- Lock-Manager (NLM, »rpc.lockd«) weiter. Von dort geht die Anfrage an den »lockd« auf dem NFS-Server. Der bearbeitet sie und schickt das Ergebnis an den NLM des Clients zurück. Der Kernel kann die Sperre schließlich ausführen. Voraussetzung ist, dass der NLM sowohl auf dem Client als auch auf dem Server gestartet ist.

Abbildung 5: Auf seine Mount-Anforderung erhält der Client ein Dateihandle, das er zusammen mit Arbeitsanweisungen (etwa Lesen oder Schreiben) an den NFS-Daemon schickt.

Nachricht bei Neustart

Wenn Client oder Server rebooten, kommt der Network-Status-Manager (NSM, »rpc.statd«) ins Spiel. Hat der »lockd« des Servers eine Datei gesperrt, dann gibt er diese Information an den NSM weiter und vermerkt im Verzeichnis »/var/lib/nfs/sm« den Name des Clients. Der Client behält seinerseits den Namen des Servers, der die Sperre durchgeführt hat. Verantwortlich dafür ist erneut der NSM.

Rebootet der Client, liest er den Namen des oder der NFS-Server, von denen er Verzeichnisse gemountet hatte, aus dieser Datei und kontaktiert deren Network-Status-Monitore. Die leiten die Information an den jeweiligen NLM weiter. Dieser hebt die Sperre auf. Fällt der Server aus, läuft das Spiel anders herum ab. Die Clients werden beim Reboot informiert und erhalten so die Möglichkeit, ihre Sperren erneut anzufordern und zu aktualisieren. Findet keine Aktualisierungsanfrage statt, hebt der Server die Locks auf.

Ein Problem ist der Einsatz von Datei-sperren immer noch in Cluster-Umgebungen. Da die Locking-Informationen in lokalen Dateien liegen und ein Cluster sie im Falle eines Failovers nicht auf einen anderen Knoten überträgt, stehen sie danach nicht mehr zur Verfügung.

Filesharing für alle Fälle

NFS ist für das Filesharing in kleineren und mittleren Netzen eine erprobte, weit verbreitete und Systemgrenzen übergreifende Lösung. Im Unterschied zu verteilten Filesystemen für sehr große Netze (siehe dazu den anschließenden AFS-Artikel) ist das Network File System auch ohne große Spezialkenntnisse zu administrieren. (jcb)