JavaScript is required to for searching.
Navigationslinks �berspringen
Druckansicht beenden
Systemverwaltungshandbuch: Netzwerkdienste
search filter icon
search icon

Dokument-Informationen

Vorwort

Teil I Netzwerkdienste - Themen

1.  Netzwerkdienst (Übersicht)

2.  Verwalten von Webcache-Servern

3.  Zeitorientierte Services

Teil II Zugriff auf Netzwerkdateisysteme - Themen

4.  Verwalten von Netzwerkdateisystemen (Übersicht)

5.  Verwaltung des Netzwerkdateisystems (Aufgaben)

6.  Zugreifen auf Netzwerkdateisysteme (Referenz)

NFS-Dateien

/etc/default/autofs-Datei

Schlüsselwörter für die /etc/default/nfs-Datei

/etc/default/nfslogd-Datei

/etc/nfs/nfslog.conf-Datei

NFS-Dämonen

automountd-Dämon

lockd-Dämon

mountd-Dämon

nfs4cbd-Dämon

nfsd-Dämon

nfslogd-Dämon

nfsmapid-Dämon

Konfigurationsdateien und nfsmapid

Vorrangsregeln

nfsmapid und DNS-TXT-Datensätze

Ermitteln der Domain der NFS-Version 4

Konfigurieren der Standarddomain der NFS-Version 4

Zusätzliche Informationen zu nfsmapid

statd-Dämon

NFS-Befehle

automount-Befehl

clear_locks-Befehl

fsstat-Befehl

mount-Befehl

mount-Optionen für NFS-Dateisysteme

Verwenden des mount-Befehls

umount-Befehl

mountall-Befehl

umountall-Befehl

share-Befehl

Nicht dateisystemspezifische share-Optionen

NFS-spezifische share-Optionen

Einrichten von Zugriffslisten mit dem share-Befehl

unshare-Befehl

shareall-Befehl

unshareall-Befehl

showmount-Befehl

setmnt-Befehl

Befehle zum Beheben von NFS-Problemen

nfsstat-Befehl

pstack-Befehl

rpcinfo-Befehl

snoop-Befehl

truss-Befehl

NFS über RDMA

Funktionsweise des NFS-Service

Versionsaushandlung in NFS

Funktionen in NFS-Version 4

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

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

Failover-Terminologie

Was ist ein repliziertes Dateisystem?

Failover und NFS-Sperrung

Clientseitiges Failover in NFS-Version 4

Große Dateien

Funktionsweise der NFS-Serverprotokollierung

Funktionsweise des WebNFS-Service

Funktionsweise der WebNFS-Sicherheitsaushandlung

WebNFS-Beschränkungen bei Verwendung eines Webbrowsers

Sicheres NFS-System

Secure RPC

DH-Authentifizierung

KERB-Authentifizierung

Verwenden vom sicheren RPC mit NFS

Autofs-Maps

Master-Autofs-Maps

Einhängepunkt /home

Einhängepunkt /net

Direkte Autofs-Map

Einhängepunkt /-

Indirekte autofs-Maps

Funktionsweise von autofs

Wie autofs durch das Netzwerk navigiert (Maps)

Wie autofs den Navigationprozess startet (Master-Map)

Autofs-Einhängeprozess

Einfache autofs-Einhängung

Hierarchisches Einhängen

Autofs-Aushängung

Wie autofs die nächsten schreibgeschützten Dateien für Clients auswählt (mehrere Speicherorte)

Autofs und Gewichtung

Variablen in einem Map-Eintrag

Maps, die sich auf andere Maps beziehen

Ausführbare autofs-Maps

Modifizieren, wie autofs im Netzwerk navigiert (Modifizieren von Maps)

Standardmäßiges Verhalten von autofs bei Verwendung von Name Services

Autofs-Referenz

Autofs und Metazeichen

Und-Zeichen (&)

Sternchen (*)

Autofs und Sonderzeichen

Teil III SLP (Service Location Protocol) - Themen

7.  SLP (Übersicht)

8.  Planen und Aktivieren von SLP (Aufgaben)

9.  Verwalten von SLP (Aufgaben)

10.  Integrieren von veralteten Services

11.  SLP (Referenz)

Teil IV Mailservices - Themen

12.  Mailservices (Übersicht)

13.  Mailservices (Aufgaben)

14.  Mailservices (Referenz)

Teil V Serielle Vernetzung - Themen

