Konfiguracja automatycznych aktualizacji bezpieczeństwa z unattended-upgrades

Między ukazaniem się aktualizacji bezpieczeństwa a jej instalacją na większości serwerów zieje luka. Rzadko bierze się ona z niedbalstwa, częściej stąd, że ktoś postanawia wgrać ją „w przyszłym tygodniu”. Skanery testują świeżo ujawnioną podatność w ciągu kilku godzin. Pakiet unattended-upgrades tę lukę zamyka.

Wersję skróconą znajdziesz jako krok 7 w liście kontrolnej dla nowego serwera root. Tutaj chodzi o wszystko, co dzieje się potem: aktualizacje bezpieczeństwa kontra wszystkie aktualizacje, zachowanie przy restarcie na serwerze gier, powiadomienie mailowe, wyłączone pakiety, przebieg próbny oraz dowód w logu.

Sprawdzone na Debianie 13 (trixie), Debianie 12 (bookworm), Ubuntu 24.04 LTS i Ubuntu 22.04 LTS. Tam, gdzie ta czwórka się różni, jest to zaznaczone. Polecenia zakładają konto root; jako zwykły użytkownik dopisz przed każdym sudo.

Co się tu właściwie dzieje

Szukanie błędów trwa tu długo, bo nie wiadomo, która z trzech uczestniczących części nie robi tego, co powinna:

1. Dwa timery systemd: apt-daily.timer dla list pakietów i pobierania, apt-daily-upgrade.timer dla instalacji.
2. Skrypt /usr/lib/apt/apt.systemd.daily, który interpretuje przełączniki spod APT::Periodic::.
3. Program unattended-upgrade, który interpretuje przełączniki spod Unattended-Upgrade:: i wykonuje całą pracę.

Zwróć uwagę na liczbę pojedynczą: pakiet unattended-upgrades, program unattended-upgrade.

systemctl list-timers 'apt-daily*' --all
systemctl cat apt-daily-upgrade.timer

Kolumny LAST i PASSED pokazują, czy jakikolwiek przebieg w ogóle się odbył. W samej jednostce stoi OnCalendar=*-*-* 6:00 wraz z RandomizedDelaySec=60m: przebieg wypada między szóstą a siódmą, a przy apt-daily.timer rozrzut wynosi dwanaście godzin. Kto zagląda o 06:05, niesłusznie uznaje mechanizm za zepsuty.

Zanim zmienisz cokolwiek: droga powrotna

Automatyczne aktualizacje wkraczają do akcji wtedy, gdy nie siedzisz przy klawiaturze. Trzy rzeczy mogą pójść źle: restart wyłącza serwer z ruchu, operacja na pakietach przerywa się i zostawia dpkg w stanie niedokończonym albo usługa po wszystkim już nie startuje.

Dostępem, który działa we wszystkich trzech przypadkach, nie jest SSH. Serwery root KVM i serwery dedykowane od KernelHosta nie mają IPMI ani iDRAC, wejście awaryjne prowadzi przez konsolę VNC w panelu klienta. Wisi ona na warstwie wirtualizacji albo na samym przyłączu, więc awaria w systemie gościa jej nie dotyka. Zaloguj się przez nią raz zawczasu i sprawdź hasło roota. Droga ratunkowa, którą wypróbowuje się dopiero w sytuacji awaryjnej, żadną drogą ratunkową nie jest.

Potem zabezpiecz stan wyjściowy:

mkdir -p /root/przed-unattended
cp -a /etc/apt/apt.conf.d/50unattended-upgrades /root/przed-unattended/
dpkg --get-selections > /root/przed-unattended/pakiety.txt
apt-mark showhold > /root/przed-unattended/holds.txt

Wyłącznik awaryjny występuje w dwóch wariantach. Twardo, przez timery:

systemctl disable --now apt-daily-upgrade.timer apt-daily.timer

Miękka droga ustawia w /etc/apt/apt.conf.d/20auto-upgrades wartość APT::Periodic::Unattended-Upgrade "0";. Listy pakietów pozostają wtedy aktualne, ale nic się nie instaluje.

Kontrola skuteczności:

systemctl is-enabled apt-daily-upgrade.timer
apt-config dump APT::Periodic

