کیا صارف کا سیشن 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 ایونٹ انٹیگریشن کو صارف سیشن کی کارروائی چلانے کی درخواست کرنے دیں، بجائے یہ فرض کرنے کے کہ مراعات یافتہ 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 اختیار ہینڈل بحال کیے بغیر نقل و حمل بحال کرتا ہے: دوبارہ جڑنے سے پہلے کھولی گئی فائل اگلی تحریر میں ناکام ہو سکتی ہے، اور رکاوٹ والی تحریر محفوظ نہیں رہتی۔ یہ فرق ان ایڈیٹرز کے لیے سب سے اہم ہے جو ایک فائل گھنٹوں کھلی رکھتے ہیں۔ بحالی فرض کرنے کے بجائے دوبارہ کھولنے کا مرحلہ منصوبہ بند کریں۔

اس پر انحصار سے پہلے ضائع ہونے والی فائلوں کے ساتھ برتاؤ جانچیں۔ ٹنل واپس آنے کے بعد دوبارہ نمودار ہونے والی ڈائریکٹری یہ ثابت نہیں کرتی کہ پہلے کے ہینڈل یا غیر محفوظ کام بچ گئے۔