Funktionsweise von autofs

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:

1. Autofs fängt die Anforderung ab.

2. Autofs sendet eine Meldung an automountd, damit das betreffende Dateisystem ausgehängt wird.

3. automountd lokalisiert die Dateisysteminformationen in einer Map, erstellt die Aktivierungsknoten und führt die Einhängung aus.

4. Autofs lässt die weitere Verarbeitung der abgefangenen Anforderung zu.

5. Nach einer bestimmten Zeit der Inaktivität hängt autofs das Dateisystem aus.

Wie autofs durch das Netzwerk navigiert (Maps)

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).

Wie autofs den Navigationprozess startet (Master-Map)

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

Autofs-Einhängeprozess

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.

Einfache autofs-Einhängung

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:

1. Prüfung der Verfügbarkeit des Einhängeservice des Servers

2. 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=####    #####

Hierarchisches Einhängen

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.

---

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.

---

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

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.

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.

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.

Weitere Informationen finden Sie auf der Manpage automount(1M).

Autofs und Gewichtung

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.

Variablen in einem Map-Eintrag

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.

Maps, die sich auf andere Maps beziehen

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 

Ausführbare autofs-Maps

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

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

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.

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

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.