Netzwerk Dateisysteme - I4 * Lehrstuhl fuer Informatik * RWTH Aachen

Rheinisch-Westfälische Technische Hochschule Aachen
Lehrstuhl für Informatik IV
Prof. Dr. rer. nat. Otto Spaniol
¡£¢¥¤§¦ ¡©¨�������¢¥¡©���£����¢�¡©� ¡
Proseminar: Kommunikationsprotokolle
SS2003
Juliane Mathes
Matrikelnummer: 235672
Betreuung: Mesut Günes
Lehrstuhl für Informatik IV, RWTH Aachen

Inhaltsverzeichnis
1 Einführung 4
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Grundlagen von Netzwerkdateisystemen 5
2.1 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 NFS - das bekannteste Netzwerkdateisystem 6
3.1 Geschichtliches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Spezifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Unterschiede NFS Version 2 und NFS Version 3 . . . . . . . . . . . . . . . . . . . . 8
3.4 Schwächen von NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5 NFS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5.1 Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5.2 Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5.3 Kommandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.6 NFS Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6.1 Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6.2 Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.6.3 Kommandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.7 Beispiel für NFS-Server und NFS-Client . . . . . . . . . . . . . . . . . . . . . . . . 13
3.7.1 Aufbau eines NFS-Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.7.2 Zugriff über verschiedene NFS-Clients . . . . . . . . . . . . . . . . . . . . 15
4 Andere Netzwerkdateisysteme 16
4.1 CIFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2 AFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 Speichernetze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2

5 Zusammenfassung 18
Abbildungsverzeichnis
1 Übermittlung des RPC Port eines Dienstes vom Server an den Client . . . . . . . . . 7
2 Ablauf des mount Vorgangs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Asynchrones Schreiben bei NFS Version 3 . . . . . . . . . . . . . . . . . . . . . . . 9
4 Netzwerk mit einem NFS-Server und zwei Clients . . . . . . . . . . . . . . . . . . . 14
5 Ein Speichernetz trennt Server und Speichergeräte . . . . . . . . . . . . . . . . . . 17
Übersicht der Abkürzungen
Abkürzung Bedeutung
ACL Access Control List
AFS Andrew File System
CIFS Common Internet File System
FTP File Transfer Protocol
NAS Network Attached Storage
NFS Network File System
RFC Request for Comments
RPC Remote Procedure Call
SAN Storage Area Network
SMB Server Message Block
TCP Transmission Control Protocol
UDP User Datagram Protocol
UID userID interne Benutzernummer, die vom System verwendet wird
XDR External Data Representation
3

1 Einführung
1.1 Motivation
Jeder handelsübliche Rechner und jede Workstation ist heute mit großen Festplatten ausgestattet, so
dass es an Speicherplatz nicht mangelt. Werden mehrere Rechner vernetzt, dann sind die Daten eines
Benutzers auf der Festplatte eines bestimmten Rechners gespeichert. Diese auf mehrere Rechner
verteilte Speicherung der Daten ist von Nachteil, da der Zugriff auf die Daten nur von diesem einen
Rechner aus erfolgen kann. Die regelmässige Datensicherung muss über mehrere Rechner hinweg
erfolgen und ist daher sehr aufwendig. Software, die auf jedem Rechner installiert ist, muss bei Erscheinen
einer neuen Version auf jedem einzelnen Rechner auf den neusten Stand gebracht werden.
Abhilfe schafft ein Netzwerkdateisystem. Es ermöglicht den gemeinsamen Zugriff auf Daten, die auf
einem zentralen Server bereitgestellt werden. Die Daten können von verschiedenen Rechnern aus
von allen Benutzern, die auf diese Daten individuell Zugriff haben, erreicht werden. Für den Benutzer
macht es keinen Unterschied, ob die Daten lokal oder auf einem entfernten Rechner liegen. Er
merkt dies im Idealfall überhaupt nicht. Die Sicherung von Daten erfolgt zentral auf dem Server. Die
Aktualisierung eines Softwarepakets wird zunächst auf dem Server durchgeführt. Damit wird eine
automatische Aktualisierung der Software auf den Clients möglich. Diese Methode ist dann nützlich
wenn Software aus Sicherheitsgründen innerhalb kürzester Zeit aktualisiert werden muss, wie zum
Beispiel bei Virenscannern. Vertrauliche Daten werden durch Zugriffsrechte geschützt und sind nur
bestimmten Benutzern zugänglich. Für manche Arbeitsbereiche wie zum Beispiel Softwareentwicklung
ist es wichtig, dass mehrere Benutzer gleichzeitig an einem Projekt arbeiten und auf gemeinsame
Dateien zum gleichen Zeitpunkt zugreifen können. Der simultane Zugriff auf Dateien wird von einem
Netzwerkdateisystem geregelt.
1.2 Zielsetzung
Durch ein Netzwerkdateisystem werden Daten für alle Rechnerarchitekturen transparent verfügbar
gemacht und stehen im gesamten Netzwerk bereit. Die Daten werden zentral auf einem oder mehreren
Servern abgelegt. Die Benutzerverwaltung ist ebenfalls zentral geregelt, das Betriebssystem der
einzelnen Rechner spielt im Hinblick auf Dateisystem und Benutzerverwaltung eine unwesentliche
Rolle. Der Benutzer kann sich durch die zentrale Benutzerverwaltung an jedem Rechner im lokalen
Netzwerk (LAN) anmelden und findet dort durch das Netzwerkdateisystem immer seine gewohnte
Arbeitsumgebung vor. Die Zugriffsbeschränkungen werden durch den Server auf Dateien und Verzeichnisse
vergeben und kontrolliert, es ist kein unbefugter Zugriff auf Daten möglich. Der Zugriff
auf Daten kann von mehreren Benutzern gleichzeitig erfolgen und es stehen Funktionen zum Auffinden
und Beseitigen von Fehlern bereit. Auf dem Server erfolgt eine regelmässige Datensicherung. Im
Falle der Fälle ist eine schnelle Wiederherstellung der Daten möglich.
4

