Isang panukala (RFC) upang palitan ang mga lumang format ng binary system log na lastlog, btmp, utmp, at wtmp ng mga bagong shared library gamit ang SQLite bilang backend ang nai-post para sa talakayan sa linux-api mailing list. Nilalayon ng inisyatibo na tugunan ang ilang isyu, kabilang ang 2038 overflow ng 32-bit time counters, kakulangan ng extensibility, mahinang performance ng query, at ang kakulangan ng atomicity kapag nagsusulat.
Sa kasalukuyan, para mag-imbak ng datos tungkol sa mga sesyon at mga pagtatangka sa pagpapatotoo sa Linux Ang mga sumusunod na binary file na may nakapirming istraktura ay ginagamit:
- /var/log/lastlog — oras ng huling pag-login (istrukturang “struct lastlog” na may field na “ll_time” na may 32-bit na time_t type);
- /var/log/btmp — mga pagtatangkang mag-login na hindi matagumpay;
- /var/run/utmp — mga kasalukuyang sesyon;
- /var/log/wtmp — kasaysayan ng mga pag-login at pag-logout.
Ang format ng mga file na ito ay binuo ilang dekada na ang nakalilipas at may ilang pangunahing limitasyon:
- Ang field na "tv_sec" sa istrukturang "utmpx" at ang field na "ll_time" sa "lastlog" ay uri ng "int32_t", ang halaga ng mga time counter batay sa kung saan ay aapaw sa Enero 19, 2038. Dahil sa mga kinakailangan sa compatibility ng ABI, kahit sa mga 64-bit na sistema, ang mga field na ito ay mananatiling 32-bit, kaya ang isyu ay makakaapekto sa lahat ng mga instalasyon. Linux.
- Hindi pinapayagan ng nakapirming laki ng record ang pagdaragdag ng mga bagong field (hal. container ID, pangalan ng serbisyo, IP address) nang hindi ganap na binabago ang format at muling kino-compile ang lahat ng utility.
- Ang mga utility na last, lastb, who, at lastlog ay napipilitang mag-ulit ng mga nilalaman ng file nang linear. Sa malalaking log, walang mga index upang epektibong ma-filter ang mga record, ang I/O load at query latency ay nagiging hindi katanggap-tanggap.
- Ang pagsulat sa isang binary file ay hindi isang atomic na operasyon. Kung mabigo ang pagsulat, maaaring bahagyang nasira ang pagsulat.
- Upang maiwasan ang mga conflict kapag maraming proseso (halimbawa, sshd at login) ang sabay-sabay na sumusulat sa journal, ginagamit ang mga flock lock, na hindi ginagarantiyahan ang atomicity at maaaring humantong sa mga deadlock.
Iminumungkahi ng may-akda ng RFC na tuluyang iwanan ang mga binary format at gamitin ang mga espesyalisadong shared library gamit ang SQLite. Isang hiwalay na library na may pare-parehong C interface ang ginagawa para sa bawat uri ng log: liblastlog2, libbtmp2, libutmp2, at libwtmp2. Gumagana ang lahat ng library sa mga database na ang schema ay may kasamang 64-bit timestamps (INTEGER type) at mga user at time index. Maaaring magdagdag ng mga bagong field nang hindi nasisira ang compatibility (sa pamamagitan ng ALTER TABLE).
Ilan sa mga argumentong pabor sa paggamit ng SQLite ay ang paggamit ng 64-bit na uri ng INTEGER para sa pag-iimbak ng epochal time, ang paggamit ng mga index upang mabawasan ang I/O sa pamamagitan ng piling pag-access sa mga record sa halip na mga full scan, ang kakayahang magdagdag ng mga bagong field nang hindi binabago ang mga umiiral na record, suporta para sa mga transaksyon ng ACID, WAL (Write-Ahead Logging) mode para sa sabay-sabay na pag-access nang walang mga lock, at ang napatunayang pagiging maaasahan ng SQLite.
Para masiguro ang maayos na transisyon, iminungkahi ang isang dual-write na estratehiya:
- Ang mga programang nagsusulat sa mga binary file (login, sshd, sudo, cron, atbp.) ay binabago upang sabay na magsulat sa parehong lumang binary file at sa bagong SQLite database sa pamamagitan ng naaangkop na library.
- May mga bagong bersyon ng mga utility (last2, lastb2, who2, lastlog2) na binubuo na nagbabasa ng data mula sa mga database ng SQLite, gamit ang mga index para sa mas mabilis na pagganap. Ang mga lumang utility ay patuloy na gumagana sa parehong mga file.
- Sa loob ng ilang taon, kapag ang karamihan sa mga sistema ay na-update na, ang suporta para sa pag-record sa mga lumang format ay maaaring hindi paganahin, at ang mga lumang utility ay maaaring ideklarang hindi na ginagamit.
Mga tanong para sa karagdagang talakayan:
- Ang pagiging mainam ng paghahati sa magkakahiwalay na mga aklatan o pagsasama-sama ng mga ito sa isa (halimbawa, libsession2).
- Pagpili ng mga pangalan para sa mga aklatan at mga kagamitan (panatilihin ang mga makasaysayang pangalan o lumipat sa mas pangkalahatang mga pangalan).
- Lokasyon ng mga file ng database (/var/lib/ para sa katayuan ng aplikasyon o /var/log/ para sa mga log).
- Mekanismo ng pagbersyon at paglipat ng schema.
- Mga parameter ng pagganap ng SQLite para sa iba't ibang mga senaryo (mga server, mga naka-embed na sistema).
- Nagbibigay ng fallback backend na nag-iimbak ng mga log sa isang magaan na binary format para sa mga system kung saan maaaring sobra ang SQLite (hal., mga naka-embed na device na may matinding limitasyon sa memorya).
Pinagmulan: opennet.ru