Do wycofania zmian: /var/log/apt/history.log podaje stary i nowy numer wersji. Ale apt install pakiet=wersja uda się tylko dopóty, dopóki stara wersja leży jeszcze na serwerze lustrzanym, a archiwa trzymają zwykle wyłącznie bieżący stan. Planuj więc naprawę w przód, nie wstecz, i trzymaj kopię zapasową.

Instalacja i faktyczne włączenie

apt update
apt install -y unattended-upgrades

Różnica między dystrybucjami: w Ubuntu 22.04 i 24.04 pakiet jest w obrazach serwerowych zainstalowany i aktywny, więc najpierw to sprawdź. W Debianie brakuje go w obrazach minimalnych, a instalacja pyta, czy stabilne aktualizacje mają być wgrywane automatycznie. Jeśli nie przebiega ona interaktywnie, na przykład podczas budowania obrazu, obowiązuje ustawienie domyślne i kluczowy plik w ogóle nie powstaje.

Bo sam pakiet niczego jeszcze nie włącza. Robi to dopiero ten plik:

cat /etc/apt/apt.conf.d/20auto-upgrades

Jeśli go nie ma, polecenie zgłasza cat: /etc/apt/apt.conf.d/20auto-upgrades: No such file or directory. Wtedy nadrób pytanie instalatora przez dpkg-reconfigure -plow unattended-upgrades albo napisz plik samodzielnie:

cat > /etc/apt/apt.conf.d/20auto-upgrades <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";
EOF

Wartości nie są przełącznikami tak/nie, tylko odstępami w dniach: "1" codziennie, "7" najwyżej raz w tygodniu, "0" wyłączone. AutocleanInterval sprząta pliki pakietów, których na serwerze lustrzanym już nie ma, co na małych dyskach systemowych widać gołym okiem (pełny dysk pod Linuksem).

Kontrola skuteczności: apt-config dump APT::Periodic wypisuje ustawione wiersze. Jeśli nie wypisuje nic, żaden plik nie został wczytany, a nocny przebieg nie zrobi nic.

Własne ustawienia we właściwym miejscu

Dostarczony z pakietem plik /etc/apt/apt.conf.d/50unattended-upgrades należy do tego pakietu. Jeśli go zmienisz, przy kolejnej aktualizacji pakietu powstanie konflikt wokół pliku konfiguracyjnego, a unattended-upgrades ten pakiet pominie. Narzędzie do automatycznych aktualizacji samo byłoby więc z nich wyłączone.

Własne wartości wpisuje się do osobnego pliku o wyższym numerze. APT czyta katalog alfabetycznie, a przy prostych wartościach wygrywa ta wczytana jako ostatnia:

cat > /etc/apt/apt.conf.d/52unattended-upgrades-local <<'EOF'
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";
Unattended-Upgrade::MinimalSteps "true";
EOF

MinimalSteps jest włączone fabrycznie i dzieli przebieg na małe kroki, które przy zamykaniu systemu da się czysto przerwać. Remove-Unused-Kernel-Packages usuwa stare kernele, które inaczej zapychają partycję /boot. Oba przełączniki sprzątające są fabrycznie ustawione w Ubuntu, w Debianie nie.

Nazwa pliku to nie drobiazg. APT czyta tu wyłącznie pliki bez rozszerzenia albo z .conf, i tylko nazwy złożone z liter, cyfr, łącznika, podkreślenia i kropki. Kopia zapasowa 52unattended-upgrades-local.bak zostaje po cichu pominięta, co akurat jest wygodne; plik 52-moje-ustawienia.txt tak samo, co wygodne już nie jest.

Kontrola skuteczności, od razu po każdej zmianie:

apt-config dump > /dev/null && echo "Składnia w porządku"
apt-config dump | grep "^Unattended-Upgrade::"

Brakujący średnik unieruchamia każde wywołanie apt, także to nocne.

Tylko aktualizacje bezpieczeństwa czy wszystkie aktualizacje

O tym, które pakiety wchodzą w grę, decyduje lista dozwolonych źródeł. Dystrybucje różnią się już samą nazwą klucza: Debian używa Unattended-Upgrade::Origins-Pattern, Ubuntu Unattended-Upgrade::Allowed-Origins.

