1.111.6 – Verwalten der Systemzeit

zurück zu Linux Zertifizierungen LPIC
Prüfungskandidaten sollten in der Lage sein, die Systemzeit richtig zu verwalten und die Uhr über NTP zu synchronisieren. Dieses Lernziel beinhaltet das Setzen von Systemdatum und -zeit, das Setzen der BIOS-Uhr auf die korrekte Zeit in UTC, die Konfiguration der korrekten Zeitzone des Systems und die Konfiguration der automatischen Korrektur der Zeit auf die NTP-Uhr.

Die wichtigsten Dateien, Bezeichnungen und Anwendungen:

* date
* hwclock
* ntpd
* ntpdate
* /usr/share/zoneinfo
* /etc/timezone
* /etc/localtime
* /etc/ntp.conf
* /etc/ntp.drift

Linux arbeitet mit zwei verschiedenen Uhren, die beide eine große Rolle spielen, die Hardware-Uhr (oder auch RTC, RealTimeClock, CMOS-Uhr, BIOS Uhr) und die Systemzeit. Um mit Linux und der Uhrzeit korrekt umzugehen müssen diese beiden Systeme genau unterschieden werden.

Die Hardware-Uhr ist ein Uhrenbaustein, der völlig unabhängig vom verwendeten Betriebssystem arbeitet. Es handelt sich um eine batteriegepufferte Uhr, die also selbst dann arbeitet, wenn der Computer ausgeschaltet (und von der Stromversorgung getrennt) ist.

Die Systemuhr von Linux ist eine Software-Uhr, die ein Teil des Linux-Kernel ist und durch einen regelmäßigen Timer-Interrupt gesteuert wird. Diese Software-Uhr zählt die Sekunden, die seit dem 1. Januar 1970 um 0:00 Uhr vergangen sind.

Unter Linux zählt nur die Systemzeit, also die kernelgesteuerte Software-Uhr. Der einzige Punkt, wo die Hardware-Uhr ins Spiel kommt ist der Moment des Systemstarts, wo die Systemzeit gestellt werden muß. Hier wird die Hardware-Uhr gelesen und die Systemzeit entsprechend eingestellt. Danach wird die Hardware-Uhr nicht weiter benutzt bis zum nächsten Systemstart.

Es gibt im Wesentlichen zwei Programme, die benutzt werden um auf die beiden Uhren zuzugreifen:

* date
Anzeigen und Stellen der Systemzeit
* hwclock
Anzeigen und Stellen der Hardware-Uhr

Bei Unix/Linux-Systemen bestehen jetzt zwei grundsätzliche Möglichkeiten, wie die Uhr gestellt werden sollte. Zum einen können wir die Uhr einfach nach der lokalen Zeit stellen, zum anderen haben wir die Möglichkeit, die Hardware-Uhr (und damit auch die Systemzeit) nach der UTC (Greenwich Mean Time) zu stellen und uns anhand einer entsprechenden Zeitzoneninformation die lokale Zeit daraus ausrechnen zu lassen. Diese zweite Möglichkeit ist heute die, der im Allgemeinen der Vorzug gegeben wird. Auch die Lernziele der LPI102 Prüfung zielen auf diese zweite Möglichkeit ab, also werden wir uns entsprechend daran halten.

Der Vorgang ist eigentlich ganz einfach. Wir stellen die Hardware-Uhr manuell (über das BIOS-Setup) auf Greenwich-Zeit und weisen der Umgebungsvariable TZ (TimeZone) den Wert zu, der unsere lokalen Zeitzone entspricht. Das verbreitete Shellscript tzselect bietet eine Auswahlmöglichkeit für die zur Verfügung stehenden Zeitzonen. In einigermaßen modernen Linuxen besteht zudem die Möglichkeit, in der Datei /etc/timezone die aktuelle Zeitzone einzutragen.

Die moderne Standard-Library von Linux kennt noch eine genauere Methode. Im Verzeichnis /usr/share/zoneinfo befinden sich binäre Informationsdateien für jede Zeitzone der Welt (inkl. Antarktis). Im Verzeichnis /etc kann jetzt ein symbolischer Link mit Namen localtime angelegt werden, der auf die entsprechende Zonendatei zeigt, also z.B. für Deutschland

ln -s /usr/share/zoneinfo/Europe/Berlin /etc/localtime

Um das zu vereinfachen existiert auf vielen Linuxen ein Script mit Namen tzconfig, das genau die Zeitzone abfrägt und anschließend den Link erstellt.

Ist die Zeitzone richtig eingestellt, so verhalten sich alle Linux-Programme, die mit Uhrzeiten arbeiten, automatisch korrekt. Jetzt können wir z.B. auch unsere Hardware-Uhr oder die Systemzeit stellen und die Programme hwclock und date rechnen aus der angegebenen Lokalzeit und der Information der Zeitzone die Greenwich-Zeit aus und stellen die Uhren entsprechend.

Damit Linux jetzt weiß, daß unsere Hardware-Uhr (und die Systemuhr) auf UTC (Greenwich) eingestellt ist, benutzen wir wieder das Programm hwclock. In einem Init-Script sollte die Anweisung

hwclock –utc –hctosys

stehen. (Falls die Uhr aber auf lokaler Zeit steht sollte statt –utc eben –localtime eingetragen sein)
date
Der Befehl date ist der normale Weg, wie auf die Systemzeit von Unix zugegriffen werden kann. Er bezieht sich aber immer auf die Systemzeit und nicht auf die CMos-Uhr (RTC Real-Time-Clock).

Als einfachste Form der Anwendung kann date einfach ohne Parameter aufgerufen werden. Dann gibt er die Systemzeit in einem String der Form

Sat Aug 21 14:17:40 MEST 1999

auf die Standard-Ausgabe aus. Das ist aber, gerade für Nicht-Amerikaner, nicht immer die gewünschte Form. Aus diesem Grund bietet date auch die Möglichkeit, eine beliebige Ausgabeform für ein Datum zu erstellen.

Wenn date einen Parameter erhält, der mit einem Pluszeichen (+) beginnt, so interpretiert es die folgende Zeichenkette und ersetzt bestimmte Elemente darin mit den entsprechenden Werten der Systemzeit.

Diese interpretierten Elemente beginnen immer mit einem Prozentzeichen (%) dem ein Buchstabe folgt. So bedeutet etwa das %H die Stunden im 24 Stunden-Modus, %M die Minuten. Wenn wir also nur wissen wollen, wie spät es gerade ist, könnten wir schreiben:

date „+Es ist jetzt %H Uhr und %M Minuten“

Die Anführungszeichen sind nötig, weil in unserer Zeichenkette Leerzeichen enthalten sind. Die Ausgabe des Befehls wäre jetzt etwas in der Art:

Es ist jetzt 14 Uhr und 25 Minuten

Eine genaue Darstellung aller unterstützter Parameter ist in der Handbuchseite aufgeführt.

Der Systemverwalter kann mit dem Befehl date auch die Systemuhr stellen, allerdings wird nur die Systemzeit, nicht die CMos-Zeit verändert. Dazu gibt es zwei Möglichkeiten:

1. Dem Kommando date folgt ein Parameter in der Form MMDDhhmm, also eine Zeichenkette, deren erste zwei Zeichen die Monatszahl (01-12) enthält, die nächsten zwei den Tag des Monats (01-31), die nächsten die Stunden (00-23) und die letzten die Minuten (00-59). Optional kann die Zeichenkette auch noch eine zwei oder vierstellige Jahreszahl und danach, durch einen Punkt getrennt die Angabe der Sekunden (zweistellig) enthalten. (MMDDhhmmYYYY.ss)
2. Das Kommando date wird mit dem Schalter -s und einem darauffolgendem Datum der Art „Sat Aug 21 14:17:40 MEST 1999“ aufgerufen. Das macht in der Regel nur dann einen Sinn, wenn vorher das date-Programm benutzt wurde um diese Zeit abzuspeichern, oder wenn ein date eines Rechners benutzt wird, die Uhren anderer Rechner zu stellen.

Verlässlichere Uhren
Sowohl die Hardware-Uhr, als auch die kernelbasierte Systemuhr sind nicht besonders verlässlich. Zwar bietet die Systemuhr die Möglichkeit über ausgeklügelte Mechanismen wie die Datei /etc/adjtime die Genauigkeit der Zeit zu erhöhen, aber eine wirklich hundertprozentige Zeit ist das auch nicht. Gerade aber bei Servern, die monatelang laufen, summiert sich auch eine kleine Ungenauigkeit auf eine störende Größenordnung. Aus diesem Grund gibt es ein spezielles Protokoll, das eine Synchronisation der Zeit über das Netz ermöglicht: das Network Time Protocol (NTP).

Damit NTP aber vernünftig arbeiten kann, benötigt es eine verläßliche Quelle für die Uhrzeit. Ein NTP-Server wird in der Regel eine Funkuhr besitzen, die eine absolut genaue Uhrzeit für den Rechner zur Verfügung stellt. Diese genaue Zeit kann er jetzt an NTP-Clients weitergeben.

Der Haken an dieser Sache ist, daß Pakete, die über das Netz transportiert werden, auch eine bestimmte Zeit benötigen, von einem Rechner zum anderen zu kommen. In einem lokalen Netz ist dieser Wert vernachlässigbar, im Internet können schon einige Sekunden zusammenkommen, je nach aktueller Verbindungsqualität und der Anzahl der Router, die zwischen den beiden Kommunikationspartnern liegen.

