Vorschlag zur Übersetzung der Systemprotokolle lastlog, btmp, utmp und wtmp zur Verwendung von SQLite.

In der Mailingliste linux-api wird ein Vorschlag (RFC) zur Diskussion gestellt, die veralteten binären Formate der Systemprotokolle lastlog, btmp, utmp und wtmp durch neue gemeinsam genutzte Bibliotheken zu ersetzen, die SQLite als Backend verwenden. Diese Initiative zielt darauf ab, vorhandene Probleme zu lösen, darunter das Überlaufen von 32-Bit-Zeitstempeln im Jahr 2038, mangelnde Erweiterbarkeit, niedrige Abfragegeschwindigkeit und das Fehlen von Atomarität beim Schreiben.

Derzeit werden in Linux die folgenden binären Dateien mit fester Struktur zur Speicherung von Daten über Sitzungen und Authentifizierungsversuche verwendet:

• /var/log/lastlog — время последнего входа (структура «struct lastlog» с полем «ll_time» 32-разрядного типа time_t);
• /var/log/btmp — неудачные попытки входа;
• /var/run/utmp — текущие сеансы;
• /var/log/wtmp — история входов и выходов.

Das Datenformat dieser Dateien wurde vor mehreren Jahrzehnten entwickelt und weist eine Reihe grundlegender Einschränkungen auf:

• Das Feld „tv_sec“ in der Struktur „utmpx“ und das Feld „ll_time“ in „lastlog“ haben den Typ „int32_t“. Der Zeitstempel, auf dem die Zähler basieren, wird am 19. Januar 2038 überlaufen. Aufgrund der Anforderungen an die ABI-Kompatibilität bleiben diese Felder auch auf 64-Bit-Systemen 32-Bit, weshalb das Problem alle Linux-Installationen betreffen wird.
• Die feste Größe der Einträge erlaubt es nicht, neue Felder hinzuzufügen (wie z.B. Container-ID, Dienstname, IP-Adresse), ohne das Format vollständig zu ersetzen und alle Utilities neu zu kompilieren.
• Die Utilities last, lastb, who und lastlog müssen den Inhalt der Dateien linear durchsuchen. Bei großen Logdateien ohne Indizes, die eine effiziente Filterung der Einträge ermöglichen, wird die Belastung des Ein- und Ausgabesystems sowie die Verzögerung bei Anfragen inakzeptabel.
• Das Schreiben in eine Binärdatei ist keine atomare Operation. Bei einem Fehler kann der Schreibvorgang teilweise beschädigt sein.
• Um Konflikte bei gleichzeitigen Schreibvorgängen in die Logs durch mehrere Prozesse (wie z.B. sshd und login) zu vermeiden, werden flock-Sperren verwendet, die jedoch keine Atomarität garantieren und zu gegenseitigen Blockierungen führen können.

Der Autor des RFC schlägt vor, vollständig auf binäre Formate zu verzichten und stattdessen spezialisierte gemeinsame Bibliotheken zu verwenden, die SQLite nutzen. Für jeden Journaltoken wird eine separate Bibliothek mit einer einheitlichen C-Schnittstelle erstellt: liblastlog2, libbtmp2, libutmp2 und libwtmp2. Alle Bibliotheken arbeiten mit einer Datenbank, deren Schema 64-Bit-Zeitsstempel (INTEGER-Typ) und Indizes nach Benutzer und Zeit umfasst. Es besteht die Möglichkeit, neue Felder hinzuzufügen, ohne die Kompatibilität zu beeinträchtigen (über ALTER TABLE).

Unter den Argumenten für die Verwendung von SQLite wird die Verwendung des 64-Bit INTEGER-Typs zur Speicherung epochaler Zeit erwähnt, der Einsatz von Indizes zur Reduzierung der Ein-/Ausgabe durch selektive Abfragen anstelle einer vollständigen Durchsuchung sowie die Möglichkeit, neue Felder ohne Änderung der bestehenden Datensätze hinzuzufügen. Darüber hinaus werden ACID-Transaktionen unterstützt, der WAL-Modus (Write-Ahead Logging) für gleichzeitigen Zugriff ohne Sperren und die nachgewiesene Zuverlässigkeit von SQLite.

Um einen reibungslosen Übergang zu gewährleisten, wird die Strategie der „doppelten Aufzeichnung“ (dual-write) vorgeschlagen:

• Programme, die in Binärdateien schreiben (login, sshd, sudo, cron usw.), werden so modifiziert, dass sie gleichzeitig sowohl in die alte Binärdatei als auch in die neue SQLite-Datenbank über die entsprechende Bibliothek schreiben.
• Neue Versionen der Tools (last2, lastb2, who2, lastlog2) werden entwickelt, die Daten aus SQLite-Datenbanken lesen und Indizes für eine schnelle Verarbeitung verwenden. Ältere Tools arbeiten weiterhin mit den bisherigen Dateien.
• In einigen Jahren, wenn der Großteil der Systeme aktualisiert wird, könnte die Unterstützung für das Schreiben in alte Formate abgeschaltet werden, und die alten Tools könnten als veraltet gelten.

Fragen, die zur weiteren Diskussion gestellt werden:

• Die Sinnhaftigkeit einer Trennung in separate Bibliotheken oder einer Zusammenführung zu einer einzigen (z. B. libsession2).
• Die Auswahl der Namen für Bibliotheken und Tools (historische Bezeichnungen beibehalten oder zu allgemeineren übergehen).
• Der Speicherort der Datenbankdateien (/var/lib/ wie für Anwendungszustände oder /var/log/ wie für Protokolle).
• Der Mechanismus zur Versionierung des Schemas und zur Migration.
• Performance-Parameter von SQLite für verschiedene Szenarien (Server, eingebettete Systeme).
• Bereitstellung eines Fallback-Backends, das Protokolle im vereinfachten Binärformat speichert, für Systeme, bei denen SQLite überflüssig sein könnte (zum Beispiel eingebettete Geräte mit strengen Speicherlimitierungen).

Quelle: opennet.ru