क्या उपयोगकर्ता सत्र के पास VPN पर SSHFS माउंट का स्वामित्व होना चाहिए?

VPN आने के बाद साझा फ़ोल्डर माउंट करने में दो पहचानें शामिल हैं जिन्हें आसानी से मिलाया जा सकता है: वह घटक जिसे नेटवर्क कॉन्फ़िगर करने की अनुमति है, और वह खाता जिसे फ़ाइल सर्वर में लॉग इन करने की अनुमति है। वे शायद ही कभी एक जैसे होते हैं। रूट के स्वामित्व वाला VPN हुक डेस्कटॉप उपयोगकर्ता का SSHFS माउंट शुरू करने के लिए खराब जगह है, क्योंकि उसके पास न उपयोगकर्ता का एजेंट है और न ही इच्छित माउंट स्वामित्व। पहले स्वामित्व सही करने से ट्रिगर सरल हो जाता है।

दो पहचानें, दो अलग अनुमतियाँ

VPN क्लाइंट को मार्ग और इंटरफ़ेस बदलने के लिए विशेषाधिकार चाहिए। SSHFS माउंट को फ़ाइल सर्वर द्वारा स्वीकार की जाने वाली SSH पहचान और उस खाते के स्वामित्व वाला FUSE माउंट चाहिए जो फ़ाइलें पढ़ेगा। रूट के रूप में चलने वाली एक स्क्रिप्ट पहली आवश्यकता पूरी करती है और दूसरी को चुपचाप तोड़ देती है।

रूट के रूप में माउंट करना फ़ाइलों को डेस्कटॉप सत्र से बाहर और संभवतः उपयोगकर्ता की कुंजी रखने वाले एजेंट तक पहुँच के बिना छोड़ देता है। माउंट मौजूद है, उपयोगकर्ता उसके माध्यम से लिख नहीं सकता, और विफलता सर्वर-साइड अनुमति समस्या जैसी दिखती है। वह गलत निदान एक दोपहर और स्टोरेज टीम को एक टिकट का खर्च है।

कोई भी ऑटोमेशन लिखने से पहले तय करें कि कौन सा खाता माउंट का स्वामी है, क्योंकि यह चयन तय करता है कि ट्रिगर कहाँ रहता है और किन क्रेडेंशियल तक पहुँच सकता है।

पहले हाथ से उपयोगकर्ता-स्वामित्व वाला माउंट स्थापित करें

एक साइन-इन किए गए उपयोगकर्ता से शुरू करें जिसके पास खाली माउंटपॉइंट, अधिकृत SSH खाता और टनल के माध्यम से सर्वर तक काम करने वाला पथ हो। मैनुअल माउंट वह आधार स्थापित करता है जिसे किसी भी ऑटोमेशन को दोहराना होता है।

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

नाम उदाहरण हैं, इसलिए उस होस्ट और एक्सपोर्ट पथ को बदलें जो आपका सर्वर वास्तव में देता है। उस पहले कनेक्शन पर अनुमोदित प्रक्रिया के माध्यम से होस्ट कुंजी सत्यापित करें। ध्यान दें कि VPN खाते का पासवर्ड स्वचालित रूप से स्टोरेज खाते का क्रेडेंशियल नहीं है, और यह विफल प्रयासों का सामान्य कारण है।

इसे सामान्य उपयोगकर्ता के रूप में उस उपयोगकर्ता के स्वामित्व वाले माउंटपॉइंट के साथ चलाएं। डिफ़ॉल्ट रूप से केवल माउंट करने वाला खाता फ़ाइलों तक पहुँचता है, और allow_other उस सीमा को हर स्थानीय उपयोगकर्ता तक बढ़ाता है। यह पहुँच का जानबूझकर विस्तार है, ऑटोमेशन के लिए कोई वैकल्पिक उपाय नहीं।

ट्रिगर को उसी सत्र संदर्भ में कार्य करने दें

समर्थित VPN इवेंट इंटीग्रेशन को उपयोगकर्ता-सत्र क्रिया चलाने के लिए कहें, बजाय यह मानने के कि एक विशेषाधिकार प्राप्त कॉलबैक डेस्कटॉप क्रेडेंशियल उधार ले सकता है। ट्रिगर को इच्छित कनेक्शन पहचानकर्ता तक सीमित करें, न कि किसी ऐसे इंटरफ़ेस तक जिसे संयोग से 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 विकल्प हैंडल बहाल किए बिना परिवहन बहाल करता है: पुनः कनेक्ट से पहले खोली गई फ़ाइल अगली लेख में विफल हो सकती है, और बाधित लेख सुरक्षित नहीं रहता। यह अंतर उन संपादकों के लिए सबसे महत्वपूर्ण है जो एक फ़ाइल को घंटों खुला रखते हैं। पुनर्प्राप्ति मानने के बजाय पुनः खोलने का चरण योजना में रखें।

इस पर निर्भर होने से पहले डिस्पोजेबल फ़ाइलों के साथ व्यवहार का परीक्षण करें। टनल लौटने के बाद फिर से दिखने वाली डायरेक्टरी यह साबित नहीं करती कि पहले के हैंडल या बिना सहेजा गया काम बच गया।