Security updates на Linux VDS: unattended-upgrades, dnf-automatic и безопасная reboot policy

Инструкции
12 июл, 2026
Время на чтение: ~20 мин
Автор: AI (GPT 5)

Искусственный интеллект

Данная статья была создана с использованием искусственного интеллекта (GTP-5). Пожалуйста, имейте в виду, что текст может содержать неточности или ошибки.

Ручное обновление сервера удобно, пока сервер один, а у администратора есть привычка регулярно заходить по SSH и смотреть список security advisories. На практике уязвимости в OpenSSL, glibc, systemd, OpenSSH, nginx, Apache, PHP, ядре и библиотечных зависимостях появляются чаще, чем хочется, а окно между публикацией исправления и массовым сканированием интернета иногда измеряется часами. Поэтому automatic security updates на Linux VDS — не роскошь, а базовая гигиена.

Но автоматические обновления нужно включать аккуратно. Наша цель — ставить именно security updates, не превращать ночное обслуживание в неожиданный major upgrade и не перезагружать продакшен без политики. В этой инструкции разберем unattended-upgrades для Debian/Ubuntu, dnf-automatic для AlmaLinux/Rocky Linux/CentOS Stream/Oracle Linux и отдельно поговорим про reboot policy: когда перезагрузка нужна, как ее обнаружить и почему «автоматически ребутить всё подряд» часто хуже, чем кажется.

Что стоит автоматизировать, а что оставить под контролем

Автоматически обычно безопасно ставить обновления безопасности из официальных репозиториев дистрибутива. Это исправления CVE и критичных ошибок, которые сопровождаются мейнтейнерами ОС и не должны радикально менять поведение приложения. На Debian и Ubuntu за это отвечает связка apt и unattended-upgrades, на RHEL-based системах — dnf и dnf-automatic.

Не стоит бездумно автоматизировать обновления сторонних репозиториев, major/minor-апгрейды баз данных, переходы между ветками PHP, обновления самописных deb/rpm-пакетов и пакетов, которые критичны для бизнес-логики. Например, автоматический апгрейд PostgreSQL между major-версиями обычно не произойдет через штатные репозитории, но сторонние репозитории и vendor-пакеты могут вести себя по-разному. Для таких компонентов лучше иметь отдельный регламент: staging, бэкап, тест миграций, окно обслуживания.

Хорошая модель для Linux VDS: security updates применяются автоматически, обычные updates проходят по расписанию вручную или через Ansible/CI, а reboot выполняется по понятной политике и с мониторингом.

Перед включением автообновлений проверьте три вещи. Во-первых, на сервере должны быть рабочие бэкапы и понятная процедура восстановления. Во-вторых, нужно знать, какие репозитории подключены и нет ли там экспериментальных веток. В-третьих, сервер должен переживать перезапуск служб: systemd units должны корректно стартовать после reboot, сайты — подниматься без ручного ввода паролей, а монтирования в /etc/fstab не должны блокировать загрузку.

Debian и Ubuntu: настройка unattended-upgrades

В Debian и Ubuntu пакет unattended-upgrades умеет ежедневно обновлять списки пакетов, выбирать разрешенные источники обновлений, устанавливать патчи и вести отдельные логи. Обычно он уже установлен в облачных образах Ubuntu, но лучше проверить явно.

Установка пакетов

apt update
apt install unattended-upgrades apt-listchanges needrestart
systemctl status unattended-upgrades --no-pager

apt-listchanges полезен для просмотра changelog перед ручными обновлениями, а needrestart помогает понять, какие службы используют старые версии библиотек и требуется ли reboot. На минимальных VDS эти пакеты часто отсутствуют.

На Ubuntu можно включить базовую конфигурацию через интерактивный помощник:

dpkg-reconfigure unattended-upgrades

Если вы управляете сервером через Ansible или просто хотите видеть все настройки явно, удобнее отредактировать файлы вручную.

Файл периодичности APT

Создайте или проверьте файл /etc/apt/apt.conf.d/20auto-upgrades:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";

Первая строка включает ежедневное обновление индексов пакетов, вторая — запуск unattended-upgrades, третья — периодическую очистку старого кеша. Для большинства VDS этого достаточно.

Разрешенные источники обновлений

