VPN क्लाइंट अनइंस्टॉल हो गया, फिर भी बूट पर टनल शुरू होती है

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

जो अनइंस्टॉलर ने कभी दर्ज नहीं किया

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

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

चार मालिक, पहले केवल पढ़ना

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

dpkg -l | grep -i acmevpn
systemctl list-unit-files | grep -i acmevpn
systemctl list-units --type=service --state=running | grep -i acmevpn

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

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show --active
grep -ril acmevpn /etc/apt/sources.list.d/ /etc/apt/sources.list

सफ़ाई के बाद भी जीवित प्रक्रिया या तो सक्रिय यूनिट है या किसी दूसरे प्रोग्राम की संतान। अब न रही सेवा को दोष देने से पहले प्रक्रिया तालिका और उसकी जनक श्रृंखला पढ़ें। प्रति-उपयोगकर्ता ऑटोस्टार्ट प्रविष्टियों को भी वही जाँच चाहिए, और वे केवल नए लॉगिन शेल में दिखती हैं, root सत्र में नहीं।

तीन क्रियाएँ जो आपस में बदली नहीं जा सकतीं

रोकना मौजूदा रन समाप्त करता है, अक्षम करना बूट-समय के लिंक हटाता है, और मास्किंग यूनिट को /dev/null की ओर इंगित करती है। केवल तीसरी सॉकेट, टाइमर या निर्भरता के ज़रिए सक्रियण को भी अवरुद्ध करती है, जो उसे तीनों में सबसे मज़बूत बनाती है। मशीन के साथ क्या करना है यह तय करते समय क्रम मायने रखता है। उस निर्णय के दौरान मास्किंग सही स्थिति है, क्योंकि वह अगले बूट पर चुपचाप शुरू होने के बजाय ज़ोर से विफल होती है।

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

वाइल्डकार्ड से गलत प्रोफ़ाइल हटती है

जो UUID आपने दर्ज किया उससे प्रोफ़ाइल हटाएँ, और कभी वाइल्डकार्ड से नहीं। keyfile निर्देशिका में मशीन की हर Wi-Fi और Ethernet प्रोफ़ाइल भी होती है, इसलिए व्यापक मिलान आपकी ज़रूरत की चीज़ें हटा देता है। हाथ से हटाई गई keyfile को वह नीति फिर से बना सकती है जो उसकी मालिक है, जिससे हटाना अप्रभावी लगता है।

nmcli connection delete uuid <uuid>

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

रीबूट के बाद क्या अब भी चलता है

जीत की घोषणा से पहले रीबूट करें, फिर एप्लिकेशन के बजाय कलाकृतियाँ खोजें। पुराने क्लाइंट द्वारा छोड़ा गया टनल इंटरफ़ेस, पुराना विभाजित रूट और प्रति-लिंक DNS—हर एक को अपना कमांड चाहिए। तीनों ऐसी सफ़ाई के बाद भी बच सकते हैं जिसने हर पैकेज सफलतापूर्वक हटाया हो।

ip link
ip route
resolvectl status

नया लॉगिन शेल भी खोलें, क्योंकि ऑटोस्टार्ट प्रविष्टि केवल वहीं सक्रिय होती है। फिर /etc/NetworkManager/dispatcher.d/ पढ़ें ऐसी स्क्रिप्ट के लिए जो इंटरफ़ेस की स्थिति बदलने पर कनेक्शन ऊपर लाती है, जो पीछे कोई सेवा न होते हुए टनल के लौटने की व्याख्या करता है। यदि कुछ अब भी बाहर डायल करता है, तो लक्षण रुकने तक फ़ाइलें हटाने के बजाय प्रक्रिया को उसके जनक तक ट्रेस करें। मशीन साफ़ करना और खाता रद्द करना अलग काम रहते हैं, और रीबूट शांत दिखे तो उनमें से केवल एक ही पूरा होता है।