Raspberry Pi VPN उपकरण को उसकी कुंजी कॉपी किए बिना फिर से बनाएं

किसी इमेज से एक बार बूट करना Pi को पुनर्निर्माण योग्य उपकरण नहीं बनाता। आपको इनपुट का एक छोटा समूह चाहिए जिसे आप दोबारा लागू कर सकें: एक अनुरक्षित आधार, एक घोषित कॉन्फ़िगरेशन, ऐप्लिकेशन का स्थायी डेटा और ऐसी डिवाइस पहचान जो केवल उसी बोर्ड की हो। अंतिम चीज़ छूट गई तो हर प्रतिस्थापन एक क्रेडेंशियल का क्लोन बन जाएगा।

नीचे दिए चरण किसी उपकरण की सिफ़ारिश नहीं, काम का क्रम हैं। जो भी कॉन्फ़िगरेशन सिस्टम इन्हें व्यक्त कर सके, वह पर्याप्त है।

पहले चार प्रकार के इनपुट सूचीबद्ध करें

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

कुछ भी फिर से बनाने से पहले चार सूचियां लिखें। खाली पंक्ति वाली सूची वह निर्णय है जो आपने अभी नहीं लिया।

रहस्यों को रिपॉज़िटरी से बाहर रखें और बताएं कि वे कहां रहते हैं

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

परीक्षण सरल है: यदि कल रिपॉज़िटरी लीक हो जाए, तो हमलावर को क्या मिलेगा? टेम्पलेट और टोपोलॉजी नोट बच जाते हैं। काम करती पहचान नहीं।

ऑटोमेशन को वह स्वामित्व दें जिसे वह दोबारा चला सके

Ansible का मॉडल प्रबंधित नोड्स की इन्वेंटरी को नाटकों, कार्यों, भूमिकाओं और हैंडलर से अलग रखता है, जो कार्य के बदलाव की सूचना देने पर सक्रिय होते हैं। उस संरचना का उपयोग करके हर सेवा को एक ही कॉन्फ़िगरेशन स्वामी दें, शेल इतिहास दोबारा चलाने के बजाय। ऐसे संचालनों को प्राथमिकता दें जो दो बार चलाने के लिए सुरक्षित हों, और सचेत रूप से तय करें कि बदली हुई फ़ाइल चल रही प्रक्रिया तक कैसे पहुंचे। सेवा शुरू होने को सुनिश्चित करने वाला कार्य उसे आपके द्वारा अभी-अभी फिर से लिखा गया कॉन्फ़िगरेशन दोबारा लोड करने को बाध्य नहीं करता।

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

डेटा और पहचान को जानबूझकर पुनर्स्थापित करें

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

पहचान के लिए तय करें कि आप वही डिवाइस पुनर्प्राप्त कर रहे हैं या प्रतिस्थापन दर्ज कर रहे हैं, क्योंकि ये अलग सफाई वाले अलग संचालन हैं।

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

बूट योग्य इमेज चार में से एक इनपुट है, और इसे दोबारा बनाना सबसे आसान है।