Основная конфигурация находится в /etc/apt/apt.conf.d/50unattended-upgrades. В Debian и Ubuntu отличаются имена origin/label, поэтому проверьте файл под свой дистрибутив, а не копируйте слепо из случайной заметки.

Для Ubuntu типичный фрагмент выглядит так:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
        "${distro_id}ESMApps:${distro_codename}-apps-security";
        "${distro_id}ESM:${distro_codename}-infra-security";
};

Строки ESM имеют смысл, если сервер действительно подключен к Ubuntu Pro/ESM. Если нет — они не дадут дополнительных обновлений, но обычно и не мешают. Для обычного сервера без ESM ключевая строка — ${distro_codename}-security.

Для Debian 12/13 чаще встречается такой подход через Origins-Pattern:

Unattended-Upgrade::Origins-Pattern {
        "origin=Debian,codename=${distro_codename},label=Debian-Security";
        "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
};

В разных релизах Debian названия security suite могли отличаться, поэтому после настройки обязательно выполните dry-run и посмотрите, какие пакеты реально выбраны. Если сервер давно живет и переживал upgrade дистрибутива, особенно важно проверить, что в /etc/apt/sources.list и /etc/apt/sources.list.d/ нет старых codename.

Автоматическая очистка и запрет неожиданного reboot

В этом же файле задайте поведение после установки пакетов. Для веб-сервера и базы данных я обычно начинаю с запрета автоматической перезагрузки:

Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "04:30";

Параметр Automatic-Reboot-Time не сработает, пока Automatic-Reboot равен false, но я все равно задаю его заранее: если в будущем команда решит разрешить auto reboot, время уже будет явно указано. На одиночном VDS с критичным сайтом лучше не включать reboot без внешней проверки доступности и без понимания, кто получит уведомление, если сервер не вернется.

Проверка unattended-upgrades

Сначала запустите тестовый прогон. Он не должен устанавливать пакеты, зато покажет много полезной диагностики по origin, blacklist и выбранным обновлениям.

unattended-upgrade --dry-run --debug

Затем проверьте таймеры APT. В современных Debian/Ubuntu обновления запускаются через systemd timers, а не через классический cron.

systemctl list-timers apt-daily.timer apt-daily-upgrade.timer
journalctl -u apt-daily-upgrade.service -n 100 --no-pager
tail -n 100 /var/log/unattended-upgrades/unattended-upgrades.log

Если вы хотите сузить окно запуска, настройте override для apt-daily-upgrade.timer. Например, чтобы апгрейды стартовали ночью с небольшим случайным разбросом:

systemctl edit apt-daily-upgrade.timer

[Timer] 
RandomizedDelaySec=30m
Persistent=true

systemctl daemon-reload
systemctl restart apt-daily-upgrade.timer
systemctl list-timers apt-daily-upgrade.timer

Случайная задержка полезна даже на одном сервере: она снижает шанс попасть ровно в момент ночного бэкапа, cron-задачи или пересборки кеша. На группе VDS она дополнительно предотвращает одновременный апгрейд всех узлов.

Логи пакетного менеджера и таймеры systemd для автоматических обновлений

AlmaLinux, Rocky Linux и другие RHEL-based: dnf-automatic

В AlmaLinux, Rocky Linux, CentOS Stream и Oracle Linux для автоматического обновления используется dnf-automatic. Важная особенность: режим security зависит от метаданных безопасности в репозиториях. Официальные репозитории RHEL-compatible дистрибутивов обычно такие данные предоставляют, а сторонние репозитории могут не помечать обновления как security. Это не ошибка dnf-automatic, а свойство конкретного репозитория.

Установка и выбор таймера

dnf install dnf-automatic
systemctl list-unit-files "dnf-automatic*.timer"

На большинстве актуальных систем есть несколько таймеров: только уведомлять, только скачивать, устанавливать обновления. Для сервера, где нужно применять security updates автоматически, обычно выбирают install timer.

systemctl enable --now dnf-automatic-install.timer
systemctl list-timers "dnf-automatic*.timer"

Если в вашем образе есть только dnf-automatic.timer, используйте его и проверьте поведение в /etc/dnf/automatic.conf. Названия таймеров могут немного отличаться между релизами, поэтому команда systemctl list-unit-files здесь надежнее памяти.