sed -n '/Allowed-Origins\|Origins-Pattern/,/};/p' /etc/apt/apt.conf.d/50unattended-upgrades

Fabrycznie aktywne są wzorce dla źródła bezpieczeństwa oraz dla głównego archiwum własnego wydania. Zakomentowane są pockety -updates, -proposed i -backports. W Ubuntu stoją tam dodatkowo dwa wpisy dla rozszerzonej usługi utrzymania; bez wykupionej subskrypcji nie dostarczają one nic. Symbole zastępcze ${distro_id} i ${distro_codename} program rozwija w czasie działania, na przykład do Debian i trixie.

Skąd biorą się części składowe wzorca, pokazuje apt-cache policy. Przy każdym źródle stoi tam wiersz zaczynający się od release z polami o= (pochodzenie), a= (archiwum), n= (nazwa kodowa), l= (etykieta) oraz c= (komponent). Debianowe źródło bezpieczeństwa nosi etykietę Debian-Security i dokładnie w nią celuje dostarczony wzorzec.

Jeśli automatycznie mają przychodzić także bieżące poprawki dystrybucji, dopisz wzorzec we własnym pliku. Listy są w konfiguracji apt uzupełniane, a nie zastępowane:

Unattended-Upgrade::Origins-Pattern {
        "origin=Debian,codename=${distro_codename}-updates";
};

W Ubuntu odpowiednikiem jest "${distro_id}:${distro_codename}-updates"; w bloku Allowed-Origins. Całą listę zastąpisz tylko wtedy, gdy wcześniej wyczyścisz ją przez #clear Unattended-Upgrade::Origins-Pattern;.

Dla źródeł zewnętrznych obowiązuje ta sama procedura. Dostarczają one jednak często nowe wersje funkcjonalne zamiast czystych poprawek bezpieczeństwa, a wgrane nocą bez nadzoru to już inna klasa ryzyka. Dla systemów produkcyjnych zasada brzmi więc: zostań przy źródłach bezpieczeństwa.

Przebieg próbny

apt update
unattended-upgrade --dry-run --debug

apt update na początku to nie ozdobnik: przebieg próbny sam nie odświeża list pakietów, więc bez tego wywołania oceniasz wczorajszy stan. Nic nie zostaje zainstalowane. Liczą się cztery miejsca w wyniku:

• Allowed origins are: wraz z listą, która naprawdę obowiązuje. To jest dowód na to, że twoja zmiana dotarła, a nie zajrzenie do pliku.
• Initial blacklist: wraz z twoimi wyjątkami. Jeśli nic tam nie stoi, chociaż jakieś wpisałeś, twój plik nie jest wczytywany.
• Wiersze zaczynające się od Checking:, po jednym na pakiet, ze źródłem i decyzją o dopuszczeniu.
• Na końcu albo Packages that will be upgraded: wraz z listą, albo No packages found that can be upgraded unattended and no pending auto-removals.

Ten ostatni komunikat pojawia się również wtedy, gdy apt list --upgradable jak najbardziej wypisuje pakiety. To nie błąd, tylko filtr przy pracy: każdy pakiet, który się tam pojawia, a którego brakuje w przebiegu próbnym, pochodzi z niedozwolonego źródła, znajduje się na twojej liście wyjątków, jest przytrzymany przez apt-mark hold albo wywołuje pytanie o plik konfiguracyjny.

Wyłączanie pakietów spod automatu

Niektórych rzeczy nie chcesz aktualizować nocą: bazy danych, której restart odcina aplikację, albo kernela systemu, który nie ma się restartować bez zapowiedzi. Pierwsza z dwóch dróg działa tylko na automat:

Unattended-Upgrade::Package-Blacklist {
        "mariadb-server$";
        "nginx$";
        "linux-image-";
};

Wpisy są wyrażeniami regularnymi zakotwiczonymi na początku nazwy pakietu. "nginx" bez znaku dolara trafia dlatego także w nginx-common oraz nginx-full; $ ogranicza wpis dokładnie do tej jednej nazwy. Odwrotnie, "linux-image-" bez $ jest poprawne wtedy, gdy chodzi ci o wszystkie pakiety kernela.

Druga droga działa na każde wywołanie apt, a więc także na twoje ręczne apt upgrade:

