{"id":164053,"date":"2026-03-13T11:11:58","date_gmt":"2026-03-13T09:11:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/predlozhenie-po-perevodu-sistemnyh-logov-lastlog-btmp-utmp-i-wtmp-na-ispolzovanie-sqlite"},"modified":"2026-03-13T11:11:58","modified_gmt":"2026-03-13T09:11:58","slug":"predlozhenie-po-perevodu-sistemnyh-logov-lastlog-btmp-utmp-i-wtmp-na-ispolzovanie-sqlite","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/predlozhenie-po-perevodu-sistemnyh-logov-lastlog-btmp-utmp-i-wtmp-na-ispolzovanie-sqlite","title":{"rendered":"Proposta per la migrazione dei log di sistema lastlog, btmp, utmp e wtmp all'utilizzo di SQLite","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nella mailing list linux-api \u00e8 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\u00e0, le basse prestazioni delle query e l'assenza di atomicit\u00e0 nelle scritture. <\/p>\n
Attualmente, per memorizzare i dati sulle sessioni e sui tentativi di autenticazione in Linux, vengono utilizzati i seguenti file binari con struttura fissa: <\/p>\n
Il formato dei dati di questi file \u00e8 stato sviluppato diversi decenni fa e presenta diverse limitazioni fondamentali: <\/p>\n
\n
Il campo «tv_sec» nella struttura «utmpx» e il campo «ll_time» in «lastlog» hanno il tipo «int32_t», il che significa che i contatori di tempo si sovraccaricheranno il 19 gennaio 2038. A causa dei requisiti di compatibilit\u00e0 ABI, anche sui sistemi a 64 bit, questi campi rimangono a 32 bit, quindi il problema riguarder\u00e0 tutte le installazioni di Linux.\n
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.\n
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.\n
La scrittura in un file binario non \u00e8 un'operazione atomica. In caso di errore, la scrittura pu\u00f2 risultare parzialmente danneggiata.\n
Per escludere conflitti durante la scrittura simultanea nei log da parte di pi\u00f9 processi (come sshd e login) vengono utilizzati i blocchi flock, che non garantiscono atomicit\u00e0 e possono portare a deadlock. <\/ul>\n
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. \u00c8 possibile aggiungere nuovi campi senza compromettere la compatibilit\u00e0 (tramite ALTER TABLE). <\/p>\n
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\u00e0 di aggiungere nuovi campi senza modificare i record esistenti, il supporto per transazioni ACID, la modalit\u00e0 WAL (Write-Ahead Logging) per l'accesso concorrente senza lock, e l'affidabilit\u00e0 comprovata di SQLite. <\/p>\n
Per garantire una transizione fluida, viene proposta una strategia di «scrittura doppia» (dual-write): <\/p>\n
\n
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.\n
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.\n
Tra qualche anno, quando la stragrande maggioranza dei sistemi sar\u00e0 aggiornata, il supporto per la scrittura nei vecchi formati potrebbe essere disattivato e i vecchi strumenti — dichiarati obsoleti. <\/ul>\n
Questioni da discutere ulteriormente: <\/p>\n
\n
L'opportunit\u00e0 di separare in librerie distinte o di unirle in una sola (ad esempio, libsession2).\n
Scelta dei nomi per librerie e strumenti (mantenere i nomi storici o passare a nomi pi\u00f9 generali).\n
Posizione dei file dei database (\/var\/lib\/ come per lo stato delle applicazioni o \/var\/log\/ come per i log).\n
Meccanismo di versioning dello schema e migrazione.\n