NTP hat auch für diese Frage eine Lösung parat. In der Regel werden nicht nur ein, sondern mehrere Server im Internet als Zeitquelle benutzt. Zu jedem Server wird eine Verbindung aufgebaut, und der Client errechnet sich aktuell, wieviel Zeit eine solche Verbindung dauert. Dazu sendet er eine Anfrage und wartet auf die Antwort. Er misst die entsprechend vergangene Zeit und errechnet sich so ein Mittel der Dauer, die ein Paket vom NTP-Server zu ihm benötigt. So kann er – mit mehreren Servern – auf eine Genauigkeit im Millisekundenbereich kommen, was völlig ausreicht, da unsere Uhr als kleinste Einheit sowieso mit Sekunden arbeitet.

Grundsätzlich geht es in diesem Zusammenhang nicht um den Aufbau eines NTP-Servers, der mit einer Funkuhr ausgestattet ist, sondern um die Anbindung eines Clients an einen existierenden Server. Diese Aufgabe ist sehr einfach zu realisieren, es gibt aber zwei verschiedene Möglichkeiten, einer solchen Anbindung:

* Anbindung über einen ständig laufenden Daemon-Prozess mit ntpd
* Anbindung über einen cron-gesteuerten Aufruf von ntpdate

Beide Möglichkeiten arbeiten mit dem NTP-Protokoll, aber im ersten Fall arbeitet unser Rechner auch als Server, während er im zweiten Fall nur Client ist.
Zeitsynchronisation mit ntpdate
Wenn es nur gewünscht ist, eine regelmäßige Anpassung der Uhrzeit über einen bestehenden Zeitserver vorzunehmen, so genügt es, mit dem Programm ntpdate die Uhrzeit eines öffentlichen Zeitservers einzuholen. In diesem Fall kann unsere Systemzeit vollkommen verstellt sein, die Uhrzeit (und das Datum) werden einfach vom genannten Server übernommen. Der Aufruf lautet:

ntpdate Zeitserver

wobei der Zeitserver entweder über seinen Namen oder seine IP-Adresse angegeben werden kann. Eine Liste öffentlicher Zeitserver im Internet ist unter https://www.eecis.udel.edu/~mills/ntp/clock1.htm erhältlich.

Natürlich bietet es sich an, diesen Aufruf regelmäßig über cron vorzunehmen. Ein entsprechender Eintrag in /etc/crontab könnte also lauten:

12 * * * * root /usr/sbin/ntpdate ntp3.fau.de

Damit würde einmal stündlich (jeweils um 12 Minuten nach der vollen Stunde) die aktuelle Uhrzeit vom Server ntp3.fau.de (einem öffentlichen Zeitserver der Universität Erlangen) geholt und die Systemzeit danach gestellt.
Zeitsynchronisation mit ntpd
Komplexer ist die Aufgabe, die Zeit über einen Daemon zu stellen. Der ntpd oder auch xntpd ermöglicht diese Form der Synchronisation. Der Daemon synchronisiert sich alle 5 Minuten mit einem oder mehreren Zeitservern oder einer lokalen Funkuhr. Seine Konfiguration erhält er über die Datei /etc/ntp.conf. In dieser Datei stehen im einfachsten Fall nur zwei Einträge:

server ntp3.fau.de
driftfile /etc/ntp.drift

Die erste Zeile bestimmt den verwendeten Zeitserver, von dem regelmäßig (alle 5 Minuten) die Zeit geholt werden soll. Die zweite Zeile bestimmt eine Datei, die ntpd selbst anlegt und in der die Abweichung der Systemzeit zur realen Zeit gespeichert wird. ntpd ermittelt über Stunden hinweg die Ungenauigkeit der lokalen Zeit und ermittelt einen Wert der Ungenauigkeit in PPM (Parts per Million), der als einfache Fließkommazahl in der Datei /etc/ntp.drift abgelegt wird. Bei jedem Neustart von ntpd kann dann mit diesem Wert gerechnet werden.

Bei der Verwendung von ntpd als Daemon haben wir jetzt neben einer genauen Uhrzeit die Möglichkeit, selbst als Zeitserver für lokale Clients aufzutreten.

Im Gegensatz zur Verwendung von ntpdate darf die Systemzeit unseres Rechners aber nie wirklich größere Abweichungen enthalten. Sobald unsere lokale Zeit mehr als 1000 Sekunden Verschiebung zur Zeit des Servers enthält, weigert sich ntpd die Zeit tatsächlich zu stellen, sondern fordert (in einer Syslog-Meldung) dazu auf, die Zeit manuell zu stellen.

Es ist nicht möglich, beide Techniken auf einmal zu betreiben. Ein Versuch, ntpdate aufzurufen, obwohl ein lokaler ntpd-Prozess läuft, endet mit der Fehlermeldung:

13 Aug 14:37:05 ntpdate[3209]: the NTP socket is in use, exiting

Beide Programme benutzen den selben Socket, können also nicht nebeneinander existieren. Es ist aber sehr wohl möglich, im entsprechenden init-Script, das ntpd starten soll, einen Aufruf von ntpdate vor dem Aufruf des Daemons zu veranlassen, um sicherzustellen, daß die Systemzeit keine zu große Abweichung aufweist.

1.111.5 – Datensicherungsstrategie

zurück zu Linux Zertifizierungen LPIC
1.111.5 – Aufrechterhaltung einer effektiven Datensicherungsstrategie
Prüfungskandidaten sollten in der Lage sein, eine Sicherungsstrategie zu planen und Dateisysteme automatisch auf verschiedene Medien zu sichern. Die Tätigkeiten beinhalten das Sichern einer rohen Partition in eine Datei oder umgekehrt, das Durchführen teilweiser und manueller Backups, das Überprüfuen der Integrität von Backupdateien und teilweises oder vollständiges Wiederherstellen von Backups.

Die wichtigsten Dateien, Bezeichnungen und Anwendungen:

* cpio
* dd
* dump
* restore
* tar

Dieser Abschnitt der LPI102 Prüfung erfordert nicht nur das Wissen um die konkrete Syntax einzelner Befehle, sondern auch die grundsätzliche Architektur von Backup-Strategien. Backups werden heute mit den unterschiedlichsten Programmen erstellt und auf unterschiedlichsten Medien abgelegt. Die genaue Syntax aller hier denkbarer Programme ist sicherlich etwas, was den Rahmen sowohl der LPI-Prüfung, als auch dieser Darstellung sprengen würde. Die wichtigsten Bordmittel werden aber hier genau besprochen.

Vorüberlegungen
Grunsätzlich ist zu sagen, daß ein Backup auf jedem Rechner notwendig ist, dessen Dateien nicht rein statisch sind. Ein Rechner, der etwa nur als Router ins Internet Dienst tut, muß sicherlich kein regelmäßiges Backup ausführen, hier würde die einmalige Sicherung nach der abschließenden Konfiguration ausreichen. Jeder Rechner, auf dem gearbeitet wird, dessen Dateien also nicht statisch sind, muß aber regelmäßige Backups erledigen, um die getane Arbeit zu sichern. Wie im einzelnen die Backups aussehen, was gesichert wird, das muß gründlich geplant werden.

Ein wesentliches Kriterium für ein Backup ist die Frage, auf welches Medium die gesicherten Daten gespeichert werden sollen. Es bietet sich grundsätzlich an, Wechselmedien zu benutzen, die an einem anderen Ort gelagert werden können. Wird ein Backup nur auf eine zweite Platte im Rechner gemacht, so haben wir vielleicht eine Absicherung gegen eine physikalische Zerstörung der Platte (Headcrash), Feuerschäden, Wasserschäden oder Diebstahl des Rechners würde diese Form des Backups nicht abdecken, die Daten wären verloren.

Wechselmedien stehen in verschiedenen Formen zur Verfügung. Neben Wechselplatten, die auf der Festplattentechnik beruhen, sind es meist Bandlaufwerke, die für Backups verwendet werden. Hier spielen drei wesentliche Familien eine Rolle, Viertelzoll-Cartridges (QIC), DAT-Cassetten und Videobänder.

Die Speicherkapazität eines Backup-Mediums ist von großer Bedeutung. Muß das Medium während des Backups gewechselt werden, weil es nicht genügend Speicherplatz aufweist, so kann ein Backup nicht vollständig automatisiert werden. Der Aufwand (und damit auch die Hemmschwelle) ist wesentlich größer, als bei einem Medium, das das ganze Backup in einem Rutsch aufnehmen kann.

Die Frage, was überhaupt gesichert werden muß, ist die nächste Überlegung. Wir unterscheiden zwischen verschiedenen Backup-Strategien. Insbesondere zwei Begriffe werden hier immer wieder fallen: volles Backup und inkrementelles Backup.

Ein Vollbackup ist ein Backup, das alle Daten, die gesichert werden müssen, in einem Arbeitsgang auf ein Medium speichert. Ein inkrementelles Backup speichert im Gegensatz dazu nur die Daten, die sich seit dem letzten Backup verändert haben. Ein inkrementelles Backup ist nur in Zussammenarbeit mit einem Vollbackup möglich!. Abhängig von der Sicherheitsanforderung kann z.B. überlegt werden, jeden Tag der Woche ein inkrementelles Backup vorzunehmen, und Freitags ein Vollbackup. Das bedingt aber, daß alle Medien, die diese Backups aufgenommen haben, zu einer Wiederherstellung (restore) der Daten benötigt werden.

