Предложение за прехвърляне на системните логове 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 за различни сценарии (сървъри, вградени системи).
• Предоставяне на резервен бекенд, който съхранява журнали в опростен бинарен формат, за системи, където SQLite може да е излишен (например, вградени устройства с строг ограничение по памет).

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