Настройка dnf-automatic в Rocky Linux и AlmaLinux

Что делает dnf-automatic в Rocky Linux и AlmaLinux

dnf-automatic — это инструмент для автоматической установки обновлений безопасности в Rocky Linux и AlmaLinux. Это небольшая программа, запускаемая таймером systemd, которая считывает файл /etc/dnf/automatic.conf и применяет настройки, разрешенные в этом файле. Установка выполняется одной командой. Остальная часть этого руководства посвящена параметрам, которые определяют, будет ли система защищена или программа будет работать вхолостую.

Если вы перешли с Debian или Ubuntu, эта утилита выполняет ту же задачу, что и unattended-upgrades на VPS с Ubuntu. Одно различие важнее всех остальных: что именно менеджер пакетов считает «безопасностью». В Ubuntu это отдельный архивный репозиторий. В семействе RHEL это метаданные, привязанные к опубликованным бюллетеням безопасности, и эти метаданные могут отсутствовать или быть устаревшими. Если направить dnf-automatic на репозиторий без данных о бюллетенях, программа ничего не установит, но отчитается об успешном завершении.

Это руководство написано для Rocky Linux 9 и AlmaLinux 9, которые используют DNF 4 (DNF — это менеджер пакетов в семействе RHEL) по состоянию на август 2026 года. В версиях 10 произошел переход на DNF5, где изменились названия инструментов, поэтому для них выделен отдельный раздел в конце. Каждая приведенная ниже команда предназначена для выполнения на вашем сервере, а рядом с ней указан ожидаемый вывод.

Установка dnf-automatic и чтение конфигурационного файла

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

sudo dnf install -y dnf-automatic
rpm -q dnf dnf-automatic
systemctl is-enabled dnf-automatic.timer

systemctl is-enabled выводит disabled на свежеустановленной системе, так как установка пакета не запускает никаких служб. Это самая распространенная причина, по которой сервер, на котором «установлен dnf-automatic», не применил ни одного обновления.

Версия DNF важна для одной из опций. Параметр reboot появился в основной ветке DNF 4.15, а Red Hat перенесла его в dnf-4.14.0-6.el9 в ноябре 2023 года через бюллетень RHBA-2023:6645. Rocky 9 и AlmaLinux 9 пересобирают этот пакет, поэтому на актуальной системе он присутствует, а на сервере, который не обновлялся с 2023 года — нет.

Конфигурационный файл находится по адресу /etc/dnf/automatic.conf. Поставляемая копия содержит все опции, понятные данной сборке, с указанием значений по умолчанию в закомментированном виде. Прочитайте его перед внесением правок, так как этот файл является единственным достоверным источником информации о настройках вашей версии.

Два переключателя, определяющие дальнейшие действия

download_updates и apply_updates в секции [commands] определяют поведение системы. Оба параметра имеют значение no по умолчанию в EL9 (enterprise Linux 9, общая база для Rocky 9 и AlmaLinux 9), поэтому, если вы просто включите dnf-automatic без редактирования, он будет только информировать вас о доступных обновлениях.

• Оба no: dnf-automatic сообщает о доступных обновлениях, но ничего не меняет на сервере.
• download_updates = yes с apply_updates = no: пакеты загружаются в кэш DNF. Установка проходит быстро и без использования сети, но в текущий момент изменения не применяются.
• Оба yes с upgrade_type = default: устанавливаются все доступные обновления, независимо от того, являются ли они обновлениями безопасности.
• Оба yes с upgrade_type = security: устанавливаются только те пакеты, которые указаны в бюллетенях безопасности.

Разумная конфигурация для VPS, доступного из Интернета:

