Es ist vielleicht ein wenig untergegangen, oder erst gar nicht an die Oberfläche geraten. Unser kleines Nieschenblog hat eine neue Kategorie, welche ich mir einfach mal erlaubt habe zu erstellen. Diese nennt sich LPIC-2 und deutet nur subjectiv auf eine Krankheit hin.

Ich konnte mich nicht mehr zurück halten und habe mir folgendes Buch gekauft:

Produktinformation

* Gebundene Ausgabe: 572 Seiten
* Verlag: Open Source Press; Auflage: 1 (Juli 2006)
* Sprache: Deutsch
* ISBN-10: 3937514201
* ISBN-13: 978-3937514208
(danke an Amazon.de

Inhaltlich bietet es folgendes (auch hier wieder ein Danke):
Kurzbeschreibung
Mit diesem Buch bekommen Interessierte erstmals in deutscher Sprache eine solide Vorbereitung auf das LPI-Zertifikat "Intermediate Level Administration" (LPIC-2, bestehend aus den Prüfungen 201 und 202). Aber auch ohne Zertifizierungsziel vermittelt es Linux-Administratoren essenzielles Grundlagenwissen.

Das Zertifikat "Intermediate Level Administration" des Linux Professional Institute (kurz: LPIC-2) setzt das Bestehen der beiden Prüfungen 201 und 202 voraus. Mit diesem Buch bekommen Interessierte erstmals in deutscher Sprache alles an die Hand, was sie für eine solide Vorbereitung benötigen. Die insgesamt 14 Prüfungsthemen (Topics) geben die Gliederung des Buches vor: Nach der Wiedergabe der vom LPI vorgegebenen Inhalte und Lernziele beschreibt die Autorin anschaulich und präzise das Fachwissen, das nicht nur zum Bestehen der Prüfungen, sondern auch für eine anspruchsvolle Administratorentätigkeit notwendig ist. Obgleich verständlich geschrieben, setzt die Thematik grundlegende Linux-Kenntnisse voraus, im Idealfall ein LPIC-1-Zertifikat. Denn es sei nicht verschwiegen: Mit diesem Buch und intensiver Lektüre allein sind die Prüfungen nicht zu bestehen: Die Zertifikate des LPI wollen nicht allein Wissen, sondern insbesondere auch Erfahrung im Bereich der Linux-Administration dokumentieren, und diese Erfahrung ist nur mit Praxis zu gewinnen. Darum schließen in diesem Buch auch praktische Übungen das jeweilige Thema ab. Die Autorin verfügt als Trainerin über langjährige Erfahrung bei der Vorbereitung auf die LPI-Prüfungen. Mit diesem Buch gibt sie ihre Erfahrung in Buchform sowohl für das Selbststudium wie auch als Schulungsmaterial weiter.

Der Verlag über das Buch
Diese Neuauflage ist das weltweit erste vom Linux Professional Institute offiziell zugelassene Trainingsbuch ("LPI Approved Training Materials") für beide Prüfungen des Level LPIC-2. Das Zertifikat "Intermediate Level Administration" des Linux Professional Institute (kurz: LPIC-2) setzt das Bestehen der beiden Prüfungen 201 und 202 voraus. Mit der 2., überarbeiteten Auflage dieses Buches bekommen Interessierte alles an die Hand, was sie für eine solide Vorbereitung benötigen.

Die insgesamt 14 Prüfungsthemen (Topics) geben die Gliederung des Buches vor: Nach der Wiedergabe der vom LPI vorgegebenen Inhalte und Lernziele beschreibt die Autorin anschaulich und präzise das Fachwissen, das nicht nur zum Bestehen der Prüfungen, sondern auch für eine anspruchsvolle Administratorentätigkeit notwendig ist. Obgleich verständlich geschrieben, setzt die Thematik grundlegende Linux-Kenntnisse voraus, im Idealfall ein LPIC-1-Zertifikat. Denn es sei nicht verschwiegen: Mit diesem Buch und intensiver Lektüre allein sind die Prüfungen nicht zu bestehen: Die Zertifikate des LPI wollen nicht allein Wissen, sondern insbesondere auch Erfahrung im Bereich der Linux-Administration dokumentieren, und diese Erfahrung ist nur mit Praxis zu gewinnen. Darum schließen in diesem Buch auch praktische Übungen das jeweilige Thema ab.

Die Autorin verfügt als Trainerin über langjährige Erfahrung bei der Vorbereitung auf die LPI-Prüfungen. Mit diesem Buch gibt sie ihre Erfahrung in Buchform sowohl für das Selbststudium wie auch als Schulungsmaterial weiter.

Wer mich kennt, der weiß das da was im Busch ist (nein, ich meine nicht den Politiker). Jawohl, ich habe mich nicht dagegen stäubern können das nächste Level im Bereich der Linux Zertifizierungen anzugehen.

Bisher habe ich knapp 50 Seiten des Buches gelesen und muss sagen, dass sich die Autorin wirklich viel Mühe gegeben zu haben scheint, möglichst viel Input, auf möglichst charmante Art und Weise auf geringem Raum unterzubringen. Das Buch ist im Vergleich zum ersten von mir gelesenen ein wahrer Impact.

Zu der neuen Kategorie: Ich habe mich eigentlich schon während meiner letzten Zertifizierungsphasen dazu entschlossen den Verlauf in Form eines - ich nenne es jetzt mal so - Manuskripts aufzuzeichnen. Leider fehlte mir immer die Konsequenz dieses Vorhaben umzusetzen. Da ich nun jedoch Teilnehmer eines Blogs bin, denk - vielmehr hoffe ich - nun auf diese Art und Weise Aufzeichnungen anfertigen zu können und so vielleicht anderen in einer solchen Situation etwas guten tun zu können. Natürlich auch als eigenes Nachschlagewerk.

Da ich nun schon fleißig dabei bin den Input zu verwerten bleibt eigentlich nur abzuwarten, wann ich den ersten LPIC-2 bezogenen Beitrag inkl. dem, was mich innerhalb des Lernstoffes beschäftigt hat, schreibe.

Dahingehend würde ich gern jeden Leser und vielleicht schon abgeschlossenen LPIC-2ler bitte sich ein paar Minuten Zeit zu nehmen und einen passenden Kommentar abzugeben. Vielleicht ensteht ja etwas daraus.... :-)

