एका टनेलसाठी जोडलेले रीस्टार्ट धोरण मशीनवरील प्रत्येक टनेलवर लागू होऊ लागते। ही 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 प्राधान्य आणि विलीनीकरण क्रमाचे दस्तऐवजीकरण करतो।

संबंधित लेख