Nehmen wir ein Beispiel: Wir haben folgenden Backup-Plan:

* Montag – inkrementelles Backup – Band 1
* Dienstag – inkrementelles Backup – Band 2
* Mittwoch – inkrementelles Backup – Band 3
* Donnerstag – inkrementelles Backup – Band 4
* Freitag – volles Backup – Band 5

Es ist jetzt Mittwoch, wir haben einen Headcrash, der uns zwingt, alle Daten auf eine neue Platte aufzuspielen. Wie müssen wir vorgehen?

Die Reihenfolge des Wiederaufspielens ist hier wichtig. Wir brauchen:

* Das Band mit dem letzten Vollbackup (Band 5)
* Die Bänder der letzten inkrementellen Backups vom letzten Vollbackup bis zum Eintreten der Katastrophe. Also in unserem Beispiel die Bänder von Montag und Dienstag (Band 1 und 2)

Das Wiederaufspielen muß jetzt in genau der Reihenfolge passieren, wie das Backup selbst. Zunächst spielen wir die Daten des Vollbackups wieder auf die Platte, dann die des Montag-Bandes und erst dann die des Dienstag-Bandes. Nur so stellen wir sicher, daß wir nicht alte Versionen von Dateien aufspielen, die die neueren wieder überschreiben…

Das ist ein aufwendiges Verfahren, das in der Praxis selten vorkommt. Um variabel mit Kombinationen von vollen und inkrementellen Backups arbeiten zu können, werden sogenannte Backup-Level definiert. Dabei wird ein Vollbackup immer Level 0 genannt, ein inkrementelles Backup hat dann Levelnummern größer als 0. Jedes inkrementelle Backup, egal welche Levelnummer es trägt, sichert immer alle Daten, die sich seit dem letzten Backup mit einer Nummer niedriger verändert haben. Ein Beispiel:

* Erster Montag des Monats
Level 0 (Vollbackup)
* Jeder andere Montag
Level 1 (wöchentliches inkrementelles Backup relativ zu Level 0)
* Dienstag
Level 2 (tägliches inkrementelles Backup relativ zu Level 1)
* Mittwoch
Level 2 (tägliches inkrementelles Backup relativ zu Level 1)
* Donnerstag
Level 2 (tägliches inkrementelles Backup relativ zu Level 1)
* Freitag
Level 2 (tägliches inkrementelles Backup relativ zu Level 1)

In diesem Fall brauchen wir für ein Wiederherstellen (restore) der Daten immer nur das aktuellste Band von jedem Level. Da jeder Level über 0 immer alle Daten sichert, die seit dem letzten Backup des vorgehenden Levels verändert wurden hat z.B. das Donnerstagsband immer auch die Daten gespeichert, die am Mittwoch verändert wurden. Es speichert ja alle Daten, seit dem letzten Backup mit niedrigerer Nummer, also seit Montag.

Zum Wiederherstellen der Daten nach einer Katastrophe am Freitag brauchen wir also

* Das letzte Vollbackup (Level 0)
* Das letzte inkrementelle Wochenbackup (Level 1)
* Das letzte inkrementelle Tagesbackup vom Donnerstag (Level 2)

Das Wiederaufspielen der Daten erfolgt jetzt in genau dieser Reihenfolge; zuerst das Vollbackup, dann Level 1 und erst dann Level 2. Jetzt ist garantiert, daß immer die aktuellsten Versionen der Dateien wiederaufgespielt sind.
Planung von Backups
Bei der Planung einer Backup-Strategie müssen ein paar Fragen durchüberlegt werden, deren Beantwortung das Backup leichter planbar machen. Wenn wir schon bei der Planung der Architektur des ganzen Systems auf solche Kriterien achten, können wir uns das Leben wesentlich erleichtern.

Die wichtigste aller Fragen ist die, welche Dateien überhaupt gesichert werden müssen. Bei einer vernünftigen Planung eines Systems können einige Teilbereiche des Systems völlig statisch angelegt werden. Das kann seinen Ausdruck dann darin finden, daß ganze Partitionen Read-Only gemountet werden, so daß selbst versehentliche Änderungen nicht möglich sind. Ein Beispiel hierfür ist die Tatsache, daß das /usr-Verzeichnis geradezu dafür gemacht ist, nur lesend eingehängt zu werden. Solche Bereiche können wir einmal – direkt nach der Installation – sichern und müssen sie dann nie wieder in unsere Backup-Überlegungen aufnehmen…

Eine weitere Überlegung beim Aufbau des Systems ist die, wo die User eines Systems Daten ablegen dürfen und wo nicht. Gibt es hier strenge Richtlinien, die etwa festlegen, daß User ihre Daten grundsätzlich nur in ihren Home-Verzeichnissen ablegen dürfen und diese Homeverzeichnisse auf einer separaten Partition liegen, dann ist durch das Backup dieser einen Partition schon der wesentliche Datenbesatz gesichert. Die Daten der User sind auf alle Fälle nicht verloren.

Ein weiterer wichtiger Bereich, der immer Teil des Backups sein sollte, ist der Bereich der Systemkonfigurationsdateien in /etc. Diese Konfiguration ist vielleicht nicht so hochdynamisch wie der Userdatenbereich, aber er enthält doch auch einige Daten, die sich oft verändern können. Neue oder veränderte Passwörter, die gesammte Arbeit der Systemkonfiguration usw. Um zu vermeiden, daß ein zu großer Datenbestand gesichert werden muß, ist es auch möglich, ein Verzeichnis auf einem Dateisystem anzulegen, das regelmäßig im Backup aufgenommen wird (z.B. /home). Dann wird ein Shellscript erstellt, das alle wichtigen Systemkonfigurationen aus /etc dorthin kopiert. Etwas wie

#!/bin/bash

cp /etc/passwd /home/backup
cp /etc/shadow /home/backup
cp /etc/group /home/backup
cp /etc/gpasswd /home/backup
cp /etc/fstab /home/backup

Dieses Script sollte jetzt täglich von cron aufgerufen werden. Damit ist sichergestellt, daß die wichtigsten Konfigurationsdateien ins Backup aufgenommen sind.

Backup mit dump
Das Programm dump bietet alle Funktionalität, um entweder ganze Dateisysteme (Partitionen) oder einzelne Verzeichnisse in ein Backup aufzunehmen. Die ursprüngliche Version von dump kommt aus der BSD Unix Welt, das Linux-Dump Programm ist aber eine eigene Version, die speziell für das EXT2 Dateisystem geschrieben wurde. Es gibt heute aber auch schon Versionen für weitere Dateisystemtypen, insbesondere für das ReiserFS.

Dump untersucht Dateien eines Dateisystems und entscheidet, welche Dateien in ein Backup aufgenommen werden müssen. Diese Dateien werden dann auf das angegebene Backup-Medium geschrieben, das entweder eine Platte, ein Band oder eine Datei sein kann. (Einstellbar mit der -f Option)

Passt das Backup nicht auf das angegebene Medium, so fordert dump zu einem Medienwechsel auf, und verteilt das Backup auf mehrere solcher Medien.

Dump unterstützt 10 Backup-Level (0-9), wobei wie oben beschrieben das Level 0 ein Vollbackup meint und jedes weitere Level ein inkrementelles Backup relativ zum letzten Backup des nächst-niedrigeren Levels bedeutet. Die grundsätzliche Aufrufform von dump ist

dump [-Level] [-u] [-f Backupdatei] Dateisystem

oder

dump [-Level] [-u] [-f Backupdatei] Verzeichnis

Wobei meist also zuerst das Backup-Level angegeben wird (0-9), gefolgt von einem u (update /etc/dumpdates). Mit der Anweisung -f Backupdatei wird das Medium gewählt. Hier steht also entweder eine Gerätedatei des verwendeten Bandlaufwerks oder ein Dateiname, der Datei, die das Backup aufnehmen soll. Die abschließende Angabe des Dateisystems oder Verzeichnisses gibt an, was gesichert werden soll.

Passt das Backup nicht auf das angegebene Medium, so fordert dump zu einem Medienwechsel auf, und verteilt das Backup auf mehrere solcher Medien.

Dump unterstützt 10 Backup-Level (0-9), wobei wie oben beschrieben das Level 0 ein Vollbackup meint und jedes weitere Level ein inkrementelles Backup relativ zum letzten Backup des nächst-niedrigeren Levels bedeutet. Die grundsätzliche Aufrufform von dump ist

dump [-Level] [-ua] [-f Backupdatei] Dateisystem

oder

dump [-Level] [-ua] [-f Backupdatei] Verzeichnis

Wobei meist also zuerst das Backup-Level angegeben wird (0-9), gefolgt von einem u (update /etc/dumpdates) und einem a, das die automatische Bandendeerkennung aktiviert. Dieses -a Argument ist bei modernen Bandlaufwerken besser als die Kalkulation, wieviel Daten auf das Band passen und wann es gewechselt werden muß. Bei der Verwendung von Dateien als Medium ist es unabdingbar diese Option zu setzen! Mit der Anweisung -f Backupdatei wird das Medium gewählt. Hier steht also entweder eine Gerätedatei des verwendeten Bandlaufwerks oder ein Dateiname, der Datei, die das Backup aufnehmen soll. Die abschließende Angabe des Dateisystems oder Verzeichnisses gibt an, was gesichert werden soll.

