چرا میانبر تازهٔ 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 می‌تواند پوشهٔ خانگی دیگری و در نتیجه مجموعهٔ پیکربندی دیگری نشان دهد. مالکیت را روی همان فایل مشخصی که برنامه مستند می‌کند درست کنید نه به‌صورت بازگشتی در کل پوشهٔ خانگی، سپس تصمیم بگیرید از این پس کدام هویت باید مالک پروفایل باشد و اجراهای آینده را با آن هم‌سو نگه دارید.

آیکون چه می‌تواند به شما بگوید و چه نمی‌تواند

یک آیکون اثبات می‌کند که فایل راه‌انداز حل می‌شود، و نه بیشتر. وضعیت اتصال از آن کلاینت است، پس تنها بررسی قابل اعتماد رابط، مسیر یا خروجی وضعیت خود کلاینت است. یک اپلت سینی که آغاز نشده می‌تواند تونلی سالم را خراب نشان دهد، در حالی که اپلتی کهنه می‌تواند تونلی خراب را سالم نشان دهد. اتصال و راه‌انداز را جداگانه بیازمایید، سپس بنویسید کدام‌یک را واقعاً درست کردید.

اگر هر دو خراب بودند، در برابر وسوسهٔ برخورد با تعمیر به‌عنوان یک تغییر مقاومت کنید. ورودی را درست کنید، آغاز را تأیید کنید، سپس تونل را تأیید کنید و نتیجهٔ هر گام را یادداشت کنید. همان ثبت است که گزارش بعدی درباره تنظیمات ازدست‌رفته را قابل عیب‌یابی می‌کند نه تکرار این یکی، و همچنین به نفر بعدی می‌گوید کدام نیمهٔ مشکل واقعی بود.