Software::Systemverwaltung
Systemd erhält eigene Log-Implementierung
Die Entwickler von Systemd haben ein neues Linux-Log-System vorgestellt, das eng mit Systemd verzahnt ist. Der neue Journald soll die Logmeldungen effizienter und sicher vor Manipulationen speichern und Analysen effizienter machen.
Lennart Poettering und Kay Sievers, die Entwickler von Systemd, halten das gegenwärtige Log-System von Linux und anderen Unix-Systemen zwar für seit über 30 Jahren bewährt, doch besitzt es auch fundamentale Nachteile. Diese Nachteile traten besonders deutlich bei dem Versuch hervor, Logs besser mit Systemd zu integrieren. So machen sie nun den Vorschlag, eine neue Log-Implementierung für Systemd zu schaffen, die parallel zum bisherigen Syslog verwendet werden kann, das alte System im Laufe der Zeit aber ersetzen soll.
Nachteile von Syslog sind unter anderem, dass die Meldungen nicht authentifiziert sind und somit gefälschte Meldungen eingetragen werden können, und dass die Meldungen in ihrer Form völlig frei sind. Werkzeuge, die die Meldungen analysieren wollen, müssen daher immer wieder an Änderungen des Formats angepasst werden. Die Zeitstempel enthalten keine Zeitzoneninformationen, Meldungen werden in verschiedene Dateien geschrieben, was ihre Zuordnung schwierig macht, das Lesen der Logdateien ist ineffizient, da es lineare Zeit benötigt, und das Netzwerkprotokoll ist sehr eingeschränkt. Im Falle eines Einbruchs können die Logdateien verändert werden, ohne dass es bemerkt wird. Es gibt normalerweise keine Zugriffskontrolle außer den Unix-Dateirechten, die Metadaten enthalten nicht den Namen des Dienstes und keinen monoton wachsenden Zeitstempel, die Log-Rotation kann ein Vollaufen der Partition nicht verhindern, Prozesse werden nur sehr eingeschränkt daran gehindert, das Log übermäßig zu füllen, die Kompression alter Logdateien macht den Zugriff darauf noch langsamer, Meldungen, die vor dem Start oder nach dem Ende des Daemons anfallen, werden nicht gespeichert, und Zusatzinformationen, die im Binärformat vorliegen, können nicht geloggt werden.
Nach Meinung von Poettering und Sievers sind diese Probleme zu schwerwiegend, um Syslog zu verbessern. Stattdessen ist eine neue Implementierung gefragt, die von Anfang an die neuen Ziele berücksichtigt. Nach Beratung mit diversen Entwicklern und Administratoren, von denen einige sehr große Systeme betreuen, wurden vierzehn Ziele des neu zu schaffenden »Journals« definiert. An erster Stelle steht die Einfachheit, die wohl den größten Vorteil des aktuellen Syslog darstellt. Der Code soll so klein wie möglich sein, wenige Abhängigkeiten enthalten (Systemd wird allerdings vorausgesetzt) und keine Abstraktionen enthalten.
Das Journal soll ohne Wartung arbeiten und Überläufe der Partition vermeiden. Es soll robust sein und die Daten sollen sich leicht auf andere Systeme kopieren und dort lesen lassen. Es soll auf alle Linux-Systeme portierbar sein, andere Unix-Systeme werden nicht in Betracht gezogen. Das Schreiben von Meldungen sowie das Analysieren und Durchsuchen des Logs sollen sehr schnell sein. Geringer Platzbedarf auf der Festplatte, allgemeine Verwendbarkeit, Loggen für mehrere oder gar eine sehr große Anzahl von Rechnern und Verhinderung von Manipulationen der Logdateien sind weitere Ziele.
Die Autoren haben eine Implementation begonnen, die bereits die grundlegenden Operationen enthält. Die Implementierung speichert wesentlich mehr Metadaten als Syslog, von denen einige vom Journal selbst hinzugefügt werden und daher nicht gefälscht werden können. Das Dateiformat ist so gewählt, dass Redundanzen weitgehend vermieden werden, zudem werden die Meldungen selbst komprimiert. Dadurch soll der Platzbedarf kaum steigen oder sogar niedriger liegen als bei Syslog. Der Quellcode einschließlich einer Client-Bibliothek ist im Git-Repositorium von Systemd verfügbar.
Das Journal soll einmal alle Logmeldungen vereinheitlichen und könnte dann auch wtmp ersetzen, Audit-Logs und UEFI-Firmware-Logs aufnehmen. Auch Kernel-Meldungen und Coredumps werden im Journal verzeichnet. Jede Meldung kann ein optionale 128 Bit große UUID (Typ 4 nach RFC 4122) enthalten. Solch eine UUID kann von jedem Entwickler unabhängig generiert werden. Wo sie benutzt wird, kann sie einen Typ von Meldungen eindeutig identifizieren, selbst wenn sich der Meldungstext ändert. Dies kann Programme unterstützen, die Logdateien auswerten.
Im Gegensatz zum traditionellen Syslog hat der Zeitstempel von journald eine Genauigkeit von einer Mikrosekunde. Das Rotieren von Logdateien wird von journald selbst vorgenommen, sobald die Größe ein Limit überschreitet oder der freie Platz auf der Partition zu klein wird. Netzwerkunterstützung ist in journald zunächst nicht direkt vorgesehen. Stattdessen haben die Entwickler vorgesehen, dass die Client-Bibliothek eine beliebige Anzahl von Logdateien parallel lesen und auswerten kann. Somit können die Logdateien von anderen Rechnern mit den üblichen Mitteln auf den Auswertungsrechner kopiert werden, und das Client-Werkzeug liest alle zugleich und bringt ihre Meldungen in den richtigen zeitlichen Zusammenhang.
Die Sicherheit von Log-Einträgen soll durch eine kryptografische Prüfsumme garantiert werden. Die Prüfsumme (Hash) jedes neuen Eintrags wird aus dem neuen Eintrag sowie dem Hash des Vorgängers erzeugt. Besitzt man den Hash eines Eintrags und ist dieser korrekt, so kann man verifizieren, dass alle vorangegangenen Einträge ebenfalls korrekt sind. Wenn der aktuelle Hash auf ein schreibgeschütztes Medium übertragen wird, sind Manipulationen immer erkennbar. Nicht zu verhindern ist allerdings, dass ein Einbrecher das gesamte Log löscht. Wie beim aktuellen Syslog hilft gegen dieses Problem nur ein Kopieren der Logs an einen gesicherten Ort.
Auch die Zugriffsrechte auf die Logs sollen besser gelöst werden. Logmeldungen von normalen Benutzern werden in separate Dateien geschrieben, auf die nur der jeweilige Benutzer mittels ACLs Zugriff hat. Nur eine Systemgruppe besitzt Zugriff auf alle Logs.
Eine erste Version von journald soll nach dem Plan der Autoren in Fedora 17 erscheinen. Syslog wird parallel dazu weiterlaufen, da es geraume Zeit dauern wird, alle bisherigen Logs zu ersetzen. Auf manchen Systemen wird eine vollständige Ablösung von Syslog vielleicht nie möglich sein. Andere, besonders eingebettete Systeme, auf denen das Loggen zum Zweck des Debuggings eine große Rolle spielt, könnten schon bald von einer vollständigen Umstellung profitieren.
Das Binärformat von journald wird von den Entwicklern derzeit nicht dokumentiert, da sie sich Änderungen vorbehalten. Da es sich um freie Software handelt, ist es aber niemandem verwehrt, den Code der Client-Bibliothek als Referenz für das Format zu verwenden, er muss nur damit rechnen, dass sich das Format noch ändern kann. Wenn das Format stabilisiert ist, wird es voraussichtlich eine Versionskennung erhalten und auch offiziell dokumentiert werden.