Die Datei /etc/dumpdates speichert die Daten alle bisherigen Backups in der Form:

/dev/hda8 0 Sat May 5 21:56:49 2001
/dev/hda8 1 Mon May 7 21:55:58 2001

Hier zeigt sich also, daß die Partition /dev/hda8 am Samstag, den 5. Mai 2001 um 21:48 Uhr ein Vollbackup (Level 0) erhalten hat, während am darauffolgenden Montag ein inkrementelles Backup (Level 1) ausgeführt wurde.

Der Aufruf

dump -0ua -f /dev/tape /dev/hda8

hatte das erste dieser beiden genannten Backups erstellt, das zweite wurde mit

dump -1ua -f /dev/tape /dev/hda8

erstellt.

Es sei hier an dieser Stelle noch einmal ausdrücklich an die Datei /etc/fstab erinnert, deren fünftes Feld die Frage klärt, ob die jeweilige Partition von dump bearbeitet werden soll, oder nicht.
Daten wiederherstellen mit restore
Das Gegenstück zum Programm dump ist restore, mit dem sich Daten von einem Backup-Medium wiederherstellen lassen. Dieses Programm hat sehr viele verschiedene Anwendungen, die alle mit Kommandozeilenparametern einstellbar sind. Die wichtigsten Aktionen für die wir dieses Programm brauchen sind nicht nur das Wiederherstellen von Daten, sondern auch der Vergleich eines Backups mit dem Orginaldatenbestand. Damit können wir bei wichtigen Backups die Konsistenz des Backups überprüfen.

Wichtige Aufrufformen von restore sind:

restore -C -f Datei

Das Backup, das sich in der Datei (Gerätedatei eines Tapes oder Datei) befindet wird mit dem Orginaldatenbestand verglichen. Eventuell auftretende Unstimmigkeiten werden angezeigt.

restore -i -f Datei

Das Backup, das sich in der Datei (Gerätedatei eines Tapes oder Datei) befindet wird mit einem interaktiven – shellähnlichen – Mechanismus durchwandert. Einzelne Dateien und Verzeichnisse können markiert werden und dann können alle markierten Dateien wiederhergestellt werden. Die wichtigsten Befehle dieser shellähnlichen Oberfläche sind:

cd Verzeichnis
Wechselt in das angegebene Verzeichnis.
ls [Verzeichnis|Datei]
Zeigt den Inhalt eines Verzeichnisses oder den Namen einer Datei. Ist eine Datei zur Wiederherstellung markiert, wird das durch ein * angezeigt.
add Verzeichnis|Datei
Das angegebene Verzeichnis oder die angegebene Datei wird zur Wiederherstellung markiert. Ist es ein Verzeichnis so werden alle darin enthaltenen Dateien auch in die Liste der zu wiederherstellenden Dateien aufgenommen (wenn nicht die -h Option auf der Kommandozeile gesetzt war).
delete Verzeichnis|Datei
Das angegebene Verzeichnis oder die angegebene Datei werden von der Liste der wiederherzustellenden Dateien gestrichen.
extract
Die Dateien und Verzeichnisse, die in der Liste der wiederherzustellenden Dateien aufgelistet sind werden wiederhergestellt.
quit
Das Programm wird beendet.

Zu beachten ist, daß restore beim Widerherstellen die Dateien im aktuellen Verzeichnis auspackt. Sollen also Dateien eines Dateisystems /dev/XXX wiederhergestellt werden, so bietet es sich an, auf die Wurzel dieser Partition zu wechseln.

restore -r -f Datei

Ein komplettes Dateisystem wird wiederhergestellt. Idealerweise ist das Ziel eine leere, frische Partition, in die dann gewechselt wird um den restore-Befehl auszuführen. Also z.B.:

mke2fs /dev/sda1
mount /dev/sda1 /mnt
cd /mnt

restore -r -f /dev/tape

Das ist die beste Lösung nach einem Plattencrash, wenn die orginale Platte zerstört ist und eine neue Platte komplett restauriert werden muß.

restore -x -f BackupDatei Datei1 Datei2 …

Die angegebenen Dateien (Datei1 Datei2 …) werden von dem Backup der Backupdatei (Gerätedatei oder Datei) gelesen und extrahiert. Auch hier wird wieder ins aktuelle Verzeichnis extrahiert. Sind einzelne der angegebenen zu extrahierenden Dateien Verzeichnisse, dann werden diese Verzeichnisse samt aller Dateien darin wiederhergestellt.

Restore ist also das Programm, mit dem alle Bearbeitung der bereits gemachten Backups vorgenommen werden, insbesondere die Wiederherstellung der gesicherten Dateien.

Ist ein Backup auf mehrere Medien verteilt, so fordert restore zum gegebenen Zeitpunkt zum Medienwechsel auf..

Partielle und manuelle Backups mit tar
Um schnell ein Verzeichnis oder ein paar Dateien zu sichern ist die Anwendung von dump und restore sicherlich übertrieben. Hier findet das Programm tar seine Anwendung. tar steht für Tape Archiver, ist also grundsätzlich auch gedacht gewesen, Backups auf Bandlaufwerke zu schreiben. Heute wird tar aber sehr häufig eingesetzt, um Verzeichnisse oder Dateien in eine Archivdatei zu packen, die dann auf anderen Medien abgespeichert werden kann oder auch an andere User weitergegeben werden kann. Vor der Einführung der modernen Paket-Manager (RPM, DPKG) war das tar-Format das bestimmende Format für Linux-Distributionen.

Tar wird sowohl zum Erstellen, als auch zum Entpacken von Archiven benutzt. Es ist also kein zusätzlicher Entpacker wie etwa restore nötig.

Wie schon dump und restore kennt auch tar die Option -f Dateiname mit der angegeben wird, welche Datei als Medium zum Speichern (oder entpacken) des Archivs verwendet werden soll. Auch hier kann entweder eine Gerätedatei eines Bandlaufwerks, eine reguläre Datei oder ein Bindestrich (für StdIn bzw StdOut) angegeben werden.

Tar selbst nimmt keinerlei Komprimierung vor, arbeitet jedoch gerne mit dem gzip-Programm zusammen. Musste man früher die Archivdatei noch manuell komprimieren, so kennt tar heute die Optionen -z (komprimieren oder dekomprimieren mit gzip) und -Z (komprimieren oder dekomprimieren mit compress – veraltet) um selbstständig gleich gepackte Archive zu erstellen oder zu entpacken. Die jeweiligen Programme gzip und compress müssen dazu aber vorhanden sein, tar ruft sie nur auf, es kann selbst keine Kompression vornehmen.

Die normale Endung einer Archivdatei, die mit tar hergestellt wurde heisst in der Regel .tar – wurde das Archiv mit gzip komprimiert trägt es standardmäßig die Endung .tar.gz oder (um auch DOS-konform zu sein) .tgz. Wurde die Archivdatei mit compress komprimiert, so endet ihr Name meist auf .tar.Z

Die drei wichtigsten Funktionen von tar sind

* Erstellen (create) von Archiven (-c)
* Inhaltsverzeichnis (table of content) von Archiven anzeigen (-t)
* Archive entpacken (extract) (-x)

Um ein Archiv mit dem Namen Test.tgz anzulegen, das mit gzip komprimiert ist und alle Dateien des Verzeichnisses Testdir enthält, rufen wir tar folgendermaßen auf:

tar -czf Test.tgz Testdir

Um den Inhalt dieses frisch geschaffenen Archivs anzusehen schreiben wir:

tar -tzf Test.tgz

Und um das Archiv im aktuellen Verzeichnis wieder zu entpacken ist der Befehl

tar -xzf Test.tgz

nötig. Wird zusätzlich noch die Option -v angegeben, so arbeitet tar „geschwätzig“ (verbose), gibt uns also mehr Informationen mit. Insbesondere beim Ansehen des Inhaltsverzeichnis ist das eine gute Idee. Aber vorsicht: Der erste Parameter von tar legt die Aktion fest (c oder t oder x), die Parameter v und z folgen beliebig. Der f-Parameter kommt am Schluß, denn ihm folgt der Dateiname.
Archive mit cpio bearbeiten
Anstelle von tar kann auch das Programm cpio verwendet werden, um Archive zu erstellen oder zu bearbeiten. cpio kann dabei verschiedene Formate – unter anderem auch das tar-Format – bearbeiten. Ein großer Vorteil von cpio ist der, daß die Liste der zu archivierenden Dateien nicht auf der Kommandozeile (wie bei tar) erwartet wird, sondern auf der Standard-Eingabe. Dadurch ist es möglich, die Ergebnisse etwa des find-Befehls direkt an cpio weiterzupipen und so ein Archiv mit den Suchergebnissen aufzubauen.

cpio arbeitet in drei verschiedenen Modi:

* copy-out
Dateien werden in ein Archiv geschrieben (out meint die Ausgabe in ein Archiv)
* copy-in
Dateien werden aus einem Archiv extrahiert (in meint die Eingabe ins Dateisystem)
* copy-pass
Dateien werden von einem Ort zu einem anderen kopiert, quasi eine Kombination aus copy-out und copy-in, ohne jedoch tatsächlich ein Archiv zu erstellen.

