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

آئیکن آپ کو کیا بتا سکتا ہے اور کیا نہیں

آئیکن ثابت کرتا ہے کہ لانچر فائل حل ہوتی ہے، اور اس سے زیادہ کچھ نہیں۔ کنکشن کی حالت کلائنٹ کی ہے، اس لیے واحد قابلِ اعتماد جانچ انٹرفیس، راستہ یا کلائنٹ کا اپنا اسٹیٹس آؤٹ پٹ ہے۔ شروع نہ ہو سکنے والا ٹرے ایپلیٹ کام کرنے والی سرنگ کو ٹوٹی ہوئی دکھا سکتا ہے، جبکہ پرانا ایپلیٹ ٹوٹی ہوئی کو ٹھیک دکھا سکتا ہے۔ کنکشن اور لانچر کو الگ الگ جانچیں، پھر لکھیں کہ آپ نے واقعی کون سی درست کی۔

اگر دونوں ٹوٹے ہوئے تھے تو مرمت کو ایک ہی تبدیلی سمجھنے کے رجحان کی مزاحمت کریں۔ اندراج درست کریں، شروعات کی تصدیق کریں، پھر سرنگ کی تصدیق کریں اور ہر مرحلے کا نتیجہ لکھیں۔ وہی ریکارڈ اگلی گمشدہ ترتیبات کی رپورٹ کو اس کی تکرار نہیں بلکہ قابلِ تشخیص بناتا ہے، اور وہی اگلے شخص کو بتاتا ہے کہ مسئلے کا کون سا نصف حقیقی تھا۔