apt-mark hold mariadb-server
apt-mark showhold

Cofa się to przez apt-mark unhold. Jeśli pakiet ma tylko nie być aktualizowany bez nadzoru, sięgnij po listę wyjątków; jeśli nie ma być aktualizowany w ogóle, po hold.

Kontrola skuteczności: apt-config dump | grep -i "Package-Blacklist" oraz apt-mark showhold. Niewygodna strona medalu: wyłączony pakiet musisz aktualizować sam. Zapisz sobie na to termin, inaczej za pół roku ten wyjątek będzie zapomnianą podatnością.

Automatyczny restart

Nowy kernel po aktualizacji leży na dysku, ale działa dopiero po restarcie; podmienione biblioteki zaczynają obowiązywać dopiero wtedy, gdy usługa wystartuje na nowo. Sterują tym trzy przełączniki:

Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-WithUsers "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Automatic-Reboot jest fabrycznie wyłączone. Automatic-Reboot-WithUsers jest fabrycznie włączone i to zaskakuje wielu: otwarta sesja SSH nie powstrzymuje restartu; kto tego oczekuje, ustawia wartość na "false". Automatic-Reboot-Time jest obowiązkowe, gdy tylko restart zostanie włączony. Bez tej wartości obowiązuje now, czyli serwer restartuje się zaraz po przebiegu, a więc między szóstą a siódmą rano.

Wyzwala go nie pakiet kernela, tylko plik znacznika:

ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs

Najbardziej brzemienna w skutki różnica w całym tym artykule: Ubuntu ten plik zakłada (pochodzi z pakietu update-notifier-common), a ten drugi wymienia odpowiedzialne za to pakiety. Debian standardowo go nie zakłada. Tam Automatic-Reboot "true" może pozostać trwale bezskuteczne, a nic przy tym nie zgłosi żadnego błędu. Kto na tym polega, chodzi miesiącami na starym kernelu z poczuciem, że wszystko gra. W Debianie pomaga zamiast tego:

apt install -y needrestart
needrestart -b

Wynik podaje pod NEEDRESTART-KCUR działający, a pod NEEDRESTART-KEXP oczekiwany kernel; jeśli się różnią, restart jest do zrobienia. Wiersze NEEDRESTART-SVC wymieniają usługi, które nadal pracują na podmienionych bibliotekach.

Dlaczego na serwerze gier ustawienie wygląda inaczej

Na serwerze WWW restart o 02:00 to kwestia kilku sekund i nikt tego nie zauważa. Na serwerze gier są podłączeni gracze, świat leży w pamięci RAM, a stan gry zapisuje się w całości dopiero przy uporządkowanym zamknięciu. Gdy proces zostanie ubity na twardo, tracisz postępy od ostatniego zapisu pośredniego, a w gorszym przypadku plik świata zostaje uszkodzony.

Dochodzi do tego szczegół systemd: przy zamykaniu systemu każda usługa dostaje swój sygnał zatrzymania, a po nim ograniczony czas, po którego upływie zostaje ubita na twardo. Serwer gry, który przy kończeniu dopiero zapisuje dane, potrzebuje zwykle więcej czasu, niż daje ustawienie domyślne, oraz polecenia zatrzymania, które wysyła do konsoli serwera stop, a nie tylko sygnał do skryptu startowego. Dla serwerów gier rozsądna jest dlatego taka kombinacja:

• Automatic-Reboot "false". Aktualizacje bezpieczeństwa dalej się wykonują, a restart pozostaje twoją decyzją.
• Okno serwisowe w porze małego obłożenia, zapowiedziane, a nie robione z zaskoczenia.
• Jednostka systemd z poleceniem zatrzymania, które zapisuje dane, i z odpowiednio dużym TimeoutStopSec, zobacz tworzenie usługi systemd.
• Jeśli jednak automatycznie, to Automatic-Reboot-Time na godzinę z niską liczbą graczy.

Sprawdzisz to bez restartu: zatrzymaj usługę przez systemctl stop, obejrzyj stan gry, uruchom ją ponownie. Jeśli przechodzi to czysto, serwer przetrwa także restart o 02:00.

Przesunięcie godziny przebiegu

systemctl edit apt-daily-upgrade.timer

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