Durch die Verwendung unterschiedlicher Formate und die Fähigkeit die zu archivierenden Dateien sowohl aus einer Dateiliste, als auch von der Standard-Eingabe zu lesen, ist cpio wesentlich flexibler als tar. Allerdings ist es auch um einiges komplizierter anzuwenden.
Ein- und Ausgabe mit dd
Um Dateien beliebiger Art (in unserem Fall speziell Archivdateien) von und auf Gerätedateien zu kopieren, existiert das sehr nützliche (und sehr häufig verwendete) Programm dd. dd steht für DiskDump und ermöglicht es, Daten von Gerätedateien zu regulären Dateien zu kopieren oder umgekehrt. Es ist natürlich auch möglich, von Gerätedatei zu Gerätedatei zu kopieren. Die grundsätzliche Form ist dabei

dd if=Eingabedatei of=Ausgabedatei bs=Blockgröße count=Anzahl

Dieser Befehl kopiert Anzahl Blöcke der Größe Blockgröße aus der Eingabedatei in die Ausgabedatei. Dabei können sowoh Ein-, als auch Ausgabedatei entweder Gerätedateien oder reguläre Dateien sein. Wird die Angabe der Blockgröße weggelassen, so werden die „natürlichen“ Blockgrößen der jeweiligen Geräte verwendet. Wird die Anzahl der zu lesenden Blöcke weggelassen, so werden alle Blöcke der Datei (oder des Gerätes) gelesen. So kann z.B ein komplettes Image einer Festplatte oder Partition (oder Diskette oder CDROM) in eine Datei durch den Befehl

dd if=Gerätedatei_des_Laufwerks of=Imagedateiname

erstellt werden. Mit dem umgekehrten Befehl

dd of=Gerätedatei_des_Laufwerks if=Imagedateiname

wird das entsprechende Image wieder auf das Gerät geschrieben.

Durch die Angabe von ibs= (Input-Blocksize) und obs= (Output-Blocksize) kann sogar noch zwischen verschiedenen Blockgrößen bei Ein- und Ausgabe unterschieden werden.

Zusätzlich kann dd auch noch Konvertierungen der zu kopierenden Blöcke vornehmen, wie etwa die Reihenfolge der Bytes in einem Datenwort oder Klein-Großschreibung.

Für die Backup-Technik ist dd besonders interessant, weil damit Archivdateien direkt auf Band geschrieben werden können oder von Bändern gelesen werden können.

1.111.4 – Systemadministrationsaufgaben

zurück zu Linux Zertifizierungen LPIC
1.111.4 – Automatisieren von Systemadministrationsaufgaben durch Planen von zukünftig laufenden Jobs
Prüfungskandidaten sollten in der Lage sein, cron oder anacron zu verwenden, um Prozesse in regelmäßigen Intervallen ausführen zu lassen, und at zu benutzen, um Jobs zu einer bestimmten Zeit auszuführen. Dies beinhaltet das Verwalten von cron und at Jobs und die Konfiguration von Benutzerzugang zu cron und at Diensten.

Die wichtigsten Dateien, Bezeichnungen und Anwendungen:

* at
* atq
* atrm
* crontab
* /etc/anacrontab
* /etc/at.deny
* /etc/at.allow
* /etc/crontab
* /etc/cron.allow
* /etc/cron.deny
* /var/spool/cron/*

Systemverwaltungsaufgaben bestehen zu einem großen Teil aus immer wiederkehrenden Routinejobs. Diese Routine kann durch Kommandos vereinfacht werden, die automatisch immer wieder in bestimmten Intervallen oder zu bestimmten Zeiten ausgeführt werden. Für diese Aufgabe existiert ein eigener Daemon, der cron-Daemon. Er kann auf verschiedene Weisen konfiguriert werden, die hier genauer beschrieben werden sollen.

Manche Aufgaben sind aber nicht regelmäßig auszuführen, sondern nur genau einmal, aber zu einem ganz bestimmten Zeitpunkt. Diese Aufgabe wird vom at-Daemon gelöst, der genau dazu gemacht ist.

Der cron-Daemon und seine Konfiguration
Der Cron-Daemon überwacht verschiedene Dateien und Verzeichnisse, in denen Anweisungen liegen, die in regelmäßigen Abständen ausgeführt werden sollen. Diese Anweisungen werden Cron-Tabellen oder eben crontabs genannt.

Cron läd beim Start all die Dateien und Verzeichnisse, die er überwacht in den Arbeitsspeicher und überprüft jede Minute einmal, ob darin Jobs enthalten sind, die in der aktuellen Minute ausgeführt werden sollen. Wenn ja, so führt er sie aus. Außerdem überprüft cron jede Minute, ob sich an den Dateien oder Verzeichnissen etwas geändert hat und – falls ja – übernimmt er diese Änderungen im Speicher.

Es gibt also mehrere Möglichkeiten, dem Cron-Daemon einen Job zur Ausführung zu übergeben. Die einzelnen Möglichkeiten sind:

User-Crontabs
Jeder User des Systems kann eine eigene Crontab (also eine Datei mit Anweisungen für Cron) erstellen und bearbeiten. Die Jobs, die darin aufgeführt sind werden von Cron unter der Userkennung des Users ausgeführt, um dessen Crontab-Datei es sich handelt. Die User-Crontabs werden nicht direkt mit einem Editor verändert, sondern mit dem Befehl crontab(1).

Systemweite Crontab-Datei
Im Verzeichnis /etc existiert eine Datei crontab, die ebenfalls Cronjobs definiert. Das Format dieser Datei unterscheidet sich etwas von dem der Usercrontabs – siehe weiter unten…

cron.d Verzeichnis
Im Verzeichnis /etc kann ein Verzeichnis cron.d existieren, das Dateien im selben Format wie /etc/crontab enthalten darf. Auch diese Dateien werden von cron überwacht und darin enthaltene Befehle werden ausgeführt.

cron.{hourly,daily,weekly,monthly} Verzeichnisse
Ebenfalls im /etc/verzeichnis können Verzeichnisse der Namen cron.hourly, cron.daily, cron.weekly und cron.monthly existieren. Diese Verzeichnisse enthalten nicht crontabs, sondern Shellscripts, die entsprechend stündlich, täglich, wöchentlich oder monatlich ausgeführt werden.

Das Format der User-Crontabs
Das Format der Crontabs der User ist etwas speziell, hier das Grundprinzip: Crontab-Einträge sind entweder Definitionen von Shellvariablen oder zeitgesteuerte Cron-Befehle. Leere Zeilen oder Zeilen, die mit einem # beginnen werden ignoriert. Das Kommentarzeichen (#) darf aber nur am Anfang der Zeile stehen mitten in einer Zeile wird es als Teil des Kommandos interpretiert. Die Definition einer Shellvariable hat immer die Form:

Name=Wert

Einige Variablen werden von Cron selbst gesetzt. SHELL wird auf /bin/sh gesetzt, HOME und LOGNAME werden den Informationen über den User aus der /etc/passwd entnommen. Die Variablen SHELL und HOME dürfen verändert werden, LOGNAME nicht.

Normalerweise schickt cron alle Ausgaben von ausgeführten Kommandos per Mail an den User, der das Cron-Kommando ausführen liess. Die Variable MAILTO kann diese Eigenschaft verändern. Wenn sie den Namen eines Users enthält, so werden ihm und nicht dem ursprünglichen Cron-User die Mail geschickt. Ist die Variable MAILTO definiert, aber leer, so wird gar keine Mail verschickt.

Alle anderen Zeilen der Crontabs, die also nicht Variablen definieren, beschreibt Kommandos, die zu bestimmten Zeiten ausgeführt werden sollen. Das grundlegende Format dieser Zeilen ist:

Minute Stunde Tag Monat Wochentag Kommando

Die einzelnen Felder definieren also die Zeit, zu der das angegebene Kommando ausgeführt werden soll. Jedes der fünf Zeitfelder darf statt einem Wert auch ein Sternchen (*) enthalten, das als Jokerzeichen gilt und für jeden beliebigen Wert steht.

Die jeweiligen Zeitfelder dürfen folgende Werte aufnehmen:

Minute 0-59
Stunde 0-23
Tag 1-31
Monat 1-12
Wochentag 0-7 (0 und 7 bedeutet Sonntag)

Auch Bereichsangabe sind erlaubt. Bereiche werden mit Bindestrich definiert. So würde die Angabe 8-11 im Stundenfeld die Stunden 8, 9, 10 und 11 meinen.

Auch Listen sind erlaubt. Listen werden durch Kommata aufgebaut. So würde die Angabe 1,2,5 im Wochentagfeld die Tage Montag, Dienstag und Freitag meinen.

Auch Kombinationen von Listen und Bereichen sind möglich. Die Angabe 1,3,15-19,30 spricht also die Zahlen 1, 3, 15, 16, 17, 18, 19 und 30 an.

Im Zusammenhang mit Bereichen können sogar Schrittweiten angegeben werden. Die Angabe 0-23/2 im Stundenfeld meint also die Stunden 0-23 aber in der Schrittweite 2 Stunden. Also 0, 2, 4, 6, 8, 10, …. Um diesen Schritt zu vervollständigen kann z.B. die Angabe alle zwei Stunden“ einfach mit */2 ausgedrückt werden. Gleiches gilt für alle anderen Zeitfelder.

Das Wochentagfeld und das Tag-Feld sind – wenn beide angegeben sind – aditiv gemeint. Die Angabe

