एक 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 वरीयता और मर्ज क्रम का दस्तावेज़ीकरण करता है।