Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Die exports-Datei

Nun beschäftigen wir uns mit der Konfiguration des NFS-Servers. Wir untersuchen, wie wir dem NFS-Server mitteilen, welche Dateisysteme er zum Mounten freigeben soll, und werfen einen Blick auf die diversen Parameter, die die Zugriffsrechte der Clients auf die Dateisysteme regeln. Der Server bestimmt die Zugriffsmöglichkeiten, über die auf die Dateien auf dem Server zugegriffen werden kann. Die Datei /etc/exports enthält eine Liste der Dateisysteme, die der Server den Clients zum Mounten und Anwenden zur Verfügung stellt.

Per Voreinstellung erlaubt rpc.mountd niemandem, Verzeichnisse des lokalen Hosts über NFS zu mounten, was eine sehr vernünftige Einstellung ist. Um einem oder mehreren Hosts den NFS-Zugriff auf ein Verzeichnis zu erlauben, müssen Sie es exportieren, d.h. in der Datei exports eintragen. Eine Beispieldatei könnte so aussehen:

 # Export-Datei für vlager /home             vale(rw) vstout(rw) vlight(rw) /usr/X11R6        vale(ro) vstout(ro) vlight(ro) /usr/TeX          vale(ro) vstout(ro) vlight(ro) /                 vale(rw,no_root_squash) /home/ftp         (ro)

Jede Zeile definiert ein Verzeichnis und die Hosts, die es mounten dürfen. Ein Hostname ist üblicherweise ein voll qualifizierter Domainname, kann zusätzlich aber auch die Platzhalter * und ? enthalten, die auf dieselbe Weise funktionieren wie bei der Bourne-Shell. Beispielsweise wird bei lab*.foo.com sowohl lab01.foo.com als auch laber.foo.com akzeptiert. Der Host kann auch in Form eines IP-Adreßbereichs Adresse/Netzmaske angegeben werden. Wird wie im obigen Beispiel beim /home/ftp-Verzeichnis kein Hostname angegeben, darf jeder Host dieses Verzeichnis mounten.

Bei der Prüfung eines Client-Host gegen die exports-Datei ermittelt rpc.mountd den Hostnamen des Client mit Hilfe eines gethostbyaddr-Aufrufs. Unter DNS liefert dieser Aufruf den kanonischen Hostnamen des Client zurück, d.h., Sie dürfen keine Aliases in exports verwenden. In einer NIS-Umgebung wird der erste passende Hostname aus der Hostdatenbank zurückgeliefert. In Umgebungen ohne DNS und NIS wird dagegen der erste Hostname aus der Datei hosts zurückgeliefert, bei dem die Adresse des Client übereinstimmt.

Dem Hostnamen kann eine Liste mit durch Kommata getrennten Optionen folgen, die in Klammern eingeschlossen sind. Diese Optionen können unter anderem die folgenden Werte annehmen:

secure

Diese Option bestimmt, daß Anforderungen von einem reservierten Internet-Port stammen müssen, d.h., die Portnummer muß kleiner als 1.024 sein. Diese Option ist per Voreinstellung aktiviert.

insecure

Diese Option kehrt die Wirkung der secure-Option um.

ro

Diese Option bewirkt, daß NFS-Mounts schreibgeschützt erfolgen, und ist per Voreinstellung aktiviert.

rw

Diese Option mountet Dateihierarchien mit Lese- und Schreibrechten.

root_squash

Dieses Sicherheits-Feature verweigert den Administratoren der angegebenen Hosts jegliche Sonderrechte, indem Anforderungen von UID 0 des Client auf UID 65534 (d.h. -2) auf dem Server abgebildet werden. Diese UID sollte dem Benutzer nobody zugeordnet sein.

no_root_squash

Bildet Anforderungen von UID 0 nicht ab. Diese Option ist per Voreinstellung aktiviert, so daß Administratoren für alle exportierten Verzeichnisse Ihres Systems Root-Rechte haben.

link_relative

Diese Option wandelt absolute symbolische Links (die mit einem Slash beginnen) in relative Links um. Diese Option macht nur Sinn, wenn das gesamte Dateisystem des Host gemountet ist. Andernfalls könnten einige Links ins Nirgendwo zeigen oder, noch schlimmer, auf Dateien, auf die niemals verwiesen werden sollte. Diese Option ist per Voreinstellung aktiviert.

link_absolute

Diese Option läßt alle symbolischen Links unverändert (das normale Verhalten bei von Sun abgeleiteten NFS-Servern).

map_identity

Diese Option weist den Server an, gleiche UIDs und GIDs für Clients und Server zu erwarten. Diese Option ist per Voreinstellung aktiv.

map_daemon

Diese Option weist den NFS-Server an, nicht denselben UID/GID-Raum für Clients und Server zu erwarten. rpc.nfsd baut dann eine Liste auf, die IDs zwischen Client und Server durch Abfrage des Client-Dämons rpc.ugidd abbildet.

map_static

Mit dieser Option können Sie eine Datei angeben, die eine statische Zuordnung von UIDs und GIDs enthält. Beispielsweise spezifiziert map_static=/etc/nfs/vlight.map die Datei /etc/nfs/vlight.map für die UID/GID-Zuordnung. Die Syntax der Zuordnung ist in der Manpage exports(5) beschrieben.

map_nis

Diese Option bewirkt, daß der NIS-Server die UID- und GID-Zuordnung übernimmt.

anonuid und anongid

Diese Optionen legen die UID und GID des anonymen Accounts fest. Das ist nützlich, wenn Sie ein Volume für öffentliche Mounts exportiert haben.

Fehler beim Lesen der exports-Datei werden an die daemon-Einrichtung von syslogd auf der Ebene notice weitergegeben, wenn rpc.nfsd oder rpc.mountd hochfährt.

Beachten Sie, daß Hostnamen aus den IP-Adressen der Clients durch “Reverse Mapping” ermittelt werden, d.h., der Resolver muß korrekt konfiguriert sein. Wenn Sie mit BIND arbeiten und sehr sicherheitsbewußt sind, sollten Sie den Spoof-Schutz in Ihrer host.conf aktivieren. Auf diese Thematik gehen wir in Kapitel 6 Name-Server- und Resolver-Konfiguration, ein.

Weitere Informationen zum Linux - Wegweiser für Netzwerker

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center