एम्बेडेड लिनक्स को सुरक्षित रूप से अपडेट करने के लिए अनुशंसित तकनीक

Question

एंबेडेड लिनक्स आधारित उपकरणों को अक्सर अनुप्रयोगों और सिस्टम फ़ाइलों को अद्यतन करने के लिए एक तंत्र की आवश्यकता होती है। उदाहरण के लिए, यूएसबी पोर्ट के साथ एक (गैर-नेटवर्क) लैब उपकरण यूएसबी स्टिक से सॉफ़्टवेयर अपडेट प्राप्त कर सकता है।

डिवाइस की आंतरिक फ्लैश मेमोरी पर फ़ाइलों की प्रतिलिपि बनाने के लिए स्क्रिप्ट चलाने के लिए यह एक साधारण बात होगी। हालांकि, यह खतरा है कि डिवाइस अद्यतन के बीच में बिजली खो देगा, और एक ईंट खत्म होगा।

एप्लिकेशन फ़ाइलों की स्थिति थोड़ा आसान है क्योंकि एप्लिकेशन निर्देशिका को डुप्लिकेट करने के लिए एक कमरा है, एक प्रति अपडेट करें, और विफलता विंडो को कम करने वाली पुरानी और नई निर्देशिकाओं को तेज़ी से स्वैप करें।

चीजें कर्नेल और सिस्टम फ़ाइलों के लिए डिकियर हैं क्योंकि वे पूरे फाइल सिस्टम में फैले हुए हैं।

हमने महत्वपूर्ण फाइलों की पहचान करने के लिए फ़ाइल सिस्टम में हार्ड और सॉफ्ट लिंक का उपयोग किया है। हम फ़ाइल अखंडता को सत्यापित करने के लिए फ़ाइलों और अभिलेखागार पर हैंश का उपयोग करते हैं। अद्यतन फ़ाइल सिस्टम से शुरू होने पर हम फॉलबैक प्रदान करने के लिए कर्नेल में एक आपातकालीन रैमफ का उपयोग करने पर विचार कर चुके हैं।

इस आवश्यकता के आपके दृष्टिकोण क्या हैं?

Answer 1

मैं एप्लिकेशन फ़ाइलों के साथ एक ही दृष्टिकोण के साथ जाऊंगा: महत्वपूर्ण फाइलों के लिए बनाएं और अपना विभाजन पूरा करें, उन्हें लिंक करें, और विभाजन को डुप्लिकेट करें। आपके सभी init में आपको पहले यह जांचना चाहिए कि क्या लिंक सभी एक ही विभाजन में दिखाए जाते हैं, यदि नहीं, तो उन्हें रीसेट करें (किसी निश्चित फ़ाइल की नवीनतम तारीख वाली फ़ाइलों के साथ विभाजन में)। यदि आप अपडेट करना चाहते हैं तो बस सबकुछ नए विभाजन पर कॉपी करें, और यदि सब कुछ ठीक है (crcs ok) फ़ाइलों पर लूप करें और प्रत्येक फ़ाइल के लिए एक फाइल सिस्टम से दूसरे लिंक के लिए सेट करें।

इस तरह आपकी महत्वपूर्ण फाइल हमेशा सनी स्थिति में रहनी चाहिए।

परिदृश्य: जबकि नो प्रॉब्लम नया विभाजन

पर फाइलों को कॉपी क्योंकि लिंक पुराने काम कर रहे लोगों को अभी भी दिखा

1. अद्यतन विफल रहता है।

2. अद्यतन विफल रहता है, जबकि

   कोई समस्या नहीं है क्योंकि सभी नई फ़ाइलों वैध और पहले से ही की नकल की (और कुछ रीलिंक कदम नहीं होगा शुरू किया है) कर रहे हैं, सेटअप की जांच सही इस

Answer 2

यदि आपको विश्वसनीयता सुनिश्चित करना है, तो आपके पास दो फ़्लैश विभाजन (या यहां तक ​​कि चिप्स) भी हो सकते हैं, एक मौजूदा कार्य विन्यास के साथ और एक नई कॉन्फ़िगरेशन के साथ। फिर हार्डवेयर वॉचडॉग का उपयोग करें जो इकाई को रीसेट करेगा और सक्रिय बूट फ्लैश विभाजन को "अंतिम ज्ञात अच्छी" कॉन्फ़िगरेशन में स्विच करेगा।

Answer 3

कम से कम दो विभाजन है जोड़ने ।मैं बूट करने के लिए वैकल्पिक 4

• बूट

• वैकल्पिक बूट

• कार्यक्रम डेटा बैकअप

• कार्यक्रम अस्थिर डेटा

उपयोग भोजन के वापस आने बूटिंग सुझाव देंगे अगर बूट विफल रहता है।