* * 13 * 5 …

meint also nicht alle Freitag der 13., sondern alle Freitage und alle 13. des Monats.

Die letzte Angabe in einer Crontab-Zeile ist der Befehl, der zur gegebenen Zeit ausgeführt werden soll. Er wird von /bin/sh oder der in der Variable SHELL angegebenen Shell ausgeführt.

Eine Beispiel-Crontab könnte also folgendermaßen aussehen – mit Kommentaren zum besseren Verständnis:

# Variablendefinition
SHELL=/bin/bash
PATH=/usr/bin:/bin

# Cronbefehle
# Das Programm foo wird täglich um 23 Uhr 56 ausgeführt
56 23 * * * foo

# Das Programm backup wird jeden Freitag um 17 Uhr 30 ausgeführt
30 17 * * 5 backup

# Alle 2 Stunden zwischen 6 und 23 Uhr wird das Programm fetchmail
# ausgeführt
0 6-23/2 * * * fetchmail

# Am ersten jedes Monats wird um 8 Uhr morgens das Programm bar ausgeführt
0 8 1 * * bar

Wenn der User, dem der crontab gehört die UserID 0 hat, also der Systemverwalter ist, dann kann eine Crontab-Zeile mit einem Bindestrich beginnen. In diesem Fall wird cron die ausgeführte Aktion nicht an den Syslog-Daemon weiterleiten. In jedem anderen Fall wird jede Cron-Aktion ins Logbuch übernommen und kann dort im Nachhinein überprüft werden.

User Crontabs verwalten mit crontab(1)
Die Crontabs der User sind zwar im Dateisystem als einzelne Dateien vorhanden (/var/spool/cron/tabs/Username), können aber dort nicht direkt editiert werden, weil sie nicht dem User gehören. Damit ein User trotzdem eigene Jobs definieren kann, steht ihm das Programm crontab zur Verfügung.

Dieses Programm erlaubt einem User, die folgenden Aktionen:

Anlegen einer neuen Crontab-Datei
Wenn ein User mit seinem Lieblings-Editor eine Datei erstellt hat, die seine Crontab-Befehle im oben beschriebenen Format enthält, und der User bisher keine Crontab besaß oder die bisherige Crontab durch diese neue Datei ersetzen will, dann kann er diese Datei mit dem Befehl

crontab Dateiname

zu seinem Crontab machen.

Ansehen der aktuellen Crontab
Mit dem Befehl

crontab -l

kann sich ein User seine Crontab am Bildschirm anzeigen lassen.

Löschen der Crontab-Datei
Wenn ein User seine Crontab-Datei löschen will, kann er dazu den Befehl

crontab -r

benutzen. Die ganze Crontab-Datei des Users wird dadurch gelöscht – alle bisherigen Jobs sind damit automatisch auch gelöscht. Die Veränderung wird sofort aktiv.

Einträge in der Crontab editieren
Mit dem Befehl

crontab -e

kann ein User seine Crontab-Datei editieren. Dazu wird der Editor aufgerufen, der in der Umgebungsvariable VISUAL bzw. EDITOR definiert ist – meist also der vi. Alle Veränderungen, die vom User dort vorgenommen werden, werden sofort nach dem Sichern und Verlassen des Editors aktiv.

Der Systemverwalter kann dem Programm crontab mit der Option -u username auch noch den User mitgeben, dessen Eintrag bearbeitet werden soll. Er kann also die Einträge jedes Users erstellen, löschen, ansehen und editieren. Ein Normaluser darf selbstverständlich nur seine eigene Datei bearbeiten.

Das Format der Crontabs in /etc
Die Datei /etc/crontab und alle Dateien (beliebigen Namens) im Verzeichnis /etc/cron.d werden auch als Crontabs gewertet und vom Cron-Daemon überwacht und ausgeführt. Im Wesentlichen entspricht das Format genau dem der User-Crontabs, mit einer Ausnahme. Zwischen dem fünften Zeitfeld (Wochentag) und dem Befehl wird hier noch ein Username angegeben, unter dessen ID der Befehl ausgeführt werden soll. Das Format ist also:

Minute Stunde Tag Monat Wochentag Username Kommando

Alle anderen oben genannten Eigenschaften bleiben unverändert, also auch die Bereichs- und Listenangabe der Zeitfelder.

Diese Dateien dürfen nur vom Systemverwalter angelegt und editiert werden, er kann aber durch das zusätzliche Userfeld bestimmen, unter wessen UserID der Befehl ausgeführt werden soll.

Die Verzeichnisse in /etc
Neben der Datei /etc/crontab und dem Verzeichnis /etc/cron.d existieren in vielen Linux-Distributionen (RedHat, Debian, SuSE,…) auch noch die Verzeichnisse

/etc/cron.hourly
/etc/cron.daily
/etc/cron.weekly
/etc/cron.monthly

Diese Verzeichnisse enthalten keine Crontabs, sondern Programme, die entsprechend stündlich, täglich, wöchentlich oder monatlich einmal ausgeführt werden sollen. In der Regel handelt es sich bei diesen Programmen um Shellscripts, die dann wiederum bestimmte Programme aufrufen. Standardeinstellungen, wann diese Programme ausgeführt werden sind:

* cron.hourly – Stündlich jeweils um *:30 Uhr
* cron.daily – Täglich jeweils um 0:00 Uhr
* cron.weekly – Wöchentlich jeweils Samstags um 0:00 Uhr
* cron.monthly – Monatlich jeweils am ersten eines Monats um 0:00 Uhr

In der Regel sind diese Verzeichnisse für regelmäßige Kommandos gemacht, die schon beim Installieren bestimmter Pakete festgelegt sind. Zumeist tragen die Scripts innerhalb dieser Verzeichnisse die Namen der Pakete, die sie installiert haben.

Cron-Dienste für User erlauben oder verbieten
Normalerweise kann jeder User eines Linux-Systems seine eigene Crontab besitzen und beliebige Aufgaben zu beliebigen Zeiten damit erledigen lassen. Das kann er aber nur – wie oben gesehen – durch die Verwendung des Programms crontab. Dieses Programm bietet aber auch eine Art Zugriffsschutz, mit dem der Systemverwalter einzelnen Usern die Verwendung dieses Programms erlauben oder verbieten kann.

Wie so oft, gibt es hier zwei verschiedene Lösungsansätze. Entweder dürfen nur die User Crontab benutzen, die die ausdrückliche Erlaubnis besitzen, oder alle User dürfen crontab benutzen, denen es nicht explizit verboten wurde.

Dazu kann der Systemverwalter im Verzeichnis /etc mit zwei Dateien arbeiten, die er dort anlegen muß. Die folgenden Möglichkeiten existieren:

Existiert die Datei /etc/cron.allow, dann dürfen nur die User mit crontab arbeiten, die in dieser Datei aufgelistet sind.

Wenn die Datei /etc/cron.allow nicht existiert, stattdessen aber die Datei /etc/cron.deny, dann dürfen alle User mit crontab arbeiten, außer denen, die in der Datei cron.deny aufgelistet sind.

Beide Dateien sind reine Textdateien, die pro Zeile einen Usernamen enthalten dürfen.

In älteren Versionen von Cron lagen diese beiden Dateien nicht in /etc sondern hießen /var/spool/cron/allow und /var/spool/cron/deny. Die Funktionsweise war aber die selbe. Auf manchen älteren Linux-Versionen finden sich noch diese älteren Einstellungen. Nach der Revision hat LPI aber auf die neuen Dateien umgestellt.
anacron
Anacron ist wie cron ein periodischer Kommandoscheduler. Er führt bestimmte Befehle in Intervallen aus, die aber – im Gegensatzt zu cron – nur in Tagen angegeben werden. Der wesentliche Unterschied ist aber der, daß anacron nicht annimmt, daß der Rechner Tag und Nacht läuft.

Wenn cron einen bestimmten Job zu einer Zeit ausführen soll, zu der der Rechner nicht angeschalten ist, dann verfällt dieser Job. Oft ist es zum Beispiel so, daß die täglichen cron-Jobs um 0:00 Uhr ausgeführt werden sollen oder die wöchentlichen am Sonntag (Tag 0). Wenn ein Rechner aber weder Sonntags, noch Nachts läuft, werden diese Jobs niemals ausgeführt. Meist handelt es sich bei diesen Jobs um Verwaltungsaufgaben, wie der Auffrischung bestimmter Systemdatenbanken (locate und man) oder der Rotation der Logdateien.

Anacron kann dieses Problem lösen. Man kann einfach diese Jobs in Intervallen von einem, sieben oder 30 Tagen starten um tägliche, wöchentliche oder monatliche Ausführung zu erzwingen. Anacron führt seine Jobs aus, wenn der letzte Ablauf eines Jobs länger als die genannte Intervallzeit in Tagen her ist. Somit wird ein Job auch dann ausgeführt, wenn der Rechner das nächste Mal angeschalten wird und nicht – wie bei cron – wenn das nächste Wochen- oder Monatsende erreicht ist.

Jedesmal, wenn anacron aufgerufen wird, ließt es seine Konfigurationsdatei (/etc/anacrontab) in der seine Jobs mit den Perioden eingestellt werden. Wenn ein Job die letzten n Tage nicht ausgeführt wurde, wobei n die angegebene Periode dieses Jobs ist, führt anacron ihn aus. Anacron erzeugt dann einen Eintrag in einer speziellen Zeitmarkendatei, die es für jeden Job erstellt, so daß es weiß, wann der Job zuletzt ausgeführt wurde. Wurden alle Kommandos ausgeführt, wird anacron beendet.