15.  Solaris PPP 4.0 (Überblick)

16.  PLanen einer PPP-Verbindung (Aufgaben)

17.  Einrichten einer PPP-Einwahlverbindung (Aufgaben)

18.  Einrichten einer PPP-Standleitungsverbindung (Aufgaben)

19.  Einrichten der PPP-Authentifizierung (Aufgaben)

20.  Einrichten eines PPPoE-Tunnels (Aufgaben)

21.  Beheben von allgemeinen PPP-Problemen (Aufgaben)

22.  Solaris PPP 4.0 (Referenz)

23.  Migrieren von Asynchronous Solaris PPP zu Solaris PPP 4.0 (Aufgaben)

24.  UUCP (Übersicht)

25.  Verwalten von UUCP (Aufgaben)

26.  UUCP (Referenz)

Teil VI Arbeiten mit Remote-Systemen - Themen

27.  Arbeiten mit Remote-Systemen (Übersicht)

28.  Verwalten des FTP-Servers (Aufgaben)

29.  Zugriff auf Remote-Systeme (Aufgaben)

Teil VII Überwachen von Netzwerkdiensten - Themen

30.  Überwachen der Netzwerkleistung (Aufgaben)

Glossar

Index

NFS-Dämonen

Zur Unterstützung von NFS-Vorgängen werden verschiedene Dämonen gestartet, wenn ein System auf die Betriebsebene 3 oder in den Mehrbenutzermodus wechselt. Die Dämonen mountd und nfsd werden auf Systemen ausgeführt, bei denen es sich um Server handelt. Ob die Serverdämonen automatisch gestartet werden, hängt davon ab, ob Einträge vorhanden sind, die durch den NFS-Dateisystemtyp in /etc/dfs/sharetab gekennzeichnet sind. Zur Unterstützung der NFS-Dateisperrung werden die Dämonen lockd und statd auf NFS-Clients und -Servern ausgeführt. Anders als in den NFS-Vorgängerversionen werden in NFS-Version 4 die Dämonen lockd, statd, mountd und nfslogd nicht verwendet.

In diesem Abschnitt werden die folgenden Dämonen beschrieben:

automountd-Dämon

Dieser Dämon verarbeitet Ein- und Aushängungsanforderungen des autofs-Service. Die Syntax des Befehls lautet folgendermaßen:

automountd [ -Tnv ] [ -D name= value ]

Der Befehl bewirkt Folgendes:

Der Standardwert für die automount-Map ist /etc/auto_master. Verwenden Sie die Option -T zur Fehlerbehebung.

lockd-Dämon

Dieser Dämon unterstützt Datensatzsperrvorgänge für NFS-Dateien. Der lockd-Dämon steuert RPC-Verbindungen zwischen Client und Server für das NLM-Protokoll (Network Lock Manager). Der Dämon wird normalerweise ohne Optionen gestartet. Sie können drei Optionen in Verbindung mit diesem Befehl angeben. Weitere Informationen finden Sie auf der Manpage lockd(1M). Diese Optionen können entweder über die Befehlszeile oder durch Bearbeiten der entsprechenden Zeichenfolge in /etc/default/nfs verwendet werden. Es folgen Beschreibungen von Schlüsselwörtern, die in der /etc/default/nfs-Datei angegeben werden können.


Hinweis - Ab Solaris 10 werden das Schlüsselwort LOCKD_GRACE_PERIOD und die Option -g nicht mehr verwendet. Das veraltete Schlüsselwort wird durch das neue Schlüsselwort GRACE_PERIOD ersetzt. Wenn beide Schlüsselwörter angegeben sind, setzt der Wert für GRACE_PERIOD den Wert für LOCKD_GRACE_PERIOD außer Kraft. Weitere Informationen finden Sie in der folgenden Beschreibung von GRACE_PERIOD.


Ebenso wie bei LOCKD_GRACE_PERIOD , GRACE_PERIOD=graceperiod in /etc/default/nfs wird die Zeit (in Sekunden) nach einem Serverneustart festgelegt, nach deren Verstreichen die Clients sowohl die von NLM bereitgestellten Sperren der NFS-Version 3 als auch die Sperren der Version 4 zurückfordern müssen. Der Wert GRACE_PERIOD bestimmt damit die Länge der Wartezeit für die Wiederherstellung der Sperre für NFS-Versionen 3 und 4.

