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-ის ამ ჩანაწერთან შედარება ყოველ რამდენიმე თვეში იჭერს აღდგენას, სანამ შესწორება ჯერ კიდევ იაფია.