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 з гэтай нататкай кожныя некалькі месяцаў зловіць аднаўленне, пакуль яго яшчэ танна выправіць.

Падобныя артыкулы