MAAS उपयोजनाद्वारे प्रॉक्सीचा मागोवा घ्या
MAAS मध्ये इमेज डाउनलोड, इन्स्टॉलर रहदारी, उपयोजित पॅकेज प्रवेश आणि नंतरच्या अनुप्रयोग विनंत्या वेगळ्या करा.
यशस्वी MAAS बूट-इमेज डाउनलोड कंट्रोलरचा मार्ग सिद्ध करते. इन्स्टॉल केलेले मशीन नंतर पॅकेज मिळवू शकत नसेल, तर त्या टप्प्यावरील ग्राहक तपासा:
| टप्पा | तपासायचा ग्राहक |
|---|---|
| इमेज/प्रोव्हिजनिंग डाउनलोड | जबाबदार कंट्रोलर सेवा |
| कमिशनिंग किंवा इन्स्टॉलेशन | तात्पुरते कार्य वातावरण |
| इन्स्टॉल केलेली OS पॅकेजेस | पॅकेज मॅनेजर आणि व्युत्पन्न कॉन्फिगरेशन |
| नंतरचे charm, स्क्रिप्ट किंवा अनुप्रयोग डाउनलोड | ती विनंती करणारा क्लायंट |
सेवेतील MAAS आवृत्तीचे समर्थित नियंत्रण वापरा. दस्तऐवजीकृत enable_http_proxy प्रोव्हिजनिंग आणि पॅकेज प्रवेशासाठी अंगभूत किंवा निर्दिष्ट प्रॉक्सीचा वापर समाविष्ट करते; http_proxy बाह्य सेवा ओळखते. पीअर-प्रॉक्सी मोडमध्ये, उपयोजित मशीन्स MAAS ची अंगभूत प्रॉक्सी वापरू शकतात, जी ती बाह्य सेवा त्यांचे पालक म्हणून वापरते. सार्वजनिक बाह्य पालकाच्या परवानगी असलेल्या वापरासाठी HTTP प्रॉक्सी यादीमधून HTTP उमेदवार निवडा; पीअर-प्रॉक्सी मोडमध्ये नोडचा MAAS-स्थानिक एंडपॉइंट अपरिवर्तित ठेवा.
म्हणून नोडवरील MAAS-स्थानिक एंडपॉइंट जुना असणे आवश्यक नाही. बाह्य पत्त्याने बदलण्यापूर्वी त्याच्या पालकाचा मागोवा घ्या. ज्या आवृत्त्यांनी नोड्सना प्रॉक्सी सेटिंग्ज दिल्या नाहीत, त्यांचे जुने preseed उपाय प्रत्येक सध्याचे उपयोजन वर्णन करत नाहीत.
अपयशी टप्प्यावर, व्युत्पन्न पॅकेज सेटिंग्ज, एंडपॉइंटची पोहोच आणि प्रमाणीकरण ओळख यांची इन्स्टॉलर वातावरणाशी तुलना करा. त्यांना समान होम डिरेक्टरी किंवा चल असण्याची गरज नाही. APT वापरणाऱ्या Ubuntu नोडवर APT च्या स्वतःच्या प्रॉक्सी पर्यायांची तपासणी करा. स्थानिक मेटाडेटा प्रवेश सार्वजनिक रेपॉझिटरींपासून वेगळा ठेवा; अंतर्गत प्रोव्हिजनिंग URL बाह्य पालकाकडे पाठवणे सार्वजनिक डाउनलोड कार्यरत असतानाही अपयशी ठरू शकते.
कंट्रोलर शेल किंवा ब्राउझर हा आणखी एक ग्राहक आहे, आणि कॉन्फिगर केलेला पॅकेज मॅनेजर प्रत्येक नंतरचे रनटाइम कॉन्फिगर करत नाही. व्यवस्थापन बदलानंतर, सेटिंग लगेच पुन्हा लोड झाली असे गृहीत धरण्याऐवजी प्रभावित विद्यमान वर्कलोडला प्रत्यक्षात काय मिळाले ते तपासा.