Konfiguracja dnf-automatic w Rocky Linux i AlmaLinux

Działanie dnf-automatic w systemach Rocky Linux i AlmaLinux

Narzędzie dnf-automatic służy do automatycznego instalowania aktualizacji bezpieczeństwa w systemach Rocky Linux oraz AlmaLinux. Jest to niewielki program uruchamiany przez timer systemd, który odczytuje plik /etc/dnf/automatic.conf i stosuje zdefiniowane w nim reguły. Instalacja wymaga wykonania jednego polecenia. Dalsza część przewodnika opisuje ustawienia decydujące o tym, czy narzędzie skutecznie zabezpieczy serwer, czy pozostanie nieaktywne.

Użytkownicy przechodzący z systemów Debian lub Ubuntu mogą porównać to rozwiązanie do unattended-upgrades w systemie Ubuntu VPS. Istnieje jedna kluczowa różnica: sposób, w jaki menedżer pakietów definiuje "bezpieczeństwo". W systemie Ubuntu jest to oddzielny kanał repozytorium. W rodzinie RHEL jest to metadana dołączona do opublikowanych biuletynów bezpieczeństwa, która może być nieobecna lub nieaktualna. Jeśli dnf-automatic zostanie skierowany do repozytorium bez danych o biuletynach, nie zainstaluje żadnych pakietów, zgłaszając jednocześnie sukces operacji.

Niniejszy przewodnik dotyczy systemów Rocky Linux 9 oraz AlmaLinux 9, które korzystają z DNF 4 (domyślny menedżer pakietów w rodzinie RHEL) według stanu na sierpień 2026 roku. W wydaniach 10 wprowadzono DNF5, co wiąże się ze zmianą nazw narzędzi, dlatego kwestie te zostały omówione w osobnej sekcji pod koniec dokumentu. Każde z poniższych poleceń należy wykonać na własnym serwerze; obok poleceń zamieszczono oczekiwane wyniki ich działania.

Instalacja dnf-automatic i analiza dostarczonej konfiguracji

Włączenie automatycznych aktualizacji powinno stanowić część podstawowej konfiguracji serwera, opisanej w pierwsze dziesięć minut na nowym VPS, zaraz po utworzeniu użytkownika innego niż root i skonfigurowaniu firewalla. Jeśli konfiguracja firewalla nie została jeszcze wykonana, firewalld jest domyślnym rozwiązaniem w systemach Rocky i AlmaLinux, a kilka poleceń wystarczy, aby otworzyć port SSH, port usługi oraz zapewnić trwałość tych reguł po restarcie systemu.

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

systemctl is-enabled wyświetla disabled na świeżej instalacji, ponieważ instalacja pakietu nie uruchamia żadnej usługi. Jest to najczęstsza przyczyna, dla której serwer z zainstalowanym dnf-automatic nigdy nie pobrał żadnej aktualizacji.

Wersja DNF ma znaczenie dla jednej z opcji. Ustawienie reboot pojawiło się w głównym nurcie DNF w wersji 4.15, a Red Hat wprowadził je w ramach backportu do dnf-4.14.0-6.el9 w listopadzie 2023 roku, zgodnie z biuletynem RHBA-2023:6645. Systemy Rocky 9 oraz AlmaLinux 9 korzystają z przebudowanych pakietów, więc aktualny system posiada tę funkcję, natomiast system nieaktualizowany od 2023 roku może jej nie zawierać.

Plik konfiguracyjny to /etc/dnf/automatic.conf. Dostarczona kopia zawiera listę wszystkich opcji rozpoznawanych przez daną kompilację wraz z wartościami domyślnymi, które są zakomentowane. Należy przeczytać ten plik przed przystąpieniem do edycji, ponieważ stanowi on wiarygodne źródło informacji o możliwościach posiadanej wersji.

Dwa przełączniki decydujące o działaniu

download_updates oraz apply_updates w sekcji [commands] określają zachowanie narzędzia. W systemach EL9 (Enterprise Linux 9, wspólna baza dla Rocky 9 oraz AlmaLinux 9) oba są domyślnie ustawione na no, więc niezmodyfikowany i włączony dnf-automatic jedynie informuje o dostępnych aktualizacjach.

