Обновления без страха: apt upgrade, который ничего не сломает

Часть 6 из 14 · Серия «Сервер в бою»

Админы маленьких серверов делятся на две секты. Первая живёт по завету «работает — не трогай»: их сервер не обновлялся два года, uptime 700 дней — предмет гордости, а в системе тем временем зияют дыры, под которые ботнеты из статьи про fail2ban давно имеют готовые эксплойты. Вторая секта жмёт «обновить всё» не глядя — и однажды вечером пятницы узнаёт, что вместе с обновлениями приехала новая минорная версия PHP, а с ней — неожиданности в проде.

Обе секты объединяет одно: страх, выросший из непонимания. apt upgrade кажется рулеткой, потому что непонятно, что именно он сделает. Сегодня разберём анатомию обновлений — чем upgrade отличается от full-upgrade и dist-upgrade (эта путаница сама по себе источник половины страхов), — выработаем ритуал безопасного обновления, поручим скучную часть автоматике unattended-upgrades и честно поговорим о самом страшном звере: переезде на новый релиз Ubuntu. Спойлер: иногда правильный ответ на «пора ли обновлять релиз» — «нет, пора переезжать на свежий сервер», и это не трусость, а стратегия.

Зачем вообще обновляться, если всё работает

Коротко, потому что аргумент один, но железный: безопасность. Подавляющее большинство взломов маленьких серверов — это не гений в капюшоне, а бот, который автоматически проверяет ваш IP на список известных уязвимостей. Известных — значит, уже исправленных: патч вышел, CVE опубликован, и с этого момента идёт гонка между вашим apt upgrade и чужим сканером. Не обновляться — значит добровольно проигрывать гонку, в которой участвуешь независимо от желания.

Есть и второй аргумент, бытовой: обновления не копятся бесплатно. Чем дольше пауза, тем больше пачка изменений, тем страшнее её накатывать — и тем сильнее хочется отложить ещё. Замкнутый круг, из которого через два года есть только один выход — миграция. Регулярные маленькие обновления — это как чистить зубы: скучно, зато без драматургии.

Анатомия: что на самом деле делают четыре команды

Главный источник страха — терминологическая каша. Разложим по полочкам, от безобидного к серьёзному.

apt update — не обновляет ничего. Только скачивает свежие списки пакетов: «узнать, что нового». Абсолютно безопасна, запускайте хоть каждый час. После неё полезно посмотреть, что предлагается:

apt list --upgradable

Вот он, момент осознанности: вместо рулетки — конкретный список. Пять строк про libssl и curl — одно дело; строка php8.3-fpm или mysql-server — другое, тут стоит притормозить и почитать, что в апдейте.

apt upgrade — обновляет установленные пакеты до новых версий, но никогда не удаляет пакеты и не ставит новые сверх зависимостей. Это его контракт и причина, почему регулярный apt upgrade в рамках одного релиза Ubuntu — операция консервативная: мажорные версии софта в стабильном релизе не меняются, в пакеты бэкпортируют в основном исправления безопасности.

apt full-upgrade (он же старый apt-get dist-upgrade — да, это одно и то же, и нет, это НЕ переход на новый релиз Ubuntu) — как upgrade, но с правом удалять пакеты, если того требует разрешение зависимостей. Нужен редко — обычно когда обновление ядра или крупная перестройка зависимостей не пролезает через обычный upgrade. Опасность не мифическая, но конкретная: перед выполнением он печатает список «The following packages will be REMOVED» — и вся техника безопасности сводится к тому, чтобы этот список прочитать, а не рефлекторно нажать Y. Если в удаляемых внезапно значится что-то жизненно важное — стоп, разбираемся.

do-release-upgrade — вот это и есть настоящий переезд: Ubuntu 22.04 → 24.04, обновление всего — ядра, PHP, MySQL, nginx, системных библиотек — на мажорные версии. Это не обновление, это трансплантация. О ней — отдельный разговор в конце.

