Az apt purge eltávolította a VPN-t, a szolgáltatás mégis indul a rendszerindításkor

Az apt purge azt mondja, hogy a csomag eltűnt, és mégis minden indításkor újra feljön egy alagút. A journal tovább növekszik, az útvonalak visszatérnek, és a gép úgy viselkedik, mintha semmit nem távolítottak volna el. A beszállító telepítője olyan fájlokat írhat, amelyeket a csomagkezelő soha nem jegyzett fel, ezért a csomag eltávolítása és egy termék eltávolítása két külön feladat. Az alábbi runbook szétválasztja a két nyilvántartást, és szándékosan befejezi az eltávolítást.

Két telepítő, két különböző nyilvántartás

A Debian csomagok fájllistát vezetnek, és a purge pontosan azt törli, amit ez a lista megnevez, valamint a csomag konfigurációját. Egy shell-telepítő vagy egy .run csomag nem vezet ilyen listát; oda ír, ahová akar, többnyire a /opt, /usr/local és /etc/systemd/system könyvtárakba. Egyik ilyen útvonal sem jelenik meg egyetlen csomag fájllistájában sem, ezért a dpkg sem tud róluk, és nem is jelenti őket. Végül két telepítési tulajdonos lesz egy fájlrendszeren, és csak az egyikük vezet könyveket.

Kérdezze meg a dpkg-t az adott útvonalról, mielőtt törölné. Az az útvonal, amelyet megtagad, az öné az eltávolításhoz, és ugyanez a válasz megmondja, hogy egy későbbi frissítés visszahozná-e.

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

Az unit és a wants hivatkozása külön fájlok

Az engedélyezés külön művelet a telepítéstől. Az unit a [Install] szakaszában célkapcsolatokat deklarál, és a systemctl enable ezeket a deklarációkat szimbolikus hivatkozásokká alakítja minden cél .wants/ könyvtárában. Most két útvonal létezik: az unit fájlja és a hivatkozás, amely behúzza egy indítási célba. Ha csak a fájlt törli, a hivatkozás a semmire mutat, ami indításkor panaszt okoz; ha csak a hivatkozást törli, az unit név szerint indítható marad. Mindkettőnek el kell mennie.

Távolítsa el őket sorrendben, majd töltse újra, hogy a systemd ne tartsa tovább a régi definíciókat a memóriában.

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

Olvassa ki a FragmentPath értékét ahelyett, hogy feltételezné a helyet, mert a beszállító esetleg a /usr/lib/systemd/system vagy a /lib/systemd/system könyvtárba írt a /etc helyett. A várt példány törlése az érvényben lévőt futva hagyja, és a javítás a következő újratöltésig sikeresnek látszik. Az újratöltés után listázza újra az unit fájlokat, és erősítse meg, hogy a név már nem jelenik meg.

Keresse meg a binárist, amely életben tartja az elrendezést

Az engedélyezett unit tovább indítja a démont, bármit is hisz a csomagadatbázis. Az a folyamat visszahozhatja az alagutat, újra hozzáadhatja az útvonalakat vagy visszaállíthat egy kill-switch szabályt, és a viselkedés természetfelettinek tűnik, amíg meg nem vizsgálja az elrendezést. Kövesse a ExecStart útvonalat, és ellenőrizze, hogy a bináris még ott van-e, mert a /opt alatt hagyott futtatható fájl minden, amire az elrendezésnek szüksége van. Az unit törlése leállítja az ütemezett indítást; nem törli a programot.

Ugyanazzal a gondossággal kezelje az állapotkönyvtárakat. A fióktokenek, a generált profilok és a gyorsítótárazott kiszolgálólisták a /var/lib alatt vagy egy otthoni könyvtárban élnek, és ezek hitelesítő adatok, nem eldobható gyorsítótár. Távolítsa el őket a szolgáltatás leállítása után, szándékosan, és jegyezze fel, mit vitt el.

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

Válasszon egyetlen indítási tulajdonost, és tesztelje

Három jelölt tarthat igényt az indításra, és mindhárom telepítése versenyt okoz a kétszeres biztonság helyett. Az asztali automatikus indítófájl csak bejelentkezés után fut, a systemd unit korábban fut, de olyan kliens kell hozzá, amely képernyő nélkül működik, a cron @reboot bejegyzés pedig olyan ütemezés szerint indul, amely hálózati kliensnél hibás lehet. A beszállító CLI-je emellett kiszolgálóargumentumot is kérhet, mert indításkor nincs előző munkamenet, amelyet folytatni lehetne. Válassza azt a jelöltet, amely illik ahhoz, ahogy a kliens hitelesít, és dobja el a többit.

Tesztelje úgy, hogy újraindítja a gépet, és három független tényre néz: az unit állapotára, a folyamatlistára és egy új kapcsolatra valami ellenőrizhetőhöz. Az a kliens, amely kulcstartót vagy interaktív bejelentkezést igényel, indításkor elbukik még helyes unit fájl mellett is, és a journal ezt megmondja, ha elolvassa, nem csak a szolgáltatás állapotát.

Vagy adjon a kliensnek olyan hitelesítő adatot, amely kérdés nélkül működik, vagy indítsa bejelentkezéskor. Mindkettő védhető, és a kettő kombinálása az, ahogy egy alagút két tulajdonost szerez, akik harcolnak érte.

Írja le, mire számíthat a következő purge

Jegyezzen fel két tényt minden kézi eltávolítás után: melyik telepítő hozta létre az elrendezést, és melyik tulajdonos indítja most. Ez a feljegyzés a következő purge-öt meglepetésből ellenőrzőlista-ponttá alakítja, és tovább él, mint az a személy, aki a munkát elvégezte.

Tartsa a szolgáltatás konfigurációja mellett, ne személyes könyvtárban, és lássa el dátummal, mert a beszállító frissítése visszaállíthat egy törölt unitot. Ha néhány havonta összeveti a systemctl list-unit-files listát ezzel a feljegyzéssel, elkapja a visszaállítást, amíg a javítás még olcsó.