• Oba no: dnf-automatic zgłasza dostępne aktualizacje i nie wprowadza żadnych zmian w systemie.
• download_updates = yes z apply_updates = no: pakiety są pobierane do pamięci podręcznej DNF. Instalacja przebiega szybko i nie wymaga sieci, ale w danym momencie nic nie jest zmieniane.
• Oba yes z upgrade_type = default: instalowana jest każda dostępna aktualizacja, niezależnie od tego, czy dotyczy bezpieczeństwa.
• Oba yes z upgrade_type = security: instalowane są wyłącznie pakiety wymienione w biuletynach bezpieczeństwa.

Rozsądny punkt wyjścia dla publicznie dostępnego serwera VPS:

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

network_online_timeout określa liczbę sekund, przez jaką proces oczekuje na działającą sieć przed przerwaniem pracy, co ma znaczenie na maszynie tuż po uruchomieniu. random_sleep to starszy sposób rozkładania obciążenia na wiele maszyn; obecnie to zadanie wykonuje timer. Uruchom systemctl cat dnf-automatic.service, aby zobaczyć dokładne flagi przekazywane przez dostarczoną usługę.

Sprawdź, czy plik działa zgodnie z oczekiwaniami, bez czekania do godziny 06:00:

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

Dziennik systemowy pokazuje, co proces przeanalizował i jakie działania podjął. Można również wymusić określone zachowanie z poziomu wiersza poleceń, co nadpisuje ustawienia pliku tylko dla tego konkretnego uruchomienia:

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

Co w rzeczywistości oznacza upgrade_type = security w systemach Rocky i Alma

DNF nie ustala, czy aktualizacja jest aktualizacją bezpieczeństwa poprzez porównywanie numerów wersji. Odczytuje metadane erraty: plik o nazwie updateinfo.xml opublikowany wewnątrz repozytorium, w którym każde zalecenie (advisory) zawiera listę pakietów, które je naprawiają. AlmaLinux publikuje je jako zalecenia ALSA, Rocky publikuje je jako RLSA. upgrade_type = security tworzy filtr na podstawie tych metadanych i aktualizuje tylko te pakiety, które do niego pasują.

Wynikają z tego dwie konsekwencje, z których obie zaskakują użytkowników.

Po pierwsze, brak metadanych oznacza brak aktualizacji. Jeśli repozytorium nie zawiera updateinfo.xml, filtr nie dopasowuje niczego, a operacja kończy się w dzienniku tym wierszem:

No security updates needed, but 3 updates available

Serwer nie jest załatany, a nic nie zgłosiło błędu. Sprawdź to samodzielnie:

dnf updateinfo list --security
dnf check-update

Jeśli dnf check-update wyświetla listę pakietów, podczas gdy dnf updateinfo list --security nie wyświetla niczego, oznacza to, że albo żadna oczekująca aktualizacja nie posiada zalecenia, albo repozytorium nie zawiera danych o zaleceniach do odczytania. Zarówno Rocky, jak i AlmaLinux je publikują, więc w tych systemach pusta lista zazwyczaj jest zgodna ze stanem faktycznym. CentOS Stream nie publikuje ich wcale.

Po drugie, tryb bezpieczeństwa nie oznacza minimalnych zmian. dnf-automatic dodaje filtr bezpieczeństwa, a następnie uruchamia standardową ścieżkę aktualizacji, więc pakiet wymieniony w zaleceniu przechodzi do najnowszej wersji dostępnej w repozytorium i pobiera wraz z nią swoje zależności. Mniejszy krok, polegający na przejściu tylko do najwcześniejszej wersji naprawiającej zalecenie, to dnf upgrade-minimal --security wykonywane ręcznie. dnf-automatic nie posiada ustawienia dla takiego działania.

