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 लाई त्यो टिप्पणीसँग तुलना गर्दा सुधार अझै सस्तो छँदै पुनर्स्थापना भेटिन्छ।