apt purge e hoqi VPN-në, por shërbimi nis përsëri gjatë boot-it

apt purge thotë se paketa nuk është më, e megjithatë një tunel ngrihet përsëri në çdo nisje. Journal vazhdon të rritet, rrugët kthehen, dhe makina sillet sikur të mos ishte hequr asgjë. Instaluesi i furnizuesit mund të shkruajë skedarë që menaxheri i paketave nuk i regjistroi kurrë, prandaj të çinstalosh një paketë dhe të çinstalosh një produkt janë dy punë të ndryshme. Runbook-u më poshtë i ndan dy regjistrat dhe e përfundon heqjen me qëllim.

Dy instalues, dy regjistra të ndryshëm

Paketat Debian mbajnë një listë skedarësh, dhe një purge fshin saktësisht atë që liston lista plus konfigurimin e paketës. Një instalues shell ose një paketë .run nuk mban një listë të tillë; shkruan ku të dojë, zakonisht në /opt, /usr/local dhe /etc/systemd/system. Asnjë prej këtyre shtigjeve nuk shfaqet në listën e skedarëve të asnjë pakete, prandaj dpkg as nuk i njeh as nuk i raporton. Përfundoni me dy pronarë të instalimit në një sistem skedarësh, dhe vetëm njëri prej tyre mban llogaritë.

Pyetni dpkg për shtegun konkret përpara se ta fshini. Një shteg që ai e mohon është i juaji për t u hequr, dhe e njëjta përgjigje ju thotë nëse një përditësim i mëvonshëm do ta kthente.

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

Një unit dhe lidhja e tij wants janë skedarë të veçantë

Aktivizimi është një veprim i veçantë nga instalimi. Unit-i deklaron marrëdhëniet e objektivit në seksionin [Install], dhe systemctl enable i kthen ato deklarata në lidhje simbolike brenda drejtorisë .wants/ të çdo objektivi. Tani ekzistojnë dy shtigje: skedari i unit-it dhe lidhja që e tërheq në një objektiv nisjeje. Fshini vetëm skedarin dhe lidhja nuk tregon gjë, çka prodhon një ankesë gjatë nisjes; fshini vetëm lidhjen dhe unit-i mbetet i nisur me emër. Të dyja duhet të ikin.

Hiqini me radhë dhe më pas ringarkoni, që systemd të ndalojë mbajtjen e përkufizimeve të vjetra në memorie.

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

Lexoni FragmentPath në vend që të supozoni vendndodhjen, sepse furnizuesi mund të ketë shkruar në /usr/lib/systemd/system ose /lib/systemd/system dhe jo në /etc. Fshirja e kopjes që prisnit lë atë efektive duke punuar, dhe rregullimi duket i suksesshëm deri në ringarkimin tjetër. Listoni përsëri skedarët e unit-eve kur të mbarojë ringarkimi, dhe konfirmoni që emri nuk shfaqet më.

Gjeni binarin që e mban gjallë këtë rregullim

Një unit i aktivizuar vazhdon të nisë daemon-in sido që mendon baza e të dhënave e paketave. Ai proces mund ta kthejë tunelin, të shtojë përsëri rrugë ose të rivendosë një rregull kill-switch, dhe sjellja duket mbinatyrore derisa të shqyrtoni rregullimin. Ndiqni shtegun ExecStart dhe kontrolloni nëse binari është ende atje, sepse një skedar i ekzekutueshëm i lënë nën /opt është gjithçka që rregullimi ka nevojë. Fshirja e unit-it ndalon nisjen e planifikuar; nuk e fshin programin.

Trajtoni drejtoritë e gjendjes me të njëjtin kujdes. Shenjat e llogarisë, profilet e gjeneruara dhe listat e serverëve në cache jetojnë nën /var/lib ose në një drejtori shtëpie, dhe këto janë kredenciale, jo cache për t u hedhur. Hiqini pasi shërbimi të ndalet, me qëllim, dhe shënoni çfarë morët.

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

Zgjidhni një pronar të vetëm të nisjes dhe provojeni

Tre kandidatë mund të kërkojnë nisjen, dhe instalimi i të treve prodhon një garë në vend të sigurisë së dyfishtë. Një skedar vetënisjeje i desktopit ekzekutohet vetëm pasi dikush të hyjë, një unit systemd ekzekutohet më herët por kërkon një klient që punon pa ekran, dhe një hyrje cron @reboot aktivizohet sipas një orari që mund të jetë i gabuar për një klient rrjeti. CLI i furnizuesit mund të kërkojë gjithashtu një argument serveri, sepse gjatë nisjes nuk ka sesion të mëparshëm për të vazhduar. Zgjidhni kandidatin që përputhet me mënyrën se si klienti autentifikohet, dhe hidhni të tjerët.

Provojeni duke rinisur makinën dhe duke parë tre fakte të pavarura: gjendjen e unit-it, listën e proceseve dhe një lidhje të re me diçka që mund të verifikoni. Një klient që kërkon një unazë çelësash ose një hyrje interaktive dështon gjatë nisjes edhe me një skedar unit të saktë, dhe journal-i e thotë këtë nëse e lexoni në vend të vetëm gjendjes së shërbimit.

Ose jepini klientit një kredencial që punon pa pyetje, ose nisni atë gjatë hyrjes. Të dyja janë të mbrojtshme, dhe kombinimi i tyre është mënyra se si një tunel fiton dy pronarë që grinden për të.

Shkruani çfarë duhet të presë purge-i i radhës

Shënoni dy fakte pas çdo heqjeje manuale: cili instalues e krijoi rregullimin, dhe cili pronar e nis tani. Ai shënim e kthen purge-in e radhës nga befasi në një zë të listës kontrolluese, dhe jeton më gjatë se personi që bëri punën.

Mbajeni pranë konfigurimit të shërbimit dhe jo në një drejtori personale, dhe vendosni datë, sepse një përditësim i furnizuesit mund të rivendosë një unit që e fshitë. Krahasimi i systemctl list-unit-files me atë shënim çdo pak muaj kap rivendosjen ndërsa rregullimi është ende i lirë.