{"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\/es\/blog\/news\/predlozhenie-po-perevodu-sistemnyh-logov-lastlog-btmp-utmp-i-wtmp-na-ispolzovanie-sqlite","title":{"rendered":"Propuesta para la traducci\u00f3n de los registros del sistema lastlog, btmp, utmp y wtmp para utilizar SQLite","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
En la lista de distribuci\u00f3n linux-api se ha propuesto (RFC) discutir la sustituci\u00f3n de los obsoletos formatos binarios de los registros del sistema lastlog, btmp, utmp y wtmp por nuevas bibliotecas compartidas que utilicen SQLite como backend. Esta iniciativa tiene como objetivo resolver problemas acumulados, entre los cuales se encuentran el desbordamiento de contadores de tiempo de 32 bits en 2038, la falta de escalabilidad, el bajo rendimiento de las consultas y la falta de atomicidad en las escrituras. <\/p>\n
Actualmente, se utilizan los siguientes archivos binarios de estructura fija para almacenar datos sobre sesiones e intentos de autenticaci\u00f3n en Linux: <\/p>\n
El formato de datos de los archivos fue desarrollado hace varias d\u00e9cadas y tiene una serie de limitaciones fundamentales: <\/p>\n
\n
El campo «tv_sec» en la estructura «utmpx» y el campo «ll_time» en «lastlog» tienen el tipo «int32_t», un valor de contador de tiempo que se desbordar\u00e1 el 19 de enero de 2038. Debido a los requisitos de compatibilidad ABI, incluso en sistemas de 64 bits, estos campos siguen siendo de 32 bits, por lo que el problema afectar\u00e1 a todas las instalaciones de Linux.\n
El tama\u00f1o fijo de los registros no permite agregar nuevos campos (por ejemplo, identificador de contenedor, nombre de servicio, direcci\u00f3n IP) sin una sustituci\u00f3n completa del formato y la recompilaci\u00f3n de todas las utilidades.\n
Las utilidades last, lastb, who y lastlog se ven obligadas a recorrer linealmente el contenido de los archivos. Con grandes tama\u00f1os de registros, sin el uso de \u00edndices que permitan filtrar registros de manera eficiente, la carga del sistema de entrada\/salida y los retrasos en la ejecuci\u00f3n de consultas se vuelven inaceptables.\n
Escribir en un archivo binario no es una operaci\u00f3n at\u00f3mica. En caso de fallo, la escritura puede quedar parcialmente da\u00f1ada.\n
Para evitar conflictos al escribir simult\u00e1neamente en los registros desde varios procesos (por ejemplo, sshd y login), se utilizan bloqueos flock, que no garantizan la atomicidad y pueden llevar a bloqueos mutuos. <\/ul>\n
El autor del RFC propone abandonar por completo los formatos binarios en favor de bibliotecas compartidas especializadas que utilizan SQLite. Se crea una biblioteca separada para cada tipo de registro con una interfaz C uniforme: liblastlog2, libbtmp2, libutmp2 y libwtmp2. Todas las bibliotecas trabajan con bases de datos cuya estructura incluye marcas de tiempo de 64 bits (tipo INTEGER) e \u00edndices por usuario y tiempo. Existe la posibilidad de agregar nuevos campos sin romper la compatibilidad (a trav\u00e9s de ALTER TABLE). <\/p>\n
Entre los argumentos a favor del uso de SQLite se menciona el uso del tipo INTEGER de 64 bits para almacenar el tiempo epoch, el uso de \u00edndices para reducir la entrada\/salida mediante acceso selectivo a los registros en lugar de escaneos completos, la capacidad de agregar nuevos campos sin modificar los registros existentes, el soporte para transacciones ACID, y el modo WAL (Write-Ahead Logging) para acceso concurrente sin bloqueos, adem\u00e1s de la confiabilidad comprobada de SQLite. <\/p>\n
Para garantizar una transici\u00f3n fluida, se propone una estrategia de «escritura dual» (dual-write): <\/p>\n
\n
Los programas que escriben en archivos binarios (login, sshd, sudo, cron, etc.) se modifican para que realicen simult\u00e1neamente la escritura tanto en el viejo archivo binario como en la nueva base de datos SQLite a trav\u00e9s de la biblioteca correspondiente.\n
Se est\u00e1n desarrollando nuevas versiones de utilidades (last2, lastb2, who2, lastlog2) que leen datos de las bases SQLite utilizando \u00edndices para un funcionamiento r\u00e1pido. Las utilidades antiguas contin\u00faan funcionando con los archivos previos.\n
En unos a\u00f1os, cuando la gran mayor\u00eda de los sistemas se actualicen, el soporte para la escritura en formatos antiguos puede desactivarse y las utilidades antiguas — ser declaradas obsoletas. <\/ul>\n
Cuestiones planteadas para discusi\u00f3n adicional: <\/p>\n
\n
La conveniencia de separarlas en bibliotecas individuales o combinarlas en una sola (por ejemplo, libsession2).\n
La elecci\u00f3n de nombres para las bibliotecas y utilidades (mantener los nombres hist\u00f3ricos o pasar a nombres m\u00e1s gen\u00e9ricos).\n
La ubicaci\u00f3n de los archivos de bases de datos (\/var\/lib\/ como para el estado de las aplicaciones o \/var\/log\/ como para los registros).\n
El mecanismo de versionado de esquemas y migraci\u00f3n.\n