© die*Mel*, Photocase.com

Ein neues Sicherheitskonzept, umfangreiche Aufräumarbeiten rund ums Locking und Leases, dazu Optimierungen vor allem fürs WAN geben dem betagten NFS neuen Schwung.

Geliebt und gefürchtet ist NFS unter Linux-Administratoren. Die meisten kennen Geschichten von hängen gebliebenen File-Servern oder -Clients, die als Konsequenz ganze Heerscharen von Rechnern mit ins Verderben rissen (siehe vorherigen Artikel). Gleichzeitig hat das schon 1985 von Sun veröffentlichte Protokoll kaum gleichberechtigte Konkurrenz, zumindest keine, die zu ähnlich eindrucksvollen Übertragungsraten in der Lage ist. NFS gilt als der Netzwerk-Filesystem-Standard in Unix-Umgebungen.

Verbesserungen

Seit der Jahrtausendwende ist Version 4 als RFC 3530 [1] spezifiziert und langsam verbreitet sie sich auch in den Rechenzentren. Die Entwickler haben den Finger genau auf die alten Wunden gelegt, die neue Implementierung verfolgt im Wesentlichen fünf Ziele:

• Weitere Steigerung der Performance
• Optimierung vor allem fürs Internet
• Eingebaute sichere Verschlüsselungs- und
  Authentifizierungsmechanismen
• Bessere Unterstützung für heterogene Netzwerke
• Leichte Integration zukünftiger Erweiterungen

Klassische Probleme

Das Netzwerk-Filesystem stammt aus einer Zeit, als das Internet noch in den Kinderschuhen steckte. Verschlüsselung und starke Authentifizierung ließen sich in alten Versionen höchstens durch externe Programme und zusätzliche Serversoftware erreichen, meist nur über große Hürden. Wer Ende der 90er Jahre versucht hatte, NIS mit LDAP und NFS zum Laufen zu kriegen, kann ein Lied davon singen.

Die Benutzer von Windows-Rechnern griffen in der Regel über kommerzielle Tools wie Suns PC/NFS oder Pathways Client für NFS auf den Server zu. Mit Windows 2000 kamen zwar die umfangreichen Werkzeuge aus Microsofts SFU-Paket (Services For Unix, [2]), zufriedenstellende Ergebnisse brachten aber meist eher die kommerziellen Programme und viele Admins mussten sich mit Problemen bei langen Dateinamen und den Unterschieden bei der Rechteverwaltung herumschlagen.

Die wichtigsten Neuerungen im Überblick

Abbildung 1 gibt einen Überblick über die auffälligsten Neuerungen in NFS 4:

• Ein komplett neues, integrierte Sicherheitsmodell mit Kerberos,
  dem Generic Security Service (GSS, [3]) und dem Simple Public-Key
  GSS-API Mechanism (SPKM, [4]).
• Diverse Dienste sind direkt in das NFS-Protokoll
  überführt.
• Der Lock-Manager arbeitet jetzt im Server und ermöglicht
  umfangreiche Optionen rund um Leases.
• Compounds beschleunigen die Übertragung und erhöhen
  die Flexibilität.
• Als Übertragungsprotokoll steht nur noch TCP zur
  Verfügung, UDP fällt komplett weg.
• Die exportierten Filesysteme stellt NFS 4 als virtuelles,
  zusammenhängendes Dateisystem (VFS) dar.
• Eine neue, kompatiblere Syntax dient für die Benutzer-,
  Gruppen- und Hostnamen.

Wer sich detaillierter für die Änderungen seit Version 3 und die geplanten nächsten Schritte interessiert, findet mehr Details auf der Webseite von NFS 4 [5] oder in den übersichtlichen Architekturdiagrammen der Linux Foundation [6].

Für Aufsehen sorgte Version 4 durch ihre fortschrittliche Sicherheitsarchitektur, die den wichtigen Schritt in Richtung User-basierte Authentifizierung für Mounts darstellt. Kerberos [7], SPKM und der Low Infrastructure Public Key Mechanism (LIPKEY, [8]) kommen dafür auf Basis des GSS zum Einsatz. Über den Gssd als Usermode-Daemon und den Identity Mapper Idmapd [9] setzt das GSS-API Benutzernamen und IDs jetzt über Strings wie »Benutzername@Rechnername« um. Ganz nebenbei macht dies NFS deutlich kompatibler mit Windows-Systemen, darüber hinaus stellt der Idmap die Kompatibilität zu LDAP-basierten Systemen und alternativen Sicherheitsprotokollen sicher.

Abbildung 1: Die Neuheiten in NFS 4 (rechts) erstrecken sich vom Userspace bis in den Kernelspace. Schon auf den ersten Blick fällt auf, dass einige Dienste wie der Lockd und der Mountd weggefallen sind, NFS 4 den Portmapper nicht mehr verwendet und eine Sicherheitsarchitektur mit Kerberos, SPKM und GSS hinzugekommen ist. (Bild: © Nach einer Idee der Linux Foundation)

Nur noch einer

Weil NFS 4 nur noch den TCP-Port 2049 benutzt, freut sich auch der Firewall-Administrator, für den jetzt komplexere NAT-Operationen kein Problem mehr darstellen. Früher, als der Portmapper die Ports für die verschiedenen Serverdienste wie Mountd, Lockd und Statd dynamisch zuwies, waren vielerorts regelrechte Hacks notwendig, um die Firewall ums NFS herumzubiegen.