Der LOCKD_RETRANSMIT_TIMEOUT=timeout-Parameter in /etc/default/nfs gibt die Dauer der Wartezeit in Sekunden an, bevor eine Sperranforderung erneut an den Remote-Server gesendet wird. Diese Option wirkt sich auf den clientseitigen NFS-Service aus. Der Standardwert für timeout beträgt 15 Sekunden. Durch eine Herabsetzung des timeout-Werts kann die Reaktionszeit für NFS-Clients in einem Netzwerk mit starker Aktivität verbessert werden. Diese Änderung kann jedoch zu einer zusätzlichen Serverbelastung aufgrund von häufigeren Sperranforderungen führen. Der gleiche Parameter kann über die Befehlszeile angegeben werden, indem der Dämon mit der Option -t timeout gestartet wird.

Der LOCKD_SERVERS= nthreads-Parameter in /etc/default/nfs gibt die maximale Anzahl von gleichzeitig aktiven Threads an, die vom Server pro Verbindung verarbeitet werden. Geben Sie den Wert nthreads unter Berücksichtigung der erwarteten Belastung des NFS-Servers an. Der Standardwert ist 20. Jeder NFS-Client, der TCP verwendet, verwendet eine einzelne Verbindung mit dem NFS-Server. Darum kann jeder Client maximal 20 gleichzeitig aktive Threads auf dem Server verwenden.

Alle NFS-Clients, die UDP verwenden, verwenden gemeinsam eine einzelne Verbindung mit dem NFS-Server. Unter diesen Bedingungen müssen Sie eventuell die Anzahl der Threads erhöhen, die für die UDP-Verbindung zur Verfügung stehen. Es müssen mindestens zwei Threads für jeden UDP-Client bereitgestellt werden. Da sich dies jedoch auf die Arbeitslast auf dem Client bezieht, reichen zwei Threads pro Client unter Umständen nicht aus. Der Nachteil der Verwendung von mehreren Threads ist, dass mehr Speicherplatz auf dem NFS-Server belegt wird. Wenn die Threads jedoch nicht verwendet werden, ist die Erhöhung von nthreads bedeutungslos. Der gleiche Parameter kann über die Befehlszeile wirksam werden, wenn der Dämon mit der Option nthreads gestartet wird.

mountd-Dämon

Dieser Dämon verarbeitet von Remote-Systemen eingehende Anforderungen für die Einhängung von Dateisystemen und sorgt für die Zugriffssteuerung. Der mountd-Dämon prüft /etc/dfs/sharetab, um festzustellen, welche Dateisysteme für die Remote-Einhängung zur Verfügung stehen und welchen Systemen erlaubt ist, Remote-Einhängungen durchzuführen. Sie können die Optionen - v und -r in Verbindung mit diesem Befehl verwenden. Weitere Informationen finden Sie auf der Manpage mountd(1M).

Die Option -v bewirkt, dass der Befehl im ausführlichen Modus ausgeführt wird. Jedesmal, wenn ein NFS-Server bestimmt, welchem Client der Zugriff gewährt werden soll, wird auf der Konsole eine Meldung ausgegeben. Die generierten Informationen können hilfreich sein, wenn versucht wird, die Ursache festzustellen, warum ein Client nicht auf ein Dateisystem zugreifen kann.

Die Option -r bewirkt, dass alle weiteren Einhängungsanforderungen, die von den Clients kommen, abgewiesen werden. Diese Option hat keinen Einfluss auf Clients, bei denen bereits ein Dateisystem eingehängt ist.


Hinweis - In NFS-Version 4 wird dieser Dämon nicht verwendet.


nfs4cbd-Dämon

Der Dämon nfs4cbd, der ausschließlich für die Verwendung des Clients der NFS-Version 4 bestimmt ist, verwaltet die Kommunikationsendpunkte für das Callback-Programm von NFS-Version 4. Der Dämon besitzt keine für den Benutzer zugängliche Schnittstelle. Weitere Informationen finden Sie auf der Manpage nfs4cbd(1M).

nfsd-Dämon

Dieser Dämon bearbeitet sonstige Clientdateisystemanforderungen. Sie können mehrere Optionen in Verbindung mit diesem Befehl verwenden. Ein vollständige Liste finden Sie auf der Manpage nfsd(1M). Diese Optionen können entweder über die Befehlszeile oder durch Bearbeiten der entsprechenden Zeichenfolge in /etc/default/nfs verwendet werden.

