למה קיצור דרך חדש ל-VPN לא מחזיר הגדרות שאבדו
משגר קובע כיצד תוכנית מתחילה, לא היכן היא שומרת את העדפותיה. השוו את ההקשר של קובץ ההרצה, המשתמש והתצורה לפני שאתם מאשימים את הסמל.
רשומות תפריט חסרות והעדפות נעלמות מתוקנות באותה תגובת רפלקס, והן בעיות לא קשורות. האחת היא אינטגרציה עם שולחן העבודה, השנייה היא מצב היישום, וסמל חדש לא משנה אף אחת מהן מעצמו. הפרדה בין השתיים דורשת ניסוי אחד ומסבירה את רוב הבלבול שאנשים מביאים לנושא הזה. המשגר מפעיל תוכנית; התוכנית מחליטה מה היא זוכרת.
שתי עבודות שרק נראות כאחת
אינטגרציה עם שולחן העבודה פירושה שהסביבה יכולה למצוא קובץ הרצה, להציג שם וסמל ולהעביר את הארגומנטים הנכונים. מצב היישום פירושו שהתוכנית כותבת פרופיל במקום עמיד וקוראת אותו שוב בהפעלה הבאה. אף אחד מהם לא מחייב את השני, ולכן קיצור דרך עובד יכול להפעיל לקוח ששכח הכול.
שנו העדפת תצוגה לא מזיקה אחת דרך הפקדים של היישום עצמו, ואז סגרו ופתחו אותו שוב באותו אופן. אם ההעדפה חוזרת, השמירה עובדת והתלונה הנותרת היא על מציאת החלון ולא על שמירת נתונים. אם היא נעלמת, קיצור הדרך הוא הסחה והשאלה האמיתית היא היכן התהליך הזה מחזיק את הקבצים שלו. בדקו העדפה אחת בכל פעם, כי לקוח שמבקש שוב סיסמה אולי מגן על סוד ולא מאבד תצורה.
השוו את קלטי ההפעלה לפני התקנה מחדש
התחילו ברשומת שולחן העבודה וקראו מה היא עושה בפועל, כי הפעלה מהתפריט אינה אוטומטית אותה סביבת תהליך כמו הפעלה מהמסוף. המפתחות החשובים הם Exec, Path ובאופן עקיף הסביבה שהפעלה מספקת. סקריפט עטיפה בתוך Exec יכול לקבוע משתנה, לשנות תיקייה או להפעיל עוזר מורשה שהתפריט לא מציג לעולם. התקנה מחדש מחליפה קבצים שהיישום כבר היה לו, וזה לעיתים רחוקות המשתנה שהשתנה.
grep -h '^Exec=' ~/.local/share/applications/*.desktop
desktop-file-validate ~/.local/share/applications/client.desktop
הסתכלו על הקובץ תחת ~/.local/share/applications לפני זה שב-/usr/share/applications, כי עותק משתמש מסתיר את עותק המערכת. הריצו desktop-file-validate כשהרשומה מתנהגת לא טוב, וחפשו עותק מיושן שעדיין מצביע על נתיב שהוסר. עותק משתמש לא תקף עדיין מועדף ברוב שולחנות העבודה, כך שקובץ שבור יכול להסיר את הרשומה מהתפריט בעוד קובץ החבילה נשאר תקף. אחר כך הריצו את אותה פקודה ביד והשוו מה שתי ההפעלות מפיקות.
היכן העדפה באמת חיה
יישומים שעוקבים אחר כללי ספריות הבסיס של XDG שמים תצורה תחת $XDG_CONFIG_HOME, מצב עמיד תחת $XDG_STATE_HOME ונתונים חד-פעמיים תחת $XDG_CACHE_HOME, וברירת המחדל היא ~/.config, ~/.local/state ו-~/.cache כשמשתנים אלה אינם מוגדרים. השלושה הם תפקידים ולא הבטחות, ולכן מוצר VPN מסוים עשוי לתעד משהו אחר לגמרי. קריאת התיעוד של הספק עצמו עדיפה על ניחוש נתיב משם תיקייה. כשהתיעוד דל, עקבו אחר התהליך ולא אחר מערכת הקבצים.
מעקב מסונן לפתיחות קבצים מראה כל נתיב תצורה שהלקוח מנסה, כולל זה שהוא כותב ביציאה. הריצו אותו כאותו משתמש עם אותה סביבה, ואז השוו את הנתיבים האלה לתיקיות שציפיתם להן.
strace -f -e trace=openat,stat -o /tmp/vpn.log vpn-client
לסודות ולפרופילים יש בעלים שונים
פרופיל שמור ופרטי התחברות שמורים הם אובייקטים נפרדים, ולעיתים קרובות עם אחסון נפרד. האחד עשוי לחיות בקובץ תצורה בעוד השני יושב במחזיק מפתחות שנפתח לכל הפעלה, כך שלקוח שמבקש שוב סיסמה אולי פשוט עושה את מה שתוכנן לעשות. מחיקת הפרופיל כדי לעצור את הבקשה היא הדרך שבה אנשים מאבדים תצורה עובדת.
הפעלות מורשות מסבכות את זה עוד יותר, כי הפעלה דרך sudo או עוזר PolicyKit יכולה להציג תיקיית בית אחרת ולכן מערך תצורה אחר. תקנו בעלות על הקובץ המסוים שהיישום מתעד ולא באופן רקורסיבי על כל תיקיית הבית, ואז החליטו איזו זהות צריכה להחזיק בפרופיל מעתה והשאירו הפעלות עתידיות עקביות איתה.
מה הסמל יכול לספר לכם ומה לא
סמל מוכיח שקובץ משגר נפתר, ולא יותר מזה. מצב החיבור שייך ללקוח, ולכן הבדיקה האמינה היחידה היא הממשק, הנתיב או פלט המצב של הלקוח עצמו. אפלט מגש שלא הופעל יכול לגרום למנהרה עובדת להיראות שבורה, בעוד אפלט מיושן יכול לגרום לאחת שבורה להיראות תקינה. בדקו את החיבור ואת המשגר בנפרד, ואז רשמו איזה מהשניים באמת תיקנתם.
אם שניהם היו שבורים, התנגדו להתייחסות לתיקון כשינוי אחד. תקנו את הרשומה, אשרו את ההפעלה, ואז אשרו את המנהרה, ורשמו את התוצאה של כל שלב. הרשומה הזו היא מה שהופך את הדיווח הבא על הגדרות שאבדו לניתן לאבחון במקום חזרה על זה, והיא גם מה שאומר לאדם הבא איזה חצי מהבעיה היה אמיתי.