Dlaczego aktualizacje trzeba testować: przypadek Debiana 12.3

Co się stało 9 grudnia 2023

Tego dnia miało ukazać się wydanie punktowe Debian 12.3 - rutynowa zbiorcza aktualizacja stabilnej dystrybucji. Zamiast obrazów pojawił się komunikat zatytułowany „Debian 12.3 image release delayed”. Jego treść jest krótka i warto ją przeczytać w oryginale:

Due to an issue in the ext4 file system with data corruption in kernel 6.1.64-1, we are pausing the planned Debian 12.3 point release images for today while we attend to fixes. Please do not upgrade any systems at this time, we urge caution for users with UnattendedUpgrades configured.

Po polsku: z powodu problemu w systemie plików ext4 powodującego uszkodzenie danych w jądrze 6.1.64-1 wstrzymujemy publikację obrazów wydania punktowego. Prosimy, aby w tej chwili nie aktualizować żadnych systemów, a szczególną ostrożność zalecamy osobom, które mają skonfigurowane automatyczne aktualizacje.

Zwróć uwagę na ostatnie zdanie. Opiekunowie dystrybucji nie napisali po prostu „uważajcie”. Wymienili z nazwy jeden konkretny mechanizm - i nie był to ani sposób instalacji, ani konfiguracja serwera, tylko automatyczne aktualizacje. Zrobili tak, bo doskonale wiedzieli, kogo ten problem dotknie najszybciej i bez ostrzeżenia.

Co mówi zgłoszenie 1057843

Komunikat odsyła do zgłoszenia numer 1057843 w systemie śledzenia błędów Debiana. Nagłówek zgłoszenia mówi wszystko, co potrzebne do oceny ryzyka:

Treść samego zgłoszenia jest równie zwięzła: „There might be a ext4 data corruption issue with the kernel released in the 12.3 bookworm point release (which is addressed in 6.1.66 upstream already)” - może występować problem uszkodzenia danych na ext4 w jądrze wydanym w wydaniu punktowym 12.3, poprawiony już w wersji 6.1.66 powyżej dystrybucji.

Dalej w wątku pojawia się potwierdzenie, że poprawka działa: ktoś uruchomił test preadv03_64 z pakietu testów Linux Test Project na systemie plików ext4, na jądrze opisanym jako Debian 6.1.66-1 (2023-12-06). Zgłoszenie zostało zarchiwizowane 8 marca 2024 roku.

Trzy rzeczy z tej tabeli zasługują na uwagę. Po pierwsze, to nie była luka bezpieczeństwa, tylko regresja - coś, co wcześniej działało, przestało działać poprawnie. Po drugie, dotyczyła jądra i systemu plików, czyli warstwy, która nie ma nad sobą nic, co mogłoby złagodzić skutki. Po trzecie, waga grave z uzasadnieniem mówiącym o utracie danych oznacza kategorię, przy której nie ma miejsca na „poczekamy, zobaczymy”.

Dlaczego ten przypadek jest inny

Awaria po aktualizacji zwykle wygląda tak: usługa nie wstaje, strona zwraca błąd, ktoś dzwoni. Jest nieprzyjemnie, ale widać ją od razu i da się cofnąć - przywrócić poprzednią wersję pakietu, odtworzyć maszynę z kopii, wrócić do migawki.

Uszkodzenie danych w systemie plików nie należy do tej kategorii i różni się trzema rzeczami:

• Nie widać go natychmiast. System wstaje, usługi działają, monitoring jest zielony. Uszkodzone są pojedyncze zapisy, a to wychodzi dopiero przy odczycie - czasem po godzinach, czasem po tygodniach.
• Cofnięcie pakietu nie cofa szkody. Powrót do poprzedniego jądra zatrzymuje powstawanie nowych uszkodzeń, ale nie naprawia tych, które już powstały. Dane trzeba odtworzyć z kopii zapasowej.
• Zatruwa kopie zapasowe. To jest najgorszy element. Jeżeli uszkodzenie działo się kilka dni, kopie z tych dni zawierają już uszkodzone dane. Im później je zauważysz, tym głębiej trzeba sięgnąć wstecz - i tym więcej pracy przepada.