Augenscheinlich habe ich meine momentane Faulheit überwunden und versuche mich nun in meinen Mitschriften zur anstehenden LPIC-2 Zertifizierung.

Anfangen wird es mit der Thematik Linux Kernel. Die nachfolgenden Informationen habe ich durch das bereits erwähnte Buch und den Unterlagen von xinux.com.

Natürlich kann ich nicht dafür bürgen, dass meine Aufzeichnungen vollständig und richtig sind. Ich habe mir lediglich die Mühe gegeben allgemeindenkend zu notieren. Was mir aus dem einfachen Grund wahrscheinlich schon nicht gelungen ist, dass viele Dinge für mich kaum relevant waren (da bereits Erfahrung damit gesammelt wurde).

Nun aber los:

Imagetypen:
Der Kernel liegt grundsätzlich als gzip gepacktes Image vor. Dabei wird jedoch zwischen zImage und bzImage unterschieden. Man könnte annehmen, dass hier unterschiedliche Kompressionsalgorithmen verwendet werden. Das ist jedoch nicht der Fall. Lediglich der Ladealgorithmus ist ein anderer. bzImage steht für Big zImage und ist eigentlich der zu verwendende Standard, da ansonsten der eher als obsolet anzusehende Ladealgorithmus von zImage verwendet wird und dazu führt, dass der Kernel nicht geladen werden kann.

Kernel Versionen:
Wenn man sich die Versionsnummerierung des Linuxkernels ansieht, stellt man schnell fest, dass hier mir drei Bereichen gearbeitet wird. So erhält man in etwas folgendes Versionsnummerngebilde:

2	.	6	.	18
Major Release number		Bei grader Zahl handelt es sich um einen für den produktiveinsatz gedachten Kernelversion. Bei einer ungraden Zahl ist die Version als experimentell anzusehen und ist für die Entwicklung gedacht.		Eigentliche Versionsnummer des Kernels.

Patchen:
Der Linuxkernel liegt, wenn man ihn sich z.B. bei kernel.org herunter lädt als sogenannter 'tree' vor. Das bedeutet, dass unterhalb 'Kernelordners' viele weitere Dateien und Ordner zur besseren Strukturierung vorliegen. Innerhalb jedes Ordners finden sich weitere zum Kernel gehörige Quellcode Dateien. Wenn man sich einen neuen Kernel kompiliert, so werden diese einzelnen Teile je nach Bedarf zusammengesetzt und ergeben so den Kernel - vereinfacht ausgedrückt.

