Предложение за превод на системните логове 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