Dodatkowe zastrzeżenie dotyczy systemu Rocky. Rocky generuje swoją erratę na podstawie danych Red Hat poprzez własny potok przetwarzania, a ten potok uległ opóźnieniu. We wrześniu 2025 roku użytkownicy zgłaszali, że updateinfo.xml w Rocky 9 BaseOS nie zmieniło się od grudnia 2024 roku, więc --security nie zawierało ostatnich zaleceń, co personel Rocky potwierdził jako znany problem. Jeśli polegasz na upgrade_type = security, porównuj od czasu do czasu listę zaleceń z najnowszymi ogłoszeniami RLSA. Na serwerze, gdzie pokrycie poprawkami jest ważniejsze niż kontrola zmian, bezpieczniejszym ustawieniem jest upgrade_type = default uruchamiane według wybranego harmonogramu.

Timer systemd, który faktycznie uruchamia zadanie

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

list-timers powinno wyświetlić jeden wiersz z czasem NEXT przypadającym za około dobę. Pusta tabela oznacza, że timer nie jest włączony, więc zadanie nigdy nie zostanie uruchomione.

Dostarczony timer wyzwala zadanie o *-*-* 6:00 z użyciem RandomizedDelaySec=60m oraz Persistent=true. Losowe opóźnienie rozprasza obciążenie floty w czasie jednej godziny, dzięki czemu wszystkie serwery nie łączą się z serwerem lustrzanym w tej samej sekundzie. Persistent=true oznacza, że maszyna wyłączona o 06:00 uruchomi pominięte zadanie krótko po starcie systemu, zamiast czekać do kolejnego dnia.

Harmonogram należy zmienić za pomocą pliku typu drop-in. Nie należy edytować dostarczonej jednostki, ponieważ aktualizacja pakietu nadpisuje pliki w /usr/lib/systemd/system.

sudo systemctl edit dnf-automatic.timer

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

Pusta linia OnCalendar= jest wymagana. OnCalendar kumuluje wartości, więc bez tego resetu zachowany zostanie wpis o 06:00 i dodany drugi, co spowoduje uruchamianie zadania dwa razy dziennie. Wynik należy potwierdzić za pomocą systemctl list-timers dnf-automatic.timer i sprawdzić kolumnę NEXT. Te same zasady dotyczące plików drop-in mają zastosowanie do każdego innego harmonogramu, co opisano w tworzenie jednostek service i timer systemu systemd.

Teraz pułapka. Pakiet dostarcza trzy dodatkowe timery: dnf-automatic-notifyonly.timer, dnf-automatic-download.timer oraz dnf-automatic-install.timer. Każdy z nich uruchamia ten sam program z określonymi flagami wiersza poleceń, a te flagi nadpisują download_updates oraz apply_updates z pliku konfiguracyjnego. Włączenie jednego z nich obok dnf-automatic.timer spowoduje dwukrotne uruchomienie zadania z różnymi zachowaniami, co wygląda dokładnie tak, jakby plik konfiguracyjny był ignorowany. Należy włączyć jeden timer i sprawdzić:

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

Skąd wiadomo, kiedy coś zostało zainstalowane?

emit_via w sekcji [emitters] steruje raportowaniem. W systemd emiter stdio zapisuje dane do dziennika, co jest niezawodną opcją, ponieważ nie wymaga instalacji żadnego dodatkowego oprogramowania:

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

Emiter motd zapisuje raport do pliku /etc/motd, zastępując jego dotychczasową zawartość. Jeśli plik ten jest używany do wyświetlania baneru powitalnego przy logowaniu, należy zrezygnować z tego emitera.

Emiter email otwiera połączenie SMTP (simple mail transfer protocol) do email_host na porcie email_port, których wartości domyślne to localhost oraz 25. Na świeżo zainstalowanym serwerze VPS żaden proces nie nasłuchuje na tym porcie, więc połączenie zostanie odrzucone, a wiadomość nie zostanie wysłana. Przed rozpoczęciem korzystania z tej funkcji należy uruchomić ss -lnt | grep ':25', a w przypadku braku wyników skonfigurować Postfix jako przekaźnik (relay-only). Gdy poczta działa poprawnie, temat wiadomości brzmi Updates applied on 'web01'., a nazwa pobierana jest z system_name.