Уже одно это разграничение снимает большую часть страха: ежедневная гигиена (update + upgrade) и трансплантация (do-release-upgrade) — операции разного порядка, и бояться первой из-за рисков второй — всё равно что бояться чистить зубы, потому что бывает удаление восьмёрок.

Что реально может сломаться (и как подстелить)

Честный список того, где обычный upgrade всё-таки умеет укусить.

Вопросы про конфиги. Если вы правили конфиг пакета руками (sshd_config, php.ini), а обновление несёт новую версию этого файла, dpkg остановится и спросит: оставить ваш или взять новый? Ответ по умолчанию — оставить свой (N), а новый вариант посмотреть потом (он сохранится рядом как .dpkg-dist). Рефлекторное «Y, установить версию мейнтейнера» на sshd_config — и ваш запрет парольного входа из третьей статьи уехал в историю. Читайте, что спрашивают.

Перезапуски сервисов. Обновление MySQL перезапустит MySQL — сайт моргнёт на секунды. Поэтому обновления с базой и PHP в списке — не в час пик. А ещё после обновления библиотек старые версии могут остаться в памяти работающих процессов — утилита needrestart (в свежих Ubuntu идёт из коробки) сама подскажет, кого перезапустить.

Ядро. Новое ядро вступает в силу только после перезагрузки. Сервер честно намекает файлом-флагом:

cat /var/run/reboot-required

Игнорировать месяцами — значит работать на старом ядре с известными дырами при формально «обновлённой» системе. Планируйте ребут в спокойное время — теперь, с мониторингом из четвёртой статьи, вы хотя бы сразу увидите, если сервер после перезагрузки не поднялся.

Отсюда — ритуал безопасного обновления, весь целиком:

# 1. Снапшот в панели VPS (одна кнопка, лучший страховой полис) — или свежий бэкап
# 2. Смотрим, что приедет
apt update && apt list --upgradable
# 3. Не в час пик — накатываем, читая вопросы
apt upgrade
# 4. Проверяем выживших
systemctl --failed
curl -sI https://ваш-сайт | head -1
# 5. Если просят — планируем ребут
cat /var/run/reboot-required 2>/dev/null

Пять минут. И заметьте, как сюда вплетается вся серия: снапшот — бэкапы, systemctl --failed — первая статья, а если что-то пошло не так — логи и journalctl -u имя-сервиса --since "10 min ago".

Unattended-upgrades: автопилот для скучной части

Ритуал хорош, но у него есть слабое место — вы. В отпуске, в запаре, в пятницу вечером — а критический патч OpenSSH не будет ждать вашего графика. Для этого существует unattended-upgrades: демон, который сам ставит обновления безопасности — и только их.

Ключевой страх — «автоматика мне что-нибудь сломает ночью» — лечится пониманием масштаба: security-обновления в стабильной Ubuntu — самые консервативные изменения из существующих, точечные патчи дыр без смены версий и поведения. Риск от них на порядки ниже риска ходить с известной дырой неделю. В свежих Ubuntu пакет уже установлен и включён; проверить и донастроить:

apt install unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades   # включить

Тонкая настройка — в /etc/apt/apt.conf.d/50unattended-upgrades. Три решения, которые стоит принять осознанно:

// 1. Источники: security — да; общие updates — на ваш вкус (я оставляю только security)
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};

// 2. Автоперезагрузка. На проде без кластера — НЕТ.
//    Пусть флаг reboot-required дождётся вас; либо, если сайт переживёт
//    минуту простоя в 4 утра, — задайте время явно:
Unattended-Upgrade::Automatic-Reboot "false";
// Unattended-Upgrade::Automatic-Reboot-Time "04:00";

// 3. Пакеты-исключения: то, что обновляете только руками
Unattended-Upgrade::Package-Blacklist {
    "mysql-server";
};

