apt purge tvrdí, že balíček je pryč, a přesto se při každém startu znovu objeví tunel. Journal dál roste, trasy se vracejí a stroj se chová, jako by se nic neodstranilo. Instalátor dodavatele může zapisovat soubory, které správce balíčků nikdy nezaznamenal, takže odinstalovat balíček a odinstalovat produkt jsou různé úkoly. Následující runbook odděluje oba záznamy a odstranění dokončí záměrně.

Dva instalátory, dva různé záznamy

Balíčky Debianu vedou seznam souborů a purge smaže přesně to, co tento seznam uvádí, plus konfiguraci balíčku. Shellový instalátor nebo balík .run takový seznam nevede; zapisuje, kam chce, obvykle do /opt, /usr/local a /etc/systemd/system. Žádná z těchto cest se neobjevuje v seznamu souborů žádného balíčku, takže o nich dpkg ani neví, ani je nehlásí. Skončíte se dvěma vlastníky instalace na jednom souborovém systému a jen jeden z nich vede účetnictví.

Před smazáním se dpkg zeptejte na konkrétní cestu. Cesta, kterou odmítne, je vaše k odstranění, a stejná odpověď vám řekne, zda by ji pozdější aktualizace vrátila.

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

Unit a jeho odkaz wants jsou oddělené soubory

Povolení je samostatný úkon od instalace. Unit deklaruje vztahy k cílům ve své sekci [Install] a systemctl enable přeměňuje tato prohlášení na symbolické odkazy v adresáři .wants/ každého cíle. Nyní existují dvě cesty: soubor unitu a odkaz, který ho vtahuje do cíle startu. Smažte jen soubor a odkaz ukazuje do prázdna, což při startu vyvolá stížnost; smažte jen odkaz a unit zůstane spustitelný podle jména. Zmizet musí obojí.

Odstraňte je v pořadí a poté znovu načtěte, aby systemd přestal držet staré definice v paměti.

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

Čtěte FragmentPath místo předpokladu umístění, protože dodavatel mohl zapsat do /usr/lib/systemd/system nebo /lib/systemd/system, a ne do /etc. Smazání kopie, kterou jste očekávali, ponechá účinnou kopii běžet a oprava vypadá úspěšně až do dalšího načtení. Po dokončení načtení znovu vypište soubory unitů a potvrďte, že se jméno už neobjevuje.

Najděte binárku, která drží uspořádání při životě

Povolený unit dál spouští démona, ať si databáze balíčků myslí cokoli. Tento proces může vrátit tunel, znovu přidat trasy nebo obnovit pravidlo kill-switch a chování vypadá nadpozemsky, dokud si neprohlédnete uspořádání. Sledujte cestu ExecStart a zkontrolujte, zda je binárka stále tam, protože spustitelný soubor ponechaný pod /opt je vše, co uspořádání potřebuje. Smazání unitu zastaví plánovaný start; nesmaže program.

Ke stavovým adresářům přistupujte stejně pečlivě. Tokeny účtů, generované profily a uložené seznamy serverů žijí pod /var/lib nebo v domovském adresáři a jde o přihlašovací údaje, ne o odhazovací cache. Odstraňte je po zastavení služby, záměrně, a poznamenejte si, co jste vzali.

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

Zvolte jednoho vlastníka startu a otestujte ho

O start se mohou ucházet tři kandidáti a instalace všech tří vytváří závod, ne dvojitou pojistku. Soubor automatického spuštění na ploše běží až po přihlášení, unit systemd běží dřív, ale potřebuje klienta, který funguje bez obrazovky, a položka cron @reboot se spouští podle plánu, který může být pro síťového klienta špatný. CLI dodavatele může navíc vyžadovat argument serveru, protože při startu neexistuje předchozí relace k obnovení. Zvolte kandidáta, který odpovídá způsobu autentizace klienta, a ostatní zahoďte.

Otestujte to restartem stroje a pohledem na tři nezávislá fakta: stav unitu, seznam procesů a nové připojení k něčemu, co můžete ověřit. Klient, který potřebuje klíčenku nebo interaktivní přihlášení, při startu selže i se správným souborem unitu, a journal to říká, pokud ho čtete místo jen stavu služby.

Buď dejte klientovi údaj, který funguje bez výzvy, nebo ho spouštějte při přihlášení. Obojí je obhajitelné a jejich spojení je způsob, jak jeden tunel získá dva vlastníky, kteří se o něj hádají.

Zapište, co má příští purge očekávat

Po každém ručním odstranění poznamenejte dva údaje: který instalátor uspořádání vytvořil a který vlastník ho nyní spouští. Tato poznámka mění příští purge z překvapení na položku kontrolního seznamu a přežije člověka, který práci udělal.

Uchovávejte ji vedle konfigurace služby, ne v osobním adresáři, a datujte ji, protože aktualizace dodavatele může obnovit unit, který jste smazali. Porovnání systemctl list-unit-files s touto poznámkou každých několik měsíců zachytí obnovu, dokud je oprava ještě levná.

Související články