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 са том белешком сваких неколико месеци ухватиће обнову док је поправка још јефтина.