नया 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 सहायक के माध्यम से शुरू करना अलग होम निर्देशिका और इसलिए अलग कॉन्फ़िगरेशन समुच्चय प्रस्तुत कर सकता है। होम निर्देशिका पर पुनरावृत्त रूप से नहीं, बल्कि उस विशिष्ट फ़ाइल पर स्वामित्व ठीक करें जिसे एप्लिकेशन प्रलेखित करता है, फिर तय करें कि आगे प्रोफ़ाइल का स्वामी कौन-सी पहचान होनी चाहिए और भविष्य की शुरुआत उसके अनुरूप रखें।

आइकन आपको क्या बता सकता है और क्या नहीं

आइकन सिद्ध करता है कि लॉन्चर फ़ाइल हल होती है, और इससे अधिक कुछ नहीं। कनेक्शन की स्थिति क्लाइंट की है, इसलिए एकमात्र विश्वसनीय जाँच इंटरफ़ेस, रूट या क्लाइंट का अपना स्टेटस आउटपुट है। जो ट्रे एप्लेट शुरू नहीं हुआ वह काम करती टनल को टूटी दिखा सकता है, जबकि पुराना एप्लेट टूटी को ठीक दिखा सकता है। कनेक्शन और लॉन्चर को अलग-अलग जाँचें, फिर लिखें कि आपने वास्तव में किसे ठीक किया।

यदि दोनों टूटे थे, तो मरम्मत को एक ही बदलाव मानने की प्रवृत्ति का विरोध करें। प्रविष्टि ठीक करें, शुरुआत की पुष्टि करें, फिर टनल की पुष्टि करें और हर चरण का परिणाम लिखें। वही रिकॉर्ड अगली खोई सेटिंग्स रिपोर्ट को इसकी पुनरावृत्ति नहीं बल्कि निदान-योग्य बनाता है, और वही अगले व्यक्ति को बताता है कि समस्या का कौन-सा आधा हिस्सा असली था।