Anacron ist also kein Daemon, der die ganze Zeit läuft, sondern muß entweder über init-Scripts oder cron regelmäßig gestartet werden.

Die Konfigurationsdatei von anacron ist sehr einfach aufgebaut. Sie enthält entweder Variablenzuweisungen, die der Umgebung zugewiesen werden, in der der entsprechende Befehl ausgeführt werden soll, oder Befehlszeilen der Form

Periode Verzögerung Job-Identifikation Kommando

Die Periode ist eine Zahl, die die Anzahl von Tagen angibt, die zwischen der letzten Ausführung des Jobs und der nächsten Ausführung mindestens vergangen sein müssen. Die Verzögerung ist ein Wert in Minuten, der angegeben wird, damit nicht alle anacron-Jobs gleichzeitig gestartet werden und so den Rechner unnötig strapazieren. Somit können die verschiedenen Jobs leicht zeitversetzt gestartet werden. Die Job-Identifikation ist ein beliebiges Wort, daß alle Zeichen außer Leerzeichen und Slashs enthalten darf. Mit Hilfe dieses Wortes wird der Dateiname der Zeitmarkendatei erstellt (das ist der Grund für die verbotenen Slashs). Am Ende der Zeile steht dann der auszuführende Befehl. Eine simple /etc/anacrontab Datei könnte also folgendermaßen aussehen:

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

