Hallo,
am 30.01.2014 stand das Thema NFS (Network File System) auf der
Tagesordnung der Lugrav, genauer gesagt die aktuelle Version 4 von
NFS.
Bekanntlich kann ein NFS-Server ein Filesystem "exportieren", so dass
es von einem NFS-Client "importiert" werden kann. Auf diesem Wege kann
ein NFS-Client ein exportiertes Filesystem des NFS-Servers wie ein
lokales Filesystem mounten und nutzen.
NFS ist in unixoiden Firmennetzen verbreitet. Aber auch für den
Heimanwender gibt es Szenarien, für die NFS eine Lösung bieten kann.
Beispiele:
- einem Desktop mit starker CPU vom NAS aus heruntergeladene
Medien-Dateien zur Verfügung zu stellen, um sie zu dekodieren,
- den Nutzern eines Heimnetzes auf allen Rechnern ihre vertrauten
Heimverzeichnisse zur Verfügung stellen,
- mit NFS als Brücke auf ein ZFS-Filesystem zugreifen, obwohl der
Rechner des Endusers über keinen ZFS-Client verfügt,
- der Klassiker: Rechner ohne lokal vorhandene Filesysteme betreiben,
d.h. ohne eigene Platte, USB-Stick, SDHC-Karte oder dergleichen,
- ...
Weil dieser Vortrag den Auftakt der Serie über Serverdienste bildete,
wurden die allgemeinen Eigenschaften von NFS beleuchtet, die es von
anderen Serverdiensten unterscheidet.
Betrachtet wurden Offenheit, Transparenz, Skalierbarkeitund
Sicherheit.
An diesen Eigenschaften entscheidet sich, ob ein bestimmter Server-
dienst, der die gesuchte Funktionalität abbildet, für eine gegebene
Aufgabenstellung in Frage kommt.
Die aktuelle Version 4 von NFS eignet sich für die Nutzung übers
Internet dank Verschlüsselung, Caching und zahlreichen Verbesserungen
im Bereich der internen Pfadauflösung.
Diese Version kann mit nur einem offenen Port unter TCP betrieben
werden. Mountd, portmapper und lockd können fortfallen, bleiben aber
aktiviert. Erstmals tritt idmapd als Daemon hinzu. Die Konfiguration
der Firewall vereinfacht sich deutlich.
Manche Eigenschaften großer Serverdienste fehlen noch. Das gilt z.B.
für die Datenreplikation.
Ebenso fehlen auch Positions- und Migrationstransparenz. Mit Version 4
braucht der NFS-Client immer noch präzise Kenntnis über den Netzwerk-
Standort des NFS-Serverdienstes und eventuellen Verlagerungen.
Bei NFS unter Debian Wheezy fällt auf, dass die Versionen 2, 3 und 4
gleichzeitig aktiv sind. Portmapper, mountd und lockd sind auch
dann aktiv, falls sie nicht gebraucht werden.
Das scheint für viele Distributionen zu gelten (wurde von mir nicht
geprüft)
Ein Parameter, einzelne Versionen ein- oder auszuschalten, fehlt.
Dafür muss man entweder sehr tief ins System eingreifen. Gebraucht
werden ein selbst kompilierter Kernel, ein neu zusammengestelltes
Initial Filesystem und weitere Konfigurationen unter /etc.
Als Workaround kommt ein Paketfilter in Frage, der alle
UDP-Verbindungen auf dem einzig benötigten NFS-Port blockiert.
Ins Auge sprang auch, dass NFS in allen Versionen nicht kaskadierbar
ist.
Diese Aussage stieß zunächst auf Unglauben.
Dennoch: Ein NFS-Server kann kein Filesystem exportieren, welches er
gleichzeitig selber importiert hat.
Die Manpage zu exportfs stellt das bereits im ersten Satz klar. Nur
lokal vorhandene Filesysteme können exportiert werden. Von remote
existierenden Filesystemen ist dort nicht die Rede.
Die technische Ursache findet sich im NFS-Protokoll. Nach dem Mounten
des entfernten Filesystems werden zwischen Server und Client nur noch
Dateihandles ausgetauscht. Für die Identifikation des Servers am
Ende der Kaskade, auf welchen ein mittlerer NFS-Server ja zugreifen
können müsste, ist im Protokoll einfach kein Platz vorgesehen.
Aus diesem Grunde scheiterte ad hoc der Versuch, ein Filesystem
gleichzeitig zu im- und zu exportieren. Die Demonstration endete mit
einer Fehlermeldung.
In der Praxis kann man sich behelfen, indem man den NFS-Client
anweist, jenes Verzeichnis direkt bei dem NFS-Server am Ende der Kette
abzuholen.
Denn nichts und niemand hindert den Client, mehrere NFS-Server
parallel zu nutzen. Das wird auf Client-Seite beim Mounten des
Filesystems geregelt.
Nach der Pause führte der zweite Teil des Abends in die Praxis.
Die Aufgabe lautete: "gleiche Heimverzeichnisse für Nutzer". Jeder
Einzelschritt von der Installation bis zur Inbetriebnahme wurde
vorgeführt und erläutert.
Dabei kamen subtile Tücken zur Sprache, die sich aufgrund der
unterschiedlichen Namensräume ergeben können und vom Daemon idmapd nur
zum Teil aufgefangen werden.
Auf dem Treffen wurde ein 5-seitiges Handout verteilt.
Es dokumentiert jeden Einzelschritt und belegt damit, wie einfach NFS
Version 4 aufzusetzen ist. Die Beschreibung einer geeigneten simplen
Firewall gehört dazu.
Das Handout beschreibt darüber hinaus in der Art eines Steckbriefs
die wichtigsten Eigenschaften von NFS 4 und gibt Fundstellen zum
Selbststudium.
Das Handout mag ergänzt werden. Auf Blatt 2 kann unter der Überschrift
"Offenheit" die Aussage "Frühere Versionen von Winlos benötigen einen
Zusatz, z.B. SFU." am Ende des 2. Absatzes ergänzt werden.
Mit diesem Hinweis endet mein Bericht über die Auftakt-Veranstaltung
der Lugrav zum Thema Serverdienste.
Manch anderes Thema kam auf diesem Treffen auch zur Sprache. Weil
diese Mail bereits so lang geworden ist ("T'schuldigung"), schildere
ich keine Details.
pv:)