Rheinisch-Westfalische Technische Hochschule AachenLehrstuhl fur Informatik IVProf. Dr. rer. nat. Otto Spaniol

� ������� ��� ������������������� �

Proseminar: KommunikationsprotokolleSS2003

Juliane MathesMatrikelnummer: 235672

Betreuung: Mesut GunesLehrstuhl fur Informatik IV, RWTH Aachen

Inhaltsverzeichnis

1 Einfuhrung 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 Schwachen 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 fur NFS-Server und NFS-Client . . . . . . . . . . . . . . . . . . . . . . . . 13

3.7.1 Aufbau eines NFS-Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.7.2 Zugriff uber 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 Ubermittlung 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 Speichergerate . . . . . . . . . . . . . . . . . . 17

Ubersicht der Abkurzungen

Abkurzung Bedeutung

ACL Access Control ListAFS Andrew File SystemCIFS Common Internet File SystemFTP File Transfer ProtocolNAS Network Attached StorageNFS Network File SystemRFC Request for CommentsRPC Remote Procedure CallSAN Storage Area NetworkSMB Server Message BlockTCP Transmission Control ProtocolUDP User Datagram ProtocolUID userID interne Benutzernummer, die vom System verwendet wirdXDR External Data Representation

3

1 Einfuhrung

1.1 Motivation

Jeder handelsubliche Rechner und jede Workstation ist heute mit großen Festplatten ausgestattet, sodass es an Speicherplatz nicht mangelt. Werden mehrere Rechner vernetzt, dann sind die Daten ei-nes Benutzers auf der Festplatte eines bestimmten Rechners gespeichert. Diese auf mehrere Rechnerverteilte Speicherung der Daten ist von Nachteil, da der Zugriff auf die Daten nur von diesem einenRechner aus erfolgen kann. Die regelmassige Datensicherung muss uber mehrere Rechner hinwegerfolgen und ist daher sehr aufwendig. Software, die auf jedem Rechner installiert ist, muss bei Er-scheinen einer neuen Version auf jedem einzelnen Rechner auf den neusten Stand gebracht werden.Abhilfe schafft ein Netzwerkdateisystem. Es ermoglicht den gemeinsamen Zugriff auf Daten, die aufeinem zentralen Server bereitgestellt werden. Die Daten konnen von verschiedenen Rechnern ausvon allen Benutzern, die auf diese Daten individuell Zugriff haben, erreicht werden. Fur den Benut-zer macht es keinen Unterschied, ob die Daten lokal oder auf einem entfernten Rechner liegen. Ermerkt dies im Idealfall uberhaupt nicht. Die Sicherung von Daten erfolgt zentral auf dem Server. DieAktualisierung eines Softwarepakets wird zunachst auf dem Server durchgefuhrt. Damit wird eineautomatische Aktualisierung der Software auf den Clients moglich. Diese Methode ist dann nutzlichwenn Software aus Sicherheitsgrunden innerhalb kurzester Zeit aktualisiert werden muss, wie zumBeispiel bei Virenscannern. Vertrauliche Daten werden durch Zugriffsrechte geschutzt und sind nurbestimmten Benutzern zuganglich. Fur manche Arbeitsbereiche wie zum Beispiel Softwareentwick-lung ist es wichtig, dass mehrere Benutzer gleichzeitig an einem Projekt arbeiten und auf gemeinsameDateien zum gleichen Zeitpunkt zugreifen konnen. Der simultane Zugriff auf Dateien wird von einemNetzwerkdateisystem geregelt.

1.2 Zielsetzung

Durch ein Netzwerkdateisystem werden Daten fur alle Rechnerarchitekturen transparent verfugbargemacht und stehen im gesamten Netzwerk bereit. Die Daten werden zentral auf einem oder mehre-ren Servern abgelegt. Die Benutzerverwaltung ist ebenfalls zentral geregelt, das Betriebssystem dereinzelnen Rechner spielt im Hinblick auf Dateisystem und Benutzerverwaltung eine unwesentlicheRolle. Der Benutzer kann sich durch die zentrale Benutzerverwaltung an jedem Rechner im lokalenNetzwerk (LAN) anmelden und findet dort durch das Netzwerkdateisystem immer seine gewohnteArbeitsumgebung vor. Die Zugriffsbeschrankungen werden durch den Server auf Dateien und Ver-zeichnisse vergeben und kontrolliert, es ist kein unbefugter Zugriff auf Daten moglich. Der Zugriffauf Daten kann von mehreren Benutzern gleichzeitig erfolgen und es stehen Funktionen zum Auffin-den und Beseitigen von Fehlern bereit. Auf dem Server erfolgt eine regelmassige Datensicherung. ImFalle der Falle ist eine schnelle Wiederherstellung der Daten moglich.

4

1.3 Aufbau der Arbeit

In dieser Arbeit wird das Konzept und der Aufbau von Netzwerkdateisystemen beschrieben und ihreFunktionsweise erlautert. Das Network File System (NFS) wird vorgestellt und an einem Beispiel de-tailliert erklart. Es werden weitere Netzwerkdateisysteme beschrieben sowie ihre Vor- und Nachteilemiteinander verglichen. Im Ausblick werden andere Ansatze zur zentralen Verwaltung von Daten imNetzwerk vorgestellt.

2 Grundlagen von Netzwerkdateisystemen

2.1 Funktionsweise

