I distributionslistan linux-api har en proposition (RFC) lagts fram för diskussion för att ersätta föråldrade binära format för systemloggarna lastlog, btmp, utmp och wtmp med nya delade bibliotek som använder SQLite som backend. Initiativet syftar till att lösa akumulerade problem som överflödet av 32-bitars tidsräknare år 2038, brist på skalbarhet, låg fråga prestanda och avsaknaden av atomisk skrivning.
För närvarande används följande binära filer med fast struktur för att lagra data om sessioner och autentiseringförsök i Linux:
- /var/log/lastlog — время последнего входа (структура «struct lastlog» с полем «ll_time» 32-разрядного типа time_t);
- /var/log/btmp — неудачные попытки входа;
- /var/run/utmp — текущие сеансы;
- /var/log/wtmp — история входов и выходов.
Datalogformatet utvecklades för flera decennier sedan och har flera fundamentala begränsningar:
- Fältet "tv_sec" i strukturen "utmpx" och fältet "ll_time" i "lastlog" har typ "int32_t", där tidsräknare värdet kommer att överflöda den 19 januari 2038. På grund av ABI-kompatibilitetskrav förblir dessa fält 32-bitars även på 64-bitars system, vilket innebär att problemet kommer att påverka alla Linux-installationer.
- Den fasta storleken av posterna tillåter inte att nya fält (till exempel container-ID, tjänstnamn, IP-adress) läggs till utan fullständig formatbyte och rekodning av alla verktyg.
- Verktygen last, lastb, who och lastlog måste linjärt söka igenom innehållet i filerna. Vid stora loggar, utan index som möjliggör effektiv filtrering av posterna, blir belastningen på in-/utgångssystemet och fördröjningar vid fråga oacceptabla.
- Skrivning till en binär fil är inte en atomär operation. Vid ett fel kan skrivningen bli delvis skadad.
- För att utesluta konflikter vid samtidig skrivning till loggen av flera processer (till exempel sshd och login) används flock-låsningar, som inte garanterar atomäritet och kan leda till dödlägen.
Författaren till RFC föreslår att helt avstå från binära format till förmån för specialiserade delade bibliotek som använder SQLite. För varje typ av logg skapas ett separat bibliotek med en enhetlig C-gränssnitt: liblastlog2, libbtmp2, libutmp2 och libwtmp2. Alla bibliotek arbetar med databaser vars schema inkluderar 64-bitars tidsstämplar (typ INTEGER) och index baserat på användare och tid. Det finns möjlighet att lägga till nya fält utan att bryta kompatibiliteten (genom ALTER TABLE).
Bland argumenten för att använda SQLite nämns användningen av 64-bitars INTEGER-typ för att lagra epoch-tid, användning av index för att minska in- och utdata genom selektivt tilltalande poster istället för fullständig skanning, möjligheten att lägga till nya fält utan att förändra befintliga poster, stöd för ACID-transaktioner, WAL-läge (Write-Ahead Logging) för konkurrerande åtkomst utan lås, beprövad tillförlitlighet hos SQLite.
För att säkerställa en smidig övergång föreslås strategin "dual-write":
- Program som skriver till binära filer (login, sshd, sudo, cron m.fl.) modifieras så att de samtidigt skriver till både den gamla binära filen och den nya SQLite-databasen genom det respektive biblioteket.
- Nya versioner av verktyg (last2, lastb2, who2, lastlog2) utvecklas som läser data från SQLite-databaser, vilket använder index för snabbare prestanda. De gamla verktygen fortsätter att fungera med de tidigare filerna.
- Om några år, när den övervägande delen av systemen har uppdaterats, kan stödet för att skriva i gamla format stängas av, och de gamla verktygen kan förklaras som föråldrade.
Frågor som ställs för ytterligare diskussion:
- Huruvida det är förnuftigt att dela upp i separata bibliotek eller att sammanföra dem till ett (t.ex. libsession2).
- Val av namn för bibliotek och verktyg (bevara historiska namn eller övergå till mer generella).
- Placering av databasfiler (/var/lib/ som för applikationstillstånd eller /var/log/ som för loggar).
- Mekanism för versionshantering av scheman och migrering.
- Prestanda-parametrar för SQLite för olika scenarier (servrar, inbyggda system).
- Tillhandahållande av fallback-backend som lagrar loggar i ett förenklat binärt format, för system där SQLite kan vara överflödigt (till exempel inbyggda enheter med strikta minnesbegränsningar).
Källa: opennet.ru