Der NFSD_LISTEN_BACKLOG=length-Parameter in /etc/default/nfs dient zur Festlegung der Länge der Verbindungswarteschlange bei verbindungsorientierten Übertragungen für NFS und TCP. Der Standardwert ist 32 Einträge. Dieselbe Auswahl kann über die Befehlszeile vorgenommen werden, indem nfsd mit der Option -l gestartet wird.

Der NFSD_MAX_CONNECTIONS=#-conn-Parameter in /etc/default/nfs dient zur Auswahl der maximalen Anzahl von Verbindungen pro verbindungsorientierte Übertragung. Der Standardwert für #-conn ist unbegrenzt. Der gleiche Parameter kann über die Befehlszeile angegeben werden, indem der Dämon mit der Option -c #-conn gestartet wird.

Der NFSD_SERVER=nservers-Parameter in /etc/default/nfs dient zur Auswahl der maximalen Anzahl von gleichzeitigen Anforderungen, die von einem Server verarbeitet werden können. Der Standardwert für nservers ist 16. Dieselbe Auswahl kann über die Befehlszeile vorgenommen werden, indem nfsd mit der Option nservers gestartet wird.

Anders als bei älteren Versionen dieses Dämons produziert nfsd nicht mehrere Instanzen, damit gleichzeitige Anforderungen verarbeitet werden können. Eine Prüfung der Verarbeitungstabelle mit ps zeigt, dass nur eine Instanz des Dämons ausgeführt wird.

nfslogd-Dämon

Dieser Dämon sorgt für die Protokollierung von Vorgängen. Die Protokollierung serverbezogener NFS-Vorgänge basiert auf den Konfigurationsoptionen, die in /etc/default/nfslogd definiert sind. Wenn die NFS-Serverprotokollierung aktiviert ist, werden die Datensätze, in denen alle in einem bestimmten Dateisystem ausgeführten RPC-Vorgänge erfasst sind, vom Kernel in eine Pufferdatei geschrieben. Dann führt nfslogd eine Nachverarbeitung dieser Anforderungen aus. Der Name Service Switch wird verwendet, um UIDs den Anmeldungen und IP-Adressen für Hostnamen zuzuordnen. Der resultierende Wert wird aufgezeichnet, wenn keine Übereinstimmung durch die angegebenen Name Services festgestellt werden kann.

Die Zuordnung von Dateizugriffsroutinen zu Pfadnamen wird ebenfalls von nfslogd durchgeführt. Der Dämon verfolgt diese Zuordnungen in einer Dateizugriffsroutine-zu-Pfad-Map. Für jedes Tag, das in /etc/nfs/nfslogd angegeben ist, ist eine Map vorhanden. Nach der Nachverarbeitung werden die Datensätze in ASCII-Protokolldateien geschrieben.


Hinweis - In NFS-Version 4 wird dieser Dämon nicht verwendet.


nfsmapid-Dämon

In Version 4 des NFS-Protokolls (RFC3530) wurde die Art und Weise des Austauschs von Benutzer- oder Gruppen-IDs (UIDs oder GIDs) zwischen Client und Server geändert. Das Protokoll verlangt, dass die Eigentümer- und Gruppenattribute einer Datei zwischen einem Client der NFS-Version 4 und einem Server der NFS-Version 4 als Zeichenfolgen in der Form von user@nfsv4_domain bzw. group@nfsv4_domain ausgetauscht werden.

Der Benutzer known_user hat beispielsweise die UID 123456 auf einem Client der NFS-Version 4, dessen voll qualifizierter Hostname system.example.com lautet. Damit der Client Anforderungen an den Server der NFS-Version 4 senden kann, muss er die UID 123456 der E-Mail-Adresse known_user@example.com zuordnen und dieses Attribut dann an den Server der NFS-Version 4 senden. Der Server der NFS-Version 4 erwartet den Empfang von Benutzer- und Gruppendateiattributen im user_or_group@nfsv4_domain -Format. Nachem der Server known_user@example.com vom Client empfangen hat, ordnet er die Zeichenfolge der lokalen UID 123456 zu, was vom zugrunde liegenden Dateisystem verstanden wird. Diese Funktionsweise setzt voraus, dass jede UID und GID im Netzwerk eindeutig ist und die Domains der NFS-Version 4 auf dem Client mit den Domains der NFS-Version 4 auf dem Server übereinstimmen.


