NFS Version 3.1, 25. August 2002

1. Vorwort

1.1 Revisionen

Revision Version 3.1, Schreibfehler im Firewall-Abschnitt, 25.8.2002 , ausgeführt von: Tavis
Revision Version 3.0, Updates und Ergänzungen in Bezug auf Leistung und Sicherheit, 16.7.2002, ausgeführt von: Tavis

1.2 Copyright

Das Copyright(c) 2002 für die NFS-HOWTO liegt bei Tavis Barr, Nicolai Langfeldt, Seth Vidal und Tom McNeal. Die Verbreitung dieses Dokuments darf nur unter den Bedingungen der Open Content License, Version 1.0 oder neuer, erfolgen.

Die neueste Version ist bei http://www.opencontent.org/openpub/ erhältlich .

Das Copyright der englischen Version wurde auf die deutsche Übersetzung übertragen, es liegt bei Jürgen Pohl.

1.3 Gewährleistung

Die NFS-HOWTO wurde nach bestem Wissen und Gewissen geschrieben. Dieses Dokument wird ohne irgendwelche Garantien zur Verfügung gestellt, das gilt auch besonders für die kommerzielle Nutzung und die Verwendbarkeit für andere Zwecke. Die Verfasser und Maintainer übernehmen keinerlei Verantwortung für die Folgen der Anwendungen der beschriebenen Prozeduren dieses Dokuments, wie z.B. beschädigte Hardware, zerstörte Daten, feindliche Nachbarn, unerklärliches persönliches Verhalten, Ehescheidung und andere Widrigkeiten.

1.4 Feedback

Diese HOWTO wird nie als abgeschlossen betrachtet werden können. Feedbacks mit Verbesserungsvorschlägen sind willkommen. Die englischsprachige Linux-NFS-Homepage ist seit Februar 2002 bei http://nfs.sourceforge.net, dort finden Sie auch die neuesten Mailinglisten, Bugfixes und Updates, sowie den Namen des gegenwärtigen Maintainer.

1.5 Übersetzung

Für die Übersetzung dieser HOWTO in andere Sprachen wären wir dankbar - wir werden die Übersetzer nach besten Kräften unterstützen. Bitte nehmen Sie mit dem Maintainer Kontakt auf.

1.6 Danksagung

Die NFS-Anwendung für Linux wurde durch die Bemühungen vieler Mitarbeiter ermöglicht, von denen einige sich ganz besonders hervor getan haben. Die Originalversion wurde von Olaf Kirch und Alan Cox entwickelt.

Der Version 3-Servercode wurde von Neil Brown weiter entwickelt, er stützte sich auf die Arbeiten von Saadia Khan, James Yarbrough, Allen Morris, H.J.Lu und anderen. Der Client-Code ist von Olaf Kirch geschrieben worden, Trond Myklebust hat das Update verfasst. Saadia Khan entwickelte den Version 4-Lock-Manager. Dave Higgen und H.J.Lu übernahmen die undankbare Aufgabe, den Code durch ausführliche Überarbeitung und Fehlerbeseitigung funktionstüchtig zu machen. H.J. hat auch die umfangreiche Entwicklung des NFS-utils- Pakets vorangetrieben. Leider kann diese Widmung aus Platzgründen nicht alle Mitarbeiter aufführen.

Die NFS-HOWTO wurde ursprünglich von Nicolai Langfeldt geschaffen. In 2000 unterzogen sie Tavis Barr und Seth Vidal einer gründlichen Revision, um den zahlreichen Änderungen der Funktionen des NFS für Linux - verursacht durch die Entwicklungen der Linux-Kernel 2.0 bis 2.4 - Rechnung zu tragen. Tom McNeal überarbeitete die Howto wiederum im Februar 2002, er führte umfangreiche Ergänzungen im Abschnitt 5 und 7 durch. Thomas Emmel, Neil Brown, Trond Myklebust, Erez Zadok und Ion Badulescu haben ebenfalls hervorragende Beiträge geleistet.

2. Einführung

2.1 Was ist NFS ?

Das Network File System (NFS) ermöglicht das Einhängen von Festplattenpartitionen von einem entferntem Server, als sei es auf einer lokalen Festplatte. Dadurch wird schneller, nahtloser Zugang zu Dateisystemen über ein Netzwerk ermöglicht.

Falls das Netzwerk nicht korrekt installiert wurde, besteht jedoch die Möglichkeit des unerwünschten Zugriffs auf Ihre Festplatte (um Ihre E-mail zu lesen, Dateien zu löschen und in Ihr System einzudringen). Bitte informieren Sie sich im Abschnitt über Sicherheit, wenn Sie ein NFS einsetzen wollen.