Netzwerkdateisysteme erlauben einen transparenten Zugriff auf Daten eines Servers von enferntenRechnern (Clients) aus. Ein oder mehrere Server bieten Verzeichnisse mit Dateien und Programmenfur andere Rechner an. Der Server stellt Funktionen zur Authentifizierung der Clients und der Be-nutzer, zur Ubermittlung der Daten, zum Auffinden und Beseitigen von Fehlern sowie zur Regelungdes gleichzeitigen Zugriffs von mehreren Rechnern auf eine Datei bereit. Die Clients binden die Ver-zeichnisse des Servers so in das lokale System ein, dass der Benutzer des Clients keinen Unterschiedzwischen lokalen und entfernten Daten bemerkt. Ein Benutzer meldet sich mit Benutzernamen undPasswort auf einem Client an und versucht auf Daten zuzugreifen, die auf einem Server gespeichertsind. Der Client fordert dann beim Server die Daten fur diesen Benutzer an. Der Benutzer selbst mussnicht wissen, wo diese Dateien liegen, er merkt nichts von der Kommunikation zwischen den beidenRechnern. Der Server verifiziert den Client und den Benutzer und ermittelt, welche Berechtigungender Benutzer auf welche Verzeichnisse oder Dateien hat. Ist dem Benutzer der Zugriff auf die ange-forderten Daten erlaubt, so werden die Daten zum Client ubertragen. Ist der Zugriff nicht erlaubt, sowird eine entsprechende Fehlermeldung an den Client geschickt. Bei erfolgreicher Authentifizierungkann der Benutzer mit den Daten so arbeiten, als ob diese lokal gespeichert waren.

2.2 Anforderungen

Fur den reibungslosen Ablauf der Kommunikation im Netzwerkdateisystem soll dieses folgende Ei-genschaften erfullen.[1]

Zugriffstransparenz: Benutzer oder Programme merken beim Zugriff auf Dateien nicht, ob auf einlokales oder auf ein entferntes Dateisystem zugegriffen wird

Ortstransparenz: Der tatsachliche Speicherort der Daten ist dem Benutzer unbekannt und kannsich andern, fur den Benutzer scheinen die Daten immer an derselben Stelle zu liegen.

Fehlertransparenz: Nach Ausfallen von Client oder Server wird der Dateibetrieb reibungslos wie-der aufgenommen.

5

Leistungstransparenz: Verzogerung durch Zugriff auf entfernte Dateien bei Schreib-/Lesezugriffensollen moglichts vermieden werden. Zu diesem Zweck werden die Daten beim Client und beimServer in einem Cache abgelegt.

Nebenlaufigkeitstransparenz: Der gleichzeitige Zugriff von mehreren Benutzern auf ein und die-selbe Datei verursacht keine Inkonsistenzen.

Zugriffstransparenz: Fur jede Datei und jedes Verzeichnis wird festgelegt, welche Benutzer oderwelche Gruppen welche Zugriffsrechte haben. Dabei wird zwischen verschiedenen Berechti-gungen, beispielsweise Lesen, Schreiben und Ausfuhren unterschieden.

3 NFS - das bekannteste Netzwerkdateisystem

3.1 Geschichtliches

Die Firma Sun Microsystems begann 1984 damit, ein System zu entwickeln, das den transparentenZugriff auf entfernte Daten ermoglichen sollte. Das Network File System (NFS) Version 1 gelangtejedoch nicht zum praktischen Einsatz, sondern wurde direkt zur Version 2 weiterentwickelt. Ein Jahrspater wurde die Version 2 von NFS vorgestellt und inklusive der Spezifikation veroffentlicht. DieHerausgabe der Spezifikation stellte zu dieser Zeit eine Neuheit dar, da solche Interna ublicherweisenicht veroffentlicht wurden. Die Bereitstellung der Spezifikation von NFS ist einer der Hauptgrundefur 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 Erwei-terung der Version 2 und zu dieser abwartskompatibel. Beide Version laufen neben- und miteinander,das heißt, Server und Client konnen auch dann miteinander kommunizieren, wenn auf einem RechnerNFS Version 3 und auf dem anderen noch NFS Version 2 eingesetzt wird. Der Funktionsumfang istdann allerdings auf Version 2 beschrankt. Seit Dezember 2000 existiert eine Spezifikation fur NFSVersion 4, Ziele dieser Version sind der verbesserte Zugriff und Durchsatz von NFS ubers Internetsowie strenge Sicherheitsmechanismen des NFS-Protokolls. Diese Version ist ebenfalls abwartskom-patibel 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] und3010 [4] beschrieben. NFS stellt netzwerkweit Dateien zur Verfugung, das Netzwerkdateisystem istin einer Client-Server-Struktur organisiert. Ein oder mehrere Server bieten Verzeichnisse fur vieleverschiedene Clients an. Der NFS-Server ist ein zustandsloser Server, es werden keine Statusmeldun-gen an die Clients geschickt. Per NFS ist es moglich, Verzeichnisse auf entfernten Rechnern auf demlokalen Rechner so einzubinden, dass clientseitig der Eindruck einer einzigen großen Festplatte ent-steht. Das Netzwerkdateisystem ist portabel uber Rechner, Systeme und Netzwerkprotokolle hinweg.

6

Die Portabilitat wird durch die Verwendung von Remote Procedure Calls (RPC) [6] gesichert. DasRPC-Protokoll verwaltet mit einem eigenem Dienst, dem Portmapper, das Angebot an Diensten undderen Funktionen, die ein Rechner anbietet. NFS ist einer der Dienste.

