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

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

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

Якщо ви працювали з Debian або Ubuntu, це те саме завдання, яке виконує unattended-upgrades на Ubuntu VPS. Найважливіша відмінність полягає в тому, що менеджер пакунків розуміє під словом «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. Якщо налаштування firewall ще не завершене, 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 з’явився в upstream 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 року користувачі повідомили, що updateinfo.xml Rocky 9 BaseOS не змінювався з грудня 2024 року. Через це --security не містив останніх advisories, а співробітники Rocky підтвердили, що це відома проблема. Якщо ви покладаєтеся на upgrade_type = security, час від часу порівнюйте список advisories з останніми оголошеннями 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-файлу. Не редагуйте встановлений 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.

А тепер пастка. Пакет містить ще три таймери: 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 записує дані до журналу. Це надійний варіант, оскільки він не потребує нічого іншого:

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

Емітер motd записує звіт у /etc/motd і замінює вміст цього файла. Якщо ви зберігаєте там банер входу, не використовуйте цей емітер.

Емітер email відкриває SMTP-з’єднання (простий протокол передавання пошти) з 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-сесії, яка вже відкрита, щоб неправильна конфігурація не заблокувала вам доступ. Нове ядро — це випадок, коли допоможе лише перезавантаження, оскільки запущене ядро неможливо замінити безпосередньо. Якщо потрібно розподілити оновлення конкретного ранку між цими двома категоріями, матеріал які оновлення потребують перезавантаження, а які — лише перезапуску сервісу розбирає вивід окремо для кожного пакета.

Контейнери — окремий випадок, оскільки dnf-automatic оновлює пакети хоста й не змінює userland, вбудований в image. Тому для сервера з Docker Engine у Rocky Linux або AlmaLinux також потрібно знову завантажити images і створити контейнери заново, перш ніж виправлення потрапить до коду, який фактично обробляє network traffic.

Чи має сервер перезавантажуватися самостійно?

[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 має дані для фільтрації. Застарілі errata Rocky, описані раніше, — один із небагатьох випадків, коли їхня повсякденна поведінка справді відрізняється. Тому, якщо сервер ще не розгорнуто, врахуйте це разом із гарантією сумісності та підтримкою старіших CPU, які відрізняють ці два дистрибутиви.

CentOS Stream є винятком, причому суттєвим. Репозиторії Stream не містять updateinfo.xml, тому фільтр безпеки ніколи не спрацює, а кожен запуск повідомлятиме No security updates needed. У Stream використовуйте upgrade_type = default і прийміть, що встановлюватимуться всі оновлення. Stream також випереджає RHEL, тому цей параметр змінює більше пакетів у системі Stream, ніж такий самий параметр у Rocky або AlmaLinux. Ця відмінність не є випадковим наслідком пакування. Вона виникла через рішення Red Hat у 2020 році перетворити CentOS на rolling preview для RHEL. Це те саме рішення, яке призвело до появи Rocky Linux і AlmaLinux.

Rocky 10 і AlmaLinux 10 перейшли на DNF5, який перейменував низку компонентів. В upstream-документації 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 збережено як 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. Фільтр безпеки не знайшов відповідностей: або жодне очікуване оновлення не містить advisory, або репозиторій не публікує дані advisory.

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

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

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