In de mailinglijst linux-api is er een voorstel (RFC) gepresenteerd om verouderde binaire formaten van systeemlogs zoals lastlog, btmp, utmp en wtmp te vervangen door nieuwe gedeelde bibliotheken die SQLite als backend gebruiken. Dit initiatief is gericht op het oplossen van opgestapelde problemen, waaronder de overflow van 32-bits tijdtellertjes in 2038, een gebrek aan uitbreidbaarheid, lage prestatie bij query's en het ontbreken van atomiciteit bij записи.
Momenteel worden voor het opslaan van gegevens over sessies en authenticatiepogingen in Linux de volgende binaire bestanden met een vaste structuur gebruikt:
- /var/log/lastlog — время последнего входа (структура «struct lastlog» с полем «ll_time» 32-разрядного типа time_t);
- /var/log/btmp — неудачные попытки входа;
- /var/run/utmp — текущие сеансы;
- /var/log/wtmp — история входов и выходов.
Het gegevensformaat van deze bestanden is enkele decennia geleden ontwikkeld en vertoont een aantal fundamentele beperkingen:
- Het veld 'tv_sec' in de structuur 'utmpx' en het veld 'll_time' in 'lastlog' hebben het type 'int32_t', waarvan de tijdtellers op basis waarvan ze werken, op 19 januari 2038 zullen overlopen. Vanwege de eisen van ABI-compatibiliteit blijven deze velden, zelfs op 64-bit systemen, 32-bit, wat betekent dat dit probleem alle Linux-installaties zal beïnvloeden.
- De vaste grootte van de records maakt het niet mogelijk om nieuwe velden toe te voegen (zoals container-ID, servicenaam, IP-adres) zonder het formaat volledig te vervangen en alle hulpprogramma's opnieuw te compileren.
- De hulpprogramma's last, lastb, who en lastlog zijn gedwongen om lineair door de bestanden te bladeren. Bij een grote grootte van logs, zonder het gebruik van indexen die het mogelijk maken om records effectief te filteren, wordt de druk op het invoer-/uitvoersysteem en de latentie bij het uitvoeren van queries onaanvaardbaar.
- Het schrijven naar een binair bestand is geen atomische operatie. Bij een storing kan de opname gedeeltelijk beschadigd raken.
- Om conflicten te voorkomen bij gelijktijdig schrijven naar logs door meerdere processen (zoals sshd en login) worden flock-locks gebruikt, die geen atomiciteit garanderen en kunnen leiden tot deadlocks.
De auteur van de RFC stelt voor om volledig af te stappen van binaire formaten ten gunste van gespecialiseerde gedeelde bibliotheken die SQLite gebruiken. Voor elk type logboeken wordt een aparte bibliotheek gecreëerd met een uniforme C-interface: liblastlog2, libbtmp2, libutmp2 en libwtmp2. Alle bibliotheken werken met databases waarvan het schema 64-bits tijdstempels (type INTEGER) en indices op gebruiker en tijd bevat. Nieuwe velden kunnen worden toegevoegd zonder de compatibiliteit te verstoren (via ALTER TABLE).
Onder de argumenten voor het gebruik van SQLite wordt genoemd dat de 64-bits INTEGER-gegevens type gebruikt wordt voor het opslaan van epoch-tijd, dat indices worden gebruikt om I/O te verminderen door selectieve toegang tot records in plaats van een volledig scan, dat nieuwe velden kunnen worden toegevoegd zonder bestaande records te wijzigen, dat ACID-transacties worden ondersteund, dat de WAL-modus (Write-Ahead Logging) wordt gebruikt voor concurrente toegang zonder blokkering, en de bewezen betrouwbaarheid van SQLite.
Om een soepele overgang te garanderen, wordt de strategie van 'dubbele schrijfoperatie' (dual-write) voorgesteld:
- Programma's die naar binaire bestanden schrijven (login, sshd, sudo, cron, enz.), worden aangepast zodat ze tegelijkertijd naar zowel het oude binaire bestand als naar de nieuwe SQLite-database schrijven via de bijbehorende bibliotheek.
- Nieuwe versies van hulpprogramma's (last2, lastb2, who2, lastlog2) worden ontwikkeld die gegevens uit SQLite-databases lezen, gebruikmakend van indices voor snelle werking. Oude hulpprogramma's blijven werken met de eerdere bestanden.
- Over enkele jaren, wanneer de overgrote meerderheid van de systemen is geüpdatet, kan de ondersteuning voor het schrijven naar oude formaten worden uitgeschakeld, en kunnen oude hulpprogramma's als verouderd worden verklaard.
Vragen die ter verdere discussie worden gesteld:
- De haalbaarheid van het splitsen in aparte bibliotheken of het samenvoegen in één (bijvoorbeeld libsession2).
- De keuze van namen voor bibliotheken en hulpprogramma's (historische namen behouden of overstappen naar meer algemene).
- De locatie van databases ( /var/lib/ zoals voor applicatietoestanden of /var/log/ zoals voor logs).
- Mechanisme voor versiebeheer van het schema en migratie.
- Prestatieparameters van SQLite voor verschillende scenario's (servers, embedded systemen).
- Het aanbieden van een fallback-backend die logs opslaat in een vereenvoudigd binair formaat, voor systemen waarop SQLite overbodig kan zijn (bijvoorbeeld embedded apparaten met strikte geheugenbeperkingen).
Bron: opennet.ru