Abbildung 1: Ubermittlung des RPC Port eines Dienstes vom Server an den Client

Abbildung 1 zeigt den Ablauf der Kommunikation zwischen zwei Rechnern uber RPC. Jeder RPC-Dienst wird durch den Rechnernamen und die zugehorige Portnummer des Dienstes angesprochen.Beim Start des Rechners registrieren sich die Dienste beim Portmapper und melden die Nummer desPorts, uber den der Dienst mit anderen Rechnern kommuniziert. Der Client fragt beim Portmapperdes Servers nach der Portnummer fur den Dienst, der genutzt werden soll. Anschliesend kommuni-ziert der Client direkt mit dem Sever uber den zuruckgelieferten Port. Der Portmapper ist an dieserKommunikation nicht mehr beteiligt.

Auf einem NFS-Server mussen beim Booten der NFS-Dienst nfsd und der Mount-Dienst mountdgestartet werden. Das d an dem Namen der Dienste weisst daraufhin, dass es sich um einen Daemonhandelt, der im Hintergrund lauft und auf Anfragen wartet. Der NFS-Dienst gibt Verzeichnisse zumExportieren frei. Der Mount-Dienst ist fur den Zugriff auf ein angefordertes Verzeichnis verantwort-lich. Weitere nutzliche Dienste sind in diesem Zusammenhang der Network State Monitor (NSM)statd und der Network Lock Manager (NLM) lockd. Sie koordinieren den gleichzeitigen Zu-griff auf ein und dieselbe Datei. Der Quota-Dienst rquotad beschrankt die Speicherplatzgroße, dieeinem Benutzer zur Verfugung steht.

Jedes UNIX Dateisystem ist hierarchisch aufgebaut, die Wurzel des Verzeichnisbaums wird mit ,,/”bezeichnet. Verzeichnisse von anderen Rechnern konnen an jedem beliebigen Punkt unterhalb derWurzel eingehangt werden. Der Vorgang, dass ein Client beim Server ein Verzeichnis anfordert unddieses dann in das eigene Dateisystem einhangt, wird als mounten bezeichnet. Der Einhangepunktmuss vorher existieren. Das Gegenstuck zum mount ist umount. Der Inhalt des Verzeichnisses wirdmit 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. Uber die Portnummern nimmt der Client mit dem Mount-Dienst des Servers direkt Kon-takt auf und fordert den Zugriff auf ein bestimmtes Verzeichnis an. Der Mount-Dienst uberpruft, obdieses Verzeichnis per NFS verfugbar ist und ob der Client die notigen Berechtigungen besitzt. Eswerden die Zugriffsberechtigungen des Rechners auf das exportierte Verzeichnis uberpruft. Der Be-nutzer wird von NFS nicht authentifiziert. Bei erfolgreicher Authentifizierung des Rechners wendetsich der Mount-Dienst an den NFS-Dienst und bekommt von diesem ein Dateihandle auf das Ver-zeichnis geliefert. Dieses Dateihandle sendet der Mount-Dienst an den Client. Alle weiteren Zugriffeauf das vom Client angeforderte Verzeichnis erfolgen danach direkt zwischen dem Client und demNFS-Dienst des Servers. Der Client pruft die Berechtigungen des Benutzers auf das Verzeichnis underlaubt oder verweigert den Zugriff.

Abbildung 2: Ablauf des mount Vorgangs

NFS arbeitet auf unterschiedlichen Systemen und Hardware-Plattformen, so dass die Darstellung derDaten unterschiedlich ausfallt. Das External Data Representation Protocol (XDR) [8] konvertiert diezu ubermittelnden Daten fur die Ubertragung in ein standardisiertes Format und nach der Ubermitt-lung auch wieder zuruck.

3.3 Unterschiede NFS Version 2 und NFS Version 3

Die Version 3 ist eine Erweiterung der Version 2. Die Veranderungen fuhren zu mehr Leistung und da-durch zu einem schnelleren Zugriff auf die Daten. Eine der wichtigsten Neuerungen ist der asynchroneSchreib-/ Lesezugriff, der die Geschwindigkeit deutlich erhoht. Beim synchronen Zugriff werden Da-ten, die ein Client an den Server schickt, direkt auf dem Server geschrieben und der Client erhalt eineBestatigung. Im Gegensatz dazu werden beim asynchronen Zugriff die Daten zuerst auf dem Serverzwischengespeichert und der Client erhalt eine Empfangsbestatigung. Zu einem gunstigen Zeitpunktwerden die gesammelten Daten auf dem Server dann aus dem Cache auf das Speichermedium ge-schrieben und der Client bekommt eine Nachricht uber den erfolgreichen Schreibvorgang. Erst nach

8

dieser Vollzugsbestatigung verwirft der Client die Daten in seinem Cache. Abbildung 3 beschreibtden asynchronen Schreibvorgang.

Die Obergrenze bezuglich der Ubertragungsgroße wird gestrichen. Andere Großenlimits werden an-gepasst oder ganz aufgehoben. In der Version 3 kann als Ubertragungsprotokoll zwischen User Da-tagram Protocol (UDP) [11], einem verbindungslosen Transportprotokoll, und Transmission ControlProtocol (TCP) [12], einem verbindungsorientierten Transportprotokoll, gewahlt werden. In Versi-on 2 wird nur mit UDP gearbeitet. Den immer großeren Dateien und Dateisystemen wird durch dieUnterstutzung von 64 Bit langen Dateizeigern Rechnung getragen.

