SSD Nodes Learn Hosting plans →
Руководства Matt ConnorАвтор: Matt Connor · Обновлено 2026-09-04

Настройка dnf-automatic для обновлений в Rocky и AlmaLinux

Настройте dnf-automatic для автоматической установки патчей безопасности. Узнайте, как активировать systemd таймер, настроить email уведомления и политику перезагрузки сервера.

Что делает 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 (стандартный менеджер пакетов в семействе RHEL) по состоянию на август 2026 года. В версиях 10 произошел переход на DNF5, где изменились названия компонентов, поэтому для них выделен отдельный раздел в конце. Каждую команду ниже следует выполнять на собственном сервере; рядом приведен ожидаемый вывод.

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

Включение автоматических обновлений следует выполнять вместе с остальными настройками в рамках первых десяти минут работы на новом VPS, сразу после создания пользователя без прав root и настройки межсетевого экрана. Если настройка межсетевого экрана еще не выполнена, firewalld — это стандартный инструмент в Rocky и AlmaLinux. Несколько команд позволят открыть SSH, открыть порт, на котором работает ваш сайт, и сохранить эти правила после перезагрузки.

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] определяют поведение системы. В EL9 (enterprise Linux 9, общая база для Rocky 9 и AlmaLinux 9) по умолчанию установлены оба параметра no, поэтому, если вы просто включите 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-сессии, чтобы некорректная конфигурация не заблокировала вам доступ. Новое ядро — это случай, когда помогает только перезагрузка, так как работающее ядро нельзя заменить «на лету». Если вы хотите распределить обновления за утро по этим двум категориям, какие обновления требуют перезагрузки, а какие — только перезапуска службы поможет разобрать вывод пакет за пакетом.

Контейнеры — это отдельный случай, так как dnf-automatic обновляет пакеты хоста и не затрагивает пользовательское окружение внутри образа. Поэтому на сервере, где работает Docker Engine на Rocky Linux или AlmaLinux, также необходимо повторно загрузить образы и пересоздать контейнеры, прежде чем исправление попадет в код, который фактически обрабатывает трафик.

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

[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 содержит данные для фильтрации. Устаревшие данные errata в Rocky, описанные ранее, — одно из немногих мест, где их повседневная работа действительно различается. Если сервер еще не развернут, учитывайте это наряду с обещанием совместимости и поддержкой старых процессоров, которые разделяют эти два дистрибутива.

CentOS Stream является исключением, причем существенным. Репозитории Stream не содержат updateinfo.xml, поэтому фильтр безопасности никогда не находит совпадений, и каждый запуск сообщает No security updates needed. В Stream используйте upgrade_type = default и примите тот факт, что вы получаете все обновления без исключения. Stream также опережает RHEL, поэтому настройки на сервере со Stream меняются чаще, чем аналогичные настройки в Rocky или AlmaLinux. Это различие — не случайность упаковки, а результат решения Red Hat от 2020 года превратить CentOS в rolling-превью RHEL, что является тем же решением, которое привело к появлению Rocky Linux и 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 после окна обновлений, чтобы найти сервисы, которые всё ещё используют старый код.