И последний штрих — знать, что автопилот вообще летает. Лог его работы: /var/log/unattended-upgrades/, а строчка в еженедельном осмотре сервера (или уведомление через Unattended-Upgrade::Mail) закрывает вопрос. Молчащая автоматика, в которую никто не заглядывает, имеет свойство молча ломаться — мы ещё вернёмся к этой мысли в статье про cron.

Итоговая схема разделения труда: безопасность — автоматом каждый день, остальное — руками по ритуалу раз в две-четыре недели. Страх ушёл, дыры закрываются за часы, сюрпризы — только читаные.

Do-release-upgrade: трансплантация, а не таблетка

Теперь о главном звере. Переход на новый релиз Ubuntu — это одновременное мажорное обновление сотен пакетов: другой PHP (прощай, ваш прод на 8.1, здравствуй 8.3 с её deprecated-сюрпризами в старом коде), другой MySQL, другой OpenSSL, другие дефолтные конфиги. На чистой системе процесс проходит гладко; на боевом сервере с трёхлетней историей ручных правок, сторонних репозиториев (PPA — первый кандидат всё сломать) и забытых зависимостей — как повезёт. А главное, обратной дороги нет: откат release-upgrade штатными средствами не предусмотрен, только восстановление из снапшота.

Когда он действительно нужен — критериев по-хорошему два:

1. Релиз приближается к концу поддержки. LTS-версии Ubuntu живут 5 лет стандартной поддержки. Пока релиз поддерживается, security-патчи приходят, и технической необходимости прыгать на новый LTS в день его выхода нет — наоборот, правило хорошего тона: подождать хотя бы до первого точечного выпуска (24.04.1 вместо 24.04.0), пока обкатают на энтузиастах. А вот когда до EOL остаётся полгода-год — пора планировать, потому что после EOL кончаются патчи, и вы автоматически вступаете в первую секту из начала статьи. Проверить свой статус: lsb_release -a и календарь релизов Ubuntu.

2. Вам нужен софт, которого нет в вашем релизе. Новый Laravel требует PHP новее, чем есть в репозитории, — типичный повод. Хотя и тут сначала стоит посмотреть на официальные докер-образы или проверенные сторонние репозитории — иногда точечное решение лучше трансплантации.

И вот честная развилка, к которой я вёл. Когда переезд на новый релиз назрел, у вас два пути:

Путь А: do-release-upgrade на месте. Снапшот обязателен, окно даунтайма закладывайте щедро, все вопросы про конфиги — читать. Подходит, когда сервер ухоженный, без экзотики, и вы готовы разбираться на живую.

Путь Б: новый VPS со свежим релизом + перенос. Поднимаете чистый сервер на актуальной LTS, разворачиваете окружение (заодно избавляясь от трёхлетних наслоений), переносите сайты, переключаете DNS. Старый сервер живёт параллельно как страховка — откат в любой момент за минуты. Для сервера с историей это почти всегда безопаснее и чище апгрейда на месте: вы получаете не «старый сервер с новыми пакетами», а действительно свежую систему.

Путь Б звучит сложнее, но на деле это просто миграция — а миграции без даунтайма целиком посвящён финал серии, четырнадцатая статья: TTL, rsync, репетиция переключения. После неё путь Б перестанет пугать окончательно.

Шпаргалка

Обновления перестают быть страшными ровно в тот момент, когда перестают быть загадочными: вы знаете, что приедет (apt list --upgradable), знаете, что может спросить система (конфиги — свои, список REMOVED — читать), у вас есть страховка (снапшот) и приборы (мониторинг, systemctl --failed). Дальше это просто гигиена.

А в следующей статье — смена жанра: от обороны к строительству. Разберём одну из самых частых причин, по которой люди вообще арендуют VPS, — собственный VPN. Поднимем WireGuard за полчаса, без магии и лишних скриптов: конфиги руками, с пониманием каждой строчки, подводные камни — по списку. Заодно наконец спрячем за VPN панель Netdata из четвёртой статьи, как и обещал.