RAM मध्ये चालणारा VPN रनटाइम लॉगबद्दल काहीही सांगत नाही

फक्त-वाचन इमेजमधून बूट होऊन आपली रनटाइम स्थिती tmpfs वर ठेवणारा VPN सर्व्हर वास्तविक आणि उपयुक्त रचना आहे। त्याला लॉग-रहित असे वर्णन करणेही सोपे आहे, जे रचना सिद्ध करत नाही। संचयन स्थान ठरवते की प्रत कुठे राहते; संकलन आणि धारणा ठरवतात की रेकॉर्ड अस्तित्वात आहे का, आणि रीबूट फक्त पहिल्यावर परिणाम करते। हे दोन वेगळे ठेवणे हीच संपूर्ण पुनरावलोकन।

स्थिती लिहू शकणाऱ्या प्रत्येक प्रक्रियेची यादी करून सुरुवात करा: डेमन, प्रमाणीकरण सेवा, जर्नल, कोणताही देखरेख एजंट आणि व्यवस्थापन साधने।

संचयन आणि संकलन वेगवेगळे प्रश्न आहेत

प्रत्येक लेखकाचे स्वतःचे गंतव्य आणि स्वतःचे धोरण असते। VPN डेमन स्थिती फाइली लिहितो, प्रमाणीकरण बॅकएंड खाते घटना लिहिते, जर्नल सेवांचे आउटपुट गोळा करते, आणि देखरेख एजंट मेट्रिक्स पूर्णपणे दुसरीकडे पाठवतो। यापैकी एक रीबूटवर अदृश्य करणारी रचना उर्वरित तीनबद्दल काहीही सांगत नाही। प्रत्येक लेखकाला त्याच्या गंतव्यापर्यंत पाठलाग करा आणि ते गंतव्य यंत्रावर आहे का ते नोंदवा।

अनुप्रयोग-विशिष्ट फाइली, अपलोड केलेले निदान आणि बाह्य सेवांनाही तीच वागणूक हवी। परिचित स्थानिक लॉग नसणे हे कनेक्शन किंवा खाते रेकॉर्ड कुठेही नाहीत याचा पुरावा नाही; ते कुठे जातात हे तुम्हाला अजून सापडले नाही याचा पुरावा आहे।

tmpfs ही हमी नाही

Linux tmpfs भौतिक RAM डिस्क नाही। माउंट परवानगी देतो तेव्हा पाने swap मध्ये लिहिता येतात असे कर्नेल दस्तऐवज स्पष्ट सांगते, त्यामुळे अनुप्रयोगाने कधीही तिथे प्रत केली नसली तरी tmpfs फाइल डिस्कपर्यंत पोहोचू शकते। mount swap-आधारित tmpfs कार्यरत आहे का हे दाखवते, आणि इतर मेमरी फाइलसिस्टम वेगळ्या पद्धतीने वागतात। /run खालील मार्ग अस्थिरता दर्शवतो असे गृहीत धरण्याऐवजी प्रत्यक्ष माउंट पर्याय वाचा।

नंतर लोक विसरतात अशा पद्धतींनी रीबूट टिकून राहणाऱ्या गोष्टींची यादी करा: कायमचा वरचा थर, जोडलेले संचयन, हायबरनेशन इमेज, क्रॅश डंप आणि संपूर्ण VM चे पायाभूत स्नॅपशॉट। प्रत्येकजण तुम्ही क्षणिक मानलेल्या स्थितीसाठी संभाव्य गंतव्य आहे। ती यादी तपासण्याची गोष्ट आहे, प्रत्येक होस्टकडे सर्व असतात असा दावा नाही।

Journald ला दोन गंतव्ये आणि एक फॉरवर्डर आहे

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

अंमलात असलेला मोड जर्नलमधूनच किंवा त्याच्या कॉन्फिगरेशन फाइलमधून वाचा, नंतर फॉरवर्डिंग लक्ष्ये स्वतंत्रपणे तपासा, कारण एक सेटिंग दुसऱ्याला नियंत्रित करत नाही।

रीबूटनंतर काय टिकले पाहिजे

स्थितीहीन रनटाइम पुनरावृत्तीय बदलीला आधार देतो, आणि सेवा स्वतः शोधू शकत नाही अशा कॉन्फिगरेशन, अधिकृतता आणि पुनर्प्राप्ती सामग्रीसाठी हेतुपूर्वक स्रोत लागतात। स्थानिक लेखन अदृश्य होण्यासाठी कार्यरत एकमेव नोंदणी किंवा रद्दीकरण स्थिती गमावणे हा वाईट सौदा आहे, आणि सामान्यही। हेतुपूर्वक काय टिकले पाहिजे ते ठरवा, नंतर ते टिकते याची खात्री करा।

तोच तर्क कार्यचालन नोंदींना लागू होतो। सुरक्षा आणि सेवा व्यवस्थापनाला खरोखर कोणत्या घटना हव्यात हे न्याय्य व्याप्ती आणि धारणेसह ठरवा, आणि उर्वरित कमी करा। कमी करणे म्हणजे प्रत्येक निदान बंद करणे नव्हे।

अंमलात असलेली संचयन आणि फॉरवर्डिंग कॉन्फिगरेशन काही निरुपद्रवी घटनांशी तुलना करा, नंतर यंत्र रीबूट करा किंवा बदला आणि काय शिल्लक राहिले, सेवेने आपली स्थिती कुठून पुनर्प्राप्त केली याची पुन्हा तपासणी करा।