أي ملف openvpn ثنائي قيد التشغيل؟ تحقّق من مسار الإطلاق

نقل حلّ قديم الملف التنفيذي لـ OpenVPN إلى مكان آخر وترك غلافًا نصيًا عند المسار الأصلي. بعد أشهر تأتي ترقية، فيتحول التراجع عن الحل إلى لعبة تخمين حول أي ملف هو العميل حقًا. يمكن لاسم الأمر والملف التنفيذي المهيّأ في الخدمة وقائمة ملفات الحزمة نفسها أن تشير جميعًا إلى كائنات مختلفة، وإصلاح أحدها دون الآخرين ينتج مضيفًا يبدو سليمًا ويعمل بشكل أسوأ.

ابدأ بالمسار الذي تطلقه الخدمة

لا يحلّ الطرفية ووحدة systemd الملفات التنفيذية بالطريقة نفسها. يبحث الصدَفة في 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 بينما يحلّ صدفتك /usr/sbin/openvpn، فإن إصلاح الملف الثاني لا يغيّر شيئًا في الخدمة.

اسأل أي حزمة تملك كل مرشّح، ثم قرّر ما إذا كان الملف مُدارًا من الحزمة أو موضوعًا محليًا. الملف الذي لا تملكه أي حزمة هو ملف وضعه أحدهم عن قصد، ويستحق اسمًا ومالكًا وسببًا قبل حذفه. الخطأ المعاكس شائع أيضًا: الكتابة فوق ملف حزمة بملف ثنائي قديم محفوظ لأن منشورًا في منتدى استخدم الدليل نفسه.

دع قاعدة بيانات الحزم تتحدث عن ملفات الحزم

حين يأتي البرنامج من حزمة Debian، يمكن لقاعدة بيانات الحزم أن تخبرك هل ما زالت ملفاته تطابق ما ثُبّت. هذا سؤال تكامل ضيّق، وليس حكمًا أمنيًا، والفرق يهم حين تقرّر ما يجب إصلاحه. عدم التطابق يعني أن الملف تغيّر بعد التثبيت، وقد يكون حلك القديم أو تعديلًا محليًا مشروعًا. لا يحسم المخرَج أيّهما، فاقرأه كمؤشر لا كاستنتاج.

شغّل التحقق واقرأ المخرَج بدلًا من اعتبار نتيجة فارغة دليلًا على أي شيء.

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

يوثّق دليل dpkg أن التحقق يقارن الملفات المثبّتة ببيانات وصفية مسجّلة محليًا، باستخدام مجاميع تحقق مخزّنة حيث توجد. يلاحظ ملف حزمة متغيّرًا، ولا يستطيع أن يخبرك هل يُطلق ملف ثنائي آخر بدلًا منه.

سجّل الحالة قبل الإصلاح

اجمع مسار الإطلاق المحلول، وعلاقة الملف بالحزمة، وموقع الغلاف، وسجل التغيير الذي أدخله. انسخ الغلاف إلى مكان محمي إذا كان يحتوي على عمل تكامل ستحتاجه لاحقًا.

لا تلصق محتويات الغلاف في سلسلة دعم قبل قراءتها، لأن هذه النصوص تحمل أحيانًا بيانات اعتماد أو تفاصيل بوابة.

سجّل أي ملفات تعريف تستخدمها الخدمة ومن المتصل أثناء عملك، لأن إعادة تشغيل النفق قد تقطع الجلسة التي تدير بها المضيف.

تحقّق من الإطلاق، ثم أزل الغلاف

بعد الإصلاح، ابدأ الخدمة وأكّد أن العملية تعمل على المسار الذي أردته. استعلام إصدار يُنفَّذ يدويًا يثبت أن الملف يعمل؛ ولا يثبت أن الوحدة تستخدمه.

ثم أعد توصيل عميل وتحقق من أن ملف التعريف ما زال يوثّق، لأن تبديل ملف ثنائي يتجاهل الخيارات الأصلية سيفشل بطريقة تبدو كمشكلة شهادة.

أزل الغلاف المُزاح عبر سجل التغيير نفسه الذي أدخله. الإصلاح المكتمل يذكر أي ملف تنفيذي يعمل، ولماذا، وأي ملف أُزيل؛ واستعادة اسم ملف مع الأمل ليست الشيء نفسه.