Unattended-upgrades на Debian/Ubuntu: автообновления без простоев и сюрпризов

Автоматические обновления на сервере — это баланс между безопасностью и предсказуемостью. С одной стороны, уязвимости требуют оперативного закрытия, с другой — внезапные перезапуски сервисов и изменения конфигураций могут стоить простоя. В экосистеме Debian/Ubuntu для автоматизации обновлений используется связка APT::Periodic и утилита unattended-upgrades. В этой статье рассмотрим практическую настройку: от установки и минимального рабочего конфига до безопасной интеграции с needrestart, правил автоперезагрузки, исключения критичных пакетов через hold/pinning и грамотной диагностики.

Что такое unattended-upgrades и как оно работает

unattended-upgrades — это инструмент, запускаемый системными таймерами APT (systemd), который устанавливает доступные обновления согласно политике APT и правилам «разрешённых источников» (Origins-Pattern). Чаще всего его включают хотя бы для security-обновлений. Процесс:

• Обновление индекса пакетов по расписанию (apt-daily.timer).
• Запуск апгрейда (apt-daily-upgrade.timer), который передаёт управление unattended-upgrades.
• Проверка и установка подходящих обновлений; при необходимости — перезапуски служб (через needrestart) и опционально — перезагрузка сервера.

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

Установка и включение

На свежих Ubuntu часто достаточно включить security-обновления при установке системы, но мы рассмотрим универсальный путь для Debian/Ubuntu.

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

Далее можно запустить интерактивный конфигуратор:

sudo dpkg-reconfigure --priority=low unattended-upgrades

Или включить периодические задания вручную в /etc/apt/apt.conf.d/20auto-upgrades:

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

Этого достаточно, чтобы обновления security начали приходить (при корректной настройке источников в /etc/apt/sources.list). Но поведение и перечень источников управляются в /etc/apt/apt.conf.d/50unattended-upgrades.

Настройка источников: только security или шире

Ключевой блок — Unattended-Upgrade::Origins-Pattern. Он определяет, какие репозитории разрешены для автообновления. Примеры:

Ubuntu (рекомендуется для production)

Unattended-Upgrade::Origins-Pattern {
  "o=Ubuntu,a=${distro_codename}-security";
  // При необходимости включите обновления из -updates (более рискованно)
  // "o=Ubuntu,a=${distro_codename}-updates";
};

Debian (stable)

Unattended-Upgrade::Origins-Pattern {
  "o=Debian,a=stable";
  "o=Debian,a=stable-updates";
  "o=Debian,codename=${distro_codename},label=Debian-Security";
};

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

Политика перезапусков: needrestart и предсказуемость

После обновлений библиотек и демонов needrestart решает, что требуется перезапустить. В интерактивном режиме на серверах это неудобно, поэтому зададим политику без вопросов в /etc/needrestart/needrestart.conf:

$nrconf{restart} = 'a';

Варианты:

• 'a' — автоматически перезапускать затронутые сервисы (подходит для большинства веб-серверов и приложений, если у вас есть healthchecks и оркестрация),
• 'l' — перезапускать только те процессы, что можно перезапустить «мягко» (менее агрессивно),
• 'i' — интерактивный режим (обычно неприемлемо для unattended),
• 'q' — ничего не спрашивать и не перезапускать (требуется ручной follow-up).

Проверьте, как перезапуски влияют на SLA: например, перезапуск php-fpm штатно прозрачен, а вот redis или postgresql требуют синхронных процедур и согласованных окон.

Автоперезагрузка после обновлений ядра

Некоторые обновления требуют reboot (создаётся файл /var/run/reboot-required). unattended-upgrades может перезагрузить систему автоматически по расписанию. В /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:30";
// Разрешить перезагрузку даже при наличии залогиненных пользователей
// Unattended-Upgrade::Automatic-Reboot-WithUsers "true";

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Исключения: чёрный список пакетов и hold/pinning

Для некоторых пакетов автоматические обновления нежелательны (базы данных, критичный proxy, специфичный драйвер). Есть три уровня контроля, от самого простого к самому строгому.

Чёрный список unattended-upgrades