1.3 Aufbau der Arbeit
In dieser Arbeit wird das Konzept und der Aufbau von Netzwerkdateisystemen beschrieben und ihre
Funktionsweise erläutert. Das Network File System (NFS) wird vorgestellt und an einem Beispiel detailliert
erklärt. Es werden weitere Netzwerkdateisysteme beschrieben sowie ihre Vor- und Nachteile
miteinander verglichen. Im Ausblick werden andere Ansätze zur zentralen Verwaltung von Daten im
Netzwerk vorgestellt.
2 Grundlagen von Netzwerkdateisystemen
2.1 Funktionsweise
Netzwerkdateisysteme erlauben einen transparenten Zugriff auf Daten eines Servers von enfernten
Rechnern (Clients) aus. Ein oder mehrere Server bieten Verzeichnisse mit Dateien und Programmen
für andere Rechner an. Der Server stellt Funktionen zur Authentifizierung der Clients und der Benutzer,
zur Übermittlung der Daten, zum Auffinden und Beseitigen von Fehlern sowie zur Regelung
des gleichzeitigen Zugriffs von mehreren Rechnern auf eine Datei bereit. Die Clients binden die Verzeichnisse
des Servers so in das lokale System ein, dass der Benutzer des Clients keinen Unterschied
zwischen lokalen und entfernten Daten bemerkt. Ein Benutzer meldet sich mit Benutzernamen und
Passwort auf einem Client an und versucht auf Daten zuzugreifen, die auf einem Server gespeichert
sind. Der Client fordert dann beim Server die Daten für diesen Benutzer an. Der Benutzer selbst muss
nicht wissen, wo diese Dateien liegen, er merkt nichts von der Kommunikation zwischen den beiden
Rechnern. Der Server verifiziert den Client und den Benutzer und ermittelt, welche Berechtigungen
der Benutzer auf welche Verzeichnisse oder Dateien hat. Ist dem Benutzer der Zugriff auf die angeforderten
Daten erlaubt, so werden die Daten zum Client übertragen. Ist der Zugriff nicht erlaubt, so
wird eine entsprechende Fehlermeldung an den Client geschickt. Bei erfolgreicher Authentifizierung
kann der Benutzer mit den Daten so arbeiten, als ob diese lokal gespeichert wären.
2.2 Anforderungen
Für den reibungslosen Ablauf der Kommunikation im Netzwerkdateisystem soll dieses folgende Eigenschaften
erfüllen.[1]
Zugriffstransparenz: Benutzer oder Programme merken beim Zugriff auf Dateien nicht, ob auf ein
lokales oder auf ein entferntes Dateisystem zugegriffen wird
Ortstransparenz: Der tatsächliche Speicherort der Daten ist dem Benutzer unbekannt und kann
sich ändern, für den Benutzer scheinen die Daten immer an derselben Stelle zu liegen.
Fehlertransparenz: Nach Ausfällen von Client oder Server wird der Dateibetrieb reibungslos wieder
aufgenommen.
5

Leistungstransparenz: Verzögerung durch Zugriff auf entfernte Dateien bei Schreib-/Lesezugriffen
sollen möglichts vermieden werden. Zu diesem Zweck werden die Daten beim Client und beim
Server in einem Cache abgelegt.
Nebenläufigkeitstransparenz: Der gleichzeitige Zugriff von mehreren Benutzern auf ein und dieselbe
Datei verursacht keine Inkonsistenzen.
Zugriffstransparenz: Für jede Datei und jedes Verzeichnis wird festgelegt, welche Benutzer oder
welche Gruppen welche Zugriffsrechte haben. Dabei wird zwischen verschiedenen Berechtigungen,
beispielsweise Lesen, Schreiben und Ausführen unterschieden.
3 NFS - das bekannteste Netzwerkdateisystem
3.1 Geschichtliches
Die Firma Sun Microsystems begann 1984 damit, ein System zu entwickeln, das den transparenten
Zugriff auf entfernte Daten ermöglichen sollte. Das Network File System (NFS) Version 1 gelangte
jedoch nicht zum praktischen Einsatz, sondern wurde direkt zur Version 2 weiterentwickelt. Ein Jahr
später wurde die Version 2 von NFS vorgestellt und inklusive der Spezifikation veröffentlicht. Die
Herausgabe der Spezifikation stellte zu dieser Zeit eine Neuheit dar, da solche Interna üblicherweise
nicht veröffentlicht wurden. Die Bereitstellung der Spezifikation von NFS ist einer der Hauptgründe
für die weite Verbreitung dieses Netzwerkdateisystems. NFS wurde auf weitere Plattformen wie BSD,
HP-UX, AIX und Linux portiert. Die Version 3 von NFS wurde 1987 vorgestellt. Sie ist eine Erweiterung
der Version 2 und zu dieser abwärtskompatibel. Beide Version laufen neben- und miteinander,
das heißt, Server und Client können auch dann miteinander kommunizieren, wenn auf einem Rechner
NFS Version 3 und auf dem anderen noch NFS Version 2 eingesetzt wird. Der Funktionsumfang ist
dann allerdings auf Version 2 beschränkt. Seit Dezember 2000 existiert eine Spezifikation für NFS
Version 4, Ziele dieser Version sind der verbesserte Zugriff und Durchsatz von NFS übers Internet
sowie strenge Sicherheitsmechanismen des NFS-Protokolls. Diese Version ist ebenfalls abwärtskompatibel
zu Version 3 und Version 2, sie ist bis jetzt aber noch nicht im praktischen Einsatz.
3.2 Spezifikation
Das Netzwerkdateisystem NFS wird durch die Request for Comments (RFC) 1094 [2], 1813 [3] und
3010 [4] beschrieben. NFS stellt netzwerkweit Dateien zur Verfügung, das Netzwerkdateisystem ist
in einer Client-Server-Struktur organisiert. Ein oder mehrere Server bieten Verzeichnisse für viele
verschiedene Clients an. Der NFS-Server ist ein zustandsloser Server, es werden keine Statusmeldungen
an die Clients geschickt. Per NFS ist es möglich, Verzeichnisse auf entfernten Rechnern auf dem
lokalen Rechner so einzubinden, dass clientseitig der Eindruck einer einzigen großen Festplatte entsteht.
Das Netzwerkdateisystem ist portabel über Rechner, Systeme und Netzwerkprotokolle hinweg.
6

