RAM मा चल्ने VPN रनटाइम लगहरूको बारेमा केही भन्दैन

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

अवस्था लेख्न सक्ने प्रत्येक प्रक्रियाको सूची बनाएर सुरु गर्नुहोस्: डेमन, प्रमाणीकरण सेवा, जर्नल, कुनै पनि निगरानी एजेन्ट र व्यवस्थापन उपकरणहरू।

भण्डारण र सङ्कलन फरक प्रश्न हुन्

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

अनुप्रयोग-विशेष फाइलहरू, अपलोड गरिएको निदान र बाह्य सेवाहरूलाई पनि त्यही व्यवहार चाहिन्छ। परिचित स्थानीय लग नहुनुले जडान वा खाता रेकर्ड कतै छैनन् भनी प्रमाणित गर्दैन; यसले ती कहाँ जान्छन् भन्ने तपाईंले अझै फेला पार्नुभएको छैन भनी प्रमाणित गर्छ।

tmpfs कुनै ग्यारेन्टी होइन

Linux tmpfs भौतिक RAM डिस्क होइन। माउन्टले अनुमति दिएमा पृष्ठहरू swap मा लेख्न सकिन्छ भनी कर्नेल कागजातले स्पष्ट भन्छ, त्यसैले अनुप्रयोगले कहिल्यै त्यहाँ प्रतिलिपि नगरे पनि tmpfs फाइल डिस्कसम्म पुग्न सक्छ। mount ले swap-समर्थित tmpfs काममा छ कि छैन देखाउँछ, र अन्य मेमोरी फाइलसिस्टमहरू अझ फरक व्यवहार गर्छन्। /run मुनिको बाटोले अस्थिरता जनाउँछ भनी अनुमान गर्नुको सट्टा वास्तविक माउन्ट विकल्पहरू पढ्नुहोस्।

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

Journald सँग दुई गन्तव्य र एक फर्वार्डर छ

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

प्रभावमा रहेको मोड जर्नलबाटै वा यसको कन्फिगरेसन फाइलबाट पढ्नुहोस्, त्यसपछि फर्वार्डिङ लक्ष्यहरू छुट्टै जाँच्नुहोस्, किनकि एउटा सेटिङले अर्कोलाई नियन्त्रण गर्दैन।

रिबुटपछि के रहनुपर्छ

अवस्थाविहीन रनटाइमले दोहोर्याउन सकिने प्रतिस्थापनलाई समर्थन गर्छ, र सेवा आफैँले आविष्कार गर्न नसक्ने कन्फिगरेसन, अधिकार र पुनःप्राप्ति सामग्रीका लागि जानाजान स्रोतहरू चाहिन्छ। स्थानीय लेखनहरू हराउनका लागि काम गर्ने एकमात्र दर्ता वा रद्दीकरण अवस्था गुमाउनु खराब सौदा हो, र सामान्य पनि। जानाजान के रहनुपर्छ भनी निर्णय गर्नुहोस्, त्यसपछि त्यो रहन्छ भनी प्रमाणित गर्नुहोस्।

त्यही तर्क सञ्चालन रेकर्डहरूमा लागू हुन्छ। सुरक्षा र सेवा व्यवस्थापनलाई साँच्चै कुन घटनाहरू चाहिन्छ भनी न्यायोचित दायरा र अवधारणसहित निर्णय गर्नुहोस्, र बाँकीलाई न्यूनतम बनाउनुहोस्। न्यूनतम बनाउनु प्रत्येक निदान बन्द गर्नुसँग बराबर होइन।

प्रभावमा रहेको भण्डारण र फर्वार्डिङ कन्फिगरेसनलाई केही हानिरहित घटनाहरूसँग तुलना गर्नुहोस्, त्यसपछि मेसिन रिबुट वा प्रतिस्थापन गर्नुहोस् र के बाँकी रह्यो, सेवाले आफ्नो अवस्था कहाँबाट पुनःप्राप्त गर्यो भनी फेरि जाँच्नुहोस्।