En la lista de distribución linux-api se ha propuesto (RFC) discutir la sustitución 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.
Actualmente, se utilizan los siguientes archivos binarios de estructura fija para almacenar datos sobre sesiones e intentos de autenticación en Linux:
- /var/log/lastlog — время последнего входа (структура «struct lastlog» с полем «ll_time» 32-разрядного типа time_t);
- /var/log/btmp — неудачные попытки входа;
- /var/run/utmp — текущие сеансы;
- /var/log/wtmp — история входов и выходов.
El formato de datos de los archivos fue desarrollado hace varias décadas y tiene una serie de limitaciones fundamentales:
- El campo 'tv_sec' en la estructura 'utmpx' y el campo 'll_time' en 'lastlog' son de tipo 'int32_t', y el valor de los contadores de tiempo se desbordará el 19 de enero de 2038. Debido a los requisitos de compatibilidad de ABI, incluso en sistemas de 64 bits, estos campos siguen siendo de 32 bits, por lo que el problema afectará a todas las instalaciones de Linux.
- El tamaño fijo de los registros no permite agregar nuevos campos (por ejemplo, identificador de contenedor, nombre de servicio, dirección IP) sin una sustitución completa del formato y la recompilación de todas las utilidades.
- Las utilidades last, lastb, who y lastlog se ven obligadas a recorrer linealmente el contenido de los archivos. Con grandes tamaños de registros, sin el uso de índices que permitan filtrar registros de manera eficiente, la carga del sistema de entrada/salida y los retrasos en la ejecución de consultas se vuelven inaceptables.
- Escribir en un archivo binario no es una operación atómica. En caso de fallo, la escritura puede quedar parcialmente dañada.
- Para evitar conflictos al escribir simultáneamente 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.
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 índices por usuario y tiempo. Existe la posibilidad de agregar nuevos campos sin romper la compatibilidad (a través de ALTER TABLE).
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 índices 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ás de la confiabilidad comprobada de SQLite.
Para garantizar una transición suave, se propone una estrategia de "doble escritura" (dual-write):
- Los programas que escriben en archivos binarios (login, sshd, sudo, cron, etc.) se modifican para que realicen simultáneamente la escritura tanto en el viejo archivo binario como en la nueva base de datos SQLite a través de la biblioteca correspondiente.
- Se están desarrollando nuevas versiones de utilidades (last2, lastb2, who2, lastlog2) que leen datos de las bases SQLite utilizando índices para un funcionamiento rápido. Las utilidades antiguas continúan funcionando con los archivos previos.
- Después de algunos años, cuando la gran mayoría de los sistemas se hayan actualizado, se podría deshabilitar el soporte para la escritura en los antiguos formatos, y las utilidades antiguas podrían declararse obsoletas.
Cuestiones planteadas para discusión adicional:
- La conveniencia de separarlas en bibliotecas individuales o combinarlas en una sola (por ejemplo, libsession2).
- La elección de nombres para las bibliotecas y utilidades (mantener los nombres históricos o pasar a nombres más genéricos).
- La ubicación de los archivos de bases de datos (/var/lib/ como para el estado de las aplicaciones o /var/log/ como para los registros).
- El mecanismo de versionado de esquemas y migración.
- Los parámetros de rendimiento de SQLite para diferentes escenarios (servidores, sistemas integrados).
- Proporcionar un backend de fallback que almacene registros en un formato binario simplificado para sistemas donde SQLite puede ser redundante (por ejemplo, dispositivos integrados con limitaciones estrictas de memoria).
Fuente: opennet.ru