Die Portabilität wird durch die Verwendung von Remote Procedure Calls (RPC) [6] gesichert. Das
RPC-Protokoll verwaltet mit einem eigenem Dienst, dem Portmapper, das Angebot an Diensten und
deren Funktionen, die ein Rechner anbietet. NFS ist einer der Dienste.
Abbildung 1: Übermittlung des RPC Port eines Dienstes vom Server an den Client
Abbildung 1 zeigt den Ablauf der Kommunikation zwischen zwei Rechnern über RPC. Jeder RPC-
Dienst wird durch den Rechnernamen und die zugehörige Portnummer des Dienstes angesprochen.
Beim Start des Rechners registrieren sich die Dienste beim Portmapper und melden die Nummer des
Ports, über den der Dienst mit anderen Rechnern kommuniziert. Der Client fragt beim Portmapper
des Servers nach der Portnummer für den Dienst, der genutzt werden soll. Anschliesend kommuniziert
der Client direkt mit dem Sever über den zurückgelieferten Port. Der Portmapper ist an dieser
Kommunikation nicht mehr beteiligt.
Auf einem NFS-Server müssen beim Booten der NFS-Dienst nfsd und der Mount-Dienst mountd
gestartet werden. Das d an dem Namen der Dienste weisst daraufhin, dass es sich um einen Daemon
handelt, der im Hintergrund läuft und auf Anfragen wartet. Der NFS-Dienst gibt Verzeichnisse zum
Exportieren frei. Der Mount-Dienst ist für den Zugriff auf ein angefordertes Verzeichnis verantwortlich.
Weitere nützliche Dienste sind in diesem Zusammenhang der Network State Monitor (NSM)
statd und der Network Lock Manager (NLM) lockd. Sie koordinieren den gleichzeitigen Zugriff
auf ein und dieselbe Datei. Der Quota-Dienst rquotad beschränkt die Speicherplatzgröße, die
einem Benutzer zur Verfügung steht.
Jedes UNIX Dateisystem ist hierarchisch aufgebaut, die Wurzel des Verzeichnisbaums wird mit ,,/”
bezeichnet. Verzeichnisse von anderen Rechnern können an jedem beliebigen Punkt unterhalb der
Wurzel eingehängt werden. Der Vorgang, dass ein Client beim Server ein Verzeichnis anfordert und
dieses dann in das eigene Dateisystem einhängt, wird als mounten bezeichnet. Der Einhängepunkt
muss vorher existieren. Das Gegenstück zum mount ist umount. Der Inhalt des Verzeichnisses wird
mit Hilfe von umount aus dem Verzeichnisbaum ausgekoppelt.
Abbildung 2 stellt den Ablauf eines mount Vorgangs dar. Beim Zugriff des Clients auf den NFS-
Server fragt der Client zuerst beim Portmapper des Servers nach den Portnummern von Mount- und
7

NFS-Dienst. Über die Portnummern nimmt der Client mit dem Mount-Dienst des Servers direkt Kontakt
auf und fordert den Zugriff auf ein bestimmtes Verzeichnis an. Der Mount-Dienst überprüft, ob
dieses Verzeichnis per NFS verfügbar ist und ob der Client die nötigen Berechtigungen besitzt. Es
werden die Zugriffsberechtigungen des Rechners auf das exportierte Verzeichnis überprüft. Der Benutzer
wird von NFS nicht authentifiziert. Bei erfolgreicher Authentifizierung des Rechners wendet
sich der Mount-Dienst an den NFS-Dienst und bekommt von diesem ein Dateihandle auf das Verzeichnis
geliefert. Dieses Dateihandle sendet der Mount-Dienst an den Client. Alle weiteren Zugriffe
auf das vom Client angeforderte Verzeichnis erfolgen danach direkt zwischen dem Client und dem
NFS-Dienst des Servers. Der Client prüft die Berechtigungen des Benutzers auf das Verzeichnis und
erlaubt oder verweigert den Zugriff.
Abbildung 2: Ablauf des mount Vorgangs
NFS arbeitet auf unterschiedlichen Systemen und Hardware-Plattformen, so dass die Darstellung der
Daten unterschiedlich ausfällt. Das External Data Representation Protocol (XDR) [8] konvertiert die
zu übermittelnden Daten für die Übertragung in ein standardisiertes Format und nach der Übermittlung
auch wieder zurück.
3.3 Unterschiede NFS Version 2 und NFS Version 3
Die Version 3 ist eine Erweiterung der Version 2. Die Veränderungen führen zu mehr Leistung und dadurch
zu einem schnelleren Zugriff auf die Daten. Eine der wichtigsten Neuerungen ist der asynchrone
Schreib-/ Lesezugriff, der die Geschwindigkeit deutlich erhöht. Beim synchronen Zugriff werden Daten,
die ein Client an den Server schickt, direkt auf dem Server geschrieben und der Client erhält eine
Bestätigung. Im Gegensatz dazu werden beim asynchronen Zugriff die Daten zuerst auf dem Server
zwischengespeichert und der Client erhält eine Empfangsbestätigung. Zu einem günstigen Zeitpunkt
werden die gesammelten Daten auf dem Server dann aus dem Cache auf das Speichermedium geschrieben
und der Client bekommt eine Nachricht über den erfolgreichen Schreibvorgang. Erst nach
8

