למה מופיעה אזהרת ניקוי המסלול של vpnc במכולה

יומני מכולה טריים מסתיימים לעתים קרובות בתלונה Read-only file system על /proc/sys/net/ipv4/route/flush, והשורה הזו מקבלת את האשמה על מנהרה שעשויה להיות בריאה לחלוטין. הכתיבה שמאחוריה מכוונת לרשומת גרעין שכבר אינה עושה דבר מועיל מאז שמטמון מסלולי IPv4 נעלם. בתוך מכולה /proc/sys מעוגן לקריאה בלבד, ולכן ההפניה נדחית לפני שמגיע ערך כלשהו והמעטפת מדפיסה את הדחייה הזו. מנהרה שעובדת יכולה להדפיס את האזהרה הזו כל עוד השורה הישנה נשארת בסקריפט, ואילו --privileged אף פעם לא הופך את הכתיבה למשמעותית.

מה הסקריפט ניסה לנקות

סקריפטים ישנים יותר של חיבור הסתיימו בניקוי מטמון: כתיבת ערך לקובץ בקרה של הגרעין ובקשה ממערך IPv4 לזרוק את מטמון הניתוב שלו, כדי שמסלול מנהרה חדש ייבחר בלי להמתין לפקיעת רשומות ישנות. הקובץ הופנה תחת /proc/sys/net/ipv4/, מה שהפך את הפעולה להפניה של מעטפת ולא לפקודת ניתוב. גרעין 3.6 הסיר את המטמון הזה, ואיתו את הסיבה לקיומו של הניקוי. שום דבר במסלול הנתונים הנוכחי אינו תלוי בכתיבה הזו.

הרשומה עצמה שרדה כקובץ מדור קודם לכתיבה בלבד, ולכן סקריפט שעדיין כותב לתוכו מגיע לנתיב אמיתי ולבדיקת הרשאות אמיתית. במארח הכתיבה מחזירה הצלחה ולא משנה דבר. במכולה אותה הפניה פוגעת ב-/proc/sys לקריאה בלבד ונכשלת עם EROFS, שהמעטפת מדפיסה כהודעת מערכת הקבצים לקריאה בלבד. בגרעינים שבהם הנתיב באמת חסר הניסוח הופך ל-No such file or directory, והמסקנה אינה משתנה.

שתי השגיאות אומרות דברים שונים, וכדאי לשמור על ההבדל ברור. Read-only file system פירושו שהגרעין הגיע לרשומה וסירב לכתיבה; No such file or directory פירושו שהרשומה נעלמה. אף אחת מההודעות אינה מדווחת על התקן המנהרה, המסלולים או פתרון השמות, ולכן אף אחת מהן אינה יכולה להצדיק הרשאה נוספת.

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

בדקו את העיגון ואת המסלול לפני שמוסיפים הרשאה

שלוש קריאות מפרידות בין אזהרה קוסמטית לבין כשל אמיתי: אם הסקריפט המותקן עדיין נושא את השורה, איך מעוגן /proc/sys, והיכן התעבורה של היישום באמת עוברת. הריצו אותן באותו מרחב שמות של המכולה או במארח שבו הופיעה האזהרה, כי בדיקה במכונה לא קשורה עונה על שאלה אחרת.

grep -n 'ipv4/route/flush' /usr/share/vpnc-scripts/vpnc-script
findmnt -no OPTIONS /proc/sys
ip -4 route get 10.20.5.10

התשובה של grep חלשה מכפי שהיא נראית, כי מציאה מוכיחה שהשורה קיימת, לא שהיא רצה ללא הגנה; סקריפט מתוחזק יכול לשאת את הכתיבה בתוך הגנה שמדלגת עליה. findmnt -no OPTIONS /proc/sys מכריע את העיגון ישירות, ו-ro בפלט הזה פירושו שכל כתיבה מתחת לנקודה הזו נדחית, יהיה אשר יהיה הסקריפט. לאחר מכן חיפוש המסלול מראה אם היעד שהיישום צריך נפתר דרך ממשק המנהרה או דרך שער ברירת המחדל של המכולה. חיפוש שבוחר בשער ברירת המחדל פירושו שהמנהרה עלתה ושום דבר לא מנתב לתוכה, וזו בעיית ניתוב ולא בעיית הרשאה.

מאיפה התיקון באמת מגיע

התיקון המתוחזק חי בסקריפט ולא בדגלי המכולה. ה-vpnc-script במעלה הזרם שינה את האופן שבו הוא מטפל בפעולה הזו, ולכן השוו את העותק שבתוך התמונה למעלה הזרם הנוכחי ועדכנו דרך החבילה או בניית התמונה שמספקת אותו. קובץ שנערך ביד בתוך מכולה פועלת אינו ניתן לבדיקה ולא ישרוד את הבנייה הבאה.

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