OpenVPN הופעל אך לא הדפיס דבר: בדקו תחילה את log-append

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

לשקט יש שני הסברים שונים מאוד

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

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

מצאו את ההוראה, ואז מצאו את התהליך.

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

מצאו את היעד שבו משתמש התהליך הפועל

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

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

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

log לעומת log-append: ראיה ומחיקה

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

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

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

כאשר עטיפת שירות לוכדת את הפלט

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

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

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

העלו את רמת הפירוט רק לאחר שתוכלו לקרוא אותה

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

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

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