هل حزمة openfortivpn .deb القديمة مناسبة فعلًا لـ Raspberry Pi لديك؟

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

ما يثبّته اسم الملف بصمت

اقرأ اسمًا مثل openfortivpn_1.17.0-1_armhf.deb من اليمين إلى اليسار. اللاحقة هي المعمارية التي جُمّع من أجلها الملف التنفيذي، والحقل الأوسط هو إصدار المصدر والتغليف، والحقل الرابع الضمني هو مجموعة المكتبات في التوزيعة التي بُني فيها.

على تثبيت 64 بت من Raspberry Pi OS تكون معمارية النظام arm64، لذا يرفض dpkg -i حزمة armhf بسبب عدم تطابق المعمارية. وحتى حين يجعل multiarch التثبيت ممكنًا، يتوقع الملف التنفيذي إصدارات مكتبات من الإصدار الذي بُني مقابله، وقد لا يوفّرها نظام أساس أحدث. النتيجة حزمة مثبّتة حيث لا يستطيع الملف التنفيذي البدء، وهو العطل الذي يفسّره الناس عادةً خطأً بأن العميل نفسه معطوب.

كون اللوحة جهاز ARM لا يجعل حزمة ARM مناسبة. المعمارية محور واحد؛ الإصدار وABI هما المحوران الآخران، ويفشلان بشكل مستقل.

اسأل التوزيعة قبل أن تسأل عن رابط تنزيل

كل قناة مُدارة تستطيع أن تخبرك بما ستثبّته الآن. نفّذ الاستعلام على الجهاز الهدف، بالمستودعات التي يستخدمها فعلًا، قبل التفكير في أي نقل للملفات.

cat /etc/os-release
dpkg --print-architecture
apt-cache policy openfortivpn

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

إذا فشل تحديث البيانات الوصفية، فافصل ذلك الفشل عن مسألة الحزمة. تحليل الأسماء ونقل المستودعات وتوقيع Release المفقود وتوزيعة منتهية الصلاحية كلها تعطّل apt update قبل أن يدخل العميل في الأمر. إصلاح المصادر مهمة مختلفة عن اختيار عميل VPN، وخلط الاثنين هو ما يجعل الناس يوجّهون نظامًا حديثًا إلى إصدار قديم.

ما يتحقق منه apt، وما لا تحصل عليه حزمة منزّلة

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

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

كتم أخطاء التوقيع أو تعطيل التحقق من TLS لإبقاء تعليمات قديمة تعمل يزيل الجزء الوحيد من العملية الذي كان يتحقق من أي شيء. أعد الفحص الفاشل بدلًا من ذلك.

ثبّت العميل، ثم شخّص الاتصال بشكل منفصل

عندما يوجد مرشّح مُدار، ثبّته عبر المعاملة العادية المراجَعة ودع مدير الحزم يسجّل ما فعله.

إذا كان النشر يحتاج فعلًا إلى بناء من المصدر، فاتبع تعليمات البناء الحالية للمشروع وتعامل معه كبرنامج أصبحت أنت مسؤولًا عن صيانته: حزم التطوير، ثم pkg-config، وترويسات مكتبة TLS وخادم PPP تبعيات حقيقية، وكذلك إجراء الإزالة الذي ستحتاجه لاحقًا.

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

الخطة التي ينبغي أن تحل محل اسم الملف القديم

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

أخيرًا سمِّ المشرف ومسار التحديث. Raspberry Pi يشغّل عميلًا لا يملكه أحد سيستمر في العمل حتى أول ترقية مكتبة، ثم سيجد شخص آخر يعاني المشكلة نفسها نفس خيط المنتدى.

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