В /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Package-Blacklist {
  "linux-image*";
  "grub*";
  "postgresql*";
};

Минус: запрет действует только для unattended, вручную вы всё так же сможете обновить.

apt-mark hold

sudo apt-mark hold linux-image-generic grub-pc
apt-mark showhold
# Снять блокировку
sudo apt-mark unhold linux-image-generic grub-pc

apt-mark hold блокирует апгрейд пакета вообще (и ручной, и автоматический), пока не снимете hold. Просто и эффективно, но требует дисциплины, чтобы не забыть о критичных патчах безопасности.

Pinning в /etc/apt/preferences.d

Тонкий контроль при помощи приоритетов:

sudo tee /etc/apt/preferences.d/99-local-pin > /dev/null << 'EOF'
Package: linux-image*
Pin: release o=Ubuntu
Pin-Priority: -1

Package: postgresql*
Pin: release o=Debian
Pin-Priority: -1
EOF

Здесь мы запрещаем установку/обновление пакетов из указанных origin. Это мощный инструмент, но легко сделать «слишком жёстко» — используйте точечные правила и проверяйте apt-cache policy.

Удаление мусора и старых ядер

Чтобы не накапливать старые ядра и зависимости, включите опции очистки:

Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";

Это особенно полезно на маленьких дисках и при длительной жизни инстансов.

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

Если у вас есть локальный MTA (например, postfix в режиме local), можно включить письма об обновлениях:

Unattended-Upgrade::Mail "root";
Unattended-Upgrade::MailOnlyOnError "true";

Альтернатива — централизованные логи и алерты из системного журнала.

Где логируются автообновления и как дебажить

Основной лог:

sudo tail -n 200 /var/log/unattended-upgrades/unattended-upgrades.log

Журналы systemd и таймеров APT:

sudo journalctl -u apt-daily.service -u apt-daily-upgrade.service -u unattended-upgrades.service -n 200

Проверить таймеры и ближайшие срабатывания:

systemctl list-timers | grep apt

Сухой прогон unattended-upgrades с повышенной подробностью:

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

Тонкие настройки APT::Periodic и поведения апгрейда

Дополнительные полезные параметры в 50unattended-upgrades:

• Unattended-Upgrade::AutoFixInterruptedDpkg "true"; — попытаться автоматически исправлять прерванные транзакции dpkg.
• Unattended-Upgrade::MinimalSteps "true"; — разбивать апгрейд на минимальные шаги, уменьшая риск долгих блокировок.
• Unattended-Upgrade::OnlyOnACPower "true"; — актуально для ноутбуков/UPS-профилей.
• Unattended-Upgrade::InstallOnShutdown "false"; — запрещать установку в момент выключения.
• Unattended-Upgrade::Skip-ConfFile-Prompt "true"; и Unattended-Upgrade::Backup-Conffiles "true";

Последняя пара помогает, когда пакеты меняют конфиги: запросы dpkg о conffiles будут автоматически обработаны, а бэкап позволит откатиться при необходимости. Всегда держите инфраструктурные конфиги под управлением конфигурации (Ansible, Puppet) — так изменения легче отслеживать.

Как увидеть, что именно будет обновлено

Полезная связка команд, чтобы понимать состав апдейтов и их происхождение:

apt list --upgradable
apt-get -s dist-upgrade
apt-cache policy <package>

Если сомневаетесь, какие «карманы» репозиториев освещены паттернами (security vs updates), сверяйте поле o= (origin) и a= (archive) в apt-cache policy.

Частые проблемы и их решение

«Автообновления не происходят»

• Проверьте, что включены APT::Periodic в 20auto-upgrades.
• Убедитесь, что таймеры не отключены или не замаскированы (systemctl status apt-daily.timer apt-daily-upgrade.timer).
• Посмотрите логи: ошибки dpkg, сломанные зависимости, блокировки (/var/lib/dpkg/lock) при параллельных установках.
• Проверьте паттерн Origins-Pattern: возможно, вы разрешили только security, а нужный пакет приходит из -updates.

«dpkg спрашивает о conffile и процесс замирает»