W przypadku innych zastosowań emiter command przekazuje raport do wskazanego programu poprzez standardowe wejście:

[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}

Wartość send_error_messages domyślnie ustawiona jest na no, co oznacza, że nieudane uruchomienie nie generuje żadnego powiadomienia. Należy włączyć tę opcję. System aktualizacji, który informuje wyłącznie o sukcesach, jest gorszy niż jego brak, ponieważ cisza jest błędnie interpretowana jako stan poprawnego działania.

dnf-automatic nie restartuje usług

Instalacja pakietu zastępuje pliki na dysku. Proces, który już działa, utrzymuje stary kod w pamięci, więc poprawiona biblioteka nie wpływa na demona uruchomionego miesiąc temu. Ta rozbieżność między stanem zainstalowanym a efektywnym jest powodem, dla którego automatyczne aktualizacje wymagają polityki restartu, a nie tylko polityki instalacji.

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

-s wymienia usługi systemd, których pliki uległy zmianie po ich uruchomieniu. -r odpowiada na jedno pytanie i wyświetla jeden z dwóch bloków:

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 nie jest głęboką analizą. Sprawdza stałą listę pakietów: kernel, kernel-core, kernel-rt, glibc, linux-firmware, systemd, dbus, dbus-broker, dbus-daemon oraz microcode_ctl. Jeśli którykolwiek z nich został zainstalowany po ostatnim uruchomieniu systemu, otrzymasz pierwszą odpowiedź. Dodaj własne nazwy pakietów w pliku z rozszerzeniem .conf w katalogu /etc/dnf/plugins/needs-restarting.d/, gdy inny element systemu również wymaga restartu, aby zmiany weszły w życie.

Jedno zastrzeżenie dla skryptów: dnf needs-restarting -r kończy działanie z kodem wyjścia innym niż zero zarówno wtedy, gdy wymagany jest restart, jak i wtedy, gdy samo polecenie zakończyło się niepowodzeniem, więc sam kod wyjścia nie pozwala na rozróżnienie tych sytuacji. Należy odczytać tekst wyjściowy.

Restart usługi jest mniejszą zmianą i zazwyczaj właściwym rozwiązaniem. Zrestartuj demona SSH z drugiej, już otwartej sesji SSH, aby błędna konfiguracja nie spowodowała utraty dostępu. Nowe jądro systemu to przypadek, w którym pomaga tylko restart całego systemu, ponieważ działające jądro nie może zostać zastąpione w trakcie pracy. Jeśli chcesz podzielić poranne aktualizacje na te dwie kategorie, które aktualizacje wymagają restartu systemu, a które tylko restartu usługi przeprowadzi Cię przez analizę pakiet po pakiecie.

Kontenery stanowią osobny przypadek, ponieważ dnf-automatic aktualizuje pakiety hosta i nigdy nie ingeruje w przestrzeń użytkownika zawartą w obrazie. Dlatego serwer z uruchomionym Docker Engine na systemie Rocky Linux lub AlmaLinux wymaga również ponownego pobrania obrazów i odtworzenia kontenerów, zanim poprawka dotrze do kodu, który faktycznie obsługuje ruch sieciowy.

Czy serwer powinien restartować się automatycznie?

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

reboot = never jest ustawieniem domyślnym. when-changed wymusza restart po każdej zastosowanej aktualizacji. when-needed restartuje system tylko wtedy, gdy weryfikacja za pomocą needs-restarting -r wykaże wymianę pakietu rdzennego, co jest rozwiązaniem preferowanym przez większość właścicieli pojedynczych serwerów w połączeniu z samodzielnie wybranym oknem czasowym. Domyślne reboot_command wyświetla zalogowanym użytkownikom pięciominutowe ostrzeżenie za pośrednictwem shutdown; czas ten można wydłużyć.

