التقنيات الموصى بها للتحديث الميداني لنظام Linux المدمج بأمان

Question

غالبًا ما تتطلب الأجهزة المضمنة المستندة إلى Linux آلية لتحديث التطبيقات وملفات النظام.على سبيل المثال، يمكن لأداة معملية (غير متصلة بالشبكة) مزودة بمنفذ USB الحصول على تحديثات البرامج من وحدة تخزين USB.

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

يعد الوضع بالنسبة لملفات التطبيق أسهل قليلاً نظرًا لوجود مساحة لتكرار دليل التطبيق وتحديث نسخة واحدة وتبديل الدلائل القديمة والجديدة بسرعة مما يقلل من نافذة الفشل.

تعتبر الأمور أكثر تعقيدًا بالنسبة لملفات kernel وملفات النظام لأنها منتشرة في جميع أنحاء نظام الملفات.

لقد استخدمنا الروابط الصلبة واللينة في نظام الملفات لتحديد الملفات المهمة.نستخدم التجزئة على الملفات والمحفوظات للتحقق من سلامة الملف.لقد فكرنا في استخدام ramfs للطوارئ في kernel لتوفير بديل في حالة فشل البدء من نظام الملفات المحدث.

ما هي النهج الخاص بك لهذا المطلب؟

Answer 1

سأتبع نفس النهج كما هو الحال مع ملفات التطبيق:قم بإنشاء الملفات المهمة وأكمل القسم الخاص بك، واربطه بها، ثم قم بتكرار القسم.في جميع ملفات init الخاصة بك، يجب عليك أولاً التحقق مما إذا كانت الروابط تظهر جميعها إلى نفس القسم، وإذا لم يكن الأمر كذلك، فقم بإعادة تعيينها (إلى القسم الذي يحتوي على الملفات بأحدث تاريخ لملف معين).إذا كنت ترغب في التحديث، فما عليك سوى نسخ كل شيء إلى القسم الجديد، وإذا كان كل شيء على ما يرام (CRCS ok)، فقم بالتكرار فوق الملفات وقم بتعيين الرابط لكل نظام ملفات إلى الآخر.

بهذه الطريقة يجب أن تكون ملفاتك الهامة دائمًا في حالة سليمة.

السيناريوهات:

1. فشل التحديث أثناء نسخ الملفات إلى القسم الجديد

   لا توجد مشكلة لأن الروابط لا تزال تظهر للروابط العاملة القديمة.

2. فشل التحديث أثناء الارتباط

   لا توجد مشكلة لأن جميع الملفات الجديدة صالحة ومنسوخة بالفعل (وإلا فلن تبدأ خطوة إعادة الربط)، تحقق من الإعداد وصحح هذا

Answer 2

إذا يجب ضمان موثوقية، هل يمكن أن يكون قسمين فلاش (أو حتى رقائق)، واحدة مع تكوين العمل الحالي واحد مع التكوين الجديد. ثم استخدام جهاز مراقبة الأجهزة التي سيتم إعادة تعيين وحدة ومفاتيح النشطة قسم التمهيد فلاش ل"آخر معروف جيدا" التكوين.

Answer 3

لديك قسمين على الأقل.أود أن أقترح 4

• حذاء طويل

• التمهيد البديل

• النسخ الاحتياطي لبيانات البرنامج

• بيانات البرنامج المتقلبة

استخدم التشغيل الاحتياطي لـ grub للتمهيد البديل في حالة فشل التمهيد.

لذا، إذا فشل التحديث، فسيعمل البديل.

لا تقم أبدًا بتحديث محمل الإقلاع.

إذا تم تحميص قسم البيانات، فأعد تنسيقه وانسخه عبر قسم بيانات النسخ الاحتياطي.

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

Answer 4

وIMHO أي تحديث الذي لا الذري يمكن كسر النظام أو جعل الاختيار الاتساق صعبة للغاية. أوافق على أن تحديث محمل الإقلاع يجب تجنبها لأنها ليست خارج السلطة آمن. عموما، وهي الشركة المصنعة يريدون تحديثا من البرامج الثابتة x.x.x إلى الإصدار y.y.y، دون أن يكلف نفسه عناء إذا تم تحديث نواة و / أو ملف واحد. يمكن تحديث ملفات واحد يتحول إلى كابوس للخدمة، لأنه من الصعب جدا أن نفهم ما يتم تشغيله على أجهزة العملاء. ربما كنت خلط نهج نسخة المزدوج (تطبيق لا لزوم لها) مع نهج واحد، نسخة. أعتقد أن هذا لا يساعد كثيرا، لأنه يتم على سلامة النظام المكون الضعيفة في السلسلة. إذا فشل تحديث من نظام ملفات الجذر، فإنه ليس من المهم أن يتم تكرار الطلب.

ونهج نسخة المزدوج يمكن أن تضمن تحديثا دون الخروج من الخدمة، إذا كنت بحاجة إلى هذا. ولكنه يتطلب الكثير من الموارد، وذلك لأن جميع المكونات يجب أن تتكرر. شخصيا، وأنا استخدم نهج تراجع، حيث بدأ من rootfs صغير في RAM إذا فشل التطبيق الرئيسي أو إذا كان التحديث الأخير لم يكن ناجحا. هذا النظام للتراجع، بدأ تلقائيا من قبل محمل الإقلاع إذا كان أي شيء يذهب على نحو خاطئ، وتحديث النظام من قلم USB (إذا كنت بحاجة لتحديث المحلي).

ولقد وجدت أبدا مشروع OSS حول هذه القضايا، وبدأت في الآونة الأخيرة واحدة جديدة، استنادا إلى تجربتي السابقة. لدي العديد من المنتجات تشغيله وبلدي العملاء سعداء معها.

وربما يمكنك أن تأخذ نظرة على ذلك. يمكنك العثور على مصادر ل "swupdate" (اسم المشروع) على github.com/sbabic/swupdate .

وستيفانو

Answer 5

أعتقد أن ما تحاول تحقيقه هنا هو ذرية عملية التحديث.تعد الذرية أمرًا بالغ الأهمية للأجهزة المدمجة، وأحد الأسباب التي تم تسليط الضوء عليها هو فقدان الطاقة؛ولكن قد يكون هناك مشكلات أخرى مثل مشكلات الأجهزة/الشبكة.التعريف الذي أستخدمه للذرية في سياق التحديثات هو:

• دائمًا ما يكون التحديث إما مكتملًا بالكامل، أو لا يكتمل على الإطلاق
• لا يرى أي مكون برمجي إلى جانب المحدث تحديثًا نصف مثبت على الإطلاق

بالنسبة إلى Embedded Linux، هناك العديد من مكونات البرامج التي قد ترغب في تحديثها وتصميمات مختلفة للاختيار من بينها؛هناك ورقة حول هذا هنا: https://mender.io/user/pages/04.resources/_white-papers/Software%20Updates.pdf