🥇Предложение по переводу системных логов lastlog, btmp, utmp и wtmp на использование SQLite

В списке рассылки linux-api выставлено на обсуждение предложение (RFC) заменить устаревшие бинарные форматы системных журналов lastlog, btmp, utmp и wtmp на новые разделяемые библиотеки, использующие SQLite в качестве бэкенда. Инициатива направлена на решение накопившихся проблем, среди которых переполнение 32-разрядных счётчиков времени в 2038 году, отсутствие расширяемости, низкая производительность запросов и отсутствие атомарности при записи.

В настоящее время для хранения данных о сеансах и попытках аутентификации в Linux используются следующие бинарные файлы, имеющие фиксированную структуру:

/var/log/lastlog — время последнего входа (структура «struct lastlog» с полем «ll_time» 32-разрядного типа time_t);
/var/log/btmp — неудачные попытки входа;
/var/run/utmp — текущие сеансы;
/var/log/wtmp — история входов и выходов.

Формат данных файлов был разработан несколько десятилетий назад и имеет ряд фундаментальных ограничений:

Поле «tv_sec» в структуре «utmpx» и поле «ll_time» в «lastlog» имеют тип «int32_t», значение счётчиков времени на основе которого переполнится 19 января 2038 года. Из-за требований ABI‑совместимости даже на 64-разрядных системах эти поля остаются 32-разрядными, поэтому проблема затронет все установки Linux.
Фиксированный размер записей не позволяет добавлять новые поля (например, идентификатор контейнера, имя сервиса, IP-адрес) без полной замены формата и перекомпиляции всех утилит.
Утилиты last, lastb, who и lastlog вынуждены линейно перебирать содержимое файлов. При большом размере журналов без использования индексов, позволяющих эффективно фильтровать записи, нагрузка на систему ввода/вывода и задержки при выполнении запросов становятся неприемлемыми.
Запись в бинарный файл не является атомарной операцией. При сбое запись может быть частично повреждена.
Для исключения конфликтов при одновременной записи в журтал несколькими процессами (например, sshd и login) используются flock-блокировки, которые не гарантируют атомарность и могут приводить к взаимным блокировкам.

Автор RFC предлагает полностью отказаться от бинарных форматов в пользу специализированных разделяемых библиотек, использующих SQLite. Для каждого типа журналов создаётся отдельная библиотека с единообразным C-интерфейсом: liblastlog2, libbtmp2, libutmp2 и libwtmp2. Все библиотеки работают с БД, схема которых включает 64-разрядные временные метки (тип INTEGER) и индексы по пользователю и времени. Имеется возможность добавления новых полей без нарушения совместимости (через ALTER TABLE).

Среди доводов в пользу использования SQLite упоминается использование 64-разрядного типа INTEGER для хранения эпохального времени, задействование индексов для снижения ввода/вывода за счёт выборочного обращения к записями вместо полного сканирования, возможность добавления новых полей без изменения существующих записей, поддержка ACID-транзакций, режим WAL (Write-Ahead Logging) для конкурентного доступа без блокировок, проверенная надёжность работы SQLite.

Для обеспечения плавного перехода предлагается стратегия «двойной записи» (dual-write):

Программы, которые пишут в бинарные файлы (login, sshd, sudo, cron и др.), модифицируются так, чтобы одновременно выполнять запись и в старый бинарный файл, и в новую SQLite-базу через соответствующую библиотеку.
Разрабатываются новые версии утилит (last2, lastb2, who2, lastlog2), которые читают данные из SQLite-баз, используя индексы для быстрой работы. Старые утилиты продолжают работать с прежними файлами.
Через несколько лет, когда подавляющее большинство систем обновятся, поддержка записи в старые форматы может быть отключена, а старые утилиты — объявлены устаревшими.

Вопросы, выставленные для дополнительного обсуждения:

Целесообразность разделения на отдельные библиотеки или объединения в одну (например, libsession2).
Выбор имён для библиотек и утилит (сохранить исторические названия или перейти к более общим).
Расположение файлов баз данных (/var/lib/ как для состояния приложений или /var/log/ как для логов).
Механизм версионирования схемы и миграции.
Параметры производительности SQLite для различных сценариев (серверы, встраиваемые системы).
Предоставление fallback-бэкенда, хранящего журналы в упрощённом бинарном формате, для систем, на которых SQLite может оказаться избыточным (например, встраиваемые устройства с жёсткими ограничениями по памяти).

Источник: opennet.ru