• Включите Skip-ConfFile-Prompt и бэкапы conffiles.
• Проверьте, нет ли ручных несогласованных правок в конфиге, который также управляется конфигурационным менеджером.

«После апгрейда сервис не поднялся»

• Просмотрите journalctl -u <service> и изменения пакета (через apt-listchanges).
• Откатитесь к предыдущему конфигу из бэкапа conffiles или репозитория конфигураций.
• Временно добавьте пакет в Package-Blacklist или поставьте apt-mark hold, пока не разберётесь.

«Места на диске почти нет»

• Включите удаление неиспользуемых зависимостей и старых ядер.
• Регулярно запускайте apt-get autoremove --purge и apt-get autoclean в обслуживающих задачах, если политика допускает.

Практические профили настроек

Веб-серверы (Nginx/Apache + PHP-FPM)

• Origins: только security.
• needrestart = 'a' — перезапуски обычно безопасны, PHP-FPM рестартуется быстро.
• Автоперезагрузка: включить, время 03:00–04:00.
• Чёрный список: grub*, ядра — по ситуации (если есть окно перезагрузок, можно не блэклистить, а полагаться на плановый reboot).

Если у вас несколько пулов и версий PHP-FPM, пригодится материал: несколько пулов PHP-FPM под разные сайты.

Приложения с in-memory state (Redis, очереди)

• Origins: security.
• needrestart = 'l' или даже 'q' с ручными перезапусками по окнам обслуживания.
• Бэкап и чёткая процедура рестарта с тестом готовности.

Базы данных

• Origins: security, без автоматических минорных апдейтов из -updates, если нет полноценного стенда.
• Чёрный список пакетов БД либо apt-mark hold на конкретные версии.
• Реплика или резервное окно для ручного обновления.

Безопасная эволюция политики

Стартуйте консервативно: security-only, отправка отчётов на почту, логи в централизованное хранилище, сухие прогоны. Затем постепенно добавляйте -updates для отдельных узлов-«канареек», чтобы поймать проблемы до выката на весь парк. Вводите исключения точечно через Package-Blacklist и hold, а не широкими «ударными» пинами.

Proxy и частные репозитории

Если доступ в интернет ограничен, используйте APT proxy/кеш и частные зеркала. Базовая настройка прокси в /etc/apt/apt.conf.d/00proxy:

Acquire::http::Proxy "http://proxy.example:3128";
Acquire::https::Proxy "http://proxy.example:3128";

Проверьте, что подписи репозиториев валидируются корректно, ключи GPG установлены, а Origins-Pattern совпадает с origin/archive вашего зеркала.

Контроль расписания через systemd

Смотреть текущее расписание и юниты:

systemctl cat apt-daily.timer
systemctl cat apt-daily-upgrade.timer
systemctl status apt-daily.service apt-daily-upgrade.service

При необходимости можно изменить календарь в override-файле таймера (через systemctl edit) и разворачивать его как часть инфраструктурного кода, чтобы во всей группе серверов обновления шли в разные слоты.

Чеклист перед включением в проде

• Проверен Origins-Pattern: только необходимые карманы (минимум — security).
• Определена политика needrestart.
• Настроена автоперезагрузка с окном и уведомлениями (при необходимости).
• Критичные пакеты исключены (через Package-Blacklist и/или hold).
• Включено удаление неиспользуемых зависимостей и старых ядер.
• Настроены уведомления: почта или централизованный сбор логов.
• Есть стенд или «канарейка», где политика обкатана.

Поднимаете новый сервер? Начните с харденинга: базовая безопасность VDS: SSH и firewall.

Краткое резюме

unattended-upgrades — мощный и достаточно безопасный механизм автообновлений, если ограничить источники до security, продумать перезапуски с needrestart, аккуратно обращаться с ядрами и критичными сервисами, а также держать под рукой мониторинг и логи. В комбинации с чёрным списком пакетов и apt-mark hold/pinning вы получаете предсказуемые апдейты без лишних ночных сюрпризов. И главное — регулярно проверяйте логи и тестируйте изменения на стенде: автоматизация не отменяет инженерной ответственности.