ব্যবহারকারীর সেশন কি 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 বিকল্পটি হ্যান্ডেল পুনরুদ্ধার না করেই পরিবহন পুনরুদ্ধার করে: পুনঃসংযোগের আগে খোলা একটি ফাইল পরের লেখায় ব্যর্থ হতে পারে, এবং বাধাপ্রাপ্ত লেখা সংরক্ষিত থাকে না। এই পার্থক্যটি সবচেয়ে গুরুত্বপূর্ণ তাদের সম্পাদকদের জন্য যারা একটি ফাইল ঘণ্টার পর ঘণ্টা খোলা রাখে। পুনরুদ্ধার ধরে নেওয়ার বদলে পুনরায় খোলার ধাপ পরিকল্পনা করুন।

নির্ভর করার আগে নিষ্পত্তিযোগ্য ফাইল দিয়ে আচরণ পরীক্ষা করুন। টানেল ফিরে আসার পরে আবার দেখা যাওয়া একটি ডিরেক্টরি প্রমাণ করে না যে আগের হ্যান্ডেল বা অসংরক্ষিত কাজ টিকে গেছে।