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