[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
random_sleep = 0
network_online_timeout = 60
reboot = never

network_online_timeout — это количество секунд, в течение которых процесс ожидает появления сети перед тем, как завершиться с ошибкой; это важно для серверов, которые только что загрузились. random_sleep — это устаревший способ распределения нагрузки между множеством машин, теперь эту задачу выполняет таймер. Запустите systemctl cat dnf-automatic.service, чтобы увидеть точные флаги, которые передает поставляемый сервис.

Проверьте, что файл работает так, как вы ожидаете, не дожидаясь 06:00:

sudo systemctl start dnf-automatic.service
sudo journalctl -u dnf-automatic.service -n 50 --no-pager

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

sudo dnf-automatic --downloadupdates --no-installupdates

Что на самом деле означает upgrade_type = security в Rocky и Alma

DNF не определяет, является ли обновление обновлением безопасности, путем сравнения номеров версий. Он считывает метаданные errata: файл под названием updateinfo.xml, опубликованный внутри репозитория, где в каждом уведомлении перечислены пакеты, исправляющие уязвимость. AlmaLinux публикует их как уведомления ALSA, Rocky публикует их как RLSA. upgrade_type = security создает фильтр на основе этих метаданных и обновляет только те пакеты, которые ему соответствуют.

Из этого следуют два вывода, и оба они часто удивляют пользователей.

Во-первых, отсутствие метаданных означает отсутствие обновлений. Если в репозитории нет updateinfo.xml, фильтр ничего не находит, и выполнение завершается строкой в журнале:

No security updates needed, but 3 updates available

Система не пропатчена, при этом об ошибке ничего не сообщается. Проверьте это самостоятельно:

dnf updateinfo list --security
dnf check-update

Если dnf check-update выводит список пакетов, а dnf updateinfo list --security не выводит ничего, это означает либо отсутствие ожидающих обновлений с уведомлениями, либо отсутствие данных об уведомлениях в репозитории. Rocky и AlmaLinux публикуют эти данные, поэтому для них пустой список обычно соответствует действительности. CentOS Stream не публикует их вовсе.

Во-вторых, режим безопасности не означает минимальные изменения. dnf-automatic добавляет фильтр безопасности, а затем запускает обычный процесс обновления. В результате пакет, указанный в уведомлении, обновляется до самой новой версии в репозитории и подтягивает за собой все зависимости. Более осторожный подход — обновление только до самой ранней версии, исправляющей уязвимость, — выполняется через dnf upgrade-minimal --security вручную. В dnf-automatic такой настройки нет.

Существует еще один нюанс для Rocky. Rocky генерирует свои errata на основе данных Red Hat через собственный конвейер, и этот конвейер иногда отстает. В сентябре 2025 года пользователи сообщали, что файл updateinfo.xml в Rocky 9 BaseOS не обновлялся с декабря 2024 года, поэтому --security не содержал свежих уведомлений, и сотрудники Rocky подтвердили это как известную проблему. Если вы полагаетесь на upgrade_type = security, время от времени сверяйте список уведомлений с последними анонсами RLSA. На сервере, где полнота покрытия важнее контроля изменений, настройка upgrade_type = default по выбранному вами расписанию является более безопасным вариантом.

Таймер systemd, который выполняет задачу

sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timer

list-timers должен вывести одну строку с временем NEXT, которое наступит примерно через сутки. Пустая таблица означает, что таймер не включен, поэтому задача никогда не будет выполнена.

Поставляемый в комплекте таймер срабатывает в *-*-* 6:00 с параметрами RandomizedDelaySec=60m и Persistent=true. Случайная задержка распределяет нагрузку на зеркало в течение часа, чтобы все серверы не обращались к нему одновременно. Параметр Persistent=true означает, что если машина была выключена в 06:00, она выполнит пропущенную задачу сразу после загрузки, а не будет ждать следующего дня.

Измените расписание с помощью drop-in файла. Не редактируйте поставляемый юнит, так как обновление пакета перезапишет файлы в /usr/lib/systemd/system.

sudo systemctl edit dnf-automatic.timer

[Timer]
OnCalendar=
OnCalendar=*-*-* 03:30
RandomizedDelaySec=30m

Пустая строка OnCalendar= обязательна. Параметр OnCalendar накапливается, поэтому без сброса вы сохраните запись на 06:00 и добавите вторую, из-за чего задача будет выполняться дважды в день. Проверьте результат с помощью systemctl list-timers dnf-automatic.timer и посмотрите на столбец NEXT. Те же правила drop-in файлов применяются к любому другому расписанию, что описано в написании юнитов сервисов и таймеров systemd.

Теперь о ловушке. Пакет содержит еще три таймера: dnf-automatic-notifyonly.timer, dnf-automatic-download.timer и dnf-automatic-install.timer. Каждый из них запускает ту же программу с флагами командной строки, и эти флаги переопределяют download_updates и apply_updates из вашего конфигурационного файла. Если включить один из них вместе с dnf-automatic.timer, задача будет выполняться дважды с разным поведением, что выглядит так, будто ваш конфигурационный файл игнорируется. Включите один таймер и проверьте:

systemctl list-unit-files 'dnf-automatic*'

Как узнать, когда был установлен пакет?

emit_via в секции [emitters] управляет отчетами. В systemd эмиттер stdio записывает данные в journal, что является надежным вариантом, так как не требует установки дополнительного ПО:

sudo journalctl -u dnf-automatic.service --since -7d --no-pager

Эмиттер motd записывает отчет в /etc/motd, перезаписывая содержимое этого файла. Если вы используете этот файл для баннера при входе в систему, не включайте данный эмиттер.

Эмиттер email открывает SMTP-соединение (simple mail transfer protocol) с email_host на порту email_port, значениями по умолчанию для которых являются localhost и 25. На чистой VPS на этом порту обычно ничего не запущено, поэтому соединение отклоняется и почта не отправляется. Запустите ss -lnt | grep ':25', прежде чем полагаться на этот метод, и настройте Postfix в режиме relay-only, если вывод пуст. Когда отправка почты заработает, тема письма будет содержать Updates applied on 'web01'., используя имя из system_name.

Для любых других целей эмиттер command передает отчет вашей программе через стандартный поток ввода:

[emitters]
emit_via = stdio, command
system_name = web01.example.com
send_error_messages = yes

[command]
command_format = /usr/local/bin/notify-ops
stdin_format = {body}

Значение send_error_messages по умолчанию — no, что означает, что при неудачном запуске отчет не будет сформирован вовсе. Включите эту опцию. Система обновлений, которая сообщает только об успешных операциях, хуже полного отсутствия системы, так как тишина воспринимается как признак исправной работы.

dnf-automatic не перезапускает ваши службы

Установка пакета заменяет файлы на диске. Запущенный процесс сохраняет старый код в оперативной памяти, поэтому исправленная библиотека никак не влияет на демон, запущенный месяц назад. Этот разрыв между установленным и фактически используемым кодом — причина, по которой автоматическое обновление требует политики перезапуска, а не только политики установки.

sudo dnf install -y dnf-plugins-core
dnf needs-restarting -s
dnf needs-restarting -r

-s выводит список служб systemd, файлы которых изменились после их запуска. -r отвечает на один вопрос и выводит один из двух блоков:

Core libraries or services have been updated since boot-up:
  * kernel
Reboot is required to fully utilize these updates.

No core libraries or services have been updated since boot-up.
Reboot should not be necessary.

-r не является инструментом глубокого анализа. Он проверяет фиксированный список пакетов: kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon и microcode_ctl. Если один из них был установлен после последней загрузки, вы получите первый вариант ответа. Добавьте собственные имена пакетов в файл с расширением .conf в директории /etc/dnf/plugins/needs-restarting.d/, если для применения изменений в других компонентах системы также требуется перезагрузка.

Важное замечание для скриптов: dnf needs-restarting -r завершается с ненулевым кодом как в случае необходимости перезагрузки, так и при ошибке выполнения самой команды, поэтому по одному лишь коду выхода нельзя определить причину. Анализируйте текстовый вывод.

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

Должен ли сервер перезагружаться автоматически?

[commands]
reboot = when-needed
reboot_command = shutdown -r +5 'Rebooting after applying package updates'

reboot = never используется по умолчанию. when-changed выполняет перезагрузку после установки любого обновления. when-needed перезагружает систему только в том случае, если проверка, заданная параметром needs-restarting -r, выявила замену базового пакета. Это оптимальный вариант для большинства владельцев одиночных серверов в сочетании с выбранным ими временным интервалом. Значение по умолчанию reboot_command уведомляет вошедших в систему пользователей за пять минут до перезагрузки через shutdown; этот интервал можно увеличить.

Перед включением этой функции решите два вопроса. Каждый критически важный сервис должен автоматически запускаться при загрузке системы; это типичная проблема для стеков Docker Compose, запущенных вручную. Также у вас должен быть доступ к консоли или режиму восстановления от провайдера, так как ядро, которое не загружается, невозможно исправить через SSH. Если хотя бы одно из этих условий не выполняется, оставьте reboot = never и выполняйте перезагрузку самостоятельно после изучения логов.

Различия между Rocky, AlmaLinux и CentOS Stream

В Rocky 9 и AlmaLinux 9 все описанное выше идентично, вплоть до путей к конфигурационным файлам и имен юнитов. Оба дистрибутива публикуют errata, поэтому upgrade_type = security содержит данные для фильтрации.

CentOS Stream является исключением, и это создает определенные сложности. Репозитории Stream не содержат updateinfo.xml, поэтому фильтр безопасности никогда не находит совпадений, и при каждом запуске сообщается о No security updates needed. В Stream используйте upgrade_type = default и учитывайте, что вы будете получать все обновления без исключения. Кроме того, Stream опережает RHEL, поэтому настройки на системе со Stream меняются чаще, чем аналогичные настройки на Rocky или AlmaLinux.

В Rocky 10 и AlmaLinux 10 произошел переход на DNF5, что повлекло за собой переименование компонентов. Согласно официальной документации DNF5, таймер называется dnf5-automatic.timer, поставляемые по умолчанию настройки находятся в /usr/share/dnf5/dnf5-plugins/automatic.conf, а ваши переопределения по-прежнему в /etc/dnf/automatic.conf. Значение download_updates по умолчанию теперь установлено в yes, а не в no, также добавлен distro-sync в качестве upgrade_type. Запрос рекомендаций (advisory) выполняется через dnf advisory list, при этом updateinfo сохранен как псевдоним. Перед копированием имен пакетов или юнитов из руководств, написанных для версии 9, убедитесь, что именно установлено в вашей системе:

dnf list --available '*automatic*'
systemctl list-unit-files '*automatic*'

Многие опубликованные руководства по этой теме до сих пор охватывают только Rocky 8. Набор доступных опций расширился с момента их написания, поэтому проверяйте закомментированный файл на своей машине, а не полагайтесь на устаревшие статьи.

Режимы сбоев и сообщения, которые вы увидите

Ничего не запускается. systemctl list-timers dnf-automatic.timer выводит пустую таблицу, а systemctl is-enabled dnf-automatic.timer выводит disabled. Пакет был установлен, но таймер — нет.

Задача выполняется, но ничего не устанавливает. В журнале содержится No security updates needed, but 3 updates available. Фильтр безопасности ничего не обнаружил: либо нет ожидающих обновлений с бюллетенями безопасности, либо репозиторий не публикует данные о них.

Настройка выглядит проигнорированной. DNF записывает неизвестную опцию в automatic.conf на уровне отладки, а затем использует значение по умолчанию. Поэтому опечатка в ключе ни на что не влияет и не вызывает предупреждений. Вы пишете apply_update = yes, а apply_updates остается равным no, из-за чего система бесконечно скачивает данные, но ничего не устанавливает. После любого редактирования запускайте sudo systemctl start dnf-automatic.service и читайте журнал, вместо того чтобы доверять файлу.

Задача выполняется дважды в день. Включены два таймера. systemctl list-unit-files 'dnf-automatic*' показывает, какие именно, а дополнительные таймеры передают флаги, которые переопределяют ваш конфигурационный файл.

Почта не приходит. Либо на порту 25 нет слушающего процесса для отправителя email, либо send_error_messages по-прежнему имеет значение no, и единственное, что стоило сообщить, было ошибкой.

Обновленный сервис по-прежнему сообщает старую версию. Файл на диске новый, а процесс в памяти — старый. dnf needs-restarting -s перечисляет сервисы, которые необходимо перезапустить.

FAQ

Устанавливает ли dnf-automatic только обновления безопасности в Rocky Linux?

Только если вы установите upgrade_type = security в /etc/dnf/automatic.conf и если ваши репозитории публикуют метаданные errata. Rocky Linux и AlmaLinux публикуют их, поэтому фильтр имеет рекомендации для сопоставления. По умолчанию установлено upgrade_type = default, что приводит к установке всех доступных обновлений после выполнения apply_updates = yes.

Почему dnf-automatic сообщает "No security updates needed, but 3 updates available"?

DNF определяет, что считается обновлением безопасности, считывая updateinfo.xml из репозитория, где каждая рекомендация содержит список пакетов, исправляющих уязвимость. Когда эти метаданные отсутствуют или устарели, фильтр безопасности ничего не находит, в то время как обычные обновления остаются в очереди, что и приводит к появлению такой строки. Это ожидаемое поведение для CentOS Stream, который вообще не публикует errata. В Rocky или AlmaLinux сравните dnf updateinfo list --security с dnf check-update и убедитесь, что ваши метаданные актуальны.

Перезагрузит ли dnf-automatic мой сервер после обновления ядра?

Нет, если вы не настроите это явно. Опция reboot по умолчанию имеет значение never. Установите reboot = when-needed, и перезагрузка произойдёт только в том случае, если проверка dnf needs-restarting -r обнаружит, что базовый пакет, такой как kernel или glibc, был заменён с момента загрузки. reboot = when-changed выполняет перезагрузку после любого применённого обновления. Оба метода используют reboot_command, который по умолчанию имеет значение shutdown -r +5 с выводом предупреждающего сообщения для вошедших в систему пользователей.

Как изменить время запуска dnf-automatic?

Выполните sudo systemctl edit dnf-automatic.timer и добавьте секцию [Timer] с пустой строкой OnCalendar=, за которой следует ваше расписание, например OnCalendar=*-*-* 03:30. Пустая строка обязательна, так как OnCalendar накапливает значения; если её пропустить, стандартный запуск в 06:00 сохранится и добавится второй. Проверьте результат с помощью systemctl list-timers dnf-automatic.timer и посмотрите на столбец NEXT.

Нужно ли мне по-прежнему проверять сервер, который обновляется автоматически?

Да. dnf-automatic только устанавливает пакеты. Он не перезапускает демоны и не отправляет уведомления, которые вы увидите, если в emit_via не указан эмиттер, который вы действительно читаете. Установите emit_via как минимум в stdio, включите send_error_messages, чтобы получать отчёты об ошибках, и запускайте dnf needs-restarting -s после окна обновлений, чтобы найти сервисы, которые всё ещё используют старый код.