ऐसी VPN ऑटोस्टार्ट प्रविष्टि ठीक करना जो केवल एक डेस्कटॉप पर चलती है

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

तीन अलग तथ्य: शुरुआत, आइकन, टनल

डेस्कटॉप प्रविष्टि किसी प्रोग्राम को शुरू करती है। वह ट्रे कार्यान्वयन स्थापित नहीं कर सकती, और उस पैनल में संकेतक नहीं दिखा सकती जो एप्लिकेशन द्वारा उपयोग किए जाने वाले प्रोटोकॉल का समर्थन नहीं करता। यदि प्रक्रिया पहले से चल रही है, तो शुरुआत का प्रश्न उत्तरित है और आप उसके बजाय एक इंटीग्रेशन समस्या देख रहे हैं।

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

कुछ भी बदलने से पहले उन्हें अलग करें। जाँचें कि प्रक्रिया मौजूद है या नहीं, फिर कि पैनल संकेतक का समर्थन करता है या नहीं, और अंत में कि इंटरफ़ेस कनेक्शन की सूचना देता है या नहीं। हर उत्तर किसी अलग परत और अलग ज़िम्मेदार व्यक्ति की ओर संकेत करता है।

वह प्रविष्टि खोजें जिसे सत्र वास्तव में पढ़ता है

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

ls -l ~/.config/autostart/ /etc/xdg/autostart/
echo "$XDG_CURRENT_DESKTOP"
grep -H -E '^(OnlyShowIn|NotShowIn|TryExec|Hidden|Exec)=' ~/.config/autostart/*.desktop /etc/xdg/autostart/*.desktop

पर्यावरण चर उस सत्र का नाम छापता है जिससे फ़िल्टरिंग कुंजियों की तुलना होती है, और वह आमतौर पर कोलन से अलग की गई सूची होती है। इसकी प्रविष्टि के मानों से शब्दशः तुलना करें, क्योंकि वे नाम केस-संवेदी कॉन्फ़िगरेशन विवरण हैं, सत्र का वर्णन नहीं। मान GNOME इससे मेल नहीं खाता: gnome, और उससे उत्पन्न मौन के साथ कोई त्रुटि संदेश नहीं जुड़ा होता। मान लेने के बजाय उसे छापें।

यदि वही फ़ाइल नाम दोनों निर्देशिकाओं में मौजूद है, तो उपयोगकर्ता की प्रतिलिपि मायने रखती है। सिस्टम फ़ाइल संपादित करना और यह सोचना कि कुछ बदला क्यों नहीं, बहुत आम तौर पर बर्बाद हुआ घंटा है।

फ़िल्टरिंग कुंजियाँ क्रम से पढ़ें

नीचे दी गई उदाहरण प्रविष्टि उन कुंजियों को दिखाती है जो तय करती हैं कि सत्र प्रोग्राम शुरू करेगा या नहीं। यह एक टुकड़ा है, पूरा लॉन्चर नहीं, और मान एक काल्पनिक पथ के हैं।

[Desktop Entry]
Type=Application
Name=Example VPN
Exec=/opt/example-vpn/client --minimized
TryExec=/opt/example-vpn/client
OnlyShowIn=GNOME;

OnlyShowIn प्रविष्टि को सूचीबद्ध वातावरणों तक सीमित करता है और NotShowIn सूचीबद्ध को बाहर रखता है। जब दोनों एक ही प्रविष्टि में दिखें तो विनिर्देश कोई उपयोगी व्यवहार परिभाषित नहीं करता, इसलिए दोनों वाली फ़ाइल को चतुर संयोजन नहीं, दोष मानें। दूसरी जोड़कर प्राथमिकता नियम की आशा करने के बजाय जिस कुंजी की ज़रूरत नहीं उसे हटा दें।

TryExec सत्र द्वारा शुरू किए जाने से पहले पूछता है कि निष्पादन योग्य फ़ाइल मौजूद है या नहीं। इसलिए पुरानी स्थापना से बचा पथ ऑटोस्टार्ट को दबा देता है, भले ही नया पैकेज मेन्यू से शुरू करने पर काम करे, और वह विफलता ठीक डेस्कटॉप फ़िल्टर जैसी दिखती है।

उपयोगकर्ता स्तर पर ओवरराइड करें, सिस्टम स्तर पर नहीं

जब फ़िल्टर इस मशीन के लिए वास्तव में ग़लत हो, तो सिस्टम प्रविष्टि को उपयोगकर्ता निर्देशिका में कॉपी करें और प्रतिलिपि बदलें। XDG ऑटोस्टार्ट नियमों के अनुसार, एक ही नाम वाली उपयोगकर्ता प्रविष्टि को प्राथमिकता मिलती है, और Hidden=true सिस्टम फ़ाइल हटाए बिना प्रविष्टि को निष्क्रिय करता है।

mkdir -p ~/.config/autostart
cp /etc/xdg/autostart/example-vpn.desktop ~/.config/autostart/
sed -i '/^OnlyShowIn=/d' ~/.config/autostart/example-vpn.desktop
desktop-file-validate ~/.config/autostart/example-vpn.desktop

लॉग आउट करने से पहले परिणाम मान्य करें, क्योंकि ख़राब प्रविष्टि को चुपचाप अनदेखा किया जाता है और अगला परीक्षण आपको कुछ नहीं बताता। पैकेज फिर से स्थापित करने से आपका ओवरराइड नहीं हटेगा, यही उद्देश्य है और यही इसे दर्ज करने का कारण भी। टिकट में फ़ाइल का पथ लिखें ताकि अगला व्यक्ति ओवरराइड फिर से निकालने के बजाय खोज ले।

साझा सिस्टम लॉन्चर संपादित करने के बजाय इसे प्राथमिकता दें, क्योंकि वह मशीन के हर उपयोगकर्ता का व्यवहार बदलता है और उसी तरह समीक्षा योग्य नहीं है। उपयोगकर्ता स्तर का ओवरराइड एक जगह दिखता है, एक फ़ाइल हटाकर उलटा जा सकता है, और टिकट में समझाना आसान है। सिस्टम फ़ाइल वैसी ही रहती है जैसे विक्रेता ने भेजी, इसलिए पैकेज अपडेट आपके तर्क को चुपचाप नहीं मिटाता।

टनल को छुए बिना शुरुआत की पुष्टि करें

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

pgrep -af example-vpn
systemctl --user status example-vpn.service
journalctl --user -b --no-pager | grep -i example-vpn | tail -20

यदि प्रक्रिया नहीं है, तो प्रविष्टि को बचे हुए फ़िल्टर या पुराने TryExec पथ के लिए फिर से पढ़ें। यदि है, तो लॉन्चर ने काम किया और गुम आइकन पैनल के संकेतक समर्थन की अलग समस्या है, उस प्रविष्टि की नहीं जिसे आपने अभी संपादित किया।

टिकट में तीनों अवलोकन दर्ज करें: शुरू हुआ, दिखता है, जुड़ा है। वह रिकॉर्ड अगले व्यक्ति को वही त्रिमुखी उलझन दोहराने से रोकता है और स्पष्ट करता है कि किस परत को अभी काम चाहिए।