Оновлення ОС на VDS закриває відомі вразливості, але невдале оновлення на віддаленому сервері може лишити вас без доступу. Різниця між apt upgrade і do-release-upgrade — це різниця між рутинною операцією і подією, яку варто планувати заздалегідь.
Оновлення пакетів (Ubuntu/Debian)
# Оновити перелік пакетів з репозиторіїв
apt update
# Оновити всі пакети без видалення наявних
apt upgrade -y
# Оновити із заміною конфігів і можливим видаленням пакетів
apt full-upgrade -y
# Прибрати пакети, які більше не потрібні як залежності
apt autoremove -yРізниця між upgrade і full-upgrade принципова: перший ніколи не видаляє встановлені пакети, навіть якщо для нової версії залежності вимагають інакше, і в такому разі просто не оновить пакет із конфліктом. Другий дозволяє видалення заради розв'язання залежностей — тому запускати його треба свідомо, дивлячись на список дій перед підтвердженням.
Оновлення дистрибутива
# Ubuntu 20.04 → 22.04, найсвіжіша LTS на момент переходу
do-release-upgrade
# Debian: акуратний шлях через зміну джерел
sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list
apt update && apt full-upgrade -yВ Ubuntu do-release-upgrade сам перевіряє доступність нової LTS, завантажує пакети і переносить конфіги відомих сервісів. У Debian окремої утиліти немає: перехід на новий реліз — це заміна кодової назви в джерелах пакетів і повний full-upgrade, тому ризик конфліктів конфігурації вищий і перевіряти їх треба вручну.
Розбір типових помилок під час оновлення
Помилка E: Unable to correct problems, you have held broken packages означає, що частина пакетів зафіксована (apt-mark hold) або конфліктує за версіями залежностей. Перевірте список зафіксованих пакетів командою apt-mark showhold і зніміть фіксацію перед оновленням, якщо вона не потрібна навмисно.
dpkg: dependency problems prevent configuration of package-name:
package-name depends on libssl3 (>= 3.0.0); however:
Version of libssl3 on system is 1.1.1.Така помилка найчастіше виникає при змішуванні репозиторіїв різних релізів — наприклад, якщо у sources.list лишилися рядки від старої версії дистрибутива поруч із новими. Рішення — перевірити /etc/apt/sources.list і файли в /etc/apt/sources.list.d/ на предмет старої кодової назви релізу.
Розірване з'єднання SSH під час do-release-upgrade раніше означало обрив процесу оновлення. Починаючи із сучасних версій утиліта сама піднімає резервний SSH-демон на альтернативному порту (зазвичай 1022) на час апгрейду — але покладатися на це не варто: безпечніше виконувати оновлення в screen або tmux, щоб сесія пережила розрив каналу.
Порівняння способів оновлення
| Спосіб | Що змінює | Ризик простою | Коли застосовувати |
|---|---|---|---|
| apt upgrade | Мінорні версії пакетів | Низький | Регулярно, раз на 1–2 тижні |
| apt full-upgrade | Пакети зі зміною залежностей | Середній | Після security-бюлетеня, перед великим релізом |
| do-release-upgrade | Весь дистрибутив (Ubuntu) | Високий | Перехід на нову LTS раз на 1–2 роки |
| Зміна кодової назви (Debian) | Весь дистрибутив (Debian) | Високий | Перехід на новий стабільний реліз |
Важливо перед оновленням
- Створіть знімок (snapshot) сервера в панелі керування — це єдиний швидкий шлях назад, якщо оновлення дистрибутива зламає завантаження.
- Оновлюйте в період низького навантаження і попередьте користувачів сервісу заздалегідь, якщо апгрейд дистрибутива — не рутинний
apt upgrade. - Перевірте версії критичних сервісів (PHP, MySQL, Nginx) до оновлення — мажорний апгрейд ОС часто тягне за собою мажорний апгрейд і цих пакетів, а це окрема міграція конфігів.
- Після оновлення перезавантажте сервер і перевірте, що всі потрібні сервіси стартують автоматично, а не лише поточний, не перезапущений процес.
Коли оновлення краще відкласти або робити інакше
Мажорний апгрейд дистрибутива не варто запускати наосліп у таких випадках:
- Сервер тримає продакшн-навантаження без резервного вузла — краще спочатку прогнати апгрейд на клоні (знімку, піднятому як окремий VDS), а вже потім на бойовому.
- Використовуються пакети зі сторонніх PPA чи репозиторіїв, зібрані під конкретну версію дистрибутива, — після апгрейду вони можуть перестати розв'язувати залежності або просто зникнути зі списку доступних.
- Немає актуального бекапу бази даних — міграція MySQL чи PostgreSQL на нову мажорну версію в рамках апгрейду ОС може вимагати окремого експорту й імпорту дампа.
Перевірка результату
- Перевірте версію релізу:
lsb_release -aабоcat /etc/os-releaseмають показувати очікувану версію. - Перевірте статус ключових сервісів:
systemctl status nginx mysql php8.2-fpm— усі мають бутиactive (running), а не просто встановлені. - Перевірте журнал ядра на помилки після перезавантаження:
dmesg | grep -i error. - Відкрийте сайт чи застосунок ззовні і переконайтеся, що він відповідає так само, як до оновлення, — версія PHP чи MySQL могла змінитися і вплинути на поведінку коду.
Якщо оновлення зачіпає ядро і після перезавантаження хочеться переконатися, що завантажилося саме нове ядро, — команда uname -r покаже версію, а деталі перезбирання модулів розібрані в статті про оновлення ядра Linux. Файрвол після зміни релізу варто перевірити окремо — іноді пакет UFW оновлюється зі зміною значень за замовчуванням, це описано в статті про налаштування UFW на VDS.
Часті питання
Чи обов'язкове перезавантаження після кожного apt upgrade, чи лише коли оновилося ядро?
Після звичайного оновлення пакетів перезавантаження не є обов'язковим — більшості сервісів досить перезапустити власний процес, і пакетний менеджер часто робить це сам. Перезавантаження стає потрібним лише тоді, коли змінюється ядро, systemd чи деякі базові бібліотеки: вони лишаються завантаженими в пам'ять до перезапуску всієї системи, а не окремого сервісу.
Якщо full-upgrade хоче видалити пакет, який насправді ще потрібен, що безпечніше зробити замість простого підтвердження?
Зупиніться і прочитайте перелік запланованих видалень, перш ніж щось підтверджувати, а тоді перевірте, чи не закріплений пакет і від чого залежить заміна. Часто безпечніше напряму розв'язати конфлікт залежностей або відкласти саме цей крок оновлення, ніж дозволити інструменту видалити пакет, на який сервер і далі спирається у щоденній роботі.
Чи відкочує відновлення знімка сервера, знятого до великого оновлення, і зміни в базі даних, зроблені пізніше?
Так, повний знімок сервера фіксує стан усього диска в той момент, включно з базами даних, тому відновлення відкочує все разом, а не лише файли операційної системи. Будь-які дані, записані після знімка, включно з новими рядками в базі, зникають разом із відкотом оновлення — саме тому для всього, що пишеться в цей проміжок, важливий окремий, свіжіший бекап бази.
Чи означає регулярне оновлення пакетів, що патчі безпеки застосовуються самі собою, чи запускати оновлення вручну все одно треба щоразу?
Регулярні оновлення пакетів усе одно треба запускати свідомо, а не чекати, що все станеться само собою — ніщо не латає сервер автоматично лише тому, що нова версія з'явилася в репозиторії. Саме перетворення цього на рутинне завдання за передбачуваним розкладом закриває відомі вразливості вчасно, адже оновлення, яке лежить незастосованим у репозиторії, узагалі не захищає сервер, що працює.