Abbildung 3: Asynchrones Schreiben bei NFS Version 3

3.4 Schwachen von NFS

NFS gewahrt einem Client-Rechner Zugriff auf ein exportiertes Verzeichnis, nicht einem Benutzer.Der NFS-Server pruft anhand der IP-Adresse des Clients, ob der Client auf das Verzeichnis zugrei-fen darf. Die Authentifizerung des Benutzers geschieht bei NFS durch den Client-Rechner uber dieinterne Nummer des Benutzers (UID). Sie wird vom Client-System beim Zugriff auf das gemounteteVerzeichnis uberpruft. Beim Anlegen des Benutzers auf dem Client wird diese UID erstellt. Wirdder Benutzer auf einem anderen Client zusatzlich angelegt, dann muss darauf geachtet werden, dasser dort die gleiche UID besitzt. Wird dieselbe UID falschlicherweise an verschiedene Benutzer ver-geben, erhalten alle diese Benutzer Zugriff auf dieselben Daten. Benutzern wird damit der Zugriffauf Daten erlaubt, den sie eigentlich nicht bekommen durften. Durch eine einheitliche Benutzerver-waltung, bei der die Benutzer zentral eingerichtet werden und dann auf allen Clients zur Verfugungstehen, tritt dieser Effekt nicht mehr auf. Beispiele fur eine zentrale Benutzerverwaltung sind YellowPages (YP) oder der Nachfolger Network Information Service (NIS+).

Der NFS Server ist ein zustandsloser Sever, das heißst, den Clients werden keine Informationen uberden Status des Servers ubermittelt. 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 ganzlahmlegen. Werden zum Beispiel Verzeichnisse des Servers beim Systemstart des Clients gemountetund der Server ist nicht erreichbar, dann wiederholt der Client den Mount-Vorgang solange, bis derServer wieder erreichbar ist. Dieser Prozess lauft im Hintergrund ab, kostet aber Ressourcen.

NFS verfolgt das Ziel, Daten fur alle Rechner, unabhangig vom Betriebssystem des Clients, bereit-zustellen. In einer UNIX Umgebung ist NFS auf allen Systemen vorhanden und zwischen diesenfunktioniert der Datenaustausch. Anders hingegen sieht es in einem heterogenen Netzwerk aus, indem Windows und UNIX Systeme miteinander kommunizieren sollen. Ein Windows-Client kenntkein NFS und kann nicht direkt auf einen NFS-Server zugreifen. Es existiert kein Protokoll, das dendirekten Zugriff von Windows-Clients auf einen NFS-Server ermoglicht. Der freiverfugbare Dateiser-verdienst SAMBA macht NFS-Ressourcen fur Windows-Clients zuganglich. Dafur muss allerdingsder Benutzer unter beiden Betriebssystemen bekannt sein, da keine betriebssystemubergreifende Be-nutzerverwaltung existiert.

NFS zeichnet sich im LAN durch gute Performance aus. Fur Verbindungen uber weite Entfernungenist es jedoch weniger geeignet. Grund hierfur sind nicht nur Performance Probleme sondern auch dieschon angesprochenen schwachen Sicherheitsmechanismen zum Schutz der Daten.

3.5 NFS Server

Als NFS Server kann jeder Rechner mit einem UNIX Betriebssystem arbeiten. Die Dienste sindin der Regel auf dem Rechner bereits vorhanden aber nicht aktiv. Die Konfiguration des Rechnersgeschieht durch Dateien, die von den Diensten eingelesen und ausgewertet werden. Die benotigtenKonfigurationsdateien und Kommandos sind auf allen UNIX Derivaten gleich, der Speicherort derDateien kann hingegen variieren. Die in dieser Arbeit verwendeten Pfade beziehen sich auf SuSELinux Version 8.0.

3.5.1 Dienste

rpc.mountd: Der Dienst implementiert das Mount-Protokoll. Wenn der Dienst eine Anfrage von ei-nem NFS-Client bekommt, pruft er in der Liste der exportierten Verzeichnisse, ob dem Client derZugriff erlaubt werden kann. Falls dem Client der Zugriff gewahrt wird, liefert der Dienst ein Datei-handle auf das angeforderte Verzeichnis an den Client zuruck. Jede erfolgreiche Anforderung einesexportierten 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 fur bestimmteRechner oder Netzwerke mit den zugehorigen Optionen.

Die Dienste rpc.lockd, rpc.statd und rpc.quotad sind nicht zwingend fur den Betrieb des NFS-Servers erforderlich. Der Network Lock Manager lockd kontrolliert den gleichzeitigen Zugriff aufeine Datei und akzeptiert oder verweigert diese. Das Ergebnis wird an den Lock-Daemon des Clients

10

ubermittelt. Der Network State Monitor statd verwaltet die Statusmeldungen des Lock-Managers uberDateisperren und reicht diese bei Bedarf an den Client weiter. Das Sperren einer Datei fur exklusivenZugriff bleibt dem zugreifenden Programm uberlassen, dies ist keine Aufgabe von NFS.

Durch den Dienst rpc.rquotad wird der dem Benutzer zur Verfugung stehende Speicherplatz be-grenzt. Die Quotas werden auf dem Server fur jeden Benutzer individuell eingerichtet und dort uber-wacht. Der Benutzer erhalt eine Warnmeldung, wenn der ihm zur Verfugung stehende Speicherplatzfast vollstandig belegt ist. Er kann den Belegungsgrad auch selbst abfragen.

3.5.2 Dateien