Pusty wiersz OnCalendar= jest obowiązkowy, bo kasuje wartość dostarczoną z pakietem. Bez niego twoja godzina dochodzi jako dodatkowa i przebieg odbywa się dwa razy dziennie.

systemctl daemon-reload
systemctl restart apt-daily-upgrade.timer
systemctl list-timers 'apt-daily*' --all

Kontrola skuteczności: w kolumnie NEXT stoi nowa godzina.

Powiadomienie przez e-mail

Mechanizm, o którym nikt nic nie słyszy, nie jest nadzorowany, tylko zapomniany. Zmieniają to dwa wiersze:

Unattended-Upgrade::Mail "admin@twojadomena.pl";
Unattended-Upgrade::MailReport "on-change";

MailReport zna trzy wartości: always po każdym przebiegu, on-change tylko wtedy, gdy coś zostało zainstalowane albo poszło źle, only-on-error wyłącznie przy błędzie. Starszy przełącznik MailOnlyOnError zastąp nowym, jeśli go u siebie zastaniesz.

Warunkiem jest droga wysyłki. unattended-upgrades wysyła przez /usr/bin/mail albo /usr/sbin/sendmail. Jeśli brakuje obu, wysyłka po prostu nie następuje, a ty niczego nie zauważysz. Na świeżym serwerze to stan normalny:

apt install -y bsd-mailx
echo "Wiadomość testowa" | mail -s "Test z serwera" admin@twojadomena.pl

Przy okazji doinstalowuje się usługa transportu poczty. Sprawdź potem przez ss -lntp | grep ':25', czy nasłuchuje wyłącznie na 127.0.0.1. Wiadomości wysyłane wprost z adresu IP serwera lądują poza tym często w spamie; jeśli raport ma naprawdę docierać, poprowadź wysyłkę przez serwer przekaźnikowy z porządnie skonfigurowaną domeną nadawcy.

Praktyczna rada: na pierwsze dwa tygodnie ustaw always. Codzienna wiadomość z informacją, że nie było nic do zrobienia, to najprostszy dowód na to, że mechanizm działa. Potem wróć na on-change, bo inaczej wkrótce zaczniesz ją kasować bez czytania.

Jak sprawdzić, czy naprawdę coś się wydarzyło

ls -l /var/log/unattended-upgrades/
tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log

Leżą tam maksymalnie trzy pliki. unattended-upgrades.log odnotowuje, co program postanowił. unattended-upgrades-dpkg.log zawiera surowy wynik instalacji i tam zaglądasz wtedy, gdy pakiet wywrócił się przy konfiguracji. unattended-upgrades-shutdown.log powstaje przy przebiegu, który skończył się dopiero podczas zamykania systemu.

Przebieg bez zdarzeń kończy się na No packages found that can be upgraded unattended and no pending auto-removals. Przebieg, który coś zrobił, zawiera Packages that will be upgraded:, a niżej All upgrades installed. Jeśli plik jest pusty albo brakuje całego katalogu, żaden przebieg nigdy się nie odbył.

Niezależnie od tego menedżer pakietów zapisuje w logu każdą akcję ze starym i nowym numerem wersji:

grep -E "^(Start-Date|Commandline|Upgrade|End-Date):" /var/log/apt/history.log | tail -n 20
zgrep -h "^Upgrade:" /var/log/apt/history.log*.gz | tail -n 10

Drugie wywołanie sięga do plików po rotacji; kto patrzy tylko na bieżący, nic nie znajduje i wyciąga z tego błędny wniosek. Trzecim źródłem jest systemd:

journalctl -u apt-daily-upgrade.service --since "-7 days" --no-pager

Pułapka, w którą wpada prawie każdy: systemctl status unattended-upgrades.service pokazuje bez przerwy active (running). To nie jest trwająca aktualizacja. Ta jednostka domyka rozpoczęty przebieg podczas zamykania systemu, a poza tym czeka. Instalacja dzieje się w apt-daily-upgrade.service.

Typowe błędy i ich rozwiązania

cat: /etc/apt/apt.conf.d/20auto-upgrades: No such file or directory
Pakiet jest zainstalowany, ale nic nie zostało włączone; w Debianie to stan normalny po instalacji nieinteraktywnej. Zaradzisz temu przez dpkg-reconfigure -plow unattended-upgrades.