1 1 updatedb updatedb
7 10 logrotate logrotate /etc/logrotate.conf
31 15 tmpclean rm /tmp/*

Jeden Tag, eine Minute nachdem anacron gestartet wurde, wird der Befehl updatedb ausgeführt. Die Zeitmarke wird in eine Datei heißt ebenfalls updatedb.

Alle 7 Tage jeweils 10 Minuten nach dem Start von anacron wird der Befehl logrotate /etc/logrotate.conf ausgeführt. Die Zeitmarkendatei heißt nur logrotate.

Alle 31 Tage werden alle Dateien im /tmp Verzeichnis gelöscht, die Zeitmarkendatei heißt tmpclean. Der Befehl wird 15 Minuten nach Aufruf von anacron gestartet.

Hat anacron all diese drei Befehle abgearbeitet, dann beendet sich das Programm wieder.
Das at-Spoolsystem
Wenn ein Kommando nicht regelmäßig ausgeführt werden soll, sondern nur zu einem ganz bestimmten Zeitpunkt, dann können wir das mit dem at-Kommando erledigen. At ist ein typisches Unix-Spoolsystem, das Aufträge entgegennimmt, in eine Warteschlange stellt und zur gegebenen Zeit dann ausführt. Die Architektur ist wie bei allen anderen Unix-Spoolsystemen ausgeführt:

* Der Befehl at gibt Aufträge in die Warteschlange
* Der Befehl atq zeigt alle Aufträge, die in der Warteschlange stehen.
* Der Befehl atrm löscht einzelne Aufträge aus der Warteschlange.
* Der Daemon atd arbeitet die Warteschlange ab. In älteren Versionen von Linux findet sich kein eigener Daemon, in diesem Fall wurde von cron jede Minute einmal das Programm atrun aufgerufen, das die Warteschlange nach Aufträgen durchsuchte, die im Augenblick ausgeführt werden sollten und – sofern gefunden – diese Jobs ausführte.

Um mit at einen Job in Auftrag zu geben, muß einfach nur der Befehl

at Zeit

aufgerufen werden. Danach kann über die Standard-Eingabe die gewümschte Befehlszeile eingegeben werden, die zu der Angegebenen Zeit ausgeführt werden soll. Um die Eingabe abzuschließen, wird in einer eigenen Zeile das Dateiendezeichen Strg-D eingegeben. Alternativ kann eine Datei angelegt werden, die die Befehle enthält, die zu der bestimmten Zeit ausgeführt werden sollen. Dann kann at entweder mit

at Zeit < Datei

oder mit

at -f Datei Zeit

aufgerufen werden.

Die verschiedenen Formen der Zeitangaben enthehmen Sie bitte der Handbuchseite.

Die Ausgaben der Kommandos, die von at zu bestimmten Zeiten ausgeführt wurden, werden dem User als Mail zugeschickt, der den Auftrag losgeschickt hatte.

Wie schon bei cron, so können wir auch bei at festlegen, wer mit diesem Programm arbeiten darf bzw. wer nicht. Dazu dienen die Dateien /etc/at.allow und /etc/at.deny. Existiert die Datei /etc/at.allow, so dürfen nur die User mit at arbeiten, die dort aufgeführt sind (ein User pro Zeile). Existiert diese Datei nicht, aber die Datei /etc/at.deny, so dürfen alle User at benutzen, außer den Usern, die in at.deny aufgelistet sind. Existieren beide Dateien nicht, so darf nur der Systemverwalter mit at arbeiten.

1.111.3 – Administrative Sicherheitsanforderungen

zurück zu Linux Zertifizierungen LPIC
1.111.3 – Konfigurieren und Nutzen der Systemlogs im Rahmen der administrativen und Sicherheitsanforderungen
Prüfungskandidaten sollten in der Lage sein, die Systemaufzeichnungen zu konfigurieren. Dieses Lernziel beinhaltet das Einstellen der Art und Menge der aufgezeichneten Informationen, das manuelle Prüfen von Logdateien auf wichtige Aktivitäten, das Überwachen der Logdateien, das Einrichten automatischer Rotation und Archivierung der Logs und das Verfolgen von Problemen, die in den Logdateien aufgezeichnet

Die wichtigsten Dateien, Bezeichnungen und Anwendungen:

* logrotate
* tail -f
* /etc/syslog.conf
* /var/log/*

Unter Linux verwaltet ein spezieller Daemon-Prozess ein Systemlogbuch, das von allen Programmen und insbesondere von allen anderen Daemon-Prozessen benutzt werden kann, um Meldungen abzugeben. Dabei kann es sich um Meldungen des normalen Systemablaufs handeln oder um Alarmmeldungen, die sofortiges Eingreifen notwendig machen. Man spricht hier von unterschiedlichen Prioritäten.

Jedes Programm kann also über einen Systemaufruf solche Meldungen abgeben. Der Daemon, der diese Meldungen entgegennimmt und entscheidet, was mit ihnen zu geschehen hat heißt syslogd. Damit der Systemverwalter entscheiden kann, was mit welchen Meldungen geschehen soll kann dieser Daemon über die Datei /etc/syslog.conf konfiguriert werden.

In der Regel werden die verschiedenen Meldungen In Dateien geschrieben, die im Verzeichnis /var/log oder einem darinliegenden Unterverzeichnis abgelegt werden. Aber genau diese Frage, wohin wird welche Meldung geschrieben, wird in der Konfigurationsdatei ja eingestellt.

Die Datei /etc/syslog.conf
Jede Zeile dieser Datei, die nicht leer ist oder mit einem # beginnt, beschreibt eine Regel, was mit einer bestimmten Meldung passieren soll. die grundlegende Form jeder Zeile ist immer gleich und lautet:

Herkunft.Priorität Aktion

Sollen in einer Regel mehrere Herkunftskategorien angegeben werden, so können sie, durch Kommas voneinander getrennt, nacheinander aufgeführt werden. Sollen mehrere Herkunfts/Prioritäts-Paare gleichzeitig angegeben werden, so müssen diese durch Strichpunkt getrennt angegeben werden. Sowohl Herkunft, als auch Priorität können durch ein Sternchen (*) ersetzt werden, das als Wildcard dient. In diesem Fall sind alle Herkunfts- bzw. Prioritätskategorien angesprochen.

Für Herkunft, Priorität und Aktion sind die folgenden Werte gültig:

Herkunftskategorien

kern Systemmeldungen direkt vom Kernel
auth Meldungen vom Sicherheitsdienst des Systems (login, …)
authpriv Vertrauliche Meldungen der internen Sicherheitsdienste
mail Meldungen des Mail-Systems
news Meldungen des News-Systems
uucp Meldungen des UUCP-Systems
lpr Meldungen des Druckerdaemons
cron Meldungen des Cron-Daemons
syslog Meldungen des syslog-Daemons selbst
daemon Meldungen aller anderer Daemon-Prozesse
user Meldungen aus normalen Anwenderprogrammen
local0-local7 frei verwendbar

Prioritäten in absteigender Reihenfolge

emerg Der letzte Spruch vor dem Absturz
alert Alarmierende Nachricht, die sofortiges Eingreifen erforderlich macht
crit Meldung über eine kritische Situation, die gerade nochmal gut gegangen ist
err Fehlermeldungen aller Art aus dem laufenden Betrieb
warn Warnungen aller Art aus dem laufenden Betrieb
notice Dokumentation besonders bemerkenswerter Situationen im Rahmen des normalen Betriebs
info Protokollierung des normalen Betriebsablaufes
debug Mitteilungen interner Programmzustände bei der Fehlersuche
none Ist keine Priorität im eigentlichen Sinn, sondern dient zum Ausschluß einzelner Herkünfte

Eine angegebene Priorität meint immer die genannte oder eine höhere. Wenn jedoch vor der Priorität ein Gleichheitszeichen (=) steht, so ist nur die genannte Priorität gemeint.

Aktionen
Eine Aktion ist immer eine Weiterleitung einer Nachricht. Es gibt vier verschiedene Arten, wie solche Nachrichten weitergeleitet werden können:

1. Ausgabe der Nachricht in eine Datei.
Dazu muß als Aktion der Dateiname mit absolutem Pfad (mit führendem Slash) angegeben werden. Normalerweise wird nach jedem Schreibvorgang des Syslog-Daemons eine Synchronisation des Dateisystems durchgeführt, weil sonst evt. Nachrichten bei einem Absturz nicht mehr physikalisch in die Datei geschrieben werden. Das ist allerdings eine sehr zeitaufwendige Aktion, daher gibt es die Möglichkeit, diese Synchronisation zu übergehen. Dazu wird dem absoluten Pfadnamen ein Bindestrich (-) vorangestellt.
2. Weiterleitung der Nachricht an einen Syslog-Daemon eines anderen Rechners im Netz.
Dazu muß als Aktion der Rechnername des Rechners angegeben werden, an dessen Syslog-Daemon die Messages geschickt werden sollen. Dem Rechnernamen muß ein Klammeraffe (@) vorangestellt werden. Damit der angesprochene Syslog-Daemon auf dem anderen Rechner auch die Meldungen annimmt, muß er mit der Kommandozeilenoption -r (remote) gestartet worden sein.
3. Ausgabe der Nachricht auf den Bildschirm von bestimmten Usern
Durch die Nennung des Usernamens (oder einer durch Kommas getrennten Liste von Usernamen) wird die Nachricht auf dem Bildschirm dieser User angezeigt, sofern sie eingeloggt sind.
4. Ausgabe der Nachricht auf den Bildschirm aller eingeloggten User
In diesem Fall steht einfach ein Sternchen (*) im Aktionsfeld.

Ein paar Beispiele
Wie können nun solche Regelzeilen aussehen? Nehmen wir an, wir wollen dafür sorgen, daß alle Meldungen des Systems in die Datei /var/log/messages geschrieben werden. Das erledigt die Zeile

*.* /var/log/messages

Wollen wir aber die Meldungen des Login-Systems, die eventuell Passwörter in Klarschrift enthalten ausschließen, so können wir das mit der Priorität none erledigen:

*.*;authpriv.none /var/log/messages

Wir können dafür sorgen, daß Meldungen des Kernels, ab der Priorität warn immer auf den Bildschirm von root geschickt werden, sofern er eingeloggt ist. Falls der User foo eingeloggt ist, soll er die Meldungen auch bekommen:

kern.warn root,foo

Auch Gerätedateien sind Dateien. Schreiben wir alle Meldungen des Kernels die mindestens die Priorität warn haben und alle Meldungen ab error aller anderen Kategorien auf die Konsole 10 (/dev/tty10). Die Meldungen von authpriv lassen wir aber wieder weg. Auf Konsole 10 können sie dann auf dem Bildschirm mitgelesen werden:

kern.warn;*.err;authpriv.none /dev/tty10

Die nächsten drei Zeilen schreiben

* Nur die kritischen Meldungen des News-Systems in die Datei /var/log/news/news.crit
* Nur die Fehlermeldungen des Newssystems in die Datei /var/log/news/news.err
* die bemerkenswerten Meldungen des News Systems in die Datei /var/log/news/news.notice

Alle Dateien werden nicht sofort synchronisiert (-)

news.=crit -/var/log/news/news.crit
news.=err -/var/log/news/news.err
news.=notice -/var/log/news/news.notice

Wenn wir einen zentralen Rechner haben, nennen wir ihn admhost, der das Logbuch für alle Rechner im Netz mitschreiben soll, so müssten alle Rechner im Netz die Zeile

*.*;authpriv.none @admhost

in der syslog.conf eingetragen haben. Der syslogd auf admhost müsste dazu mit der Option -r gestartet sein.

Durch eine durchdachte Einteilung kann sich ein Systemverwalter viel Arbeit ersparen. Es ist ja möglich, daß alle denkbaren Ereignisse in verschiedene Dateien geschrieben werden, die dann schnell und effizient durchsucht werden können. Werden z.B. alle Meldungen ab der Priorität error (oder für vorsichtige Systemverwalter besser warn) in eine spezielle Datei geschrieben, so kann der Systemverwalter diese Datei regelmäßig überprüfen und muß sich nicht lange durch einen Berg von alltäglichen Meldungen kämpfen, um kritische Meldungen zu entdecken.

Verfolgen von Logdateien in Echtzeit
Manchmal ist es notwendig, Logdateien während einer bestimmten Aktion zu beobachten, um bestimmte Meldungen zu verfolgen. Um eine solche Beobachtung in „Echtzeit“ zu ermöglichen gibt es zwei verschiedene Möglichkeiten. Die erste und am häufigsten angewandte Methode wird mit dem Befehl tail realisiert. tail kennt den Parameter -f, der eben diese Fähigkeit zur Verfügung stellt. Der Befehl

tail -f /var/log/messages

zeigt die letzten 10 Zeilen der Datei /var/log/messages am Bildschirm an. Statt aber dann zur Eingabeaufforderung zurückzukehren verharrt tail (durch den Parameter -f – forever) und wartet, ob die Datei „wächst“, also neue Zeilen angefügt bekommt. Sobald neue Zeilen in die Datei geschrieben werden, werden sie auch auf dem Bildschirm ausgegeben.

Somit kann die Datei also „beim Wachsen beobachtet werden“, erst ein Strg-C beendet diese fortlaufende Beobachtung. Diese Fähigkeit ist natürlich ideal geeignet, Log-Dateien zu beobachten, während ein Fehler gesucht wird.

Die zweite angesprochene Möglichkeit bietet das Programm less, der uns wohlbekannte Pager. less kennt auch die Möglichkeit einer Datei beim Wachsen zuzusehen, dazu muß der Befehl F eingegeben werden. Auch dieser Modus muß mit einem Strg-C abgebrochen werden.
Automatische Rotation der Logbuchdateien
Logbuchdateien werden zwangsläufig ziemlich schnell wachsen. Im normalen Betriebsablauf eines Linux-Rechners, der nicht nur untätig in der Ecke steht können pro Tag problemlos 50 bis 100 Kilobyte Meldungen entstehen. Da bietet es sich doch an, diese Logbücher hin und wieder zu löschen oder zu archivieren.

Im professionellen Umfeld sollten Logdateien niemals gelöscht werden. Sie sollten besser archiviert und abgespeichert werden, am besten zusammen mit dem Datum der Speicherung oder noch besser mit dem Start- und Enddatum. Einmal archiviert kann eine solche Datei dann komprimiert werden, Programme wie gzip sind bestens geeignet, Textdateien wie Logbücher mit immer wiederkehrenden Textpassagen auf eine sehr geringe Größe zu bringen. Eine Logdatei kann so tatsächlich weniger als ein Zehntel ihrer ursprünglichen Größe bekommen.

Verschiedene Linux-Distributionen gehen hier verschiedene Wege. Aber es zeichnet sich ein Standard ab, der dazu geeignet ist, zu große Logbuchdateien regelmäßig zu komprimieren und optional auch regelmäßig per Mail zu verschicken. Das Programm, das diesen Job übernimmt heißt logrotate und wird regelmäßig von cron (siehe Kapitel 1.111.4) aufgerufen.

logrotate bezieht seine Informationen aus einer (oder mehrerer) Konfigurationsdateien, die ihm als Kommandozeilenparameter mitgegeben wurden. Das genaue Format dieser Dateien ist auf der Handbuchseite erklärt.

Vielleicht sollte der Begriff Rotation noch einmal genauer erklärt werden. Er stammt aus der Welt des Backup, in der meist mehrere Bänder für ein Backup verwendet werden. Wenn wir beispielsweise jeden Freitag ein Backup machen, dann benutzen wir nicht jedesmal das selbe Band, sondern wir haben vielleicht 5 Bänder. Nun „rotieren“ wir diese Bänder, das heißt, das wir in der ersten Woche das erste Band benutzen, in der zweiten das zweite usw. In der sechsten Woche benutzen wir dann also wieder das erste Band. So stehen uns immer die letzten 5 Wochen zur Verfügung.

Genauso läuft es mit den Logdateien. Das Programm logrotate rotiert die Logdateien, das heißt die gegenwärtige Logdatei wird – wenn ein bestimmtes Kriterium (Größe, Tag, Woche, Monat) erfüllt ist – in eine andere Datei kopiert (und optional komprimiert). Die Orginal-Logdatei wird dann gelöscht und neu angelegt. Die Anzahl der Rotationen (analog zu der Anzahl der verwendeten Bänder aus dem Backup-Beispiel) ist einstellbar. Das würde bedeuten, daß nach beispielsweise fünf Rotationen die älteste Datei gelöscht wird und statt dessen die neue Rotationsdatei angelegt wird. So haben wir die Sicherheit, daß immer nur eine begrenzte Anzahl von Dateien (und eine begrenzte Menge Speicherplatz) verwendet wird.

Optional kann man es aber auch so einrichten, daß die Logdatei, bevor sie dann endgültig gelöscht wird, an eine anzugebende E-Mail-Adresse gemailt wird.

Notizen zu Open Source, Linux, Informatik, Physiologie, Umfragen, Tai Chi, Rezepte, Blumen und für mich Interessantes eben