� /etc/rpc : Die Datei enthalt eine Liste der laufenden Dienste und ihre Portnummern. DieseListe wird bei jedem Booten des Rechners neu erstellt.

� /etc/hosts.allow und /etc/hosts.deny : In diesen Dateien wird eingetragen, wel-che Rechner, Gruppen von Rechnern oder Netzwerke auf bestimmte Dienste zugreifen durfenbzw. wem der Zugriff verboten ist. Jeder Eintrag besteht aus dem Namen des Dienstes ge-folgt von einer Liste der Rechner, die von ALLOW oder DENY beendet wird. Allgemein ist esublich, den Zugriff auf sicherheitskritsche Dienste zuerst komplett zu sperren und dann explizitden Zugriff fur das lokale Subnetz oder bestimmte Rechner zu erlauben.

� /etc/exports : Die Datei verwaltet die zu exportierenden Verzeichnisse. Ein Eintrag be-steht aus dem Namen des Verzeichnis, das exportiert werden soll, gefolgt von den zugelassenenClients. Die zu jedem Client gehorigen Zugriffsoptionen werden in Klammern hinter dem Cli-ent angegeben. Der Eintrag /home *.rwth-aachen.de(rw) erlaubt jedem Rechner derRWTH den schreibenden Zugriff auf das Verzeichnis /home des NFS-Servers. Dieses Schrei-brecht bedeutet nicht, dass jeder Benutzer auf dem Verzeichnis schreiben darf, sondern erlaubtlediglich dem Client grundsatzlich den schreibenden Zugriff. Die Option ro deaktiviert denSchreibzugriff des Clients auf das Verzeichnis, unabhangig davon, ob der Benutzer dort Schrei-brechte hat oder nicht. Alle Optionen und ihre Bedeutung erhalt man durch den Befehl manexportfs [16].

� /ect/init.d/nfsserver : Das Skript erledigt das Starten oder Stoppen der Diensterpc.mountd und rpc.nfsd. Damit diese Dienste beim Serverstart automatisch aktiviert werden,mussen in dem Verzeichnis /etc/init.d/rcn.dVerweise auf das Skript angelegt werden.Das n gibt die Nummer des Runlevels an, in dem ein bestimmter Dienst starten soll. Mehr zuRunleveln und ihrer Konfiguration unter [13].

3.5.3 Kommandos

exportfs [-airuv] [host:/path] : Der Befehl exportiert ein Verzeichnis des Servers ,,perHand”.

11

-a Alle Verzeichnisse aus der Datei /etc/exports und aus der Kommandozeile werden expor-tiert.

-i Das Verzeichnis der Kommandozeile wird exportiert, die Datei /etc/exports wird nichtausgewertet.

-r Alle Verzeichnisse werden erneut exportiert, (aquivalent zu -u dann -a)-u Alle exportierten Verzeichnisse werden nicht langer exportiert.-v Statusmeldungen anzeigen (verbose mode)

showmount [-ae] : Durch den Befehl werden die exportierten Verzeichnisse des aktuellen Rech-ners 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 Nutzungdes NFS Servers an.

-n Die fur NFS spezifischen Werte werden angezeigt.-r Es werden die fur RPC spezifischen Werte ausgegeben.

3.6 NFS Client

Die exportierten Verzeichnisse eines NFS-Servers stehen jedem Rechner, der zum Zugriff berechtigtist, zur Verfugung. Der Benutzer kann diese Verzeichnisse mit dem Befehl mount in das Dateisys-tem des Clients einfugen. Beim jedem Neustart des Clients muss dieser Mount-Vorgang wiederholtwerden. Dies ist fur oft benutze Verzeichnisse unpraktisch. Abhilfe schafft das feste Einbinden derVerzeichnisse beim Hochfahren des Rechners. Hierzu werden die benotigten Verzeichnisse genau wielokale Laufwerke in der Datei /etc/fstab eingetragen. Eine andere Moglichkeit ist das Ein- undAushangen eines Verzeichnisses bei Bedarf. Dies wird durch einen Daemon, den Automounter, erle-digt. Der Automounter uberwacht den Zugriff auf ein bestimmtes lokales Verzeichnis und mountet beiBedarf das entsprechende NFS-Verzeichnis. Findet uber langere Zeit kein Zugriff mehr auf das lokaleVerzeichnis statt, so wird das NFS-Verzeichnis wieder entfernt. Das Verfahren des dynamischen Ein-und Auskoppelns von Verzeichnissen in das Dateisystem wird zum Beispiel bei Homeverzeichnissengenutzt.

3.6.1 Dienste

Zum Zugriff auf einen NFS-Server ist kein Dienst erfoderlich. Fur die Benutzung des Automoun-ters muss der Dienst autofs konfiguriert werden. Dieser Dienst erzeugt fur jedes Verzeichnis, dasdynamisch eingebunden werden soll, einen Automounter-Daemon, der das Verzeichnis uberwacht.

12

3.6.2 Dateien

� /etc/fstab : In der Datei werden alle statischen Informationen uber Dateisysteme, dieEinhangepunkte und Optionen verwaltet. Ein Eintrag in der Datei besteht aus sechs Feldern,die durch Leerzeichen voneinander getrennt sind. Der Eintrag marple:/home /home nfsrw,bg 0 0 besagt, dass das Verzeichnis home des Servers marple an der Stelle /home in dasDateisystem eingehangt werden soll. Der Typ des Dateisystems ist nfs, die Optionen sind aufStandardwerte gesetzt. Die erste Spalte eines solchen Eintrags gibt an, welches Gerat oder Ver-zeichnis gemountet werden soll. Der zweite Eintrag gibt den Einhangepunkt im Dateisysteman, der dritte legt den Typ des Dateisystems fest. Das vierte Feld enthalt die Optionen fur denMount-Vorgang. Die beiden letzten Felder geben an, ob und in welcher Reihenfolge ein Backupoder eine Uberprufung des Dateisystems stattfinden soll. All diese Begriffe werden ausfuhrlichund gut unter [13] erklart.

