Утримання APT або шлях оновлення: відкат клієнта VPN

Оновлення клієнта ламають тунелі, старі версії продовжують працювати, і це залишає два очевидні засоби. Одне утримує пакет на місці й чекає виправлення; інше одразу переходить на підтримувану конфігурацію. Вони не однаково безпечні, і жодне не є стратегією обслуговування без виходу. Порівняйте їх за тим, що вони насправді заморожують, перш ніж вибирати.

Два засоби на одну регресію

Утримання пакета зберігає робочу версію встановленою і не дає APT її зсунути. Це виграє час, тримає користувачів на зв'язку й залишає основну помилку недоторканою. Рух уперед означає знайти підтримуваний випуск, що виправляє регресію, або змінити власника з'єднання на те, що дистрибутив ще підтримує. Це коштує більше роботи заздалегідь і прибирає постійний ризик.

Вибір залежить від трьох фактів, які мають бути у вас до рішення: який компонент регресував, чи існує виправлений випуск і як довго можна терпіти тимчасовий стан.

Зафіксуйте збій, перш ніж вибирати будь-що з двох

Оновлення ядра NetworkManager, оновлення плагіна VPN і регресія помічника резолвера виглядають однаково з місця користувача й мають різних кандидатів на відкат. Запишіть точні пакети, версії та першу нову помилку.

apt-cache policy network-manager network-manager-openvpn
dpkg -l | grep -E 'network-manager|openvpn|wireguard'

Метадані пакета можуть застаріти, якщо списки не оновлювалися, тому читайте їх як підказку й звіряйте з фактично встановленою версією. Не беріть цільову версію з допису на форумі; той самий рядок версії з іншого випуску може нести інший набір залежностей.

Порівняйте, що охоплює утримання

Утримання перешкоджає автоматичному встановленню, оновленню чи видаленню пакета. Але воно не заморожує його залежності, не ремонтує з'єднання й не робить старий бінарний файл безпечним. Саме ця прогалина і є всім порівнянням. Якщо регресія прийшла з бібліотеки, з якою пов'язаний клієнт, утримання клієнта нічого не змінює, поки бібліотека продовжує рухатися.

sudo apt-get -s install network-manager=1.42.4-1
apt-mark showhold

Спочатку змоделюйте зниження версії й прочитайте запропоновані зміни повністю. Зниження, яке видаляє залежність, потрібну робочому столу, — це інший інцидент, і моделювання — найдешевше місце, щоб його виявити. Якщо утримання справді правильна тимчасова межа, запишіть його як рішення з власником, причиною та умовою зняття. Утримання без власника стає постійною інфраструктурою, якої ніхто не наважується торкатися.

Порівняйте шляхи виходу

Шлях уперед — це виправлення від дистрибутива або постачальника, застосоване після перевірки на незалежному з'єднанні. Це тримає систему в підтримуваному потоці оновлень і закриває вразливість. Шлях міграції замінює клієнт або хост на те, що дистрибутив ще підтримує. Це більше роботи й часто єдина чесна відповідь, коли регресований компонент не має виправленого випуску в цій гілці.

sudo apt-mark unhold network-manager
sudo apt update
sudo apt full-upgrade

Який би вихід ви не обрали, перевірте точний профіль, шлях автентифікації, маршрути, поведінку DNS і повторне підключення, перш ніж оголосити готовим. Тунель, що піднімається один раз, — не те саме, що тунель, який витримує призупинення, зміну мережі та перезавантаження. Збережіть докази збою для звіту про помилку: версії пакетів, витяги з журналу, структуру профілю без секретів. Ніколи не додавайте приватні ключі чи облікові дані, щоб зробити звіт повнішим.

Що має містити запис

Запишіть рішення в чотири рядки: що регресувало, що було утримано або змінено, хто володіє тимчасовим станом і що його знімає. Додайте перевірку, яку ви виконали, бо наступний інженер її повторить.

Утримання з датою виходу — керована межа відкату. Утримання без неї — непояснене зниження версії, яке тихо стало частиною інфраструктури.