एउटै OpenVPN drop-in ले हरेक टनेल बदल्यो: इन्स्टेन्स बनाम टेम्प्लेट

एउटा टनेलका लागि थपिएको रिस्टार्ट नीति मेसिनको हरेक टनेलमा लागू हुन थाल्छ। यो systemd को बग होइन; यो इन्स्टेन्स drop-in र टेम्प्लेट drop-in बीचको फरक हो। फाइल कुन मार्गमुनि लेख्नुहुन्छ भन्नेले कति सेवाले त्यो उत्तराधिकारमा पाउँछन् भन्ने निर्धारण गर्छ।

सेटिङअघि दायरा छान्नुहोस्। दुवै डाइरेक्टरी लगभग उस्तै देखिन्छन्, र तीमध्ये एउटा मात्र तपाईंले चाहेको इन्स्टेन्समा सीमित छ।

लक्षण: एउटा सम्पादन, हरेक टनेल

निश्चित इन्स्टेन्सको drop-in पूरा इन्स्टेन्सको नामको डाइरेक्टरीमुनि रहन्छ, जस्तै [email protected]। टेम्प्लेट drop-in [email protected] मुनि रहन्छ, बीचमा @ चिन्ह हुन्छ र इन्स्टेन्सको नाम हुँदैन। पहिलो office मा मात्र लागू हुन्छ। दोस्रो त्यो टेम्प्लेटबाट बनाइने हरेक सेवामा लागू हुन्छ।

टेम्प्लेट स्वरूप अलग [email protected] टेम्प्लेटसम्म पुग्दैन, र नाममा openvpn भएका असम्बन्धित सेवासम्म पनि पुग्दैन।

दायरासँग मिल्ने डाइरेक्टरी छान्नुहोस्

दुवै डाइरेक्टरी /etc/systemd/system/ मुनि छन्। अन्तिम system घटक छोड्दा systemd ले प्रणाली ओभरराइडका रूपमा नपढ्ने मार्ग बन्छ, र यो ठीक देखिने फाइललाई केही नगराउने शान्त उपाय हो। पूरा मार्ग एकचोटि लेख्नुहोस् र फेरि प्रयोग गर्नुहोस्।

drop-in लाई ठीक खण्ड शीर्षक पनि चाहिन्छ। सेवा सेटिङहरू [Service] मुनि पर्छन्। सेटिङ भए तर खण्ड नभएको फाइल बेवास्ता वा अस्वीकार गरिन्छ, र फाइल त्यहाँ अधिकारिक देखिँदै गर्दा unit पहिलेजस्तै व्यवहार गरिरहन्छ।

एकभन्दा बढी drop-in थप्दै हुनुहुन्छ भने उद्देश्य फाइल नाममा राख्नुहोस्। शब्दकोशीय क्रमले मर्ज निर्धारण गर्छ, र फाइल के गर्छ भन्ने नामले त्यो क्रमलाई पढ्नयोग्य बनाउँछ।

लेख्नुअघि मर्ज गरिएको unit पढ्नुहोस्

केही लेख्नुअघि मर्ज गरिएको unit पढ्नुहोस्। systemctl cat [email protected] ले मुख्य unit र लागू हुने हरेक drop-in मर्ज क्रममा छाप्छ। टेम्प्लेट परिवर्तन विचार गर्दा त्यसलाई दोस्रो इन्स्टेन्ससँग तुलना गर्नुहोस्। त्यो तुलनाले कुन सेवाले सम्पादन उत्तराधिकारमा पाउँछन् भन्ने ठ्याक्कै देखाउँछ।

इन्स्टेन्स फाइलले टेम्प्लेट सेटिङ मेट्दैन। दुवै मर्ज हुन्छन्, त्यसैलेतपाईंले बिर्सनुभएको टेम्प्लेट मान अझै लागू हुन सक्छ।

अन्य नामित drop-in, रनटाइम सेटिङ र प्याकेजले दिने कन्फिगरेसन पनि सहभागी हुन्छन्। तपाईंले अन्तिममा सम्पादन गरेको फाइल नै पूरा unit हो भनी नठान्नुहोस्। मर्ज गरिएको आउटपुट नै unit हो।

unit नीति प्रोफाइलबाहिर राख्नुहोस्

unit नीति र VPN कन्फिगरेसन अलग राख्नुहोस्। प्रोफाइल निर्देश [Service] मुनि भएकै कारण वैध systemd वाक्यरचना बन्दैन। रिस्टार्ट सेटिङ पनि .ovpn फाइलमा पर्दैन।

यो विभाजनले नै रिस्टार्ट नीतिOpenVPN ले आफैं गर्ने पियर रिकभरीसँग एउटै नभएको कारण पनि बताउँछ। दायरा छान्नुअघि कस्तो व्यवहार चाहनुहुन्छ निर्णय गर्नुहोस्।

यसलाई लागू गर्नुहोस् र इन्स्टेन्स प्रमाणित गर्नुहोस्

परिवर्तनपछि systemctl daemon-reload प्रयोग गरी म्यानेजरका परिभाषा पुनः लोड गर्नुहोस्। त्यो पुनःलोडले टनेल रिस्टार्ट गर्दैन; यसले unit फाइलहरू मात्र फेरि पढ्छ। त्यसपछि तपाईंले चाहेको जीवनचक्र कार्य ठ्याक्कै इन्स्टेन्समा लागू गर्नुहोस्।

लोड भएको unit फेरि पढेर र तपाईंले बदल्नुभएको व्यवहार अवलोकन गरेर प्रमाणित गर्नुहोस्। सक्रिय काम बोकेको रिस्टार्ट योजनाबद्ध अवरोधको योग्य हुन्छ, उत्पादन टनेलमा द्रुत परीक्षणको होइन। ओभरराइडको उद्देश्य र दायरा डिप्लोयमेन्टको छेउमा लेख्नुहोस् ताकि अर्को व्यक्तिले फाइल साझा गर्नका लागि हो कि होइन भन्ने थाहा पाओस्।

नीति साँच्चै साझा भएमा जानाजान टेम्प्लेटमा सार्नुहोस् र सकियो भन्नुअघि दोस्रो इन्स्टेन्स जाँच्नुहोस्।systemd unit सन्दर्भ ले drop-in प्राथमिकता र मर्ज क्रम दस्तावेजीकरण गर्छ।