Przed aktywacją tej funkcji należy rozstrzygnąć dwie kwestie. Każda usługa, od której zależy działanie systemu, musi uruchamiać się automatycznie podczas startu; jest to typowy problem w przypadku stosów Docker Compose uruchamianych ręcznie. Niezbędny jest również dostęp do konsoli lub trybu ratunkowego u dostawcy, ponieważ jądra, które nie uruchamia się poprawnie, nie można naprawić przez SSH. Jeśli brakuje któregokolwiek z tych elementów, należy zachować reboot = never i wykonywać restarty samodzielnie po uprzednim sprawdzeniu dziennika zdarzeń.

Rocky, AlmaLinux i CentOS Stream: różnice

W systemach Rocky 9 oraz AlmaLinux 9 powyższe kroki są identyczne, włącznie ze ścieżkami konfiguracji i nazwami jednostek. Oba systemy publikują erraty, więc upgrade_type = security posiada dane do filtrowania. Nieaktualne erraty Rocky, o których wspomniano wcześniej, stanowią jeden z niewielu punktów, w których codzienne działanie tych systemów faktycznie się różni. Jeśli serwer nie został jeszcze przygotowany, należy wziąć to pod uwagę wraz z obietnicą kompatybilności i wsparciem dla starszych procesorów, które odróżniają te dwa systemy.

CentOS Stream stanowi wyjątek i jest to różnica istotna. Repozytoria Stream nie zawierają updateinfo.xml, więc filtr bezpieczeństwa nigdy nie znajdzie dopasowania, a każde uruchomienie zgłosi No security updates needed. W systemie Stream należy użyć upgrade_type = default i zaakceptować fakt, że instalowane są wszystkie aktualizacje. Stream wyprzedza również RHEL, więc dane ustawienie zmienia się na maszynie ze Stream częściej niż to samo ustawienie na Rocky lub AlmaLinux. Ta różnica nie wynika z błędów w pakowaniu, lecz jest rezultatem decyzji Red Hat z 2020 roku, aby przekształcić CentOS w wersję zapoznawczą RHEL, co jest tą samą decyzją, która doprowadziła do powstania Rocky Linux i AlmaLinux.

Systemy Rocky 10 oraz AlmaLinux 10 przeszły na DNF5, co wiąże się ze zmianą nazw. Dokumentacja upstream DNF5 wskazuje timer jako dnf5-automatic.timer, umieszcza domyślne ustawienia dostarczone z oprogramowaniem w /usr/share/dnf5/dnf5-plugins/automatic.conf, podczas gdy nadpisania użytkownika nadal znajdują się w /etc/dnf/automatic.conf. Domyślnie download_updates ustawiono na yes zamiast no, a distro-sync dodano jako upgrade_type. Zapytanie o biuletyny to dnf advisory list, przy czym updateinfo zachowano jako alias. Przed skopiowaniem nazw pakietów lub jednostek z poradnika napisanego dla wersji 9, należy sprawdzić, co faktycznie zostało zainstalowane w danej wersji systemu:

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

Wiele opublikowanych poradników na ten temat dotyczy wyłącznie Rocky 8. Zestaw opcji rozrósł się od czasu ich powstania, dlatego należy sprawdzić plik z komentarzami na własnym serwerze, zamiast polegać na starym artykule.

Tryby awarii i komunikaty, które zobaczysz

Nic nie działa. systemctl list-timers dnf-automatic.timer wyświetla pustą tabelę, a systemctl is-enabled dnf-automatic.timer zwraca disabled. Pakiet został zainstalowany, ale timer nie.

Zadanie uruchamia się, ale nic nie instaluje. Dziennik zawiera No security updates needed, but 3 updates available. Filtr bezpieczeństwa nie dopasował żadnego elementu, ponieważ albo żadna oczekująca aktualizacja nie posiada biuletynu, albo repozytorium nie publikuje danych o biuletynach.

Ustawienie wydaje się ignorowane. DNF loguje nieznaną opcję w automatic.conf na poziomie debugowania, a następnie używa wartości domyślnej. Błędnie wpisany klucz nie powoduje żadnych zmian i nie generuje ostrzeżeń. Wpisz apply_update = yes, a apply_updates pozostanie na no, przez co serwer będzie pobierał dane w nieskończoność, ale nigdy ich nie zainstaluje. Po każdej edycji uruchom sudo systemctl start dnf-automatic.service i sprawdź dziennik zamiast polegać na zawartości pliku.