dieser Vollzugsbestätigung verwirft der Client die Daten in seinem Cache. Abbildung 3 beschreibt
den asynchronen Schreibvorgang.
Die Obergrenze bezüglich der Übertragungsgröße wird gestrichen. Andere Größenlimits werden angepasst
oder ganz aufgehoben. In der Version 3 kann als Übertragungsprotokoll zwischen User Datagram
Protocol (UDP) [11], einem verbindungslosen Transportprotokoll, und Transmission Control
Protocol (TCP) [12], einem verbindungsorientierten Transportprotokoll, gewählt werden. In Version
2 wird nur mit UDP gearbeitet. Den immer größeren Dateien und Dateisystemen wird durch die
Unterstützung von 64 Bit langen Dateizeigern Rechnung getragen.
3.4 Schwächen von NFS
Abbildung 3: Asynchrones Schreiben bei NFS Version 3
NFS gewährt einem Client-Rechner Zugriff auf ein exportiertes Verzeichnis, nicht einem Benutzer.
Der NFS-Server prüft anhand der IP-Adresse des Clients, ob der Client auf das Verzeichnis zugreifen
darf. Die Authentifizerung des Benutzers geschieht bei NFS durch den Client-Rechner über die
interne Nummer des Benutzers (UID). Sie wird vom Client-System beim Zugriff auf das gemountete
Verzeichnis überprüft. Beim Anlegen des Benutzers auf dem Client wird diese UID erstellt. Wird
der Benutzer auf einem anderen Client zusätzlich angelegt, dann muss darauf geachtet werden, dass
er dort die gleiche UID besitzt. Wird dieselbe UID fälschlicherweise an verschiedene Benutzer vergeben,
erhalten alle diese Benutzer Zugriff auf dieselben Daten. Benutzern wird damit der Zugriff
auf Daten erlaubt, den sie eigentlich nicht bekommen dürften. Durch eine einheitliche Benutzerverwaltung,
bei der die Benutzer zentral eingerichtet werden und dann auf allen Clients zur Verfügung
stehen, tritt dieser Effekt nicht mehr auf. Beispiele für eine zentrale Benutzerverwaltung sind Yellow
Pages (YP) oder der Nachfolger Network Information Service (NIS+).
Der NFS Server ist ein zustandsloser Sever, das heißst, den Clients werden keine Informationen über
den Status des Servers übermittelt. Dies ist bei einem Ausfall des Servers nachteilig, da die Clients
9

immer wieder versuchen, den Server zu erreichen und so das eigene System verlangsamen oder ganz
lahmlegen. Werden zum Beispiel Verzeichnisse des Servers beim Systemstart des Clients gemountet
und der Server ist nicht erreichbar, dann wiederholt der Client den Mount-Vorgang solange, bis der
Server wieder erreichbar ist. Dieser Prozess läuft im Hintergrund ab, kostet aber Ressourcen.
NFS verfolgt das Ziel, Daten für alle Rechner, unabhängig vom Betriebssystem des Clients, bereitzustellen.
In einer UNIX Umgebung ist NFS auf allen Systemen vorhanden und zwischen diesen
funktioniert der Datenaustausch. Anders hingegen sieht es in einem heterogenen Netzwerk aus, in
dem Windows und UNIX Systeme miteinander kommunizieren sollen. Ein Windows-Client kennt
kein NFS und kann nicht direkt auf einen NFS-Server zugreifen. Es existiert kein Protokoll, das den
direkten Zugriff von Windows-Clients auf einen NFS-Server ermöglicht. Der freiverfügbare Dateiserverdienst
SAMBA macht NFS-Ressourcen für Windows-Clients zugänglich. Dafür muss allerdings
der Benutzer unter beiden Betriebssystemen bekannt sein, da keine betriebssystemübergreifende Benutzerverwaltung
existiert.
NFS zeichnet sich im LAN durch gute Performance aus. Für Verbindungen über weite Entfernungen
ist es jedoch weniger geeignet. Grund hierfür sind nicht nur Performance Probleme sondern auch die
schon angesprochenen schwachen Sicherheitsmechanismen zum Schutz der Daten.
3.5 NFS Server
Als NFS Server kann jeder Rechner mit einem UNIX Betriebssystem arbeiten. Die Dienste sind
in der Regel auf dem Rechner bereits vorhanden aber nicht aktiv. Die Konfiguration des Rechners
geschieht durch Dateien, die von den Diensten eingelesen und ausgewertet werden. Die benötigten
Konfigurationsdateien und Kommandos sind auf allen UNIX Derivaten gleich, der Speicherort der
Dateien kann hingegen variieren. Die in dieser Arbeit verwendeten Pfade beziehen sich auf SuSE
Linux Version 8.0.
3.5.1 Dienste
rpc.mountd: Der Dienst implementiert das Mount-Protokoll. Wenn der Dienst eine Anfrage von einem
NFS-Client bekommt, prüft er in der Liste der exportierten Verzeichnisse, ob dem Client der
Zugriff erlaubt werden kann. Falls dem Client der Zugriff gewährt wird, liefert der Dienst ein Dateihandle
auf das angeforderte Verzeichnis an den Client zurück. Jede erfolgreiche Anforderung eines
exportierten Verzeichnisses wird in der Datei /var/state/nfs/rmtab eingetragen. Dieser Eintrag wird,
nachdem der Client das Verzeichnis nicht mehr importiert, wieder entfernt.
rpc.nfsd: Der Dienst exportiert die in der Datei /etc/exports festgelegten Verzeichnisse für bestimmte
Rechner oder Netzwerke mit den zugehörigen Optionen.
Die Dienste rpc.lockd, rpc.statd und rpc.quotad sind nicht zwingend für den Betrieb des NFS-
Servers erforderlich. Der Network Lock Manager lockd kontrolliert den gleichzeitigen Zugriff auf
eine Datei und akzeptiert oder verweigert diese. Das Ergebnis wird an den Lock-Daemon des Clients
10