Dlatego w tej jednej kategorii błędów czas między publikacją pakietu a jego instalacją ma realną wartość. W przypadku Debiana 12.3 ostrzeżenie i poprawka pojawiły się w ciągu dni. Kto aktualizował ręcznie i z rozeznaniem, miał szansę tego okna nie przegapić. Kto miał włączony automat, mógł nie mieć żadnej.

Co automat robi domyślnie

Tu zaczyna się część, której nie chcieliśmy opisywać z pamięci. Odczytaliśmy konfigurację, którą pakiet przynosi ze sobą, na maszynach testowych z Debianem 13 i Ubuntu 24.04. Stan na wrzesień 2026.

Debian 13, pakiet w wersji 2.12

Aktywne wpisy w /etc/apt/apt.conf.d/50unattended-upgrades - po odfiltrowaniu zakomentowanych - wyglądają tak:

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

Pierwsza linia jest tą, na którą warto spojrzeć dwa razy. label=Debian to główne archiwum stabilnego wydania, a nie repozytorium bezpieczeństwa. Komentarz w tym samym pliku opisuje to wprost: „Software will be the latest available for the named release” - oprogramowanie będzie najnowsze dostępne dla danego wydania.

A właśnie do głównego archiwum stabilnego wydania trafiają wydania punktowe. Czyli ta zbiorcza aktualizacja, która 9 grudnia 2023 niosła jądro 6.1.64-1.

Nie trzeba wierzyć plikowi na słowo - narzędzie samo raportuje, co uznaje za dozwolone:

$ sudo unattended-upgrade --dry-run --debug
Allowed origins are: origin=Debian,codename=trixie,label=Debian,
                     origin=Debian,codename=trixie,label=Debian-Security,
                     origin=Debian,codename=trixie-security,label=Debian-Security

Druga rzecz, którą sprawdziliśmy, to lista wyjątków. Sekcja Unattended-Upgrade::Package-Blacklist w domyślnej konfiguracji Debiana jest pusta. Nie ma tam ani jądra, ani bazy danych, ani niczego innego. Wszystko, co pasuje do wzorca źródeł, kwalifikuje się do automatycznej instalacji.

Ubuntu 24.04, pakiet w wersji 2.9.1

Ten sam plik na Ubuntu ma inny zestaw aktywnych wpisów:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}";
        "${distro_id}:${distro_codename}-security";
        "${distro_id}ESMApps:${distro_codename}-apps-security";
        "${distro_id}ESM:${distro_codename}-infra-security";
};

Tu również pierwsza pozycja to kieszeń wydania, a nie samo bezpieczeństwo. Warto zauważyć, czego na obu listach nie ma: kieszeni -updates, choć jest ona skonfigurowana w źródłach obu systemów. To celowa decyzja opiekunów pakietu, ale nie zmienia wniosku - zakres automatu jest szerszy niż „tylko poprawki bezpieczeństwa”.

Restart

Na obu systemach ustawienie Unattended-Upgrade::Automatic-Reboot jest zakomentowane, czyli automatyczny restart jest domyślnie wyłączony. To dobra wiadomość, ale ma drugą stronę: po aktualizacji jądra system dalej pracuje na starym, dopóki ktoś go nie zrestartuje. Powstaje rozjazd między tym, co jest zainstalowane, a tym, co faktycznie działa - i łatwo go przeoczyć, skoro nikt nie musiał niczego zatwierdzać.

Złudzenie „tylko bezpieczeństwo”

Najczęstsze uzasadnienie automatycznych aktualizacji brzmi: instalujemy tylko poprawki bezpieczeństwa, więc ryzyko jest minimalne. Pomiar z poprzedniej sekcji pokazuje, że domyślna konfiguracja nie robi tylko tego - na obu systemach pierwsza pozycja listy to kieszeń wydania, czyli zwykłe archiwum.

Ale nawet gdyby ograniczyć automat wyłącznie do repozytorium bezpieczeństwa, złudzenie pozostaje. Poprawka bezpieczeństwa to też zmiana kodu, często w bibliotece, z której korzysta wszystko w systemie. Poprawki bezpieczeństwa bywają pilne i przez to trafiają do wydania po krótszych testach niż zwykłe zmiany. Nie ma reguły mówiącej, że zmiana oznaczona jako bezpieczeństwo nie może zepsuć działającej usługi - jest tylko reguła mówiąca, że trzeba ją zainstalować szybciej.

