Verteilte Daten

Vorbereitungen

Ehe jedoch entfernte Dateisysteme ins lokale Filesystem eingehängt werden können, bedarf es noch kleinerer Vorbereitungen – client- wie serverseitig. Als erstes wäre hier die Konfigurationsdatei /etc/exports auf dem freigebenden Rechner zu nennen, in der alle zu exportierenden Verzeichnisse aufgeführt werden. Dazu kommen Angaben, wer (welche Clients) wie (mit welchen Rechten) auf die Freigaben zugreifen dürfen. Abbildung 4 zeigt eine exports-Datei, in der das Verzeichnis /export/RPMS auf dem NFS-Server sowohl zum Lesen ("read") als auch zum Schreiben ("write") für alle (@L: *) Client-Rechner freigegeben wird. Auf eine auf dem NFS-Server unter /mnt/cdrom gemountete CD darf lediglich der Client stargazer lesend ("read only") zugreifen.

Abbildung 4: Die Datei /etc/exports mit verschiedenen Freigaben

In der zweiten Spalte können weitere Einschränkungen festgelegt werden. So lässt sich gezielt festlegen, dass in der ersten Spalte angegebene Verzeichnisse nur für Rechner mit bestimmten IP-Adressen oder aus bestimmten Domains zugänglich sind. Sogar Wildcards sind möglich.

Der Befehl exportfs zeigt alle freigegebenen Verzeichnisse an. Wenn Sie ihn mit der Option -r benutzen, synchronisiert er die Datei exports mit der NFS-Tabelle (bei Red Hat unter /var/lib/nfs/xtab, auf Solaris-Workstations unter /etc/dfs/sharetab zu finden). Neue exportfs-Einträge werden dabei in die NFS-Tabelle aufgenommen, während nicht mehr in der Export-Liste vorhandene Einträge gelöscht werden. Ein Blick in diese Datei verrät Neugierigen übrigens weitere interessante Parameter für die zweite exports-Spalte, von denen einige in Tabelle 1 aufgeführt sind.

Der lokale NFS-Daemon auf dem Client-Rechner bekommt nun alle erforderlichen Variablen und Daten geliefert, um mit dem NFS-Server zu kommunizieren. Von jetzt an können Sie mit dem externen Filesystem arbeiten, als ob es lokal zu Ihrem Rechner gehörte. Es ist nun ein Teil Ihres eigenen Systems.

Auch für den mount-Befehl gibt es weitere Optionen (vgl. Tabelle 2), zum Beispiel hard und soft. Bei einem "Hardmount" (der Normalfall) versucht der Client, auf Teufel-komm-raus Zugriff auf den NFS-Server zu erlangen. Bei einer Netzstörung oder der Nichtverfügbarkeit des Servers kann diese Hartnäckigkeit zum Erliegen des Systems führen. Beim "Softmount" dagegen schickt der Client Anfragen lediglich so lange ab, bis ein Timeout eintritt und der User eine Fehlermeldung erhält – auch nicht immer die optimale Lösung. Um bei diesen beiden Mount-Verfahren einen Abbruch zu erzwingen, gibt es die Option intr (ihr Gegenteil heißt nointr). Sie erlaubt es Ihnen, einen Mount-Versuch per Hand (meist mit [Strg-c]) frühzeitig zu unterbrechen. Per Default (oder bei Angabe der Mount-Option fg) gibt der Mount-Prozess nicht auf, wenn's beim ersten Mal nicht klappt. Gibt man den entsprechenden Befehl in einer Shell ein, bleibt diese blockiert. Mit der Option bg versehen, reagiert mount auf einen missglückten Versuch entspannter: Der Prozess taucht in den Hintergrund ab und wird zu einer Art Daemon, der es später nochmal probiert, ohne die Shell zu blockieren. So versucht der Befehl

mount -t NFS -o bg,intr,retry=5 defiant:/export/RPMS /mnt/nfs

das auf dem Rechner defiant freigegebene Verzeichnis /export/RPMS in den lokalen Dateibaum unter /mnt/nfs einzuhängen. Geht der erste Versuch schief, taucht der mount-Prozess in den Hintergrund ab (bg), damit Sie weiter auf Ihrer Shell arbeiten können. Nach fünf Fehlversuchen soll er automatisch aufgeben (retry=5), während der Sie allerdings die Option zum Abbruch von Hand haben (intr).

[root@defiant /]# ls -al /usr/bin/passwd
-r-sr-xr-x root system passwd
[root@defiant /]# ls -al /etc/shadow
-rw-r--r-- root system passwd

Sysadmins sind bekanntlich sehr faule Menschen, die alles automatisieren möchten. Statt Dateisysteme per Hand einzuhängen, gibt es daher auch hier einen einfacheren Weg: den Eintrag in die Datei /etc/fstab des lokalen NFS-Client-Rechners. In dieser Datei stehen alle Dateisysteme, Schnittstellen und Devices, die irgendwann einmal gemountet werden bzw. werden können. Lassen Sie uns einen kurzen Blick auf Abbildung 5 werfen.

Abbildung 5: /etc/fstab

