Javaslat a rendszernaplók, a lastlog, btmp, utmp és wtmp SQLite-ra való áttérésére.

A linux-api mailing list proposal (RFC) has been put forward for discussion to replace the outdated binary formats of the system logs lastlog, btmp, utmp, and wtmp with new shared libraries that use SQLite as a backend. This initiative aims to address accumulated issues, including the overflow of 32-bit time counters in 2038, lack of extensibility, low query performance, and the absence of atomicity during writes.

Currently, the following binary files with a fixed structure are used in Linux to store session data and authentication attempts:

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

The data format of these files was developed several decades ago and has a number of fundamental limitations:

  • The 'tv_sec' field in the 'utmpx' structure and the 'll_time' field in 'lastlog' are of type 'int32_t', and the value of the time counters will overflow on January 19, 2038. Due to ABI compatibility requirements, these fields remain 32-bit even on 64-bit systems, so the issue will affect all Linux installations.
  • The fixed size of records does not allow for the addition of new fields (such as container ID, service name, IP address) without completely replacing the format and recompiling all utilities.
  • The last, lastb, who, and lastlog utilities are forced to linearly scan the contents of the files. With large log sizes, the lack of indexes for effectively filtering records leads to an unacceptable load on input/output systems and delays in query execution.
  • Writing to a binary file is not an atomic operation. In the event of a failure, the write may become partially corrupted.
  • To avoid conflicts during simultaneous writing to the logs by multiple processes (such as sshd and login), flock locks are used, which do not guarantee atomicity and can lead to deadlocks.

Az RFC szerzője javasolja a bináris formátumok teljes elhagyását a SQLite-ot használó, speciális megosztott könyvtárak javára. Minden naplózási típushoz külön könyvtár készül egységes C interfésszel: liblastlog2, libbtmp2, libutmp2 és libwtmp2. Minden könyvtár adatbázisokkal dolgozik, amelyek sémái 64-bites időbélyegeket (INTEGER típus) és indexeket tartalmaznak felhasználó és idő szerint. Lehetőség van új mezők hozzáadására anélkül, hogy megszakítanák a kompatibilitást (ALTER TABLE segítségével).

Az SQLite használatának érvek között szerepel a 64-bites INTEGER típus alkalmazása az epochális idő tárolására, indexek felhasználása az I/O csökkentése érdekében, a rekordok szelektív elérésének lehetősége a teljes beolvasás helyett, új mezők hozzáadásának lehetősége a meglévő bejegyzések módosítása nélkül, az ACID tranzakciók támogatása, a WAL (Write-Ahead Logging) üzemmód a zárolás nélküli egyidejű hozzáféréshez, valamint az SQLite megbízhatóságának megfelelően tesztelt működése.

A zökkenőmentes átmenet biztosítására javasolt a „kettős írás” (dual-write) stratégia:

  • Azok a programok, amelyek bináris fájlokba írnak (login, sshd, sudo, cron stb.), módosításra kerülnek, hogy egyszerre írjanak a régi bináris fájlba és az új SQLite-adatbázisba a megfelelő könyvtáron keresztül.
  • Új verziók készülnek az olyan segédprogramokból (last2, lastb2, who2, lastlog2), amelyek az SQLite-adatbázisokból olvasnak, indexek használatával a gyors működés érdekében. A régi segédprogramok továbbra is működnek a korábbi fájlokkal.
  • Néhány év múlva, amikor a rendszerek túlnyomó többsége frissül, a régi formátumokba való írás támogatása kikapcsolható, és a régi segédprogramok elavultnak nyilváníthatók.

Kérdések, amelyek további megvitatásra várnak:

  • Részleges könyvtárak szétválasztásának vagy egyesítésének célszerűsége (például libsession2).
  • Könyvtárak és segédprogramok névválasztása (történelmi nevek megőrzése vagy általánosabb nevekre váltás).
  • Az adatbázis fájlok elhelyezkedése (/var/lib/ az alkalmazás állapotához vagy /var/log/ a naplókhoz).
  • Az schema verziókezelési mechanizmusa és migráció.
  • Az SQLite teljesítménymutatói különböző forgatókönyvekhez (szerverek, beágyazott rendszerek).
  • Egy fallback háttérrendszer biztosítása, amely egyszerűsített bináris formátumban tárolja a naplókat olyan rendszerek számára, ahol az SQLite felesleges lehet (például beágyazott eszközök szigorú memória korlátozásokkal).

Forrás: opennet.ru

Megbízható hosting vásárlása weboldalak számára, DDoS védelemmel, VPS VDS szerverek. 🔥 Megbízható webtárhely vásárlása DDoS védelemmel, VPS VDS szerverek | ProHoster