dnf-automatic: оновлення безпеки Rocky та AlmaLinux

Що робить dnf-automatic у Rocky Linux і AlmaLinux

dnf-automatic забезпечує автоматичне встановлення оновлень безпеки у Rocky Linux і AlmaLinux. Це невелика програма, яку запускає таймер systemd. Вона читає /etc/dnf/automatic.conf і застосовує лише дозволені цим файлом оновлення. Для встановлення достатньо однієї команди. Решта цього посібника присвячена параметрам, від яких залежить, чи захищатиме вона сервер, чи непомітно не робитиме нічого.

Якщо ви працювали з Debian або Ubuntu, dnf-automatic виконує те саме завдання, що й unattended-upgrades на VPS з Ubuntu. Найважливіша відмінність стосується значення слова «security» для менеджера пакетів. В Ubuntu це окремий архівний pocket. У сімействі RHEL це метадані, пов’язані з опублікованими advisory, і ці метадані можуть бути відсутніми або застарілими. Якщо вказати dnf-automatic репозиторій без даних advisory, програма нічого не встановить, але повідомить про успішне виконання.

Цей посібник підготовлено для Rocky Linux 9 і AlmaLinux 9, які використовують DNF 4 (DNF — менеджер пакетів у сімействі RHEL), станом на August 2026. У релізах 10 використовується DNF5, і назви параметрів там змінюються, тому їм присвячено окремий розділ наприкінці. Кожна наведена нижче команда призначена для виконання на вашому сервері. Поруч наведено очікуваний результат.

Встановіть dnf-automatic і перегляньте конфігурацію, що постачається з пакетом

Увімкнення автоматичних оновлень належить до решти початкового налаштування, описаного в перші десять хвилин на новому VPS, одразу після створення користувача без прав root і налаштування firewall.

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 року через advisory 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: встановлюються лише пакети, зазначені в security advisory.

Розумна початкова конфігурація для 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 — застарілий спосіб розподіляти навантаження між багатьма машинами; тепер це завдання виконує timer. Виконайте 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, опублікований у репозиторії, де кожен advisory містить перелік пакетів, які його виправляють. AlmaLinux публікує такі записи як advisories 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 взагалі нічого не виводить, це означає одне з двох: або жоден пакет, для якого очікується оновлення, не має advisory, або в репозиторії немає даних advisory для читання. Rocky та AlmaLinux публікують такі дані, тому в цих двох дистрибутивах порожній список зазвичай є коректним результатом. CentOS Stream їх взагалі не публікує.

По-друге, режим security не означає мінімальні зміни. dnf-automatic додає security-фільтр, а потім запускає звичайний процес оновлення. Тому пакет, зазначений в advisory, оновлюється до найновішої версії в репозиторії та встановлює разом із нею залежності. Менший крок — оновлення лише до найпершої версії, яка виправляє advisory, — це dnf upgrade-minimal --security, який потрібно запускати вручну. У dnf-automatic немає налаштування для цього режиму.

Є ще один нюанс, що стосується Rocky. Rocky генерує свої errata на основі даних Red Hat через власний pipeline, і цей pipeline відстає. У вересні 2025 року користувачі повідомили, що Rocky 9 BaseOS updateinfo.xml не змінювався з грудня 2024 року. Через це --security не містив нових advisory, а співробітники Rocky підтвердили, що це відома проблема. Якщо ви покладаєтеся на upgrade_type = security, час від часу порівнюйте список advisory з останніми оголошеннями RLSA. На сервері, де повнота покриття важливіша за контроль змін, безпечнішим налаштуванням буде upgrade_type = default за розкладом, який ви визначите.

Фактичний запуск виконує timer systemd

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

list-timers має вивести один рядок із часом NEXT, приблизно через добу. Порожня таблиця означає, що timer не увімкнено, тому завдання ніколи не запуститься.

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

Змініть розклад за допомогою drop-in. Не редагуйте unit, поставлений у пакеті, оскільки оновлення пакета замінює файли в /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 застосовуються до всього іншого, що ви плануєте запускати; це описано в розділі створення unit-файлів service і timer systemd.

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

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

Як дізнатися, коли щось було встановлено?

emit_via у розділі [emitters] керує формуванням звітів. У systemd емітер stdio записує дані до журналу. Це надійний варіант, оскільки він не потребує нічого іншого:

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 лише для ретрансляції. Коли надсилання пошти працює, тема повідомлення має значення 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 не перезапускає ваші сервіси

Встановлення пакета замінює файли на диску. Процес, який уже запущений, продовжує використовувати старий код у пам’яті, тому виправлена бібліотека не впливає на daemon, запущений минулого місяця. Саме через цю різницю між встановленим і фактично активним кодом автоматичне встановлення оновлень потребує політики перезапуску, а не лише політики встановлення.

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 daemon із другої вже відкритої 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 усе описане вище ідентичне, аж до шляху до конфігурації та назв unit. Обидва дистрибутиви публікують 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, у якому назви компонентів змінилися. Документація upstream для DNF5 задає timer як 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 збережено як alias. Перед копіюванням назв пакетів або unit із посібника для версії 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 на рівні debug, а потім використовує значення за замовчуванням. Тому помилково написаний ключ нічого не змінює й не спричиняє попередження. Запишіть 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 публікують такі метадані, тому фільтр має advisory для зіставлення. Значення за замовчуванням, яке постачається із системою, — upgrade_type = default; воно встановлює всі доступні оновлення після apply_updates = yes.

Чому dnf-automatic повідомляє «Оновлення безпеки не потрібні, але доступні 3 оновлення»?

DNF визначає, що вважати оновленням безпеки, читаючи updateinfo.xml з репозиторію. У ньому кожен advisory містить список пакетів, які його виправляють. Якщо ці метадані відсутні або застарілі, фільтр безпеки не знаходить збігів, хоча звичайні оновлення залишаються доступними. Саме тому з’являється це повідомлення. Це очікувана поведінка для 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 не вказує emitter, який ви фактично переглядаєте. Щонайменше встановіть emit_via у значення stdio, увімкніть send_error_messages, щоб також повідомляти про помилки, і виконайте dnf needs-restarting -s після вікна оновлення, щоб знайти служби, які досі працюють зі старим кодом.