| orm@doc-tcpip.org | Erstellt: April 2000 - Letzte Modifikation: Juli 2004 |
Der Automounter ist ein Deamon, der den Umgang mit NFS (Network File System) erleichtert. Möchte man per NFS auf ein von einem Server exportiertes Filesystem zugreifen, so muß dieses zuerst lokal gemountet werden. Das kann von Hand erfolgen, in größeren Umgebungen ein schwieriges Vorgehen. Zusätzlich wird ein NFS-Mount behandelt wie eine lokal installierte Platte, das System hängt, wenn der Server nicht mehr erreicht werden kann.
Der Automounter automatisiert die nötigen Mounts. Er stellt sich dem lokalen User wie ein NFS-Server dar, und überwacht ein Dummy-Verzeichnis. Stellt er in diesem Verzeichnis Aktivitäten fest, so mountet er vom entsprechenden Server ein Filesystem. Er prüft vor dem Mount die Erreichbarkeit des Servers, üerwacht die Erreichbarkeit während der Lebensdauer des Mounts und hängt den Mount nach einer Periode der Nichtbenutzung ab.
Der Automount-Deamon lebt als normaler Prozess. Er registriert sich beim Portmapper und kann dann per RPC (Remote Procedure Call) kontaktiert werden.
elazul# rpcinfo
program version netid address service owner
....
300019 1 tcp 0.0.0.0.3.255 amd superuser
300019 1 udp 0.0.0.0.3.253 amd superuser
Gegenüber dem lokalen System sieht der Automounter
aus wie ein NFS-Server, er wird also über einen
NFS-Client angesprochen. Zusätzlich ist der
Automounter in der Lage, mit dem Kernel per System
Call zu kommunizieren.
______________ ----------------
|User Prozess| | AMD | (NFS Server)
-------------- ----------------
| ^ | ^ | ^
System Calls 1 12 | | | | Remote Procedure
| | 4 9 10 3 Calls (RPC)
User Space | | | | | |
----------------|---|--------------------------------
Kernel Space | | | | | |
| | | | | |
------------------------------- | |
| VFS | | |
------------------------------- | |
| ^ | ^ | |
5 8 2 11 | |
| | ----------------
UFS, NFS, EXT2 ... | NFS Client |
| | ----------------
6 7
| |
Platte, CDROM ...
Öffnet ein User-Prozess ein File in einem Filesystem, das per Automounter gemountet wird, ist das für den User-Prozess eine völlig normale Anfrage per System-Call an das VFS (Virtuel File System) des Rechners. Der User Prozess sieht nur das VFS.
Der System Call löst eine Trap aus, der Kernel unterbricht laufende Prozesse und führt den System Call aus. Das VFS erkennt, das es sich um einen NFS-Mount handelt und kontaktiert per NFS-Client den definierten Server - hier der Automounter. Das ist ein LOOKUP-Request. Der Automounter vergleicht das angefragte Verzeichnis mit den konfigurierten Keys und setzt den Mount den Einstellungen entsprechend auf. Vorher prüft der Automounter die Erreichbarkeit des wirklichen NFS-Servers und übermittelt dann das Mount-Kommando an den Kernel. Dabei mountet der Automounter in ein Verzeichnis, das er kontrolliert.
Das Mount-Kommando ist wieder ein System-Call, den der Kernel abarbeitet. Wenn der Mount erfolgt ist, also ein Pfad für den Zugriff auf das gewünschte File-System existiert, erfolgt eine positive Rückmeldung an den automounter, der dann per RPC dem NFS-Client mitteilt, daß der Mount steht. Der Automounter übermittelt dazu einen symbolischen Link, der die Pfadangabe des Clients mit dem effektiven Mountpoint verknüpft. Der User-Prozess kann jetzt über VFS - NFS-Client - NFS-Server auf das gewünschte File-System zugreifen.
Der Automounter hat mit der weiteren Datenübertragung nichts mehr zu tun - er überwacht nur den Mount sowie den Zugang zum Server und baut den Mount bei Nichtbenutzung ab. Der Zugang zum Server wird im Fall von UDP-Datagrammen mit einer speziellen NFS-Prozedur geprüft: NullProc. Diese Prozedur macht nichts, löst aber eine Eingangsbestätigung aus - der Server lebt also noch. Im Fall von NFS über TCP wird diese Prüfung nicht gemacht, man verläst sich auf die TCP-Mechanismen (Keepalive).
Automounter (wie amd etc.) sind User-Space Prozesse und müßen daher per System Calls mit dem Kernel kommunizieren sowie mit anderen Prozessen um die System-Resourcen konkurrieren.
Solcherart implementierte Dienste sind immer relativ langsam, da per Interrupt Kontext-Switches im Kernel erforderlich sind.
Daher hat SUN das AutoFS entwickelt, ein Hilfs-File System. Alle zeitkritischen Zugriffe sind damit in den Kernel verlagert und laufen dort als Kernelprozesse entsprechend schneller ab.
Hier wird der Automounter amd eingesetzt. Das ist ein Prozess im User-Space, AutoFS wird bei der Standard-Installation nicht eingesetzt.
Möchte man nur das vorhandene CDROM Laufwerk automatisch mounten, so benötigt man trotzdem einige NFS Teile (den Portmapper). Damit gehen Sicherheitsrisiken einher....
Das Map-file zu diesem Zweck (/etc/amd.cdrom):
#Automount des CDRom cdrom type:=cdfs;dev:=/dev/acd0;opts:=ro
Für die weitere Konfiguration des Amd bietet sich das Konfigurationsfile /etc/amd.conf an. Der Aufruf des Amd wird dann nicht mit Optionen überfrachtet.
#Global Options [global] auto_dir = /.amd_mnt #Verzeichnis der Mounts log_file = /var/log/amd #Logfile # Pro Map (Mount) ein Eintrag - hier für das CDROM [ /auto ] map_name = /etc/amd.cdrom
Es gibt sehr viele Optionen (Man-Page des amd) - so kann man z.B. die Zeit einstellen, nach der ein nichtbenutzter Mount abgehängt wird.
Der Aufruf des amd erfolgt jetzt mit amd -F /etc/amd.conf. Das kann man aber auch weglassen, da /etc/amd.conf der Default ist.
Nach dem Start erscheint der virtuelle Mountpoint in der Ausgabe des mount-Kommandos. Als Device wird die PID des Amd-Prozesses, der Hostname und das überwachte Verzeichnis angegeben; eine deutliche Arbeitserleichterung.
/dev/ad0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad0s1d on /data (ufs, local, soft-updates) /dev/ad0s1h on /home (ufs, local, soft-updates) /dev/ad0s1f on /tmp (ufs, local, soft-updates) /dev/ad0s1g on /usr (ufs, local, soft-updates) /dev/ad0s1e on /var (ufs, local, soft-updates) procfs on /proc (procfs, local) pid594@elazul:/auto on /auto (nfs)
Wechselt man nun nach /auto, so passiert nichts. Es stehen dort auch keine Files, das Verzeichnis ist leer.
Der User muß also wissen, daß er dort nach cdrom wechseln kann - oder der Administrator muß einen symbolischen Link für /cdrom erzeugt haben: ln -s /auto/cdrom /cdrom.
Wechselt man dann /cdrom bzw. /auto/cdrom oder öffnet eine Datei in diesen Pfaden, so wird die CD gemountet. Die Ausgabe des mount-Kommandos nimmt folgende Form an:
/dev/ad0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad0s1d on /data (ufs, local, soft-updates) /dev/ad0s1h on /home (ufs, local, soft-updates) /dev/ad0s1f on /tmp (ufs, local, soft-updates) /dev/ad0s1g on /usr (ufs, local, soft-updates) /dev/ad0s1e on /var (ufs, local, soft-updates) procfs on /proc (procfs, local) pid594@elazul:/auto on /auto (nfs) /dev/acd0 on /.amd_mnt/elazul/auto/cdrom (cd9660, local, read-only)
Auf der Systemkonsole und in den Logs findet sich folgende Meldung:
Jul 16 11:50:41 elazul kernel: cd9660: Joliet Extension (Level 3)
Der Mount der CDROM ist genau nach den Angaben der Datei /etc/amd.cdrom ausgeführt worden - die Platzhalter aus der Eintrag für den Automount sind mit den definierten Optionen ersetzt.
Im Verzeichnis /auto finden sich jetzt Links zum Automountpoint .amd_mnt, andem der Mount wirklich hängt:
#ls -l /a total 1 lrwxrwxrwx 1 root wheel 24 Jul 16 11:34 cdrom -> /.amd_mnt/elazul/auto/cdrom
Bei Nichtbenutzung wird der Mount nach 2 Minuten wieder abgebaut. Dieser Wert ist einstellbar. Nichtbenutzung bedeutet, daß kein User oder Prozess eine Datei aus dem Verzeichnis offen hält. Ein einfaches "stehen" im Verzeichnis reicht schon, da dann die Datei /. des Verzeichnis offen ist.
Zum automatischen Starten des amd ohne weitere Argumente (steht ja alles in der amd.conf wird folgender Eintrag in die /etc/rc.conf gemacht:
amd_enable="YES" amd_flags="-F /etc/amd.conf"
Der Automounter amd hat einen Administrations-Client amq. Dieser ist prinzipiel ein NFS-Client, der per RPC mit dem Amd kommuniziert - allerdings mit weitreichenden Folgen.
Einen Überblick über die eingerichteten Mountpoints und die aktuellen Mounts gibt amq:
elazul# amq / root "root" elazul:(pid706) /auto toplvl /etc/amd.cdrom /auto /auto/cdrom cdfs /dev/acd0 /.amd_mnt/elazul/auto/cdrom
Die Zugriffs/NFS Statistiken für bestimmte Mounts erhält man mit Angabe des entsprechenden Mountpoints:
elazu# amq /auto/cdrom What Uid Getattr Lookup RdDir RdLnk Statfs Mounted@ /auto/cdrom 0 3 0 0 1 0 04/07/18 22:40:13
Weitere wichtige Schalter sind -v für die Startup-Messages und die Version. Der Schalter -f bringt den Amd dazu, sein Konfigurationsfile sowie die Maps neu einzulesen. Einen Mount kann man vor der Zeit mit dem Schalter -u händisch abhängen (amq -u /auto/cdrom). Es ist keine gute Idee, das normale umount-Kommando zu benutzen - jeder Automounter kommt durcheinander, weil er den Mount weiterhin als vorhanden glaubt.
Beispielfile für ein Map-file:
#Beispiel /etc/auto.home
/defaults type:=nfs; opts:=nosuid,quota,intr,rw
orm -rhost:=elbueno; rfs:=/data1/user; sublink:=${key} \
host!=${rhost}; type:= nfs \
host==${rhost}; type:= link
hugo -rfs:=/u/home; sublink:=${key} \
rhost:=elazul rhost:=dumpy rhost:=rocky \
host!=${rhost}; type:= nfs \
host==${rhost}; type:= link
Jede Zeile (Zeilen können mit einem Backslash verlängert werden) beginnt mit einem Key. Mit /defaults werden die standard Einstellungen für alle folgenden Mounts bzw. Maps gesetzt (Mount-Optionen). Der Typ des Mounts ist nfs, nosuid verhindert die Ausführung von Programmen, die das SUID-Bit (Switch User ID) gesetzt haben. Die Option quota aktiviert den Quota-Support für das NFS gemountete FS, mit intr sorgt man dafür, daß der Mount mit CTRL C unterbrochen werden kann - sehr praktisch bei einem hängenden Mount. Lesen und Schreiben bzw. nur Lesen läßt man mit den Optionen rw bzw. ro zu. Das Minus-Zeichen (-) kennzeichnet Optionen, die für diesen Eintrag gelten. Diese Optionen haben Priorität gegenüber den Defaults. Der Name des Eintrags (orm) ist der Key. rhost zeigt den Server, der das rfs, das remote Filesystem, exportiert. Die sublink Option weist darauf hin, daß /data1/user/orm kein eigenes FS ist. Gemountet wird effektiv also /data1/user. Definiert man mehrere rhost-Einträge, so versucht Amd alle Server und mountet dann vom Schnellsten. Die host!= Zeile zeigt an, was getan wird, wenn der lokale Hostname nicht der Name des entfernten Hosts (rhost) ist. Im zweiten Fall (host==) ist man auf der Maschine, die als Server exportiert - daher wird das FS direkt gemountet (Typ link).
AIX nutzt das AutoFS. Es wird zwischen direkten und indirekten Mounte unterschieden. Beim direkten Mount wird in der Datei /etc/auto_master geschaut, und dann direkt das angegebene File analysiert und ausgeführt (mit den entsprechenden Pfadangaben). Im Fall des indirekten Mounts wird das in auto_master angegebene Verzeichnis als Ausgangspunkt für die relativen Pfade (/etc/auto.indirect) benutzt.
%cat auto_master /- /etc/auto.direct /auto/mnt/ /etc/auto.indirect
Die Map-Files:
%cat auto.direct /autofs/tmp_nim -rw nimmaster:/tmp /autofs/intern -ro cristina:/data/crypto /autofs/cdrom -fstype=cdrfs,ro :/dev/cd0 /autofs/testy -ro cristina:/orm/Tips
%cat auto.indirect work -rw kawasaki:/u/orm/work src -rw pinocchio:/home/code
Nach dem Starten des AutoFS bzw. Automounters wird also das Verzeichnis /autofs und /auto/mnt überwacht. Wird eines der Verzeichnisse angesprochen, so werden die entsprechenden Mounts ausgeführt.
Gestartet wird AutoFS mit einem Skript:
/usr/sbin/automount
Das ist ein Skript, mit dem wahlweise der
alte, nicht-AutoFS Automounter oder der neue
AutoFS Automounter gestartet werden kann.
Im Fall des AutoFS wird die Binary
/usr/sbin/autofsmount gestartet, sonst
/usr/sbin/compat_automount.
Dieses Skript dient als Administrations-Werkzeug für AutoFS. Starten und Stoppen des Automount-Deamons (automountd) erfolgt aber über SRC (System Resource Controller). Der Deamon ist single-threaded. Das bedeutet, das ein hängender Server auch alle anderen Mounts beeinflußt.
Solche Probleme lassen sich aber gut verfolgen, da der Deamon mit dem Schalter -T dazu gebracht werden kann, daß er alle RPC mittraced.
[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]
Copyright 2001-2021 by Orm Hager - Es gilt die GPL