Na seznamu diskusí linux-api bylo předloženo návrh (RFC) na výměnu zastaralých binárních formátů systémových protokolů lastlog, btmp, utmp a wtmp za nové sdílené knihovny, které používají SQLite jako backend. Iniciativa má za cíl vyřešit nahromaděné problémy, mezi nimiž je přetečení 32bitových časových čítačů v roce 2038, absence rozšiřitelnosti, nízký výkon dotazů a absence atomarity při zápisu.
V současnosti se pro ukládání dat o relacích a pokusech o autentizaci v Linuxu používají následující binární soubory s pevným formátem:
- /var/log/lastlog — время последнего входа (структура «struct lastlog» с полем «ll_time» 32-разрядного типа time_t);
- /var/log/btmp — неудачные попытки входа;
- /var/run/utmp — текущие сеансы;
- /var/log/wtmp — история входов и выходов.
Formát dat souborů byl vyvinut před několika desítkami let a má řadu základních omezení:
- Pole „tv_sec“ ve struktuře „utmpx“ a pole „ll_time“ v „lastlog“ mají typ „int32_t“, jehož hodnoty časových čítačů přetečou 19. ledna 2038. Vzhledem k požadavkům na ABI kompatibilitu zůstávají tyto pole při 64bitových systémech stále 32bitová, takže problém se dotkne všech instalací Linuxu.
- Pevná velikost záznamů neumožňuje přidávat nová pole (například identifikátor kontejneru, jméno služby, IP adresa) bez úplné změny formátu a překompilace všech utilit.
- Užití utilit last, lastb, who a lastlog je nuceno lineárně procházet obsah souborů. Při velké velikosti protokolů, bez použití indexů, které umožňují efektivní filtrování záznamů, se zátěž na systém vstupu/výstupu a zpoždění při vykonávání dotazů stávají nepřijatelnými.
- Zápis do binárního souboru není atomární operací. V případě selhání může být zápis částečně poškozen.
- Pro vyloučení konfliktů při souběžném zápisu do protokolu několika procesy (například sshd a login) se používají flock zamykání, která nezaručují atomaritu a mohou vést k vzájemnému blokování.
Autor RFC navrhuje zcela opustit binární formáty ve prospěch specializovaných sdílených knihoven používajících SQLite. Pro každý typ žurnálů se vytváří samostatná knihovna se jednotným C rozhraním: liblastlog2, libbtmp2, libutmp2 a libwtmp2. Všechny knihovny pracují s databázemi, jejichž schéma zahrnuje 64bitové časové značky (typ INTEGER) a indexy podle uživatele a času. Je možné přidávat nová pole bez porušení kompatibility (pomocí ALTER TABLE).
Mezi argumenty pro použití SQLite se zmiňuje použití 64bitového typu INTEGER pro ukládání epochálního času, zapojení indexů pro snížení vstupu/výstupu díky selektivnímu přístupu k záznamům místo plného skenování, možnost přidávat nová pole bez změny stávajících záznamů, podpora ACID transakcí, režim WAL (Write-Ahead Logging) pro konkurenční přístup bez zámků a ověřená spolehlivost práce SQLite.
Pro zajištění plynulého přechodu se navrhuje strategie 'duálního zápisu' (dual-write):
- Programy, které zapisují do binárních souborů (login, sshd, sudo, cron atd.), se modifikují tak, aby současně prováděly zápis jak do starého binárního souboru, tak do nové SQLite databáze prostřednictvím příslušné knihovny.
- Vyvíjejí se nové verze utilit (last2, lastb2, who2, lastlog2), které čtou data ze SQLite databází, využívající indexy pro rychlou práci. Staré utility nadále fungují se stávajícími soubory.
- Za několik let, když se drtivá většina systémů aktualizuje, může být podpora zápisu do starých formátů vypnuta a staré utility prohlášeny za zastaralé.
Otázky, které byly předloženy k dalšímu projednání:
- Opodstatněnost rozdělení na samostatné knihovny nebo sloučení do jedné (například libsession2).
- Výběr názvů pro knihovny a utility (zachovat historické názvy nebo přejít na obecnější).
- Umístění souborů databází (/var/lib/ jako pro stav aplikací nebo /var/log/ jako pro logy).
- Mechanismus verzování schématu a migrace.
- Parametry výkonnosti SQLite pro různé scénáře (servery, vestavěné systémy).
- Poskytování fallback backendu, který uchovává protokoly ve zjednodušeném binárním formátu, pro systémy, kde může být SQLite nadbytečné (například vestavěná zařízení s přísnými omezeními paměti).
Zdroj: opennet.ru
