apt purge usunął VPN, ale usługa nadal startuje przy rozruchu

apt purge twierdzi, że pakietu nie ma, a mimo to przy każdym starcie znów pojawia się tunel. Journal wciąż rośnie, trasy wracają, a maszyna zachowuje się, jakby nic nie usunięto. Instalator dostawcy może zapisywać pliki, których menedżer pakietów nigdy nie zarejestrował, więc odinstalowanie pakietu i odinstalowanie produktu to dwie różne prace. Poniższy runbook rozdziela dwa rejestry i świadomie kończy usuwanie.

Dwa instalatory, dwa różne rejestry

Pakiety Debiana prowadzą listę plików, a purge usuwa dokładnie to, co ta lista wymienia, plus konfigurację pakietu. Instalator powłoki albo pakiet .run nie prowadzi takiej listy; pisze, gdzie chce, zwykle do /opt, /usr/local i /etc/systemd/system. Żadna z tych ścieżek nie występuje na liście plików jakiegokolwiek pakietu, więc dpkg ani o nich nie wie, ani ich nie zgłasza. Kończysz z dwoma właścicielami instalacji na jednym systemie plików i tylko jeden z nich prowadzi księgi.

Zapytaj dpkg o konkretną ścieżkę, zanim ją usuniesz. Ścieżka, której się wyprze, jest twoja do usunięcia, a ta sama odpowiedź mówi, czy późniejsza aktualizacja by ją przywróciła.

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

Unit i jego dowiązanie wants to osobne pliki

Włączanie to czynność odrębna od instalowania. Unit deklaruje relacje celów w sekcji [Install], a systemctl enable zamienia te deklaracje na dowiązania symboliczne w katalogu .wants/ każdego celu. Teraz istnieją dwie ścieżki: plik unitu i dowiązanie, które wciąga go do celu rozruchu. Usuń sam plik, a dowiązanie wskazuje w próżnię, co daje skargę przy rozruchu; usuń samo dowiązanie, a unit pozostaje uruchamialny po nazwie. Oba muszą zniknąć.

Usuń je po kolei i przeładuj ponownie, żeby systemd przestał trzymać stare definicje w pamięci.

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

Czytaj FragmentPath zamiast zakładać lokalizację, bo dostawca mógł zapisać do /usr/lib/systemd/system lub /lib/systemd/system, a nie do /etc. Usunięcie oczekiwanej kopii zostawia działającą w ruchu, a poprawka wygląda na udaną do następnego przeładowania. Wypisz pliki unitów ponownie po zakończeniu przeładowania i potwierdź, że nazwa już się nie pojawia.

Znajdź plik binarny, który utrzymuje ten układ przy życiu

Włączony unit nadal uruchamia demona, cokolwiek sądzi baza pakietów. Ten proces może przywrócić tunel, dodać trasy ponownie albo odtworzyć regułę kill-switch, a zachowanie wygląda nadnaturalnie, dopóki nie obejrzysz układu. Idź ścieżką ExecStart i sprawdź, czy plik binarny wciąż tam jest, bo plik wykonywalny zostawiony pod /opt to wszystko, czego układ potrzebuje. Usunięcie unitu zatrzymuje zaplanowany start; nie usuwa programu.

Traktuj katalogi stanu z taką samą troską. Tokeny kont, wygenerowane profile i buforowane listy serwerów żyją pod /var/lib lub w katalogu domowym, a to dane uwierzytelniające, nie bufor do wyrzucenia. Usuń je po zatrzymaniu usługi, świadomie, i zapisz, co zabrałeś.

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

Wybierz jednego właściciela rozruchu i przetestuj go

Trzej kandydaci mogą rościć sobie prawo do rozruchu, a instalacja wszystkich trzech daje wyścig, a nie podwójne zabezpieczenie. Plik autostartu pulpitu działa dopiero po zalogowaniu się kogoś, unit systemd działa wcześniej, ale wymaga klienta działającego bez ekranu, a wpis cron @reboot odpala się według harmonogramu, który dla klienta sieciowego może być błędny. CLI dostawcy może dodatkowo wymagać argumentu serwera, bo przy rozruchu nie ma poprzedniej sesji do wznowienia. Wybierz kandydata pasującego do sposobu uwierzytelniania klienta, a resztę odrzuć.

Przetestuj to, restartując maszynę i patrząc na trzy niezależne fakty: stan unitu, listę procesów i nowe połączenie z czymś, co możesz zweryfikować. Klient wymagający pęku kluczy albo interaktywnego logowania zawodzi przy rozruchu nawet z poprawnym plikiem unitu, a journal to mówi, jeśli go czytasz, a nie tylko status usługi.

Albo daj klientowi dane uwierzytelniające działające bez pytania, albo uruchamiaj go przy logowaniu. Oba rozwiązania są obronne, a ich łączenie to sposób, w jaki jeden tunel zyskuje dwóch właścicieli, którzy się o niego kłócą.

Zapisz, czego powinien oczekiwać następny purge

Zanotuj dwa fakty po każdym ręcznym usunięciu: który instalator stworzył układ i który właściciel uruchamia go teraz. Ta notatka zmienia następny purge z niespodzianki w punkt listy kontrolnej i żyje dłużej niż osoba, która wykonała pracę.

Trzymaj ją obok konfiguracji usługi, a nie w katalogu osobistym, i opatrz datą, bo aktualizacja dostawcy może przywrócić usunięty unit. Porównywanie systemctl list-unit-files z tą notatką co kilka miesięcy wyłapuje przywrócenie, dopóki poprawka jest jeszcze tania.