4.1 Der Server

Das erste, das man tun muss, ist portmap zu starten, da dieses Protokoll von NFS benötigt wird.

Oder natürlich über das entsprechende Startskript der Distribution:

Der Befehl rpcinfo zeigt die auf der Maschine laufenden RPC-Dienste, spezifiziert als das Argument (-p Option). Im ersten Fall sieht man, dass portmap noch nicht läuft: Man startet es (die meisten Linux-Distributionen enthalten Skripte, um dies beim Starten zu automatisieren). Danach wird erneut geprüft, ob es läuft. Ein anderer oft vorkommender Grund für eine negative Antwort auf rpcinfo ist, dass der portmapper nicht antworten darf aufgrund von Sicherheitsrestriktionen in den Dateien /etc/hosts.allow oder /etc/hosts.deny. In diesem Fall fügt man einen Eintrag zu der Datei /etc/hosts.allow hinzu.

portmap: <hosts>
     

Vor dem Starten von NFS selbst muss es konfiguriert werden. Es gibt nur eine einzige Konfigurationsdatei, und die heisst /etc/exports. Jede Zeile zeigt einen Verzeichnisbaum, der exportiert werden soll, gefolgt von einer Liste von Clients, die auf ihn zugreifen dürfen. Es ist möglich, am Ende jedes Client-Namens Optionen hinzuzufügen. Die Manpage zu exports erklärt die Syntax für Client-Namen und Optionen.

Die akzeptierten Formen für Client-Namen sind:

• Rechnername
• Wildcards auf einen Domainnamen (z.B. : linux-*.mondomaine.fr)
• eine netgroup (Netzgruppe) (@group), wenn  NIS benutzt wird
• eine  IP-Adresse

# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients.  See exports(5).
/storage1/home          10.0.0.0/24(rw,async)
/storage1/system        10.0.0.0/24(rw,async)
/storage1/cdroms        10.0.0.0/24(rw,async)
/storage2/audio         10.0.0.0/24(rw,async)
/storage2/video         10.0.0.0/24(rw,async)
/storage2/backup        10.0.0.0/24(rw,async)
/storage2/transfer      10.0.0.0/24(rw,async)

/diskless/excelsior     excelsior(rw,async,no_root_squash)
/diskless/yorktown      yorktown(rw,async,no_root_squash)
/diskless/stargazer     stargazer(rw,async,no_root_squash)
/diskless/saratoga      saratoga(rw,async,no_root_squash)
     

Ohne im Detail alle verfügbaren mount-Optionen beschreiben zu wollen, hier dennoch eine Aufzählung der wichtigsten Optionen:

• rw (read write): Der Client kann im exportierten Sytem lesen und schreiben
• ro (read only): Der Client kann im exportierten System nur lesen
• root_squash: Es ist sicherer, wenn der  root-Benutzer eines Client nicht mit Root-Erlaubnis schreiben darf. Um dies zu vermeiden, wird die  UID/GID 0 (z. B. die von  root) auf der Seite des Clients in den Benutzer nobody übersetzt. Diese Option ist standartmässig aktiv, kann aber mit no_root_squash abgeschaltet werden.
• all_squash: Alle Clients, die auf das oben exportierte System zugreifen, benutzen die  UID/GID des Benutzers nobody
• anonuid, anongid: Der Benutzer nobody benutzt jetzt  UID und GID definiert durch diese Optionen.

Jetzt müssen die rpc.mountd und rpc.nfs Daemons gestartet werden, um einen laufenden NFS-Server zu bekommen. Man sollte nochmals mit dem Befehl rpcinfo überprüfen, dass alles läuft. Man kann den Server sogar für die nsm- und nlm-Protokolle initialisieren (rpc.statd bzw. rpc.lockd). Sie sind aber nicht unbedingt notwendig, um einen NFS-Server laufen zu lassen. Allerdings sind sie hilfreich, wenn eine Maschine ausfällt, von selbst rebootet, etc...

Wenn man die Konfigurationsdatei /etc/exports ändert, muss man die betroffenen Daemons informieren, dass Änderungen gemacht wurden. Der Befehl exportfs übermittelt diese Information an die Server. Die Option -r synchronisiert die Datei /var/lib/nfs/etab mit der Datei /etc/exports. Die Option -v zeigt die exportierten Dateisysteme zusammen mit ihren Optionen an.

Nach dem Start enthalten die folgenden Dateien wichtige Informationen:

• /var/lib/nfs/rmtab: Jede Zeile zeigt den Namen des Clients und das Dateisystem, das von diesem Server importiert wurde.
• /var/lib/nfs/etab: Die Datei /etc/exports enthält nur eine Wunschliste. etab wird durch exportfs erzeugt. Es enthält auf jeder Zeile detaillierte Informationen über die Optionen, die benutzt werden, wenn ein Dateisystem zu einem einzelnen Client exportiert wird. Es ist die Referenzdatei, die von rpc.mountd benutzt wird, wenn dieser gestartet wird.
• /proc/fs/nfs/exports: enthält die Client-Liste, so wie sie der  Kernel kennt.
• /var/lib/nfs/xtab: Wird benutzt für die Genauigkeit, wenn etab Clientennamen und Rechnergruppen mit Wildcards enthält. Diese Datei enthält nur explizite Rechnernamen.

Wenn ein Client auf ein Dateisystem zugreifen möchte, fängt er damit an, mountd zu fragen. Dieser sucht dann in etab, ob die Abfrage beantwortet werden kann. Er prüft ebenso, ob der Client zu dieser Abfrage berechtigt ist (hosts.{allow, deny},  Regeln der Firewall, ...). Der  Kernel benutzt exportfs für die Überprüfung. Wenn in der Datei /var/lib/nfs/etab das exportierte System berechtigt ist, zu der Gruppe, zu der der Client gehört, exportiert zu werden, dann informiert mountd den  Kernel, der daraufhin xtab mit dem neuen Rechnernamen aktualisiert.

4.2 Der Client

Hier gibt es normalerweise wenig zu tun. Der Zugriff auf ein Dateisystem, das von NFS exportiert wurde, wird direkt vom  Kernel verwaltet. Er muss mit  Unterstützung für NFS kompiliert worden sein. Die Datei /proc/filesystems listet alle Dateisysteme auf, die direkt vom  Kernel unterstützt werden. Man muss dann nur dem  Kernel sagen, dass man Zugriff auf ein von NFS exportiertes System haben möchte.

Der Befehl mount berechtigt zum Zugriff auf verschiedene Dateisysteme. Er informiert den  Kernel, dass ein neues Dateisystem verfügbar ist, mit Angabe seines Typs, des Gerätes und seinem Mount-Punkt. Die Option -t kann dazu benutzt werden, um den Typ des benutzten Dateisystems zu spezifizieren. Für NFS schreibt man -t nfs.

mount hat seine eigenen Optionen für NFS. Zum Beispiel können die Optionen rsize und wsize dazu benutzt werden, um die Blockgrößen für Lesen und Schreiben zu ändern. Man kann NFS-spezifische Optionen mit allgemeineren Optionen wie intr, noexec oder nosuid verbinden. Die  manpage zu mount listet alle diese Optionen auf.

Wir nehmen an, der Rechner enterprise ist ein NFS-Server und exportiert sein Verzeichnis /usr/local. Wenn man darauf vom Rechner excelsior aus zugreifen will, dann muss man nur das exportierte Verzeichnis von enterprise auf excelsior mounten:

Der Befehl zeigt an, dass man ein NFS Dateisystem mountet (-t nfs), mit den Optionen nosuid, hard und intr. Die beiden letzten Argumente sind die interessantesten. Das erste der beiden spezifiziert das zu mountende Gerät. Für NFS ist die Syntax anders als in der gewöhnlichen Befehlszeile von mount, wo man das Gerät und das Verzeichnis spezifiziert. Hier spezifiziert man server:exported_directory anstelle eines Gerätes.

Das letzte Argument zeigt die Stelle des Dateisystems auf der Client-Seite an. Hier teilen sich excelsior und enterprise einfach das Verzeichnis /usr/local. Dadurch kann vermieden werden, Programme mehr als einmal in /usr/local zu installieren. Um dies permanent zu machen, kann man dies auf excelsior in der Datei /etc/fstab spezifizieren. fstab enthält alle Dateisysteme, die beim Start gemounted werden müssen. Die Syntax für /etc/fstab lautet:

#    device           mount point file system  options          dump fsckorder
enterprise:/usr/local /usr/local  nfs          nosuid,hard,intr 0    0
     

Man sollte jedoch mit permanenten Einträgen vorsichtig sein. Man kann es nur benutzen, wenn der Server (enterprise) immer eingeschaltet ist oder vor dem Client (excelsior) eingeschaltet wird.