Hinweis - Wenn der Server nicht den angegebenen Benutzer- oder Gruppennamen erkennt, kann er diesen nicht der entsprechenden eindeutigen ID zuordnen, die ein Ganzzahlwert ist. Dies ist auch dann der Fall, wenn die Domains der NFS-Version 4 übereinstimmen. In solch einem Fall ordnet der Server den eingehenden Benutzer- oder Gruppennamen dem Benutzer nobody zu. Um dies zu verhindern, sollten Administratoren die Verwendung spezieller Konten vermeiden, die nur auf dem Client der NFS-Version 4 vorhanden sind.


Der Client wie auch der Server der NFS-Version 4 sind in der Lage, Ganzzahlen in Zeichenfolgen und Zeichenfolgen in Ganzzahlen zu konvertieren. Wenn beispielsweise ein GETATTR-Vorgang stattgefunden hat, ordnet der Server der NFS-Version 4 die vom zugrunde liegenden Dateisystem kommenden UIDs und GIDs den entsprechenden Zeichenfolgen zu und sendet diese Informationen an den Client. Auch der Client muss UIDs und GIDs den Zeichenfolgen zuordnen. Wenn beispielsweise der Befehl chown ausgeführt wurde, ordnet der Client die neue UID oder GID einer Zeichenfolge zu, bevor er einen SETATTR-Vorgang an den Server sendet.

Beachten Sie jedoch, dass der Client und der Server unterschiedlich auf nicht bekannte Zeichenfolgen antwortet:

Sie können den Domainnamen für die Clients und Server mithilfe des Befehls sharectl und mit der folgenden Option ändern.

nfsmapid_domain

Legt eine allgemeine Domain für Clients und Server fest. Setzt die standardmäßige Verwendung des lokalen DNS-Domainnamens außer Kraft. Aufgabenbezogene Informationen finden Sie unter Einrichten von NFS-Services.

Konfigurationsdateien und nfsmapid

Im Folgenden wird beschrieben, wie der Dämon nfsmapid die Dateien /etc/nsswitch.conf und /etc/resolv.conf verwendet:

Vorrangsregeln

Damit nfsmapid richtig funktioniert, müssen die Clients und Server der NFS-Version 4 dieselbe Domain haben. Um sicherzustellen, dass die Domains der NFS-Version 4 übereinstimmen, richtet sich nfsmapid nach den folgenden Vorrangsregeln:

  1. Zunächst prüft der Dämon die Datei /etc/default/nfs auf einen Wert, der dem Schlüsselwort NFSMAPID_DOMAIN zugewiesen wurde. Falls ein solcher Wert gefunden wird, hat er Vorrang vor allen sonstigen Einstellungen. Der zugewiesene Wert wird an die abgehenden Attributzeichenfolgen angehängt und mit den eingehenden Attributzeichenfolgen verglichen. Weitere Informationen zu Schlüsselwörtern in der /etc/default/nfs-Datei finden Sie unter Schlüsselwörter für die /etc/default/nfs-Datei. Informationen zur Verfahrensweise finden Sie unter Einrichten von NFS-Services.


    Hinweis - Die Verwendung der Einstellung NFSMAPID_DOMAIN ist nicht skalierbar und wird nicht für große Bereitstellungen empfohlen.


  2. Falls dem Schlüsselwort NFSMAPID_DOMAIN kein Wert zugewiesen ist, sucht der Dämon nach einem Domainnamen in einem DNS-TXT-Ressourcendatensatz. nfsmapid verwendet die Anweisung in der /etc/resolv.conf-Datei, die von den Routinen im resolver verwendet werden. Der resolver durchsucht die konfigurierten DNS-Server nach dem _nfsv4idmapdomain-TXT-Ressourcendatensatz. Beachten Sie, dass die Verwendung von DNS-TXT-Ressourcendatensätzen skalierbarer ist. Aus diesem Grund ist die kontinuierliche Verwendung von TXT-Datensätzen der Angabe eines Schlüsselworts in der /etc/default/nfs-Datei vorzuziehen.

  3. Wenn kein DNS-TXT-Datensatz konfiguriert ist, um einen Domainnamen bereitzustellen, verwendet der Dämon nfsmapid den Wert, der von der Anweisung domain oder search in der Datei /etc/resolv.conf angegeben wird, wobei die zuletzt angegebene Anweisung Priorität hat.

    Im folgenden Beispiel, in dem sowohl domain- als auch die search-Anweisung verwendet wird, verwendet der Dämon nfsmapid die erste Domain, die nach der search-Anweisung angegeben ist, d. h. company.com.

    domain example.company.com
    search company.com foo.bar.com
  4. Wenn die Datei /etc/resolv.conf nicht vorhanden ist, ruft nfsmapid den Domainnamen der NFS-Version 4 ab, indem dem Verhalten des Befehls domainname gefolgt wird. Wenn die Datei /etc/defaultdomain vorhanden ist, verwendet nfsmapid den Inhalt der Datei für die Domain der NFS-Version 4. Wenn die Datei /etc/defaultdomain nicht vorhanden ist, verwendet nfsmapid den Domainnamen, der vom konfigurierten Naming Service des Netzwerks bereitgestellt wird. Weitere Informationen finden Sie auf der Manpage domainname(1M).