� autofs : Das Skript startet den autofs-Dienst. Der Dienst uberwacht alle Verzeichnisse, diein der Datei /etc/auto.master angegeben sind, und mountet bei Bedarf das zugehorigeVerzeichnis vom NFS-Server. Nach langerer Nichtbenutzung wird das Verzeichnis wieder ausdem Dateisystem ausgehangt. Damit der autofs-Dienst beim Hochfahren des Clients gestartetwird, mussen Verweise auf das Skript in den einzelnen Runleveln angelegt werden. Die Vorge-hensweise wird in [13] erklart.

� auto.master : Die Datei enthalt eine Liste von Verzeichnissen, die durch den autofs-Dienstuberwacht werden sollen. Jeder Eintrag besteht aus dem Verzeichnisnamen sowie dem Nameneiner Datei, der keymap. In dieser Datei ist das zu mountende Verzeichnis mit den zugehorigenOptionen angegeben. Mehr Informationen zur Syntax dieser Datei erhalt man durch den Befehlman autofs [16].

3.6.3 Kommandos

mount [-t vfstype] [-o options] device dir : Durch diesen Befehl wird das Geratoder Verzeichnis device an der Stelle dir in das lokale Dateisystem eingehangt. Mit dem Paramter-t kann der Typ des Dateisystems angegeben werden. Mit -o werden weitere Optionen gesetzt unddie Standardwerte verandert. Alle Optionen und ihre Bedeutung erhalt man durch den Befehl manmount [16].umount dir : Dies ist das Gegenstuck zum Befehl mount. Mit dem Befehl wird das Verzeichnisdir wird aus dem Dateisystem ausgehangt.Der Befehl showmount -e hostname zeigt die auf dem Server hostname uber NFS verfugba-ren Verzeichnisse an. Die genaue Syntax dieses Befehl ist unter Abschnitt 3.5.3 zu finden.

3.7 Beispiel fur NFS-Server und NFS-Client

Das konkrete Beispiel zeigt den Aufbau und die Konfiguration eines NFS-Servers unter Linux sowieden 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 Passwortern. In einem grosse-ren Netzwerk sollte die Benutzerverwaltung uber ein System wie NIS geregelt werden. Der Servermarple bietet die Verzeichnisse /opt und /home. Auf diese Verzeichnisse soll der Client stringerZugriff haben. Dem Client craddock soll kein Zugriff auf die Verzeichnisse erlaubt werden. DerAufbau des Netzwerks ist in Abbildung 4 zu erkennen.

3.7.1 Aufbau eines NFS-Servers

Die Installation der benotigten Pakete und die Konfiguration des NFS Servers muss als Benutzer rootdurchgefuhrt werden, da nur dieser die notigen Rechte besitzt. Zuerst wird auf dem Server das Paketnfs-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 al-len 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 zumZugriff per NFS. Die Verzeichnisliste und die zugehorigen Optionen werden in /etc/exports an-gegeben./opt 192.168.99.*(ro)/home 192.168.99.*(rw,no root squash)Dann wird der NFS Server gestartet:

marple:/etc/init.d # ./nfsserver startStarting kernel based NFS server done

und das Ergebnis uberpruft.

marple:/etc/init.d # showmount -e marpleExport list for marple:/opt 192.168.99.*/home 192.168.99.*

14

3.7.2 Zugriff uber verschiedene NFS-Clients

Auf dem Client werden keine besonderen Pakete fur den Zugriff auf Verzeichnisse uber NFS benotigt,da das mount Kommando zum Linux System gehort. Im folgenden Beispiel werden zwei verschiedeneClient Rechner betrachtet. Der Client stringer hat die IP Adresse 192.168.99.2. Damit gehort erzum lokalen Subnetz, weshalb ihm der Zugriff auf den Server erlaubt ist. Der Client craddock hatdie IP Adresse 192.168.100.3. Er gehort nicht zum lokalen Subnetz und hat daher keinen Zugriff aufden 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 Befehlmkdir /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 uber-pruft werden. Das Verzeichnis /home erscheint dann in der Liste der gemounteten Verzeichnisse.Eine andere Moglichkeit 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 derStelle /sw eingehangt oder kann nachtraglich mit dem Befehl

stringer:/ # mount /swmount: can’t find /sw in /etc/fstab or /etc/mtab

eingehangt werden. Weil im Beispiel der erwahnte fstab-Eintrag noch nicht vorhanden ist, fuhrt derBefehl zu einer Fehlermeldung. In der Datei /etc/fstab wird deswegen folgende Zeile hinzu-gefugt marple:/opt /sw nfs bg,hard,ro 0 0. Damit wird festgelegt, dass das Verzeich-nis /opt des Servers marple im Verzeichnis /sw auf dem Client eingehangt wird. Als Dateityp wird nfsangeben, die Optionen sind bg, rw, hard. Die beiden Nullen sorgen dafur, dass auf dem Verzeichnisbeim Booten keine Uberprufung des Dateisystems ausgefuhrt 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 eingehangtwurden.

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, dasich beide Rechner in demselben Subnetz befinden und der NFS-Server den Zugriff von Rechnernaus demselben Subnetz erlaubt. Anders sieht es bei dem Rechner craddock aus. Auf Grund derIP-Adresse gehort der Rechner zu einenem anderen Subnetz als der Server. Diesem Rechner ist derZugriff auf den NFS-Server verboten, ein mount-Vorgang schlagt daher mit einer Fehlermeldung fehl.

