In der Mailingliste linux-api wurde ein Vorschlag (RFC) zur Diskussion gestellt, die veralteten Binärformate der Systemprotokolle lastlog, btmp, utmp und wtmp durch neue Shared Libraries zu ersetzen, die SQLite als Backend verwenden. Die Initiative zielt darauf ab, bestehende Probleme zu lösen, darunter das Überlaufen der 32-Bit-Zeitstempel im Jahr 2038, fehlende Erweiterbarkeit, geringe Abfrageleistung und fehlende Atomarität beim Schreiben.
Derzeit werden für die Speicherung von Daten zu Sitzungen und Authentifizierungsversuchen in Linux folgende Binärdateien mit fester Struktur verwendet:
- /var/log/lastlog — время последнего входа (структура «struct lastlog» с полем «ll_time» 32-разрядного типа time_t);
- /var/log/btmp — неудачные попытки входа;
- /var/run/utmp — текущие сеансы;
- /var/log/wtmp — история входов и выходов.
Das Dateiformat wurde vor mehreren Jahrzehnten entwickelt und hat eine Reihe von grundlegenden Einschränkungen:
- Das Feld "tv_sec" in der Struktur "utmpx" und das Feld "ll_time" in "lastlog" haben den Typ "int32_t", dessen Zeitstempel am 19. Januar 2038 überlaufen wird. Aufgrund von Anforderungen an die ABI-Kompatibilität bleiben diese Felder selbst auf 64-Bit-Systemen 32-Bit, sodass das Problem alle Linux-Installationen betreffen wird.
- Die feste Größe der Einträge lässt keine neuen Felder (z. B. Container-ID, Dienstnamen, IP-Adresse) hinzufügen, 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 Protokollen ohne Indizes, die eine effiziente Filterung der Einträge ermöglichen, wird die Last auf das Ein-/Ausgabesystem und die Verzögerungen bei der Durchführung von Abfragen inakzeptabel.
- Das Schreiben in eine Binärdatei ist keine atomare Operation. Bei einem Fehler kann der Schreibvorgang teilweise beschädigt werden.
- Um Konflikte beim gleichzeitigen Schreiben in die Protokolle durch mehrere Prozesse (z. B. sshd und login) zu vermeiden, werden flock-Sperren verwendet, die keine Atomarität garantieren und zu gegenseitigen Blockaden führen können.
Der RFC-Autor schlägt vor, vollständig auf binäre Formate zugunsten spezialisierter, gemeinsam nutzbarer Bibliotheken umzusteigen, die SQLite verwenden. Für jede Art von Protokollen wird eine separate Bibliothek mit einer einheitlichen C-Schnittstelle erstellt: liblastlog2, libbtmp2, libutmp2 und libwtmp2. Alle Bibliotheken arbeiten mit Datenbanken, dessen Schema 64-Bit-Zeitstempel (Typ INTEGER) und Indizes für Benutzer und Zeit umfasst. Es besteht die Möglichkeit, neue Felder hinzuzufügen, ohne die Kompatibilität zu verletzen (über ALTER TABLE).
Zu den Argumenten für die Nutzung von SQLite gehört die Verwendung des 64-Bit-Typs INTEGER zur Speicherung ephemerer Zeit, der Einsatz von Indizes zur Verringerung der I/O-Operationen durch gezielte Abfragen anstelle von vollständigem Scannen, die Möglichkeit, neue Felder hinzuzufügen, ohne bestehende Datensätze zu ändern, die Unterstützung von ACID-Transaktionen, der WAL-Modus (Write-Ahead Logging) für gleichzeitigen Zugriff ohne Sperren und die nachgewiesene Zuverlässigkeit von SQLite.
Für einen reibungslosen Übergang wird die Strategie des „Doppelten Schreibens“ (dual-write) vorgeschlagen:
- Programme, die in binäre Dateien schreiben (login, sshd, sudo, cron usw.), werden so modifiziert, dass sie gleichzeitig sowohl in die alte binäre Datei als auch in die neue SQLite-Datenbank über die entsprechende Bibliothek schreiben.
- Es werden neue Versionen von Dienstprogrammen (last2, lastb2, who2, lastlog2) entwickelt, die Daten aus SQLite-Datenbanken lesen und Indizes für eine schnelle Verarbeitung nutzen. Alte Dienstprogramme arbeiten weiterhin mit den bisherigen Dateien.
- Nach einigen Jahren, wenn die überwiegende Mehrheit der Systeme aktualisiert wurde, kann die Unterstützung für das Schreiben in alte Formate deaktiviert und die alten Dienstprogramme als veraltet erklärt werden.
Fragen, die zur weiteren Diskussion gestellt werden:
- Die Zweckmäßigkeit der Trennung in separate Bibliotheken oder der Zusammenlegung in eine einzige (z. B. libsession2).
- Die Wahl der Namen für Bibliotheken und Dienstprogramme (historische Bezeichnungen beibehalten oder auf allgemeinere umsteigen).
- Der Speicherort der Datenbankdateien (/var/lib/ wie bei Anwendungszuständen oder /var/log/ wie bei Protokollen).
- Ein Mechanismus zur Versionierung des Schemas und zur Migration.
- Die Leistungsparameter von SQLite für verschiedene Szenarien (Server, eingebettete Systeme).
- Bereitstellung eines Fallback-Backends, das Protokolle im vereinfachten binären Format speichert, für Systeme, bei denen SQLite möglicherweise überflüssig ist (z. B. eingebettete Geräte mit strengen Speicherbeschränkungen).
Quelle: opennet.ru