Aufgrund dessen, dass der Kernel Quelloffen vorliegt, kann jeder Verbesserungen und Ergänzugen daran vornehmen. Diese können dann z.B. in Form eines Patches weitergegeben werden.

Der Patch selbst ist eigentlich nur eine Textdatei, welche neben den Unterschieden zum originalquelltext auch entsprechende Informationen zu den Zeilennummern und Dateinamen enthält.

Angewendet wird ein Patch wie folgt:
Bsp.: patch -p0 < anzuwendender-patch.txt

Das -p0 gibt die relative Position zum Quelltextbaum wieder. In diesem Fall würde man sich z.B. in einem übergeordneten Verezeichnis wie /usr/src befinden und dateien in /usr/src/Kernel-Tree/ patchen wollen. Befindet man sich in diesem Beispiel hingegen innerhalb des Quelltextverzeichnisses, so müsste es -p1 heißen.

Kernel kompilieren:
Um einen Kernel zu kompilieren sei es empfohlen die Kernelquellen in /usr/src/ zu hinterlegen und einen symbolischen Link nach /usr/src/linux einzurichten. Neben der Tatsache, dass ein global existierendes Makefile in der ersten Ebene des Kernelbaums liegt, befinden sich in nahezu jedem Unterverzeichnis weitere Makefiles.
Um einen Kernel zu kompilieren, reicht hingegen das eine globale, bzw. die darin definierten Ziele.

Es bieten sich folgende Möglichkeiten innerhalb des Quelltextverzeichnisses zur Konfiguration an:
-make config Eine unbequeme Art zum Konfigurieren, da jedes Element einzeln abgefragt wird.
-make menuconfig Eine konsolenbasierte Menüführung erleichtert die Navigation innerhalb der einzelnen Elemente und ermöglicht so ein 'hin- und herspringen.
-make xconfig Setzt einen laufenden Xserver voraus und bietet eine mit der Maus ansteuerbare Konfigurationsoberfläche.

Hat man seinen Kernel seinen wünschen entsprechend konfiguriert, so findet man seine gemachten Einstellungen in der Datei .config.

Abhängigkeiten zwischen den Konfigurationen werden mit make dep geprüft.

Der Kernel selbst wird mit make bzImage übersetzt.

Die zugehörigen Module übersetzt man mit make modules und installiert sie anschließend mit make modules_install.

Hat man bereits einen eine Konfiguration durchgeführt, so bereinigt man am besten vor der Konfiguration mit make clean alle .o Dateien oder löscht alles nebst .config Datei mit make mrproper.

Im Anschluss muss man noch das Kernelimage aus /usr/src/linux/arch/Prozessorarchitektur/boot/bzImage an einen geeigneten Ort bewegen. Geeignet ist dazu /boot.

Bootloader einrichten:
Ist dies geschehen, so muss noch der Bootloader angepasst werden. Im Falle von Lilo sähe ein Eintrag (in der /etc/lilo.conf) ungefähr wie folgt aus:

Image = /boot/Mein-eigener-Linuxkernel
label = Handarbeit
root = /dev/hda2

Verwendet man hingegen Grub, so würde das so aussehen können (in der /boot/grub/menu.lst):

title Handarbeit
root (hd0,1)
kernel /boot/Mein-eigener-Linuxkernel

Initrd:
Manchmal kann es vorkommen, dass man zum starten des Systems eine initial Ramdisk braucht. Diese enthält für den Start notwendige Treiber, wie z.B. bestimmte SCSI Module. Dazu bedient man sich des mkinitrd Skriptes. Leider gibt es hier distributionsspezifische Unterschiede;

-Redhat - Bedient sich den notwendigen Modulen aus /etc/modules.conf (bzw. /etc/modprobe.conf).
-Debian - Enthält sämtliche Konfigurationseinstellungen in /etc/mkinitrd.
SuSE - Trägt alle relevanten Einstellungen in die Datei /etc/sysconfig/kernel ein.

