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
Zusätzliche Informationen zu nfsmapid
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
Autofs ist ein clientseitiger Service, der zum automatischen Einhängen von Dateisystemen dient. Es folgen die Komponenten, die beim automatischen Einhängen zusammenwirken:
automount-Befehl
autofs-Dateisystem
automountd-Dämon
Der automount-Service, svc:/system/filesystem/autofs , der während des Systemstarts aufgerufen wird, liest die Master-Map-Datei auto_master, um eine anfängliche Gruppe von autofs-Einhängungen zu erstellen. Diese autofs-Einhängungen werden beim Start nicht automatisch eingehängt. Vielmehr sind diese Einhängungen Punkte, unter denen Dateisysteme zu späteren Zeitpunkten eingehängt werden. Diese Punkte werden auch als Aktivierungsknoten bezeichnet.
Nachdem die autofs-Einhängungen eingerichtet wurden, können unter diesen Einhängungen weitere Dateisysteme eingehängt werden. Wenn autofs beispielsweise eine Anforderung zum Zugriff auf ein Dateisystem erhält, das derzeit nicht eingehängt ist, ruft autofs den Dämon automountd auf, der dann das betreffende Dateisystem einhängt.
Nach dem anfänglichen Einhängen der autofs-Einhängepunkte wird der Befehl automount verwendet, um die autofs-Einhängepunkte nach Bedarf zu aktualisieren. Mithilfe des Befehls wird die Liste der Einhängungen in der auto_master-Map mit der Liste der eingehängten Dateisysteme in der Einhängetabellendatei /etc/mnttab (vormals /etc/mtab) verglichen. automount nimmt dann die entsprechenden Änderungen vor. Dieser Vorgang erlaubt Systemadministratoren, Einhängeinformationen in auto_master zu ändern und diese Änderungen in autofs-Vorgängen verwenden zu lassen, ohne den autofs-Dämon zu stoppen und neu zu starten. Nachdem das Dateisystem eingehängt wurde, ist beim zweiten Zugriff erst dann ein Eingreifen von automountd erforderlich, wenn das Dateisystem automatisch ausgehängt wurde.
Im Gegensatz zum Befehl mount liest automount nicht die /etc/vfstab-Datei (die sich auf die einzelnen Computer bezieht), damit aufgelistete Dateisysteme eingehängt werden können. Der Befehl automount wird durch den Namespace oder lokale Dateien innerhalb einer Domain und auf Computern gesteuert.
Es folgt eine vereinfachte Beschreibung der Funktionsweise von autofs.
Der automount-Dämon automountd wird während des Boot-Vorgangs durch den Service svc:/system/filesystem/autofs gestartet. Siehe dazu Abbildung 6-3. Dieser Service führt auch den Befehl automount aus, der die Master-Map liest und die autofs-Einhängepunkte installiert. Weitere Informationen finden Sie unter Wie autofs den Navigationprozess startet (Master-Map).
Abbildung 6-3 Der svc:/system/filesystem/autofs-Service startet automount.
Autofs ist ein Kernel-Dateisystem zur Unterstützung des automatischen Ein- und Aushängens.
Wenn eine Anforderung gesendet wird, um auf ein Dateisystem an einem autofs-Einhängepunkt zuzugreifen, geschieht Folgendes:
Autofs fängt die Anforderung ab.
Autofs sendet eine Meldung an automountd, damit das betreffende Dateisystem ausgehängt wird.
automountd lokalisiert die Dateisysteminformationen in einer Map, erstellt die Aktivierungsknoten und führt die Einhängung aus.
Autofs lässt die weitere Verarbeitung der abgefangenen Anforderung zu.
Nach einer bestimmten Zeit der Inaktivität hängt autofs das Dateisystem aus.
Hinweis - Einhängungen, die durch den autofs-Service gesteuert werden, sollten nicht manuell ein- oder ausgehängt werden. Selbst wenn dies erfolgreich durchgeführt werden kann, wird nicht vom autofs-Service geprüft, ob das betreffende Objekt ausgehängt wurde, woraus Inkonsistenzen resultieren können. Durch einen Neustart werden alle autofs-Einhängepunkte entfernt.
Autofs durchsucht eine Reihe von Maps, um durch das Netzwerk zu navigieren. Maps sind Dateien, die Informationen wie beispielsweise die Passworteinträge aller Benutzer in einem Netzwerk oder die Namen aller Hostcomputer in einem Netzwerk enthalten. Die Maps enthalten netzwerkübergreifende Entsprechungen der UNIX-Administrationsdateien. Maps sind lokal oder über einen Netzwerk-Name Service wie NIS oder NIS+ verfügbar. Lesen Sie dazu Modifizieren, wie autofs im Netzwerk navigiert (Modifizieren von Maps).
Mit dem Befehl automount wird die Master-Map beim Systemstart gelesen. Jeder Eintrag in der Master-Map ist der Name einer direkten oder indirekten Map, eines Pfads oder von Einhängeoptionen (siehe Abbildung 6-4). Die Reihenfolge der Einträge ist nicht von Bedeutung. automount vergleicht die Einträge in der Master-Map mit den Einträgen in der Einhängetabelle, um eine aktuelle Liste zu erstellen.
Abbildung 6-4 Navigation durch die Master-Map
Wie der autofs-Service reagiert, wenn eine Einhängungsanforderung ausgelöst wird, hängt davon ab, wie die Automounter-Maps konfiguriert sind. Der Einhängeprozess ist in der Regel für alle Einhängepunkte der gleiche. Jedoch ändert sich das Endergebnis in Abhängigkeit vom angegebenen Einhängepunkt und von der Komplexität der Maps. Der Einhängevorgang umfasst die Erstellung von Aktivierungsknoten.
Zur Veranschaulichung des autofs-Einhängeprozesses wird angenommen, dass die folgenden Dateien installiert sind.
$ cat /etc/auto_master # Master map for automounter # +auto_master /net -hosts -nosuid,nobrowse /home auto_home -nobrowse /share auto_share $ cat /etc/auto_share # share directory map for automounter # ws gumbo:/export/share/ws
Wenn auf das /share-Verzeichnis zugegriffen wird, erstellt der autofs-Service einen Aktivierungsknoten für /share/ws, ein Eintrag in /etc/mnttab, der wie folgt aussehen kann:
-hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=###
Wenn auf das /share/ws-Verzeichnis zugegriffen wird, führt der autofs-Service folgende Schritte aus, um den Prozess durchzuführen:
Prüfung der Verfügbarkeit des Einhängeservice des Servers
Einhängen des angeforderten Dateisystems unter /share. Jetzt enthält die /etc/mnttab-Datei die folgenden Einträge:
-hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=### gumbo:/export/share/ws /share/ws nfs nosuid,dev=#### #####
Wenn in den Automounter-Dateien mehrere Schichten definiert sind, wird der Einhängeprozess komplexer. Angenommen, Sie fügen Folgendes in die /etc/auto_shared -Datei aus dem vorangegangenen Beispiel ein:
# share directory map for automounter # ws / gumbo:/export/share/ws /usr gumbo:/export/share/ws/usr
Der Einhängeprozess ist im Wesentlichen derselbe wie im vorangegangenen Beispiel, wenn auf den /share/ws-Einhängepunkt zugegriffen wird. Außerdem wird ein Aktivierungsknoten für die nächste Ebene (/usr) im /share/ws-Dateisystem erstellt, sodass die nächste Ebene eingehängt werden kann, wenn auf sie zugegriffen wird. In diesem Beispiel muss /export/share/ws/usr auf dem NFS-Server vorhanden sein, damit der Aktivierungsknoten erstellt werden kann.
Achtung - Verwenden Sie nicht die Option -soft, wenn Sie hierarchische Ebenen angeben. Eine Erläuterung dieser Beschränkung finden Sie unter Autofs-Aushängung. |
Das Aushängen nach einer bestimmten Leerlaufzeit wird von unten nach oben durchgeführt (in umgekehrter Reihenfolge des Einhängens). Wenn eines der Verzeichnisse auf einer höheren Ebene der Hierarchie verwendet wird, werden nur die Dateisysteme unter dem betreffenden Verzeichnis ausgehängt. Während des Aushängeprozesses werden Aktivierungsknoten entfernt, wonach das Dateisystem ausgehängt wird. Wenn das Dateisystem beschäftigt ist, schlägt das Aushängen fehl und die Aktivierungsknoten werden erneut installiert.
Achtung - Verwenden Sie nicht die Option -soft, wenn Sie hierarchische Ebenen angeben. Wenn die Option -soft verwendet wird, können Anforderungen zur erneuten Installation der Aktivierungsknoten eine Zeitüberschreitung auslösen. Wenn die Aktivierungsknoten nicht installiert werden können, ist kein Zugriff auf die nächste Ebene der Einhängungen möglich. Die einzige Möglichkeit, dieses Problem zu beheben, besteht darin, alle Komponenten in der Hierarchie vom Automounter aushängen zu lassen. Der Automounter kann das Aushängen durchführen, indem er entweder darauf wartet, dass die Dateisysteme automatisch ausgehängt werden, oder indem er das System neu startet. |
Die direkte Beispiel-Map enthält Folgendes:
/usr/local -ro \ /bin ivy:/export/local/sun4\ /share ivy:/export/local/share\ /src ivy:/export/local/src /usr/man -ro oak:/usr/man \ rose:/usr/man \ willow:/usr/man /usr/games -ro peach:/usr/games /usr/spool/news -ro pine:/usr/spool/news \ willow:/var/spool/news
Die Einhängepunkte /usr/man und /usr/spool/news listen mehrere Speicherorte auf: drei für den ersten Einhängepunkt und zwei für den zweiten Einhängepunkt. Jeder der replizierten Speicherorte kann denselben Service für jeden Benutzer bereitstellen. Dieses Verfahren ist nur dann fehleranfällig, wenn Sie ein schreibgeschütztes Dateisystem einhängen, da Sie die Kontrolle über die Speicherorte der Dateien haben müssen, die Sie beschreiben oder modifizieren. Es macht keinen Sinn, Dateien auf einem Server zu modifizieren und kurze Zeit später dieselben Dateien auf einem anderen Server erneut zu modifizieren. Der Vorteil ist der, dass der beste verfügbare Server automatisch verwendet wird und kein Handeln des Benutzers erforderlich ist.
Wenn die Dateisysteme als Replikationen konfiguriert sind (siehe Was ist ein repliziertes Dateisystem?), haben die Clients den Vorteil, das Failover verwenden zu können. Beim Failover wird nicht nur automatisch der beste Server bestimmt: Wenn dieser Server ausfällt, verwendet der Client automatisch den nächstbesten Server.
Ein Beispiel für die Konfiguration eines effizienten Dateisystems als Replikation sind Manpages. In einem großen Netzwerk können mehrere Server die aktuellen Manpages exportieren. Von welchem Server aus Sie die Manpages einhängen, spielt keine Rolle, wenn der Server in Betrieb ist und seine Dateisysteme exportiert. Im vorangegangenen Beispiel werden mehrere Einhängepositionen in einer Liste von Einhängepositionen in einem Map-Eintrag definiert.
/usr/man -ro oak:/usr/man rose:/usr/man willow:/usr/man
In diesem Beispiel können Sie die Manpages von den Servern oak, rose oder willow einhängen. Welcher Server der beste ist, hängt von verschiedenen Faktoren ab, darunter folgende:
Die Anzahl von Servern, die eine bestimmte NFS-Protokollebene unterstützen
Die Nähe des Servers
Die Gewichtung
Während des Sortierprozesses werden die Server gezählt, die jede Version des NFS-Protokolls unterstützen. Die Version des Protokolls, die von den meisten Servern unterstützt wird, wird als standardmäßiges Protokoll verwendet. Dadurch wird dem Client die maximale Auswahl an Servern zur Verfügung gestellt.
Nachdem der größte Teil der Server mit derselben Protokollversion gefunden wurde, wird die Liste dieser Server nach Nähe sortiert. Zur Bestimmung der Nähe werden IPv4-Adressen untersucht. Die IPv4-Adressen zeigen an, welche Server sich in jedem Teilnetz befinden. Servern in einem lokalen Teilnetz wird der Vorzug vor Servern in einem Remote-Teilnetz gegeben. Durch die bevorzugte Verwendung des nächsten Servers werden Latenz und Netzwerkverkehr verringert.
Hinweis - Die Nähe kann nicht für Replikationen bestimmt werden, die IPv6-Adressen verwenden.
Abbildung 6-5 zeigt die Servernähe.
Abbildung 6-5 Servernähe
Wenn mehrere Server, die dasselbe Protokoll unterstützen, sich im selben Teilnetz befinden, wird die Dauer zur Herstellung der Verbindung mit jedem Server ermittelt und es wird der schnellste Server verwendet. Das Sortieren kann auch durch die Gewichtung beeinflusst werden (siehe Autofs und Gewichtung).
Wenn beispielsweise mehr Server der Version 4 zur Verfügung stehen, wird Version 4 als standardmäßiges Protokoll verwendet. Der Sortierprozess ist nun jedoch komplexer. Es folgen einige Beispiele zur Funktionsweise des Sortierprozesses:
Servern in einem lokalen Teilnetz wird der Vorzug vor Servern in einem Remote-Teilnetz gegeben. Wenn sich also ein Server der Version 3 im lokalen Teilnetz befindet und sich der nächste Server der Version 4 in einem Remote-Teilnetz befindet, wird dem Server der Version 3 der Vorzug gegeben. Wenn zum lokalen Teilnetz Server der Version 2 gehören, erhalten diese den Vorzug vor den Servern der Version 3 und 4 in Remote-Teilnetzen.
Wenn zum lokalen Teilnetz Server der Version 2, 3 und 4 gehören, ist eine weitere Sortierung erforderlich. Der Automounter zieht die höchste Version im lokalen Teilnetz vor. In diesem Fall ist dies Version 4. Wenn im lokalen Teilnetz jedoch mehr Server der Version 3 oder der Version 2 als Server der Version 4 vorhanden sind, wählt der Automounter die nächstniedrige Version im Verhältnis zur höchsten Version. Wenn beispielsweise im lokalen Teilnetz drei Server der Version 4, drei Server der Version 3 und zehn Server der Version 2 enthalten sind, wird ein Server der Version 3 gewählt.
Wenn im lokalen Teilnetz mehrere Server der Version 2 und 3 enthalten sind, sucht der Automounter zunächst nach der höchsten Version. Dann zählt der Automounter die Server, die die einzelnen Versionen ausführen. Wenn die höchste Version von den meisten Servern ausgeführt wird, wird die höchste Version gewählt. Wenn eine niedrigere Version von mehr Servern ausgeführt wird, wählt der Automounter ausgehend von der höchsten Version die nächstniedrige Version. Wenn beispielsweise mehr Server der Version 2 als Server der Version 3 im lokalen Teilnetz vorhanden sind, wird ein Server der Version 2 gewählt.
Hinweis - Die Gewichtung wird auch durch die Werte der Schlüsselwörter in der /etc/default/nfs-Datei beeinflusst. Insbesondere können manche Versionen durch die Werte für NFS_SERVER_VERSMIN, NFS_CLIENT_VERSMIN, NFS_SERVER_VERSMAX und NFS_CLIENT_VERSMAX aus dem Sortierprozess ausgeschlossen werden. Weitere Informationen zu diesen Schlüsselwörtern finden Sie unter Schlüsselwörter für die /etc/default/nfs-Datei.
Bei einem Failover wird der Sortierprozess zum Zeitpunkt des Einhängens überprüft, wenn ein Server ausgewählt wird. In einer Umgebung, in der einzelne Server ihre Dateisysteme nicht temporär exportieren können, eignet sich der Einsatz von mehreren Speicherorten.
Das Failover ist vor allem in einem großen Netzwerk mit vielen Teilnetzen sinnvoll. Autofs wählt einen geeigneten Server aus und kann den NFS-Netzwerkverkehr auf ein Segment des lokalen Netzwerks beschränken. Wenn ein Server mehrere Netzwerkschnittstellen hat, können Sie den Hostnamen auflisten, der jeder Netzwerkschnittstelle zugeordnet ist, als ob die Schnittstelle ein separater Server wäre. Autofs wählt die Schnittstelle, die dem Client am nächsten ist.
Hinweis - Bei manuellen Einhängungen werden weder die Gewichtung noch die Nähe geprüft. Mit dem Befehl mount werden die von links nach rechts aufgelisteten Server priorisiert.
Weitere Informationen finden Sie auf der Manpage automount(1M).
Sie können die Auswahl von Servern mit der gleichen Nähe beeinflussen, indem Sie einen Gewichtungswert in die autofs-Map einfügen. Beispiel:
/usr/man -ro oak,rose(1),willow(2):/usr/man
Die in Klammern eingeschlossenen Werte zeigen die Gewichtung an. Server ohne Gewichtung haben den Wert null und werden darum mit größter Wahrscheinlichkeit ausgewählt. Je höher der Gewichtungswert, desto geringer die Wahrscheinlichkeit, dass der Server ausgewählt wird.
Hinweis - Alle anderen Serverauswahlfaktoren sind wichtiger als die Gewichtung. Die Gewichtung wird nur dann berücksichtigt, wenn aus Servern mit der gleichen Netzwerknähe ausgewählt wird.
Sie können eine clientspezifische Variable erstellen, indem Sie ein Dollarzeichen ($) vor den Namen der Variablen setzen. Mithilfe der Variablen können Sie verschiedene Architekturtypen bereitstellen, die auf den gleichen Dateisystemspeicherort zugreifen. Sie können auch geschweifte Klammern verwenden, um den Namen von angehängten Buchstaben oder Ziffern abzugrenzen. In Tabelle 6-2 werden die vordefinierten Map-Variablen dargestellt.
Tabelle 6-2 Vordefinierte Map-Variablen
|
Sie können Variablen überall auf der Eintragszeile verwenden, jedoch nicht als Schlüssel. Sie verwenden beispielsweise einen Dateiserver, der Binärwerte für SPARC- und x86-Architekturen aus /usr/local/bin/sparc und /usr/local/bin/x86 exportiert. Die Clients können Einhängungen über einen Map-Eintrag wie den folgenden ausführen:
/usr/local/bin -ro server:/usr/local/bin/$CPU
Jetzt gilt der auf die Clients bezogene Eintrag für alle Architekturen.
Hinweis - Die meisten Anwendungen, die für eine der sun4-Architekturen entwickelt wurden, können auf allen sun4-Plattformen ausgeführt werden. Die -ARCH-Variable ist für sun4 festcodiert.
Ein in einer Datei-Map verwendeter Map-Eintrag +mapname bewirkt, dass automount die angegebene Map liest, als wäre sie in der aktuellen Datei enthalten. Wenn vor mapname kein Schrägstrich steht, behandelt autofs den Map-Namen als Zeichenfolge und verwendet die Name Service Switch-Richtlinie, um nach dem Map-Namen zu suchen. Wenn der Pfadname ein absoluter Pfadname ist, sucht automount in einer lokalen Map, um den Namen zu finden. Wenn die Map mit einem Bindestrich (-) beginnt, fragt automount die entsprechende integrierte Map wie beispielsweise hosts ab.
Diese Name Service Switch-Datei enthält einen Eintrag für autofs mit der Bezeichnung automount, in dem die Reihenfolge angegeben ist, in der nach dem Name Service gesucht wurde. Die folgende Datei ist ein Beispiel für eine Name Service Switch-Datei:
# # /etc/nsswitch.nis: # # An example file that could be copied over to /etc/nsswitch.conf; # it uses NIS (YP) in conjunction with files. # # "hosts:" and "services:" in this file are used only if the /etc/netconfig # file contains "switch.so" as a nametoaddr library for "inet" transports. # the following two lines obviate the "+" entry in /etc/passwd and /etc/group. passwd: files nis group: files nis # consult /etc "files" only if nis is down. hosts: nis [NOTFOUND=return] files networks: nis [NOTFOUND=return] files protocols: nis [NOTFOUND=return] files rpc: nis [NOTFOUND=return] files ethers: nis [NOTFOUND=return] files netmasks: nis [NOTFOUND=return] files bootparams: nis [NOTFOUND=return] files publickey: nis [NOTFOUND=return] files netgroup: nis automount: files nis aliases: files nis # for efficient getservbyname() avoid nis services: files nis
In diesem Beispiel werden die lokalen Maps vor den NIS-Maps durchsucht. Darum können in Ihrer lokalen /etc/auto_home-Map einige Einträge für die Home-Verzeichnisse enthalten sein, auf die am häufigsten zugegriffen wird. Sie können dann den Switch verwenden, um zur NIS-Map zurückzukehren, um auf die anderen Einträge zuzugreifen.
bill cs.csc.edu:/export/home/bill bonny cs.csc.edu:/export/home/bonny
Wenn nach der Abfrage der einbezogenen Map keine Übereinstimmung gefunden wird, fährt automount mit der Abfrage der aktuellen Map fort. Darum können Sie mehrere Einträge nach einem +-Eintrag einfügen.
bill cs.csc.edu:/export/home/bill bonny cs.csc.edu:/export/home/bonny +auto_home
Die einbezogene Map kann eine lokale Datei oder eine integrierte Map sein. Beachten Sie, dass nur in lokalen Dateien +-Einträge enthalten sein können.
+auto_home_finance # NIS+ map +auto_home_sales # NIS+ map +auto_home_engineering # NIS+ map +/etc/auto_mystuff # local map +auto_home # NIS+ map +-hosts # built-in hosts map
Sie können eine autofs-Map erstellen, mit deren Hilfe Befehle zum Generieren der autofs-Einhängepunkte ausgeführt werden. Sie können aus der Verwendung einer ausführbaren autofs-Map Nutzen ziehen, wenn Sie die autofs-Struktur aus einer Datenbank oder einer unstrukturierten Datei erstellen müssen. Der Nachteil der Verwendung einer ausführbaren Map besteht darin, dass die Map auf jedem Host installiert werden muss. Eine ausführbare Map kann weder in den NIS- noch in den NIS+-Name Service einbezogen werden.
Die ausführbare Map muss einen Eintrag in der auto_master-Datei haben.
/execute auto_execute
Es folgt ein Beispiel einer ausführbaren Map:
#!/bin/ksh # # executable map for autofs # case $1 in src) echo '-nosuid,hard bee:/export1' ;; esac
Damit dieses Beispiel funktioniert, muss die Datei als /etc/auto_execute installiert sein, und das ausführbare Bit muss gesetzt sein. Setzen Sie die Berechtigungen auf 744. In diesem Fall bewirkt die Ausführung des Befehls, dass das /export1 -Dateisystem von bee eingehängt wird:
% ls /execute/src
Sie können Einträge in Maps modifizieren, löschen oder hinzufügen, um die Anforderungen in Ihrer Umgebung zu erfüllen. Da sich der Speicherort von Anwendungen und anderen Dateisystemen, die von Benutzern benötigt werden, ändert, müssen diese Änderungen in den Maps reflektiert werden. Sie können autofs-Maps jederzeit modifizieren. Ob Ihre Modifizierungen beim nächsten Einhängen eines Dateisystems durch automountd wirksam sind, hängt davon ab, welche Map Sie modifizieren und welcher Art die von Ihnen vorgenommenen Modifizierungen sind.
Während des Boot-Vorgangs wird autofs vom Service svc:/system/filesystem/autofs aufgerufen. Dann prüft autofs die Master-Map auto_master. Autofs unterliegt den nachstehend erläuterten Regeln.
Autofs verwendet den Name Service, der im automount-Eintrag der /etc/nsswitch.conf-Datei angegeben ist. Wenn NIS+ angegeben ist, aber nicht die lokalen Dateien oder NIS, werden alle Map-Namen in der vorliegenden Form verwendet. Wenn NIS angegeben ist und autofs keine passende Map, aber einen Map-Namen findet, der einen oder mehrere Unterstriche enthält, werden die Unterstriche in Punkte umgewandelt. Durch diese Änderung können die alten NIS-Dateinamen verwendet werden. Anschließend prüft autofs erneut die Map (siehe Abbildung 6-6).
Abbildung 6-6 Wie autofs den Name Service verwendet
Die Bildschirmaktivität in dieser Sitzung sieht wie im folgenden Beispiel aus:
$ grep /home /etc/auto_master /home auto_home $ ypmatch brent auto_home Can't match key brent in map auto_home. Reason: no such map in server's domain. $ ypmatch brent auto.home diskus:/export/home/diskus1/&
Wenn Dateien als Name Service ausgewählt werden, wird vorausgesetzt, dass es sich bei allen Maps um lokale Dateien im /etc-Verzeichnis handelt. Autofs interpretiert einen mit einem Schrägstrich (/) beginnenden Map-Namen als lokal, ungeachtet des von autofs verwendeten Name Service.