apt purge го отстрани VPN, но услугата сè уште се стартува при подигање

apt purge вели дека пакетот го нема, а тунелот сепак се појавува при секое стартување. Journal продолжува да расте, маршрутите се враќаат, и машината се однесува како ништо да не е отстрането. Инсталаторот на доставувачот може да запише датотеки што менаџерот на пакети никогаш не ги забележал, затоа отстранување пакет и отстранување производ се два различни задачи. Runbook-от подолу ги разделува двата записа и го завршува отстранувањето намерно.

Два инсталатори, два различни записи

Debian пакетите држат список на датотеки, а purge брише точно тоа што списокот го именува плус конфигурацијата на пакетот. Shell инсталатор или .run пакет не држи таков список; пишува каде сака, обично во /opt, /usr/local и /etc/systemd/system. Ниту една од тие патеки не се појавува во списокот на датотеки на кој било пакет, па dpkg ниту знае за нив ниту ги известува. Завршувате со два сопственици на инсталацијата на еден датотечен систем, и само еден од нив води книги.

Прашајте го dpkg за конкретната патека пред да ја избришете. Патека што ја отфрла е ваша за отстранување, а истиот одговор ви кажува дали подоцнежна надградба би ја вратила.

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

Unit и неговата wants врска се одделни датотеки

Овозможувањето е одделен чин од инсталирањето. Unit-от декларира односи кон цели во својот [Install] дел, а systemctl enable ги претвора тие декларации во симболични врски во .wants/ директориумот на секоја цел. Сега постојат две патеки: датотеката на unit-от и врската што го влече во цел за подигање. Избришете ја само датотеката и врската покажува во празно, што создава жалба при подигање; избришете ја само врската и unit-от останува стартувачки по име. И двете мора да заминат.

Отстранете ги по ред и потоа вчитајте одново, за systemd да престане да ги држи старите дефиниции во меморијата.

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

Читајте го FragmentPath наместо да претпоставувате локација, бидејќи доставувачот можеби пишувал во /usr/lib/systemd/system или /lib/systemd/system, а не во /etc. Бришењето на копијата што ја очекувавте ја остава активната да работи, и поправката изгледа успешна до следното вчитување. Повторно излистајте ги датотеките на unit-ите откако ќе заврши вчитувањето и потврдете дека името повеќе не се појавува.

Најдете ја бинарната програма што го одржува распоредот жив

Овозможен unit продолжува да го стартува демонот што и да мисли базата на пакети. Тој процес може да го врати тунелот, повторно да додаде маршрути или да обнови правило за kill-switch, и однесувањето изгледа натприродно додека не го прегледате распоредот. Следете ја патеката ExecStart и проверете дали бинарната програма е сè уште таму, бидејќи извршна датотека оставена под /opt е сè што му треба на распоредот. Бришењето на unit-от го запира закажаното стартување; не ја брише програмата.

Кон директориумите за состојба постапувајте со исто внимание. Токени на сметка, генерирани профили и кеширани списоци на сервери живеат под /var/lib или во домашна папка, а тоа се акредитиви, не кеш за фрлање. Отстранете ги откако услугата е запрена, намерно, и забележете што зедовте.

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

Изберете еден сопственик на подигањето и тестирајте го

Тројца кандидати можат да го бараат подигањето, а инсталирањето на сите тројца создава трка, не двојна сигурност. Датотека за автоматско стартување на работна површина работи само откако некој ќе се најави, systemd unit работи порано но бара клиент што работи без екран, а cron запис @reboot се активира по распоред што може да е погрешен за мрежен клиент. CLI-то на доставувачот може дополнително да бара аргумент за сервер, бидејќи при подигање нема претходна сесија за продолжување. Изберете го кандидатот што одговара на начинот на кој клиентот се автентифицира и отфрлете ги другите.

Тестирајте го со повторно подигање на машината и гледање три независни факти: состојбата на unit-от, списокот на процеси и нова врска кон нешто што можете да го потврдите. Клиент што бара приврзок за клучеви или интерактивна најава не успева при подигање дури и со точна датотека на unit, а journal-от го кажува тоа ако го читате наместо само статусот на услугата.

Или дајте му на клиентот акредитив што работи без прашање, или стартувајте го при најава. И двете се одбранливи, а нивното комбинирање е начинот на кој еден тунел добива два сопственици што се караат за него.

Запишете што треба да очекува следниот purge

Забележете два факти по секое рачно отстранување: кој инсталатор го создал распоредот и кој сопственик сега го стартува. Таа белешка го претвора следниот purge од изненадување во ставка на контролен список, и таа го надживува човекот што ја завршил работата.

Чувајте ја до конфигурацијата на услугата, а не во лична папка, и датирајте ја, бидејќи надградба на доставувачот може да врати unit што сте го избришале. Споредбата на systemctl list-unit-files со таа белешка на неколку месеци ја фаќа обновата додека поправката е сè уште евтина.