Funktionsweise des NFS-Service

In den folgenden Abschnitten werden einige der komplexen Funktionen der NFS-Software beschrieben. Beachten Sie, dass einige der in diesem Abschnitt enthaltenen Beschreibungen ausschließlich für die NFS-Version 4 gelten.

• Versionsaushandlung in NFS

• Funktionen in NFS-Version 4

• UDP- und TCP-Aushandlung

• Aushandlung der Dateiübertragungsgröße

• Einhängen von Dateisystemen

• Funktionsweise der Option -public und der NFS-URLs beim Einhängen

• Clientseitiges Failover

• Große Dateien

• Funktionsweise der NFS-Serverprotokollierung

• Funktionsweise des WebNFS-Service

• WebNFS-Beschränkungen bei Verwendung eines Webbrowsers

• Sicheres NFS-System

• Secure RPC

Versionsaushandlung in NFS

Der NFS-Initiierungsprozess schließt die Aushandlung der Protokollebenen für Server und Clients ein. Wenn Sie keinen Versionsstand angeben, wird ein geeigneter Versionstand standardmäßig ausgewählt. Wenn beispielsweise sowohl der Server als auch der Client die Version 3 unterstützen, wird Version 3 verwendet. Wenn der Client oder der Server nur die Version 2 unterstützen, wird Version 2 verwendet.

Ab Solaris 10 können Sie die Schlüsselwörter NFS_CLIENT_VERSMIN, NFS_CLIENT_VERSMAX, NFS_SERVER_VERSMIN und NFS_SERVER_VERSMAX in der /etc/default/nfs-Datei angeben. Die von Ihnen angegebenen minimalen und maximalen Werte für den Server und den Client ersetzen die Standardwerte dieser Schlüsselwörter. Der minimale Standardwert für sowohl den Client als auch den Server ist 2, und der maximale Standardwert ist 4. Lesen Sie dazu Schlüsselwörter für die /etc/default/nfs-Datei. Um festzustellen, welche Version vom Server unterstützt wird, beginnt der NFS-Client mit den Einstellungen für NFS_CLIENT_VERSMAX und fährt dann mit den weiteren Versionen fort, bis er die Versionseinstellung für NFS_CLIENT_VERSMIN erreicht. Sobald die unterstützte Version gefunden ist, wird der Vorgang beendet. Wenn beispielsweise NFS_CLIENT_VERSMAX=4 und NFS_CLIENT_VERSMIN=2 angegebenen sind, prüft der Client zunächst Version 4, dann Version 3 und zuletzt Version 2. Wenn NFS_CLIENT_VERSMIN und NFS_CLIENT_VERSMAX auf den gleichen Wert gesetzt sind, verwendet der Client stets die betreffende Version und versucht nicht, eine andere Version zu verwenden. Wenn der Server nicht über diese Version verfügt, schlägt die Einhängung fehl.

Informationen zur Verfahrensweise finden Sie unter Einrichten von NFS-Services.

Funktionen in NFS-Version 4

An NFS-Version 4 wurden viele Änderungen vorgenommen. In diesem Abschnitt werden diese neuen Funktionen beschrieben.

• Aufheben der gemeinsamen Nutzung und erneutes Freigeben zur gemeinsamen Nutzung eines Dateisystems in NFS-Version 4

• Dateisystem-Namespace in NFS-Version 4

• Temporäre Dateizugriffsroutinen in NFS-Version 4

• Clientwiederherstellung in NFS-Version 4

• OPEN-Unterstützung zur gemeinsamen Nutzung in NFS-Version 4

• Delegierung in NFS-Version 4

• Zugriffskontrolllisten (ACLs) und nfsmapid in NFS-Version 4

• Clientseitiges Failover in NFS-Version 4

Verfahrensbezogene Informationen zur Verwendung der NFS-Version 4 finden Sie unter Einrichten von NFS-Services.

Aufheben der gemeinsamen Nutzung und erneutes Freigeben zur gemeinsamen Nutzung eines Dateisystems in NFS-Version 4

Wenn ein Client versucht, auf eine Dateisystem zuzugreifen, für den die gemeinsame Nutzung aufgehoben wurde, antwortet der Server sowohl bei Verwendung von NFS-Version 3 als auch NFS-Version 4 mit einem Fehlercode. In NFS-Version 3 werden von Clients veranlasste Sperre jedoch vom Server beibehalten, bevor die gemeinsame Nutzung des Dateisystems aufgehoben wird. Dadurch ist es nach der erneuten Freigabe zur gemeinsamen Nutzung des Dateisystems möglich, dass Clients der NFS-Version 3 auf das Dateisystem zugreifen, obwohl die gemeinsame Nutzung des Dateisystems nicht aufgehoben wurde.

Wenn mit NFS-Version 4 die gemeinsame Nutzung eines Dateisystems aufgehoben wird, werden sämtliche Zustände von geöffneten Dateien oder Dateisperrungen im betreffenden Dateisystem außer Kraft gesetzt. Wenn der Client versucht, auf diese Dateien oder Sperren zuzugreifen, erhält er eine Fehlermeldung. Dieser Fehler wird der Anwendung normalerweise als E/A-Fehler gemeldet. Beachten Sie jedoch, dass durch die erneute Freigabe eines gemeinsam genutzten Dateisystems zum Zweck der Änderung von Optionen keine Zustände auf dem Server außer Kraft gesetzt werden.

Relevante Informationen finden Sie unter Clientwiederherstellung in NFS-Version 4 oder auf der Manpage unshare_nfs(1M).

Dateisystem-Namespace in NFS-Version 4

Die Server der NFS-Version 4 erstellen und verwalten ein Pseudodateisystem, das Clients den mühelosen Zugriff auf alle exportierten Objekte auf einem Server ermöglicht. In den Vorgängerversionen war das Pseudodateisystem nicht vorhanden. Die Clients waren gezwungen, jedes gemeinsamgenutzte Serverdateisystem einzuhängen, um den Zugriff zu ermöglichen. Betrachten Sie das folgende Beispiel.

Abbildung 6-2 Ansichten des Serverdateisystems und des Clientdateisystems

Beachten Sie, dass die Verzeichnisse payroll und nfs4x für den Client nicht sichtbar sind, da sie nicht exportiert wurden und nicht zu exportierten Verzeichnisse führen. Das Verzeichnis local ist jedoch für den Client sichtbar, da es sich um ein exportiertes Verzeichnis handelt. Das Verzeichnis projects ist für den Client sichtbar, da projects zum exportierten Verzeichnis nfs4 führt. Dadurch werden nicht explizit exportierte Teile des Server-Namespace mit einem Pseudodateisystem überbrückt, das nur exportierte Verzeichnisse und Verzeichnisse anzeigt, die zu Serverexporten führen.

Ein Pseudodateisystem ist eine Struktur, die nur Verzeichnisse enthält und vom Server erstellt wird. Das Pseudodateisystem erlaubt einem Client, die Hierarchie von exportierten Dateisystemen zu durchsuchen. Dadurch wird die Sicht des Clients auf das Pseudodateisystem durch die Pfade beschränkt, die zu den exportierten Dateisystemen führen.

Frühere Versionen von NFS ließen es nicht zu, dass Clients Serverdateisysteme durchqueren, ohne jedes Dateisystem einzuhängen. In NFS-Version 4 bewirkt der Server-Namespace jedoch Folgendes:

• Beschränkung der Dateisystemansicht des Clients auf Verzeichnisse, die zu Serverexporten führen

• Müheloser Zugriff auf Serverexporte für Clients, ohne dass die Clients die jeweils zugrunde liegenden Dateisysteme einhängen müssen Siehe vorangegangenes Beispiel. Beachten Sie jedoch, dass es aufgrund unterschiedlicher Betriebssysteme erforderlich sein kann, dass jedes Serverdateisystem vom Client eingehängt werden muss.

Aus POSIX-bezogenen Gründen überschreitet der Client der NFS-Version 4 von Solaris keine Grenzen des Serverdateisystems. Wenn dies vom Client versucht wird, wird ein leeres Verzeichnis angezeigt. Um dieses Problem zu beheben, müssen Sie jedes der Dateisysteme des Servers einhängen.

Temporäre Dateizugriffsroutinen in NFS-Version 4

Dateizugriffsroutinen werden auf dem Server erstellt und enthalten Informationen, mit deren Hilfe Dateien und Verzeichnisse eindeutig bestimmt werden können. In den NFS-Versionen 2 und 3 wurden vom Server dauerhafte Dateizugriffsroutinen zurückgegeben. Dadurch konnte der Client gewährleisten, dass der Server eine Dateizugriffsroutine generiert, die immer auf dieselbe Datei verweist. Beispiel:

• Wurde eine Datei gelöscht und durch eine Datei mit dem gleichen Namen ersetzt, generierte der Server eine neue Dateizugriffsroutine für die neue Datei. Wenn der Client eine alte Dateizugriffsroutine verwendete, gab der Server eine Fehlermeldung zurück, die darauf hinwies, dass die Dateizugriffsroutine veraltet war.

• Wenn eine Datei umbenannt wurde, blieb die Dateizugriffsroutine unverändert.

• Wenn Sie den Server neu starten mussten, sind die Dateizugriffsroutinen unverändert geblieben.

Wenn der Server eine auf eine Dateizugriffsroutine bezogene Anforderung von einem Client erhielt, konnte die Anforderung problemlos aufgelöst werden, wodurch die Dateizugriffsroutine immer auf die richtige Datei verwies.

Diese Methode zur Bestimmung von Dateien und Verzeichnissen für NFS-Vorgänge war für die meisten UNIX-basierten Server völlig ausreichend. Jedoch konnte die Methode nicht auf Servern implementiert werden, die andere Mittel zur Bestimmung verwendeten, beispielsweise den Pfadnamen einer Datei. Um dieses Problem zu lösen, gestattet das Protokoll der NFS-Version 4 einem Server, zu deklarieren, dass seine Dateizugriffsroutinen temporär sind. Dadurch kann eine andere Dateizugriffsroutine verwendet werden. Ist dies der Fall, muss der Client nach der neuen Dateizugriffsroutine suchen.

Wie in den NFS-Versionen 2 und 3 von Solaris stellt auch der Server der NFS-Version 4 stets dauerhafte Dateizugriffsroutinen bereit. Jedoch müssen Clients der NFS-Version 4 von Solaris, die auf Server zugreifen, die keine Server der NFS-Version 4 von Solaris sind, temporäre Dateizugriffsroutinen unterstützen, wenn diese vom Server verwendet werden. Vor allem muss der Client die Zuordnung zwischen Pfadname und Dateizugriffsroutine zwischenspeichern, wenn ihm vom Server mitgeteilt wird, dass die Dateizugriffsroutine temporär ist. Der Client verwendet die temporäre Dateizugriffsroutine, bis ihre Nutzungsdauer abgelaufen ist. Sobald dies geschehen ist, führt der Client folgende Vorgänge aus:

• Entfernen der zwischengespeicherten Informationen, die sich auf die Dateizugriffsroutine beziehen

• Suchen nach der neuen Dateizugriffsroutine für die betreffende Datei

• Versuchen, den Vorgang zu wiederholen

Die Nutzungsdauer von temporären Dateizugriffsroutinen kann aus folgenden Gründen ablaufen:

• Eine Datei wird geschlossen.

• Das Dateisystem der Dateizugriffsroutine wird migriert.

• Ein Client benennt eine Datei um.

• Server wird neu gestartet.

Beachten Sie Folgendes: Wenn der Client die neue Dateizugriffsroutine nicht finden kann, wird eine Fehlermeldung in die syslog-Datei geschrieben. Weitere Versuche des Zugriffs auf diese Datei schlagen fehl, und es wird ein E/A-Fehler ausgegeben.

Clientwiederherstellung in NFS-Version 4

Das Protokoll der NFS-Version 4 ist ein statusbehaftetes Protokoll. Ein Protokoll ist statusbehaftet, wenn der Client und der Server aktuelle Informationen über Folgendes verwahren:

• Offene Dateien

• Dateisperren

Bei einem Ausfall wie beispielsweise einem Serverabsturz arbeiten der Client und der Server zusammen, um den Status vor dem Ausfall (offen und gesperrt) wiederherzustellen.

Wenn ein Server abstürzt und neu gestartet wird, geht der Status des Servers verloren. Der Client erkennt, dass der Server neu gestartet wurde und beginnt, den Server dabei zu unterstützen, seinen Status wiederherzustellen. Dieser Prozess wird als Clientwiederherstellung bezeichnet, da er vom Client gesteuert wird.

Wenn der Client feststellt, dass der Server neu gestartet wurde, stellt der Client sofort seine laufenden Aktivitäten ein und beginnt mit dem Prozess der Clientwiederherstellung. Wenn die Wiederherstellung beginnt, wird eine Meldung wie die folgende in das Systemfehlerprotokoll /var/adm/messages eingetragen:

NOTICE: Starting recovery server basil.example.company.com

Während der Wiederherstellung sendet der Client die Informationen, die Aufschluss über den vorherigen Status des Clients geben, an den Server. Beachten Sie jedoch, dass der Client in diesem Zeitraum keine neuen Anforderungen an den Server sendet. Neue Anforderungen für das Öffnen oder Sperren von Dateien können erst dann gesendet werden, wenn der Server die Wiederherstellung abgeschlossen hat.

Wenn die Clientwiederherstellung abgeschlossen ist, wird eine Meldung wie die folgende in das Systemfehlerprotokoll /var/adm/messages eingetragen:

NOTICE: Recovery done for server basil.example.company.com

Jetzt ist der Vorgang erfolgreich abgeschlossen (der Client hat seine Statusinformationen an den Server gesendet). Obwohl der Client diesen Vorgang abgeschlossen hat, kann es sein, dass dies bei anderen Clients noch nicht der Fall ist. Aus diesem Grund akzeptiert der Server über einen bestimmten Zeitraum keine Anforderungen für das Öffnen oder Sperren von Dateien. Diese Zeitspanne, die als Wartezeit bezeichnet wird, gestattet allen Clients, ihre Wiederherstellung abzuschließen.

Wenn der Client während dieser Wartezeit versucht, neue Dateien zu öffnen oder neue Sperren festzulegen, wird die betreffende Anforderung verweigert und der Fehlercode GRACE ausgegeben. Nach Empfang dieses Fehlers muss der Client warten, bis die Wartezeit abgelaufen ist. Sobald dies geschehen ist, kann der Client die Anforderung erneut an den Server senden. Während der Wartezeit wird die folgende Meldung angezeigt:

NFS server recovering

Während der Wartezeit kann die Ausführung von Befehlen fortgesetzt werden, die nicht das Öffnen oder Sperren von Dateien veranlassen. Dies sind beispielsweise die Befehle ls und cd. Die Ausführung dieser Befehle wird nicht ausgesetzt. Jedoch wird die Ausführung eines Befehls wie beispielsweise cat, der das Öffnen einer Datei veranlasst, bis zum Ende der Wartezeit ausgesetzt.

Sobald die Wartezeit abgelaufen ist, wird die folgende Meldung angezeigt:

NFS server recovery ok.

Der Client kann nun neue Anforderungen für das Öffnen und Sperren von Dateien an den Server senden.

Die Clientwiederherstellung kann aus verschiedenen Gründen fehlschlagen. Wenn beispielsweise nach dem Neustart des Servers eine Netzwerkpartition vorhanden ist, kann der Client seinen Status eventuell nicht mithilfe des Servers wiederherstellen, bevor die Wartezeit abgelaufen ist. Nach Ablauf der Wartezeit gestattet der Server dem Client nicht, seinen Status wiederherzustellen, da aus neuen statusbehafteten Vorgängen Konflikte resultieren können. Eine neue Dateisperre kann beispielsweise mit einer alten Dateisperre in Konflikt geraten, wenn der Client versucht, die alte Dateisperre wiederherzustellen. In einem solchen Fall gibt der Server den Fehlercode NO_GRACE an den Client zurück.

Wenn die Wiederherstellung eines Öffnungsvorgangs für eine bestimmte Datei fehlschlägt, kennzeichnet der Client die Dateien als nicht verwendbar, wodurch die folgende Meldung angezeigt wird.