Module einrichten:
Die Konfiguration der einzelnen Module erfolgt vorzugweise über die Datei /etc/modules.conf (bzw. /etc/modprobe.conf). Dabei gilt es zu wissen, dass mit einem Alias-Eintrag Geräte benannt werden können. Bsp.: alias eth0 3c503. Optionen sollten separat gesetzt werden. Bsp.: options 3c503 io=??? irq=???. Damit man sich nicht sämtliche möglichen Optionen zusammenkratzen muss, bietet hier der Befehl modinfo abhilfe.

Systemstart

• Der Bootloader lädt den Kernel
• Der Kernel lädt die Root-Partition (in aller Regel read-only)
• Der Kernel übergibt die Herrschaft über den weiteren Bootprozess an init

Somit lässt sich erkennen, dass Init der erste gestartete Prozess ist. Damit trägt er immer
die Prozesskennung "1". Was Init jetzt genau machen soll wird über die Datei /etc/inittab
konfiguriert. Sobald das System einen Status erreicht hat, den man verwenden möchte, so
nutzt man Init zum wechseln der Runlevel. So würde man z.B. mit init 3 in das
Runlevel 3 wechseln. Damit man sich orientieren kann, in welchem Runlevel man sich befindet
gibt es den Befehl runlevel der uns anzeigt innerhalb welchen wir uns befinden.

linux:~# runlevel
N 2

N bedeutet in diesem Fall, dass noch kein Wechsel des Runlevels stattgefunden hat. Andernfalls würde man hier das zuletzt ausgeführte Runlevel sehen.

Die Datei /etc/inittab

Wie bereits oben erwähnt bietet die Datei /etc/inittab die Möglichkeit den Bootprozess
des Systems zu beeinflussen. Dies geschieht innerhalb der Datei mit jeweils einer Zeile
die aus insgesamt vier Feldern besteht.

id:Runlevel:aktion:Befehl

• id = Ein (bis auf die Getty-Prozesse) Frei wählbarer Bezeichner. Hier kann man sowas wie sys,r3
  oder ähnliches verwenden.
• Runlevel = Bezieht sich auf den oder die Runlevel, auf welches diese Zeil angewendet werden soll.
• aktion = Hier muss eine der nachfolgend aufgeführten Aktionen eingesetzt werden:
  • respawn startet den Befehl nach seiner Beendigung erneut (Getty sei hier als Beispiel genannt).
  • wait startet den Befehl genau ein mal und wartet auf dessen Beendigung.
  • boot starte den Befehl während de bootens.
  • bootwait wie boot, wartet allerdings so lange, bis der Befehl beendet wurde.
  • initdefault definiert den standardmäßig zu startenden Runlevel. Damit wird auch das Feld Runlevel ausser kraft gestzt.
  • powerwait führt den Befehl aus, sobald z.B. durch eine USV ein Abfall der Spannung gemeldet wird. Wartet bis zu Beendigung des Befehls.
  • powerfail wie powerwait, wartet allerdings nicht bis zur Beendigung des Befehls.
  • powerokwait Sobald die Spannung von der USV wieder als stabil gemeldet wird, wird befehl ausgeführt. Wartet bis zur Beendigung von Befehl.
  • powerfailnow Die USV meldet, das es kurz vor zwölf ist. Genau jetzt soll der Befehl ausgeführt werden.
  • ctrlaltdel Was soll ausgeführt werden, sobald man die Tastenkombination STRG+ALT+DEL benutzt.
• Befehl = Hier kann jeder Benutzerdefinierte Befehl oder ein Shellskript angegeben werden.

Bsp.: ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

So gestaltet sich auch der Aufbau der einzelnen Runlevel. Es wäre jedoch extrem mühsam jeden Service einzeln in die /etc/inittab einzutragen und dort zu pflegen. Deshalb gibt es sogenannte initskripte. Diese liegen üblicher weise im Verzeichnis /etc/init.d und werden für jeden Dienst oder Befehl einzeln gepflegt. Diese allein bieten aber nur Grundlage einer Runlevelkonfiguration. Da bei einem Linuxsystem diverse Runlevel existieren (z.B. 1 für den singleuser-mode, 3 für den Netzwerkbetrieb ohne X, 5 für eine grafische Oberfläche) muss init mitgeteilt werden, welche skripte in welchem Runlevel ausgeführt werden.

Dazu wird lediglich ein symbolische Link des Skripts in eines der rcX.d Verzeichnisse gesetzt. X steht in diesem Fall für die Nummer des Runlevels, also z.B. 3.

Distributionsunterschiede