Przypadek Debiana 12.3 jest tu szczególnie wymowny, bo pokazuje coś jeszcze: problem przyszedł nie z repozytorium bezpieczeństwa, lecz ze zwykłego wydania punktowego. Gdyby ktoś zawęził automat do samego bezpieczeństwa, tego akurat jądra by nie dostał. Gdyby zostawił konfigurację domyślną - dostałby.

Czy to znaczy: nigdy?

Nie. Uczciwa odpowiedź jest bardziej nudna niż hasło w tytule i brzmi: to zależy od tego, co się stanie, gdy automat się pomyli.

Automatyczne aktualizacje rozwiązują realny problem. Serwer, którego nikt nie aktualizuje miesiącami, jest niebezpieczny w sposób znacznie bardziej przewidywalny niż serwer, który raz na kilka lat trafi na złą aktualizację. Wyłączenie automatu bez zbudowania procesu w jego miejsce jest zmianą na gorsze, nie na lepsze. Największym zagrożeniem dla większości serwerów nie jest wadliwe wydanie punktowe, tylko dziura załatana rok temu i nigdy niezainstalowana.

Rozstrzygające jest pytanie o koszt błędu:

Wzorzec jest prosty: im trudniej odtworzyć to, co maszyna trzyma, tym mniej automatu. Nie dlatego, że aktualizacje są złe, tylko dlatego, że na takiej maszynie nie chcemy zmian, których nikt nie zatwierdził i nikt nie obserwuje.

Jak testować aktualizacje

Testowanie aktualizacji brzmi jak duży proces, a w praktyce sprowadza się do czterech nawyków. Żaden nie wymaga osobnego narzędzia.

1. Zobacz, co się wydarzy, zanim się wydarzy. Apt potrafi pokazać plan bez jego wykonania:

sudo apt-get update
sudo apt-get -s upgrade        # -s to symulacja, nic nie instaluje

Jeżeli na liście pojawia się jądro, biblioteka podstawowa albo silnik bazy danych, to nie jest aktualizacja do zrobienia między jednym telefonem a drugim.

2. Miej gdzie sprawdzić. Maszyna testowa z tym samym wydaniem systemu i tym samym stosem co produkcja wystarczy, żeby aktualizacja przeszła najpierw tam. Nie musi to być kosztowne - lab z kilkoma maszynami mieści się na zwykłym laptopie, a odtworzenie zepsutej maszyny trwa minuty.

3. Rozłóż wdrożenie w czasie. Najpierw środowisko testowe, potem jedna maszyna produkcyjna, a dopiero po kilku dniach reszta. Ten odstęp jest właśnie tym, co w grudniu 2023 uratowało tych, którzy go mieli - ostrzeżenie i poprawka pojawiły się w ciągu dni.

4. Czytaj, zanim zatwierdzisz. Komunikaty na stronie dystrybucji i lista zmian pakietu to dwie minuty. Właśnie tam 9 grudnia 2023 stało zdanie „prosimy nie aktualizować żadnych systemów”.

Warto też wiedzieć, czego test nie da. Sprawdzenie na czystej maszynie testowej pokaże, czy aktualizacja nie psuje samego systemu i usług. Nie pokaże, czy nie psuje Twoich danych ani Twojej konfiguracji narastałej latami - a to jest dokładnie ta kategoria, w którą trafił błąd z tego artykułu. Dlatego test nie zastępuje kopii zapasowej, tylko ją uzupełnia.

Ustawienia, które warto zmienić

Jeżeli po tej lekturze zostajesz przy automacie - a na części maszyn to rozsądny wybór - poniżej trzy zmiany, które wynikają wprost z tego, co zmierzyliśmy.

Zawęź źródła do samego bezpieczeństwa. Usuń z aktywnej listy pozycję odpowiadającą głównemu archiwum wydania, zostawiając wpisy z etykietą bezpieczeństwa. Zmiana jest jednym wierszem, a wyłącza z automatu całą kategorię, do której należało jądro z 12.3.

Wyłącz jądro i to, co trzyma dane. Pusta domyślnie lista wyjątków to miejsce, w którym można wypisać pakiety wymagające decyzji człowieka:

Unattended-Upgrade::Package-Blacklist {
        "linux-image-";
        "linux-headers-";
        "mariadb-server";
        "postgresql-";
};

