apt purge ने VPN हटा दिया, फिर भी सेवा बूट पर शुरू होती है

apt purge कहता है कि पैकेज चला गया, फिर भी हर शुरुआत पर एक टनल फिर उठ आती है। journal बढ़ता रहता है, रूट लौट आते हैं, और मशीन ऐसे व्यवहार करती है जैसे कुछ हटाया ही न गया हो। विक्रेता का इंस्टॉलर ऐसी फ़ाइलें लिख सकता है जिन्हें पैकेज प्रबंधक ने कभी दर्ज नहीं किया, इसलिए पैकेज हटाना और उत्पाद हटाना दो अलग काम हैं. नीचे दिया गया runbook दोनों रिकॉर्ड अलग करता है और हटाने को जानबूझकर पूरा करता है।

दो इंस्टॉलर, दो अलग रिकॉर्ड

Debian पैकेज फ़ाइलों की सूची रखते हैं, और purge ठीक वही मिटाता है जो वह सूची नाम लेती है, साथ में पैकेज का कॉन्फ़िगरेशन। shell इंस्टॉलर या .run बंडल ऐसी सूची नहीं रखता; वह जहाँ चाहे लिखता है, आमतौर पर /opt, /usr/local और /etc/systemd/system में। उनमें से कोई भी पथ किसी पैकेज की फ़ाइल सूची में नहीं दिखता, इसलिए dpkg न उन्हें जानता है न उनकी रिपोर्ट करता है। अंत में एक ही फ़ाइल सिस्टम पर दो इंस्टॉलेशन मालिक होते हैं और उनमें से केवल एक हिसाब रखता है।

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

dpkg -S /etc/systemd/system/acmevpn.service
systemctl list-unit-files | grep -i acmevpn

unit और उसका wants लिंक अलग फ़ाइलें हैं

सक्षम करना स्थापित करने से अलग कार्य है। unit अपने [Install] अनुभाग में लक्ष्य संबंध घोषित करता है, और systemctl enable उन घोषणाओं को हर लक्ष्य की .wants/ निर्देशिका में प्रतीकात्मक लिंक में बदल देता है। अब दो पथ हैं: unit फ़ाइल, और वह लिंक जो उसे बूट लक्ष्य में खींचता है। केवल फ़ाइल मिटाएँ तो लिंक कहीं नहीं इंगित करता, जिससे बूट पर शिकायत होती है; केवल लिंक मिटाएँ तो unit नाम से शुरू होने योग्य रहता है। दोनों को जाना है।

उन्हें क्रम से हटाएँ और बाद में फिर से लोड करें, ताकि systemd पुरानी परिभाषाएँ स्मृति में रखना बंद कर दे।

systemctl disable --now acmevpn.service
systemctl show -p FragmentPath -p ExecStart acmevpn.service
sudo rm /etc/systemd/system/acmevpn.service
sudo rm /etc/systemd/system/multi-user.target.wants/acmevpn.service
systemctl daemon-reload

स्थान मान लेने के बजाय FragmentPath पढ़ें, क्योंकि विक्रेता ने /etc के बजाय /usr/lib/systemd/system या /lib/systemd/system में लिखा हो सकता है। जिस प्रति की आपने अपेक्षा की थी उसे मिटाने से प्रभावी प्रति चलती रहती है, और अगले पुनःलोड तक सुधार सफल लगता है। पुनःलोड पूरा होने पर unit फ़ाइलें फिर सूचीबद्ध करें और पुष्टि करें कि नाम अब नहीं दिखता।

वह बाइनरी खोजें जो इस व्यवस्था को जीवित रखती है

सक्षम unit पैकेज डेटाबेस को जो भी लगे, डेमॉन शुरू करता रहता है। वह प्रक्रिया टनल वापस ला सकती है, रूट फिर जोड़ सकती है या kill-switch नियम बहाल कर सकती है, और जब तक आप व्यवस्था जाँच नहीं लेते व्यवहार अलौकिक लगता है। ExecStart पथ का अनुसरण करें और जाँचें कि बाइनरी अभी भी वहीं है, क्योंकि /opt के नीचे छोड़ी गई निष्पादन योग्य फ़ाइल ही इस व्यवस्था की पूरी आवश्यकता है। unit मिटाने से निर्धारित शुरुआत रुकती है; वह प्रोग्राम नहीं मिटाता।

स्टेट निर्देशिकाओं के साथ भी उतनी ही सावधानी रखें। खाता टोकन, बनाए गए प्रोफ़ाइल और कैश की गई सर्वर सूचियाँ /var/lib के नीचे या होम निर्देशिका में रहती हैं, और वे क्रेडेंशियल हैं, फेंकने योग्य कैश नहीं। सेवा रुकने के बाद उन्हें जानबूझकर हटाएँ और लिखें कि क्या लिया।

sudo ls -l /opt/acmevpn /usr/local/bin/acmevpn
sudo find /var/lib -maxdepth 2 -iname "*acme*"
systemctl is-enabled acmevpn.service

बूट का एक मालिक चुनें और उसे जाँचें

तीन उम्मीदवार बूट पर दावा कर सकते हैं, और तीनों स्थापित करने से दोहरी सुरक्षा के बजाय दौड़ पैदा होती है। डेस्कटॉप ऑटोस्टार्ट फ़ाइल किसी के साइन-इन करने के बाद ही चलती है, systemd unit पहले चलता है पर ऐसा क्लाइंट चाहिए जो स्क्रीन के बिना चले, और cron @reboot प्रविष्टि ऐसी समय-सारिणी पर चलती है जो नेटवर्क क्लाइंट के लिए गलत हो सकती है। विक्रेता का CLI अतिरिक्त रूप से सर्वर तर्क माँग सकता है, क्योंकि बूट पर जारी रखने के लिए पिछला सत्र नहीं होता। वह उम्मीदवार चुनें जो क्लाइंट के प्रमाणीकरण के तरीके से मेल खाता है, और बाकी छोड़ दें।

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

या तो क्लाइंट को ऐसा क्रेडेंशियल दें जो बिना पूछे काम करे, या फिर साइन-इन पर उसे शुरू करें। दोनों उचित हैं, और दोनों को मिलाना ही वह तरीका है जिससे एक टनल के दो मालिक हो जाते हैं जो उसके लिए लड़ते हैं।

लिखें कि अगले purge को क्या अपेक्षा रखनी चाहिए

किसी भी मैन्युअल हटाने के बाद दो तथ्य लिखें: किस इंस्टॉलर ने यह व्यवस्था बनाई, और अब कौन मालिक इसे शुरू करता है। वह नोट अगले purge को आश्चर्य से चेकलिस्ट के एक मद में बदल देता है, और काम करने वाले व्यक्ति से अधिक जीता है।

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