Konfiguracja dnf-automatic: Rocky Linux i AlmaLinux

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

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 zawarte 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 narzędzie do unattended-upgrades na serwerze VPS z Ubuntu. 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 metadane dołączone do opublikowanych biuletynów bezpieczeństwa, które mogą być niekompletne lub nieaktualne. Jeśli wskażesz dnf-automatic na repozytorium pozbawione danych o biuletynach, narzędzie nie zainstaluje żadnych aktualizacji, raportując jednocześnie sukces operacji.

Przewodnik został przygotowany dla 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. Wydania 10 korzystają z DNF5, gdzie nazewnictwo uległo zmianie, dlatego poświęcono im oddzielną sekcję pod koniec dokumentu. Każde poniższe polecenie jest przeznaczone do wykonania na własnym serwerze; obok poleceń zamieszczono oczekiwane wyniki.

Instalacja dnf-automatic i analiza dostarczonej konfiguracji

Włączenie automatycznych aktualizacji powinno być częścią standardowej konfiguracji opisanej w pierwsze dziesięć minut na nowym VPS, zaraz po utworzeniu użytkownika innego niż root i skonfigurowaniu firewalla.

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ż zainstalowanie pakietu nie uruchamia żadnego procesu. Jest to najczęstsza przyczyna, dla której serwer z zainstalowanym dnf-automatic nigdy nie pobrał żadnej aktualizacji.

Wersja DNF ma znaczenie dla jednej 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 poprzez biuletyn RHBA-2023:6645. Rocky 9 oraz AlmaLinux 9 przebudowują ten pakiet, więc aktualny system go posiada, natomiast system nieaktualizowany od 2023 roku – nie.

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

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

download_updates oraz apply_updates w sekcji [commands] określają zachowanie narzędzia. W systemie EL9 (enterprise Linux 9, wspólna baza dla Rocky 9 oraz AlmaLinux 9) oba parametry są domyślnie ustawione na no, więc włączona usługa dnf-automatic bez edycji konfiguracji 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 połączenia z siecią, ale żadne zmiany nie są wprowadzane automatycznie.
• 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ądna konfiguracja początkowa dla serwera VPS wystawionego do Internetu:

[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 dla serwera tuż po uruchomieniu. random_sleep to starsza metoda rozkładania obciążenia na wiele maszyn; obecnie to zadanie realizuje timer. Uruchom systemctl cat dnf-automatic.service, aby sprawdzić 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 konfigurację z pliku tylko dla danego 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 publikowany wewnątrz repozytorium, w którym każde zalecenie (advisory) wymienia pakiety, które je naprawiają. AlmaLinux publikuje je jako zalecenia ALSA, Rocky publikuje je jako RLSA. upgrade_type = security buduje filtr na podstawie tych metadanych i aktualizuje tylko te pakiety, które do niego pasują.

Wynikają z tego dwie konsekwencje, z których obie bywają zaskakujące.

Po pierwsze, brak metadanych oznacza brak aktualizacji. Jeśli repozytorium nie zawiera updateinfo.xml, filtr nie dopasowuje żadnego pakietu, a proces kończy się następującym wpisem w dzienniku:

No security updates needed, but 3 updates available

System nie jest załatany, a nic nie zgłosiło błędu. Należy sprawdzić 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 zwraca żadnych wyników, oznacza to, że albo żadna oczekująca aktualizacja nie posiada przypisanego zalecenia, albo repozytorium nie zawiera danych o zaleceniach. Zarówno Rocky, jak i AlmaLinux publikują te dane, więc w tych systemach pusta lista zazwyczaj jest wiarygodna. 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 jest aktualizowany do najnowszej wersji dostępnej w repozytorium wraz ze wszystkimi zależnościami. Mniejszy krok, polegający na aktualizacji tylko do najwcześniejszej wersji naprawiającej dane zalecenie, to dnf upgrade-minimal --security wykonywane ręcznie. dnf-automatic nie posiada ustawienia dla takiego działania.

W przypadku Rocky istnieje jeszcze jedno zastrzeżenie. Rocky generuje swoją erratę na podstawie danych Red Hat poprzez własny potok przetwarzania, który miewa opóźnienia. We wrześniu 2025 roku użytkownicy zgłaszali, że updateinfo.xml dla Rocky 9 BaseOS nie zmieniło się od grudnia 2024 roku, przez co --security nie zawierało najnowszych zaleceń, co zespół Rocky potwierdził jako znany problem. Jeśli polegasz na upgrade_type = security, porównuj listę zaleceń z najnowszymi ogłoszeniami RLSA od czasu do czasu. Na serwerze, gdzie pokrycie aktualizacjami jest ważniejsze niż kontrola zmian, bezpieczniejszym ustawieniem jest upgrade_type = default uruchamiane zgodnie z wybranym harmonogramem.

Timer systemd, który faktycznie uruchamia zadanie

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

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

Dostarczony timer uruchamia się o *-*-* 6:00 za pomocą RandomizedDelaySec=60m oraz Persistent=true. Losowe opóźnienie rozkłada obciążenie floty serwerów w czasie jednej godziny, aby wszystkie maszyny nie łączyły się z serwerem lustrzanym w tej samej sekundzie. Persistent=true oznacza, że maszyna wyłączona o 06:00 wykona pominięte zadanie krótko po uruchomieniu, 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 się, więc bez tego wyczyszczenia 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 tworzeniu jednostek usług i timerów 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 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*'

Jak sprawdzić datę instalacji?

emit_via w sekcji [emitters] odpowiada za raportowanie. W systemie systemd emiter stdio zapisuje dane do dziennika (journal), co stanowi niezawodną opcję, ponieważ nie wymaga instalacji żadnego dodatkowego oprogramowania:

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

Emiter motd zapisuje raport w pliku /etc/motd, zastępując jego dotychczasową zawartość. Jeśli w tym miejscu przechowywany jest baner logowania, 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. Świeżo zainstalowany serwer VPS nie posiada usługi nasłuchującej 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 w trybie przekaźnika (relay-only). Gdy wysyłka poczty działa poprawnie, temat wiadomości brzmi Updates applied on 'web01'., a nazwa pobierana jest z system_name.

W przypadku innych rozwiązań 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 raportu. 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 poprawny.

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 w zeszłym miesiącu. 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 wyświetla listę usług systemd, których pliki uległy zmianie po ich uruchomieniu. -r odpowiada na jedno pytanie i wypisuje 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 narzędziem do głębokiej analizy. 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.

Ważna uwaga dla skryptów: dnf needs-restarting -r zwraca kod wyjścia różny od zera 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 analizować 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, ponieważ działające jądro nie może zostać zastąpione w trakcie pracy systemu.

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, że wymieniono pakiet rdzenny. Jest to rozwiązanie zalecane dla większości pojedynczych serwerów, w połączeniu z samodzielnie wybranym oknem czasowym. Domyślne reboot_command zapewnia zalogowanym użytkownikom pięciominutowe ostrzeżenie za pośrednictwem shutdown; wartość tę można zwiększyć.

Przed włączeniem 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 którykolwiek z tych warunków nie jest spełniony, 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ższa procedura jest identyczna, włącznie ze ścieżkami konfiguracji oraz nazwami jednostek. Oba systemy publikują erraty, dzięki czemu upgrade_type = security posiada dane do filtrowania.

CentOS Stream stanowi wyjątek i jest to przypadek istotny. 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 przypadku 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ę częściej na maszynie ze Stream niż w przypadku Rocky lub AlmaLinux.

Wersje Rocky 10 oraz AlmaLinux 10 przeszły na DNF5, co wiąże się ze zmianą nazewnictwa. Dokumentacja upstream dla 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. Wartość domyślna download_updates została zmieniona z no na yes, dodano także distro-sync 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 zweryfikować, 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 dostępnych opcji rozrósł się od czasu ich powstania, dlatego należy sprawdzić plik z komentarzami na własnej maszynie, 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 żadne oczekujące zadanie 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ść, nigdy ich nie instalując. 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 są aktywne, 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 jest nadal ustawione na 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 pod warunkiem, że repozytoria publikują metadane erraty. Zarówno Rocky Linux, jak i AlmaLinux publikują te dane, więc filtr ma dostęp do odpowiednich biuletynów. Domyślna konfiguracja to upgrade_type = default, która instaluje każdą dostępną aktualizację, 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żdy biuletyn zawiera listę powiązanych pakietów. Gdy te metadane są nieobecne lub nieaktualne, filtr bezpieczeństwa nie znajduje dopasowań, mimo że zwykłe aktualizacje 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 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 za pomocą dnf needs-restarting -r wykaże, że kluczowy pakiet, taki jak kernel lub glibc, został zastąpiony od czasu ostatniego uruchomienia. Opcja reboot = when-changed wymusza restart po każdej zastosowanej aktualizacji. Oba mechanizmy korzystają z reboot_command, który domyślnie ustawiony jest na shutdown -r +5 i wyświetla ostrzeżenie zalogowanym użytkownikom.

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 własny harmonogram, na przykład OnCalendar=*-*-* 03:30. Pusta linia jest wymagana, ponieważ OnCalendar sumuje wpisy; jej pominięcie spowoduje zachowanie domyślnego uruchomienia o 06:00 i dodanie drugiego terminu. Zweryfikuj ustawienia 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 jedynie instaluje pakiety. Nie restartuje demonów i nie wysyła powiadomień, chyba że w emit_via zdefiniowano emiter, który faktycznie monitorujesz. Ustaw emit_via przynajmniej na stdio, włącz send_error_messages, aby otrzymywać raporty o błędach, oraz uruchamiaj dnf needs-restarting -s po oknie serwisowym, aby zidentyfikować usługi, które nadal korzystają ze starego kodu.