Zadanie uruchamia się dwa razy dziennie. Włączone są dwa timery. systemctl list-unit-files 'dnf-automatic*' pokazuje, które z nich działają, a dodatkowe instancje przekazują flagi, które nadpisują konfigurację z pliku.

Brak wiadomości e-mail. Albo nikt nie nasłuchuje na porcie 25 dla emitera email, albo send_error_messages nadal ma wartość no i jedyną rzeczą wartą zgłoszenia był błąd.

Zaktualizowana usługa nadal zgłasza starą wersję. Plik na dysku jest nowy, ale proces w pamięci jest stary. dnf needs-restarting -s wskazuje usługi, które należy zrestartować.

FAQ

Czy dnf-automatic instaluje na Rocky Linux tylko aktualizacje bezpieczeństwa?

Tylko jeśli w pliku /etc/dnf/automatic.conf ustawisz upgrade_type = security oraz jeśli repozytoria publikują metadane erraty. Rocky Linux i AlmaLinux publikują te dane, więc filtr może dopasować odpowiednie poprawki. Domyślne ustawienie to upgrade_type = default, które instaluje wszystkie dostępne aktualizacje, gdy tylko apply_updates = yes.

Dlaczego dnf-automatic zgłasza "No security updates needed, but 3 updates available"?

DNF określa, co jest aktualizacją bezpieczeństwa, odczytując updateinfo.xml z repozytorium, gdzie każda porada zawiera listę pakietów naprawczych. Gdy te metadane są nieobecne lub nieaktualne, filtr bezpieczeństwa nie znajduje dopasowań, podczas gdy zwykłe aktualizacje wciąż oczekują na instalację, co skutkuje wyświetleniem tego komunikatu. Jest to zachowanie typowe dla CentOS Stream, który w ogóle nie publikuje erraty. W przypadku Rocky Linux lub AlmaLinux porównaj dnf updateinfo list --security z dnf check-update i sprawdź, czy metadane są aktualne.

Czy dnf-automatic zrestartuje serwer po aktualizacji jądra?

Nie, chyba że zostanie to skonfigurowane. Opcja reboot ma domyślną wartość never. Ustaw reboot = when-needed, aby restart następował tylko wtedy, gdy sprawdzenie dnf needs-restarting -r wykaże, że pakiet rdzenny, taki jak kernel lub glibc, został zastąpiony od czasu ostatniego uruchomienia. reboot = when-changed wymusza restart po każdej zastosowanej aktualizacji. Obie opcje korzystają z reboot_command, którego domyślną wartością jest shutdown -r +5, co powoduje wyświetlenie ostrzeżenia dla zalogowanych użytkowników.

Jak zmienić godzinę uruchamiania dnf-automatic?

Uruchom sudo systemctl edit dnf-automatic.timer i dodaj sekcję [Timer] z pustą linią OnCalendar=, a następnie podaj harmonogram, na przykład OnCalendar=*-*-* 03:30. Pusta linia jest wymagana, ponieważ OnCalendar sumuje wartości; jej pominięcie spowoduje zachowanie domyślnego uruchomienia o 06:00 i dodanie kolejnego terminu. Zweryfikuj konfigurację za pomocą systemctl list-timers dnf-automatic.timer i sprawdź kolumnę NEXT.

Czy nadal muszę sprawdzać serwer, który aktualizuje się automatycznie?

Tak. dnf-automatic instaluje pakiety i na tym kończy działanie. Nie restartuje demonów i nie wysyła powiadomień, chyba że w emit_via wskazano emiter, który faktycznie monitorujesz. Ustaw emit_via na co najmniej stdio, włącz send_error_messages, aby otrzymywać raporty o błędach, oraz uruchom dnf needs-restarting -s po oknie serwisowym, aby zidentyfikować usługi nadal korzystające ze starego kodu.