Auch hier sehen Sie wieder, dass es sich um eine reine ASCII-Datei handelt, in der Sie als root selbstständig Einträge vornehmen können. In der ersten Spalte findet das Gerät (die Festplattenpartition, das CD-Device etc.), das Sie mounten möchten, seinen Platz. Darauf folgt der Mountpoint, also das Verzeichnis, unterhalb dessen das "fremde" Dateisystem in den lokalen Dateibaum eingehängt wird. Die dritte Spalte enthält den Filesystem-Typ, in der vierten definiert man die Mount-Optionen (siehe Tabelle 2). Die letzten beiden Spalten enthalten die Information, ob ein Filesystem-Dump, d. h. eine Sicherung des Dateisystems oder Verzeichnisses, erzeugbar sein und ob das Dateisystem vor dem Mounten geprüft werden soll.

Ein für Sie zugängliches, von einem NFS-Server exportiertes Verzeichnis tragen Sie hier etwa folgendermaßen ein:

defiant:/export/RPMS   /mnt/nfs   nfs   noauto,user,bg,hard,intr   0   0

Dieser Eintrag ähnelt den bisherigen Konsoleneingaben sehr: Quell- und Zielverzeichnis, der Dateisystemtyp (nfs) und die verschiedenen Optionen sind leicht auszumachen. Das Beispielverzeichnis wird nicht automatisch beim Booten gemountet (noauto), kann aber von Normalbenutzern eingehängt werden (user). Dabei kommen die oben erwähnten NFS-Mount-Optionen bg, hard und intr zum Zuge. Nun lässt sich das von defiant exportierte Verzeichnis /export/RPMS mit einem einfachen mount /mnt/nfs ins lokale Dateisystem einhängen.

Automount

Das ist Ihnen noch nicht einfach genug? Dann brauchen Sie einen Automounter. Er hängt benötigte Verzeichnisse automatisch bei Bedarf (Zugriff) ein und entfernt sie nach einem bestimmten Zeitraum der Nichtnutzung wieder. Dies lässt sich über ein Kernel-Modul namens autofs realisieren, dass in vielen Fällen bereits im vorgefertigten Kernel integriert ist.

Das Autofs-Modul "belauscht" alle "Wechsel"-Vorgänge innerhalb des Dateisystems. Bei einem cd in ein Verzeichnis oder bei Aufruf einer Datei unterhalb des eingehängten Mountpoints gibt das Modul die Anfrage an den Automount-Daemon weiter. Dieser arbeitet nun die Konfigurationseinstellungen ab, die in den "auto-Dateien" unterhalb von /etc definiert sind. Die erste Datei, der er sich zuwendet, ist die /etc/auto.master, die die allgemeine Vorgehensweise beschreibt (Listing 1).

#/etc/auto.master
/export/RPMS     /etc/auto.rpms
/home            /etc/auto.home -intr,[…]

/xxx             /etc/auto.xxx  -nosuid,[…]

Die erste Spalte gibt die Mountpoints an, in der zweiten Spalte steht der Name einer sogenannten Map-Datei, und die dritte definiert die zugehörigen Mount-Optionen. Wenn Sie nun auf das Verzeichnis /xxx zugreifen wollen, erkennt dies das Autofs-Modul; der Automount-Daemon liest die auto.master-Datei aus und sieht, dass alle weiteren Informationen in der Datei /etc/auto.xxx abgelegt sind. Dort liest er die hinterlegte Vorgehensweise aus. Diese Map-Datei ist ähnlich aufgebaut wie die Master-Datei.

cdrom      -fstype=iso9660      :/dev/cdrom
dokus      -ro,intr,soft        ftp.bobcom.de:/pub/linux/HOWTO
win2k      -fstype=vfat,ro      :/dev/hdc1

Das erste Beispiel in Listing 2 verfügt, dass Daten-CDs mit dem ISO-9660-Dateisystem über die Gerätedatei /dev/cdrom ins Unterverzeichnis /xxx/cdrom eingebunden werden. Die zweite Zeile mountet das Verzeichnis /pub/linux/HOWTO vom NFS-Server ftp.bobcom.de nur lesbar ("read only") per manuell unterbrechbarem Softmount ins lokale Verzeichnis /xxx/dokus (bei NFS-Mounts muss kein Filesystemtyp angegeben werden), während die lokale VFAT-Windows-Partition /dev/hdc ebenfalls nur lesbar bei Bedarf unter /xxx/win2k zu finden ist.

Anhand der Erkenntnisse aus dieser Map setzt der Automounter den Mount-Vorgang in Gang, und kurz darauf können Sie sich im implizit angeforderten neuen Verzeichnis bewegen. Wenn Sie längere Zeit (Defaultwert ist fünf Minuten) nicht mehr darin befinden, erfolgt ein automatischer Unmount.

Manche fragen sich jetzt sicher, was bei gleichzeitigem Schreibzugriff mehrerer Clients auf eine Datei passiert. Hier werden – ähnlich einer Datenbank – die Files gelockt, d. h. für den weiteren Gebrauch gesperrt, und selbst in eine Datenbank eingetragen. Hierbei erhält der verantwortliche "Network Lock Manager" (NLM) Schützenhilfe vom "Network State Monitor" (NSM), der die Aktivitäten der am NFS-Zugriff beteiligten Maschinen überwacht. Hat ein Client einen Zugriff beendet oder muss neu booten, entsperrt der Lock Manager die Dateien und gibt sie für die Öffentlichkeit wieder frei.