{"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\/news\/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 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\u00e0, le basse prestazioni delle query e l'assenza di atomicit\u00e0 durante la scrittura. <\/p>\n
Attualmente, per memorizzare i dati sulle sessioni e sui tentativi di autenticazione in Linux, vengono utilizzati i seguenti file binari con una struttura fissa: <\/p>\n
Il formato dei dati dei file \u00e8 stato sviluppato decenni fa e presenta una serie di limitazioni fondamentali: <\/p>\n
\n
Il campo tv_sec<\/tt> nella struttura utmpx<\/tt> e il campo ll_time<\/tt> in lastlog<\/tt> sono di tipo int32_t<\/tt>, e il valore dei contatori di tempo su cui si basa si sovraccaricher\u00e0 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 colpir\u00e0 tutte le installazioni di Linux.\n
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.\n
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.\n
La scrittura in un file binario non \u00e8 un'operazione atomica. In caso di errore, la scrittura pu\u00f2 essere parzialmente danneggiata.\n
Per evitare conflitti durante la scrittura simultanea nei registri da parte di pi\u00f9 processi (ad esempio, sshd e login) vengono utilizzati i blocchi flock, che non garantiscono l'atomicit\u00e0 e possono portare a situazioni di deadlock. <\/ul>\n
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. \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 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\u00e0 di aggiungere nuovi campi senza modificare i record esistenti, il supporto per le transazioni ACID, la modalit\u00e0 WAL (Write-Ahead Logging) per l'accesso concorrente senza blocchi e l'affidabilit\u00e0 comprovata di SQLite. <\/p>\n
Per garantire una transizione fluida, si propone una strategia di dual-write<\/tt>: <\/p>\n
\n
I programmi che scrivono in file binari (login, sshd, sudo, cron, ecc.) vengono modificati affinch\u00e9 possano scrivere simultaneamente nel vecchio file binario e nel nuovo database SQLite tramite l'apposita libreria.\n
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.\n
Tra alcuni anni, 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 considerare per ulteriori discussioni: <\/p>\n
\n
L'opportunit\u00e0 di separare in librerie distinte o di unire in una sola (ad esempio, libsession2).\n
La scelta dei nomi per le librerie e gli strumenti (mantenere i nomi storici o passare a denominazioni pi\u00f9 generali).\n
La posizione dei file di database (\/var\/lib\/ come per lo stato delle applicazioni o \/var\/log\/ come per i log).\n
Il meccanismo di versioning dello schema e migrazione.\n