übermittelt. Der Network State Monitor statd verwaltet die Statusmeldungen des Lock-Managers über
Dateisperren und reicht diese bei Bedarf an den Client weiter. Das Sperren einer Datei für exklusiven
Zugriff bleibt dem zugreifenden Programm überlassen, dies ist keine Aufgabe von NFS.
Durch den Dienst rpc.rquotad wird der dem Benutzer zur Verfügung stehende Speicherplatz begrenzt.
Die Quotas werden auf dem Server für jeden Benutzer individuell eingerichtet und dort überwacht.
Der Benutzer erhält eine Warnmeldung, wenn der ihm zur Verfügung stehende Speicherplatz
fast vollständig belegt ist. Er kann den Belegungsgrad auch selbst abfragen.
3.5.2 Dateien
/etc/rpc : Die Datei enthält eine Liste der laufenden Dienste und ihre Portnummern. Diese
�
Liste wird bei jedem Booten des Rechners neu erstellt.
� /etc/hosts.allow und /etc/hosts.deny : In diesen Dateien wird eingetragen, welche
Rechner, Gruppen von Rechnern oder Netzwerke auf bestimmte Dienste zugreifen dürfen
bzw. wem der Zugriff verboten ist. Jeder Eintrag besteht aus dem Namen des Dienstes gefolgt
von einer Liste der Rechner, die von ALLOW oder DENY beendet wird. Allgemein ist es
üblich, den Zugriff auf sicherheitskritsche Dienste zuerst komplett zu sperren und dann explizit
den Zugriff für das lokale Subnetz oder bestimmte Rechner zu erlauben.
� /etc/exports : Die Datei verwaltet die zu exportierenden Verzeichnisse. Ein Eintrag besteht
aus dem Namen des Verzeichnis, das exportiert werden soll, gefolgt von den zugelassenen
Clients. Die zu jedem Client gehörigen Zugriffsoptionen werden in Klammern hinter dem Client
angegeben. Der Eintrag /home *.rwth-aachen.de(rw) erlaubt jedem Rechner der
RWTH den schreibenden Zugriff auf das Verzeichnis /home des NFS-Servers. Dieses Schreibrecht
bedeutet nicht, dass jeder Benutzer auf dem Verzeichnis schreiben darf, sondern erlaubt
lediglich dem Client grundsätzlich den schreibenden Zugriff. Die Option ro deaktiviert den
Schreibzugriff des Clients auf das Verzeichnis, unabhängig davon, ob der Benutzer dort Schreibrechte
hat oder nicht. Alle Optionen und ihre Bedeutung erhält man durch den Befehl man
exportfs [16].
� /ect/init.d/nfsserver : Das Skript erledigt das Starten oder Stoppen der Dienste
rpc.mountd und rpc.nfsd. Damit diese Dienste beim Serverstart automatisch aktiviert werden,
müssen in dem Verzeichnis /etc/init.d/rcn.d Verweise auf das Skript angelegt werden.
Das n gibt die Nummer des Runlevels an, in dem ein bestimmter Dienst starten soll. Mehr zu
Runleveln und ihrer Konfiguration unter [13].
3.5.3 Kommandos
exportfs [-airuv] [host:/path] : Der Befehl exportiert ein Verzeichnis des Servers ,,per
Hand”.
11

-a Alle Verzeichnisse aus der Datei /etc/exports und aus der Kommandozeile werden exportiert.
-i Das Verzeichnis der Kommandozeile wird exportiert, die Datei /etc/exports wird nicht
ausgewertet.
-r Alle Verzeichnisse werden erneut exportiert, (äquivalent zu -u dann -a)
-u Alle exportierten Verzeichnisse werden nicht länger exportiert.
-v Statusmeldungen anzeigen (verbose mode)
showmount [-ae] : Durch den Befehl werden die exportierten Verzeichnisse des aktuellen Rechners
oder eines anderen Rechners aufgelistet.
-a Es werden die exportierten Verzeichnisse der Maschine ausgegeben.
-e hostname Die exportierten Verzeichnisse vom Rechner hostname werden aufgelistet.
nfsstat [-nr] : Der Befehl zeigt statistische Informationen zur Auslastung und zur Nutzung
des NFS Servers an.
-n Die für NFS spezifischen Werte werden angezeigt.
-r Es werden die für RPC spezifischen Werte ausgegeben.
3.6 NFS Client
Die exportierten Verzeichnisse eines NFS-Servers stehen jedem Rechner, der zum Zugriff berechtigt
ist, zur Verfügung. Der Benutzer kann diese Verzeichnisse mit dem Befehl mount in das Dateisystem
des Clients einfügen. Beim jedem Neustart des Clients muss dieser Mount-Vorgang wiederholt
werden. Dies ist für oft benutze Verzeichnisse unpraktisch. Abhilfe schafft das feste Einbinden der
Verzeichnisse beim Hochfahren des Rechners. Hierzu werden die benötigten Verzeichnisse genau wie
lokale Laufwerke in der Datei /etc/fstab eingetragen. Eine andere Möglichkeit ist das Ein- und
Aushängen eines Verzeichnisses bei Bedarf. Dies wird durch einen Daemon, den Automounter, erledigt.
Der Automounter überwacht den Zugriff auf ein bestimmtes lokales Verzeichnis und mountet bei
Bedarf das entsprechende NFS-Verzeichnis. Findet über längere Zeit kein Zugriff mehr auf das lokale
Verzeichnis statt, so wird das NFS-Verzeichnis wieder entfernt. Das Verfahren des dynamischen Einund
Auskoppelns von Verzeichnissen in das Dateisystem wird zum Beispiel bei Homeverzeichnissen
genutzt.
3.6.1 Dienste
Zum Zugriff auf einen NFS-Server ist kein Dienst erfoderlich. Für die Benutzung des Automounters
muss der Dienst autofs konfiguriert werden. Dieser Dienst erzeugt für jedes Verzeichnis, das
dynamisch eingebunden werden soll, einen Automounter-Daemon, der das Verzeichnis überwacht.
12

