apt purge премахна VPN, но услугата все още стартира при зареждане

apt purge казва, че пакетът е изчезнал, а тунелът все още се вдига при всяко стартиране. Журналът продължава да расте, маршрутите се връщат и машината се държи така, сякаш нищо не е премахнато. Инсталаторът на доставчика може да записва файлове, които мениджърът на пакети никога не е записвал, затова премахването на пакет и премахването на продукт са различни задачи. 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

Изберете един собственик на зареждането и го тествайте

Три кандидата могат да претендират за зареждането и инсталирането и на трите създава надпревара, а не двойна сигурност. Файл за автоматично стартиране на работния плот работи само след като някой влезе, unit на systemd работи по-рано, но изисква клиент, който работи без екран, а запис cron @reboot се задейства по график, който може да е грешен за мрежов клиент. CLI на доставчика може допълнително да изисква аргумент за сървър, защото при зареждане няма предишна сесия за възобновяване. Изберете кандидата, който пасва на начина, по който клиентът се удостоверява, и отхвърлете останалите.

Тествайте го, като рестартирате машината и погледнете три независими факта: състоянието на unit-а, списъка с процеси и нова връзка към нещо, което можете да проверите. Клиент, който изисква ключодържател или интерактивно влизане, се проваля при зареждане дори с правилен файл на unit, а журналът го казва, ако го четете, вместо само статуса на услугата.

Или дайте на клиента идентификационни данни, които работят без подкана, или го стартирайте при влизане. И двете са защитими, а комбинирането им е начинът, по който един тунел се сдобива с двама собственици, които се борят за него.

Запишете какво да очаква следващият purge

Отбележете два факта след всяко ръчно премахване: кой инсталатор е създал подредбата и кой собственик сега я стартира. Тази бележка превръща следващия purge от изненада в точка от контролен списък и надживява човека, който е свършил работата.

Пазете я до конфигурацията на услугата, а не в лична директория, и я датирайте, защото обновяване на доставчика може да възстанови unit, който сте изтрили. Сравняването на systemctl list-unit-files с тази бележка на няколко месеца хваща възстановяването, докато поправката е още евтина.