nfsmapid und DNS-TXT-Datensätze

Da DNS überall zu finden ist, empfiehlt sich die Verwendung des Speicher- und Verteilungsmechanismus von DNS für den Domainnamen der NFS-Version 4. Aufgrund der natürlichen Skalierbarkeit von DNS ist die Verwendung von DNS-TXT-Ressourcendatensätzen zudem die bevorzugte Methode zum Konfigurieren des Domainnamens der NFS-Version 4 für große Bereitstellungen. Sie sollten den _nfsv4idmapdomain-TXT-Datensatz auf DNS-Servern der Unternehmensklasse konfigurieren. Durch eine solche Konfiguration wird sichergestellt, dass jeder Client oder Server der NFS-Version 4 die entsprechende Domain der NFS-Version 4 in einer DNS-Struktur finden kann.

Es folgt ein Beispiel für einen bevorzugten Eintrag zum Aktivieren des DNS-Servers für die Bereitstellung eines Domainnamens der NFS-Version 4:

_nfsv4idmapdomain        IN        TXT            "foo.bar"

In diesem Beispiel ist der Domainname, der konfiguriert werden soll, der Wert, der in Anführungszeichen eingeschlossen ist. Beachten Sie, dass kein ttl-Feld angegeben ist und dass keine Domain an _nfsv4idmapdomain, den Wert im owner-Feld, angefügt ist. Diese Konfiguration ermöglicht dem TXT-Datensatz, den ${ORIGIN}-Eintrag der Zone aus dem SOA-Datensatz (Start-Of-Authority) zu verwenden. Wenn beispielsweise verschiedene Ebenen des Domain-Namespace vorhanden sind, kann der Datensatz folgendes Aussehen haben:

_nfsv4idmapdomain.subnet.yourcorp.com.    IN    TXT    "foo.bar"
_nfsv4idmapdomain.yourcorp.com.           IN    TXT    "foo.bar"

Diese Konfiguration bietet DNS-Clients zusätzliche Flexibilität bei der Verwendung der resolv.conf-Datei zum Durchsuchen der DNS-Baumstruktur. Weitere Informationen finden Sie auf der Manpage resolv.conf(4). Dank dieser Funktion wird die Wahrscheinlichkeit erhöht, den TXT-Datensatz zu finden. DNS-Teildomains können ihre eigenen DNS-TXT-Ressourcendatensätze definieren, wodurch für noch größere Flexibilität gesorgt wird. Diese Fähigkeit ermöglicht DNS-Teildomains der unteren Ebene, den TXT-Datensatz außer Kraft zu setzen, der von der Domain der obersten Ebene definiert ist.


Hinweis - Die vom TXT-Datensatz angegebene Domain kann eine beliebige Zeichenfolge sein, die nicht unbedingt mit der DNS-Domain für Clients und Server übereinstimmen muss, die die NFS-Version 4 verwenden. Sie haben die Möglichkeit, Daten der NFS-Version 4 nicht für andere DNS-Domains freizugeben.


Ermitteln der Domain der NFS-Version 4

Bevor Sie einen Wert für die Domain der NFS-Version 4 Ihres Netzwerks zuweisen, prüfen Sie, ob bereits eine Domain der NFS-Version 4 für Ihr Netzwerk konfiguriert ist. In den folgenden Beispielen werden Möglichkeiten aufgezeigt, wie eine Domain der NFS-Version 4 in Ihrem Netzwerk ermittelt werden kann.

Weitere Informationen finden Sie auf den folgenden Manpages :

Konfigurieren der Standarddomain der NFS-Version 4