WARNING: The following NFS file could not be recovered and was marked dead 
(can't reopen:  NFS status 70):  file :  filename

Der Wert 70 dient nur als Beispiel.

Wenn die Wiederherstellung einer Dateisperre fehlschlägt, wird die folgende Fehlermeldung ausgegeben:

NOTICE: nfs4_send_siglost:  pid PROCESS-ID lost
lock on server SERVER-NAME

In solch einem Fall wird das auf den betreffenden Prozess bezogene Signal SIGLOST ausgegeben. Nach der Ausgabe des Signals SIGLOST wird der Prozess standardmäßig beendet.

Um diesen Status zu beseitigen, müssen Sie alle Anwendung neu starten, bei denen zum Zeitpunkt des Ausfalls Dateien geöffnet waren. Dann kann Folgendes auftreten:

• Manche Prozesse, die die betreffende Datei nicht erneut geöffnet haben, empfangen E/A-Fehler.

• Andere Prozesse, die die Datei erneut geöffnet haben oder nach der fehlgeschlagenen Wiederherstellung den Öffnungsvorgang ausgeführt haben, können ohne Probleme auf die Datei zugreifen.

Manche Prozesse können also auf eine bestimmte Datei zugreifen, andere aber nicht.

OPEN-Unterstützung zur gemeinsamen Nutzung in NFS-Version 4

Das Protokoll der NFS-Version 4 bietet mehrere Modi zum gemeinsamen Dateizugriff, die der Client verwenden kann, um den Dateizugriff anderer Clients zu steuern. Ein Client kann Folgendes definieren:

• DENY_NONE-Modus – andere Clients erhalten Lese- und Schreibzugriff auf eine Datei.

• DENY_READ-Modus – anderen Clients wird der Lesezugriff auf eine Datei verweigert.

• DENY_WRITE-Modus – anderen Clients wird der Schreibzugriff auf eine Datei verweigert.

• DENY_BOTH-Modus – anderen Clients wird der Lese- und Schreibzugriff auf eine Datei verweigert.

Diese Modi für den gemeinsamen Dateizugriff werden vom Server der NFS-Version 4 von Solaris vollständig implementiert. Wenn ein Client versucht, eine Datei auf eine Art und Weise zu öffnen, die mit dem aktuellen Modus zum gemeinsamen Dateizugriff in Konflikt steht, verweigert der Server diesen Vorgang, wodurch der Vorgang fehlschlägt. Wenn ein solcher Versuch bei der Einleitung von Öffnungs- oder Erstellungsvorgängen fehlschlägt, empfängt der Client der NFS-Version 4 einen Protokollfehler. Dieser Fehler wird dem Anwendungsfehler EACCES zugeordnet.

Obwohl das Protokoll mehrere Modi zum gemeinsamen Dateizugriff bietet, ist dies derzeit beim Öffnungsvorgang in Solaris nicht der Fall. Wenn eine Datei geöffnet wird, kann ein Client der NFS-Version 4 von Solaris nur den DENY_NONE-Modus verwenden.

Obwohl der Systemaufruf fcntl einen F_SHARE-Befehl verwendet, um den gemeinsamen Dateizugriff zu steuern, können die fcntl-Befehle mit NFS-Version 4 nicht richtig implementiert werden. Wenn Sie diese fcntl-Befehle auf einem Client der NFS-Version 4 anwenden, gibt der Client den Fehler EAGAIN an die Anwendung zurück.

Delegierung in NFS-Version 4

NFS-Version 4 bietet sowohl Client- als auch Serverunterstützung für die Delegierung. Delegierung ist ein Verfahren, bei dem ein Server die Verwaltung einer Datei an einen Client delegiert. Ein Server kann beispielsweise einem Client eine Lese- oder Schreibdelegierung gewähren. Lesedelegierungen können mehreren Clients gleichzeitig gewährt werden, da diese Delegierungen nicht miteinander in Konflikt stehen. Eine Schreibdelegierung kann nur einem Client gewährt werden, da eine solche Delegierung mit Zugriffsvorgängen, die von anderen Clients ausgeführt werden, in Konflikt geraten können. Wenn der Client eine Schreibdelegierung besitzt, sendet er keine Vorgänge an den Server, wenn ihm der exklusiver Zugriff auf eine Datei garantiert wird. Der Client sendet auch dann keine Vorgänge an den Server, wenn er eine Schreibdelegierung besitzt. Der Grund dafür ist der, dass der Server gewährleistet, dass kein Client die Datei im Schreibmodus öffnen kann. Die Delegierung hat den Zweck, die Vorgänge zwischen dem Server und dem Client bedeutend zu verringern. Dies hat auch zur Folge, dass der Netzwerkverkehr verringert wird und die Leistung von Clients und Servern verbessert wird. Beachten Sie jedoch, dass der Grad der Leistungssteigerung davon abhängt, welche Dateien von einer Anwendung verwendet und wie stark das Netzwerk und der Server belastet werden.

Die Entscheidung, ob eine Delegierung gewährt wird, wird allein vom Server getroffen. Von einem Client wird keine Delegierung angefordert. Die vom Server getroffenen Entscheidungen bezüglich einer Delegierung begründen sich auf den Dateizugriffsmustern. Wenn kurze Zeit zuvor von verschiedenen Clients im Schreibmodus auf eine Datei zugegriffen wurde, gewährt der Server eventuell keine Delegierung. Der Grund ist der, dass dieses Zugriffsmuster auf potenzielle zukünftige Konflikte hindeutet.

Ein Konflikt entsteht, wenn ein Client auf eine Art und Weise auf eine Datei zugreift, die mit der Delegierung in Widerspruch steht, die vor kurzem für den Zugriff auf diese Datei gewährt wurde. Wenn ein Client beispielsweise im Besitz einer Schreibdelegierung für eine Datei ist und die Datei von einem zweiten Client geöffnet wird, um Lese- oder Schreibzugriff zu erhalten, widerruft der Server die Schreibdelegierung des ersten Clients. Ein ähnlicher Vorgang findet statt, wenn ein Client im Besitz einer Lesedelegierung ist und ein anderer Client dieselbe Datei öffnet, um Schreibzugriff zu erhalten: Der Server widerruft die Lesedelegierung. In beiden Fällen wird dem zweiten Client keine Delegierung gewährt, weil ein Konflikt entstanden ist. Sobald ein Konflikt ensteht, verwendet der Server einen Callback-Mechanismus, um den Client zu kontaktieren, der im Besitz der Delegierung ist. Nachdem der Client diesen Callback empfangen hat, sendet er die aktualisierten Daten der Datei an den Server und gibt die Delegierung zurück. Wenn der Client nicht auf den erneuten Aufruf antwortet, widerruft der Server die Delegierung. In solchen Fällen lehnt der Server alle Vorgänge ab, die vom Client für diese Datei angefordert werden, und der Client meldet, dass die angeforderten Vorgänge fehlgeschlagen sind. Fehlgeschlagenen Vorgänge dieser Art werden der Anwendung als E/A-Fehler gemeldet. Um diese Fehler zu beheben, muss die Datei geschlossen und dann wieder geöffnet werden. Fehler, die aus widerrufenen Delegierungen resultieren, können auftreten, wenn eine Netzwerkpartition zwischen dem Client und dem Server vorhanden ist, während der Client im Besitz einer Delegierung ist.

Beachten Sie, dass ein Server keine Zugriffskonflikte löst, die aus einer Datei resultieren, die auf einem anderen Server gespeichert ist. Aus diesem Grund löst ein NFS-Server nur Konflikte, die aus Dateien resultieren, die von ihm selbst gespeichert werden. Außerdem kann ein Server, der auf Konflikte auftwortet, die von Clients verursacht werden, auf denen verschiedene NFS-Versionen ausgeführt werden, nur an den Client erneute Aufrufe senden, auf dem die NFS-Version 4 ausgeführt wird. Ein NFS-Server kann keine erneuten Aufrufe für Clients einleiten, auf denen frühere Versionen von NFS ausgeführt werden.

Die Erkennung von Konflikten gestaltet sich unterschiedlich. Anders als in NFS-Version 4 wird ein Konflikt erst dann erkannt, wenn der Client versucht, eine Datei zu lesen, zu beschreiben oder zu sperren, da bei den Versionen 2 und 3 kein offenes Verfahren verwendet wird. Die Antwort des Servers auf diese Konflikte fällt ebenfalls unterschiedlich aus. Beispiel:

• In NFS-Version 3 gibt der Server den Fehler JUKEBOX zurück, wodurch der Client veranlasst wird, die Zugriffsanforderung auszusetzen und es zu einem späteren Zeitpunkt erneut zu versuchen. Der Client gibt die Meldung File unavailable (Datei nicht verfügbar) aus.

• Da in NFS-Version 2 keine Entsprechung für den Fehler JUKEBOX vorhanden ist, antwortet der Server nicht, wodurch der Client zunächst wartet und dann erneut versucht, den Vorgang auszuführen. Der Client gibt die Meldung NFS server not responding (NFS-Server antwortet nicht) aus.

Dieser Zustand ist beendet, sobald der Delegierungskonflikt gelöst ist.

Die Serverdelegierung ist standardmäßig aktiviert. Sie können die Delegierung deaktivieren, indem Sie die /etc/default/nfs -Datei modifizieren. Informationen zur Verfahrensweise finden Sie unter So wählen Sie andere NFS-Versionen auf einem Server aus.

Für die Clientdelegierung sind keine Schlüsselwörter erforderlich. Der Callback-Dämon der NFS-Version 4, nfs4cbd, stellt einen Callback-Service auf dem Client bereit. Dieser Dämon wird automatisch gestartet, wenn eine Einhängung für NFS-Version 4 aktiviert wird. Der Client übermittelt standardmäßig die Callback-Informationen an den Server, die für alle Internetübertragungen benötigt werden, die in der /etc/netconfig -Systemdatei aufgelistet sind. Bitte beachten Sie: Wenn der Client für IPv6 aktiviert ist und die IPv6-Adresse für den Namen des Clients nicht bestimmt werden kann, akzeptiert der Callback-Dämon IPv6-Verbindungen.

Der Callback-Dämon verwendet eine vorübergehende Programmnummer und eine dynamisch zugewiesene Portnummer. Diese Informationen werden dem Server zur Verfügung gestellt, und der Server prüft den Callback-Pfad, bevor er Delegierungen zulässt. Wenn die Prüfung des Callback-Pfads nicht erfolgreich war, gewährt der Server keine Delegierungen. Dies ist das einzige nach außen hin erkennbare Verhalten.

Bitte beachten Sie: Da die Callback-Informationen in eine Anforderung der NFS-Version 4 eingebettet sind, kann der Server den Client nicht über ein Gerät kontaktieren, das NAT (Network Address Translation) verwendet. Der Callback-Dämon verwendet zudem eine dynamische Portnummer. Aus diesem Grund ist der Server eventuell nicht in der Lage, eine Firewall zu überwinden, was auch dann der Fall ist, wenn die betreffende Firewall normalen NFS-Verkehr an Port 2049 zulässt. In solchen Fällen gewährt der Server keine Delegierungen.

Zugriffskontrolllisten (ACLs) und nfsmapid in NFS-Version 4

Eine Zugriffskontrollliste (ACL) bietet mehr Sicherheit für Dateien, da dem Eigentümer einer Datei ermöglicht wird, Dateiberechtigungen für den Dateieigentümer, die Gruppe und weitere Benutzer und Gruppen zu definieren. Zugriffskontrolllisten werden auf dem Server und dem Client definiert, indem der Befehl setfacl verwendet wird. Weitere Informationen finden Sie auf der Manpage setfacl(1). In der NFS-Version 4 wird der ID-Mapper nfsmapid verwendet, um Benutzer- oder Gruppen-IDs in Zugriffssteuerungslisteneinträgen auf einem Server den Benutzer- oder Gruppen-IDs in Zugriffssteuerungslisteneinträgen auf einem Client zuzuordnen. Die Zuordnung erfolgt auch in umgekehrter Richtung. Die Benutzer- und Gruppen-IDs in den Einträgen der Zugriffssteuerungsliste müssen sowohl auf dem Client als auch auf dem Server vorhanden sein.

Gründe für eine fehlgeschlagene ID-Zuordnung

Eine ID-Zuordnung kann aus folgenden Gründen fehlschlagen:

• Wenn ein Benutzer, der in einem Zugriffssteuerungslisteneintrag auf einem Server angegeben ist, oder eine Gruppe, die in einem solchen Eintrag angegeben ist, nicht einem gültigen Benutzer oder einer gültigen Gruppe auf einem Client zugeordnet werden kann, wird dem Benutzer bzw. der Gruppe nicht erlaubt, die Zugriffssteuerungsliste auf dem Client zu lesen.

  Wenn Sie beispielsweise den Befehl ls -lv oder den Befehl ls -lV ausgeben, erhalten Sie die Fehlermeldung "Permission denied"(Zugriff verweigert). Diese Fehlermeldung bezieht sich auf die Dateien mit Benutzer- oder Gruppen-ID-Einträgen in der Zugriffssteuerungsliste, die der Server nicht dem Client zuordnen kann. Der ID-Mapper konnte einen Benutzer oder eine Gruppe in der Zugriffssteuerungsliste nicht zuordnen. Wenn der ID-Mapper einen Benutzer oder eine Gruppe zuordnen kann, steht ein Pluszeichen (+) hinter den Berechtigungen in der Dateiliste, die durch ls -l erstellt wird. Beispiel:

  % ls -l
  -rw-r--rw-+   1 luis    staff      11968 Aug 12  2005 foobar

  Der Befehl getfacl kann die Fehlermeldung "Permission denied" (Zugriff verweigert) aus dem gleichen Grund zurückgeben. Weitere Informationen zu diesem Befehl finden Sie auf der Manpage getfacl(1).

• Wenn die Benutzer- oder Gruppen-ID in einem Zugriffssteuerungslisteneintrag, der für den Client definiert ist, keiner gültigen Benutzer- oder Gruppen-ID auf dem Server zugeordnet werden kann, kann die Ausführung des Befehls setfacl oder des Befehls chmod fehlschlagen, wodurch die Fehlermeldung "Permission denied" (Zugriff verweigert) zurückgegeben wird.

• Wenn die NFSMAPID_DOMAIN-Werte des Clients und des Servers nicht übereinstimmen, schlägt die ID-Zuordnung fehl. Weitere Informationen finden Sie unter Schlüsselwörter für die /etc/default/nfs-Datei.

Vermeiden von ID-Zuordnungsproblemen mit Zugriffssteuerungslisten

Um ID-Zuordnungsprobleme zu vermeiden, gehen Sie wie folgt vor:

• Stellen Sie sicher, dass der Wert für NFSMAPID_DOMAIN in der /etc/default/nfs-Datei korrekt angegeben ist.

• Stellen Sie sicher, dass alle Benutzer- und Gruppen-IDs in den Einträgen der Zugriffssteuerungsliste sowohl auf dem Client als auch auf dem Server der NFS-Version 4 vorhanden sind.

Prüfen auf nicht zugeordnete Benutzer- oder Gruppen-IDs

Um festzustellen, ob ein Benutzer oder eine Gruppe nicht auf dem Server oder Client zugeordnet werden kann, verwenden Sie das folgende Skript:

#! /usr/sbin/dtrace -Fs

sdt:::nfs4-acl-nobody
{
     printf("validate_idmapping: (%s) in the ACL could not be mapped!", 
stringof(arg0));
}

Zusätzliche Informationen zu Zugriffssteuerungslisten oder nfsmapid

Siehe Folgendes:

• Schützen von UFS-Dateien mit ACLs (Übersicht der Schritte) in Systemverwaltungshandbuch: Sicherheitsservices

• Kapitel 8, Schützen von Oracle Solaris ZFS-Dateien mit Zugriffssteuerungslisten und Attributen in Oracle Solaris ZFS-Administrationshandbuch

• nfsmapid-Dämon

UDP- und TCP-Aushandlung

Während der Initiierung wird auch das Transportprotokoll ausgehandelt. Standardmäßig wird das erste verbindungsorientierte Transportprotokoll ausgewählt, das sowohl auf dem Client als auch auf dem Server unterstützt wird. Wird die Auswahl nicht erfolgreich durchgeführt, wird das erste verbindungslose Transportprotokoll verwendet. Die auf einem System unterstützten Transportprotokolle werden in /etc/netconfig aufgelistet. Das von dieser Version unterstützte verbindungsorientierte Transportprotokoll ist TCP. UDP ist das verbindungslose Transportprotokoll.

Wenn sowohl die NFS-Protokollversion als auch das Transportprotokoll durch die Aushandlung festgelegt werden, hat die NFS-Protokollversion Vorrang vor dem Transportprotokoll. Das Protokoll der NFS-Version 3, das UDP verwendet, hat Vorrang vor dem Protokoll der NFS-Version 2, das TCP verwendet. Sie können sowohl die NFS-Protokollversion als auch das Transportprotokoll manuell auswählen, indem Sie den Befehl mount verwenden. Weitere Informationen finden Sie auf der Manpage mount_nfs(1M). In den meisten Fällen sollten Sie die Aushandlung zulassen, damit die besten Optionen ausgewählt werden.

Aushandlung der Dateiübertragungsgröße

Mit der Dateiübertragungsgröße wird die Größe der Puffer festgelegt, die verwendet werden, wenn Daten zwischen dem Client und dem Server übertragen werden. Im Allgemeinen sind höherwertige Übertragungsgrößen vorzuziehen. Das Protokoll der NFS-Version 3 hat eine unbegrenzte Übertragungsgröße. Ab Solaris 2.6 bietet die Software jedoch eine standardmäßige Puffergröße von 32 KB. Der Client kann zum Transport der Einhängung eine kleinere Übertragungsgröße anbieten. In den meisten Fällen ist dies jedoch nicht nötig.

Die Übertragungsgröße wird nicht mit Systemen ausgehandelt, die das Protokoll der NFS-Version 2 verwenden. Dementsprechend wird die maximale Übertragungsgröße auf 8 KB gesetzt.

Sie können die Optionen -rsize und -wsize verwenden, um die Übertragungsgröße manuell mithilfe des Befehls mount festzulegen. Eventuell müssen Sie die Übertragungsgröße für manche PC-Clients verringern. Sie können die Übertragungsgröße aber auch erhöhen, wenn die Konfiguration des NFS-Servers die Verwendung höherwertiger Übertragungsgrößen zulässt.

Einhängen von Dateisystemen

Die folgende Beschreibung bezieht sich auf Einhängungen mit NFS-Version 3. Im Einhängeprozess der NFS-Version 4 sind weder der Portmap-Service noch das MOUNT-Protokoll enthalten.

Wenn ein Client ein Dateisystem von einem Server einhängen muss, muss der Client zunächst eine Dateizugriffsroutine vom Server abrufen. Die Dateizugriffsroutine muss zum Dateisystem passen. Dieses Verfahren erfordert die Durchführung mehrerer Transaktionen zwischen dem Client und dem Server. In diesem Beispiel versucht der Client, das auf dem Server befindliche System /home/terry einzuhängen. Nach dieser Transaktion wird eine snoop-Ablaufverfolgung durchgeführt.

client -> server PORTMAP C GETPORT prog=100005 (MOUNT) vers=3 proto=UDP
server -> client PORTMAP R GETPORT port=33492
client -> server MOUNT3 C Null
server -> client MOUNT3 R Null 
client -> server MOUNT3 C Mount /export/home9/terry
server -> client MOUNT3 R Mount OK FH=9000 Auth=unix
client -> server PORTMAP C GETPORT prog=100003 (NFS) vers=3 proto=TCP
server -> client PORTMAP R GETPORT port=2049
client -> server NFS C NULL3
server -> client NFS R NULL3 
client -> server NFS C FSINFO3 FH=9000
server -> client NFS R FSINFO3 OK
client -> server NFS C GETATTR3 FH=9000
server -> client NFS R GETATTR3 OK

Während dieser Ablaufverfolgung fordert der Client zunächst die Einhängeportnummer vom Portmap-Service auf dem NFS-Server an. Nachdem der Client die Einhängeportnummer (33492) empfangen hat, wird diese verwendet, um festzustellen, ob der Service auf dem Server verfügbar ist. Nachdem der Client festgestellt hat, dass an der betreffenden Portnummer ein Service vorhanden ist, kann er eine Einhängungsanforderung versenden. Wenn der Server auf diese Anforderung antwortet, stellt der Server die Dateizugriffsroutine für das Dateisystem (9000) bereit, das eingehängt werden soll. Der Client fordert dann die NFS-Portnummer an. Wenn der Client die Nummer vom Server erhalten hat, prüft er die Verfügbarkeit des NFS-Service (nfsd). Außerdem fordert der Client NFS-Informationen zum Dateisystem an, das die Dateizugriffsroutine verwendet.

Im folgenden Beispiel hängt der Client ein Dateisystem mithilfe der Option public ein.

client -> server NFS C LOOKUP3 FH=0000 /export/home9/terry
server -> client NFS R LOOKUP3 OK FH=9000
client -> server NFS C FSINFO3 FH=9000
server -> client NFS R FSINFO3 OK
client -> server NFS C GETATTR3 FH=9000
server -> client NFS R GETATTR3 OK

Durch Verwendung der standardmäßigen Routine für den Zugriff auf öffentliche Dateien (0000) werden alle Transaktionen übersprungen, die zum Abrufen von Informationen vom Portmap-Service und zur Bestimmung der NFS-Portnummer dienen.

Funktionsweise der Option -public und der NFS-URLs beim Einhängen

Die Verwendung der Option -public kann zum Fehlschlagen einer Einhängung führen. Die Situation kann auch kompliziert werden, wenn eine NFS-URL hinzugefügt wird. In der folgenden Liste wird beschrieben, wie ein Dateisystem eingehängt wird, wenn die folgenden Optionen verwendet werden:

• Public option with NFS URL – erzwingt die Verwendung der Routine für den Zugriff auf öffentliche Dateien. Das Einhängen schlägt fehl, wenn die Routine für den Zugriff auf öffentliche Dateien nicht unterstützt wird.

• Public option with regular path – erzwingt die Verwendung der Routine für den Zugriff auf öffentliche Dateien. Das Einhängen schlägt fehl, wenn die Routine für den Zugriff auf öffentliche Dateien nicht unterstützt wird.

• NFS URL only – die Routine für den Zugriff auf öffentliche Dateien wird verwendet, wenn diese Dateizugriffsroutine auf dem NFS-Server aktiviert ist. Schlägt die Einhängung fehl, wenn die Routine für den Zugriff auf öffentliche Dateien verwendet wird, versuchen Sie, die Einhängung mit dem MOUNT-Protokoll durchzuführen.

• Regular path only – verwenden Sie nicht die Routine für den Zugriff auf öffentliche Dateien. Das MOUNT-Protokoll wird verwendet.

Clientseitiges Failover

Durch Verwendung des clientseitigen Failover hat ein NFS-Client Kenntnis von vielen Servern, die dieselben Daten zur Verfügung stellen. Dadurch kann ein alternativer Server verwendet werden, wenn der aktuelle Server nicht verfügbar ist. Das Dateisystem kann eventuell nicht mehr zur Verfügung stehen, wenn Folgendes geschieht:

• Ein Server, mit dem das Dateisystem verbunden ist, stürzt ab.

• Der Server ist überlastet.

• Ein Netzwerkfehler tritt auf.

Unter diesen Bedingungen ist das Failover für den Benutzer normalerweise transparent. Das Failover kann jederzeit stattfinden, ohne die Prozesse zu unterbrechen, die auf dem Client ausgeführt werden.

Ein Failover erfordert, dass das Dateisystem mit Schreibschutz eingehängt ist. Die Dateisysteme müssen identisch sein, damit das Failover erfolgreich ausgeführt werden kann. Eine Beschreibung, wann ein Dateisystem identisch ist, finden Sie unter Was ist ein repliziertes Dateisystem?. Ein statisches Dateisystem oder ein Dateisystem, das nur selten geändert wird, eignet sich am besten für ein Failover.

Sie können CacheFS und clientseitiges Failover nicht für dieselbe NFS-Einhängung verwenden. Für jedes CacheFS-Dateisystem werden zusätzliche Informationen gespeichert. Da diese Informationen während des Failover nicht aktualisiert werden können, kann nur eine dieser Funktionen verwendet werden, wenn ein Dateisystem eingehängt wird.

Wie viele Replikationen für jedes Dateisystem bereitgestellt werden müssen, hängt von zahlreichen Faktoren ab. Idealerweise sollten Sie mindestens über zwei Server verfügen. Jeder Server sollte mehrere Teilnetze unterstützen. Dies ist effizienter, als jeweils einen Server pro Teilnetz einzusetzen. Das Verfahren erfordert, dass jeder gelistete Server geprüft wird. Aus diesem Grund geht das Einhängen umso langsamer vonstatten, je mehr Server gelistet sind.

Failover-Terminologie

Um diesen Prozess zu verstehen, müssen Sie zwei Begriffe kennen:

• Failover – Die Auswahl eines Servers aus einer Liste von Servern, die ein repliziertes Dateisystem unterstützen. Normalerweise wird der nächste Server in der sortierten Liste verwendet, sofern er antwortet.

• Neuzuordnung – Die Verwendung eines neuen Servers. Durch die normale Verwendung wird der Pfadname für jede aktive Datei des Remote-Dateisystems von den Clients gespeichert. Während der Neuzuordnung werden diese Pfadnamen evaluiert, um die Dateien auf dem neuen Server zu platzieren.

Was ist ein repliziertes Dateisystem?

Für die Zwecke des Failover wird ein Dateisystem als Replikation bezeichnet, wenn jede Datei gleich groß ist und die gleiche Größe und den gleichen Typ aufweist, wie das ursprüngliche Dateisystem. Berechtigungen, Erstellungdaten und andere Dateiattribute werden nicht berücksichtigt. Wenn die Dateigröße oder die Dateitypen unterschiedlich sind, schlägt die Neuzuweisung fehl, und der Prozess bleibt hängen, bis der alte Server wieder zur Verfügung steht. In NFS-Version 4 ist das Verhalten unterschiedlich. Lesen Sie dazu Clientseitiges Failover in NFS-Version 4.

Sie können ein repliziertes Dateisystem verwalten, indem Sie rdist, cpio oder einen anderen Dateiübertragungsmechanismus verwenden. Da durch die Aktualisierung der replizierten Dateisysteme Inkonsistenzen verursacht werden, sollten folgende Sicherheitsmaßnahmen getroffen werden, um optimale Ergebnisse zu erzielen:

• Umbenennen der alten Dateiversion vor dem Installieren einer neuen Version

• Ausführen der Aktualisierungen in der Nacht, wenn die Clientauslastung niedrig ist

• Durchführung möglichst kleiner Aktualisierungen

• Minimierung der Anzahl von Kopien

Failover und NFS-Sperrung

Manche Softwarepakete erfordern eine Sperrung des Lesezugriffs auf Dateien. Um eine Beschädigung dieser Produkte zu vermeiden, werden Sperrungen des Lesezugriffs auf schreibgeschützte Dateisysteme zugelassen. Sie sind allerdings nur auf der Clientseite sichtbar. Die Sperren bleiben bei einer Neuzuordnung bestehen, da dem Server diese Sperren nicht bekannt sind. Da die Dateien nicht geändert werden, müssen sie auf der Serverseite nicht gesperrt werden.

Clientseitiges Failover in NFS-Version 4

Wenn in NFS-Version 4 eine Replikation nicht bereitgestellt werden kann, weil die Dateigrößen unterschiedlich sind oder die Dateitypen nicht übereinstimmen, geschieht Folgendes:

• Die Datei wird als gesperrt gekennzeichnet.

• Eine Warnung wird ausgegeben.

• Die Anwendung empfängt einen Systemaufruffehler.

In NFS-Version 4 werden keine Replikationsfehler bei Verzeichnissen von unterschiedlicher Größe angezeigt. In früheren Versionen von NFS wurde in diesem Fall ein Fehler gemeldet, der den Neuzuordnungsprozess behindert.

Wenn in NFS-Version 4 ein Verzeichnis nicht gelesen werden kann, wird der Vorgang vom nächsten gelisteten Server ausgeführt. In früheren Versionen von NFS führten nicht erfolgreiche Lesevorgänge dazu, dass die Neuzuordnung fehlschlug und der Prozess hing, bis der ursprüngliche Server wieder verfügbar war.

Große Dateien

Das Betriebssystem unterstützt Dateien mit einer Größe von über 2 GB. UFS-Dateisysteme werden standardmäßig mit der Option - largefiles eingehängt, um die neue Funktion zu unterstützen. Lesen Sie bei Bedarf dazu So deaktivieren Sie große Dateien auf einem NFS-Server.

Wenn das Dateisystem des Servers mithilfe der Option -largefiles eingehängt wird, kann ein Solaris 2.6-NFS-Client auf große Dateien zugreifen, ohne dass Änderungen erforderlich sind. Jedoch können diese großen Dateien nicht mithilfe von allen Solaris 2.6-Befehlen verarbeitet werden. Eine Liste der Befehle, die in Verbindung mit großen Dateien verwendet werden können, finden Sie unter largefile(5). Clients, die das Protokoll der NFS-Version 3 mit den Erweiterungen für große Dateien nicht unterstützen, können nicht auf große Dateien zugreifen. Obwohl Clients, auf denen Solaris 2.5 ausgeführt wird, das Protokoll der NFS-Version 3 verwenden können, unterstützt die Version nicht die Verarbeitung großer Dateien.

Funktionsweise der NFS-Serverprotokollierung

Die NFS-Serverprotokollierung stellt Datensätze der NFS-Lese- und Schreibvorgänge sowie der Vorgänge bereit, die zum Modifizieren des Dateisystems dienen. Diese Daten können verwendet werden, um den Zugriff auf Informationen zu verfolgen. Außerdem bieten Datensätze eine Möglichkeit, die Nachfrage nach diesen Informationen zu messen.

Wenn auf ein Dateisystem, für das die Protokollierung aktiviert ist, zugegriffen wird, schreibt der Kernel die Raw-Daten in eine Pufferdatei. In diesen Daten ist Folgendes enthalten:

• Ein Zeitstempel

• Die Client-IP-Adresse

• Die UID des Anforderers

• Die Dateizugriffsroutine des Datei- oder Verzeichnisobjekts, auf das zugegriffen wird

• Die Art des ausgeführten Vorgangs

Der Dämon nfslogd konvertiert diese Raw-Daten in ASCII-Datensätze, die in Protokolldateien gespeichert werden. Während der Konvertierung werden die IP-Adressen in Hostnamen und die UIDs in Anmeldenamen umgewandelt, wenn der aktivierte Name Service Übereinstimmungen finden kann. Außerdem werden die Dateizugriffsroutinen in Pfadnamen konvertiert. Um die Konvertierung durchzuführen, verfolgt der Dämon die Dateizugriffsroutinen und speichert die Informationen in einer separaten Dateizugriffsroutine-zu-Pfad-Tabelle. Dadurch muss der Pfad nicht jedesmal aufs Neue ermittelt werden, wenn auf eine Dateizugriffsroutine zugegriffen wird. Da keine Änderungen an den Zuordnungen in der Dateizugriffsroutine-zu-Pfad-Tabelle vorgenommen werden, wenn nfslogd deaktiviert ist, müssen Sie dafür sorgen, dass der Dämon weiterhin ausgeführt wird.

Funktionsweise des WebNFS-Service

Der WebNFS-Service stellt den Clients Dateien in einem Verzeichnis zur Verfügung, indem eine Routine für den Zugriff auf öffentliche Dateien verwendet wird. Eine Dateizugriffsroutine ist eine vom Kernel generierte Adresse, die zur Angabe einer Datei für NFS-Clients dient. Die Routine für den Zugriff auf öffentliche Dateien hat einen vordefinierten Wert, sodass der Server keine Dateizugriffsroutine für den Client generieren muss. Durch die Fähigkeit, diese vordefinierte Dateizugriffsroutine zu verwenden, wird der Netzwerkverkehr verringert, da die Verwendung des MOUNT-Protokolls entfällt. Diese Fähigkeit beschleunigt zudem die clientbezogenen Prozesse.

Die Routine für den Zugriff auf öffentliche Dateien auf einem NFS-Server wird standardmäßig im Root-Dateisystem erstellt. Dieser standardmäßige Vorgang gewährleistet den WebNFS-Zugriff auf alle Clients, die bereits über Einhängeberechtigungen auf dem Server verfügen. Sie können die Routine für den Zugriff auf öffentliche Dateien ändern, um auf ein beliebiges Dateisystem mithilfe des Befehls share zu verweisen.

Wenn der Client über die Dateizugriffsroutine für das Dateisystem verfügt, wird ein LOOKUP-Vorgang ausgeführt, um die Dateizugriffsroutine für die Datei zu bestimmen, auf die zugegriffen wird. Das NFS-Protokoll ermöglicht die Evaluierung von jeweils nur einer Pfadnamenkomponente. Jede weitere Verzeichnishierarchieebene erfordert einen weiteren LOOKUP-Vorgang. Ein WebNFS-Server kann den gesamten Pfadnamen mithilfe einer einzelnen Mehrkomponenten-Suchtransaktion evaluieren, wenn der LOOKUP-Vorgang in Relation zur Routine für den Zugriff auf öffentliche Dateien steht. Mehrkomponenten-Suchvorgänge ermöglichen dem Webserver, die Dateizugriffsroutine für die gewünschte Datei bereitzustellen, ohne die Dateizugriffsroutinen für jede Verzeichnisebene im Pfadnamen auszutauschen.

Außerdem kann ein NFS-Client gleichzeitige Downloads über eine einzige TCP-Verbindung einleiten. Diese Verbindung ermöglicht einen schnellen Zugriff ohne zusätzliche Belastung des Servers durch das Einrichten mehrerer Verbindungen. Obwohl Webbrowseranwendungen das gleichzeitige Herunterladen mehrerer Dateien unterstützen, hat jede Datei eine eigene Verbindung. Durch die Verwendung einer Verbindung kann die WebNFS-Software die Mehrbelastung des Servers verringern.

Wenn die letzte Komponente des Pfadnamens eine symbolische Verknüpfung zu einem anderen Dateisystem ist, kann der Client auf die Datei zugreifen, wenn er bereits über Zugriff durch normale NFS-Aktivitäten verfügt.

Normalerweise wird eine NFS-URL in Relation zur Routine für den Zugriff auf öffentliche Dateien evaluiert. Die Evaluierung kann geändert werden, damit sie in Relation zum Root-Dateisystem des Servers steht, indem ein zusätzlicher Schrägstrich an den Anfang des Pfads gesetzt wird. Die ibeiden NFS-URLs in diesem Beispiel sind äquivalent, wenn die Routine für den Zugriff auf öffentliche Dateien im /export/ftp-Dateisystem bereitgestellt ist.

nfs://server/junk
nfs://server//export/ftp/junk

Funktionsweise der WebNFS-Sicherheitsaushandlung

Der NFS-Service stellt ein neues Protokoll bereit, das WebNFS-Clients ermöglicht, einen bestimmten Sicherheitsmechanismus mit einem WebNFS-Server auszuhandeln. Das neue Protokoll verwendet für die Sicherheitsaushandlung eine Mehrkomponenten-Suche, bei der es sich um eine Erweiterung der Mehrkomponenten-Suche handelt, die in früheren Versionen des WebNFS-Protokolls verwendet wurde.

Der WebNFS-Client initiiert den Prozess, indem er mithilfe der Routine für den Zugriff auf öffentliche Dateien eine normale Mehrkomponenten-Suche anfordert. Da dem Client nicht bekannt ist, wie der Pfad durch den Server geschützt wird, wird der standardmäßige Sicherheitsmechanismus verwendet. Wenn der standardmäßige Sicherheitsmechanismus nicht ausreicht, antwortet der Server mit einem AUTH_TOOWEAK-Fehler. Dadurch wird angezeigt, dass der Mechanismus nicht gültig ist. Der Client muss einen wirkungsvolleren Standardmechanismus verwenden.

Nachdem der Client den AUTH_TOOWEAK-Fehler empfangen hat, sendet er eine Anforderung an den Server, um festzustellen, welche Sicherheitsmechanismen erforderlich sind. Wenn die Anforderung erfolgreich durchgeführt wird, antwortet der Server mit einer Feldgruppe von Sicherheitsmechanismen, die für den angegebenen Pfad erforderlich sind. Je nach Größe der Feldgruppe der Sicherheitsmechanismen führt der Client weitere Anforderungen aus, um die vollständige Feldgruppe abzurufen. Wenn der Server die WebNFS-Sicherheitsaushandlung nicht unterstützt, schlägt die Anforderung fehl.

Nach einer erfolgreich durchgeführten Anforderung wählt der WebNFS-Client den ersten Sicherheitsmechanismus aus der Feldgruppe aus, die vom Client unterstützt wird. Der Client gibt dann eine normale Mehrkomponenten-Suchanforderung aus, indem er die ausgewählten Sicherheitsmechanismen verwendet, um die Dateizugriffsroutine abzurufen. Alle nachfolgenden NFS-Anforderungen werden mithilfe des ausgewählten Sicherheitsmechanismus und der Dateizugriffsroutine durchgeführt.

WebNFS-Beschränkungen bei Verwendung eines Webbrowsers

Viele Funktionen, die von einer Website bereitgestellt werden, die HTTP verwendet, werden von der WebNFS-Software nicht unterstützt. Diese Unterschiede sind auf die Tatsache zurückzuführen, dass der NFS-Server die Datei lediglich sendet, wodurch bestimmte Verarbeitungsvorgänge vom Client ausgeführt werden müssen. Wenn eine Website sowohl für den WebNFS- als auch für den HTTP-Zugriff konfiguriert werden muss, ist Folgendes zu berücksichtigen:

• Bei NFS-Suchvorgängen werden keine CGI-Skripten ausgeführt. Aus diesem Grund kann ein Dateisystem mit einer aktiven Website, auf der viele Skripten verwendet werden, eventuell nicht mithilfe von NFS durchsucht werden.

• Der Browser startet möglicherweise verschiedene Viewer, um Dateien in verschiedenen Dateiformaten zu verarbeiten. Durch den Zugriff auf diese Dateien über eine NFS-URL wird ein externer Viewer gestartet, wenn der Dateityp durch den Dateinamen bestimmt werden kann. Der Browser erkennt normalerweise alle Dateinamenserweiterungen für standardmäßige MIME-Typen, wenn eine NFS-URL verwendet wird. Die WebNFS-Software prüft nicht den Inhalt der Datei, um den Dateityp zu bestimmen. Darum kann ein Dateiname nur anhand der Dateinamenserweiterung bestimmt werden.

• In NFS-Suchvorgängen können keine serverseitigen ImageMaps (anklickbare Bilder) verwendet werden. Es können aber clientseitige ImageMaps (anklickbare Bilder) verwendet werden, weil die URLs durch Speicherorte definiert werden. Es ist keine weitere Anwort des Dokumentservers erforderlich.

Sicheres NFS-System

Die NFS-Umgebung ist eine effiziente und bequeme Methode zur gemeinsamen Nutzung von Dateisystemen in einem Netzwerk, das aus verschiedenen Computerarchitekturen und Betriebssystemen besteht. Die Funktionen, die eine reibungslose gemeinsame Nutzung von Dateisystemen durch NFS gewährleisten, sind jedoch auch die Ursache für Sicherheitsprobleme. In der Vergangenheit wurden für die meisten NFS-Implementierungen die UNIX-Authentifizierung (oder AUTH_SYS) verwendet, während bessere Authentifizierungsverfahren wie beispielsweise AUTH_DH bereits zur Verfügung standen. Bei Verwendung der UNIX-Authentifizierung authentifiziert ein NFS-Server eine Dateianforderung, indem anstelle des Benutzers der Computer authentifiziert wird, von dem die Anforderung ausgeht. Dadurch kann ein Clientbenutzer den Befehl su ausführen und der Eigentümer einer Datei sein. Wenn die DH-Authentifizierung verwendet wird, authentifiziert der NFS-Server den Benutzer, wodurch diese Art der Imitation bedeutend erschwert wird.

Jeder, der Root-Zugriff hat und über Kenntnisse über Netzwerkprogrammierung verfügt, kann Daten in das Netzwerk einschleusen oder diese aus dem Netzwerk extrahieren. Die größte Gefahr stellen Angriffe dar, bei denen Daten eingeschleust werden. Durch Generierung der richtigen Pakete oder durch Aufzeichnung von Dialogen, die später wiedergegeben werden, kann beispielsweise ein Benutzer imitiert werden. Diese Angriffe gefährden die Datenintegrität. Angriffe durch passives Mithören, bei dem nur das Netzwerk abgehört wird, ohne eine Person zu imitieren, sind weniger gefährlich, da die Datenintegrität nicht gefährdet wird. Benutzer können vertrauliche Daten schützen, indem sie die Daten verschlüsseln, die über das Netzwerk gesendet werden.

Ein allgemeiner Ansatz zur Behebung von Netzwerksicherheitsproblemen besteht darin, entsprechende Lösungen in den einzelnen Anwendungen zu implementieren. Ein besserer Ansatz besteht darin, ein standardmäßiges Authentifizierungssystem für alle Anwendungen zu installieren.

Das Betriebssystem Solaris bietet ein Authentifizierungsystem auf der Ebene des RPC (Remote Procedure Call). RPC ist ein Mechanismus, auf dem der NFS-Vorgang basiert. Dieses System, das als sicheres RPC bezeichnet wird, verbessert spürbar die Sicherheit von Netzwerkumgebungen und bietet Services wie beispielsweise dem NFS-System mehr Sicherheit. Da das NFS-System die vom sicheren RPC bereitgestellten Funktionen verwendet, wird es in diesem Zusammenhang auch als sicheres NFS-System bezeichnet.

Secure RPC

Sicheres RPC ist eine wichtige Grundlage für den Einsatz des sicheren NFS-Systems. Das Ziel vom sicheren RPC ist die Einrichtung eines Systems, das mindestens so sicher wie ein Teilnehmersystem ist. In einem Teilnehmersystem verwenden alle Benutzer einen einzelnen Computer. Jeder Benutzer wird durch ein Anmeldepasswort authentifiziert. Mit der DES-Authentifizierung (Data Encryption Standard) wird derselbe Authentifizierungsprozess durchgeführt. Die Benutzer können sich bei jedem Remote-Computer wie bei einem lokalen Terminal anmelden. Die Anmeldepasswörter der Benutzer gewährleisten die Netzwerksicherheit. In einem Teilnehmersystem darf der Systemadministrator aus ethischen Gründen kein Passwort ändern, um einen Benutzer zu imitieren. Im sicheren RPC wird dem Netzwerkadministrator vertraut und vorausgesetzt, dass keine Einträge in einer Datenbank geändert werden, in der der öffentliche Schlüssel gespeichert sind.

Um ein RPC-Authentifizierungssystem zu verstehen, müssen Sie zwei Begriffe kennen: Berechtigungsnachweise und Nachweise. Beispielsweise dienen Berechtigungsnachweise in Verbindung mit Ausweisen zur Identifizierung einer Person: Name, Adresse und Geburtsdatum. Der Nachweis ist das Foto, das zum Ausweis gehört. Ob der Ausweis gestolen ist oder der Person gehört, die im Besitz des Ausweises ist, lässt sich feststellen, indem das Ausweisfoto mit der Person verglichen wird. In RPC sendet der Clientprozess zusammen mit jeder RPC-Anforderung sowohl Berechtigungsnachweise als auch einen Nachweis an den Server. Der Server sendet nur einen Nachweis zurück, da der Client die Berechtigungsnachweise des Servers bereits "kennt".

Die RPC-Authentifizierung ist unbegrenzt erweiterungsfähig, es können demnach zahlreiche Authentifizierungssysteme wie beispielsweise UNIX, DH oder KERB integriert werden.

Wenn die UNIX-Authentifizierung von einem Netzwerkdienst verwendet wird, ist in den Berechtigungsnachweisen der Hostname des Clients, die UID, die GID und die Gruppenzugriffsliste enthalten. Im Nachweis ist jedoch nichts enthalten. Da also kein Nachweis vorhanden ist, könnte ein Superuser Berechtigungsnachweise fälschen, indem er einen Befehl wie beispielsweise su verwendet. Ein weiteres Problem im Zusammenhang mit der UNIX-Authentifizierung besteht darin, dass bei der UNIX-Authentifizierung vorausgesetzt wird, dass alle Computer in einem Netzwerk UNIX-Computer sind. Die UNIX-Authentifizierung schlägt fehl, wenn sie bei anderen Betriebssystemen in einem heterogenen Netzwerk angewendet wird.

Um die mit der UNIX-Authentifizierung verbundenen Probleme zu vermeiden, wird im sicheren RPC die DH-Authentifizierung verwendet.

DH-Authentifizierung

Bei der DH-Authentifizierung werden der DES (Data Encryption Standard) und Diffie-Hellman-Verschlüsselung mit öffentlichen Schlüsseln verwendet, um Benutzer und Computer in einem Netzwerk zu authentifizieren. DES ist ein standardmäßiger Verschlüsselungsmechanismus. Diffie-Hellman-Verschlüsselung mit öffentlichem Schlüssel ist ein Ziffernsystem, das zwei Schlüssel umfasst: einen öffentlichen und einen geheimen Schlüssel. Die öffentlichen und die geheimen Schlüssel werden im Namespace gespeichert. NIS speichert die Schlüssel in der Map für öffentliche Schlüssel. Diese Maps enthalten die öffentlichen und geheimen Schlüssel für alle potentiellen Benutzer. Weitere Informationen zum Einrichten dieser Tabellen finden Sie unter Systemverwaltungshandbuch: Naming Services und Directory Services (DNS, NIS und LDAP).

Die Sicherheit der DH-Authentifizierung basiert auf der Fähigkeit eines Absenders, die aktuelle Zeit zu verschlüsseln, die dann vom Empfänger entschlüsselt und mit der eigenen Zeit verglichen wird. Der Zeitstempel wird mit DES verschlüsselt. Damit dieses Schema funktioniert, müssen folgende Voraussetzungen erfüllt sein:

• Die beiden Agenten müssen die aktuelle Zeit vereinbaren.

• Der Absender und der Empfänger müssen den gleichen Verschlüsselungsschlüsseln verwenden.

Wenn ein Netzwerk ein Zeitsynchronisierungsprogramm ausführt, wird die Zeit auf dem Client und dem Server automatisch synchronisiert. Wenn kein Zeitsynchronisierungsprogramm zur Verfügung steht, können die Zeitstempel berechnet werden, indem die Zeit des Servers anstelle der Netzwerkzeit verwendet wird. Der Client fragt beim Server die Zeit ab, bevor er mit der RPC-Sitzung beginnt. Dann berechnet er die Zeitdifferenz zwischen seiner eigenen Uhr und der des Servers. Diese Differenz wird verwendet, um die Uhr des Clients anzupassen, wenn die Zeitstempel berechnet werden. Wenn die Uhren des Clients und des Servers nicht mehr synchron laufen, lehnt der Server die Anforderungen des Clients ab. Das auf dem Server ausgeführte DH-Authentifizierungssystem führt erneut eine Synchronisierung mit dem Server durch.

Der Client und der Server erhalten den gleichen Verschlüsselungsschlüssel, indem ein zufälliger Dialogschlüssel generiert wird, der auch als Sitzungsschlüssel bezeichnet wird, und indem die Verschlüsselung mit öffentlichen Schlüsseln verwendet wird, um einen allgemeinen Schlüssel abzuleiten. Der allgemeine Schlüssel ist ein Schlüssel, den nur der Client und der Server ableiten können. Der Dialogschlüssel wird verwendet, um den Zeitstempel des Clients zu verschlüsseln und zu entschlüsseln. Der allgemeine Schlüssel wird verwendet, um den Dialogschlüssel zu verschlüsseln und zu entschlüsseln.

KERB-Authentifizierung

Kerberos ist ein Authentifizierungssystem, das am MIT entwickelt wurde. Kerberos bietet zahlreiche Verschlüsselungstypen, darunter DES. Kerberos-Unterstützung wird nicht mehr als Teil von Secure RPC bereitgestellt, aber Solaris enthält eine serverseitige und clientseitige Implementierung. Weitere Informationen zur Implementierung der Kerberos-Authentifizierung finden Sie in Kapitel 21, Einführung zum Kerberos-Service in Systemverwaltungshandbuch: Sicherheitsservices.

Verwenden vom sicheren RPC mit NFS

Wenn Sie vorhaben, das sichere RPC zu verwenden, sollten Sie Folgendes berücksichtigen:

• Wenn ein Server abstürzt, wenn niemand in der Nähe ist (beispielsweise nach einem Stromausfall), werden alle geheimen Schlüssel gelöscht, die im System gespeichert sind. Dann kann kein Prozess auf sichere Netzwerkdienste zugreifen oder ein NFS-Dateisystem einhängen. Die wichtigen Prozesse während eines Neustarts werden normalerweise als root ausgeführt. Darum würden diese Prozesse funktionieren, wenn der geheime Schlüssel des Root-Benutzers gespeichert wäre. Allerdings kennt niemand das Passwort, das zum Entschlüsseln des Schlüssels benötigt wird. keylogin -r erlaubt root, den unverschlüsselten geheimen Schlüssel in der Datei /etc/.rootkey zu speichern, die von keyserv gelesen wird.

• Manche Systeme werden mithilfe einer Root-Anmelde-Shell auf der Konsole und ohne Aufforderung zur Eingabe eines Passworts im Einzelbenutzermodus neu gestartet. In solchen Fällen ist die physische Sicherheit von vorrangiger Bedeutung.

• Das Booten von Computern ohne lokalen Massenspeicher ist nicht umfassend sicher. Der Boot-Server könnte imitiert werden, um einen falschen Kernel zu booten, mit dem beispielsweise ein Datensatz Ihres geheimen Schlüssels auf einem Remote-Computer erstellt wird. Das sichere NFS-System bietet nur dann Schutz, wenn der Kernel und der Schlüsselserver ausgeführt werden. Ansonsten gibt es keine Möglichkeit, die Replikationen zu authentifizieren, die vom Boot-Server bereitgestellt werden. Diese Beschränkung kann ein schwerwiegendes Problem sein, erfordert aber einen ausgeklügelten Angriff unter Verwendung des Kernel-Quellcodes. Beim kriminellen Vorgehen werden auf jeden Fall Spuren hinterlassen. Wenn Sie im Netzwerk nach Boot-Servern suchen, würden Sie den falschen Standort des Boot-Servers finden.

• Die meisten setuid-Programme sind im Besitz des root-Benutzers. Wenn der geheime Schlüssel für root in /etc/.rootkey gespeichert wird, verhalten sich diese Programme wie gewöhnlich. Wenn ein setuid-Programm jedoch im Besitz eines Benutzers ist, funktioniert es eventuell nicht immer richtig. Ein setuid-Programm ist beispielsweise im Besitz von dave und dave hat sich nach dem Booten nicht beim Computer angemeldet. Das Programm würde dann nicht auf die sicheren Netzwerkdienste zugreifen können.

• Wenn Sie sich (mithilfe von login , rlogin oder telnet) bei einem Remote-Computer anmelden und keylogin verwenden, um Zugriff zu erhalten, geben Sie den Zugriff auf Ihr Konto frei. Der Grund dafür ist der, dass Ihr geheimer Schlüssel an den Schlüsselserver des Computers weitergegeben wird, auf dem Ihr geheimer Schlüssel dann gespeichert wird. Dieser Prozess ist nur dann von Bedeutung, wenn Sie den Remote-Computer nicht als vertrauenswürdig betrachten. Wenn Sie jedoch Zweifel haben, melden Sie sich nicht bei dem Remote-Computer an, wenn dieser ein Passwort verlangt. Verwenden Sie stattdessen die NFS-Umgebung, um Dateisysteme einzuhängen, die vom Remote-Computer gemeinsam genutzt werden. Als Alternative können Sie keylogout verwenden, um den geheimen Schlüssel auf dem Schlüsselserver zu löschen.

• Wenn ein Home-Verzeichnis mit der Option -o sec=dh zur gemeinsamen Nutzung freigegeben wird, können Remote-Anmeldungen ein Problem darstellen. Wenn die /etc/hosts.equiv- oder ~/.rhosts-Datei nicht so eingerichtet ist, dass ein Passwort angefordert wird, kann die Anmeldung erfolgreich durchgeführt werden. Die Benutzer können jedoch nicht auf ihre Home-Verzeichnisse zugreifen, weil die Authentifizierung lokal durchgeführt wurde. Wenn ein Benutzer zur Eingabe eines Passworts aufgefordert wird, kann der Benutzer auf sein Home-Verzeichnis zugreifen, wenn das Passwort mit dem Netzwerkpasswort übereinstimmt.