SQLite प्रयोग गर्न प्रणाली लगहरू lastlog, btmp, utmp, र wtmp मा स्थानान्तरण गर्ने प्रस्ताव

SQLite लाई ब्याकएन्डको रूपमा प्रयोग गरेर नयाँ साझा पुस्तकालयहरूसँग लिगेसी बाइनरी प्रणाली लग ढाँचाहरू lastlog, btmp, utmp, र wtmp लाई प्रतिस्थापन गर्ने प्रस्ताव (RFC) linux-api मेलिङ सूचीमा छलफलको लागि पोस्ट गरिएको छ। यो पहलले ३२-बिट समय काउन्टरहरूको २०३८ ओभरफ्लो, एक्सटेन्सिबिलिटीको अभाव, खराब क्वेरी प्रदर्शन, र लेख्दा परमाणुताको अभाव सहित धेरै समस्याहरूलाई सम्बोधन गर्ने लक्ष्य राखेको छ।

हाल, लिनक्समा सत्र र प्रमाणीकरण प्रयास डेटा भण्डारण गर्न निम्न स्थिर-संरचना बाइनरीहरू प्रयोग गरिन्छ:

• /var/log/lastlog — अन्तिम लगइनको समय (३२-बिट time_t प्रकारको फिल्ड "ll_time" सहितको संरचना "struct lastlog");
• /var/log/btmp — असफल लगइन प्रयासहरू;
• /var/run/utmp — हालको सत्रहरू;
• /var/log/wtmp — लगइन र लगआउटको इतिहास।

यी फाइलहरूको ढाँचा धेरै दशक अघि विकसित गरिएको थियो र यसमा धेरै आधारभूत सीमितताहरू छन्:

• "utmpx" संरचनामा रहेको "tv_sec" फिल्ड र "lastlog" मा रहेको "ll_time" फिल्ड "int32_t" प्रकारका छन्, जसको आधारमा समय काउन्टर मान जनवरी १९, २०३८ मा ओभरफ्लो हुनेछ। ABI अनुकूलता आवश्यकताहरूको कारणले गर्दा, ६४-बिट प्रणालीहरूमा पनि, यी फिल्डहरू ३२-बिट नै रहन्छन्, त्यसैले यो समस्याले सबै Linux स्थापनाहरूलाई असर गर्नेछ।
• निश्चित रेकर्ड साइजले ढाँचा पूर्ण रूपमा परिवर्तन नगरी र सबै उपयोगिताहरू पुन: कम्पाइल नगरी नयाँ क्षेत्रहरू (जस्तै कन्टेनर ID, सेवा नाम, IP ठेगाना) थप्न अनुमति दिँदैन।
• last, lastb, who, र lastlog उपयोगिताहरूलाई फाइल सामग्रीहरू लाइनरली पुनरावृत्ति गर्न बाध्य पारिन्छ। ठूला लगहरूसँग, प्रभावकारी रूपमा रेकर्डहरू फिल्टर गर्न अनुक्रमणिकाहरू बिना, I/O लोड र क्वेरी विलम्बता अस्वीकार्य हुन्छ।
• बाइनरी फाइलमा लेख्नु परमाणु अपरेशन होइन। यदि लेखन असफल भयो भने, लेखन आंशिक रूपमा बिग्रन सक्छ।
• धेरै प्रक्रियाहरू (उदाहरणका लागि, sshd र login) एकै समयमा जर्नलमा लेख्दा द्वन्द्वबाट बच्न, फ्लक लकहरू प्रयोग गरिन्छ, जसले परमाणुताको ग्यारेन्टी गर्दैन र गतिरोध निम्त्याउन सक्छ।

