Teil I Netzwerkdienste - Themen
2. Verwalten von Webcache-Servern
Teil II Zugriff auf Netzwerkdateisysteme - Themen
4. Verwalten von Netzwerkdateisystemen (Übersicht)
5. Verwaltung des Netzwerkdateisystems (Aufgaben)
6. Zugreifen auf Netzwerkdateisysteme (Referenz)
Schlüsselwörter für die /etc/default/nfs-Datei
Konfigurationsdateien und nfsmapid
nfsmapid und DNS-TXT-Datensätze
Ermitteln der Domain der NFS-Version 4
Konfigurieren der Standarddomain der NFS-Version 4
mount-Optionen für NFS-Dateisysteme
Nicht dateisystemspezifische share-Optionen
NFS-spezifische share-Optionen
Einrichten von Zugriffslisten mit dem share-Befehl
Befehle zum Beheben von NFS-Problemen
Funktionsweise des NFS-Service
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
Zugriffskontrolllisten (ACLs) und nfsmapid in NFS-Version 4
Aushandlung der Dateiübertragungsgröße
Funktionsweise der Option -public und der NFS-URLs beim Einhängen
Was ist ein repliziertes Dateisystem?
Clientseitiges Failover in NFS-Version 4
Funktionsweise der NFS-Serverprotokollierung
Funktionsweise des WebNFS-Service
Funktionsweise der WebNFS-Sicherheitsaushandlung
WebNFS-Beschränkungen bei Verwendung eines Webbrowsers
Verwenden vom sicheren RPC mit NFS
Wie autofs durch das Netzwerk navigiert (Maps)
Wie autofs den Navigationprozess startet (Master-Map)
Wie autofs die nächsten schreibgeschützten Dateien für Clients auswählt (mehrere Speicherorte)
Variablen in einem Map-Eintrag
Maps, die sich auf andere Maps beziehen
Modifizieren, wie autofs im Netzwerk navigiert (Modifizieren von Maps)
Standardmäßiges Verhalten von autofs bei Verwendung von Name Services
Teil III SLP (Service Location Protocol) - Themen
8. Planen und Aktivieren von SLP (Aufgaben)
9. Verwalten von SLP (Aufgaben)
10. Integrieren von veralteten Services
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)
25. Verwalten von UUCP (Aufgaben)
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
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:
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:
-T aktiviert die Ablaufverfolgung.
-n deaktiviert Suchvorgänge auf allen autofs-Knoten.
-v protokolliert alle Statusmeldungen auf der Konsole.
-D name=value ersetzt value für die Variable der automount-Map, die durch name angegeben ist.
Der Standardwert für die automount-Map ist /etc/auto_master. Verwenden Sie die Option -T zur Fehlerbehebung.
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.
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.
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).
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.
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.
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:
Wenn der Benutzer nicht auf dem Server vorhanden ist, lehnt der Server den Remote-Prozeduraufruf (RPC) ab und gibt eine Fehlermeldung an den Client zurück. Dies geschieht selbst dann, wenn es sich um dieselbe Domainkonfiguration der NFS-Version 4 handelt. Dadurch werden die Vorgänge begrenzt, die vom Remote-Benutzer ausgeführt werden können.
Wenn der Benutzer sowohl auf dem Client als auch auf dem Server vorhanden ist, aber die Domains nicht übereinstimmen, lehnt der Server die Attributänderungsvorgänge (wie beispielsweise SETATTR) ab, die von ihm verlangen, die eingehende Benutzer-Zeichenfolge einem Ganzzahlwert zuzuordnen, der vom zugrunde liegenden Dateisystem verstanden werden kann. Damit die Clients und Server der NFS-Version 4 richtig funktionieren, müssen ihre Domains der NFS-Version 4, d. h. der Teil der Zeichenfolge hinter dem @-Zeichen, übereinstimmen.
Wenn der Client der NFS-Version 4 keinen Benutzer- oder Gruppennamen des Servers erkennt, kann der Client die Zeichenfolge nicht der entsprechenden eindeutigen ID zuordnen, die ein Ganzzahlwert ist. In solch einem Fall ordnet der Client die eingehende Benutzer- oder Gruppenzeichenfolge dem Benutzer nobody zu. Diese Zuordnung zu nobody führt zu diversen Problemen für verschiedene Anwendungen. Was die Funktionen von NFS-Version 4 anbetrifft, so können Vorgänge zum Modifizieren von Dateiattributen nicht erfolgreich ausgeführt werden.
Sie können den Domainnamen für die Clients und Server mithilfe des Befehls sharectl und mit der folgenden Option ändern.
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.
Im Folgenden wird beschrieben, wie der Dämon nfsmapid die Dateien /etc/nsswitch.conf und /etc/resolv.conf verwendet:
nfsmapid verwendet standardmäßige Funktionen der C-Bibliothek, um Passwort- und Gruppeninformationen von Backend-Name Services anzufordern. Diese Name Services werden durch Einstellungen in der /etc/nsswitch.conf-Datei gesteuert. Änderungen an der nsswitch.conf-Datei wirken sich auf nfsmapid -Vorgänge aus. Weitere Informationen zur nsswitch.conf-Datei finden Sie auf der Manpage nsswitch.conf(4).
Um sicherzustellen, dass die Clients der NFS-Version 4 Dateisysteme von verschiedenen Domains einhängen können, verwendet nfsmapid die Konfiguration des DNS-TXT-Ressourcendatensatzes (RR), _nfsv4idmapdomain . Weitere Informationen zum Konfigurieren des _nfsv4idmapdomain -Ressourcendatensatzes finden Sie unter nfsmapid und DNS-TXT-Datensätze. Beachten Sie zudem Folgendes:
Der DNS-TXT-Ressourcendatensatz muss unter Angabe der entsprechenden Domaininformationen explizit auf dem DNS-Server konfiguriert sein.
Die /etc/resolv.conf-Datei sollte mit den entsprechenden Parametern konfiguriert werden, um dem resolver zu ermöglichen, den DNS-Server zu finden und nach den Textdatensätzen für die Domains der NFS-Version 4 des Clients und des Servers zu suchen.
Weitere Informationen finden Sie hier:
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:
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.
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.
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
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).
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.
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.
Um die Domain der NFS-Version 4 anhand eines DNS-TXT-Ressourcendatensatz zu ermitteln, verwenden Sie entweder den Befehl nslookup oder den Befehl dig:
Es folgt eine Beispielausgabe für den Befehl nslookup:
# nslookup -q=txt _nfsv4idmapdomain Server: 10.255.255.255 Address: 10.255.255.255#53 _nfsv4idmapdomain.example.company.com text = "company.com"
Dies ist eine Beispielausgabe für den Befehl dig:
# dig +domain=example.company.com -t TXT _nfsv4idmapdomain ... ;; QUESTION SECTION: ;_nfsv4idmapdomain.example.company.com. IN TXT ;; ANSWER SECTION: _nfsv4idmapdomain.example.company.com. 21600 IN TXT "company.com" ;; AUTHORITY SECTION: ...
Weitere Informationen zum Einrichten eines DNS-TXT-Ressourcendatensatzes finden Sie unter nfsmapid und DNS-TXT-Datensätze.
Wenn Ihr Netzwerk nicht mit einem DNS-TXT-Ressourcendatensatz der NFS-Version 4 eingerichtet ist, verwenden Sie den folgenden Befehl, um Ihre Domain der NFS-Version 4 anhand des DNS-Domainnamens zu ermitteln:
# egrep domain /etc/resolv.conf domain example.company.com
Wenn die Datei /etc/resolv.conf nicht für die Bereitstellung eines DNS-Domainnamens für den Client konfiguriert ist, verwenden Sie den folgenden Befehl, um die Domain anhand der Domainkonfiguration der NFS-Version 4 des Netzwerks zu ermitteln:
# cat /var/run/nfs4_domain company.com
Wenn Sie einen anderen Naming Service wie beispielsweise NIS verwenden, verwenden Sie den folgenden Befehl, um die Domain für den Naming Service zu ermitteln, der für Ihr Netzwerk konfiguriert ist:
# domainname it.example.company.com
Weitere Informationen finden Sie auf den folgenden Manpages :
In diesem Abschnitt wird beschrieben, wie das Netzwerk die entsprechende Standarddomain abruft:
Informationen zu den neuesten Versionen finden Sie unter Konfigurieren der Standarddomain der NFS-Version 4.
Informationen zur Anfangsversion von Solaris 10 finden Sie unter Konfigurieren einer Standarddomain der NFS-Version 4 mit Solaris 10.
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:
Der Befehl sysidtool schließt das Programm sysidnfs4 ein. Das Programm wird während des Installationsprozesses ausgeführt, um festzustellen, ob eine Domain der NFS-Version 4 für das Netzwerk konfiguriert wurde. Weitere Informationen finden Sie auf den Manpages sysidtool(1M) und sysidnfs4(1M).
Die sysidcfg-Datei hat ein neues Schlüsselwort, nfs4_domain. Dieses Schlüsselwort kann verwendet werden, um die Domain der NFS-Version 4 zu definieren. Beachten Sie, dass auch andere Schlüsselwörter in der sysidcfg-Datei definiert werden können. Weitere Informationen finden Sie auf der Manpage sysidcfg(4).
Im Folgenden wird die Funktionsweise beschrieben:
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.
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:
Das im Beispiel angeführte JumpStart-Skript set_nfs4_domain der Anfangsversion von Solaris 10 wird nicht mehr benötigt. Von einer weiteren Verwendung wird abgeraten.
Die /etc/.NFS4inst_state.domain-Datei, die durch die frühere Implementierung des sysidnfs4-Programms erstellt wurde, wird 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:
Oracle Solaris 10 9/10 Installationshandbuch: Grundinstallationen
Oracle Solaris 10 9/10 Installationshandbuch: Netzwerkbasierte Installation
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.
Weitere Informationen zu nfsmapid finden Sie hier:
Manpage nfsmapid(1M)
Manpage nfs(4)
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.