No packages found that can be upgraded unattended and no pending auto-removals, chociaż apt list --upgradable pokazuje pakiety
To nie błąd, tylko filtr. Sprawdź po kolei: dozwolone źródła w przebiegu próbnym, listę wyjątków, apt-mark showhold, pytania o pliki konfiguracyjne.

E: Syntax error /etc/apt/apt.conf.d/52unattended-upgrades-local:2: Extra junk at end of file
Brakujący średnik na końcu wiersza albo niezamknięty nawias klamrowy. Dopóki błąd tam siedzi, wywraca się każde wywołanie apt, nie tylko automat.

E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1234 (unattended-upgr) razem z E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
Automatyczny przebieg jest zajęty; zdradza to nazwa procesu ucięta do piętnastu znaków. Odczekaj kilka minut. Ubicie tego procesu wyprodukuje kolejny błąd z tej listy. Szerzej: apt nie mógł zdjąć blokady.

E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.
Wykonaj dokładnie to polecenie. Ustawiony fabrycznie Unattended-Upgrade::AutoFixInterruptedDpkg pozwala kolejnemu przebiegowi naprawić to samodzielnie, ale tylko wtedy, gdy w ogóle do tego miejsca dojdzie.

Package nginx-common has conffile prompt and needs to be upgraded manually w logu
Zmieniłeś plik konfiguracyjny, który należy do pakietu, a nowa wersja przynosi własny, zmieniony wariant. Program pomija wtedy ten pakiet już na stałe. Aktualizację zrób ręcznie. Otwarte przypadki pokaże:

find /etc -type f \( -name "*.dpkg-dist" -o -name "*.dpkg-new" -o -name "*.ucf-dist" \)

Cache has broken packages, exiting w logu
Po wcześniejszej operacji został niedokończony stan. apt --fix-broken install, a potem dpkg --configure -a. Do tego czasu automat co noc nie robi nic.

Twoje ustawienia nie działają, a żaden komunikat o błędzie się nie pojawia.
To znak rozpoznawczy pominiętej nazwy pliku. Sprawdź przez apt-config dump | grep -i unattended, czy wartości zostały wczytane.

Automatic-Reboot "true" w Debianie nic nie daje.
Brakuje tam pliku znacznika /var/run/reboot-required.

Porównanie czterech systemów

Czego automat nie zrobi

• Nie przeprowadzi przejścia na nowe wydanie główne ani nie ruszy źródeł zewnętrznych, dopóki nie wpiszesz dla nich wzorca.
• Nie ruszy niczego spoza menedżera pakietów. Ręcznie rozpakowane programy, rozszerzenia systemu zarządzania treścią, pluginy serwera gry i kontenery dalej chodzą na swoim starym stanie.
• Nie zastąpi kopii zapasowej ani monitoringu. Aktualizacja potrafi zatrzymać usługę, a jeśli nikt nie patrzy, usługa stoi do rana.
• Nie ochroni przed atakami sieciowymi. Aktualne pakiety zamykają znane podatności, natomiast przeciwko atakom wolumetrycznym pomaga wyłącznie filtrowanie w sieci przed serwerem, u KernelHosta w centrum danych maincubes we Frankfurcie nad Menem.

Kontrola końcowa

1. apt-config dump APT::Periodic wypisuje Update-Package-Lists "1" oraz Unattended-Upgrade "1".
2. apt-config dump | grep "^Unattended-Upgrade::" pokazuje twoje własne wartości.
3. systemctl list-timers 'apt-daily*' --all pokazuje oba timery z sensowną kolumną NEXT.
4. unattended-upgrade --dry-run --debug przechodzi bez błędów i wymienia oczekiwane źródła.
5. tail -n 40 /var/log/unattended-upgrades/unattended-upgrades.log zawiera po pierwszym przebiegu wpis z datą.
6. ls -l /var/run/reboot-required w Ubuntu, needrestart -b w Debianie.

Punkt piąty liczy się naprawdę i wymaga jednego dnia cierpliwości: wszystko wcześniejsze to przygotowanie, a dowodem jest dopiero wpis z dzisiejszej nocy.