Inhaltsverzeichnis
Bewertung 3
Die Kandidaten sollten in der Lage sein, automount Dateisysteme zu konfigurieren. Dieses Prüfungsziel beinhaltet automount für Netzwerk- und Gerätedateisysteme. Auch beinhaltet ist die Erstellung von Nicht-EXT2 Dateisystemen wie etwa CDROMs.
Schlüsseldateien, Begriffe und Hilfsmittel beinhalten:
- /etc/auto.master
- /etc/auto.[dir]
- mkisofs
- dd
- mke2fs
Konfiguration von automount-Dateisystemen
Als Automounting wird der Vorgang bezeichnet, dass Dateisysteme bei Gebrauch automatisch durch einen Daemon eingehängt (mount) werden. Auch das Wiederabhängen (umount) kann nach einer bestimmten Zeit ohne Aktivität automatisch erfolgen. Dieser Vorgang ist unabhängig von Einträgen in /etc/fstab. Der Daemon, der für diesen Vorgang verwendet wird heißt automount und sollte über ein Startscript in /etc/init.d gestartet werden. Das gesammte autofs-System liegt im Kernel-Space, ist also konkret abhängig von der jeweiligen Kernel-Version. Seit der Kernelversion 2.0.xx ist die autofs-Funktionalität stabil aber als experimentell markiert, seit der Version 2.2.xx ist es eine normale Kernel-Option.
Die Konfiguration von automount kann entweder lokal oder netzweit über NIS(plus) oder LDAP erledigt werden. Diese Beschreibung reduziert sich auf die lokale Konfiguration mit Dateien (Typ: file). Genauere Informationen über andere Typen entnehmen Sie der Handbuchseite.
Die Konfigurationsdateien von automount befinden sich im Verzeichnis /etc. Die Konfiguration läuft in zwei Stufen ab. Die Datei /etc/auto.master beschreibt einzelne Verzeichnisse, die wiederum Mountpoints enthalten sollen. Für jedes solche Verzeichnis wird eine weitere Datei angegeben (meist /etc/auto.verzeichnisname) in der dann die eigentliche Information steckt, was wie wohin gemountet werden soll. Beim Start des Daemonen durch das Script in /etc/init.d wird für jeden Eintrag in /etc/auto.master ein eigener Daemon gestartet, der dann die jeweilige angegebene Datei als Konfigurationsdatei nutzt. Ein Beispiel:
Die Datei /etc/auto.master
/media /etc/auto.media --timeout 120 /net /etc/auto.net /windows /etc/auto.win
Jede Zeile der Datei beschreibt eine automount-Basis sammt zugehöriger Konfigurationsdatei und optionaler Parameter. Der erste Eintrag ist ein Verzeichnis, das existieren muß. Dieses Verzeichnis ist nicht der Mountpoint selbst sondern das Verzeichnis in dem später die Mountpoints der einzelnen Dateisysteme automatisch angelegt werden.
Der zweite Eintrag beschreibt die Konfigurationsdatei, die für den automount-Daemon benutzt werden soll. Diese Dateien werden gleich weiter unten beschrieben. Der dritte Eintrag ist optional und kann Parameter für den automount-Daemon enthalten. In unserem Beispiel enthält er in der ersten Zeile die Anweisung, dass nach 120 Sekunden ohne weiteren Zugriff die Dateisysteme unter /media automatisch abgehängt werden sollen. Ohne diese Einstellung werden Dateisysteme nach 5 Minuten (–timeout 300) automatisch abgehängt, wenn sie nicht in Gebrauch (busy) sind.
Die anderen Konfigurationsdateien
Für jeden Eintrag in /etc/auto.master benötigen wir jetzt noch eine Konfigurationsdatei, die die eigentlichen Informationen enthält, was gemountet werden soll. In unserem Beispiel benötigen wir also die Dateien
- /etc/auto.media
- /etc/auto.net
- /etc/auto.win
Die erste Datei soll unsere Wechselmedien beschreiben. Nehmen wir an, wir haben ein CD-ROM Laufwerk unter /dev/cdrom, ein Diskettenlaufwerk unter /dev/fd0 und ein Zip-Laufwerk unter /dev/sda1. Die Konfigurationsdatei /etc/auto.media würde also folgendermaßen aussehen:
cdrom -fstype=iso9660,ro,sync,nodev,nosuid :/dev/cdrom floppy -fstype=auto,sync,nodev,nosuid :/dev/fd0 zip -fstype=auto,defaults :/dev/sda1
Jede Zeile enthält diesmal die Beschreibung eines Dateisystems und die Information, wohin es gemountet werden soll. Das erste Feld beschreibt den Mountpoint. Die Angaben sind relativ zu dem Verzeichnis, das im entsprechenden Eintrag in /etc/auto.master angegeben wurde. In unserem Beispiel also /media. Die hier angegebenen Verzeichnisse müssen nicht angelegt werden, im Gegenteil, sollten sie schon existieren, so werden sie temporär entfernt, solange der automount-Daemon läuft. Die Mountpoints unseres Beispiels sind also
- /media/cdrom
- /media/floppy
- /media/zip
Der zweite Eintrag jeder Zeile beschreibt die Optionen des mount-Programms, die für das entsprechende Dateisystem benutzt werden sollen. Einen Überblick über die gängigsten Optionen erhalten Sie hier
Der dritte Eintrag schließlich enthält die Angabe, welches Gerät an den angegebenen Mountpoint eingehängt werden soll. Der führende Doppelpunkt (:) bedeutet, dass es sich um ein lokales Gerät handelt, nicht um ein NFS-Dateisystem.
In der nächsten Beispieldatei (/etc/auto.net) definieren wir stattdessen die NFS-Dateisysteme, auf die wir zugreifen wollen, bzw. die automatisch gemountet werden sollen. Die Datei selbst hat beispielsweise folgenden Inhalt:
einstein -defaults einstein:/var/public gauss -defaults,ro gauss:/public
Wie im letzten Beispiel, so bezeichnen die ersten Felder jedes Eintrags wiederum die Mountpoints realtiv zu dem Verzeichnis, das wir in /etc/auto.master angegeben hatten, hier also /net. In das Verzeichnis /net/einstein soll also mit den voreingestellten Optionen (-default) das über NFS freigegebene Verzeichnis /var/public des Rechners einstein eingehängt werden. Beachten Sie, dass diesmal kein führender Doppelpunkt existiert – es handelt sich ja um NFS-Dateisystemangaben der Form
Rechnername:Verzeichnisname
Die letzte Konfigurationsdatei /etc/auto.win enthält jetzt nichts neues mehr, sie könnte etwa folgendermaßen aussehen:
C -fstyp=vfat :/dev/hda1 D -fstyp=vfat :/dev/hdb1 einsteinC -defaults einstein:/windows/c
Hier haben wir jetzt beides gemischt, sowohl lokale, als auch NFS Dateisysteme in einer Datei.
Natürlich müssen nicht drei oder mehrere autofs-Konfigurationen angelegt werden. Im Orginalzustand wird meist eine einzelne Konfigurationsdatei mit Namen /etc/auto.misc ausgeliefert. Wenn aber unterschiedliche Basisverzeichnisse (wie in unserem Beispiel /net, /media und /windows) verwendet werden sollen, dann benötigen wir für jedes eine eigene Konfigurationsdatei.
Erstellung eines ISO9660 Dateisystems
Die Dateisysteme, die wir bisher besprochen haben, waren alles EXT2 Dateisysteme. Natürlich kann Linux auch andere Dateisysteme verwalten, etwa die augenblicklich sehr beliebten Journaling-Dateisysteme wie das ReiserFS. Analog zu den Befehlen des EXT2 Systems existieren meist jeweils die entsprechenden Befehle auch für die anderen Dateisysteme. Eine Vergleichstabelle der Befehle z.B. zwischen EXT2 und Reiser machen das deutlich:
| Action | EXT2 | Reiser |
|---|---|---|
| Anlegen eines Dateisystems | mke2fs | mkreiserfs |
| Überprüfen eines Dateisystems | e2fsck | reiserfsck |
| Debuggen eines Dateisystems | debugfs | debugreiserfs |
Ähnliches gilt auch für andere Dateisysteme. Eine Ausnahme dieses Prinzips stellt das ISO9660 Dateisystem dar. Dieses System ist für CDROMs gedacht und ist intern wesentlich einfacher aufgebaut, als vergleichbare Systeme für beschreibbare Medien. Der Grund liegt eben darin, dass bei der Erstellung eines CD-Rom Dateisystems bereits alle Daten dieses Systems feststehen und im Nachhinein nicht mehr verändert werden können.
Aus diesem Grund sind weder Dateisystemüberprüfung, noch ein Dateisystemdebug für ein ISO-System notwendig. Das Erstellen eines solchen Systems wird aber wiederum mit einem Befehl mkisofs erledigt. Im Gegensatz zu anderen Systemen wie Reiser oder EXT2 kann aber das neu zu erstellende ISO-System nicht gleich auf das entsprechende Medium geschrieben werden. Diese Aufgabe übernimmt ein spezielles Brennprogramm wie z.B. cdrecord, das mit der Ansteuerung der verschiedenen CD-Brenner vertraut ist.
Das Programm mkisofs muß also über den Umweg einer sogenannten Image-Datei sein Dateisystem erstellen. Eine solche Imagedatei enthält Bit für Bit genau das, was auf der CDROM später enthalten sein soll. mkisofs erstellt ein solches Image, das dann später mit geeigneten Programmen auf eine CD gebrannt werden kann.
Das Programm mkisofs versteht sehr viele verschiedene Kommandozeilenparameter und wird ausschließlich über sie gesteuert. Es kann inzwischen sowohl die CD-ROM Erweiterungen von Microsoft (Joliet-Extensions) und Apple (HFS) erzeugen, als auch die üblichen RockRidge-Erweiterungen für Unix. Die gesamten Funktionen dieses Programms sind hier nicht alle darstellbar, beschränken wir uns auf die wichtigsten.
Die ursprüngliche Definition des ISO9660 Standards beschränkte sich auf die Dateinamensregeln von MSDOS. Es gab also
- keine Unterscheidung zwischen Groß- und Kleinbuchstaben
- nur Dateinamen mit 8 Zeichen und einer 3 Zeichen Erweiterung (8.3)
- nur einen Punkt im Dateinamen
- keinerlei Dateiattribute wie Eigentümer, Gruppe, Zugriffsmodus, …
Diese Einschränkungen waren für Unix-User untragbar. Aus diesem Grund sind die sogenannten RockRidge Erweiterungen für das ISO9660 Dateisystem eingeführt worden. Wenn wir für Linux-Systeme CDs brennen wollen, so benötigen wir dringend diese Erweiterungen.
Die Aufrufform des mkisofs Programms könnte stark vereinfacht wie folgt dargestellt werden:
mkisofs [Optionen] [-o Ausgabedateiname] Verzeichnis
Das Programm erstellt jetzt ein CDROM Image mit dem Inhalt des Verzeichnisses Verzeichnis und schreibt es in die Datei Ausgabedatei. Die Ausgabedatei ist also die Imagedatei, die wir später dann brennen können. Die wichtigsten Optionen sind: -R RockRidge Erweiterungen werden angewendet. -T In jedem Verzeichnis wird eine Datei TRANS.TBL angelegt, die die Dateinamen für die Systeme enthält, die RockRidge nicht verstehen. -sysid SystemID Ermöglicht die Angabe der SystemID der späteren CDROM.
Um also zum Beispiel unser komplettes Verzeichnis /etc samt aller Unterverzeichnisse in eine ISO9660 Image-Datei mit RockRidge Erweiterungen abzulegen, die wir später auf CD brennen können, schreiben wir einfach:
mkisofs -R -o /tmp/myimage /etc
Die Datei /tmp/myimage enthält jetzt also Bit für Bit genau das Abbild (Image) einer CDROM. Diese Datei kann jetzt mit Programmen wie cdrecord tatsächlich auf eine CD gebrannt werden.
Das Programm mkisofs unterstützt inzwischen auch das Anlegen von bootfähigen CDs und viele anderen Features, die aber den Rahmen dieser Darstellung bei weitem sprengen würden.
Umgang mit Dateisystemimages
Im letzten Abschnitt haben wir das erste Mal Imagedateien kennengelernt, also Dateien, die Abbilder ganzer Laufwerke beinhalten. Die Fähigkeit von Unix, mit solchen Dateien zu arbeiten ist schon viel älter, als die CDROMs, sie wurde und wird auch für andere Zwecke benutzt.
Unix arbeitet ja bekanntlich mit Gerätedateien, also mit der Repräsentation von blockorientierten Geräten durch die Dateien im Verzeichnis /dev. Aus der Sicht des Betriebssystems sind blockorientierte Geräte wie Festplatten, Partitionen, Disketten oder CDROMs also sowieso nichts anderes als Dateien. Was hindert uns also daran, auch mit Image-Dateien so umzugehen, als seien es Geräte?
Damit das in diesem Zusammenhang nochmal klar wird, folgen hier noch zwei konkrete Anwendungsbeispiele für den Umgang mit Imagedateien.
Kopieren von Images auf oder von Geräten
Wenn wir ein blockorientiertes Gerät benutzen, sagen wir einmal beispielsweise ein Diskettenlaufwerk, dann können wir dieses Gerät ja über die entsprechende Gerätedatei wie eine Image-Datei ansprechen. Um also den gesamten Inhalt einer Diskette byteweise auf den Bildschirm auszugeben könnten wir schreiben
cat /dev/fd0
Der Befehl cat gibt ja den Inhalt einer Datei auf die Standard-Ausgabe aus. Wir würden zwar mit dieser Ausgabe wenig anfangen können, weil sie ja nicht nur den Dateiinhalt, sondern eben wirklich jedes Bit auf der Diskette ausgeben würde, aber es geht tatsächlich. Leiten wir jetzt diese Ausgabe des cat-Programms in eine andere Datei um, so haben wir also ein genaues Abbild (Image) der Diskette.
cat /dev/fd0 > Datei
Sehen wir uns jetzt einmal diese Datei mit ls -l an, dann erhalten wir die Ausgabe:
# ls -l Datei -rw-r--r-- 1 root root 1474560 24. Feb 19:05 Datei
An der Größe der Datei können wir sofort feststellen, dass alle 1,44 MByte der Diskette in die Datei geschrieben wurden. Der Befehl file, der uns ja Auskunft über die Art einer Datei gibt erkennt folgendes:
# file Datei Datei: x86 boot sector, system MSDOS5.0, FAT (12 bit)
Beachten Sie, dass wir die Diskette vorher nicht gemountet hatten. Wir wollen ja nicht über das Dateisystem auf das Laufwerk zugreifen, sondern über das Image.
Es ist jetzt übrigens genauso andersherum möglich, die Imagedatei wieder auf eine andere Diskette zu schreiben, indem wir eingeben:
cat Datei > /dev/fd0
Jetzt schreiben wir also die Datei auf das Gerät, der Effekt ist genau der, den wir erwartet hatten, die Diskette wurde byteweise kopiert.
Genauso ließe sich auch eine CDROM oder eine ganze Partition auf die Festplatte kopieren. Der Befehl cat ist aber nur bedingt geeignet, um diese Aufgaben zu lösen. Unix und damit auch Linux bietet uns einen Befehl, der noch wesentlich geeigneter ist, der Befehl dd.
Dieser Befehl ermöglicht die Angabe der Eingabedatei (inputfile – if) und der Ausgabedatei (outputfile – of), die Größe der zu lesenden Blocks (blocksize – bs) und die Anzahl der zu kopierenden Blocks (count). Werden Blockgröße und Anzahl weggelassen, dann wird die ganze Datei oder eben das ganze Gerät kopiert. Der folgende Befehl kopiert also das Image der eingelegten Diskette in die Datei Datei.
dd if=/dev/fd0 of=Datei
Es ist aber eben auch möglich, bestimmte Teile eines Laufwerks zu lesen. Der Bootsektor einer Festplattenpartition beginnt z.B. bei Sektor 0 und ist 512 Byte groß. Um also den Bootsektor der Platte /dev/hda3 in eine Datei zu kopieren, schreiben wir
dd if=/dev/hda3 of=Datei bs=512 count=1
Wir kopieren also 1 Block der Größe 512 aus der Datei /dev/hda3 in die Datei Datei.
Falls wir exakt identische Festplatten hätten, sagen wir /dev/hda und /dev/hdb so könnten wir auch eine komplette Spiegelung dieser Platten dadurch erreichen, dass wir schreiben:
dd if=/dev/hda of=/dev/hdb
Jetzt wären die Platten tatsächlich völlig identisch.
Mounten von Imagedateien mit loop
Wenn wir mit Image-Dateien arbeiten, dann stellt sich oftmals die Frage, ob die Datei tatsächlich den von uns erwarteten Inhalt hat. Es wäre ja aber ärgerlich, wenn wir ein Diskettenimage erstellt hätten und dieses Image zur Überprüfung erst wieder auf eine Diskette kopieren müssten, diese Diskette dann mounten und erst dann überprüfen könnten, ob alles funktioniert hat.
Linux bietet die Möglichkeit an, mit Hilfe des sogenannten Loop-Mechanismus, eine Imagedatei zu mounten, als wäre sie eine Gerätedatei. Dazu muß allerdings der Kernel den Loop-Mechanismus eingebaut haben oder das Modul loop.o geladen haben.
Spielen wir es einmal durch. Wir erstellen ein Image einer Diskette wie im letzten Abschnitt beschrieben:
dd if=/dev/fd0 of=/tmp/Datei
Im Verzeichnis /tmp liegt jetzt unser Image. Jetzt mounten wir dieses Image:
mount -o loop /tmp/Datei /mnt
Wir haben jetzt tatsächlich das Image gemountet, als wäre es ein Gerät. Im Verzeichnis /mnt können wir uns jetzt den Inhalt der Diskette ansehen und sogar daran Veränderungen vornehmen. Das kann gerade bei CDROM-Images sehr praktisch sein, weil wir vor dem Brennen genau überprüfen können, ob tatsächlich alles, was wir uns vorgestellt hatten auch im Image abgelegt wurde.
Linux bietet zusätzlich die Möglichkeit, eine solche Imagedatei mit einem Loop-Device – also einer echten Gerätedatei – zu verbinden. Dazu dient der Befehl losetup, der die folgende Aufrufform hat:
losetup Loopdevice Datei
Gültige Loop-Devices sind /dev/loop0, /dev/loop1, …
Hätten wir unsere Imagedatei mit einem solchen Loop-Gerät verbinden wollen, hätten wir also geschrieben:
losetup /dev/loop0 /tmp/Datei
Jetzt wäre es möglich, dieses Loop-Device zu mounten mit:
mount /dev/loop0 /mnt
Um eine Datei wieder vom Loop-Device zu trennen genügt ein
losetup -d /dev/loop0
Das geht aber natürlich nur, wenn das Loop-Gerät nicht mehr gemountet ist.