Конфигурация security-only обновлений

Откройте /etc/dnf/automatic.conf и проверьте секцию [commands]:

[commands]
upgrade_type = security
random_sleep = 900
download_updates = yes
apply_updates = yes
reboot = never
reboot_command = shutdown -r +5 'Rebooting after applying package updates'

upgrade_type = security говорит устанавливать только обновления безопасности. random_sleep добавляет случайную задержку в секундах. apply_updates = yes разрешает установку, иначе обновления будут только скачаны или показаны в уведомлениях, в зависимости от выбранного таймера и секций emitters.

Параметр reboot = never — осознанный выбор для большинства продакшен VDS. У dnf-automatic есть режимы автоматической перезагрузки, но включать их стоит только после проверки, что сервер корректно загружается без ручного вмешательства, а приложение имеет health check и внешний мониторинг.

Проверка security metadata и логов

Посмотрите, видит ли DNF обновления безопасности:

dnf updateinfo list security
dnf updateinfo summary

Если список пустой, это не всегда означает проблему. Возможно, обновлений безопасности сейчас нет. Но если вы точно знаете о свежем advisory, проверьте подключенные репозитории и их метаданные.

dnf repolist
dnf automatic --debug
journalctl -u dnf-automatic-install.service -n 100 --no-pager

На CentOS Stream нужно учитывать rolling-характер потока обновлений: пакеты приходят иначе, чем в AlmaLinux/Rocky Linux. Это не делает dnf-automatic бесполезным, но для консервативного продакшена лучше особенно внимательно смотреть на репозитории и тестировать обновления на staging.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Reboot policy: когда перезагружать Linux VDS

Патч установлен — это еще не всегда значит, что уязвимый код перестал работать. Если обновилась библиотека, процесс может продолжать держать старую версию в памяти. Если обновилось ядро, новое ядро начнет работать только после reboot. Поэтому политика перезагрузок — такая же часть security updates, как и сама установка пакетов.

Есть три распространенные стратегии. Первая — никогда не перезагружать автоматически, а только создавать сигнал для администратора. Это безопасно для доступности, но требует дисциплины. Вторая — автоматически перезагружать в ночное окно, если ОС явно просит reboot. Это подходит для некритичных одиночных серверов и внутренних сервисов. Третья — rolling reboot: сначала вывести узел из балансировщика, обновить, перезагрузить, проверить health check и только потом перейти к следующему. Для группы VDS это лучший вариант.

Как понять, что reboot нужен в Debian/Ubuntu

После обновления пакетов Debian/Ubuntu часто создают файл /var/run/reboot-required. Посмотреть причину можно так:

test -f /var/run/reboot-required && cat /var/run/reboot-required
test -f /var/run/reboot-required.pkgs && cat /var/run/reboot-required.pkgs
needrestart -r l

needrestart дополнительно покажет службы, которые используют старые библиотеки. Иногда достаточно перезапустить конкретный сервис, например PHP-FPM или nginx, но при обновлении ядра, glibc и низкоуровневых компонентов лучше планировать reboot.

Как понять, что reboot нужен в AlmaLinux/Rocky Linux

Для RHEL-based систем удобна утилита needs-restarting из пакета dnf-utils:

dnf install dnf-utils
needs-restarting -r

Код возврата у команды полезен для автоматизации: если reboot нужен, команда сообщает об этом и возвращает ненулевой статус. Это удобно использовать в Ansible, shell-скриптах и системах мониторинга.

Практичная политика для одиночного веб-сервера

Для одного Linux VDS с nginx/Apache, PHP-FPM и базой данных разумная политика может выглядеть так: security updates ставятся автоматически каждую ночь; reboot автоматически не выполняется; утром или в отдельное окно мониторинг показывает флаг «требуется перезагрузка»; администратор проверяет бэкап, нагрузку и выполняет reboot вручную. Если проект допускает короткий простой ночью, можно разрешить автоматический reboot, но только после нескольких успешных ручных перезагрузок и проверки консоли провайдера.

Перед перезагрузкой полезно выполнить короткий чек-лист:

убедиться, что есть свежий бэкап или снимок;
проверить свободное место на /, /boot и разделах с данными;
посмотреть, нет ли зависших обновлений apt/dnf;
проверить, что важные сервисы включены в автозагрузку;
иметь доступ к rescue/console на случай проблем с сетью или boot.

df -h
systemctl --failed
systemctl is-enabled nginx
systemctl is-enabled php-fpm
systemctl is-enabled mariadb
systemctl is-enabled postgresql

Команды для служб нужно адаптировать под ваш стек: на Debian PHP-FPM юниты называются вроде php8.3-fpm, на RHEL-based системах часто используется php-fpm. Если на сервере несколько версий PHP, заранее проверьте, что нужные пулы стартуют после reboot; подробнее о такой схеме можно прочитать в материале про несколько PHP-FPM пулов за nginx.

Сам reboot лучше запускать явно и с сообщением:

shutdown -r 04:30 'Planned reboot after security updates'

Если нужно перезагрузить сразу:

systemctl reboot

После возврата сервера проверьте ядро, uptime, failed units и доступность приложения:

uname -r
uptime
systemctl --failed
ss -lntp

Чек-лист безопасной перезагрузки Linux сервера в терминале

Логи, уведомления и контроль изменений

Автообновления без логов превращаются в «черный ящик»: вроде что-то работало ночью, но непонятно, что именно установилось. Минимум — регулярно смотреть системный журнал и отдельные логи пакетного менеджера.

Для Debian/Ubuntu:

tail -n 200 /var/log/unattended-upgrades/unattended-upgrades.log
tail -n 200 /var/log/apt/history.log
journalctl -u unattended-upgrades -n 100 --no-pager
journalctl -u apt-daily-upgrade.service -n 100 --no-pager

Для AlmaLinux/Rocky Linux и других RHEL-based систем:

journalctl -u dnf-automatic-install.service -n 200 --no-pager
tail -n 200 /var/log/dnf.log
tail -n 200 /var/log/dnf.rpm.log

Если на сервере настроена почта для системных уведомлений, можно включить email-отчеты. Но на многих VDS локальный MTA не настроен, а письма от root уходят в никуда. В таком случае лучше собирать события в централизованные логи или мониторинг: например, алертить по наличию /var/run/reboot-required, по ошибкам unit-ов apt-daily-upgrade.service/dnf-automatic-install.service и по факту давно не выполнявшихся обновлений.

Полезная метрика для регламента: «сколько дней сервер живет с требуемым reboot». Если ядро безопасности поставлено неделю назад, но сервер всё еще работает на старом ядре, формально патч установлен, а фактически риск остается. Для инфраструктуры с несколькими VDS это быстро становится заметной проблемой.

Типовые ошибки и как их избежать

Первая ошибка — включить автоматические обновления всех репозиториев. На Debian/Ubuntu это может случиться, если добавить в Allowed-Origins обычные updates/backports без понимания последствий. На RHEL-based системах похожий эффект возможен при upgrade_type = default. Для начала держитесь security-only режима.

Вторая ошибка — не учитывать lock пакетного менеджера. Если ночью у вас уже идет backup, сборка контейнеров, ручной apt upgrade или другой automation, задания могут конфликтовать. Разведите расписания: бэкапы отдельно, package updates отдельно, тяжелые cron-задачи отдельно.

Третья ошибка — запретить reboot навсегда. Это выглядит безопасно для uptime, но плохо для безопасности. Запрет automatic reboot должен сопровождаться алертом и регулярным окном обслуживания. Иначе сервер годами копит обновленные, но не активированные ядра.

Четвертая ошибка — забыть про staging. Даже security update иногда может изменить поведение. Особенно это касается библиотек TLS, драйверов, контейнерного runtime, модулей веб-сервера и языковых рантаймов. Если у проекта есть staging VDS, включите там такую же схему обновлений раньше продакшена и смотрите, что происходит.

Пятая ошибка — не проверять загрузку после изменений в /etc/fstab, сетевых настройках, firewall и systemd units. Automatic security updates редко ломают boot сами по себе, но reboot после них может выявить старую ошибку конфигурации, которая месяцами была незаметна на работающем сервере. Если перед включением автообновлений вы меняете файловую систему или параметры монтирования, пригодится отдельная инструкция по настройке ext4 и XFS на VDS.