Nazwy dopasuj do własnego stosu - powyższe są przykładem, nie zaleceniem uniwersalnym. Zasada brzmi: wypisz to, czego uszkodzenie kosztuje więcej niż opóźnienie łatki.

Nie włączaj automatycznego restartu. Jest domyślnie wyłączony i tak powinno zostać. Restart po aktualizacji jądra to decyzja o przerwie w działaniu usługi i należy do człowieka, który wie, co akurat na tej maszynie się dzieje. Zamiast tego warto monitorować, czy restart jest potrzebny - plik /var/run/reboot-required pojawia się właśnie w takiej sytuacji.

Jeżeli automat ma zniknąć, użyj reguły priorytetu, a nie samego usunięcia. Pakiet usunięty może wrócić jako zależność miękka czegoś innego; reguła z priorytetem ujemnym blokuje instalację także w takiej sytuacji, a jej działanie sprawdzisz przez apt-cache policy. Mechanizm opisujemy w artykule o priorytetach APT.

I rzecz najważniejsza, niezależna od ustawień: automat musi zostawiać ślad, który ktoś ogląda. Jeżeli nikt nie sprawdza, co zostało zainstalowane, to o zmianie dowiesz się dopiero z awarii - i nie będziesz wiedział, kiedy nastąpiła.

Granice tego wniosku

1. Jeden incydent to nie statystyka. Opisujemy jeden przypadek z grudnia 2023, bo jest dobrze udokumentowany i dotyczył stabilnej dystrybucji. Nie twierdzimy, że takie zdarzenia są częste - przeciwnie, są rzadkie. Rzadkie zdarzenie o wysokim koszcie wymaga jednak innej odpowiedzi niż częste o niskim.
2. Nie badaliśmy przyczyny w kodzie jądra. Wątek techniczny upstream jest zabezpieczony przed automatycznym pobieraniem i nie udało się go odczytać. Opieramy się wyłącznie na komunikacie Debiana i treści zgłoszenia 1057843.
3. Konfiguracje sprawdziliśmy we wrześniu 2026. Wartości domyślne pakietu unattended-upgrades mogą się zmienić między wydaniami. Sprawdź swoją wersję u siebie, zamiast przepisywać wartości z tego artykułu.
4. Nie odtwarzaliśmy samego błędu. Nie uruchamialiśmy jądra 6.1.64-1 ani testu, który ujawnia uszkodzenie. Opis skutków pochodzi z klasyfikacji w zgłoszeniu, nie z naszego pomiaru.

Checklista

1. Wiesz, czy na Twoich serwerach unattended-upgrades jest zainstalowany - sprawdziłeś, zamiast zakładać. Na obrazach chmurowych jest domyślnie.
2. Jeżeli ma go nie być, usunięcie uzupełniłeś regułą priorytetu, żeby nie wrócił jako zależność.
3. Jeżeli jest, wiesz, które źródła ma na aktywnej liście, i sprawdziłeś to przez unattended-upgrade --dry-run --debug.
4. Lista wyjątków nie jest pusta na maszynach, które trzymają dane.
5. Automatyczny restart pozostaje wyłączony, a potrzebę restartu ktoś monitoruje.
6. Masz gdzie sprawdzić aktualizację przed produkcją, na tym samym wydaniu systemu.
7. Wdrożenie jest rozłożone w czasie: test, jedna maszyna, reszta po kilku dniach.
8. Przed większą aktualizacją zaglądasz na stronę dystrybucji i do listy zmian.
9. Kopie zapasowe są testowane odtworzeniem, bo przy uszkodzeniu danych to one są ostatnią linią.
10. Aktualizacje zostawiają ślad w logu, który ktoś faktycznie ogląda.

Historia Debiana 12.3 nie jest argumentem przeciwko aktualizowaniu systemów. Jest argumentem za tym, żeby ktoś wiedział, co i kiedy zostało na nich zainstalowane. Dystrybucja wychwyciła problem, wstrzymała publikację i ostrzegła tego samego dnia. Cała ta praca dociera jednak tylko tam, gdzie po drugiej stronie jest ktoś, kto może ją przeczytać i zareagować. Automat jest dobrym narzędziem wszędzie tam, gdzie pomyłka kosztuje godzinę. Tam, gdzie kosztuje dane klienta, decyzja powinna należeć do człowieka.