3.6.2 Dateien
� /etc/fstab : In der Datei werden alle statischen Informationen über Dateisysteme, die
Einhängepunkte und Optionen verwaltet. Ein Eintrag in der Datei besteht aus sechs Feldern,
die durch Leerzeichen voneinander getrennt sind. Der Eintrag marple:/home /home nfs
rw,bg 0 0 besagt, dass das Verzeichnis home des Servers marple an der Stelle /home in das
Dateisystem eingehängt werden soll. Der Typ des Dateisystems ist nfs, die Optionen sind auf
Standardwerte gesetzt. Die erste Spalte eines solchen Eintrags gibt an, welches Gerät oder Verzeichnis
gemountet werden soll. Der zweite Eintrag gibt den Einhängepunkt im Dateisystem
an, der dritte legt den Typ des Dateisystems fest. Das vierte Feld enthält die Optionen für den
Mount-Vorgang. Die beiden letzten Felder geben an, ob und in welcher Reihenfolge ein Backup
oder eine Überprüfung des Dateisystems stattfinden soll. All diese Begriffe werden ausführlich
und gut unter [13] erklärt.
� autofs : Das Skript startet den autofs-Dienst. Der Dienst überwacht alle Verzeichnisse, die
in der Datei /etc/auto.master angegeben sind, und mountet bei Bedarf das zugehörige
Verzeichnis vom NFS-Server. Nach längerer Nichtbenutzung wird das Verzeichnis wieder aus
dem Dateisystem ausgehängt. Damit der autofs-Dienst beim Hochfahren des Clients gestartet
wird, müssen Verweise auf das Skript in den einzelnen Runleveln angelegt werden. Die Vorgehensweise
wird in [13] erklärt.
� auto.master : Die Datei enthält eine Liste von Verzeichnissen, die durch den autofs-Dienst
überwacht werden sollen. Jeder Eintrag besteht aus dem Verzeichnisnamen sowie dem Namen
einer Datei, der keymap. In dieser Datei ist das zu mountende Verzeichnis mit den zugehörigen
Optionen angegeben. Mehr Informationen zur Syntax dieser Datei erhält man durch den Befehl
man autofs [16].
3.6.3 Kommandos
mount [-t vfstype] [-o options] device dir : Durch diesen Befehl wird das Gerät
oder Verzeichnis device an der Stelle dir in das lokale Dateisystem eingehängt. Mit dem Paramter
-t kann der Typ des Dateisystems angegeben werden. Mit -o werden weitere Optionen gesetzt und
die Standardwerte verändert. Alle Optionen und ihre Bedeutung erhält man durch den Befehl man
mount [16].
umount dir : Dies ist das Gegenstück zum Befehl mount. Mit dem Befehl wird das Verzeichnis
dir wird aus dem Dateisystem ausgehängt.
Der Befehl showmount -e hostname zeigt die auf dem Server hostname über NFS verfügbaren
Verzeichnisse an. Die genaue Syntax dieses Befehl ist unter Abschnitt 3.5.3 zu finden.
3.7 Beispiel für NFS-Server und NFS-Client
Das konkrete Beispiel zeigt den Aufbau und die Konfiguration eines NFS-Servers unter Linux sowie
den Zugriff von verschiedenen Clients aus. Um Unstimmigkeiten der UIDs zu vermeiden, existieren
13

Abbildung 4: Netzwerk mit einem NFS-Server und zwei Clients
auf allen Maschinen die gleichen Benutzer mit den gleichen UIDs und Passwörtern. In einem grösseren
Netzwerk sollte die Benutzerverwaltung über ein System wie NIS geregelt werden. Der Server
marple bietet die Verzeichnisse /opt und /home. Auf diese Verzeichnisse soll der Client stringer
Zugriff haben. Dem Client craddock soll kein Zugriff auf die Verzeichnisse erlaubt werden. Der
Aufbau des Netzwerks ist in Abbildung 4 zu erkennen.
3.7.1 Aufbau eines NFS-Servers
Die Installation der benötigten Pakete und die Konfiguration des NFS Servers muss als Benutzer root
durchgeführt werden, da nur dieser die nötigen Rechte besitzt. Zuerst wird auf dem Server das Paket
nfs-utils und, falls noch nicht geschehen, der Portmapper (Paket portmap) installiert.
In der Datei /etc/host.deny wird durch den Eintrag nfs: ALL der Zugriff per NFS von allen
Maschinen aus verboten. Der Eintrag rpc.mountd : 192.168.99.*/255.255.255.0:
ALLOW in der Datei /etc/hosts.allow berechtigt alle Rechner des Subnetzes 192.168.99 zum
Zugriff per NFS. Die Verzeichnisliste und die zugehörigen Optionen werden in /etc/exports angegeben.
/opt 192.168.99.*(ro)
/home 192.168.99.*(rw,no root squash)
Dann wird der NFS Server gestartet:
marple:/etc/init.d # ./nfsserver start
Starting kernel based NFS server done
und das Ergebnis überprüft.
marple:/etc/init.d # showmount -e marple
Export list for marple:
/opt 192.168.99.*
/home 192.168.99.*
14

3.7.2 Zugriff über verschiedene NFS-Clients
Auf dem Client werden keine besonderen Pakete für den Zugriff auf Verzeichnisse über NFS benötigt,
da das mount Kommando zum Linux System gehört. Im folgenden Beispiel werden zwei verschiedene
Client Rechner betrachtet. Der Client stringer hat die IP Adresse 192.168.99.2. Damit gehört er
zum lokalen Subnetz, weshalb ihm der Zugriff auf den Server erlaubt ist. Der Client craddock hat
die IP Adresse 192.168.100.3. Er gehört nicht zum lokalen Subnetz und hat daher keinen Zugriff auf
den NFS-Server.
Dem Clients stringer ist der Zugriff auf die exportierten Verzeichnisse des NFS-Servers gestattet.
Auf dem Client werden, falls noch nicht vorhanden, die Verzeichnisse /sw und /home mit dem Befehl
mkdir /sw;mkdir /home erstellt. Durch den Befehl
stringer:/ # mount marple:/home /home -obg,hard,rw
wird das Verzeichnis ’zu Fuss’ gemountet. Der mount Vorgang kann durch den Befehl mount überprüft
werden. Das Verzeichnis /home erscheint dann in der Liste der gemounteten Verzeichnisse.
Eine andere Möglichkeit besteht darin, den Namen des zu importierenden Verzeichnisses in der Datei
/etc/fstab einzutragen. Das Verzeichnis marple:/opt wird dann beim Booten des Clients an der
Stelle /sw eingehängt oder kann nachträglich mit dem Befehl
stringer:/ # mount /sw
mount: can’t find /sw in /etc/fstab or /etc/mtab
eingehängt werden. Weil im Beispiel der erwähnte fstab-Eintrag noch nicht vorhanden ist, führt der
Befehl zu einer Fehlermeldung. In der Datei /etc/fstab wird deswegen folgende Zeile hinzugefügt
marple:/opt /sw nfs bg,hard,ro 0 0. Damit wird festgelegt, dass das Verzeichnis
/opt des Servers marple im Verzeichnis /sw auf dem Client eingehängt wird. Als Dateityp wird nfs
angeben, die Optionen sind bg, rw, hard. Die beiden Nullen sorgen dafür, dass auf dem Verzeichnis
beim Booten keine Überprüfung des Dateisystems ausgeführt wird.
Danach wird das Verzeicnis /sw erneut gemountet, diesmal mit Erfolg. Der folgende Befehl zeigt,
dass beide Verzeichnisse vom Server gemountet wurdenin das Dateisystem des Clients eingehängt
wurden.
stringer:/etc # mount
/dev/hda3 on / type reiserfs (rw)
/dev/hda2 on /boot type ext2 (rw)
marple:/home on /home type nfs (rw,bg,hard,addr=192.168.99.1)
marple:/opt on /sw type nfs (ro,bg,hard,addr=192.168.99.1)
Dem Client stringer ist der Zugriff auf die exportierten Verzeichnisse des Servers erlaubt, da
sich beide Rechner in demselben Subnetz befinden und der NFS-Server den Zugriff von Rechnern
aus demselben Subnetz erlaubt. Anders sieht es bei dem Rechner craddock aus. Auf Grund der
IP-Adresse gehört der Rechner zu einenem anderen Subnetz als der Server. Diesem Rechner ist der
Zugriff auf den NFS-Server verboten, ein mount-Vorgang schlägt daher mit einer Fehlermeldung fehl.
15