तो यदि अद्यतन विफल रहता है, तो वैकल्पिक कार्य करता है।

बूट लोडर को अद्यतन न करें।

यदि डेटा विभाजन टोस्ट किया गया है, तो बैकअप डेटा विभाजन पर सुधार और प्रतिलिपि बनाएँ।

अब जब तक फ्लैश डिस्क मर जाती है तब तक आप असफल नहीं हो सकते हैं। यदि आप सीओटीएस हार्डवेयर का उपयोग कर रहे हैं, और मुख्य डिस्क कहती है, कॉम्पैक्ट फ्लैश, आप एक छोटी यूएसबी कुंजी कहने पर शारीरिक रूप से पृथक बैकअप ले सकते हैं।

Answer 4

IMHO कोई भी अद्यतन जो परमाणु नहीं है सिस्टम को तोड़ सकता है या स्थिरता के लिए जांच को काफी कठिन बना सकता है। मैं सहमत हूं कि बूट लोडर को अद्यतन करना टालना चाहिए क्योंकि यह सुरक्षित नहीं है। आम तौर पर, निर्माता फर्मवेयर x.x.x से संस्करण y.y.y में एक अपडेट चाहते हैं, अगर कर्नेल और/या एक फ़ाइल को अपडेट किया गया हो तो परेशान किए बिना। एकल फाइलों को अपडेट करना सेवा के लिए एक दुःस्वप्न बन सकता है, क्योंकि यह समझना बहुत मुश्किल है कि ग्राहक के हार्डवेयर पर क्या चल रहा है। हो सकता है कि आप एकल-प्रतिलिपि दृष्टिकोण के साथ एक दोहरी प्रति दृष्टिकोण (एप्लिकेशन अनावश्यक है) मिश्रण कर रहे हों। मुझे लगता है कि इससे बहुत मदद नहीं मिलती है, क्योंकि सिस्टम की अखंडता श्रृंखला में कमजोर घटक द्वारा की जाती है। यदि रूट फाइल सिस्टम का अद्यतन विफल रहता है, तो यह महत्वपूर्ण नहीं है कि एप्लिकेशन डुप्लिकेट हो।

यदि आपको इसकी आवश्यकता हो तो एक दोहरी प्रतिलिपि सेवा बिना किसी सेवा के अपडेट की गारंटी दे सकती है। लेकिन इसके लिए बहुत सारे संसाधनों की आवश्यकता है, क्योंकि सभी घटकों को डुप्लिकेट किया जाना चाहिए। निजी तौर पर, मैं फ़ॉलबैक दृष्टिकोण का उपयोग करता हूं, जहां मुख्य एप्लिकेशन विफल होने पर अंतिम अपडेट सफल नहीं होता है या रैम में एक छोटा रूटफ प्रारंभ होता है। यह फ़ॉलबैक सिस्टम, बूटलोडर द्वारा स्वचालित रूप से प्रारंभ होता है यदि कुछ भी गलत हो जाता है, तो यूएसबी कलम से सिस्टम अपडेट करें (यदि स्थानीय अपडेट आवश्यक है)।

मुझे इन मुद्दों के बारे में कभी भी ओएसएस परियोजना नहीं मिली है और मैंने हाल ही में अपने पिछले अनुभव के आधार पर एक नया शुरू किया है। मेरे पास कई उत्पाद चल रहे हैं और मेरा ग्राहक इससे खुश हैं।

शायद आप इसे देख सकते हैं। आप github.com/sbabic/swupdate पर "स्वैपडेट" (प्रोजेक्ट का नाम) के स्रोत ढूंढ सकते हैं।

Stefano

Answer 5

मुझे लगता है कि आप अद्यतन प्रक्रिया के atomicity यहाँ हासिल करने की कोशिश कर रहे हैं। एम्बेडेड उपकरणों के लिए परमाणुता महत्वपूर्ण है, हाइलाइट किए गए कारणों में से एक बिजली की कमी है; लेकिन हार्डवेयर/नेटवर्क के मुद्दों जैसे अन्य हो सकते हैं।एक परिभाषा मैं अद्यतन के संदर्भ में atomicity के लिए उपयोग करते हैं:

• एक अद्यतन हमेशा या तो पूरी तरह से पूरा हो गया है या बिल्कुल नहीं
• अपडेटर के अलावा कोई सॉफ्टवेयर घटक कभी देखता है एक आधा अद्यतन स्थापित

एंबेडेड लिनक्स के लिए कई सॉफ़्टवेयर घटक हैं जिन्हें आप अपडेट करना और विभिन्न डिज़ाइन चुनने के लिए चुन सकते हैं; यहां पर एक पेपर है: https://mender.io/user/pages/04.resources/_white-papers/Software%20Updates.pdf