Nella mailing list linux-api è stata presentata una proposta (RFC) per sostituire i formati binari obsoleti dei log di sistema lastlog, btmp, utmp e wtmp con nuove librerie condivise che utilizzano SQLite come backend. L'iniziativa mira a risolvere problemi accumulati, tra cui il superamento dei contatori del tempo a 32 bit nel 2038, la mancanza di scalabilità, le basse prestazioni delle query e l'assenza di atomicità nelle scritture.
Attualmente, per memorizzare i dati sulle sessioni e sui tentativi di autenticazione in Linux, vengono utilizzati i seguenti file binari con struttura fissa:
- /var/log/lastlog — время последнего входа (структура «struct lastlog» с полем «ll_time» 32-разрядного типа time_t);
- /var/log/btmp — неудачные попытки входа;
- /var/run/utmp — текущие сеансы;
- /var/log/wtmp — история входов и выходов.
Il formato dei dati di questi file è stato sviluppato diversi decenni fa e presenta diverse limitazioni fondamentali:
- Il campo "tv_sec" nella struttura "utmpx" e il campo "ll_time" in "lastlog" sono di tipo "int32_t", e il valore dei contatori del tempo basato su questo supererà il limite il 19 gennaio 2038. A causa dei requisiti di compatibilità ABI, anche sui sistemi a 64 bit, questi campi rimangono a 32 bit, quindi il problema coinvolgerà tutte le installazioni Linux.
- La dimensione fissa delle registrazioni non consente di aggiungere nuovi campi (come l'identificatore del contenitore, il nome del servizio, l'indirizzo IP) senza una sostituzione completa del formato e la ricompilazione di tutti gli strumenti.
- Gli strumenti last, lastb, who e lastlog devono scorrere linearmente il contenuto dei file. Con log di grandi dimensioni, senza utilizzare indici che permettano di filtrare le registrazioni in modo efficace, il carico sul sistema di input/output e i ritardi nell'esecuzione delle query diventano inaccettabili.
- La scrittura in un file binario non è un'operazione atomica. In caso di errore, la scrittura può risultare parzialmente danneggiata.
- Per escludere conflitti durante la scrittura simultanea nei log da parte di più processi (come sshd e login) vengono utilizzati i blocchi flock, che non garantiscono atomicità e possono portare a deadlock.
L'autore della RFC propone di abbandonare completamente i formati binari a favore di librerie condivise specializzate che utilizzano SQLite. Per ogni tipo di registro viene creata una libreria separata con un'interfaccia C uniforme: liblastlog2, libbtmp2, libutmp2 e libwtmp2. Tutte le librerie lavorano con un database la cui schema include timestamp a 64 bit (tipo INTEGER) e indici per utente e tempo. È possibile aggiungere nuovi campi senza compromettere la compatibilità (tramite ALTER TABLE).
Tra i motivi a favore dell'uso di SQLite si menziona l'utilizzo del tipo INTEGER a 64 bit per memorizzare il tempo epoch, l'uso di indici per ridurre l'input/output grazie all'accesso selettivo ai record invece di una scansione completa, la possibilità di aggiungere nuovi campi senza modificare i record esistenti, il supporto per transazioni ACID, la modalità WAL (Write-Ahead Logging) per l'accesso concorrente senza lock, e l'affidabilità comprovata di SQLite.
Per garantire una transizione fluida, viene proposta una strategia di 'scrittura doppia' (dual-write):
- I programmi che scrivono in file binari (login, sshd, sudo, cron, ecc.) vengono modificati in modo da scrivere simultaneamente sia nel vecchio file binario che nel nuovo database SQLite tramite la libreria appropriata.
- Vengono sviluppate nuove versioni degli strumenti (last2, lastb2, who2, lastlog2), che leggono i dati dai database SQLite utilizzando gli indici per un funzionamento rapido. I vecchi strumenti continuano a funzionare con i file precedenti.
- Dopo alcuni anni, quando la stragrande maggioranza dei sistemi sarà aggiornata, il supporto per la scrittura nei vecchi formati potrebbe essere disabilitato e i vecchi strumenti dichiarati obsoleti.
Questioni da discutere ulteriormente:
- L'opportunità di separare in librerie distinte o di unirle in una sola (ad esempio, libsession2).
- Scelta dei nomi per librerie e strumenti (mantenere i nomi storici o passare a nomi più generali).
- Posizione dei file dei database (/var/lib/ come per lo stato delle applicazioni o /var/log/ come per i log).
- Meccanismo di versioning dello schema e migrazione.
- Parametri di prestazione di SQLite per diversi scenari (server, sistemi embedded).
- Fornitura di un backend fallback che memorizza i log in un formato binario semplificato, per sistemi in cui SQLite potrebbe essere eccessivo (ad esempio, dispositivi embedded con severe limitazioni di memoria).
Fonte: opennet.ru