craddock: # mount marple:/opt /sw
mount: marple:/opt failed, reason given by server: Permission denied
Das Beispiel bietet einen kurzen Einblick in die Arbeitsweise von NFS und zeigt das Zusammenspiel
zwischen Client und Server. Weitere Möglichkeiten wie der Aufbau eines komplexen Netzwerks oder
die Benutzung von autofs zum dynamischen mounten von Homeverzeichnissen werden in diesem
Beispiel nicht erläutert.
4 Andere Netzwerkdateisysteme
4.1 CIFS
Das Common Internet File System (CIFS) dient zur Verbindung von Windows-Rechnern in einem
Netzwerk. Es setzt auf TCP/IP auf und ist wie NFS in einer Client-Server-Struktur organisiert. Das
Netzwerkdateisystem beruht auf Server Message Block (SMB). Dieser Mechanismus ist der Vorläufer
von CIFS und wird bei Windows 3.11 und Windows95/98 eingesetzt. Über sogenannte Freigaben
können Rechner auf Verzeichnisse oder Festplatten anderer Rechner zugreifen. Anders als bei NFS
erfolgt bei CIFS ab WindowsNT die Freigabe von Verzeichnissen für Benutzer und nicht für Rechner.
Die Benutzer werden von einem zentralen Server, dem Domänen-Controller verwaltet. Auf dem
Server werden Freigaben eingerichtet und die Benutzer erhalten auf diese Freigaben Berechtigungen.
Ein Benutzer meldet sich auf dem Client an und wird, bevor er Zugriff auf die Freigaben des Servers
erhält, von diesem authentifiziert. Der Zugriff auf Dateien wird durch Access Control Lists (ACL) auf
dem Server kontrolliert.
Seit WindowsNT Service Pack3 werden die Passwörter verschlüsselt im Netzwerk übertragen, in allen
vorherigen Versionen erfolgte eine unverschlüsselte Übergabe des Passwortes. Durch die Kopplung
des Dateizugriffs an einen Benutzer reagiert das CIFS sehr empfindlich auf eine Unterbrechung der
Verbindung zum Server. Der Benutzer verliert unter Umständen Daten und muss sich nach Wiederherstellung
der Verbindung erneut am Server anmelden.
4.2 AFS
Als gemeinsames Projekt von IBM und der Carnegie-Mellon-University wurde das Andrew File System
(AFS) entwickelt. AFS ist ein verteiltes Netzwerkdateisystem. Anders als bei NFS werden bei
AFS die Dateien über mehrere Dateiserver verteilt. Der Benutzer muss nicht wissen, auf welchem
Fileserver seine Daten liegen, da sich die AFS-Verzeichnisstruktur über Links in das Dateisystem
integriert. Jedes lokale Dateisystem ist eine AFS-Zelle. Diese Zellen werden zu einem globalen AFS-
Katalog zusammengefügt, so dass prinzipiell alle Daten im AFS weltweit zugänglich sind. Durch
diese Skalierbarkeit des Dateisystems bietet sich AFS auch für den Einsatz in grossen Netzwerken
oder dem Internet an. Die Berechtigungen der Benutzer werden wie bei CIFS in ACLs verwaltet.
16

AFS unterstützt die Replikation von Dateien. Von jeder Datei können read-write-Kopien und readonly-Kopien
auf anderen Servern existieren. Der Client entscheidet dann, welche Version er von welchem
Server anfordert. Die Replikation bietet eine gewisse Sicherheit bei Serverausfällen. Eine solche
Replikation wird von NFS standardmässig nicht unterstützt. AFS wird zur Zeit auf UNIX-Servern
aufgesetzt und läßt sich sowohl von Windows- als auch auf UNIX-Clients aus nutzen.
4.3 Speichernetze
Im Zuge der stetig wachsenden Speicherkapazität entstehen Alternativen zum herkömmlichen Speichermedium
Festplatte. Speichernetze (Storage Area Networks, SAN) trennen Server und Speicher,
diese Trennung wird in Abbildung 5 verdeutlicht. Die vielen kleinen Festplatten und Bandlaufwerke,
die an jeden Server angeschlossen sind, werden durch wenige große Speichergeräte ersetzt. Dieser
Vorgang wird als Speicherkonsolidierung bezeichnet.
Abbildung 5: Ein Speichernetz trennt Server und Speichergeräte
Speichernetze können an zwei Stellen zwischen Anwendung und Festplatte geschaltet werden. Blockorientierte
Speichernetze ersetzten das lokale Datenkabel durch ein serielles Netzwerk. Dieses Netzwerk
kann auch grössere Entfernung überbrücken, die Geräte kommunizieren weiterhin blockorientiert
miteinander. Mehrere Server können dann auf das gleiche Speichermedium zugreifen, die Speichergeräte
sind unabhängig von den Rechnern. Auch beim Network Attached Storage (NAS) ist der
Speicher unabhängig von den Rechnern. Im Gegensatz zu SAN treten bei NAS die Speichermedien
selbst als Dateiserver auf. Auf diese vorkonfigurierten Server wird dann dateiorientiert durch Anwendungsprotokolle
wie NFS oder CIFS zugegriffen.
SAN und NAS sind keine konkurrierenden Konzepte sondern zwei verschiedene Techniken, die sich
kombinieren lassen. Ein NAS-Server kann ein Speichernetz hervorragend zur Speicherung oder Sicherung
von Daten nutzen.
17

