Inalis ng apt purge ang VPN, pero nagsisimula pa rin ang serbisyo sa boot

Sinasabi ng apt purge na wala na ang pakete, pero may tumutubong tunel sa bawat pagsisimula. Patuloy na lumalaki ang journal, bumabalik ang mga ruta, at kumikilos ang makina na parang walang inalis. Ang installer ng vendor ay maaaring magsulat ng mga file na hindi kailanman naitala ng tagapamahala ng pakete, kaya mag-uninstall ng pakete at mag-uninstall ng produkto ay dalawang magkaibang gawain. Hinihiwalay ng runbook sa ibaba ang dalawang tala at sinasadyang tinatapos ang pag-alis.

Dalawang installer, dalawang magkaibang tala

May listahan ng file ang mga pakete ng Debian, at binubura ng purge ang eksaktong tinutukoy ng listahang iyon kasama ang configuration ng pakete. Ang shell installer o .run bundle ay walang ganoong listahan; nagsusulat ito kahit saan, karaniwang sa /opt, /usr/local at /etc/systemd/system. Wala sa mga landas na iyon ang lumalabas sa listahan ng file ng anumang pakete, kaya hindi sila kilala o iniuulat ng dpkg. Sa huli may dalawang may-ari ng pag-install sa isang file system, at isa lang sa kanila ang nagtatala ng mga libro.

Tanungin ang dpkg tungkol sa partikular na landas bago ito burahin. Ang landas na tinatanggihan nito ay sa iyo na alisin, at ang parehong sagot ay nagsasabi kung ibabalik ito ng susunod na update.

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

Ang unit at ang wants link nito ay magkahiwalay na file

Ang pagpapagana ay hiwalay na gawa sa pag-install. Nagdedeklara ang unit ng mga relasyon sa target sa seksyong [Install], at ginagawa ng systemctl enable ang mga deklarasyong iyon na symbolic link sa loob ng .wants/ na direktoryo ng bawat target. May dalawang landas na ngayon: ang unit file, at ang link na humihila nito papasok sa target ng boot. Kung file lang ang buburahin, wala nang itinuturo ang link, na nagdudulot ng reklamo sa boot; kung link lang ang buburahin, nananatiling maisisimula ang unit sa pangalan. Dapat mawala ang dalawa.

Alisin ang mga ito nang sunod-sunod at pagkatapos ay i-reload, upang tumigil ang systemd sa paghawak ng lumang mga depinisyon sa memorya.

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

Basahin ang FragmentPath sa halip na ipagpalagay ang lokasyon, dahil maaaring nagsulat ang vendor sa /usr/lib/systemd/system o /lib/systemd/system at hindi sa /etc. Kapag binura ang kopyang inaasahan mo, patuloy na tumatakbo ang aktwal, at mukhang matagumpay ang pagwawasto hanggang sa susunod na reload. Ilista muli ang mga unit file kapag tapos na ang reload, at tiyakin na hindi na lumalabas ang pangalan.

Hanapin ang binary na nagpapanatiling buhay ng kaayusang ito

Ang naka-enable na unit ay patuloy na nagsisimula ng daemon anuman ang paniwalaan ng database ng pakete. Maaaring ibalik ng prosesong iyon ang tunel, magdagdag muli ng mga ruta, o magpanumbalik ng kill-switch na tuntunin, at ang pag-uugali ay parang sobrenatural hanggang suriin mo ang kaayusan. Sundin ang landas ng ExecStart at tingnan kung naroon pa ang binary, dahil ang executable na naiwan sa ilalim ng /opt ang siyang tanging kailangan ng kaayusan. Ang pagbura ng unit ay naghihinto sa naka-iskedyul na pagsisimula; hindi nito binubura ang programa.

Tratuhin ang mga direktoryo ng estado nang may parehong pag-iingat. Ang mga token ng account, mga nabuong profile at mga naka-cache na listahan ng server ay nakatira sa ilalim ng /var/lib o sa home directory, at mga kredensyal ang mga iyon, hindi basurang cache. Alisin ang mga ito kapag huminto ang serbisyo, nang sadya, at itala ang kinuha mo.

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

Pumili ng isang may-ari ng boot at subukan ito

Tatlong kandidato ang maaaring mag-angkin ng boot, at ang pag-install ng tatlo ay nagdudulot ng karera sa halip na dobleng seguridad. Ang autostart file ng desktop ay tumatakbo lamang pagkatapos may mag-login, ang systemd unit ay tumatakbo nang mas maaga pero kailangan ng client na gumagana nang walang screen, at ang cron @reboot entry ay pumipitik ayon sa iskedyul na maaaring mali para sa network client. Ang CLI ng vendor ay maaari pang mangailangan ng server argument, dahil sa boot ay walang naunang session na maipagpapatuloy. Piliin ang kandidatong tumutugma sa paraan ng pagpapatunay ng client, at itapon ang iba.

Subukan ito sa pamamagitan ng pag-restart ng makina at pagtingin sa tatlong malayang katotohanan: ang estado ng unit, ang listahan ng proseso, at isang bagong koneksyon sa isang bagay na maaari mong i-verify. Ang client na nangangailangan ng keyring o interactive na pag-login ay nabibigo sa boot kahit may tamang unit file, at sinasabi ito ng journal kung babasahin mo ito sa halip na estado lang ng serbisyo.

Bigyan ang client ng kredensyal na gumagana nang walang tanong, o simulan ito sa pag-login. Pareho silang maipagtatanggol, at ang pagsasama ng dalawa ay kung paano nakakakuha ang isang tunel ng dalawang may-ari na nag-aagawan dito.

Isulat kung ano ang dapat asahan ng susunod na purge

Itala ang dalawang katotohanan pagkatapos ng anumang manu-manong pag-alis: aling installer ang gumawa ng kaayusan, at aling may-ari ang nagsisimula nito ngayon. Ang talang iyon ay ginagawang item sa checklist ang susunod na purge mula sa sorpresa, at mas matagal itong nabubuhay kaysa sa taong gumawa ng trabaho.

Itago ito sa tabi ng configuration ng serbisyo at hindi sa personal na direktoryo, at lagyan ng petsa, dahil maaaring maibalik ng update ng vendor ang unit na binura mo. Ang paghahambing ng systemctl list-unit-files sa talang iyon tuwing ilang buwan ay nahuhuli ang pagpanumbalik habang mura pa ang pagwawasto.