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 کی ترجیح اور ضم ہونے کی ترتیب کی دستاویز کرتا ہے۔