In diesem Abschnitt wird beschrieben, wie das Netzwerk die entsprechende Standarddomain abruft:

Konfigurieren der Standarddomain der NFS-Version 4

In der Anfangsversion von Solaris 10 wurde die Domain während des ersten Systemneustarts nach der Installation des Betriebssystems definiert. In höheren Versionen wird die Domain der NFS-Version 4 während der Installation des Betriebssystems definiert. Um diese Funktion bereitzustellen, wurden die folgenden Funktionen hinzugefügt:

Im Folgenden wird die Funktionsweise beschrieben:

  1. Das Programm sysidnfs4 prüft die Datei /etc/.sysIDtool.state , um festzustellen, ob eine Domain der NFS-Version 4 ermittelt wurde.

    • Wenn die Datei .sysIDtool.state zeigt, dass eine Domain der NFS-Version 4 für das Netzwerk konfiguriert wurde, führt das Programm sysidnfs4 weitere Prüfungen durch. Es folgt ein Beispiel für eine .sysIDtool.state-Datei:

      1       # System previously configured?
      1       # Bootparams succeeded?
      1       # System is on a network?
      1       # Extended network information gathered?
      1       # Autobinder succeeded?
      1       # Network has subnets?
      1       # root password prompted for?
      1       # locale and term prompted for?
      1       # security policy in place
      1       # NFSv4 domain configured
      xterms

      Die 1, die vor # NFSv4 domain configured steht, bedeutet, dass die Domain der NFS-Version 4 konfiguriert wurde.

    • Wenn die .sysIDtool.state-Datei zeigt, dass keine Domain der NFS-Version 4 für das Netzwerk konfiguriert wurde, muss das Programm sysidnfs4 weitere Prüfungen durchführen. Es folgt ein Beispiel für eine .sysIDtool.state-Datei:

      1       # System previously configured?
      1       # Bootparams succeeded?
      1       # System is on a network?
      1       # Extended network information gathered?
      1       # Autobinder succeeded?
      1       # Network has subnets?
      1       # root password prompted for?
      1       # locale and term prompted for?
      1       # security policy in place
      0       # NFSv4 domain configured
      xterms

      Die 0, die vor # NFSv4 domain configured steht, weist darauf hin, dass keine Domain der NFS-Version 4 konfiguriert wurde.

  2. Wenn keine Domain der NFS-Version 4 ermittelt wurde, prüft das Programm sysidnfs4 das nfs4_domain-Schlüsselwort in der sysidcfg-Datei.

    • Wenn ein Wert für nfs4_domain vorhanden ist, wird er dem Schlüsselwort NFSMAPID_DOMAIN in der /etc/default/nfs-Datei zugewiesen. Beachten Sie, dass jeder Wert, der NFSMAPID_DOMAIN zugewiesen ist, die Fähigkeit des Dämons nfsmapid außer Kraft setzt, Domains dynamisch auszuwählen. Weitere Informationen zur Funktion der Domains zur dynamischen Auswahl des Dämons nfsmapid finden Sie unter Vorrangsregeln.

    • Wenn kein Wert für nfs4_domain vorhanden ist, ermittelt das Programm sysidnfs4 die Domain, die nfsmapid aus den konfigurierten Name Services des Betriebssystems ableitet. Dieser abgeleitete Wert wird als Standarddomain an einer interaktiven Eingabeaufforderung dargestellt, die Ihnen die Möglichkeit gibt, den Standardwert zu übernehmen oder eine andere Domain der NFS-Version 4 zuzuweisen.

Dadurch wird Folgendes nicht mehr benötigt:


Hinweis - Aufgrund der Allgegenwärtigkeit und natürlichen Skalierbarkeit von DSN werden DNS-TXT-Datensätze zum Konfigurieren der Domain von großen Bereitstellungen der NFS-Version 4 weiterhin bevorzugt verwendet. Dies wird auch nachdrücklich empfohlen. Lesen Sie dazu auch nfsmapid und DNS-TXT-Datensätze.


Ausführliche Informationen zum Solaris-Installationsprozess finden Sie hier:

Konfigurieren einer Standarddomain der NFS-Version 4 mit Solaris 10