15

craddock: # mount marple:/opt /swmount: marple:/opt failed, reason given by server: Permission denied

Das Beispiel bietet einen kurzen Einblick in die Arbeitsweise von NFS und zeigt das Zusammenspielzwischen Client und Server. Weitere Moglichkeiten wie der Aufbau eines komplexen Netzwerks oderdie Benutzung von autofs zum dynamischen mounten von Homeverzeichnissen werden in diesemBeispiel nicht erlautert.

4 Andere Netzwerkdateisysteme

4.1 CIFS

Das Common Internet File System (CIFS) dient zur Verbindung von Windows-Rechnern in einemNetzwerk. Es setzt auf TCP/IP auf und ist wie NFS in einer Client-Server-Struktur organisiert. DasNetzwerkdateisystem beruht auf Server Message Block (SMB). Dieser Mechanismus ist der Vorlaufervon CIFS und wird bei Windows 3.11 und Windows95/98 eingesetzt. Uber sogenannte Freigabenkonnen Rechner auf Verzeichnisse oder Festplatten anderer Rechner zugreifen. Anders als bei NFSerfolgt bei CIFS ab WindowsNT die Freigabe von Verzeichnissen fur Benutzer und nicht fur Rech-ner. Die Benutzer werden von einem zentralen Server, dem Domanen-Controller verwaltet. Auf demServer 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 Serverserhalt, von diesem authentifiziert. Der Zugriff auf Dateien wird durch Access Control Lists (ACL) aufdem Server kontrolliert.Seit WindowsNT Service Pack3 werden die Passworter verschlusselt im Netzwerk ubertragen, in allenvorherigen Versionen erfolgte eine unverschlusselte Ubergabe des Passwortes. Durch die Kopplungdes Dateizugriffs an einen Benutzer reagiert das CIFS sehr empfindlich auf eine Unterbrechung derVerbindung zum Server. Der Benutzer verliert unter Umstanden Daten und muss sich nach Wieder-herstellung der Verbindung erneut am Server anmelden.

4.2 AFS

Als gemeinsames Projekt von IBM und der Carnegie-Mellon-University wurde das Andrew File Sys-tem (AFS) entwickelt. AFS ist ein verteiltes Netzwerkdateisystem. Anders als bei NFS werden beiAFS die Dateien uber mehrere Dateiserver verteilt. Der Benutzer muss nicht wissen, auf welchemFileserver seine Daten liegen, da sich die AFS-Verzeichnisstruktur uber Links in das Dateisystemintegriert. Jedes lokale Dateisystem ist eine AFS-Zelle. Diese Zellen werden zu einem globalen AFS-Katalog zusammengefugt, so dass prinzipiell alle Daten im AFS weltweit zuganglich sind. Durchdiese Skalierbarkeit des Dateisystems bietet sich AFS auch fur den Einsatz in grossen Netzwerkenoder dem Internet an. Die Berechtigungen der Benutzer werden wie bei CIFS in ACLs verwaltet.

16

AFS unterstutzt die Replikation von Dateien. Von jeder Datei konnen read-write-Kopien und read-only-Kopien auf anderen Servern existieren. Der Client entscheidet dann, welche Version er von wel-chem Server anfordert. Die Replikation bietet eine gewisse Sicherheit bei Serverausfallen. Eine sol-che Replikation wird von NFS standardmassig nicht unterstutzt. AFS wird zur Zeit auf UNIX-Servernaufgesetzt und laßt sich sowohl von Windows- als auch auf UNIX-Clients aus nutzen.

4.3 Speichernetze

Im Zuge der stetig wachsenden Speicherkapazitat entstehen Alternativen zum herkommlichen Spei-chermedium 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 Speichergerate ersetzt. DieserVorgang wird als Speicherkonsolidierung bezeichnet.

Abbildung 5: Ein Speichernetz trennt Server und Speichergerate

Speichernetze konnen an zwei Stellen zwischen Anwendung und Festplatte geschaltet werden. Block-orientierte Speichernetze ersetzten das lokale Datenkabel durch ein serielles Netzwerk. Dieses Netz-werk kann auch grossere Entfernung uberbrucken, die Gerate kommunizieren weiterhin blockorien-tiert miteinander. Mehrere Server konnen dann auf das gleiche Speichermedium zugreifen, die Spei-chergerate sind unabhangig von den Rechnern. Auch beim Network Attached Storage (NAS) ist derSpeicher unabhangig von den Rechnern. Im Gegensatz zu SAN treten bei NAS die Speichermedienselbst als Dateiserver auf. Auf diese vorkonfigurierten Server wird dann dateiorientiert durch Anwen-dungsprotokolle wie NFS oder CIFS zugegriffen.SAN und NAS sind keine konkurrierenden Konzepte sondern zwei verschiedene Techniken, die sichkombinieren lassen. Ein NAS-Server kann ein Speichernetz hervorragend zur Speicherung oder Si-cherung von Daten nutzen.

17

5 Zusammenfassung

