prerm में VPN पैकेज हटाना विफल: पहले क्या जाँचें

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

जीवनचक्र का कौन-सा चरण वास्तव में विफल हुआ

Debian पैकेज इंस्टॉलेशन पर preinst और postinst चलाते हैं, और हटाने या पूरी सफ़ाई पर prerm और postrm, तथा हर स्क्रिप्ट की एक्ज़िट स्थिति अगली कार्रवाई तय करती है। prerm से आने वाली त्रुटि का अर्थ है कि पैकेज की फ़ाइलें मिटने से पहले हटाना रुक गया; postrm से आने वाली त्रुटि का अर्थ है कि हटाना पहले ही हो चुका और सफ़ाई विफल हुई। ये अलग-अलग रिकवरी वाली अलग स्थितियाँ हैं। वितरण नीति यह भी अपेक्षा करती है कि स्क्रिप्टें दोबारा चलना सहें, क्योंकि विफल चरण से बचना नहीं, उसे दोहराना चाहिए।

पहली त्रुटि शब्दशः लिखें, पैकेज का नाम, संस्करण और वितरण संस्करण के साथ। बाद की त्रुटियाँ आमतौर पर परिणाम होती हैं।

बदलने से पहले पैकेज की स्थिति पढ़ें

दूसरा आदेश देने से पहले पैकेज मैनेजर से पूछें कि उसे क्या हुआ लगता है।

dpkg -l vpn-package
dpkg --audit
apt-get -s remove vpn-package

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

मरम्मत से पहले प्रबंधन मार्ग की रक्षा करें

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

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

पैकेज, नेटवर्क और क्रेडेंशियल के परिणाम अलग करें

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

फिर दोबारा जुड़ें और एक अनुमत गंतव्य जाँचें। अभी भी चल रहे टनल के साथ साफ़ पैकेज स्थिति साफ़ नेटवर्क से अलग परिणाम है, और केवल दूसरा ही बताता है कि हटाना वास्तव में लागू हुआ।