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:)