האם סקריפט ה-up של OpenVPN רץ מוקדם מדי, או שמעולם לא היה מוכן?

סקריפט ה-up רץ, יוצא עם אפס, והמשימה שבתוכו נכשלת להגיע לשירות פרטי שעובד באופן מושלם שתי שניות אחר כך מהמסוף. האינסטינקט הוא תזמון, והתיקון הרגיל הוא השהיה, שמסתירה את המרוץ בלי להבין אותו. הקריאה המועילה יותר היא ש-“up” הוא שם של ווי, לא הבטחה למוכנות. הוא נורה כאשר התקן המנהרה מוגדר, וזה מוקדם יותר ממסלולים, DNS ובוודאי מוקדם יותר מכל יישום מאחורי המנהרה.

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

היכן up נמצא בסדר האתחול

OpenVPN מגדיר את התקן המנהרה ואז מריץ את ווי ה-up. התקנת מסלולים היא שלב מאוחר יותר, ויש לה ווי משלה, ולכן משימה שתלויה במסלול ושמוקמה ב-up עלולה לראות התקן בלי נתיב שימושי. שימו את עבודת המסלולים ב-route-up ובעיית התזמון בדרך כלל נעלמת.

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

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

מה הווי באמת יורש

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

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

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

למה הוספת השהיה אינה בדיקת מוכנות

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

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

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

ניקוי והתחברות מחדש ראויים לאותה תשומת לב

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

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

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

תנו שם לאירוע שכל משימה תלויה בו, ואז חברו אותה לאירוע הזה. כל השאר הוא השהיה שמעמידה פנים שהיא בדיקה.