האם הפעלת המשתמש צריכה להחזיק את עיגון SSHFS דרך VPN?

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

שתי זהויות, שתי הרשאות נפרדות

לקוח ה-VPN זקוק להרשאות כדי לשנות מסלולים וממשקים. עיגון SSHFS זקוק לזהות SSH ששרת הקבצים מקבל ולעיגון FUSE בבעלות החשבון שיקרא את הקבצים. סקריפט אחד שרץ כ-root ממלא את הדרישה הראשונה ושובר בשקט את השנייה.

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

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

הקימו תחילה עיגון בבעלות המשתמש ביד

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

mkdir -p "$HOME/mnt/team"
sshfs [email protected]:/exports/team "$HOME/mnt/team"
mount | grep sshfs

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

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

תנו לטריגר לפעול באותו הקשר הפעלה

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

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

nmcli -g UUID connection show --active
systemctl --user list-units 'sshfs*'
pgrep -a sshfs

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

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

תכננו את הניתוק לפני שאתם כופים את הניקוי

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

fusermount3 -u "$HOME/mnt/team"
mountpoint "$HOME/mnt/team"

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

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

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