מעקב אחר ה-proxy דרך פריסת MAAS

הורדה מוצלחת של תמונת האתחול של MAAS מוכיחה את המסלול של הבקר. אם המכונה המותקנת לא מצליחה להשיג חבילות מאוחר יותר, בדקו את הצרכן בשלב הזה:

השתמשו בבקרות הנתמכות של גרסת MAAS שנמצאת בשירות. enable_http_proxy המתועד מכסה שימוש ב-proxy המובנה או הנקוב לצורך הקצאה וגישה לחבילות; http_proxy מזהה שירות חיצוני. במצב peer-proxy, מכונות שנפרסו יכולות להשתמש ב-proxy המובנה של MAAS, שמשתמש בשירות החיצוני הזה כהורה שלו. לשימוש מותר בהורה חיצוני ציבורי, בחרו מועמד HTTP מרשימת ה-proxy מסוג HTTP; במצב peer-proxy השאירו את נקודת הקצה המקומית של MAAS בצומת ללא שינוי.

לפיכך נקודת קצה מקומית של MAAS בצומת אינה בהכרח מיושנת. עקבו אחר ההורה שלה לפני החלפתה בכתובת החיצונית. פתרונות preseed ישנים מגרסאות שלא העבירו הגדרות proxy לצמתים אינם מתארים כל פריסה נוכחית.

בשלב שנכשל, השוו את הגדרות החבילות שנוצרו, את נגישות נקודת הקצה ואת זהות האימות לסביבת המתקין. אין צורך שיחלקו ספריית בית או משתנים. בצומת Ubuntu שמשתמש ב-APT, בדקו את אפשרויות ה-proxy של APT עצמו. הפרידו בין גישה למטא-נתונים מקומיים לבין מאגרים ציבוריים; שליחת כתובת URL פנימית של הקצאה להורה החיצוני עלולה להיכשל בעוד הורדות ציבוריות עובדות.

מעטפת בקר או דפדפן הם צרכן נוסף, ומנהל חבילות מוגדר אינו מגדיר כל סביבת הרצה מאוחרת. לאחר שינוי ניהולי, בדקו מה עומס העבודה הקיים שנפגע קיבל בפועל, במקום להניח שהוא טען מחדש את ההגדרה מיד.