کون سی openvpn بائنری چل رہی ہے؟ لانچ راستہ جانچیں

ایک پرانے حل نے OpenVPN کی قابلِ عمل فائل کو کہیں اور منتقل کر دیا اور اصل راستے پر shell ریپر چھوڑ دیا۔ مہینوں بعد اپ ڈیٹ آتی ہے، اور اس حل کو واپس کرنا ایک اندازے کا کھیل بن جاتا ہے کہ اصل میں کون سی فائل کلائنٹ ہے۔ کمانڈ کا نام، سروس میں ترتیب دی گئی قابلِ عمل فائل اور پیکیج کی اپنی فائل فہرست سب مختلف چیزوں کی طرف اشارہ کر سکتے ہیں، اور باقیوں کے بغیر ایک کی مرمت ایسا میزبان بناتی ہے جو ٹھیک دکھتا ہے اور زیادہ برا برتاؤ کرتا ہے۔

اُس راستے سے شروع کریں جو سروس شروع کرتی ہے

ٹرمینل اور systemd یونٹ قابلِ عمل فائلوں کو ایک جیسے حل نہیں کرتے۔ shell PATH میں تلاش کرتا ہے؛ یونٹ راستہ بتاتا ہے، اور drop-in تبدیلیاں اُس فائل کو چھوئے بغیر اُسے بدل سکتی ہیں جو آپ پڑھ رہے ہیں۔ یہی فرق اس کام کی بیشتر الجھن کی وضاحت کرتا ہے۔ یہ بھی طے کرتا ہے کہ آپ کی مرمت کو کون سی فائل نشانہ بنانی ہے۔

یونٹ سے پوچھیں کہ وہ کیا چلاتا ہے، اُسے بدلنے والے drop-in سمیت، اور جس حصے کو آپ مستند سمجھتے ہیں اُس کی بجائے نتیجے میں آنے والی ExecStart سطر پڑھیں۔ پھر اُس راستے کی پیروی کسی بھی علامتی لنک سے ہوتے ہوئے آخری فائل تک کریں۔ چھپی ہوئی ڈائریکٹری میں exec پر ختم ہونے والا ریپر اِن پرانے حل کا عام ڈھانچہ ہے۔

کچھ بھی بدلنے سے پہلے حل شدہ راستہ لکھ لیں۔

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

کمانڈ کے نام کا سروس کے راستے سے موازنہ کریں

دونوں جواب اکثر مختلف ہوتے ہیں، اور یہ فرق بذاتِ خود خرابی نہیں۔ NetworkManager پلگ ان اپنا راستہ شروع کر سکتا ہے، اور کنٹینر کوئی اور ماؤنٹ کر سکتا ہے۔

اہم یہ جاننا ہے کہ ٹریفک کی خدمت کرنے والے عمل کو کون سا مالک شروع کرتا ہے۔ اگر یونٹ /usr/local/sbin/openvpn-wrapper چلاتا ہے جبکہ آپ کا shell /usr/sbin/openvpn حل کرتا ہے، تو دوسری فائل کی مرمت سروس میں کچھ نہیں بدلتی۔

پوچھیں کہ ہر امیدوار کس پیکیج کا ہے، پھر فیصلہ کریں کہ فائل پیکیج کے زیرِ انتظام ہے یا مقامی طور پر رکھی گئی ہے۔ مالک پیکیج کے بغیر فائل وہ فائل ہے جو کسی نے جان بوجھ کر وہاں رکھی ہے، اور مٹانے سے پہلے وہ نام، مالک اور وجہ کی حقدار ہے۔ اُلٹی غلطی بھی عام ہے: پیکیج فائل کو پرانی محفوظ بائنری سے اوپر لکھنا کیونکہ کسی فورم کی پوسٹ نے وہی ڈائریکٹری استعمال کی تھی۔

پیکیج فائلوں کے بارے میں پیکیج ڈیٹابیس کو بولنے دیں

جب سافٹ ویئر Debian پیکیج سے آیا ہو، تو پیکیج ڈیٹابیس بتا سکتا ہے کہ اُس کی فائلیں ابھی بھی نصب شدہ سے مطابقت رکھتی ہیں یا نہیں۔ یہ سالمیت کا ایک تنگ سوال ہے، سلامتی کا فیصلہ نہیں، اور یہ فرق اُس وقت اہم ہے جب آپ فیصلہ کرتے ہیں کہ کیا مرمت کرنی ہے۔ عدم مطابقت کا مطلب ہے کہ فائل نصب کے بعد بدلی، جو آپ کا پرانا حل یا جائز مقامی ترمیم ہو سکتی ہے۔ نتیجہ یہ طے نہیں کرتا کہ کون سی، اس لیے اسے نتیجے کی بجائے اشارے کے طور پر پڑھیں۔

توثیق چلائیں اور خالی نتیجے کو کسی چیز کا ثبوت سمجھنے کی بجائے نتیجہ پڑھیں۔

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

dpkg دستی درج کرتی ہے کہ توثیق نصب شدہ فائلوں کا مقامی طور پر درج میٹاڈیٹا سے موازنہ کرتی ہے، جہاں موجود ہوں وہاں محفوظ چیک سم استعمال کرتی ہے۔ یہ بدلی ہوئی پیکیج فائل کو نوٹ کرتی ہے، اور یہ نہیں بتا سکتی کہ اُس کی بجائے کوئی اور بائنری چل رہی ہے۔

مرمت سے پہلے حالت درج کریں

حل شدہ لانچ راستہ، فائل کا پیکیج سے تعلق، ریپر کا مقام اور وہ تبدیلی ریکارڈ جمع کریں جس نے اُسے لایا۔ اگر ریپر میں بعد میں درکار انضمام کا کام ہو تو اُسے محفوظ جگہ پر نقل کریں۔

پڑھنے سے پہلے ریپر کا مواد کسی معاونت تھریڈ میں نہ چسپاں کریں، کیونکہ یہ اسکرپٹس کبھی کبھی اسناد یا گیٹ وے کی تفصیلات رکھتے ہیں۔

کام کے دوران درج کریں کہ سروس کون سے پروفائل استعمال کرتی ہے اور کون جڑا ہوا ہے، کیونکہ ٹنل دوبارہ شروع کرنے سے وہ سیشن منقطع ہو سکتا ہے جس سے آپ میزبان کا انتظام کر رہے ہیں۔

لانچ کی توثیق کریں، پھر ریپر ہٹائیں

مرمت کے بعد سروس شروع کریں اور تصدیق کریں کہ عمل آپ کے مطلوبہ راستے پر چل رہا ہے۔ ہاتھ سے چلائی گئی ورژن استفسار ثابت کرتی ہے کہ فائل کام کرتی ہے؛ یہ ثابت نہیں کرتی کہ یونٹ اُسے استعمال کرتا ہے۔

پھر کلائنٹ دوبارہ جوڑیں اور دیکھیں کہ پروفائل اب بھی تصدیق کرتا ہے، کیونکہ اصل اختیارات کو نظر انداز کرنے والی بائنری تبدیلی اِس طرح ناکام ہوگی جو سرٹیفکیٹ کے مسئلے جیسی لگے۔

ہٹایا گیا ریپر اُسی تبدیلی ریکارڈ کے ذریعے ہٹائیں جس نے اُسے لایا۔ مکمل مرمت بتاتی ہے کہ کون سی قابلِ عمل فائل چل رہی ہے، کیوں، اور کون سی فائل ہٹائی گئی؛ فائل کا نام بحال کرنا اور اُمید رکھنا ایک ہی بات نہیں۔