RAM में चलने वाला VPN रनटाइम लॉग के बारे में कुछ नहीं कहता

केवल पढ़ने योग्य इमेज से बूट होकर अपनी रनटाइम स्थिति tmpfs पर रखने वाला VPN सर्वर वास्तविक और उपयोगी डिज़ाइन है। इसे लॉग-रहित बताना भी आसान है, जो डिज़ाइन साबित नहीं करता। संग्रहण स्थान तय करता है कि प्रति कहाँ रहती है; संग्रहण और प्रतिधारण तय करते हैं कि रिकॉर्ड है भी या नहीं, और रीबूट केवल पहले को प्रभावित करता है। इन दोनों को अलग रखना ही पूरी समीक्षा है।

उन सभी प्रक्रियाओं की सूची बनाकर शुरू करें जो स्थिति लिख सकती हैं: डेमन, प्रमाणीकरण सेवा, जर्नल, कोई भी मॉनिटरिंग एजेंट और प्रबंधन उपकरण।

संग्रहण और संग्रह दो अलग प्रश्न हैं

हर लेखक का अपना गंतव्य और अपनी नीति है। VPN डेमन स्थिति फ़ाइलें लिखता है, प्रमाणीकरण बैकएंड खाता घटनाएँ लिखता है, जर्नल सेवाओं का आउटपुट इकट्ठा करता है, और मॉनिटरिंग एजेंट मेट्रिक्स कहीं और भेजता है। जो डिज़ाइन इनमें से एक को रीबूट पर गायब कर देता है, उसने बाकी तीन के बारे में कुछ नहीं कहा। हर लेखक को उसके गंतव्य तक पीछे चलाइए और नोट कीजिए कि वह गंतव्य मशीन पर है भी या नहीं।

एप्लिकेशन-विशिष्ट फ़ाइलें, अपलोड किया गया निदान और बाहरी सेवाएँ भी वही व्यवहार चाहती हैं। परिचित स्थानीय लॉग का अभाव यह साबित नहीं करता कि कनेक्शन या खाता रिकॉर्ड कहीं नहीं हैं; यह साबित करता है कि आपने अभी तक नहीं खोजा कि वे कहाँ जाते हैं।

tmpfs कोई गारंटी नहीं है

Linux tmpfs भौतिक RAM डिस्क नहीं है। कर्नेल दस्तावेज़ स्पष्ट है कि माउंट अनुमति देने पर पेज swap में लिखे जा सकते हैं, इसलिए tmpfs फ़ाइल डिस्क तक पहुँच सकती है, भले ही एप्लिकेशन ने उसे कभी वहाँ नकल न किया हो। mount दिखाता है कि swap-आधारित tmpfs काम में है या नहीं, और अन्य मेमोरी फ़ाइलसिस्टम और भी अलग व्यवहार करते हैं। /run के अंतर्गत पथ का अर्थ अस्थिरता मानने के बजाय वास्तविक माउंट विकल्प पढ़िए।

फिर उन चीज़ों की सूची बनाइए जो रीबूट के बाद भी उन तरीकों से बची रहती हैं जिन्हें लोग भूल जाते हैं: स्थायी ऊपरी परत, जुड़ा संग्रहण, हाइबरनेशन इमेज, क्रैश डंप और पूरे VM के अधोसंरचना स्नैपशॉट। इनमें से हर एक उस स्थिति का संभावित गंतव्य है जिसे आप क्षणिक मानते थे। वह सूची जाँचने की चीज़ है, यह दावा नहीं कि हर होस्ट के पास ये सब हैं।

Journald के दो गंतव्य और एक फ़ॉरवर्डर है

Journald इस विभाजन को साफ़ दिखाता है। अस्थिर संग्रहण प्रविष्टियाँ /run/log/journal के अंतर्गत रखता है, स्थायी संग्रहण /var/log/journal के अंतर्गत, और स्वचालित मोड दोनों में से चुनता है; प्रभावी मोड चल रहे सिस्टम से आता है, इमेज के विवरण से नहीं। अस्थिर में बदलने से पहले से स्थायी रूप से लिखा गया नहीं मिटता। फ़ॉरवर्डिंग भी अलग चैनल है: स्थानीय रूप से कुछ न रखने वाला संग्रहण सेटिंग भी संदेश किसी अन्य लक्ष्य को सौंप सकता है।

प्रभावी मोड जर्नल से ही या उसकी कॉन्फ़िगरेशन फ़ाइल से पढ़िए, फिर फ़ॉरवर्डिंग लक्ष्य अलग से जाँचिए, क्योंकि एक सेटिंग दूसरे को नियंत्रित नहीं करती।

रीबूट के बाद क्या बचना चाहिए

स्थिति-रहित रनटाइम दोहराने योग्य प्रतिस्थापन का समर्थन करता है, और उसे कॉन्फ़िगरेशन, प्राधिकरण और पुनर्प्राप्ति सामग्री के लिए जानबूझकर स्रोत चाहिए जो सेवा खुद नहीं बना सकती। स्थानीय लेखन गायब करने के लिए एकमात्र काम करने वाली नामांकन या निरसन स्थिति खोना बुरा सौदा है, और आम भी। जानबूझकर तय कीजिए कि क्या बचना चाहिए, फिर जाँचिए कि बचता है।

वही तर्क परिचालन रिकॉर्ड पर लागू होता है। तय कीजिए कि सुरक्षा और सेवा प्रबंधन को वास्तव में कौन-सी घटनाएँ चाहिए, उचित दायरे और प्रतिधारण के साथ, और बाकी को न्यूनतम कीजिए। न्यूनतम करना हर निदान बंद करने के बराबर नहीं है।

प्रभावी संग्रहण और फ़ॉरवर्डिंग कॉन्फ़िगरेशन की कुछ हानिरहित घटनाओं से तुलना कीजिए, फिर मशीन को रीबूट या बदलिए और फिर जाँचिए कि क्या बचा और सेवा ने अपनी स्थिति कहाँ से पुनःप्राप्त की।