Nella mailing list linux-api è stata proposta (RFC) la sostituzione dei formati binari obsoleti dei registri di sistema lastlog, btmp, utmp e wtmp con nuove librerie condivisibili che utilizzano SQLite come backend. L'iniziativa mira a risolvere problemi accumulati, tra cui il sovraccarico dei contatori di tempo a 32 bit nel 2038, la mancanza di scalabilità, le basse prestazioni delle query e l'assenza di atomicità durante la scrittura.
Attualmente, per memorizzare i dati sulle sessioni e sui tentativi di autenticazione in Linux, vengono utilizzati i seguenti file binari con una 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 dei file è stato sviluppato decenni fa e presenta una serie di limitazioni fondamentali:
- Il campo "tv_sec" nella struttura "utmpx" e il campo "ll_time" in "lastlog" sono di tipo "int32_t", il valore dei contatori di tempo basato sui quali si sovraccaricherà 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 interesserà tutte le installazioni di Linux.
- La dimensione fissa delle registrazioni non consente di aggiungere nuovi campi (ad esempio, l'identificatore del contenitore, il nome del servizio, l'indirizzo IP) senza sostituire completamente il formato e ricompilare tutte le utility.
- Le utility last, lastb, who e lastlog sono costrette a esaminare linearmente il contenuto dei file. Con log di grandi dimensioni, senza indici che consentano di filtrare efficacemente le registrazioni, 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ò essere parzialmente danneggiata.
- Per evitare conflitti durante la scrittura simultanea nei registri da parte di più processi (ad esempio, sshd e login) vengono utilizzati i blocchi flock, che non garantiscono l'atomicità e possono portare a situazioni di deadlock.
L'autore del 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 evidenzia l'utilizzo del tipo INTEGER a 64 bit per memorizzare il tempo epocale, l'uso di indici per ridurre l'input/output tramite accessi selettivi ai record invece di una scansione completa, la possibilità di aggiungere nuovi campi senza modificare i record esistenti, il supporto per le transazioni ACID, la modalità WAL (Write-Ahead Logging) per l'accesso concorrente senza blocchi e l'affidabilità comprovata di SQLite.
Per garantire una transizione fluida, si propone una strategia di "scrittura doppia" (dual-write):
- I programmi che scrivono in file binari (login, sshd, sudo, cron, ecc.) vengono modificati affinché possano scrivere simultaneamente nel vecchio file binario e nel nuovo database SQLite tramite l'apposita libreria.
- Vengono sviluppate nuove versioni degli strumenti (last2, lastb2, who2, lastlog2) che leggono i dati dai database SQLite, utilizzando indici per un funzionamento rapido. I vecchi strumenti continuano a operare 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 disattivato e i vecchi strumenti dichiarati obsoleti.
Questioni da considerare per ulteriori discussioni:
- L'opportunità di separare in librerie distinte o di unire in una sola (ad esempio, libsession2).
- La scelta dei nomi per le librerie e gli strumenti (mantenere i nomi storici o passare a denominazioni più generali).
- La posizione dei file di database (/var/lib/ come per lo stato delle applicazioni o /var/log/ come per i log).
- Il meccanismo di versioning dello schema e migrazione.
- Le opzioni di prestazioni di SQLite per diversi scenari (servers, sistemi embedded).
- Fornitura di un backend di fallback che memorizza i log in un formato binario semplificato, per sistemi in cui SQLite potrebbe risultare eccessivo (ad esempio, dispositivi embedded con severe limitazioni di memoria).
Fonte: opennet.ru