• SuSE = rcX.d Verzeichnisse finden sich in /etc/init.d/rcX.d.
• Debian = rcX.d Verzeichnisse finden sich in /etc/rcX.d.
• RedHat = rcX.d Verzeichnisse finden sich in /etc/rc.d/rcX.d.

S89cron -> ../init.d/cron

Da sie Skripte in diesen Verzeichnissen in alphabetischer Reihenfolge abgearbeitet werden, sollte man sich an eine Namensgebung gewöhnen, welche sich mitlerweile eingebürgert hat:

{S|K}{Positionsnummer in der Abarbeitungsschleife}{Programmname}

• S bedeutet Start.
• K bedeutet kill also beenden.

Positionsnummer soll lediglich der Orientierung bzw. der Organisation der Abarbeitunsreihenfolge dienen (man erinnere sich an die alphabetische Abarbeitung). Programmname ist hier wiederum mehr oder weniger zur eigenen Orientierung.

Diese Skripte enthalten in aller Regel mindestens die Parameter Start oder Stop, meistens aber mehr.

linux:~# /etc/init.d/cron
Usage: /etc/init.d/cron {start|stop|restart|reload|force-reload}.

Man hat bei der Konfiguration der einzelnen Runlevel entweder auf pure Handarbeit zurückgreifen, oder die von den Distributionen zur Verfügung gestellten Tools nutzen:

• SuSE = insserv (-r zum entfernen des Links ) oder chkconfig (--add zum hinzufügen, -l zum auflisten)
• RedHat = chkconfig (--level zum bestimmen der anzusteuernden Runlevel, --list zum auflisten der gesetzten Links, ) (on zum aktivieren)
• Debian = update-rc.d (Dienstbezeichnung) start (Prozessnummerierung Runlevel Runlevel) . stop (Prozessnummerierung Runlevel Runlevel Runlevel ...) .

Systemrettung

Zum Thema Systemrettung gibt es sicherlich viel zu schreiben. Ich werde mich hier allerdings nur auf wesentliche Aspekte beziehen.

Bei der Verwendung eines Bootloaders wie Lilo oder Grub können gleich mehrere Probleme auftreten. Zum einen wird der First Stage Loader geladen, welcher sich in der Regel im MBR (Master Boot Record) befindet. Im Anschluss wird aufgrund der Informationen, welche der First Stage Loader enthält, der Second Stage Loader gestartet. Verwender man Lilo ist dieser in der Datei /boot/boot.b zu finden. Verwendet man hingegen Grub, so finden sich die Dateien in /boot/grub.

linux:~# ls /boot/grub/
default fat_stage1_5 menu.lst~ stage1
device.map jfs_stage1_5 minix_stage1_5 stage2
e2fs_stage1_5 menu.lst reiserfs_stage1_5 xfs_stage1_5

Dateisystemchecks

Eine wichtige Rolle bei der Systemwiederherstellung spielen Dateisystemchecks. Dabei verwendet man zumeist das Kommando fsck.Dateisystem mit Angabe der Partition, welche es zu kontrollieren gilt.

Bsp.: fsck.ext2 /dev/hda1

Wichtig hierbei ist die Erwähnung der Option -b Superblock. Hiermit ist es nämlich möglich den Ersatzsuperblock des Dateisystems anzugeben, für den Fall, das der ursprüngliche nicht mehr intakt ist. Die Lage des Ersatzsuperblocks ist abhängig von der Blockgröße des Dateisystems. Jedoch lässt sich die Formel

Blockgröße * 8193

anwenden um die Lage zu errechnen. Bei einer Blockgröße von z.B. 4Kb findet sich der Ersatzsuperblock in 32768. Wer nicht rechnen möchte kann einfach dump2fs /dev/Partition verwenden um die Lage zu ermitteln.

In diesem heutigen Beitrag über meinen Werdegang als LPIC-2 zertifizierter Mensch, wird es um eine etwas ausführlichere Darstellung der Benutzung von Dateisystemen gehen. Wie immer übernehme ich keinerlei Haftung auf Vollständigkeit, da ich zwar bemüht bin sämtliche Aspekte für einen mehr oder weniger Neuling zu berücksichten, es jedoch nicht garantieren kann.

Einbinden von Dateisystemen

