सफल MAAS बूट-इमेज डाउनलोड कंट्रोलर के मार्ग को सिद्ध करता है। यदि इंस्टॉल की गई मशीन बाद में पैकेज नहीं ला सकती, तो उस चरण में उपभोक्ता की जाँच करें:

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

सेवा में मौजूद MAAS संस्करण के समर्थित नियंत्रणों का उपयोग करें। प्रलेखित enable_http_proxy प्रोविज़निंग और पैकेज एक्सेस के लिए अंतर्निहित या निर्दिष्ट प्रॉक्सी के उपयोग को कवर करता है; http_proxy किसी बाहरी सेवा की पहचान करता है। पीयर-प्रॉक्सी मोड में, परिनियोजित मशीनें MAAS की अंतर्निहित प्रॉक्सी का उपयोग कर सकती हैं, जो उस बाहरी सेवा को अपने पैरेंट के रूप में उपयोग करती है। सार्वजनिक बाहरी पैरेंट के अनुमत उपयोग के लिए HTTP प्रॉक्सी सूची से HTTP उम्मीदवार चुनें; पीयर-प्रॉक्सी मोड में नोड के MAAS-स्थानीय एंडपॉइंट को अपरिवर्तित रखें।

इसलिए नोड पर MAAS-स्थानीय एंडपॉइंट ज़रूरी नहीं कि पुराना हो। बाहरी पते से बदलने से पहले उसके पैरेंट का पालन करें। जिन रिलीज़ों ने नोड्स को प्रॉक्सी सेटिंग्स नहीं भेजीं, उनके पुराने preseed समाधान हर वर्तमान परिनियोजन का वर्णन नहीं करते।

विफल होने वाले चरण में, उत्पन्न पैकेज सेटिंग्स, एंडपॉइंट की पहुँच और प्रमाणीकरण पहचान की तुलना इंस्टॉलर वातावरण से करें। उन्हें समान होम डायरेक्टरी या चर साझा करने की आवश्यकता नहीं है। APT का उपयोग करने वाले Ubuntu नोड पर APT के अपने प्रॉक्सी विकल्पों की जाँच करें। स्थानीय मेटाडेटा एक्सेस को सार्वजनिक रिपॉज़िटरी से अलग रखें; आंतरिक प्रोविज़निंग URL बाहरी पैरेंट को भेजना विफल हो सकता है जबकि सार्वजनिक डाउनलोड काम कर रहे हों।

कंट्रोलर शेल या ब्राउज़र एक और उपभोक्ता है, और कॉन्फ़िगर किया गया पैकेज प्रबंधक हर बाद के रनटाइम को कॉन्फ़िगर नहीं करता। प्रबंधन परिवर्तन के बाद, प्रभावित मौजूदा वर्कलोड को वास्तव में क्या मिला, यह जाँचें, बजाय यह मानने के कि उसने सेटिंग तुरंत पुनः लोड कर ली।

संबंधित लेख