नयाँ 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 सहायकमार्फत सुरु गर्नाले फरक होम डाइरेक्टरी र त्यसैले फरक कन्फिगरेसन समूह प्रस्तुत गर्न सक्छ। सम्पूर्ण होम डाइरेक्टरीमा पुनरावृत्त रूपमा होइन, एप्लिकेसनले दस्तावेजीकरण गर्ने विशिष्ट फाइलमा स्वामित्व सुधार्नुहोस्, त्यसपछि अबदेखि प्रोफाइल कुन पहिचानको हुनुपर्छ भनेर निर्णय गर्नुहोस् र भविष्यका सुरुवातहरू त्यसैसँग मिलाएर राख्नुहोस्।

आइकनले तपाईंलाई के भन्न सक्छ र के सक्दैन

आइकनले लन्चर फाइल समाधान हुन्छ भनी प्रमाणित गर्छ, त्यसभन्दा बढी केही होइन। जडानको अवस्था क्लाइन्टको हो, त्यसैले एकमात्र भरपर्दो जाँच इन्टरफेस, रुट वा क्लाइन्टको आफ्नै स्थिति आउटपुट हो। सुरु नभएको ट्रे एप्लेटले काम गर्ने टनेल बिग्रिएको देखाउन सक्छ, जबकि पुरानो एप्लेटले बिग्रिएको ठीक देखाउन सक्छ। जडान र लन्चर छुट्टाछुट्टै परीक्षण गर्नुहोस्, त्यसपछि तपाईंले वास्तवमा कुन ठीक गर्नुभयो लेख्नुहोस्।

यदि दुवै बिग्रिएका थिए भने मर्मतलाई एउटै परिवर्तन मान्ने प्रवृत्तिको प्रतिकार गर्नुहोस्। प्रविष्टि ठीक गर्नुहोस्, सुरुवात पुष्टि गर्नुहोस्, त्यसपछि टनेल पुष्टि गर्नुहोस् र हरेक चरणको नतिजा लेख्नुहोस्। त्यही अभिलेखले अर्को हराएका सेटिङको प्रतिवेदनलाई यसको पुनरावृत्ति होइन, निदानयोग्य बनाउँछ, र त्यसैले अर्को व्यक्तिलाई समस्याको कुन आधा साँचो थियो भन्छ।