Um unter einem Unixoiden System ein Dateisystem als solches nutzen zu können, muss es zu erst gemountet und so dem System zur Verfügung gestellt sein. Dies beeinhaltet, dass das Dateisystem innerhalb der Verzeichnisstruktur "eingehängt" wird.

Handelt sich es sich im ein Dateisystem, welches wir nur kurz nutzen wollen, so bietet sich der Befehl mount an. Soll hingegen das Dateisystem bei jedem Start des Rechners zur Verfügung stehen, so wäre es lästig ständig händisch den Befehl auszuführen. Dafür existert die Datei /etc/fstab. Der Aufbau dieser Datei folgt dem nachfolgend aufgeführten Schema:

device mountpunkt Dateisystemtyp mount-optionen dumprelevanz fsckreihenfolge

• device - Welche Gerätedatei (später dazu mehr) soll beim Start eingehangen werden ? Neben der Angabe einer Gerätedatei kann ebenfalls eine NFS-Freigabe, ein Dateisystemlabel (LABEL=) oder eine UUID (UUID=) angegeben werden.
• mountpunkt - An welcher Stelle der Verzeichnisstruktur soll das Dateisystem zur Verfügung gestellt werden.
• Dateisystemtyp - um welches Dateisystem handelt es sich. Im Zweifelsfall bietet auto Abhilfe.
• mountpunkt-optionen - Welche Optionen sollen beim Einhängen beachtet werden.
• dumprelevanz - Soll das Dateisystem bei einer Sicherung mit dem Befehl dump berücksichtig werden?
• fsckreihenfolge - Legt indirekt die Reihenfolge fest, in der Dateisysteme eingehangen werden sollen, da es die Reihenfolge für die Dateisystemüberprüfung darstellt. Zulässige Werte sind 0 bis 9, wobei das Root-Dateisystem in der Regel eine 1 erhält.

mount bzw. umount

Wie bereits erwähnt, stellt ein Unixoides System in aller Regel den Befehl mount zur Verfügung, welcher zum händischen Bereitstellen von Dateisystemen genutzt wird. Eine typische Anwendung von mount sieht wie folgt aus:

mount -t typ Gerät Einhängepunkt

• -t spezifiziert den Dateisystemtyp des einzuhängenden Geräts.
• Gerät gibt das Gerät an, welches innerhalb des Verzeichnisbaum zur Verfügung gestellt werden soll. Synchron zu den Angaben in der /etc/fstab können auch hier NFS-Freigaben, LABEL, UUID angegeben werden.
• Einhängepunkt benennt den genauen Ort, an dem das Dateisystem eingehanden und damit bereitgestellt wird.

Möchte man Dateisysteme welche man in der Datei /etc/fstab angegeben hat von Hand aushängen und/oder wieder einhängen, so kann mount in der einfachsten Form aufgerufen werden

mount Gerät|Mountpunkt

Das funktioniert, weil mount zu Beginn die Datei /etc/fstab einliest.

Wird ein Dateisystem gemountet (also eingehangen und zur Verfügung gestellt), so hat dies zur Folge, dass ein Eintrag in der Datei /proc/mounts, sowie der Datei /etc/mtab erstellt wird. Man kann jedoch einen Eintrag in die Datei /etc/mtab verhindern, indem man einem mount Befehl die Option -n mitgibt. Typischer Weise sind die enthaltenen Einträge der Dateien /proc/mounts und /etc/mtab identisch und bieten einen Überblick über gesetzte Einhängeoptionen und (sofern dies zutrifft) den Benutzer, welcher das Dateisystem eingehangen hat.

Bsp.: /dev/sdb1 /mnt/space ext3 rw,relatime 0 0

Möchte man ein bereits eingehangenes Dateisystem wieder aushängen, so braucht man den Befehl umount, welchem man lediglich den Einhängepunkt, oder ggf. das eingehangene Gerät mitteilen muss.

Erhält man einen Fehler beim aushängen eines Dateisystems, so liegt es mit einer großen Wahrscheinlichkeit daran, dass noch mit diesem Dateisystem gearbeitet wird.

Der Befehl fuser zeigt die Prozesse an, welche das eingehängte Dateisystem aktuell nutzen. Mit Hifle des Schalters -k bietet er zudem die Möglichkeit sämtliche Prozesse zu killen (also zu beenden) und somit das Aushängen zu ermöglichen.

