apt purge pašalino VPN, bet paslauga vis tiek paleidžiama įkrovimo metu

apt purge teigia, kad paketo nebėra, o tunelis vis tiek pakyla per kiekvieną paleidimą. Journal vis auga, maršrutai grįžta, o mašina elgiasi taip, lyg nieko nebuvo pašalinta. Tiekėjo diegėjas gali rašyti failus, kurių paketų tvarkytuvė niekada neužregistravo, todėl pašalinti paketą ir pašalinti produktą yra du skirtingi darbai. Toliau pateiktas runbook atskiria du įrašus ir sąmoningai užbaigia šalinimą.

Du diegėjai, du skirtingi įrašai

Debian paketai turi failų sąrašą, o purge ištrina būtent tai, ką tas sąrašas nurodo, ir paketo konfigūraciją. Shell diegėjas arba .run rinkinys tokio sąrašo neturi; jis rašo kur nori, dažniausiai į /opt, /usr/local ir /etc/systemd/system. Nė vienas iš šių kelių nepatenka į jokio paketo failų sąrašą, todėl dpkg apie juos nežino ir jų neskelbia. Galų gale vienoje failų sistemoje lieka du diegimo savininkai, ir tik vienas jų veda apskaitą.

Prieš ištrindami paklauskite dpkg apie konkretų kelią. Kelias, kurio jis atsisako, yra jūsų šalinti, ir tas pats atsakymas pasakys, ar vėlesnis atnaujinimas jį grąžintų.

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

Unit ir jo wants nuoroda yra atskiri failai

Įjungimas yra atskiras veiksmas nuo diegimo. Unit savo [Install] skyriuje deklaruoja tikslų ryšius, o systemctl enable tuos pareiškimus paverčia simbolinėmis nuorodomis kiekvieno tikslo .wants/ kataloge. Dabar yra du keliai: unit failas ir nuoroda, kuri įtraukia jį į įkrovimo tikslą. Ištrinkite tik failą ir nuoroda nieko nerodo, o tai įkrovimo metu sukelia skundą; ištrinkite tik nuorodą ir unit lieka paleidžiamas pagal pavadinimą. Turi dingti abu.

Pašalinkite juos iš eilės ir po to įkelkite iš naujo, kad systemd nustotų laikyti senas apibrėžtis atmintyje.

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

Skaitykite FragmentPath, o ne spėkite vietą, nes tiekėjas galėjo rašyti į /usr/lib/systemd/system arba /lib/systemd/system, o ne į /etc. Ištrynus lauktą kopiją, veikianti lieka veikti, ir pataisa atrodo sėkminga iki kito įkėlimo. Pasibaigus įkėlimui dar kartą išvardinkite unit failus ir patvirtinkite, kad pavadinimas nebepasirodo.

Raskite dvejetainį failą, kuris palaiko šią tvarką

Įjungtas unit vis tiek paleidžia tarnybą, kad ir ką manytų paketų duomenų bazė. Tas procesas gali grąžinti tunelį, vėl pridėti maršrutus arba atkurti kill-switch taisyklę, o elgsena atrodo antgamtiška, kol neapžiūrėsite tvarkos. Sekite ExecStart kelią ir patikrinkite, ar dvejetainis failas dar ten, nes /opt apačioje paliktas vykdomasis failas yra viskas, ko tvarkai reikia. Ištrynus unit sustabdomas suplanuotas paleidimas; programa neištrinama.

Su būsenos katalogais elkitės taip pat atsargiai. Paskyros žetonai, sugeneruoti profiliai ir talpykloje laikomi serverių sąrašai gyvena /var/lib apačioje arba namų kataloge, ir tai yra prisijungimo duomenys, o ne išmetama talpykla. Pašalinkite juos sustabdę paslaugą, sąmoningai, ir užsirašykite, ką paėmėte.

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

Pasirinkite vieną įkrovimo savininką ir išbandykite jį

Trys kandidatai gali pretenduoti į įkrovimą, o įdiegus visus tris atsiranda lenktynės, o ne dviguba apsauga. Darbalaukio automatinio paleidimo failas veikia tik po to, kai kas nors prisijungia, systemd unit veikia anksčiau, bet reikia kliento, kuris dirba be ekrano, o cron @reboot įrašas suveikia pagal grafiką, kuris tinklo klientui gali būti neteisingas. Tiekėjo CLI gali papildomai reikalauti serverio argumento, nes įkrovimo metu nėra ankstesnės sesijos, kurią būtų galima tęsti. Pasirinkite kandidatą, atitinkantį tai, kaip klientas autentifikuojasi, o kitus atmeskite.

Išbandykite jį perkraudami mašiną ir pažiūrėję tris nepriklausomus faktus: unit būseną, procesų sąrašą ir naują ryšį su kuo nors, ką galite patikrinti. Klientas, kuriam reikia raktų saugyklos arba interaktyvaus prisijungimo, įkrovimo metu nepavyksta net su teisingu unit failu, ir journal tai pasako, jei jį skaitote, o ne tik paslaugos būseną.

Arba duokite klientui prisijungimo duomenis, kurie veikia be klausimo, arba paleiskite jį prisijungimo metu. Abu variantai pagrįsti, o jų derinimas yra būdas, kuriuo vienas tunelis įgyja du savininkus, kurie dėl jo ginčijasi.

Užsirašykite, ko turėtų tikėtis kitas purge

Po kiekvieno rankinio šalinimo užsirašykite du faktus: kuris diegėjas sukūrė tvarką ir kuris savininkas ją dabar paleidžia. Ta pastaba paverčia kitą purge iš netikėtumo į kontrolinio sąrašo punktą, ir ji gyvena ilgiau nei žmogus, kuris atliko darbą.

Laikykite ją šalia paslaugos konfigūracijos, o ne asmeniniame kataloge, ir datuokite, nes tiekėjo atnaujinimas gali atkurti jūsų ištrintą unit. Palyginus systemctl list-unit-files su ta pastaba kas kelis mėnesius, atkūrimas pagaunamas, kol pataisa dar pigi.