# Der NFS Server

Mit dem Kernel 2.1 wurde erstmals ein Kernel-basierender NFS-Dämon vorgestellt. Dadurch wird versucht, diesen doch recht verbreiteten Dienst durch direkte Unterstützung im Kernel zu optimieren. Besonders den bislang unbefriedigenden Durchsatz beim Schreiben auf ein NFS-Verzeichnis hofft man hiermit zu beschleunigen (das Umkopieren der Daten vom Nutzer- in den Systemadressraum wird vermieden). Noch steckt dieser in den Kinderschuhen und beinhaltet vermutlich eine Reihe von Fehlern. Dennoch möchte ich im Laufe dieses Kapitels auf die Konfiguration dieses Dämons eingehen.

Die Konfigurationsdatei für beide NFS-Dämons (User-Space und Kernel) ist `/etc/exports`. In ihr sind alle zu exportierenden Dateisysteme zusammen mit den Zugriffsrechten enthalten:

`# Aufbau einer /etc/exports # <Zu exportierendes Verzeichnis> <[Rechner]( Optionen )> # /home (rw, no_all_squash) /projects *.galaxis.de(rw) zeus(ro) /usr/bin (ro, root_squash) #`

Jedes vom Server zu exportierende Verzeichnis ist auf einer neuen Zeile anzugeben. Alle weiteren Angaben sind optional. Der Zugriff auf ein Verzeichnis kann auf bestimmte Rechner/Netzgruppen beschränkt werden. Folgende Syntaxvarianten werden unterstützt:

Format der Rechnernamen | Bedeutung
`mars` | Einzelner Rechner (hier kann auch die IP-Adresse stehen)
`@netgroup` | Eine Zusammenfassung von Rechnern in eine Gruppe. Eine solche Gruppe muss in der Datei `/etc/netgroup` existieren.
`[a-d]*.galaxis.de` | Bei Angabe von Wildcards expandiert der Eintrag zu allen bekannten Rechnernamen, die dem Muster entsprechen.
`localnet` | Alle Rechner des angegebenen Netzes. Entweder wird die IP-Adresse des Netzwerkes eingetragen oder der Name des Netzwerkes (dieser muss in der Datei `/etc/networks` stehen).
`=public` | Dieser spezielle "Rechnername" definiert ein Verzeichnis als öffentliches Wurzelverzeichnis und wird in Verbindung mit WebNFS genutzt. Ein Webbrowser kann auf ein solches Verzeichnis unter Umgehung des Mount-Protokolls zugreifen. Somit können auch Webbrowser von Nicht-Unix-Systemen (die i.d.R. das Mount-Protokoll nicht unterstützen) auf ein so exportiertes Verzeichnis zugreifen. Dem Eintrag `=public` dürfen keine Optionen folgen; diese werden auf einer weiteren Zeile definiert:
`/home/httpd =public /home/httpd (ro, all_squash, insecure)`

Mit Hilfe von Optionen können die Berechtigungen beim Zugriff durch importierende Rechner gesteuert werden:

Option (Auswahl) | Bedeutung
`secure` | Zugriff ist nur für Anforderungen an "vertrauenswürdigen" Internetports (< 1024) erlaubt. Das Gegenstück ist `insecure`.
`ro, rw` | Lesender (ro) bzw. schreibender (rw) Zugriff erlaubt.
`noaccess` | Kein Zugriff für die spezifizierten Rechner.
`root_squash` | Die Nutzer-/Gruppen-ID 0 (root) wird auf Nobody/Nogroup (-2) gemappt. Hierdurch verliert der Systemverwalter des importierenden Rechners seine Sonderrechte auf dem importierten Verzeichnis. Soll Root auch dieses verwalten dürfen, ist die Option `no_root_squash` zu setzen.
`all_squash` | Alle Nutzer-/Gruppen-IDs werden auf Nobody/Nogroup (-2) gemappt. Das Gegenstück ist `no_all_squash`. Behalten die Nutzer ihre UIDs auf importierenden Rechnern, sollte sicher gestellt werden, dass alle UIDs im Netz eindeutig sind, da Zugriffsrechte nur anhand der UID/GID verifiziert werden und nicht anhand von Nutzer-/Gruppennamen!
`squash_uids, squash_gids` | Hier können spezielle UIDs/GIDs auf Nobody/Nogroup (-2) gemappt werden. Die Syntax lautet `squash_uids=18-15,23,27,30-100`.
`anonuid, anongid` | Jede UID/GID wird auf Nobody/Nogroup (-2) gemappt. Die Option ist sinnvoll, wenn die Clients das Nutzerkonzept nicht kennen (z.B. DOS).