Неуспешно премахване на VPN пакет в prerm: какво да проверите първо

Деинсталирането може да спре по средата с грешка, която назовава скрипт за поддръжка, оставяйки VPN наполовина премахнат: конфигурационните файлове остават, услугата може все още да работи, а мениджърът на пакети отказва да продължи. Изкушаващото решение в стара тема във форум е да изтриете скрипта и да принудите премахването. Това лекува симптома и изхвърля стъпката за почистване, която се е провалила. Първо прочетете етапа и състоянието на пакета.

Коя стъпка от жизнения цикъл всъщност се провали

Debian пакетите изпълняват preinst и postinst при инсталиране, а prerm и postrm при премахване или пълно изчистване, като кодът за изход на всеки скрипт определя следващото действие. Грешка от prerm означава, че премахването е спряло, преди файловете на пакета да бъдат изтрити; грешка от postrm означава, че премахването вече е станало и почистването се е провалило. Това са различни ситуации с различно възстановяване. Политиката на дистрибуцията също очаква скриптовете да понасят повторно изпълнение, защото провален етап трябва да се повтори, а не да се избягва.

Запишете първата грешка дословно, заедно с името на пакета, версията и изданието на дистрибуцията. Следващите грешки обикновено са последици.

Прочетете състоянието на пакета, преди да го промените

Попитайте мениджъра на пакети какво смята, че се е случило, преди да издадете друга команда.

dpkg -l vpn-package
dpkg --audit
apt-get -s remove vpn-package

Списъкът показва флаговете за състояние на пакета, одитът намира пакети, оставени счупени или наполовина конфигурирани, а симулираното премахване отпечатва какво би направил apt, без да докосва нищо. Симулация, която се проваля на същия скрипт, потвърждава етапа, а не мрежата. Отбележете скрипта, посочен в грешката, и избройте информационните файлове на пакета, ако трябва да видите кои скриптове съществуват. Нищо от това още не оправдава редактирането на тези файлове.

Защитете пътя за управление преди ремонта

Ако VPN носи единствената ви SSH сесия към този хост, премахването ѝ прекратява достъпа ви по средата на ремонта. Първо осигурете конзола, извънлентов интерфейс за управление или втори маршрут и потвърдете, че работи, преди да започнете. Запазете профила и всякакви инструкции за повторно записване, които ще ви трябват после, защото пълното изчистване може да премахне генерирана конфигурация. Дръжте идентификационните данни извън бележките, които поставяте в тикет, и дръжте частните ключове напълно извън диагностиката.

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

Разделете резултатите за пакета, мрежата и идентификационните данни

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

След това се свържете отново и тествайте една разрешена дестинация. Чисто състояние на пакета с все още работещ тунел е различен резултат от чиста мрежа и само второто ви казва, че премахването наистина е влязло в сила.