Wenn Sie die NFS-Version der Anfangsversion von Solaris 10 verwenden und Ihr Netzwerk mehrere DNS-Domains, aber nur einen einzelnen UID- und GID-Namespace umfasst, müssen alle Clients den gleichen Wert für NFSMAPID_DOMAIN verwenden. Bei Standorten, die DNS verwenden, löst nfsmapid dieses Problem, indem der Domainname aus dem Wert abgerufen wird, den Sie _nfsv4idmapdomain zugewiesen haben. Weitere Informationen finden Sie unter nfsmapid und DNS-TXT-Datensätze. Wenn Ihr Netzwerk nicht zur Verwendung von DNS konfiguriert ist, verwendet das Betriebssystem beim ersten Starten des Systems das Dienstprogramm sysidconfig(1M), um folgende Eingabeaufforderungen für einen Domänennamen der NFS-Version 4 bereitzustellen:

This system is configured with NFS version 4, which uses a 
domain name that is automatically derived from the system's 
name services. The derived domain name is sufficient for most 
configurations. In a few cases, mounts that cross different 
domains might cause files to be owned by nobody due to the 
lack of a common domain name.

Do you need to override the system's default NFS verion 4 domain 
name (yes/no)? [no]

Die Standardantwort ist [no]. Wenn Sie [no] wählen, wird Folgendes angezeigt:

For more information about how the NFS version 4 default domain name is 
derived and its impact, refer to the man pages for nfsmapid(1M) and 
nfs(4), and the System Administration Guide: Network Services.

Wenn Sie [yes] wählen, wird die folgende Eingabeaufforderung angezeigt:

Enter the domain to be used as the NFS version 4 domain name.
NFS version 4 domain name []:

Hinweis - Wenn ein Wert für NFSMAPID_DOMAIN in /etc/default/nfs vorhanden ist, setzt der von Ihnen angegebene [domain_name] den Wert außer Kraft.


Zusätzliche Informationen zu nfsmapid

Weitere Informationen zu nfsmapid finden Sie hier:

statd-Dämon

Dieser Dämon stellt in Verbindung mit lockd Funktionen zur Wiederherstellung nach einem Systemabsturz für den Sperren-Manager bereit. Der statd-Dämon verfolgt die Clients, die über Sperren auf einem NFS-Server verfügen. Wenn ein Server abstürzt, kontaktiert der auf dem Server befindliche Dämon statd während des Neustarts den auf dem Client befindlichen Dämon statd. Der Client statd kann versuchen, Sperren auf dem Server zurückzufordern. Der Client statd benachrichtigt zudem den Server statd, wenn ein Client abgestützt ist, damit die Sperren des Clients auf dem Server entfernt werden können. Für diesen Dämon stehen keine Auswahloptionen zur Verfügung. Weitere Informationen finden Sie auf der Manpage statd(1M).

In Solaris 7 wurde das Verfahren zum Verfolgen des Clients mit statd verbessert. In allen früheren Solaris-Versionen hat statd mithilfe des nicht qualifizierten Hostnamens für jeden Client Dateien in /var/statmon/sm erstellt. Die Dateibenennung verursachte Probleme, wenn zwei Clients mit demselben Hostnamen in verschiedenen Domains vorhanden waren oder wenn sich Clients nicht in derselben Domain wie der NFS-Server befanden. Da durch den nicht qualifizierten Hostnamen nur der Hostname (ohne Informationen zur Domain oder IP-Adresse) angegeben wird, konnte mit der älteren Version von statd nicht zwischen Clients unterschieden werden. Um dieses Problem zu beheben, erstellt der Dämon statd von Solaris 7 eine symbolische Verknüpfung in /var/statmon/sm mit dem nicht qualifizierten Hostnamen her, indem die IP-Adresse des Clients verwendet wird. Die neue Verknüpfung sieht wie folgt aus:

# ls -l /var/statmon/sm
lrwxrwxrwx   1 daemon          11 Apr 29 16:32 ipv4.192.168.255.255 -> myhost
lrwxrwxrwx   1 daemon          11 Apr 29 16:32 ipv6.fec0::56:a00:20ff:feb9:2734 -> v6host
--w-------   1 daemon          11 Apr 29 16:32 myhost
--w-------   1 daemon          11 Apr 29 16:32 v6host

In diesem Beispiel lautet der Hostname des Clients myhost, und die IP-Adresse des Clients lautet 192.168.255.255. Wenn ein anderer Host mit dem Namen myhost ein Dateisystem erstellt, verweisen zwei symbolische Verknüpfungen auf den Hostnamen.


Hinweis - In NFS-Version 4 wird dieser Dämon nicht verwendet.