Es gibt andere Systeme, die ähnliche Funktionen wie das NFS erfüllen. Samba liefert Dateiservices auf Windows-Clients ( http://www.samba.org/).

Das Andrew-Datei-System von IBM seit kurzem Open-Source, ermöglicht gemeinsame Dateibenutzung mit einigen zusätzlichen Sicherheitsfunktionen und Leistungseigenschaften.

Das Coda Datei System dessen Entwicklung besonders die Arbeit mit entfernten Clients verbessern soll, ist noch nicht abgeschlossen. Viele Charakteristiken des Andrew- und des Coda-Datei-Systems werden voraussichtlich in der Version 4 des NFS eingeschlossen sein.

Das heutige NFS hat die Vorteile eines ausgereiften, gut verständlichen Standard mit guter Unterstützung über viele Plattformen.

2.2 Was ist das Ziel dieser HOWTO ?

Diese HOWTO soll eine möglichst vollständige, schrittweise Einführung in die korrekte und erfolgreiche Installation des NFS in zwei Hauptschritten erreichen:

Konfigurationen des Servers und danach des Client - in dieser Reihenfolge. Ausserdem finden Sie Tipps für Anwender mit besonderen Bedingungen, Hardware-Installationen, Sicherheit und Fehlersuche.

Diese HOWTO ist keine Beschreibung der inneren Struktur des NFS. Wer darüber mehr wissen möchte, kann in «Linux NFS and Automounter Administration» von Erez Zadok (Sybex, 2001) nachlesen.

Das klassische NFS-Buch, inzwischen erneuert und immer noch brauchbar, ist «Managing NFS and NIS» von Hal Stern, publiziert bei O'Reilly Associates, Inc. Eine fortgeschrittenere technische Beschreibung des NFS liefert Brent Callaghan in «NFS Illustrated».

Das vorliegende Dokument ist auch nicht als vollständiges Referenz-Handbuch gedacht, es enthält infolgedessen keine umfassende Liste aller Eigenschaften des Linux-NFS.

(Die Manual Pages für nfs(5), exports(5), mount(8),fstab(5), nfsd(8), lockd(8), statd(8), rquotad(8) und mountd(8) enthalten umfassende Beschreibungen).

Das veraltete PC-NFS und NFS-Version 4 (noch in Entwicklung) sind ebenfalls nicht erwähnt (PC-Benutzer sind besser beraten, Samba zum Datenaustausch auf Windows-Maschinen zu benutzen).

2.3 Empfohlene Vorkenntnisse

Einige Grundkenntnisse von TCP-IP- Netzwerken wären sehr hilfreich, bevor Sie sich in diese HOWTO vertiefen. Die Networking Overview HOWTO kann Ihnen dabei behilflich sein.

2.4 Software-Voraussetzungen: Kernel-Versionen und nfs-utils

Die Unterschiede zwischen NFS-Version 2 und Version 3 werden später erklärt. Wir setzen voraus, dass NFS-Version 3 auf einem dedizierten oder einem mit hohen Datentransferraten beanspruchten Server installiert wird. NFS-Version 2 ist für gelegentlichen Gebrauch geeignet.

NFS-Version 2 wird seit einiger Zeit benutzt (beginnend mit dem Kernel 1.2). Mindestens Kernel 2.2.18 ist jedoch erforderlich, um folgendes durchzuführen:

Für Kernelversionen von 2.2.14 an aufwärts gibt es Patches, welche die oben genannten Funktionen ermöglichen. Einige können von der Linux NFS-Homepage heruntergeladen werden.

Falls Ihre Kernelversion zwischen 2.2.14 und 2.2.17 liegt und Sie den Sourcecode zur Verfügung haben, ist leicht festzustellen, ob diese Patches installiert sind. Server-Unterstützung ist eine der Konfigurationsoptionen der NFS-Version 3. Falls Sie nicht gezwungen sind, einen älteren Kernel zu benutzen, wäre es am besten einen Upgrade durchzuführen, denn in der Zwischenzeit wurden einige Probleme beseitigt.

Damit NFS-Version 3 funktioniert, sind NFS-utils Version 0.1.6. und Mount-Version 2.10m oder höher notwendig. Da nfs-utils und mount abwärtskompatibel sind und die neueren Versionen mehr Sicherheit und weniger Probleme haben, sollte dies Anreiz zur Installation der neuesten Versionen dieser Pakete im Rahmen der NFS-Installation sein.

Alle Kernel von 2.4 aufwärts sind für NFS-Version 3 voll funktionsfähig.

Wollen wir unseren eigenen Kernel bauen, müssen wir auf jeden Fall NFS und NFS-Version 3 vor dem Kompilieren auswählen. Die meisten, aber nicht alle Standard-Distributionen kommen mit NFS-Version 3-Unterstützung des Kernels.

Um mit Dateien umzugehen, die grösser als 2GB sind, wird ein 2.4x-Kernel und Version 2.2x von glibc notwendig.

Alle Kernel nach Version 2.2.18 unterstützen das NFS über TCP auf der Clientseite. Gegenwärtig gilt das NFS über TCP auf der Serverseite bei den Kerneln, die der 2.2.18 -Serie folgen, als experimentielle Option. Für Kernel 2.4 und 2.5 gibt es Patches - beginnend mit den Versionen 2.4.17 und 2.5.6. Die Patches werden als stabil betrachtet, jedoch sind sie noch verhältnismässig neu und nicht weit verbreitet oder in den 2.4-Kernel integriert.

Mit der Einführung neuer Kernel wurden viele neue Funktionen geschaffen, wir befassen uns hier mit allen neueren Versionen, von 2.2.18 bis einschliesslich 2.4. x. Für ältere Kernelversionen ist die NFS-Anwendung hier möglicherweise nicht korrekt beschrieben.

Während dieses Dokument verfasst wird, ist NFS-Version 4 als Protokoll fertiggestellt, die Anwendung als fertiges Produkt steht zur Zeit nicht zur Verfügung - wir werden deshalb hier nicht darauf eingehen.

2.5 Wo finden wir Hilfe und weitere Informationen

Im November 2000 war http://nfs.sourceforge.net die Linux-NFS-Homepage. Dort finden Sie Mailinglisten, die sich auf NFS beziehen, als auch die neuesten Versionen von NFS-utils, NFS-Kernelpatches und andere NFS-Pakete.

Tritt ein Problem oder eine Frage für Sie auf, die in dieser Howto, in Meist gefragte Fragen oder in den man pages nicht beantwortet wird, senden Sie am besten eine Message an die NFS-Mailing-Liste (http://nfs.sourceforge.net ). Um es den Developern und anderen Usern zu ermöglichen, Ihr Problem zu behandeln, fügen Sie bitte die folgenden Informationen bei:

Es ist auch nützlich, die Netzwerk - Konfiguration der verbundenen Hosts zu kennen.

Beinhaltet Ihr Problem nicht mounten oder shares exportieren zu können, fügen Sie bitte auch folgendes bei:

Das Beifügen dieser Informationen zu Ihren spezifischen Fragen - nachdem Sie die zugehörige Dokumentation gelesen haben - ist die beste Methode, um brauchbare Antworten zu erhalten.

Weitere Hinweise sind in den Manual Pages von nfs(5), exports(5), mount(8), fstab(5), nfsd(8), lockd(8), statd(8), rquotad(8) und mountd(8) zu finden.

3.1 Einführung in die Serverinstallation

Wir nehmen an, dass Sie einen Server und einen Client einrichten wollen. Installieren Sie nur einen Client, der von irgend einem Server bedient wird (z.B. in Ihrer Abteilung), können Sie direkt zum Abschnitt 4 weitergehen. Die Einrichtung jedes Client erfordert jedoch Änderungen am Server, um den Client zu autorisieren (es sei denn die Servereinstellung wird auf sehr unsichere Weise durchgeführt). Falls Sie keinen Server einrichten wollen, empfehlen wir jedoch diesen Abschnitt zu lesen - Sie erhalten einen Einblick in die Probleme, die mit der Autorisierung auftreten können.

Installieren des Servers erfolgt in zwei Schritten: Installation der Konfigurationsdateien des NFS und das Starten der NFS-Services.

3.2 Installation der Konfigurationsdateien

Drei Konfigurationsdateien müssen geändert werden, um ein NFS auf dem Server zu installieren: /etc/exports, /etc/hosts.allow und /etc/hosts.deny. Strenggenommen würde es ausreichen, /etc/exports zu ändern, um das NFS funktionsfähig zu machen, die Installation wäre jedoch höchst unsicher.

Wahrscheinlich müssen Sie auch die Start-Skripts ändern, im Abschnitt 3.3.3 finden Sie weitere Informationen darüber.

Jeder Eintrag in der Liste dieser Datei repräsentiert ein gemeinsames Volume und dessen Zugriffseigenschaften. Die Manual Pages (man export) enthalten ausführliche Beschreibungen der Setup-Optionen, das Nachfolgende ist wahrscheinlich für die meisten Fälle ausreichend.

Ein Eintrag in /etc/exports wird typisch wie folgt aussehen:

directory machine1(option11,option12) machine2(option21,option22)

Angenommen wir haben zwei Clients: Rechner 1 (slave1) und Rechner 2 (slave2), mit den IP-Adressen 192.168.0.1 und 192.168.0.2 . Wir wollen unsere Programme, Dateien und die Homeverzeichnisse für diese beiden Rechner zugänglich machen. Eine typische Installation für /etc/exports könnte so aussehen:

/usr/local/ 192.168.0.1(ro) 192.168.0.2(ro)
/home 192.168.0.1(rw) 192.168.0.2(rw)

Wir erlauben hiermit unseren Clients nur Lesezugriff auf /usr/local, da hier unsere Programme liegen, Schreibzugriff wird aus Sicherheitsgründen für Rechner 1 (slave1) und Rechner 2 (slave2) nicht erteilt. Dagegen ist Lese- und Schreibzugriff auf das exportierte Homeverzeichnis erwünscht, da hier die Benutzer ihre Dateien speichern und bearbeiten wollen. Im Falle einer umfangreicheren Installation, - z.B. eine Anzahl Rechner eines grösseren lokalen Netzwerks benötigen Zugang auf Ihren Server- bestehen mehrere Möglichkeiten, die Installation der Adressen zu vereinfachen. Erstens, eine Gruppe von Rechnern kann Zugang erhalten, indem sie als Netzwerk und mit netmask spezifiziert werden. Zum Beispiel können alle Rechner mit IP-Adressen zwischen 192.168.0.0 und 192.168.0.255 mit folgenden Einträgen Zugriff erhalten:

In der Networking-Overview-HOWTO finden Sie weitere Informationen, wie netmask funktioniert. Die Manual Pages für init und hosts.allow enthalten auch hilfreiche Hinweise.

Zweitens, Sie können NIS-netgroups verwenden. Um eine Netzgruppe in Ihrer Exportdatei zu bestimmen, setzen Sie ein «@» vor den Namen der Netzgruppe. Näheres dazu finden Sie in der NIS-HOWTO (http://www.linuxdoc.org/HOWTO/NIS-HOWTO.html).

Drittens, benutzen Sie das Jokerzeichen, wie z.B. *.foo.com oder 192.168. anstelle der Hostnamen. Es bestanden Probleme mit der Joker - Benutzung im 2.2 . Kernel, diese wurden jedoch im Kernel 2.2.19 behoben. Vergessen Sie jedoch nicht, dass diese Vereinfachungen Sicherheitsrisiken darstellen, wenn sich in Ihrer Netzgruppe oder im lokalen Netzwerk Rechner befinden, denen Sie nicht voll vertrauen können.

Vorsicht ist auch mit dem geboten, was nicht exportiert werden darf oder was nicht exportiert werden sollte.

Diese zwei Steuerdateien bestimmen, welche Rechner Zugang zu Ihrem Server erhalten. Jede Zeile der Datei führt einen Service und die zugehörigen Clients auf. Erhält der Server eine Anforderung eines Client-Rechners, führt er folgende Schritte durch:

Neben der Zugangskontrolle zu den Diensten, die von ineid kontrolliert werden (wie Telnet und FTP), können diese Dateien den Zugang zum NFS durch Beschränkungen der Verbindungen zu den entsprechenden Dämonen, die für NFS-Dienste zuständig sind, kontrollieren. Die Beschränkungen werden spezifisch auf die einzelnen Dienste ausgerichtet.

Der erste Dämon, welcher den Zugang beschränkt, ist der Portmapper. Dieser teilt den anfragenden Clients mit, wie die NFS-Services des Systems gefunden werden können. Beschränkter Zugang zum Portmapper ist die beste Verteidigung gegen Eindringlinge durch das NFS, weil vollständig unautorisierte Clients nicht wissen, wo die NFS-Dämonen zu finden sind. Wir müssen jedoch auf zwei Dinge achten: es genügt nicht, sich auf die Einschränkungen des Portmapper zu verlassen, falls ein Eindringling aus irgendwelchen Gründen weiss, wie die entsprechenden Dämonen zu finden sind. Zweitens, Beschränkung des Portmappers verhindert auch Anforderungen auf das NIS.

Das sollte im allgemeinen harmlos sein, normalerweise sollten das NFS und das NIS auf ähnliche Weise eingeschränkt sein. Es ist generell eine gute Idee das NIS und das NFS gleichzeitig auszuführen, weil die Client-Rechner auf irgendeine Art erfahren müssen, wer die exportierten Verzeichnisse besitzt. Natürlich gibt es andere Wege dafür, wie z.B. das Synchronisieren von Kennwörtern.

In der NIS-HOWTO (http://www.linuxdoc.org/HOWTO/NIS-HOWTO.html) findet man spezifische Anleitungen zur NIS-Installation.

Bei der Anwendung des NFS (wie auch bei den meisten anderen Netzwerkdiensten) ist es immer eine gute Idee, den Zugang zu den Hosts ausdrücklich auf das Notwendigste zu beschränken.Der erste Schritt dafür ist der folgende Eintrag in /etc/hosts.deny:

Mit Hilfe der NFS-utils 0.2.0 können Sie den Zugang zu bestimmten Dämonen enger begrenzen. Das ist eine gute Vorsichtsmassnahme, da Eindringlinge oft in der Lage sind den Portmapper zu umgehen. Falls Sie eine neuere Version der NFS-utils haben, können Sie bei den NFS-Dämonen entsprechende Einträge vornehmen (im nächsten Abschnitt wird darauf näher eingegangen). Für jetzt machen wir für die Dämonen einen Eintrag in hosts.deny:

lockd:ALL
mountd:ALL
rquotad:ALL
statd:ALL

Selbst wenn Sie eine ältere Version der NFS-utils benutzen, sind diese Einträge im schlimmsten Fall harmlos - sie werden ignoriert. Beim nächsten Upgrade, werden Sie es jedoch etwas einfacher haben. Einige Systemverwalter machen den Eintrag ALL:ALL in /etc/hosts.deny, hierdurch wird den Services, die nicht ausdrücklich erlaubt sind, der Zugang verweigert.

Dieses sehr sichere Verfahren kann Ihnen jedoch bei der späteren Installation neuer Services Schwierigkeiten bereiten. Haben Sie den Eintrag vergessen, können Sie eventuell nicht herausfinden, warum die Service-Installation scheitert.

Als nächstes müssen wir noch einen Eintrag in hosts.allow vornehmen, um allen erwünschten Hosts Zugriff zu geben.(Beschränken wir uns nur auf die Einträge in hosts.deny hat niemand Zugang zum NFS.)

Die Einträge in hosts.allow erfolgen im Format:

Hier bedeutet 'host' die IP-Adresse des erwünschten Client. Es ist möglich in einigen Versionen den DNS-Namen des Host zu benutzen, wir raten jedoch sehr davon ab. Angenommen, wir haben die oben genannten Bedingungen und wir möchten Rechner1.foo.com und Rechner2.foo.com Zugang erlauben, die Rechner haben die IP-Adressen 192.168.0.1 und 192.168.0.2. Unser Eintrag in /etc/hosts.allow:

Bei neueren NFS-utils-Versionen würden wir folgendes einfügen (falls die Einträge nicht unterstützt werden, sind sie harmlos):

lockd:192.168.0.1 , 192.168.0.2
rquotad:192.168.0.1 , 192.168.0.2
mountd:192.168.0.1 , 192.168.0.2
statd:192.168.0.1 , 192.168.0.2

Wollen Sie ein NFS auf einer grösseren Anzahl von Rechnern eines lokalen Netzwerks benutzen, erlauben Ihnen /etc/hosts.allow Einträge in der Form network/netmask, wie vorgehend im /etc/exports- Beispiel gezeigt.

3.3 Starten des NFS

Der NFS-Server sollte nun konfiguriert und betriebsbereit sein. Wir müssen jedoch herausfinden, ob neuere Versionen des Kernels und der NFS-utils- Dateien installiert sind. Nachprüfen gemäss Abschnitt 2.4.

Ehe Sie das NFS starten, muss die TCP-IP-Netzwerkfunktion bestehen. Können Sie Telnet, FTP, usw. benutzen, ist der TCP-Netzwerkbetrieb wahrscheinlich in Ordnung. Bei den neueren Linuxdistributionen sollte das NFS bei einen Neustart automatisch aktiviert werden, die Startup-Skripts sollten Ihre Einträge in /etc/exports entdecken und das NFS wie erwartet starten. Siehe Abschnitt 3.4 : Bestätigen, dass NFS aktiv ist.

Führt das zu keinem Ergebnis oder ist der Rechner an einer Stelle, wo er nicht neu gestartet werden kann, finden Sie im folgenden Abschnitt, welche Dämonen gestartet werden müssen, um das NFS funktionstüchtig zu machen. Lief nfsd schon auf Ihrem Rechner vor den Änderungen Ihrer Konfigurationsdateien, müssen Sie Ihre Konfiguration rückgängig machen, siehe Abschnitt 3.5 für nähere Einzelheiten.

NFS braucht zum Starten den Portmapper-Dämon portmap oder rpc.portmap, dieser muss als erstes gestartet werden. Er sollte in /sbin, manchmal auch in /usr/sbin zu finden sein. Die neueren Linuxdistributionen starten diesen Dämon im Bootskript. Prüfen Sie, ob das zutrifft, indem Sie

ps ¦ grep portmap

eingeben.

Das NFS wird durch fünf Dämonen gesteuert: rpc.nfsd (der die meiste Arbeit leistet), rpc.lockd und rpc.statd sind für das File-Locking zuständig, rpc.mountd kümmert sich um die ersten Mount-Anforderungen und rpc.rquotad ist für die Dateiquoten der exportierten Volumes verantwortlich. Seit dem Kernel 2.2.18 wird lockd bei Bedarf durch nfsd aufgerufen - kein besonderer Eingriff ist erforderlich. statd muss separat gestartet werden. Die meisten neueren Linuxdistributionen enthalten Startup-Skripts für diese Dämonen, sie sind alle als Teil des NFS-utils-Pakets im /sbin - oder im /usr/sbin -Verzeichnis zu finden. Enthält Ihre Distribution die Dämonen nicht in den Startup-Skripts, sollten Sie diese in der Reihenfolge hinzufügt werden:

rpc.portmap
rpc.mountd,rpc.nfsd
rpc.statd, rpc.lockd(falls nötig), rpc.rquotad

Die NFS-utils-Pakete von Red Hat und Debian enthalten Beispiele von Startup-Skripts. Für andere Distributionen, können Sie im allgemeinen den Red Hat-Skript kopieren. Sie werden wahrscheinlich die Zeile

entfernen müssen, um Fehlermeldungen zu vermeiden.

3.4 Bestätigen, dass NFS funktioniert

Mit dem Kommando rpcinfo-p sollten Sie den Portmapper abfragen, welche Dienste geleistet werden. Das Resultat sollte etwa so aussehen:

program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100011 1 udp 749 rquotad
100011 2 udp 749 rquotad
100005 1 udp 759 mountd
100005 1 tcp 761 mountd
100005 2 udp 764 mountd
100005 2 tcp 766 mountd
100005 3 udp 769 mountd
100005 3 tcp 771 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
300019 1 tcp 830 amd
300019 1 udp 831 amd
100024 1 udp 944 status
100024 1 tcp 946 status
100021 1 udp 1042 nlockmgr
100021 3 udp 1042 nlockmgr
100021 4 udp 1042 nlockmgr
100021 1 tcp 1629 nlockmgr
100021 3 tcp 1629 nlockmgr
100021 4 tcp 1629 nlockmgr

Das bedeutet, wir haben NFS-Versionen 2 und 3, rpc.statd -Version 1, Network-Lock-Manager (der Servicenamen für rpc.lockd) Version 1,3 und 4. Ebenfalls aufgeführt sind verschiedene Serviceausführungen, je nachdem ob das NFS TCP oder UDP benutzt. Die Linux-Standardeinstellung ist UDP, TCP muss besonders angefordert werden. Andere Betriebssysteme wie z.B. Solaries benutzen TCP als Standardeinstellung. Ist nicht mindestens je eine Zeile mit portmap, nfs und mountd zu finden, müssen Sie in der Prozedur zurückgehen und versuchen, die entsprechenden Dämonen zu starten (siehe auch Abschnitt 7. Fehlersuche, falls das nicht funktioniert). Finden Sie diese Services in der Liste, können die Clients für den Dateizugriff auf den Server konfiguriert werden.

3.5 Spätere Änderungen in /etc/exports

Änderungen in /etc/exports werden nicht sofort aktiviert. Mit dem Kommando exportfs-ra zwingen Sie nfsd die /etc/exports-Datei neu einzulesen. Ist das Kommando exportfs nicht zu finden, killen Sie nfsd mit der -HUP flag (siehe Manual Pages für kill). Hilft auch das nicht, prüfen Sie in hosts.allow, ob keine neuen Client-Rechner übersehen wurden. Prüfen Sie auch die Host-Liste der Firewalls, die vielleicht installiert sind (siehe Abschnitt 6. für weitere Einzelheiten zu Firewalls und NFS).

4. Einrichten eines NFS Client

4.1 Entfernte Verzeichnisse mounten

Prüfen Sie vor dem Mounten, ob Ihr mount-Programm nicht veraltet ist (Version 2.10m für NFS-Version 3) und ob der Clientrechner NFS-mounten unterstützt - die meisten Linux-Standarddistributionen sind dazu in der Lage. Benutzen Sie den Kernel 2.2 oder eine ältere Version mit dem /proc- Dateisystem, sehen Sie im /proc -Verzeichnis, ob es eine Zeile mit NFS enthält. Ist das nicht der Fall, könnte es durch die Eingabe von insmod nfs erscheinen, falls NFS als Modul kompiliert wurde. Führt das nicht weiter, müssen Sie einen Kernel neu bauen (oder downloaden), der NFS-Unterstützung integriert hat. Kernel, die NFS nicht kompiliert haben, werden im allgemeinen eine spezifische Fehlermeldung nach dem mount- Befehl (wie unten aufgeführt) ausgeben. Damit ein Rechner als NFS-Client funktioniert, muss der Portmapper installiert sein. Für die Benutzung des NFS-File-Locking, müssen rpc.statd und rpc.lockd auf dem Client und dem Server laufen. Die meisten neueren Distributionen starten diese Programme in der Standardeinstellung beim Bootvorgang. Falls ihr Rechner dieses nicht durchführt: siehe Abschnitt 3.2., wie das behoben werden kann. Mit portmap, lockd und statd in Betrieb, sollte es jetzt möglich sein, das entfernte Verzeichnis von Ihrem Server aus zu mounten, als sei es eine lokale Festplatte. Benutzen wir unser Beispiel aus dem vorgehenden Abschnitt und nehmen wir an, unser Server heisst master.foo.com und wir möchten das /home-Verzeichnis auf dem Rechner slave1.foo.com mounten. Der nächste Schritt ist sehr einfach, in der root-Eingabeaufforderung des Rechner slave1.foo.com schreiben wir:

und das Verzeichnis /home wird als Verzeichnis /mnt/home auf dem slave1.foo.com erscheinen. ( Anmerkung: wir nehmen an, dass das Verzeichnis /mnt/home vorher als leerer Mount-Point eingerichtet wurde). Falls das schiefgeht, siehe Fehlersuche (Abschnitt 7).

Sie können das Verzeichnis wieder loswerden, indem Sie eingeben:

genau wie in einem lokalen Dateisystem.

4.2 Mounten von NFS-Dateisystemen beim Bootvorgang

NFS-Verzeichnisse können der /etc/fstab-Datei wie in einem lokalen Verzeichnis beigefügt werden, d.h. sie mounten, wenn das System startet. Der einzige Unterschied ist, dass der Typ des Dateiensystems auf nfs gesetzt wird, die Instruktionen dump und fsck (die letzten beiden Einträge im /etc/fstab) werden auf Null gestellt. Für unser obengenanntes Beispiel sehen die Einträge im /etc/fstab folgendermassen aus:

Die Manual Pages für fstab geben Anleitungen zur Syntax dieser Datei. Wird ein Automounter (z.B. amd oder autofs) benutzt, sehen die entsprechenden Felder für die Mount-Anweisungen sehr ähnlich oder gleich aus. Jetzt sollte das NFS funktionstüchtig sein, einige spätere Feineinstellungen werden es noch verbessern. Bitte lesen Sie im Abschnitt 6. nach, ob Ihre Konfiguration wirklich sicher ist.

4.3 Mount-Optionen

Einige Optionen sollten umgehend eingeschaltet werden. Diese bestimmen das Verhalten von NFS-Clients bei einem Server-Crash oder bei Netzwerkzusammenbruch. Das NFS übersteht diese bestens, wenn die Clients richtig konfiguriert wurden. Es gibt zwei sehr unterschiedliche Verhaltensweisen des Versagens:

Machen wir mit dem vorangegangenen Beispiel weiter, fstab wird folgenden Eintrag erhalten:

Die rsize - und wsize-mount-Optionen bestimmen die Grösse der Datenpakete, welche Client und Server in beiden Richtungen miteinander austauschen. Die Grundeinstellungen können entweder zu gross oder zu klein sein, es existiert keine bestimmte optimale Grösse, die mit allen oder fast allen Konfigurationen arbeitet.

Einerseits haben einige Kombinationen von Linuxkerneln und Netzwerkkarten (meistens auf älteren Rechnern) Mühe mit grossen Blöcken.

Können diese jedoch grosse Blöcke verarbeiten, erzielt das meistens grössere Geschwindigkeiten. Das Festlegen der richtigen Blockgrösse ist ein wichtiger Faktor für die Systemleistung und damit für die produktive Nutzung des NFS-Servers. Siehe Abschnitt 5. für Hinweise.

5. Optimieren der NFS-Leistung

Der erste Schritt zur optimalen Leistung des NFS ist die sorgfältige Analyse Ihrer Netzwerkumgebung - aus der Sicht des Client als auch des Servers. Im ersten Abschnitt beschäftigen wir uns mit Eigenschaften, die allgemein für den Client wichtig sind. Danach (Abschnitt 5.3 und folgend) wenden wir uns dem Server zu. In beiden Fällen werden die Eigenschaften nicht ausschliesslich auf die eine oder andere Seite beschränkt, es ist jedoch nützlicher die beiden auseinander zu halten, um einen besseres Bild von Ursachen und Wirkungen zu erhalten Neben der allgemeinen Konfiguration des Netzwerks - wie zum Beispiel angemessene Netzkapazität, schnellere NIC's, vollständige Duplex-Einstellungen (um Kollisionen zu verhindern), Übereinstimmung in der Netzwerkgeschwindigkeit zwischen Schaltern und Hubs, usw. - sind die richtigen Grössen der NFS-Datenpuffer am wichtigsten. Sie werden durch die mount-Kommandooptionen von rsize und wsize bestimmt.

5.1 Bestimmen der Blockgrösse für optimale Transfergeschwindigkeiten

Die mount-Kommandooptionen für rsize und wsize bestimmen die Grösse der Datenpakete, welche Client und Server austauschen. Werden die Optionen von rsize und wsize nicht besonders bestimmt, findet man unterschiedliche Standardeinstellungen, je nach NFS-Version. Der häufigste Defaultwert ist 4K (4096 bytes). Für Mounts auf TCP-Basis in Kernel-Version 2.2 und für alle Mounts von Kernel-Version 2.4 an aufwärts, bestimmt der Server die Blockgrössen-Standardeinstellung.

Die maximale Blockgrösse wird ebenfalls durch den Server bestimmt. Sie wird durch die Kernelkonstante NFSSVC_MAXBLKSIZE definiert - zu finden in der Linux-Sourcedatei ./include/linux/nfsd/const.h. Die jetzige maximale Blockgrösse für den Kernel 2.4.17 ist 8K(8192 bytes). Der Patch, durch den NFS über TCP/IP-Transport implementiert wird, gibt jedoch einen Wert von 32K (im Patch als 32*1024 definiert) als Maximalblockgrösse an.

Gegenwärtig unterstützen alle 2.4 - Clients Blockgrössen bis zu 32k, dadurch wird der Transfer von Standard-32k-Blöcken über das NFS von anderen Servern, wie z.B. Solaris, ohne Eingriff des Client ermöglicht.

Die Standardeinstellungen können je nach der Kombination von Hardware und Kernel unterschiedliche Grössen haben. Einige Kombinationen von Linuxkerneln und Netzwerkkarten (meistens auf älteren Rechnern) haben Mühe mit grossen Blöcken. Sind sie jedoch in der Lage, grosse Blöcke zu verarbeiten, erreicht man in einigen Fällen grössere Geschwindigkeiten.

Wir werden durch Versuche die schnellste rsize - und wsize -Konfiguration finden. Die Geschwindigkeit der eingestellten Optionen kann mit einigen einfachen Kommandos getestet werden, falls das Netzwerk nicht gerade stark benutzt wird. Ist das Netzwerk schon schwer belastet, können Ihre Resultate stark variieren, es sei denn Sie benutzen ein komplexeres Benchmarkprogramm, wie Bonnie, Bonnie++ oder IOzone.

Mit dem ersten dieser Kommandos senden wir 16384 Blöcke mit je 16k der Spezialdatei /dev/zero (bestehend aus schnell übertragbaren Null-Bytes) auf die Mount-Partition. Wir werden die Übertragungszeit messen. Auf den Client-Rechner geben Sie ein:

Das ergibt eine 256MB-Datei von Null-Bytes. Als Richtlinie sollte die Datei mindestens die doppelte Grösse des Server-RAM haben, achten Sie jedoch auf das verfügbare Festplattenvolumen. Dann senden sie die Datei zurück auf den Client-Rechner (/dev/null) mit dem folgenden Befehl:

Wiederholen Sie diesen Vorgang einige Male und ermitteln Sie den Durchschnittswert der Übertragungsdauer. Unmounten und mounten Sie das Dateisystem jedes Mal auf dem Client und dem Server, das sollte alle Zwischenspeicher klären. Führen Sie die unmount/mount-Prozedur mit grösseren und kleineren Blockgrössen durch. Deren Grössen sollten Vielfache von 1024 Bytes betragen, beachten Sie jedoch die maximale Grösse, welche Ihr System erlaubt. Das NFS-Version 2 ist auf das Maximum von 8K begrenzt, unbeeinflusst von der maximalen Blockgrösse gemäss dem NFSSVC_MAXBLKSIZE. NFS-Version 3 kann bis zu 64K verkraften. Nach allgemeiner Erfahrung sollte die Blockgrösse eine Verdoppelung der Grundzahl (1024) sein, da alle einschränkenden Parameter (z.B. die Blockgrössen des Dateisystems und die Netzwerkpaketgrösse) ebenfalls dieser Regel folgen. Viele Benutzer scheinen jedoch erfolgreicher mit der Blockgrösse als Vielfache der Blockgrösse des Dateiensystems und der Netzwerkpaketgrösse zu sein.

Wechseln Sie sofort nach dem Mounten einer grösseren Datei in das entsprechende Verzeichnis und führen Sie einige Kommandos wie ls durch, um herauszufinden, ob die Dinge wie erwartet verlaufen. Werfen Sie auch einen Blick auf das Dateisystem, ob die Dinge wie geplant aussehen. Sind rsize und wsize zu gross, sind die Symptome manchmal recht eigenartig und nicht besonders auffallend. Ein typisches Anzeichen sind unvollständige Dateilisten bei der Ausführung des «ls»-Kommandos und keine Fehlermeldungen. Oder das Lesen von Dateien versagt plötzlich ohne Fehlermeldung. Nachdem die rsize/wsize-Grösse herausgefunden wurde, führen Sie den Datenübertragungstest erneut durch. Die verschiedenen Serverplattformen haben unterschiedliche optimale Übertragungsraten.

Vergessen Sie nicht, die neu ermittelten Werte für rsize/wsize in /etc/fstab/ einzutragen.

Erscheinen Ihre Ergebnisse ungleichmässig oder zweifelhaft, ist es ratsam, dass Sie Ihr Netzwerk mit verschiedenen rsize- und wsize-Werten weitgehender analysieren. Für diesen Fall einige Hinweise zu mehreren nützlichen Benchmarkprogrammen:

Das z.Z. benutzerfreundlichste Benchmarkprogramm scheint IOzone zu sein. Es liefert den grössten Prüfumfang, einschliesslich einer weiten Anzahl von Dateigrössen und I/O-Typen, wie lesen, schreiben,.... Für eine Durchführung von IOzone (root-Zugang ist erforderlich) empfehlen wir unmounten und mounten des zu testenden Dateisystems, um die Zwischenspeicher zwischen den Testläufen zu leeren. Die Zeit zum Schliessen der Dateien sollte mitgemessen werden. Unter der Annahme Sie haben /temp an alle Clients verteilt und IOzone ist in einem lokalen Verzeichnis installiert, sollte die folgende Prozedur erfolgreich sein:

# echo "foo:/temp /mnt/foo nfs rw, hard, intr, rsize=8192, wsize=8192 0 0"
>> /etc/fstab
# mkdir /mnt/foo
# mount /mnt/foo
#./iozone -a -R -c -U /mnt/foo -f /mnt/foo/testfile > logfile

Der Benchmarkprozess sollte nicht länger als 2 bis 3 Stunden für jeden rsize- und wsize-Wert dauern. Auf der oben genannte Webseite ist die vollständige Dokumentation der Parameter zu finden. Die Optionen für das eben genannte Beispiel bedeuten:

5.2 Paketgrösse und Netzwerktreiber

Es gibt viele ausgezeichnete Netzwerktreiber für Linux, einige sind jedoch ziemlich schlampig - darunter ein paar Treiber von namhaften Netzwerkkarten. Experimentieren Sie direkt mit Ihrer Netzwerkkarte, um herauszufinden, welchen Datenverkehr diese am besten verträgt. Versuchen Sie mit den ping-Optionen -f und -s grössere Pakete zwischen den zwei Rechnern hin- und herpendel zu lassen (Näheres in den man ping -Manual Pages). Gehen viele Pakete verloren oder dauert das Ansprechen auf die Übertragungsaufforderung zu lange, ist vermutlich die Leistung der Netzwerkkarte nicht ausreichend.

Für eine weitreichendere Analyse des NFS-Verhaltens benutzen Sie das nfsstat- Kommando, um einen Blick auf die NFS-Transaktionen, die Client- und Server-Statistik, die Netzwerkstatistik, usw zu werfen. Die -o net-Option wird die Anzahl der verlorenen Pakte in Bezug auf die Gesamtzahl der Übertragungen angeben. Bei UDP-Transaktionen ist das wichtigste statistische Ergebnis die Anzahl der Transmissionswiederholungen (verusacht durch fallengelassene Pakete), Socket-Puffer-Überlauf, allgemeine Serverüberlastung, Timeouts, usw. All das hat schwerwiegenden Einfluss auf die NFS-Leistung und sollte daher sorgfältig beobachtet werden. Beachten Sie, dass nfsstat noch nicht die -z-Option implementiert, diese würde alle Zähler auf Null zurücksetzen, d.h. bevor Sie einen neuen Bechmark-Test laufen lassen, müssen Sie feststellen was die gegenwärtigen Werte des nfsstat-Zählers sind.

Um Netzwerkprobleme zu beseitigen, sollte die Paketgrösse der Netzwerkkartenleistung angepasst werden. Nicht selten existiert auch ein anderer Engpass irgendwo im Netz, z.B. beim Router, der die Paketgrösse - welche die Netzwerkkarte übertragen könnte - zwischen zwei Rechnern einschränkt. TCP sollte die richtige Paketgrösse für das Netzwerk automatisch entdecken, UDP bleibt bei seiner Standardeinstellung. Die Ermittlung der richtigen Paketgrösse ist bei der Anwendung von NFS über UDP besonders wichtig.

Die Netzwerkpaketgrösse kann mit dem tracepath-Kommando geprüft werden: Geben Sie auf dem Client tracepath [server] 2049 ein, dadurch sollte das MTU des Pfades angezeigt werden. Durch die MTU-Option in ifconfig kann das MTU der Netzwerkkarte auf den gleichen Wert wie das Pfad-MTU eingestellt werden, dadurch können Sie feststellen, ob weniger Pakete verlorengehen. Näheres über die Einstellung der MTU-Optionen ist in den ifconfig-Manual Pages zu finden.

Zusätzlich liefert netstat -s Messdaten, die den Verkehr über alle unterstützten Protokolle betreffen. Sie finden auch in /proc/net/snmp Informationen über das gegenwärtige Verhalten des Netzwerks - im nächsten Kapitel sind nähere Einzelheiten darüber aufgeführt.

5.3 Überlauf von fragmentierten Paketen

Die Anwendung von rsize oder wsize mit einer Grösse, welche des Netzwerks MTU (in vielen Netzwerken auf 1500 eingestellt) übersteigt, verursacht IP-Paket-Fragmentierung beim Gebrauch des NFS über UDP. IP-Paket-Fragmentierung und Zusammensetzen erfordern grosszügige CPU-Ressourcen an beiden Enden der Netzwerkverbindung. Zusätzlich macht die Paket-Fragmentierung den Netzwerkverkehr unzuverlässiger, da eine vollständige RPC-Anforderung zurückgeschickt werden muss, wenn ein UDP-Paket-Fragment aus irgend einem Grund fallen gelassen wird. Jeder Anstieg von RPC-Rückanforderungen, kombiniert mit einer höheren Anzahl von Timeouts, ist das schlimmste Leistungshindernis des NFS über UDP.

Pakete können aus vielen Gründen fallengelassen werden. Bei einer komplexen Netzwerktopografie können die Fragmentrouten variieren oder die Fragmente erreichen den Server nicht zum Zusammensetzen. Die NFS-Serverkapazität kann auch eine Rolle spielen, bei Erreichen der Pufferkapazität des Kernels beginnt dieser Pakete wegzuwerfen. Bei Kerneln, die das /proc- Dateisystem unterstützen, können die Dateien /proc/sys/net/ipv4/ipfrag_high_thresh und /proc/sys/net/ipv4/ipfrag_low_thresh überwacht werden.

Ein anderer Zähler zur Überwachung ist: IP:ReasmFails in der Datei /proc/net/snmp, das ist die Anzahl der verfehlten Fragment- Assemblies - falls diese Zahl während starkem Datenverkehr zu schnell ansteigt, haben wir ein Problem.

5.4 NFS über TCP

Ein neues Feature - erhältlich für die Kernel 2.4 und 2.5, gegenwärtig jedoch noch nicht für die Mehrzahl der Kernel verfügbar - ist NFS über TCP. Der Gebrauch von TCP hat bestimmte Vor- und Nachteile im Vergleich zu UDP. Der Vorteil ist, dass es weit besser als UDP in verlustreichen Netzwerken funktioniert. Beim Gebrauch von TCP wird ein einzelnes fallengelassenes Paket neu angefordert, ohne dass die gesamte RPC-Übertragungsaufforderung wiederholt werden muss, das ergibt bessere Leistungen in einem verlustreichen Netzwerk. Ausserdem wird TCP - dank des unterstützenden Flow Control auf der Netzwerkebene - besser mit Geschwindigkeitsunterschieden fertig als UDP.

Der Nachteil bei der Benutzung des TCP liegt darin, dass es kein statusloses Protokoll wie UDP ist. Stürzt Ihr Server mitten in einer Paket-Transmission ab, hängt der Client, d.h. alle gemeinsam genutzten Dateien müssen entfernt und wieder neu gemountet werden.

Der Overhead, den das TCP-Protokoll erzeugt, ergibt eine etwas langsamere Leistung als UDP unter idealen Netzwerkbedingungen, der Preis dafür ist jedoch nicht einschneidend und ist meistens ohne sorgfältige Messungen nicht feststellbar. Falls Sie ein umfassendes Gigabit-Ethernet benutzen, sollten Sie die Verwendung von Jumbo-Frames erwägen, da ein Hochgeschwindigkeitsnetzwerk erweiterte Framegrössen ohne erhöhte Kollisionsraten ermöglicht - besonders wenn das Netzwerk auf Vollduplex eingestellt ist.

5.5 Timeout und Retransmissions - Werte

Zwei Mount-Kommando-Optionen, timeo und retrans, kontrollieren das Verhalten der UDP-Anforderungen, wenn Timeouts, verursacht durch fallengelassene Pakete, Netzwerküberlastung, usw. auftreten. Die -o timeo - Option erlaubt die Einstellung des Zeitraums - in Zehnteln von Sekunden - die der Client wartet, bis er sich entscheidet, dass er keine Antwort vom Server erhält und eine neue Anforderung schickt. Die Grundeinstellung ist 0,7s. Die o-retrans - Option erlaubt die Einstellung der Anzahl der Timeouts, die der Client erlaubt, bevor er mit der Meldung Server not responding reagiert. Die Grundeinstellung ist 3 Versuche. Nach dieser Meldung versucht der Client weiterhin Anforderungen zu senden, jedoch nur einmal falls ein weiterer Timeout erfolgt, dann erscheint die Meldung wieder. Wenn es dem Client gelingt, wieder Kontakt aufzunehmen, kehrt er zu den ursprünglichen retrans-Werten zurück und gibt die Meldung: Server OK.

Falls schon zu viele Retransmissionen auftreten ( siehe Resultat des nfsstat-Befehls) oder Sie wollen die Grösse der Transferblöcke ohne Timeouts und Retransmissionen erhöhen, müssen Sie die Defaultwerte ändern. Die spezifischen Änderungen hängen von Ihrer Netzwerkumgebung ab, in den meisten Fällen ist die Grundeinstellung angemessen.

5.6 Anzahl der NFS-Instanzen des NFSD Server-Dämons

Die meisten Startup-Skripts (in Linux und anderen Systemen) starten mit 8 nfsd-Instanzen. Als das NFS eingeführt wurde, entschied sich Sun für diese Zahl als Grundregel, die allgemein befolgt wurde. Es besteht keine allgemeine Regel für die optimale Anzahl von Instanzen, ein Server mit grossem Datendurchsatz benötigt eventuell eine höhere Anzahl. Sie sollten mindestens einen Dämon pro Prozessor einsetzen, jedoch vier bis acht je Prozessor sind eine bessere Gebrauchsregel. Benutzen Sie Kernel 2.4 oder höher und Sie möchten wissen, wie häufig jeder nfsd -Strang benutzt wird, werfen Sie einen Blick in die Datei /proc/net/rpc/nfsd. Die letzten zehn Zahlen in der th-Zeile sind die Sekunden, während derer sich der Stranggebrauch in den oberen Prozenten des erlaubten Maximums befand. Finden Sie eine grössere Anzahl in den höheren Prozentzahlen (z.B.70%), sollten Sie die Zahl der nfsd-Instanzen erhöhen. Das geschieht durch Eintrag der gewünschten Zahl der Instanzen in die Befehlszeile der nfsd-Optionen, es wird durchgeführt im NFS- Startup-Skript (/etc/rc.d/init.d/nfs in Red Hat) mittels RPCNFSDCOUNT. Näheres ist in den nfsd(8)- Manual Pages zu finden.

5.7 Speicherbegrenzungen der Eingabewarteschlange

Die Sockel-Eingabewarteschlangen der Kernel 2.2 und 2.4, in welcher die Anfragen während des Verarbeiten warten, hat einen kleinen Standardeinstellungswert (rmem_default) von 64k. Diese Warteschlange ist für Clients mit grösseren Lesebelastungen und für Server mit erhöhten Schreibbelastungen wichtig.

Wenn Sie z.B. 8 nfsd-Instanzen auf dem Server laufen haben, wird für jede nur 8k-Speicher zur Verarbeitung der Schreibanfrage bereitgestellt. Noch dazu hat die Sockel-Ausgabewarteschlange - wichtig für Clients mit grosser Schreiblast und Server mit höherer Leselast - eine kleine Standardeinstellung (wmem_default).

Einige veröffentlichte Ergebnisse des NFS-Benchmark. Programms SPECsfs machen viel höhere Angaben für die Lese- und Schreibwerte, [rw] mem_default und [rw] mem_max. Sie sollten die Erhöhung dieser Werte auf mindestens 256k erwägen. Die Lese- und Schreibwerte werden im proc-Dateisystem eingestellt, z.B. in den Dateien /proc/sys/net/core/rmem_default und /proc/sys/net/core/rmem_max. Der /proc/sys/net/core/rmem_default-Wert kann in drei Schritten erhöht werden. Die folgende Methode ist ein Hack, der jedoch ohne Probleme funktionieren sollte.

Erhöhen Sie den Wert in der Datei:

echo 262144 /proc/sys/net/core/rmem_default
echo 262144 /proc/sys/net/core/rmem_max

Neustarten von NFS, z.B. Eingabe in Red Hat :

Wiederherstellen der ursprünglichen Werte für den Fall, dass andere Kernel von diesen abhängig sind:

echo 65536 /proc/sys/net/core/rmem_default echo 65536 /proc/sys/net/core/rmem_max

Führen Sie unbedingt den letzen Schritt durch. Die Erfahrung zeigt, dass Rechner abstürzen, wenn dieser Wert über längere Zeit erhöht bleibt.

5.8 Autonegotiation vom NICs und den Hubs abschalten

Falls die die Autonegotiation der Netzwerkkarten nicht mit den Hubs und den Switches kooperiert, die Ports mit verschiedenen Geschwindigkeiten oder mit unterschiedlichen Duplexeinstellungen arbeiten, wird die Leistung durch zu viele Kollisionen, fallengelassene Pakete, usw., stark beeinflusst. Falls Sie eine zu hohe Anzahl von fallengelassenen Paketen im nfsstat-Output oder eine allgemein schlechte Netzwerkleistung feststellen, experimentieren Sie mit der Netzwerkgeschwindigkeit und der Duplexeinstellung. Wenn möglich, richten Sie ein vollständiges 100Base T - Subnetz ein, die Eliminierung von fast allen Kollisionen in Voll-Duplex beseitigt den schlimmsten Bremsklotz für das NFS über UDP. Vorsicht beim Abschalten der Autonegation der Netzwerkkarte: der Hub oder der Switch mit denen die Karte verbunden ist, sucht nach anderen Mitteln (z.B. parallele Erkennung), um die Duplexeinstellungen herauszufinden. Einige Karten benutzen Halb-Duplex als Grundeinstellung, da es wahrscheinlicher ist, das dieses von einem älteren Hub unterstützt wird. Die beste Lösung - falls vom Treiber unterstützt - zwingt die Karte 100Base T- Vollduplex zu benutzen.

5.9 Vergleich von synchronem und asynchronem Verhalten des NFS

Das Standard-Export-Verhalten für die NFS-Version 2 - und Version 3 - Protokolle und der Defaultwert von exportfs der nfs-utils-Versionen vor 1.11 ( dieses ist in der CVS-Baumstruktur zu finden, wurde jedoch noch nicht - d.h. Januar 2002 - in einem Paket veröffentlicht ) ist «asynchron». Diese Grundeinstellungen erlauben dem der Server, den Anforderungen des Client zu entsprechen, sobald er die Dateien verarbeitet und an das lokale Dateisystem übergeben hat, ohne darauf zu warten, dass die Daten sicher geschrieben sind. Die Markierung der «async»-Option in des Servers Exportliste bestätigt das. Das Ergebnis ist bessere Leistung auf Kosten möglicher Datenkorruption, falls der Server rebootet, während noch ungeschriebene Daten und/oder Metadaten zwischengespeichert werden. Diese mögliche Datenkorruption kann während dieses Vorgangs nicht entdeckt werden, da die sync -Option den Server anweist den Client zu täuschen, indem diesem mitgeteilt wurde, dass die Daten - unabhängig vom benutzten Protokoll - sicher abgelagert wurden.

Um «synchron»- Verhalten zu erzwingen, was für die Ausführung des NFS bei den meisten proprietären Systemen (Solaris, HP-UX, RS/6000, usw.) die Grundeinstellung ist und auch als solche in der neuesten Version des exportfs benutzt wird, muss des Linux-Servers Dateisystem mit der «sync»-Option exportiert werden. Dazu ist zu bemerken, dass durch das Spezifizieren des synchronen Exports keinerlei Option in des Servers Exportliste erscheint:

Wurde Ihr Kernel mit dem /proc-Dateisystem kompiliert, enthält die Datei /proc/fs/nfs/exports eine vollständige Liste der Export-Optionen. Bei synchronem Verhalten wird der Server eine Anforderung des NFS-Version 2-Protokoll nicht durchführen, bis das lokale Dateisystem alle Daten / Metadaten geschrieben hat. Der Server wird eine synchrone NFS-Version 3 -Anforderung unverzögert ausführen. Er wird in einer Status-Rückmeldung dem Client mitteilen, welche Daten in den Zwischenspeichern bleiben sollen und welche Daten sicher weggeworfen werden können. Es sind drei Statuswerte möglich - als Aufzählungstyp - (nfs3_stable_how) in include/linux/nfs.h. Diese Werte, mit den daraus folgenden Schritten, sehen folgendermassen aus:

Zusätzlich zu der vorgehend aufgeführten Erklärungen des synchronen Verhaltens, könnte der Client - unabhängig vom Protokoll - auf vollständig synchronem Verhalten bestehen, indem er alle Dateien über die 0_SYNC-Option öffnet. In diesem Fall werden alle Replies auf die Client-Anforderungen warten, bis alle Daten auf dem Server gespeichert sind - unabhängig vom aktiven Protokoll. Das bedeutet, dass alle Requests in NFS-Version 3 werden über NFS_FILE_SYNC durchgeführt, d.h. der Server antwortet auf der gleichen Basis. In diesem Fall wird die Performance von NFS-Version 2 und NFS-Version 3 fast identisch sein. Wird jedoch die ursprüngliche Grundeinstellung async benutzt, hat die 0_SYNC - Option in beiden NFS-Versionen keinen Effekt, der Server reagiert auf den Client bevor die Schreibfunktion beendet ist. Hierbei wird der Performanceunterschied zwischen den beiden Versionen ebenfalls verschwinden. Zum Schluss sei bemerkt, dass bei Anforderungen über das NFS-Version 3-Protokoll eine Bestätigungsauforderung des NFS-Client beim Schliessen einer Datei oder bei der Ausführung von fsync() den synchronen Server zwingen wird, vorgehend ungeschriebene Daten und Metadaten zu speichern. Der Server wird dem Client nicht antworten, bis dieser Vorgang - bei sync-Einstellung - beendet ist. Wird async benutzt, ist das Verhalten im Wesentlichen festgelegt, da der Server dem Client vortäuscht, dass die Daten sicher geschrieben wurden. Dieses Verhalten kann Client und Server der Datenkorruption aussetzen, da zwischengespeicherte Daten auf dem Client weggeworfen werden in der Annahme, dass der Server die Daten sicher gespeichert hat.

5.10 Andere, nicht direkt auf NFS bezogene Methoden zur Verbesserung der Serverleistung

Die Performance des Servers und die Zugriffsgeschwindigkeit auf dessen Festplatte haben im allgemeinen einen wichtigen Einfluss auf die NFS-Leistung. Allgemeine Richtlinien zur Installation eines optimalen Daten-Servers sind ausserhalb des Rahmens dieses Dokuments, wir möchten jedoch einige Hinweise nicht versäumen:

6. Sicherheit und NFS

Die folgenden Sicherheitstipps und deren Erklärungen werden Ihre Netzinstallation nicht vollständig sicher machen. Es gibt keine absolute Sicherheit für Ihre Installation. Wir möchten Ihnen jedoch einige Hinweise zu den Sicherheitsproblemen des NFS geben. Diese ist keine umfassende Anleitung, sie ist immer ergänzungsbedürftig und ist ständigen Änderungen unterworfen. Haben Sie einige Ratschläge oder Hinweise, bitte senden Sie diese dem HOWTO-Maintainer.

Ist Ihr Rechner Teil eines Netzwerks, das keinen Zugang zur Aussenwelt hat (nicht mal ein Modem) und Sie vertrauen allen vernetzten Rechnern und deren Benutzern, ist dieser Abschnitt für Sie eigentlich überflüssig. Wir glauben jedoch, dass verhältnismässig wenige Netzwerke diesen Bedingungen entsprechen. Jeder, der ein NFS installieren will, sollte sich mit diesem Abschnitt vertraut machen. Im NFS benötigt man zwei Schritte, um Zugriff auf eine Datei in einem entfernten Verzeichnis des Servers zu erhalten.

Der Mount-Zugang ist der erste Schritt: Der Client-Rechner versucht, sich mit dem Server zu verbinden. Die Sicherheit dafür wird durch die Datei /etc/exports hergestellt. Diese Datei enthält die Namen und die IP-Adressen der Rechner, die Zugang zu einem share point haben. Decken sich des Clients IP-Adresse und und ein entsprechender Eintrag in der Zugangsliste, wird Mount-Zugang erteilt. Das ist nicht sehr sicher: Ist jemand in der Lage, sich durchzumogeln oder hat sich eine vertraute Adresse zugänglich gemacht, wird der Zugang zum mount point erteilt. Um einen Vergleich aus dem echten Leben für diese Art der «Authentifizierung» zu geben: ein Unbekannter stellt sich Ihnen vor und Sie vertrauen ihm, weil die Person ein Schild mit «Mein Name ist...» trägt. Sobald die Maschine das Volume gemountet hat, besteht für das Betriebssystem Zugang zu allen Dateien dieses Volumes (mit der Ausnahme von denen die root gehören, siehe unten), einschliesslich Schreiberlaubnis, wenn das Volume mit der rw-Option exportiert wurde.

Der zweite Schritt ist der Dateizugang. Das ist eine Funktion der normalen Dateisystem-Zugriffskontrolle des Client und keine spezielle Funktion des NFS. Sobald ein Laufwerk gemountet ist, übernehmen User- und Gruppenerlaubnis die Zugangskontrolle.

Ein Beispiel: Bob mapt auf dem Server zur UserID 9999. Er erzeugt eine Datei auf dem Server für die nur dieser User Zugang hat (das entspricht der Anwendung von chmod 0600). Ein Client erhält die Erlaubnis, die Festplatte mit dieser Datei zu mounten. Auf diesem Client mapt sich Mary zur UserID 9999. Das heisst, Client-Benutzer Mary bekommt Zugang zu Bob's Datei, die als nur für ihn zugänglich gekennzeichnet ist. Es wird noch schlimmer: ist jemand Super-User auf dem Client geworden, kann er mit su-username die Identität jedes Users annehmen. Das NFS spricht darauf nicht an.

Es ist jedoch nicht hoffnungslos. Auf dem Server können mehrere Massnahmen getroffen werden, um die Gefährdung über die Clients zu vermindern. Wir werden diese in Kürze behandeln. Die Auffassung, dass Sicherheitsmassnahmen nicht besonders wichtig sind, könnte trügen. Im

Abschnitt 6.1 kommen wir auf die Sicherheit des Portmappers, Abschnitt 6.2 betrifft die Sicherheit des Servers und Abschnitt 6.3 behandelt die Sicherheit des Client. Im Abschnitt 6.4 kommen wir kurz auf die richtige Anwendung von Firewalls auf Ihrem NFS-Server. Abschliessend möchten wir darauf hinweisen, wie wichtig es ist, dass die NFS-Dämonen und die Client-Programme auf dem neuesten Stand sind. Wenn Sie annehmen, dass ein Fehlerbericht zu neu ist, um ein Problem für Sie darzustellen, ist Ihr System wahrscheinlich schon davon betroffen.

Eine gute Methode, um auf dem neuesten Stand der Sicherheitswarnungen zu bleiben, ist ein Abonnement der bugtraq-Mailingliste, siehe:

(http://www.securityfocus.com/forums/bugtraq/faq.html)

Auch mit der Suchmaschine im www.securityfocus.com finden Sie alle Sicherheitsberichte bezüglich NFS. Prüfen Sie auch regelmässig die CERT-Warnungen, die auf der CERT Webseite http://www.cert.org zu finden sind.

6.1 Portmapper

Portmapper führt eine Liste der Services, welche jedem Port zugeordnet sind. Die Liste wird von dem verbindungssuchenden Rechner benutzt, um herauszufinden, auf welchem Port bestimmte Services zu finden sind. Portmapper ist in den letzte Jahren verbessert worden, er bereitet jedoch den Systemadministratoren immer noch einige Sorgen. Portmapper sollten, ebenso wie das NFS und das NIS, nicht in der Lage sein, Verbindungen ausserhalb des vertrauten, lokalen Netzwerkes herzustellen. Werden sie der Aussenwelt ausgesetzt, ist äusserste Sorgfalt und gute Überwachung des Systems notwendig. Die Linux-Distributionen sind nicht alle gleich. Einige der neuen Distributionen haben keinen Portmapper, der sich absichern lässt. Es gibt eine einfache Methode den Portmapper zu prüfen, die Anwendung von strings(l) sollte die einschlägigen Dateien /etc/hosts.deny und hosts/allow/ lesen. Angenommen Ihr Portmapper ist /sbin/portmap können Sie diesen mit folgendem Kommando prüfen:

Auf einem Rechner mit sicherbarem Portmapper erscheint etwa folgendes:

/etc/hosts.allow
/etc/hosts.deny
@(#) hosts_ctl.c. 1.4 94/12/28/ 17:42:27
@(#) hosts_access.c 1.21 97/02/12/ 02:13:22

Zuerst ändern wir /etc/hosts.deny. Es sollte die Zeile enthalten:

diese verweigert Zugang für alle. Nachdem das geschlossen wurde, geben Sie ein:

um herauszufinden, ob Portmapper diese Datei liest und ausführt. Rpcinfo sollte nichts ausgeben oder eventuell eine Fehlermeldung erzeugen. Die Dateien /etc/hosts.allow und /etc/hosts.deny werden aktiv unmittelbar nachdem Sie diese gespeichert haben. Kein Dämon muss neu gestartet werden.

Portmapper-Zugang für alle zu verweigern, wäre etwas drastisch. Wir öffnen ihn, indem wir /etc/hosts.allow ändern. Zuerst müssen wir uns entscheiden, was wir eingeben wollen. Die Datei sollte alle Rechner enthalten, die Zugang zu Ihrem Portmapper benötigen.

In einem einfachen Linux-System benötigen einige Rechner Zugang zu einer begrenzten Anzahl von Dateien. Der Portmapper verwaltet nfsd, mountd, ypbind/ypserv, rquotad, lockd (welches als nlockmgr zu finden ist), statd (zu finden als status und 'r'-Services wie ruptime und rusers. Von diesen sind jedoch nur nfsd, mountd, ypbind/ypserv und eventuell rquotad, lockd, und statd relevant.

Alle Rechner, die Zugriff auf Ihren Rechner benötigen, sollten diese Programme ausführen können.

Nehmen wir an, die Adresse Ihres Rechners ist 192.168.0.254, er ist in dem Subnetz 192.168.0.0 beheimatet und alle Rechner im Subnetz haben Zugriffsrecht auf ihn (Erklärungen zur Terminology sind in der Networking Overview HOWTO zu finden).

Dann schreiben wir:

portmap: 192.168.0.0/255.255.255.0

im /etc/hosts.allow. Falls Sie nicht sicher sind, was Ihre Netzwerk- oder Netmask-Bezeichnung ist, finden Sie durch Eingabe von ifconfig die Netmask und mittels netstat das Netzwerk finden. Für das Gerät eth0 sollte ifconfig auf diesem Rechner folgendermassen aussehen:

Und netstat -rn sollte folgendermassen aussehen:

(Die Netzwerk-Adresse am Anfang der Eingabe)

Die Dateien /etc/hosts.deny und /etc-hosts.allow sind in den Manual Pages unter den gleichen Namen beschrieben.

NFS-utils-Pakete Version 0.2.0 und höher benutzen ebenfalls die Dateien hosts.allow und hosts.deny, d.h. Sie sollten auch dort die entsprechenden Einträge für lockd, statd, mountd und rqotad vornehmen. Siehe Abschnitt 3.2.2 Die oben beschriebenen Schritte sollten den Server besser sichern. Das einzige verbleibende Problem besteht, wenn es jemandem möglich ist, administrativen Zugang auf eine Ihrer vertrauten Client-Maschinen zu erhalten und falsche NFS-Anforderungen auszuführen. Der nächste Abschnitt beschäftigt sich mit diesem Problem.

6.2 Server-Sicherheit: nfsd und mount

Für den Server können wir uns entscheiden, dem root-Zugriff des Client nicht zu trauen, indem wir durch die root_squash-Option in /etc/exports:

den Zugang verweigern. Das ist übrigens die Standardeinstellung, sie sollte unbedingt immer aktiv sein - ausser Sie haben einen ganz besonderen Grund, diese abzuschalten, das wird mit der no_root_squash-Option durchgeführt.

Versucht ein Client-Benutzer mit UID 0 (die Benutzer-ID-Nummer) Lese-/Schreib- und Lösch-Zugriff auf das Dateisystem zu bekommen, ersetzt der Server die UID mit des Server's «nobody»- Account. Das bedeutet, dem root-Benutzer am Client wird der Zugriff auf Dateien im root verweigert, auf die nur vom Server aus der root-Zugriff möglich ist.

Soweit alles gut - Sie sollten eigentlich root_squash für alle zu exportierenden Datei- Systeme benutzen. «Aber der root-Benutzer am Client kann immer noch su benutzen und als gewöhnlicher Benutzer Zugriff zu den Benutzerdateien erhalten und diese ändern», bemerken Sie. Die Antwort dazu ist: richtig, genau das erwarten wir von einem Unixsystem und dem NFS. Eine wichtige Folge davon: alle Binärdateien sollten direkt im root-Verzeichnis sein, nicht im bin oder in einem anderen Nicht-root-Zugriff. Der einzige Zugriff, den der Client-root-Benutzer nicht erhält, ist auf den Server-root.

In den exports(5)-Manual Pages sind weitere squash-Optionen beschrieben, Sie können entscheiden, welchen Client-Benutzern Sie vertrauen und welchen nicht. Die TCP-Ports 1-1024 sind für den root-Gebrauch reserviert (sie werden deshalb manchmal als «sichere Ports» bezeichnet). Ein Nicht-root-Benutzer kann nicht bind für diese Ports anwenden. Das Hinzufügen der secure-Option in /etc/exports ermöglicht nur die Benutzung der Ports 1 - 1024, infolgedessen kann ein unberechtigter Nicht-root-Benutzer keinen gefälschten NFS-Dialog eröffnen und Zugang zu einem unreservierten Port erhalten. Diese Option ist die Standardeinstellung.

6.3 Client-Sicherheit

Bei der Konfiguration des Client-Rechners können wir gegenüber dem Server durch mounten einiger Optionen etwas Vorsicht einbauen. Wir können zum Beispiel suid-Programme unterbinden, die durch das NFS-Dateisystem mit der nonsuid-Option arbeiten. Einig Unix-Programme, wie z.B. passwd, werden «suid»-Programme genannt: Sie setzen den Benutzer mit Besitzer einer Datei gleich. Ist root der Besitzer einer Datei die suid ist, wird das Programm in root ausgeführt, d.h. es kann Operationen durchführen, die nur root erlaubt sind, wie z.B. Änderungen der Passwort-Datei. Der Gebrauch der nosuid-Option ist daher eine gute Idee, die Sie für alle NFS-gemounteten Platten erwägen sollten. Das bedeutet, der root-Benutzer des Servers kann kein suid-root- Programm ins Dateiystem stellen und dann mit diesem auch root auf dem Client werden. Man kann auch mit der noexec-Option generell verbieten, Programme auf gemounteten NFS-Dateisystemen auszuführen. Das kann sich aber als unpraktischer als nosuid erweisen, da ein Dateisystem mindestens einige Skripts und ausführbare Programme enthält.

Einige ältere Programme (z.B. xterm) beruhten auf der Idee, dass root Schreibzugriff auf Server und Client haben sollte. Diese Eigenschaft wird jedoch von neueren Kerneln beim NFS-Mounten nicht ausgeführt. Das hat Folgen für die Sicherheit: Programme, welche diese Art suid-Aktivität ausführen eventuell können benutzt werden, um Ihre UID auf NFS-Servern, die UID-mappen ausführen, zu ändern. In der Standardeinstellung des Linux-Kernel wurde daher broken_suid abgestellt.

Zusammengefasst: benutzen Sie eine ältere Linux-Distribution, ein altes suid-Programm oder eine veraltete Unix-Version, kann es notwenig sein, dass Sie mit broken_suid mounten müssen. Die neueren Distributionen von Linux und Unix enthalten xterm und ähnliche Programme nur als ausführbare Dateien ohne suid-Funktionen, setuid wird mit anderen Programmen durchgeführt. Die oben genannten Optionen werden in den Optionsspalten von rsize und wsize durch ein Komma getrennt eingetragen.

In der gegenwärtigen Ausführung von NFS (2.2.18+) ist File-Locking voll unterstützt, d.h. rpc.statd und rpc.lockd müssen auf dem Client installiert sein, um die lock-Funktionen ausführen zu können. Portmapper muss ebenfalls in Betrieb sein. Die meisten Probleme, die mit dem NFS auf dem Server auftreten, sind auch auf dem Client zu finden. Lesen Sie im Portmapper-Abschnitt, wie dieser gesichert werden kann

6.4 NFS und Firewalls (ipchains und netfilter)

IPchains ( in 2.2.X Kerneln) und netfilter (in 2.4.X Kerneln) gewährleisten ein gutes Sicherheitsniveau - anstatt sich auf den Dämon zu verlassen (in diesem Fall TCP wrapper) erfolgt die Zugriffkontrolle auf einer niedrigeren Ebene. Dadurch kann die Verbindung viel früher und umfassender verhindert werden, das schützt vor vielen Angriffen .

Wie man eine Linux-Firewall installiert, wird hier nicht beschrieben. Wer mehr darüber wissen will, lese die Firewall-HOWTO .

(http://www.Linuxdoc.org/HOWTO/Firewall-HOWTO.html)

oder die IPCHAINS-HOWTO

(http://linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html).

Für Benutzer des Kernel 2.4 und darüber lohnt sich ein Besuch auf der Netfilter-Website:

http://netfilter.filewatcher.org .

Sind Sie schon mit ipchains und netfilter vertraut, erhalten Sie in diesem Abschnitt einige Tipps, wie Sie Ihre Firewall optimaler im NFS einsetzen können.

Eine gute Richtlinie für die Firewall-Konfiguration: viel verweigern und nur wenig zulassen - das schützt dagegen, dass man unbewusst mehr erlaubt, als man eigentlich wollte.

Um zu verstehen, wie man am besten die NFS-Dämonen mit einer Firewall schützt, werden wir kurz darauf eingehen, wie diese zu den Ports binden.

Wenn ein Dämon startet, verlangt er vom Portmapper einen freien Port. Der Portmapper weist den Port zu und verfolgt, welcher Dämon gegenwärtig welchen Port benutzt. Wenn andere Hosts oder Prozessoren mit dem Dämon kommunizieren müssen, fordern sie vom Portmapper die Portnummer an, um den Dämon zu finden. Die Ports ändern sich ständig, da die verschiedene Ports unterschiedlich frei sind und daher von Portmapper jeweils wieder neu zugewiesen werden. Das behindert das Einrichten der Firewall. Wissen wir nicht, wo die Dämonen zu finden sind, ist es nicht möglich zu entscheiden, zu welchen Ports wir Zugang erlauben sollen. Das mag für ein geschütztes, isoliertes LAN kein Problem darstellen. Für öffentliche Netze ist das jedoch fürchterlich.

Mit dem Kernel 2.4.13 (oder neuer) und den nfs-utils 0.3.3. (oder neuer) brauchen wir uns wegen der fliessenden Ports im Portmapper keine Sorgen mehr machen. Jetzt können alle Dämonen, die sich auf das NFS beziehen an ein Port gebunden werden. Die meisten sprechen positiv auf eine -p-Option an, wenn sie starten. Diese Dämonen, welche durch den Kernel gestartet werden, reagieren auf Kernel-Argumente oder Modul-Optionen. Diese werden nachfolgend beschrieben.

Einige der beteiligten Dämonen, die Daten durch das NFS gemeinsam nutzen, sind bereits zu einem Port verbunden. portmap ist stets an Port 111 TCP und UDP. nfsd ist am Port 2049 TCP und UDP ( NFS über TCP mit dem Kernel 2.4.17 ist experimental und ist nicht für Maschinen im Allgemeingebrauch gedacht).

Die anderen Dämonen (statd, mountd, lockd und rquotad) wandern, je nach Anforderung des Portmapper, zum ersten freien Port.

Um statd an einem bestimmten Port zu binden, benutzen wir die -p portnum- Option. Um statd zu zwingen, auf eine bestimmten Port anzusprechen bentzen wir die -o portnum-Option beim Start.

Um montd an einen bestimmten Port zu zwingen, benutzen wir die -p portnum- Option.

Ein Beispiel: um statd auf Port 32765 zu broadcasten und auf Port 32766 zu empfangen, geben wir folgendes ein:

#statd -p 32765 -o 32766
# mountd -p 32767

lockd wird durch den Kernel gestartet, wenn es gebraucht wird. Aus diesem Grund müssen die Modul-Optionen ( falls es als Modul eingerichtet ist) oder die Kernel-Optionen aktiviert werden, um lockd zum Empfang und zum Ansprechen auf bestimmte Ports zu zwingen.

Benutzen Sie ladbare Moduls und Sie möchten diese Optionen mit der /etc/modules.conf -Datei ausführen, ergänzen Sie diese Datei mit der folgenden Zeile:

Diese Zeile bestimmt, dass 32768 der udp - und der tcp - Port im lockd sein sollen.

Falls Sie keine ladbaren Moduls benutzen oder Sie haben lockd in den Kernel kompiliert, anstatt einen Modul zu bauen, müssen Sie die Optionen durch einen Eintrag in des Kernels Bootbefehl ausführen.

Das sieht etwa so aus:

Die Portnummern müssen nicht gleich sein, ungleiche Bezeichnungen führen eventuell zu unnötiger Verwirrung.

Benutzen Sie Quotas - und machen Sie diese mittels rpc.quotad im NFS sichtbar - müssen Sie das beim Installieren Ihrer Firewall berücksichtigen. Es bestehen zwei rpc.quotad - Quelldatenbäume. Einer befindet sich im nfs-utils-Baum, der andere im quota-tools-Baum. Ihre Funktionen sind nicht identisch. Jener im nfs-utils-Baum bindet den Dämon mit der -p-Anweisung an einen Port, der im quota-tools-Baum jedoch nicht. Informieren Sie sich jedoch in der Dokumentation Ihrer Distribution, ob das zutrifft.

Um diese Erläuterungen zu vervollständigen, beschreiben wir ein Netzwerk und die Installation einer Firewall, um unseren NFS-Server zu schützen. Unser NFS-Server ist 192.168.0.42, unser Client ist 192.168.0.45. Wie im Beispiel oben, statd ist gestartet worden, es bindet Port 32765 für eintreffende Anforderungen und antwortet auf Port 32766. moutd wurde bestimmt, auf Port 32767 zu binden. Die Modul-Parameter von lockd wurden bestimmt auf Port 32768 zu binden. nfsd ist am Port 2049 und portmap am Port 111

Wir benutzen keine Quotas.

Mittels IPCHAINS sieht eine einfache Firewall etwa so aus:

ipchains -A input -f -j ACCEPT -s 192.168.0.45
ipchains -A input -s 192.168.0.45 -d 0/0 32765:32768 -p 6 -j ACCEPT
ipchains -A input -s 192.168.0.45 -d 0/0 32765:32768 -p 17 -j ACCEPT
ipchains -A input -s 192.168.0.45 -d 0/0 2049 -p 17 -j ACCEPT
ipchains -A input -s 192.168.0.45 -d 0/0 2049 -p 6 -j ACCEPT
ipchains -A input -s 192.168.0.45 -d 0/0 111 -p 6 -j ACCEPT
ipchains -A input -s 192.168.0.45 -d 0/0 111 -p 17 -j ACCEPT
ipchains -A input -s 0/0 -d 0/0 -p 6 -j DENY -y -1
ipchains -A input -s 0/0 -d 0/0 -p 17 -j DENY -1

Die Reihe von äquivalenten Befehlen für netfilter ist:

iptables -A input -f -j ACCEPT -s 192.168.0.45
iptables -A input -s 192.168.0.45 -d 0/0 32765:32768 -p 6 -j ACCEPT
iptables -A input -s 192.168.0.45 -d 0/0 32765:32768 -p 17 -j ACCEPT
iptables -A input -s 192.168.0.45 -d 0/0 2049 -p 17 -j ACCEPT
iptables-A input -s 192.168.0.45 -d 0/0 2049 -p 6 -j ACCEPT
iptables -A input -s 192.168.0.45 -d 0/0 111 -p 6 -j ACCEPT
iptables-A input -s 192.168.0.45 -d 0/0 111 -p 17 -j ACCEPT
iptables -A input -s 0/0 -d 0/0 -p 6 -j DENY--syn--log-level 5
iptables -A input -s 0/0 -d 0/0 -p 17 -j DENY --log-level 5

Die erste Zeile gibt Anweisung, alle Paket-Fragmente zu akzeptieren (das erste Fragmentpaket wird jedoch als normales Paket behandelt). Theoretisch muss jedes Paket wieder zusammengesetzt werden, bevor es verarbeitet wird. Das Zusammensetzen erfolgt nur, nachdem das erste Fragmentpaket verarbeitet ist. Natürlich kann ein Rechner durch überladen mit Fragmentpaketen angegriffen werden. Werden keine Fragmente durchgelassen, wird das NFS funktionsunfähig. Näheres siehe Abschnitt 7.8

Mit den anderen Zeilen gestatten wir spezifische Verbindungen von jedem Port unseres Client zu bestimmten Ports auf unserem Server. Das bedeutet, wenn 192.158.0.46 zum Beispiel versucht mit dem NFS-Server zu verbinden , wird es nicht möglich sein zu mounten oder herauszufinden, welche mounts zugänglich sind.

Mit diesen neuen Fähigkeiten, Ports zu bestimmen, ist es viel leichter zu kontrollieren, welche Hosts auf die NFS-Shares zugreifen dürfen. Hierbei möchten wir erwähnen, dass NFS kein verschlüsseltes Protokoll ist und jeder der direkt im gleichen Netz ist, könnte den Verkehr ausschnüffeln und die wechselseitigen Informationen wieder zusammenbauen.

6.5 NFS-Tunneln durch ssh

Eine Methode zur Verschlüsselung des NFS-Verkehrs über ein Netzwerk ist die Port-Weiterleitung mittels ssh. Wir werden jedoch sehen, dass hierdurch echte Nachteile entstehen, wenn Sie den lokalen Usern auf Ihrem Server nicht vollständig vertrauen.

Der erste Schritt beeinhaltet den Export von Dateien zum Localhost. Um z.B. die /home-Partition zu exportieren geben wir folgendes ein:

Der nächste Schritt ist der Gebrauch von ssh um Ports weiterzuleiten. ssh kann z.B. den Server anordnen, an den Client von jedem Port auf jeder Maschine weiterzuleiten. Nehmen wir wie im vorangegangenen Beispiel an, unser Server ist 192.168.0.42 und wir haben mountd mit dem Argument -p 32767 auf Port 32767 bestimmt. Dann geben wir auf dem Client ein:

Das Kommando der ersten Zeile auf dem Client verursacht, dass ssh jede Anforderung auf des Client's Port 250 durch ssh auf dem Server an dessen Port 2049 weiterleitet. Die zweite Zeile bedeutet, dass eine gleiche Art Weiterleitung vom Port 251 des Client zum Port 32767 des Servers angefordert wurde. Da localhost Teil des Servers ist, findet die Weiterleitung auf dem Server selbst statt. Dem Port hätte bestimmt werden können, zu jedem Port auf jeder Maschine weiterzuleiten und die Anforderungen würden aussehen, als kämen sie vom Server selbst. Daraus schliessen wir also, dass die Anfragen dem NFSD des Servers so erscheinen, als kämen sie von Server selbst. Hier ist jedoch zu bemerken, um ein Port unterhalb 1024 an den Client zu binden, muss der Befehl von root auf dem Client eingegeben werden. Das ist auf jeden Fall notwendig, wenn wir unser Dateisystem mit der secure-Option exportiert haben.

Zum Schluss benutzen wir einen kleinen Trick mit der letzten Option -f sleep 60m. Normalerweise, wenn wir ssh benutzen, auch mit der -L-Option, öffnen wir eine Shell auf der entfernten Maschine. Wir wollen jedoch, dass die Port-Weiterleitung im Hintergrund durchgeführt wird und wir unsere Shell-Funktion vom Client zurück erhalten. Wir weisen also ssh mit einen Befehl im Hintergrund an, für 60 Minuten zu schlafen. Damit wird der Port für 60 Minuten weitergeleitet bis er eine Verbindung erhält, von hier an bleibt die Weiterleitung bestehen, bis die Verbindung beendet wird oder bis die 60 Minuten vorüber sind, je nachdem was später geschieht. Der oben aufgeführte Befehl könnte mit unserem Startup-Skript auf dem Client direkt nach dem Netzwerkstart ausgeführt werden.

Als nächstes müssen wir das Dateisystem auf dem Client mounten. Dafür weisen wir den Client an, das Dateisystem auf dem localhost zu mounten jedoch über einen anderen Port als den üblichen 2049. Der Eintrag im /etc/fstab würde folgendermassen aussehen:

Hierbei können wir erkennen, wie unglaublich unsicher diese Prozedur ist, indem wir uns nur einen gewöhnlichen User vorstellen, der auf dem Server lokal einloggen kann. Ist das möglich, kann nichts ihn daran hindern, unsere Prozedur nachzuvollziehen und mittels ssh Ihren privilegierten Port der Client-Maschine (wo er legal root ist) zu den Ports 2049 und 32767 des Servers weiterzuleiten. Das bedeutet, jeder gewöhnliche User am Server kann unser Dateisystem mit den gleichen Rechten mounten wie root auf unserem Client.

Betreiben Sie einen NFS-Server auf den sich normale User nicht einloggen können und Sie möchten diese Methode benutzen, bestehen zwei weitere Hindernisse: Erstens, die Verbindung geschieht vom Client zum Server durch ssh, deshalb ist es notwendig Port 22 (wo ssh wartet) für den Client in der Firewall offen zu halten. Jedoch müssen die anderen Ports, wie 2949 und 32767, nicht mehr offen bleiben. Zweitens, file locking funktioniert nicht mehr. Es ist nicht möglich statd oder den locking-Manager zu Anfragen auf einen bestimmten Port für einen bestimmten mount aufzufordern, d.h. jede locking-Anfrage verursacht, dass statd zum statd auf dem Localhost verbindet, d.h. zu sich selber - das endet mit einer Fehleranzeige. Jeder Versuch, das zu ändern, würde zu einem grösseren Umprogrammieren des NFS führen.

Es ist eventuell auch möglich, IPSec zur Verschlüsselung des Netzwerkverkehrs zwischen Ihrem Client und Server einzusetzen, ohne die lokale Sicherheit Ihres Servers zu gefährden, wir wollen jedoch hier nicht näher darauf eingehen. Bitte lesen Sie auf der FreeS/WAN-Homepage mehr über den Gebrauch von IPSec unter Linux.

6.6 Zusammenfassung

Sie können ziemlich sicher sein, dass viele der bisher bekannt gewordenen Fehler des NFS vermieden werden, wenn hosts.allow, hosts.deny, root_squash, nosuid und priviligierte Port-Einstellungen des Portmapper/NFS-Programms benutzt werden.

Netzwerk-Eindringlinge können unerwünschte Kommandos in Ihrem .forward erzeugen oder Ihre E-Mail lesen, wenn /home oder /var/mail durch NFS exportiert werden. Aus dem gleichen Grund sollten Sie niemals Zugang zu Ihren PGP-Schlüssel über das NFS herstellen, mindestens ist Ihnen jetzt etwas über das Risiko bekannt.

Das NFS und Portmapper sind komplexe Subsysteme. Es ist daher möglich, dass noch weitere unentdeckte Fehler im Grundprogramm enthalten sind, die zu unerwünschten Eingriffen ausgenutzt werden könnten.

7. Fehlersuche

Geht bei der Anwendung des NFS etwas schief, könnten Ihnen die folgenden Schritte weiterhelfen. Probleme tauchen meistens zuerst am Client-Rechner auf, wir beginnen also dort mit unser Diagnose.

7.1 Dateien sind nicht im gemounteten Dateisystem zu finden

Erstens, prüfen Sie, ob das Dateisystem wirklich gemountet ist. Es gibt verschiedene Möglichkeiten, um das herauszufinden. Am zuverlässigsten ist ein Blick in die Datei /proc/mounts, die alle gemounteten Dateisysteme nebst Details aufführt. Führt das zu keinem Resultat (wenn Sie z.B. nicht das /proc-Dateisystem in Ihren Kernel kompiliert haben), sollte die Eingabe von mount-f einen etwas weniger detailierten Bericht produzieren.

Scheint das Dateiensystem gemountet zu sein, dann haben Sie vielleicht durch mounten eines anderen Dateisystems dieses dem ersten übergelagert (unmounten und re-mounten Sie beide) oder Sie haben das Dateisystem des Servers exportiert, bevor Sie es dort gemountet haben - NFS exportiert hierbei den zugrunde liegenden mountpoint (Sie müssen in diesem Fall das NFS auf dem Server neu starten).

Ist das Dateisystem nicht gemountet, versuchen Sie es einzuhängen. Bringt das kein Resultat, siehe Symptom 3, unten.

7.2 Dateiaufruf hängt oder Timeout wartet auf den Zugriff zur Datei

Das bedeutet normalerweise, dass der Client nicht mit dem Server Kommunizieren kann. Siehe unten, Abschnitt 7.3. Symptom 3.

7.3 Dateisystem kann nicht gemountet werden

Kann mount ein Volume nicht installieren, sind zwei allgemeine Fehlermeldungen möglich:

b. RPC: Program Not Registered ( oder eine andere «RPC»-Fehlermeldung). Das bedeutet, der Client entdeckt das NFS nicht auf dem Server. Verschiedene Gründe können dafür zuständig sein.

Bei der Fehlermeldung «No Remote Programs Registered», müssen Sie in den Dateien /etc/hosts.allow und /etc/hosts.deny auf Ihrem Server prüfen, ob dem Client Zugriffsrecht erteilt worden ist. Scheinen die Einträge korrekt zu sein, stellen Sie fest, ob im /etc/hosts (oder Ihrem DNS-Server) der Rechner korrekt aufgeführt ist und ob Sie den Server vom Client pingen können. Werfen Sie auch einen Blick ins Fehlerprotokoll des Systems für hilfreiche Hinweise: Authentifizierungsfehler, verursacht von fehlerhaften Einträgen im /etc/hosts.allow erscheinen gewöhnlich in /var/log/messages - sie können aber auch an anderer Stelle auftauchen, je nachdem wie Ihr Systemprotokoll installiert wurde. Die Manual Pages für syslog enthalten Hinweise, wie Ihr syslog-Protokoll konfiguriert ist.

Zu guter Letzt, einige ältere Betriebssysteme verhalten sich nicht kooperativ, wenn die Routen zwischen den beiden Rechnern asymmetrisch sind. Versuchen Sie tracepath [server] auf dem Client einzugeben und stellen Sie fest, ob «asymmetric» irgendwo in der Ausgabe erscheint. Trifft das zu, dann könnte das die Ursache für Paketverlust sein.

Asymmetrische Routen sind jedoch meistens kein Problem bei neueren Linux- Distributionen.

Erscheint die Fehleranzeige «Remote System Error - No Route to Host» und Sie können den Server wie erwartet pingen, sind Sie das Opfer einer übereifrigen Firewall. Prüfen sie alle Firewalls am Server, am Client und auf allen Routern zwischendrin.

Die Manual Pages für ipchains, netfilter und ipfwadm könnten dabei behilflich sein, ebenso die IPCHAINS-HOWTO (

http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html )

und die Firewall-HOWTO

( http://www.Linuxdoc.org/HOWTO/Firewall-HOWTO.html ).

7.4 Sie erhalten keine Zugriffserlaubnis zu den Dateien auf dem gemountetem Volume.

Das könnte von jedem der folgenden zwei Probleme verursacht sein:

Wird keine Schreiberlaubnis erteilt, prüfen Sie in den Export-Optionen des Servers /proc/fs/nfs/exports, ob das Dateisystem nur mit Leseerlaubnis exportiert wurde. Um das zu ändern, muss der Export mit Lese- und Schreibzugang erneut durchführt werden (nicht vergessen exportfs-ra nach dem Ändern von /etc/exports auszuführen). Prüfen Sie auch /proc/mounts, ob das Volume Lese- und Schreiberlaubnis hat (wurde es nur mit Lesezugriff gemountet, hätten Sie eine mehr spezifische Fehlermeldung erhalten). Hat es keinen Schreibzugriff, müssen Sie mit der rw-Option remounten.

Die Gründe für das zweite Problem liegen im Mappen der Benutzernamen. Die Folgen sind unterschiedlich, je nachdem, ob Sie sich als root- Benutzer oder als Nicht-root-Benutzer anmelden: als Nicht-root sind vermutlich die Benutzernamen auf dem Client und dem Server nicht synchronisiert. Geben Sie id[user] auf dem Client und dem Server ein und stellen Sie fest, ob beide die gleiche UID-Nummer haben. Sind diese unterschiedlich, macht das Programm, das zum Synchronisieren der Benutzernamen benutzt wird (NIS,NIS+, rsync,usw.) Schwierigkeiten. Die Gruppennamen müssen auch übereinstimmen. Sie dürfen auch nicht mit der all_squash-Option exportieren. Stimmen die Benutzernamen überein, hat der Benutzer ein allgemeineres Zugriffproblem, das nichts mit dem NFS zu tun hat. Sind Sie root-Benutzer, exportieren Sie wahrscheinlich nicht mit der no_root_squash-Option, prüfen Sie /proc/fs/nfs/exports oder /var/lib/nfs/xtab auf dem Server, ob diese Option aufgeführt ist. Nur aus sehr zwingenden Gründen sollte es Schreibzugang als root auf dem Server geben - in der Standardeinstellung wird das vom NFS verweigert. Siehe Abschnitt 6.

Ist root squashing aktiviert (lassen Sie es dabei) und Sie wollen root die gleichen Zugriffsrechte zu den Dateien gewähren, die der Benutzer nobody haben sollte, denken sie daran, dass der Server bestimmt, zu welchen UID root gemappt wird. In der Standardeinstellung benutzt der Server die UID und GID von nobody in der /etc/passwd-Datei - das kann jedoch mit den anouid-und anongid-Optionen in der /etc/exports-Datei ausser Kraft gesetzt werden. Prüfen Sie, ob Client und Server darin übereinstimmen, was zu welchem UID der User gemappt wird.

7.5 Beim Transfer von grossen Dateien benötigt NFS alle CPU-Zyklen des Servers und bringt diesen zum Stillstand.

Das ist ein Problem mit der fsync()-Funktion im Kernel 2.2. Es verursacht, dass alle sync-to-disk Anforderungen summiert werden, als Ergebnis wächst die Schreibzeit im Quadrat zur Dateigrösse. Upgraden mit dem Kernel 2.4 sollte das Problem beseitigen. Exportieren mit der no_wdelay-Option zwingt das Programm o_sync() zu benutzen, das schneller sein sollte.

7.6 Seltsame Fehler- und Protokoll-Meldungen

7.7 Die durchführbaren Zugriffsrechte decken sich nicht mit den Einträgen in /etc/exports.

/etc/exports ist äusserst empfindlich auf Leerstellen, die folgenden Einträge sind nicht gleich:

/export/dir hostname(rw,no_root_squash)
/export/dir hostname (rw,no_root_squash)

Der erste Eintrag gibt Hostname-rw-Zugriff auf /export/dir ohne root sqash-Rechte. Der zweite Eintrag erlaubt Hostname-rw-Zugriff, einschliesslich root squash - ausserdem JEDER-Lese/Schreib-Zugang ohne root squash -Rechte. Nett, nicht wahr?

7.8 Unerklärliches und unzuverlässiges Verhalten

Eingaben von einfachen Befehlen wie Is werden ausgeführt. Alle anderen, die man zum grossen Datentransfer benötigt, verursachen, dass mountpoint sperrt. Einer von zwei Gründen kann dafür zuständig sein:

7.9 nfsd startet nicht

Prüfen Sie in der /etc/exports-Datei, ob root Lesezugriff hat und ob die Binärdateien ausgeführt werden können. Der Kernel muss für NFS-Serverunterstützung kompiliert worden sein. Hilft das alles nichts, führen Sie eine Neuinstallation der Binärdateien durch.

7.10 Dateikorruption beim Einsatz von mehreren Clients

Ändert man eine Datei innerhalb einer Sekunde nach einer vorgehenden Änderung und die Dateigrösse ändert sich nicht, wird sie die gleiche inode-Nummer weiterführen. Daher können andauernde Lese-und Schreibvorgänge durch mehrere Clients zu Datenverfälschung führen. Diesen Fehler zu beseitigen, erfordert Änderungen tief in den Schichten des Dateisystems, daher ist es eine Angelegenheit die in 2.5 behandelt wird.

8. Benutzung von Linux NFS mit anderen Betriebssystemen

Jedes Betriebssystem, einschliesslich Linux, hat seine Eigenheiten und Unterschiede in der NFS-Implementation - manchmal sind die Kommunikationsprotokolle ungenau oder es existieren riesige Sicherheitsmängel. So weit bekannt, arbeitet Linux mit allen NFS-Ausführungen der bekanntesten Hersteller. Es können jedoch besondere Massnahmen notwendig sein, um sicherzustellen, dass zwei Betriebssysteme wie erwartet miteinander kommunizieren. Der folgende Abschnitt liefert nähere Informationen für diese Schritte.

Im allgemeinen ist man sehr schlecht mit dem Versuch beraten, eine Linux-Maschine mit einem Kernel 2.2.18 oder älter als NFS-Server für Nicht-Linux-Clients zu benutzen. Die Implementation bei älteren Kerneln auf Clients kann gut funktionieren, bleiben Sie jedoch hängen, würde ein Upgrade des Kernels unser erster Ratschlag sein, um herauszufinden, ob das Problem damit beseitigt ist. Die Implementation des NFS-User-Bereichs auf Nicht-Linux-Clients ist auch mangelhaft.

Es folgt eine Liste bekannter Probleme, die beim Gebrauch von Linux mit den anderen Betriebssystemen auftreten.

8.1 AIX

Das Format für die /etc/exports-Datei unseres Beispiels in Abschnitt 3. ist:

/usr slave1.foo.com:slave2.foo.com,access=slave1.foo.com:slave2.foo.com
/home slave1.foo.com:slave2.foo.com,rw=slave1.foo.com:slave2.foo.com

AIX benutzt die /etc/filesystems-Datei anstelle von /etc/fstab. Das Eintragbeispiel - wie im Abschnitt 4.

/mnt/home:
dev = "/home
vfs = nfs
nodename = master.foo.com
mount = true
options = bg,hard,intr,rsize=1024,wsize=1024,vers=2,proto=udp

account = false

8.2 BSD

BSD-Kernel scheinen besser mit grösseren Blöcken zu arbeiten.

Einige BSD-Versionen könnten Anfragen von unsicheren Ports an den Server schicken, in diesem Fall müssen Sie die Volumes mit der insecure-Option exportieren. Siehe Manual Pages von export(5) für weitere Einzelheiten.

8.3 Compaq Tru64 Unix

Im allgemeinen arbeiten Tru64 Unix-Server sehr gut mit Linux-Clients zusammen. Das Format für die /etc/exports-Datei aus unserem Beispiel in Abschnitt 3. sollte folgendermassen aussehen:

/usr slave1.foo.com:slave2.foo.com \
-access= slave1.foo.com:slave2.foo.com \
/home slave1.foo.com:slave2.foo.com \
-rw= slave1.foo.com:slave2.foo.com \
-root= slave1.foo.com:slave2.foo.com

Tru64 prüft die /etc/exports-Datei bei jeder mount-Anforderung. Es ist daher nicht notwendig das exportfs-Kommando auszuführen - in vielen Versionen von Tru64 Unix existiert es nicht.

Auf zwei Dinge müssen wir hier aufpassen: Erstens, Tru64 Unix mountet mittels NFS-Version 3 als Standardeinstellung. Unterstützt der Linux-Server NFS-Version 3 nicht, erscheinen Fehlermeldungen. Zweitens, in Tru64 Unix werden NFS-Locking-Anforderungen durch den Dämon ausgeführt. Aus diesem Grund muss die insecure_locks-Option für alle auf einen Tru64 Unix 4.x zu exportierendes Volumes ausgeführt werden. Die exports-Manual Pages enthalten mehr Details.

8.4 HP - UX

Ein Beispiel für einen /etc/exports-Eintrag auf einer HP-UX-Maschine sieht so aus:

/usr -ro,access=slave1.foo.com:slave2.foo.com
/home -rw=slave1.foo.com:slave2.foo.com:root=slave1.foo.com:slave2.foo.com

( Die root-Option im letzten Eintrag ist nur zur allgemeinen Information, es wird empfohlen, diese nicht zu benutzen - ausser es besteht keine andere Möglichkeit.)

HP-UX-Clients ohne Laufwerk benötigen mindestens die Kernel Version 2.2.19 (oder 2.2.18 mit Patch) um Dateien vom Gerät korrekt exportieren zu können. Alle Exporte auf einen HP-UX-Client müssen mit der insecure_locks- Option durchgeführt werden.

8.5 IRIX

Hier ein Beispiel für einen /etc/exports-Dateieintrag in IRIX:

/usr -ro,access=slave1.foo.com:slave2.foo.com
/home -
rw=slave1.foo.com:slave2.fo.com:root=slave1.foo.com:slave2.foo.com

( Die root-Option im letzten Eintrag ist nur zur allgemeinen Information gedacht. Es wird empfohlen, diese nicht zu benutzen, ausser es ist notwendig.)

Es wurde von Problemen berichtet, die beim Gebrauch der nohide-Option bei Exporten auf Systeme mit Linux 2.2 auftreten. Im Kernel 2.4 wurde das beseitigt. Eine Aushilfe ist der Export und das Mounten von separaten Unterverzeichnissen.

Mit dem Kernel 2.4.17 gibt es immer noch einige Mängel mit der übergreifenden Funktionstüchtigkeit, die einen Kernel-Upgrade erfordern. Im Speziellen:

IRIX-Versionen bis 6.5.12 haben Schwierigkeiten Datei-Systeme zu mounten, die von Linux-Maschinen exportiert wurden - der mount-point "geht verloren", z.B.:

# mount linux:/disk1 /mnt
# cd /mnt/xyz/abc
#pwd
/xyz/abc

Das ist ein bekannter IRIX-Fehler (SGI bug 815265 - IRIX not liking file handles of less than 32 bytes), dieser wurde in IRIX6.5.13 behoben. Ist es nicht möglich auf IRIX 6.5.13 umzusteigen, ist die inoffizielle Notlösung Linux-nfsd zu zwingen immer 32 byte Datei-Handle zu benutzen.

Es gibt eine Anzahl von Patches, siehe: http://geocrawler.com/archives/3/789/2001/8/50/6371896/ http://oss.sgi.com/projects/xfs/mail_archive/0110/msg00006.html

8.6 Solaris

Das Format von Solaris auf der Serverseite ist etwas unterschiedlich von anderen Betriebssystemen. Anstelle von /etc/exports ist /etc/dfs/dfstab die Konfigurationsdatei . Eingaben erfolgen in der Form von «share»-Kommandos, unser Beispiel gemäss Abschnitt 3. wird so aussehen:

Anstelle von exportfs muss shareall ausgeführt werden. Solaris-Server sind besonders empfindlich auf die Paketgrösse - ändern Sie rsize und wsize auf 31768 beim Mounten. Abschliessend noch eine Besonderheit mit root squashing auf Solaris: root wird auf den Benutzernamen noone gemappt, das ist nicht das gleiche wie der Benutzer nobodynobody. Haben Sie Schwierigkeiten mit der Dateizugriffserlaubnis als root auf der Client-Maschine, prüfen Sie, ob das Mappen funktioniert.

Solaris wird regelmässig die folgende Meldung machen:

Das geschieht, weil Solaris-Clients beim Mounten versuchen ACL-Informationen zu finden - welche Linux natürlich nicht hat. Die Meldung kann ohne Bedenken übersehen werden. Es gibt zwei bekannte Probleme mit Solaris-Clients ohne Laufwerk: erstens, mindestens Kernel 2.2.19 wird benötigt, um mit /dev/null korrekt exportieren zu können. Zweitens, die Paketgrösse muss auf Sparc-Servern ohne Laufwerk extrem klein eingestellt werden (z.B. 1024), weil die Clients nicht in der Lage sind, Pakete in umgekehrter Reihenfolge zu assemblieren. Die Einstellung kann durch /etc/bootparams auf dem Client erfolgen.

8.7 SunOS

SunOS hat nur NFS-Version 2 über UDP zur Verfügung.

Auf der Serverseite benutzt SunOS das traditionellste Format für seine /etc/exports-Datei. Das Beispiel nach Abschnitt 3 würde folgendermassen aussehen

/usr -access=slave1.foo.com,slave2.foo.com
/home -
rw=slave1.foo.com,slave2.foo.com,root=slave1.foo.com,slave2.foo.com

Die root-Option ist auch hier wieder nur zur Information gedacht, sie sollte nur benutzt werden falls notwendig.

SunOS führt alle NFS-Locking-Anforderungen über Dämonen aus, daher muss die insecur_locks-Option auf allen Volumen, die zu einer SunOS-Maschine exportiert werden, aktiviert sein. Siehe exports-Manual Pages für weitere Angaben.