RFC लेखकले SQLite प्रयोग गर्ने विशेष साझा पुस्तकालयहरूको पक्षमा बाइनरी ढाँचाहरू पूर्ण रूपमा त्याग्ने प्रस्ताव राखेका छन्। प्रत्येक लग प्रकारको लागि एक समान C इन्टरफेस भएको छुट्टै पुस्तकालय सिर्जना गरिँदैछ: liblastlog2, libbtmp2, libutmp2, र libwtmp2। सबै पुस्तकालयहरूले डाटाबेसहरूसँग काम गर्छन् जसको स्किमामा ६४-बिट टाइमस्ट्याम्पहरू (INTEGER प्रकार) र प्रयोगकर्ता र समय अनुक्रमणिकाहरू समावेश छन्। अनुकूलता तोडेर (ALTER TABLE मार्फत) नयाँ क्षेत्रहरू थप्न सकिन्छ।

SQLite प्रयोग गर्ने पक्षमा रहेका केही तर्कहरूमा युगान्तकारी समय भण्डारण गर्न ६४-बिट INTEGER प्रकारको प्रयोग, पूर्ण स्क्यानको सट्टा रेकर्डहरू छनौट रूपमा पहुँच गरेर I/O घटाउन अनुक्रमणिकाहरूको प्रयोग, अवस्थित रेकर्डहरू परिवर्तन नगरी नयाँ क्षेत्रहरू थप्ने क्षमता, ACID लेनदेनको लागि समर्थन, लक बिना समवर्ती पहुँचको लागि WAL (लेखन-अगाडि लगिङ) मोड, र SQLite को प्रमाणित विश्वसनीयता समावेश छन्।

सहज संक्रमण सुनिश्चित गर्न, दोहोरो-लेखन रणनीति प्रस्ताव गरिएको छ:

• बाइनरी फाइलहरू (लगइन, sshd, sudo, cron, आदि) मा लेख्ने प्रोग्रामहरूलाई उपयुक्त पुस्तकालय मार्फत पुरानो बाइनरी फाइल र नयाँ SQLite डाटाबेस दुवैमा एकैसाथ लेख्न परिमार्जन गरिन्छ।
• छिटो कार्यसम्पादनको लागि अनुक्रमणिका प्रयोग गरेर SQLite डाटाबेसबाट डेटा पढ्ने उपयोगिताहरूको नयाँ संस्करणहरू (last2, lastb2, who2, lastlog2) विकास भइरहेका छन्। पुराना उपयोगिताहरूले उही फाइलहरूसँग काम गर्न जारी राख्छन्।
• केही वर्षमा, जब धेरैजसो प्रणालीहरू अद्यावधिक हुन्छन्, पुरानो ढाँचाहरूमा रेकर्डिङको लागि समर्थन असक्षम हुन सक्छ, र पुराना उपयोगिताहरू अप्रचलित घोषित हुन सक्छ।

थप छलफलको लागि प्रश्नहरू:

• छुट्टाछुट्टै पुस्तकालयहरूमा विभाजन गर्ने वा तिनीहरूलाई एउटैमा संयोजन गर्ने सल्लाह (उदाहरणका लागि, libsession2)।
• पुस्तकालय र उपयोगिताहरूको लागि नामहरू छनौट गर्दै (ऐतिहासिक नामहरू राख्नुहोस् वा थप सामान्य नामहरूमा स्विच गर्नुहोस्)।
• डाटाबेस फाइलहरूको स्थान (/var/lib/ अनुप्रयोग स्थितिको लागि वा /var/log/ लगहरूको लागि)।
• स्कीमा संस्करण र माइग्रेसन संयन्त्र।
• विभिन्न परिदृश्यहरूको लागि SQLite प्रदर्शन प्यारामिटरहरू (सर्भरहरू, एम्बेडेड प्रणालीहरू)।
• SQLite ओभरकिल हुन सक्ने प्रणालीहरूको लागि हल्का बाइनरी ढाँचामा लगहरू भण्डारण गर्ने फलब्याक ब्याकएन्ड प्रदान गर्दछ (जस्तै, गम्भीर मेमोरी अवरोधहरू भएका एम्बेडेड उपकरणहरू)।

स्रोत: opennet.ru