Системный журнал — практичная база знаний по VPS и Linux
Системный журнал Системный журнал
Linux • Debian • Ubuntu • обновления • Безопасность

Автоматические обновления безопасности Debian и Ubuntu без неожиданных перезагрузок

5 мин чтения Урок 6 из 6

Автоматическая установка security-обновлений сокращает время между выпуском исправления и его применением. Но режим «установить всё и сразу перезагрузить» опасен для продакшена. Хорошая конфигурация обновляет только разрешённые источники, ведёт журнал, не перезагружает сервер неожиданно и регулярно проверяется вручную.

Что делает unattended-upgrades

Пакет выбирает обновления из разрешённых источников APT и устанавливает их без интерактивного диалога. Запуск обычно выполняют systemd timers apt-daily.timer и apt-daily-upgrade.timer. Точное время может иметь случайную задержку, чтобы тысячи серверов не обращались к зеркалам одновременно.

Это не замена полноценному обслуживанию. Администратор всё равно должен контролировать отложенные пакеты, перезагрузки, ошибки служб и обновление между версиями ОС.

Установите необходимые пакеты

sudo apt update
sudo apt install unattended-upgrades apt-listchanges

Включите базовую конфигурацию:

sudo dpkg-reconfigure -plow unattended-upgrades

Проверьте созданные файлы:

ls -l /etc/apt/apt.conf.d/20auto-upgrades \
      /etc/apt/apt.conf.d/50unattended-upgrades

Настройте периодический запуск

Файл /etc/apt/apt.conf.d/20auto-upgrades обычно содержит:

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

Значение 1 означает ежедневную проверку. Не добавляйте собственный cron поверх systemd timers без необходимости: параллельные процессы APT создают блокировки и усложняют диагностику.

Проверьте разрешённые источники

Основные правила находятся в 50unattended-upgrades. Формат различается между Debian и Ubuntu, поэтому не копируйте файл целиком с другой системы. Посмотрите фактическую конфигурацию:

sudo unattended-upgrade --dry-run --debug

В отладочном выводе видно, какие origins разрешены и какие пакеты будут выбраны. По умолчанию на сервере разумно автоматически ставить security-обновления, а обычные обновления устанавливать в плановое окно после просмотра.

Создайте отдельный локальный файл

Чтобы не редактировать пакетный файл, добавьте настройки в файл с более поздним номером:

sudoedit /etc/apt/apt.conf.d/52unattended-upgrades-local

Безопасный базовый вариант:

Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::SyslogEnable "true";

Автоматическую перезагрузку на одиночном VPS лучше оставить выключенной, пока нет мониторинга, окна обслуживания и проверки доступности приложения после старта.

Исключения для чувствительных пакетов

Пакеты можно временно поместить в blacklist:

Unattended-Upgrade::Package-Blacklist {
    "docker-ce";
    "mariadb-server";
};

Однако постоянный blacklist создаёт долг безопасности. Для долгой фиксации версии используйте осознанную политику обновления и регулярно пересматривайте исключения.

Проверьте пакеты в hold:

apt-mark showhold

Добавить и снять hold:

sudo apt-mark hold package-name
sudo apt-mark unhold package-name

Проверка в dry-run

sudo unattended-upgrade --dry-run --debug

Dry-run должен завершиться без ошибок репозиториев и показать ожидаемый набор пакетов. Обратите внимание на:

  • неподписанные или недоступные репозитории;
  • пакеты, которые не разрешено обновлять;
  • конфликты зависимостей;
  • попытки установить пакет из стороннего origin.

Запустите один реальный цикл вручную

sudo unattended-upgrade --verbose

Затем проверьте:

sudo tail -n 200 /var/log/unattended-upgrades/unattended-upgrades.log
sudo tail -n 200 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
systemctl --failed

На системе без файловых журналов события могут быть доступны через journald:

sudo journalctl -u unattended-upgrades --since today --no-pager

Проверьте systemd timers

systemctl list-timers 'apt-daily*' --all
systemctl status apt-daily.timer apt-daily-upgrade.timer --no-pager

Не ожидайте запуск строго в указанную минуту: службы APT используют случайную задержку. Это нормальное поведение.

Посмотреть последние выполнения:

journalctl -u apt-daily.service \
  -u apt-daily-upgrade.service \
  --since '-7 days' --no-pager

Контроль перезагрузки

Проверьте запрос перезагрузки:

if test -f /var/run/reboot-required; then
  cat /var/run/reboot-required
  cat /var/run/reboot-required.pkgs 2>/dev/null
fi

Лучше отправлять этот факт в мониторинг и перезагружать сервер в согласованное окно. Если автоматическая перезагрузка действительно нужна:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:30";

Такой режим допустим только когда:

  • сервисы автоматически стартуют и проверены после reboot;
  • есть внешний health-check;
  • данные приложений корректно завершают работу;
  • время указано в правильной системной зоне;
  • доступна консоль провайдера.

Почтовые уведомления

Если на сервере настроен локальный почтовый транспорт, можно указать адрес:

Unattended-Upgrade::Mail "admin@example.net";
Unattended-Upgrade::MailReport "only-on-error";

Не считайте уведомления работающими, пока не проверена реальная доставка наружу. На сервере без MTA лучше отправлять метрики и результат выполнения в существующую систему мониторинга.

Сторонние репозитории

Docker, NodeSource, MariaDB и другие репозитории имеют собственные origins. Не разрешайте их автоматическое обновление простым шаблоном *. Сначала изучите:

apt-cache policy
grep -R --no-filename -h '^deb ' \
  /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null

Сторонние пакеты лучше обновлять в отдельном контролируемом окне, особенно если они запускают миграции или перезапускают приложение.

Контроль после автоматического обновления

Минимальный ежедневный контроль:

systemctl --failed
test -f /var/run/reboot-required && echo REBOOT_REQUIRED
grep -E 'ERROR|WARNING' \
  /var/log/unattended-upgrades/unattended-upgrades.log | tail

Для веб-сервера добавьте внешнюю проверку HTTPS и критичного endpoint. Успешная работа APT не означает, что приложение пережило перезапуск библиотеки или службы.

Типовые проблемы

APT постоянно заблокирован

Проверьте одновременно работающие timers, cron и ручные скрипты:

ps aux | grep -E '[a]pt|[d]pkg'
systemctl list-timers 'apt-*' --all
grep -R "apt .*upgrade" /etc/cron* /var/spool/cron 2>/dev/null

Обновления не устанавливаются

Запустите dry-run с debug и проверьте разрешённые origins. Часто пакет относится не к security-репозиторию или удерживается зависимостями.

Службы используют старые библиотеки

Установите и запускайте needrestart в плановом обслуживании:

sudo apt install needrestart
sudo needrestart

Не включайте автоматический перезапуск всех служб без тестирования приложения.

Рекомендуемая политика для небольшого VPS

  1. Ежедневно автоматически обновлять списки и устанавливать security-пакеты.
  2. Не выполнять автоматическую перезагрузку.
  3. Отправлять ошибку и требование reboot в мониторинг.
  4. Раз в неделю просматривать обычные обновления и отложенные пакеты.
  5. Раз в месяц проверять dry-run, логи и список исключений.
  6. Перед обновлением базы данных, контейнерной платформы или крупного приложения создавать проверенную резервную копию.

Итог

Безопасная автоматизация должна быть предсказуемой и наблюдаемой. Ограничьте источники security-репозиториями, сначала выполните dry-run, запретите неожиданный reboot, проверяйте журналы и связывайте результат с внешним мониторингом. Тогда unattended-upgrades снижает риск, а не создаёт новый.