Unabhängig kann auch der Befehl lsof (list open files) genutzt werden, um die noch geöffneten Dateie anzeigen zu lassen, welche ein aushängen verhindern.

Bsp.:

COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
Thunar 5782 kesar 24w REG 8,17 1293090816 2564097 /mnt/space/test.txt

Swap

Swap-Speicher bietet dem System die Möglichkeit Inhalte des Arbeitsspeichers auszulagern. Swap-Speicher wird vorzugweise in Form einer eigenen Partition bereigestellt. Diese muss die Partitions-ID 82 tragen (kann z.B. mit Programmen wie fdisk [nicht die MS-Version] erledigt werden.). Zudem besitzt eine Swap-Partition kein Dateisystem.

Ist eine solche Partition angelegt, bzw. vorhanden, so kann sie mit

swapon /dev/Swap-Partition

initialisiert werden. Im Anschluss sollte man der Bequemlichkeit halber die Swap-Partition in die /etc/fstab eintragen. Hierbei ist zu beachten, dass im Feld Mountpunkt, als auch im Feld Dateisystemtyp swap angegeben ist. Die Auslastung einer Swap-Partition wird von swapon -s angezeigt.

Filename Type Size Used Priority

/dev/sda3 partition 979956 45080 -1

Wie zu erkennen ist, wird bei der Ausgabe auch eine Priorität mit angegeben. Diese kann entweder innerhalb der /etc/fstab (im Feld der Optionen mit pri=Wert) oder swapon -p setzen. Es gilt einen Wertebereich von 0 - 32767 zu beachten.

Wartung, Pflege, Verwaltung

Bei der Verwendung von Dateisystemen ist der Zugriff auf Device-Dateien unbedingt notwendig. Heutige Systeme sollten solche Dateien nahezu selbstständig anlegen. Ist dies jedoch mal nicht der Fall, so zieht man den Befehl mknod zur Hilfe (später mehr). Bei solchen Device-Dateien wird unterschieden zwischen Block- und Character-Dateien. Das begründet sich einfach darin, dass man auf z.B. Festplatten blockweise und Konsolen (z.B. Serielle-SChnittstelle) zeichenweise zugreift.

Zusätzlich ist noch der Umgang mit Major- und Minordevice-Nummern wichtig für das Verständis. Die Major-Devicenummer teilt dem Kernel mit, welchen Treiber er für dieses Gerät zu laden hat. Die Minor-Devicenummer dient quasi der Durchnummerierung und stellt in Kombination mit der Major-Devicenummer eine eindeutige Kennung dar.

Wie bereits oben erwähnt kann es vorkommen, dass man eine Device-Datei von hand anlegen muss, um später mit ihr innerhalb des Systems arbeiten zu können. Dafür muss man dem Befehl mknod sowohl den Dateityp (Block oder Character), als auch eine Major und Minornummer mitteilen.

Bsp.: mknod Name Typ Majornummer Minornummer

mknode /dev/hda9 b 4 7

Schlechte Blöcke

Jeder Datenträger trägt das Potential in sich physikalische Fehler aufzuweisen. Um diese zu finden und ggf. handhabbar zu machen gibt es den Befehl badblocks.

Grundsätzlich bieten sich mit Badblocks drei verschiedene Testmöglichkeiten:

• Readonly-Test Ist das standardmäßige Testverfahren. Hier werden lediglich sämtliche Blöche eines Datenträgers auf Lesbarkeit überprüft.
• Read-Write-Test Dieser Testmodus wird durch den Schalter -w eingeleitet und führt dazu das sämtliche Blöcke eines Datenträgers mit einem Muster vollgeschrieben werden, welches im Anschluss wieder versucht wird einzulesen. Folge ist allerdings, dass sämtliche Daten gelöscht werden.
• Read-Write-Test (brave Methode) Ist eine abgewandelte Form des durch -w eingeleiteten Verfahrens. Hierbei wird der ursprüngliche Inhalt des Blocks zwischengespeichert, um ihn im Anschluss an das Testverfahren wieder zurück zu schreiben. Wird eingeleitet durch den Schalter -n.