In der aktuellen Version haben die Entwickler diese Dienste entsorgt oder in das Protokoll integriert und so den Portmapper überflüssig gemacht. Als zusätzliches Bonbon zur Beschränkung auf TCP gibt\’s noch Statefulness und Kontrollmechanismen, die alte Versionen wegen UDP auf höheren Schichten realisierten.

Caching, Compounds, virtuelle Filesysteme

Wie zu erwarten war, haben die Programmierer auch an vielen anderen Ecken und Kanten geschliffen. Dank intelligentem, verteilbarem Caching und verbessertem, teilweise delegierbarem Locking eignet sich NFS 4 besser für Replikation und Migrationen, die Version ist deutlich resistenter gegen Systemcrashes und vor allem viel flotter als ihre Vorgänger, sagen die Entwickler.

Der wesentliche Grund dafür findet sich in den Roundtrip-Optimierungen mit den Compound Procedures. Dieser Trick gestattet es dem Client, mehrere Anfragen in ein Paket zu packen und sie gleichzeitig an den Server zu schicken. Ein Paper auf der NFS-4-Homepage [10] rechnet detailliert vor, wie der identische Mountbefehl unter NFS 3 elf Roundtrips verursacht, unter NFS 4 jedoch nur zwei. Gerade in Netzen mit hoher Latenz wie bei klassischen WAN-Verbindungen dürfte sich das positiv bemerkbar machen.

Das neue Protokoll erlaubt es, virtuelle Filesysteme (VFS) auf Client und Server abzubilden. Wie bei FTP oder HTTP existiert für einen Client ein Eingangspunkt, ein Root-Verzeichnis, unterhalb dessen der Server die freigegebenen Directories und Dateien bereitstellt (Abbildung 2). Der Client hat nur den Blick auf das virtuelle Dateisystem. Er sieht die wirklichen Strukturen auf dem Server nicht und kann nur, von seiner Wurzel ausgehend, Netzwerklaufwerke mounten. Auf jedem NFS-Server darf es somit aber auch nur eine Freigabe mit der »fsid=0« geben, sonst wäre Verwirrung programmiert. Weil NFS innerhalb der Exporte allerdings Symlinks erlaubt, ist die altbekannte Flexibilität wieder sichergestellt.

Abbildung 2: Dank des virtuellen Filesystems von NFS ahnt der Client (rechts) nichts davon, dass der Server (links) die eingebundenen Freigaben von völlig unterschiedlichen physikalischen Lauf-werken gemountet hat.

Leases, Handles und Locks, Open statt Lookup

Admins heterogener Umgebungen werden die neu implementierten Dateihandles schätzen. Wo früher Groß- oder Kleinschreibung von Dateinamen Probleme verursachte, kommen heute eindeutige, aber temporäre (volatile) Dateihandles zum Einsatz, die der Server aus Device- und Inode-Nummer generiert. Damit unterstützt NFS 4 Case-sensitive Betriebssysteme und erweiterte Datei-Attribute besser, mit den neuen Named Attributes kann der Admin sogar beliebige eigene Erweiterungen hinzufügen.

NFS 4 ersetzt Lookups durch »open()«-Funktionen und führt das Konzept der Leases ein. Dateien, für die viele Benutzer auf verschiedenen Rechnern Leserechte benötigen, kann der Server jetzt erstmals an alle gemeinsam verleihen. Überhaupt präsentiert sich der ganze Komplex des Locking, früher über den Daemon »lockd« repräsentiert, komplett überarbeitet. NFS kann Dateien jetzt auch exklusiv an einen Benutzer verleihen, wenn dieser auf sie schreiben möchte. Das Locking ist jetzt vollständig ins Protokoll, der Lock-Manager in den Server integriert. NFS 4 unterstützt damit auch Mandatory Locking [11].

ACLs

Wie schon bei den alten Versionen prüft auch NFS 4 Server-seitig die Zugriffsrechte und Access Control Lists (ACLs) auf Dateien. Aber wo früher zahlreiche Roundtrips nötig waren, um die Sequenz der Lookup- und Access-Prozeduren zu durchlaufen, ermöglicht NFS 4 den direkten Zugriff auf die Unix-Funktion »access()« [12].

Mit ihr lassen sich die Berechtigungen anzeigen, ohne die Datei selbst zu öffnen. Die von NFS 4 verwendeten nativen ACLs ähneln denen von CIFS [13] und arbeiten daher deutlich unkomplizierter mit Samba und Windows-Systemen zusammen. Wie diese funktionieren und wie sich das passende Kernelpatch einspielen lässt, dokumentiert ein Suse-Howto [14]. Selbstverständlich unterstützt NFS 4 aber auch Posix-ACLs.

Ernsthafte Verbesserung

Auch wenn die komplexe Kerberos-Installation und -Konfiguration für NFS 4 an vielen Stellen noch Probleme bereitet, wird sich das Konzept sicher durchsetzen. Die umfangreichen Neuerungen von NFS 4 zeugen vom ernsthaften Bestreben der Entwickler, die gesteckten Ziele umzusetzen, wenn auch mit Verzögerung.

Auch Dokumentation gibt es viel: Zahlreiche Howtos sind im Umlauf, meist sparen sie aber gerade den problematischsten Teil (Kerberos) aus. Im Web finden sich Anleitungen zu Fedora [15], Gentoo [16], Suse [17], Ubuntu [18] und eine Migrationshilfe für Admins, die von NFS 3 auf NFS 4 umziehen [19]. Als Nebenwirkung der Neuerungen sind die beiden Versionen nämlich nicht mehr miteinander kompatibel.