5 Zusammenfassung
Die Arbeit stellt die generelle Idee und den Aufbau von Netzwerkdateisystemen vor und beschreibt
die an sie gestellten Anforderungen. Das Netzwerkdateisystem NFS wird erläutert und die Vor- und
Nachteile von NFS werden aufgezeichnet. Die Dateien und Dienste, die zum Funktionieren von NFS
notwendig sind, werden detailliert beschrieben, sowie einige nützliche Kommandos im Umgang mit
NFS erläutert. Anschliessend wird in einem Beispiel der Aufbau eines NSF Servers erklärt und die
Kommunikation zwischen Server und Clients gezeigt. Dann werden andere Dateisysteme wie CIFS
und AFS vorgestellt und ihre Unterschiede zu NFS untersucht.
In heutigen Netzwerken ist ohne ein Netzwerkdateisystem kein vernüftiges Arbeiten mehr möglich.
In allen Firmen und Institutonen, selbst zu Hause im Heimnetzwerk, wird ein Netzwerkdateisystem
eingesetzt um Daten zwischen Rechnern auszutauschen. Die bestehenden Netzwerkdateisysteme
erfüllen viele Aufgaben, haben aber auch Schwächen und lassen Verbesserungswünsche offen. Das
Ziel eines Netzwerkdateisystems, Daten für Clients unabhängig von Betriebssystemen und Netzwerken
anbieten zu können, wird von keinem zur Zeit existierenden Netzwerkdateisystem erreicht. Der
Austausch zwischen Rechnern mit verschiedenen Betriebssystemen gestaltet sich schwierig und ist
nur mit zusätzlichem Aufwand zu realisieren. Der Datentransfer über das Internet wird im Allgemeinen
durch systemspezifische Applikationen mit Hilfe des File Transfer Protocol (FTP) gelöst und
nicht durch ein Netzwerkdateisystem. In dieser Hinsicht bleibt noch viel Raum für die Weiterentwicklung
der einzelnen Netzwerkdateisysteme.
In der Version4 von NFS wird bei der Weiterentwicklung die größste Schwäche von NFS behoben, die
mangelhaften Sicherheitsmechanismen. Der NFS-Server überprüft dann nicht nur den Client sondern
auch den Benutzer. Die Authentifizierung des Benutzers geschieht über Kerberos [10], so sind strenge
Sicherheitsregeln möglich. Durch die besseren Sicherheitsfunktionen bietet sich NFS dann auch zum
Einsatz im Internet an.
Es bleiben noch viele Einsatzmöglichkeiten für ein Netzwerkdateisystem offen. Der Benutzer könnte
zum Beispiel zu Hause bei Bedarf so an seinem Rechner mit den Daten arbeiten, als ob er an seinem
Arbeitplatz wäre. Die Möglichkeit, jederzeit eine Sicherung der eigenen Daten anzufertigen und gesicherte
Daten wiederherzustellen, würde dem Benutzer weitere Sicherheit bieten. Die zeitverzögerte
Synchronisation wäre für Konferenzen und Projektentwürfe praktisch.
18

Literatur
[1] Reinhard Riedl Universität Zürich: Kernvorlesung Kommunikation und Verteilte Systeme. SS02
http://www.ifi.unizh.ch/ riedl/lectures/KV-Einfuehrung.pdf
[2] Sun Microsystems Inc.: RFC 1094 - NFS: Network File System Protocol Specification. March
1989 http://www.faqs.org/rfcs/rfc1094.html
[3] B. Callaghan, B. Pawlowski, P. Staubach Sun Microsystems Inc.: RFC 1813 - NFS Version 3
Protocol Specification. June 1995 http://www.faqs.org/rfcs/rfc1813.html
[4] S. Shepler, B. Callaghan, D. Robinson, R. Thurlow Sun Microsystems Inc., C. Beame, Hummingbird
Ltd., M. Eisler Zambeel Inc., D. Noveck Network Appliance Inc.:RFC 3010 - NFS
Version 4 Protocol. December 2000 http://www.faqs.org/rfcs/rfc3010.html
[5] S. Shepler Sun Microsystems Inc.: RFC 2624 - NFS Version 4 Design Considerations. June
1999 http://www.faqs.org/rfcs/rfc2624.html
[6] Sun Microsystems Inc.: RFC 1057 - RPC: Remote Procedure Call Prtotocol Specification Version
2. June 1988 http://www.faqs.org/rfcs/rfc1057.html
[7] R. Srinivasan Sun Microsystems: RFC 1831 - RPC: Remote Procedure Call Protocol Specification
Version 2. August 1995 http://www.faqs.org/rfcs/rfc1831.html
[8] Sun Microsystems Inc.: RFC 1014 - XDR: External Data Representation Standard. June 1987
http://www.faqs.org/rfcs/rfc1014.html
[9] R. Srinivasan Sun Microsystems: RFC 1832 - XDR: External Data Representation Standard.
August 1995 http://www.faqs.org/rfcs/rfc1832.html
[10] J. Linn OpenVision Technologies: RFC 1964 - The Kerberos Version 5 GSS-API Mechanism.
June 1996 http://www.faqs.org/rfcs/rfc1964.html
[11] J. Postel ISI: RFC 768 - UDP: User Datagram Protocol. August 1980
http://www.faqs.org/rfcs/rfc768.html
[12] Information Sciences Institute University of Southern California: RFC 793 - TCP: Transmission
Control Protocol. September 1981 http://www.faqs.org/rfcs/rfc793.html
[13] Sebastian Hentze, Dirk Hohndel, Martin Müller, Olaf Kirch: Linux Anwenderhandbuch. 1995
5.Auflage LunetIX Softfair
[14] Alexander Mattausch: Gut Verbunden - Kooperation im Netz mit dem Network Files System
NFS. c’t 15/2000 S.198-203
[15] Ulf Troppens: Speicher im Netz - Professionelle Speicherverwaltung mit SAN und NAS. c’t
08/2003 S.174-181
[16] Man-Pages unter SuSE Linux 8.0
19