Allein das Wissen um defekte Blöcke bringt einen nicht viel weiter. Darum bieten Tools wie fsck oder mkfs (in abhängigkeit von den Subroutinen) die Möglichkeit die Informationen von badblocks zu nutzen. Zeit sparen kann man sich, wenn man beim Aufruf von badblocks den Schalter -o Datei nutzt. Dies führt dazu, dass Informationen zu defekten Blöcken in Datei geschrieben werden. Diese kann man wiederum zb.B. bei mkfs.ext2 mit dem Schalter -i nutzen um defekte Blöcke direkt ausschließen zu lassen. Da es sich bei der Suche nach defekten Blöcken um eine aufwendige Aktion handelt, bietet sich der Schalter -s bei der Verwendung von badblocks an um sich den aktuellen Stand der Prozedur anzeigen zu lassen.

Dateisysteme

Um mit Dateisystemen arbeiten zu können, ist ein gewisser Fundus an Hintergrundwissen unerlässlich. Da dies jedoch den Rahmen dieses Beitrages sprengen würde, da einfach auf die Wikipediaartikel verwiesen:

• Ext2 bei Wikipedia
• Ext3 bei Wikipedia
• Reiserfs bei Wikipedia

Um Informationen zu einem Dateisystem zu erhalten bieten sich diverse Tools an.

Um z.B. ein Ext2 Dateisystem ein wenig genauer unter die Lupe zu nehmen verwendet man das Programm dumpe2fs. So lassen scih z.B. Informationen über die Lage der Ersatz-Superblöcke mit dem Schalter -h herausfinden.

Möchte man hingegen interaktiv in das Dateisystem eingreifen, so ist das Programm debugfs die erste wahl. Es bietet nach dem Aufruf eine Art Kommandozeile, mit Hilfe derer man z.B. direkt auf einzelne Blöcke und sogar Inodes zugreifen kann. Für den Fall, dass man ReiserFS verwendet, so lautet das Äquivalent debugreiserfs.

Da es sich bei der oben aufgeführten Form von Eingriff um eine ziemlich gefährliche Angelegenheit handelt, gibt es für die rudimentären Aufgaben das Programm tune2fs (für Ext-Dateisysteme). Hiermit hat man die Möglichkeit folgende Parameter des Dateisystems zu ändern:

• -c max-mount-counts Wie oft kann das Dateisystem gemountet werden, bevor ein fsck gestartet wird.
• -C mount-counts setzt die Anzahl der bisher durchgeführten Einhängevorgänge per Hand.
• -i Intervall Wenn keine häufigen Einhängeversuche durchgeführt werden, definiert Intervall die Zeit, nachder unabhängig von max-mount-counts das Dateisystem überprüft wird.
• -j Hinzufügen eines Journal zum Dateisystem
• -T datum Definiert das DAtum des letzten Dateisystemchecks im Superblock
• -e wert Wert definiert das Verhalten, wenn bei dem letzten Dateisystemcheck ein Fehler aufgetreten ist. Möglich ist z.B. Continue, remount-ro oder panic.
• -m Prozent Wie viel Prozent des Dateisystems wird für den Systemverwalter reserviert.
• -r Zahl Wie -m nur das hier direkt die Anzahl der Blöcke angegeben wird.
• -u Benutzer Welcher Benutzer darf die unter -m oder -r reservierten Blöcke nutzen?
• -g Gruppe Wie -u nur dass hier eine Gruppe definiert wird.
• -U UUID Setzt die automatisch generierte UUID per Hand.
• -M Verzeichnis Setzt den zuletzt verwendeten Mountpunkt händisch. Dieser wird im Superblock gespeichert.

Automount

Automount dient dazu automatisch Dateisysteme zu mounten, sobald die benötigt werden. Dazu benutzt der Dienst autofs eine Konfigurationsdatei wie z.B. /etc/auto.master.

Diese Datei enthält Pro Zeile einen Eintrag in der Form:

Sammel-Mountpunkt Konfigurationsdatei Optionen

Ein solcher Eintrag sorgt dafür, dass Sammel-Mountpunkt überwacht wird und entsprechende Dateisysteme aus der Datei Konfigurationsdatei mit den dazugehörigen Optionen bei Bedarf einhängt.

Die Konfigurationsdatei ist in etwa wie folgt aufgebaut:

Name-des-Dateisystemmountpunktes -fstype-mit-Optionen :überwachtes Gerät

Hierbei achtet der automountdienst darauf, dass wenn ein Zugriff auf das Verzeichnis (Name-des-Dateisystemmountpunktes) statt findet das überwachte Gerät mit den (optionalen) fstype-Optionen eingehängt wird.