Автоматический патчинг серверов: Unattended-Upgrades и dnf-automatic

Сервер не обновлялся полгода, и в одну пятницу прилетел RCE в OpenSSL. Если обновлять вручную — вы опоздаете. Автоматический патчинг безопасности через Unattended-Upgrades или dnf-automatic закрывает CVE без участия человека. На конфигурацию уходит несколько часов, после чего не нужно еженедельно заходить по SSH. Мы настраиваем эту систему на серверах Linux уже более 5 лет — более 500 серверов под управлением Debian/Ubuntu и RHEL. За это время выработали стандарт: патчи security-обновлений в течение 24 часов после выхода, минимизация простоев, полный контроль через Ansible.

Почему автоматический патчинг необходим?

70% успешных атак на Linux-инфраструктуру используют известные уязвимости, для которых уже есть патчи. Ручное обновление: найти CVE, зайти на каждый сервер, выполнить apt upgrade или dnf update, перезапустить сервисы. На 50 серверов уходит полный день администратора. Автоматизация сокращает это время до нуля и устраняет человеческий фактор: забытые серверы, пропущенные пакеты, разная версионность. Мы внедряем системы, которые сами проверяют и устанавливают обновления безопасности сразу после выхода. Мы гарантируем, что после настройки uptime ваших сервисов останется на уровне 99.9%. Среднее время реакции на экстренные CVE сокращается с 12 часов до 1 часа, а затраты на администрирование падают на 80%.

Как работает Unattended-Upgrades на Debian/Ubuntu

Пакет уже предустановлен на большинстве современных Ubuntu. Основной конфиг — /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    // "${distro_id}:${distro_codename}-updates";
    // опционально
};
Unattended-Upgrade::Mail "[email protected]";
Unattended-Upgrade::MailReport "on-change";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";

Automatic-Reboot "false" — намеренно. Автоматический перезапуск продакшен-серверов без окна обслуживания — плохая идея. Для ядра и glibc требуется ребут, но его лучше планировать вручную или через отдельный инструмент (kured для Kubernetes-нод).

Активация через /etc/apt/apt.conf.d/20auto-upgrades:

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

Проверка без применения: unattended-upgrade --dry-run --debug.

Как настроить Unattended-Upgrades?

1. Установите пакет: apt install unattended-upgrades.
2. Отредактируйте конфиг /etc/apt/apt.conf.d/50unattended-upgrades согласно вашей политике.
3. Создайте или измените /etc/apt/apt.conf.d/20auto-upgrades для активации.
4. Запустите unattended-upgrade --dry-run --debug для проверки.
5. Проверьте логи в /var/log/unattended-upgrades/.

Как настроить dnf-automatic на RHEL/CentOS/AlmaLinux

dnf install dnf-automatic 

Конфиг /etc/dnf/automatic.conf:

[commands]
upgrade_type = security
apply_updates = yes
random_sleep = 360

[emitters]
emit_via = email
email_to = [email protected]
email_from = [email protected]

systemctl enable --now dnf-automatic-install.timer 

Таймер запускается раз в сутки со случайной задержкой до 360 секунд — это рассыпает нагрузку на зеркала, если серверов много.

Какие пакеты лучше исключить из автоматического обновления?

Ядро Linux, проприетарные драйверы (NVIDIA, AMD) и пакеты, требующие ручной миграции (например, базы данных), не стоит обновлять автоматически. Используйте apt-mark hold <пакет> на Debian/Ubuntu или dnf versionlock <пакет> на RHEL. Unattended-Upgrades и dnf-automatic игнорируют заблокированные пакеты. В нашей практике hold-пакеты документируются в Ansible-инвентори и проверяются при каждом развёртывании.

Как проверить успешность обновлений?

На Debian/Ubuntu смотрите /var/log/unattended-upgrades/unattended-upgrades.log. На RHEL — journalctl -u dnf-automatic-install. Если в логах есть kept back, это означает смену зависимостей или активный hold. Dry-run с unattended-upgrade --dry-run --debug покажет, что будет установлено без применения.

Сравнение инструментов для разных ОС

Этапы работы по настройке патчинга

Типичные ошибки при автоматическом патчинге

• Забывают исключить ядро из автоматического обновления — сервер может перезагрузиться в неподходящее время.
• Не настраивают уведомления — пропускают сбой при обновлении.
• Используют один конфиг для всех ОС, игнорируя различия между APT и DNF.

Что входит в настройку автоматического патчинга

• Аудит текущего состояния: инвентаризация ОС, версий, hold-пакетов.
• Разработка политики обновлений: security-only, расписание, уведомления.
• Написание Ansible-роли для развёртывания конфигов на все серверы.
• Тестирование на изолированном стенде.
• Постепенный деплой на продуктив с мониторингом логов.
• Документация: описание hold-пакетов, процедура отката, инструкция для администратора.
• Пост-инсталляционная поддержка: помощь при первых циклах обновлений.

Сколько времени занимает настройка?

Для однородной инфраструктуры (только Debian или только RHEL) — от 2 часов. Для смешанной с разными ОС и требованиями — до 1 дня. Стоимость рассчитывается индивидуально исходя из количества серверов и сложности. Вы экономите время и деньги администратора, которые можно направить на развитие. Инвестиция окупается за счёт предотвращения инцидентов.

Оцениваем вашу инфраструктуру за один день. Свяжитесь с нами для консультации. Закажите настройку автоматического патчинга — получите защиту без простоя. Более 5 лет опыта, более 100 проектов, 500+ серверов под управлением, сертифицированные инженеры.