Die Arbeit stellt die generelle Idee und den Aufbau von Netzwerkdateisystemen vor und beschreibtdie an sie gestellten Anforderungen. Das Netzwerkdateisystem NFS wird erlautert und die Vor- undNachteile von NFS werden aufgezeichnet. Die Dateien und Dienste, die zum Funktionieren von NFSnotwendig sind, werden detailliert beschrieben, sowie einige nutzliche Kommandos im Umgang mitNFS erlautert. Anschliessend wird in einem Beispiel der Aufbau eines NSF Servers erklart und dieKommunikation zwischen Server und Clients gezeigt. Dann werden andere Dateisysteme wie CIFSund AFS vorgestellt und ihre Unterschiede zu NFS untersucht.

In heutigen Netzwerken ist ohne ein Netzwerkdateisystem kein vernuftiges Arbeiten mehr moglich.In allen Firmen und Institutonen, selbst zu Hause im Heimnetzwerk, wird ein Netzwerkdateisys-tem eingesetzt um Daten zwischen Rechnern auszutauschen. Die bestehenden Netzwerkdateisystemeerfullen viele Aufgaben, haben aber auch Schwachen und lassen Verbesserungswunsche offen. DasZiel eines Netzwerkdateisystems, Daten fur Clients unabhangig von Betriebssystemen und Netzwer-ken anbieten zu konnen, wird von keinem zur Zeit existierenden Netzwerkdateisystem erreicht. DerAustausch zwischen Rechnern mit verschiedenen Betriebssystemen gestaltet sich schwierig und istnur mit zusatzlichem Aufwand zu realisieren. Der Datentransfer uber das Internet wird im Allge-meinen durch systemspezifische Applikationen mit Hilfe des File Transfer Protocol (FTP) gelost undnicht durch ein Netzwerkdateisystem. In dieser Hinsicht bleibt noch viel Raum fur die Weiterentwick-lung der einzelnen Netzwerkdateisysteme.

In der Version4 von NFS wird bei der Weiterentwicklung die großste Schwache von NFS behoben, diemangelhaften Sicherheitsmechanismen. Der NFS-Server uberpruft dann nicht nur den Client sondernauch den Benutzer. Die Authentifizierung des Benutzers geschieht uber Kerberos [10], so sind strengeSicherheitsregeln moglich. Durch die besseren Sicherheitsfunktionen bietet sich NFS dann auch zumEinsatz im Internet an.

Es bleiben noch viele Einsatzmoglichkeiten fur ein Netzwerkdateisystem offen. Der Benutzer konntezum Beispiel zu Hause bei Bedarf so an seinem Rechner mit den Daten arbeiten, als ob er an seinemArbeitplatz ware. Die Moglichkeit, jederzeit eine Sicherung der eigenen Daten anzufertigen und ge-sicherte Daten wiederherzustellen, wurde dem Benutzer weitere Sicherheit bieten. Die zeitverzogerteSynchronisation ware fur Konferenzen und Projektentwurfe praktisch.

18

Literatur

[1] Reinhard Riedl Universitat Zurich: Kernvorlesung Kommunikation und Verteilte Systeme. SS02http://www.ifi.unizh.ch/ riedl/lectures/KV-Einfuehrung.pdf

[2] Sun Microsystems Inc.: RFC 1094 - NFS: Network File System Protocol Specification. March1989 http://www.faqs.org/rfcs/rfc1094.html

[3] B. Callaghan, B. Pawlowski, P. Staubach Sun Microsystems Inc.: RFC 1813 - NFS Version 3Protocol Specification. June 1995 http://www.faqs.org/rfcs/rfc1813.html

[4] S. Shepler, B. Callaghan, D. Robinson, R. Thurlow Sun Microsystems Inc., C. Beame, Hum-mingbird Ltd., M. Eisler Zambeel Inc., D. Noveck Network Appliance Inc.:RFC 3010 - NFSVersion 4 Protocol. December 2000 http://www.faqs.org/rfcs/rfc3010.html

[5] S. Shepler Sun Microsystems Inc.: RFC 2624 - NFS Version 4 Design Considerations. June1999 http://www.faqs.org/rfcs/rfc2624.html

[6] Sun Microsystems Inc.: RFC 1057 - RPC: Remote Procedure Call Prtotocol Specification Ver-sion 2. June 1988 http://www.faqs.org/rfcs/rfc1057.html

[7] R. Srinivasan Sun Microsystems: RFC 1831 - RPC: Remote Procedure Call Protocol Specifica-tion Version 2. August 1995 http://www.faqs.org/rfcs/rfc1831.html

[8] Sun Microsystems Inc.: RFC 1014 - XDR: External Data Representation Standard. June 1987http://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 1980http://www.faqs.org/rfcs/rfc768.html

[12] Information Sciences Institute University of Southern California: RFC 793 - TCP: TransmissionControl Protocol. September 1981 http://www.faqs.org/rfcs/rfc793.html

[13] Sebastian Hentze, Dirk Hohndel, Martin Muller, Olaf Kirch: Linux Anwenderhandbuch. 19955.Auflage LunetIX Softfair

[14] Alexander Mattausch: Gut Verbunden - Kooperation im Netz mit dem Network Files SystemNFS. c’t 15/2000 S.198-203

[15] Ulf Troppens: Speicher im Netz - Professionelle Speicherverwaltung mit SAN und NAS. c’t08/2003 S.174-181

[16] Man-Pages unter SuSE Linux 8.0

19