Debian 13 w praktyce: nowości w repozytoriach i co się zmieni dla adminów

Debian 13 w kontekście poprzednich wydań: co się naprawdę zmienia

Cykl wydawniczy Debiana a miejsce Debiana 13

Debian od lat trzyma dość przewidywalny cykl życia: gałąź unstable (sid), zamrażanie testing, a po stabilizacji – nowe stabilne wydanie co około dwa lata. Debian 11 i 12 zbudowały reputację bardzo przewidywalnej platformy serwerowej, ale też nieco „zachowawczej” jeśli chodzi o wersje oprogramowania. Debian 13 wpisuje się w ten schemat, lecz przesuwa granicę między konserwatyzmem a aktualnością pakietów.

Dla administratora istotne jest to, że Debian 13 nie jest rewolucją w stylu zmiany init na systemd sprzed lat, ale raczej większą ewolucją. Z punktu widzenia repozytoriów pojawia się dopracowanie podziału na komponenty, odświeżone wersje kernela, systemd i bibliotek podstawowych oraz mocniejsze uporządkowanie kwestii firmware. Efekt: mniej „kombinowania” przy instalacji na nowszym sprzęcie i stabilniejsze środowisko do utrzymania w dłuższym horyzoncie.

Cykl wsparcia pozostaje zbliżony do poprzednich wydań. Stabilne wydanie ma pełne wsparcie bezpieczeństwa przez kilka lat, a potem część luki wypełniają inicjatywy LTS. To oznacza, że Debian 13 będzie fundamentem sporej części serwerów produkcyjnych i VPS-ów jeszcze długo po jego premierze. Warto więc zrozumieć, jakie decyzje projektowe stoją za tym wydaniem i jak wpłyną na codzienną administrację.

Stabilność kontra nowe wersje pakietów

Fundamentalne założenie się nie zmienia: Debian 13 pozostaje dystrybucją, która priorytetowo traktuje stabilność API/ABI, przewidywalne zachowanie i bezpieczeństwo. „Nowość” nie jest celem samym w sobie. Z drugiej strony od kilku wydań widoczna jest presja ze strony środowisk chmurowych i developerów, by stable nie był już „skamieniałą” wersją sprzed kilku lat.

W Debianie 13 więcej komponentów pojawia się w wersjach zbliżonych do aktualnych wydań upstream, ale nadal przechodzi intensywne testy. Dotyczy to m.in. kernela, systemd, narzędzi kontenerowych, głównych kompilatorów i bibliotek sieciowych. Zwiększa to kompatybilność z nowoczesnymi środowiskami (np. Kubernetes, nowe generacje hypervisorów) bez porzucania charakterystycznej dla Debiana przewidywalności. Admini zyskują w ten sposób lepsze wsparcie dla nowszego sprzętu i frameworków, ale muszą też wyostrzyć uwagę przy aktualizacjach większych komponentów.

W praktyce oznacza to np. bardziej „ruchome” środowisko systemd, nowsze domyślne algorytmy kryptograficzne w OpenSSH czy zmiany w obsłudze sieci. Migrując z Debiana 11/12 na 13, trzeba przygotować się na to, że niektóre stare obejścia i hacki przestaną działać, bo przestały być wspierane przez świeższe wersje pakietów.

Mit o wiecznie przestarzałym Debianie

Częsty stereotyp: „Debian jest zawsze przestarzały, więc do niczego się nie nadaje poza małymi serwerami WWW”. Rzeczywistość w Debianie 13 wygląda inaczej. Owszem, nie jest to dystrybucja typu rolling release, ale w wielu obszarach różnica względem „najświeższych” upstreamów zmalała. Zwłaszcza w komponentach krytycznych dla bezpieczeństwa i sieci Debian trzyma się bliżej obecnych wydań.

Mit bierze się często z porównywania samych numerów wersji, bez uwzględnienia patchy bezpieczeństwa backportowanych przez maintainerów Debiana. Dla admina liczy się to, czy pakiet jest bezpieczny, wspierany i przewidywalny, a nie to, czy numer jest identyczny z aktualnym wydaniem upstream. Debian 13 nadal preferuje backportowanie poprawek zamiast ciągłego skakania po głównych wydaniach, ale robi to w sposób bardziej świadomy wymogów chmury i nowoczesnych aplikacji.

Dobrze widać to w repozytoriach backports i security: nowsze wersje krytycznych narzędzi pojawiają się szybciej, a admin ma większą kontrolę nad tym, które pakiety są „podciągane” do wersji z backportów. Z punktu widzenia utrzymania infrastruktury ważne jest, że Debian 13 redukuje konieczność korzystania z nieoficjalnych repozytoriów tylko po to, by mieć np. nowszy kernel lub narzędzia sieciowe.

Znaczenie Debiana 13 dla serwerów, VPS-ów i desktopów adminów

Na serwerach bare-metal Debian 13 oznacza przede wszystkim lepsze wsparcie sprzętowe (dzięki nowemu kernelowi i firmware), mocniejsze domyślne ustawienia bezpieczeństwa oraz świeższe wersje serwerów usług (nginx, PostgreSQL, MariaDB, OpenSSH). Dla sporej części środowisk oznacza to możliwość rezygnacji z własnoręcznie kompilowanych pakietów albo egzotycznych repozytoriów, które były potrzebne tylko po to, by obsłużyć nową generację kart sieciowych czy macierzy.

W świecie VPS-ów Debian 13 będzie jednym z domyślnych obrazów w większości większych chmur i dostawców hostingowych. Tutaj główną korzyścią jest przewidywalne zachowanie repozytoriów security i prostsze zarządzanie aktualizacjami – zwłaszcza gdy infrastrukturą zarządza się przez Ansible, Puppet czy Salt. Dobrze ułożona struktura repozytoriów ułatwia też używanie mirrorów lokalnych.

Na desktopach adminów Debian 13 przynosi nowsze środowiska graficzne i narzędzia developerskie, co bywa istotne, jeśli stacje robocze są oparte na Debianie stable. Można wówczas częściej obyć się bez mieszania stable z testingiem – co jest źródłem wielu problemów – i skorzystać z backportów jako kontrolowanego źródła nowszych pakietów. To przekłada się bezpośrednio na mniejszą liczbę „dziwnych” błędów, gdy na tej samej maszynie pracuje się jako deweloper i administrator.

Nowości w oficjalnych repozytoriach Debiana 13

Struktura: main, contrib, non-free i non-free-firmware

Podział pakietów w Debianie na komponenty main, contrib i non-free jest znany od dawna. Debian 13 doprecyzowuje ten podział i rozwija osobny komponent non-free-firmware. Powód jest prosty: potrzeby praktyki wyprzedziły „czyste” ideały wolnego oprogramowania, szczególnie w kontekście sterowników i firmware’u do współczesnego sprzętu.

Komponenty w Debianie 13 w uproszczeniu:

• main – wyłącznie wolne oprogramowanie, zgodne z DFSG. Tylko te pakiety są oficjalnie wspierane na wszystkich nośnikach instalacyjnych.
• contrib – pakiety wolne, ale zależne od niewolnych komponentów (np. wymagające sterowników z non-free-firmware).
• non-free – niewolne aplikacje, biblioteki i inne składniki, które nie spełniają DFSG.
• non-free-firmware – zamknięty firmware, głównie do urządzeń sprzętowych: karty sieciowe, kontrolery RAID, GPU i inne.

W Debianie 13 instalatory i obrazy systemu mogą domyślnie korzystać z non-free-firmware, jeśli użytkownik na to pozwoli. To radykalnie zmniejsza liczbę przypadków, w których po instalacji serwera nie działa sieć, bo brakuje zamkniętego firmware do karty. Dla admina oznacza to mniej gimnastyki z dogrywaniem paczek firmware-* z pamięci USB czy sieci.

Firmware i sterowniki: skutki dla bare-metal i VM

Dla serwerów bare-metal Debian 13 jest znacznie łagodniejszy niż poprzednie wydania, jeśli chodzi o obsługę współczesnego sprzętu. W praktyce na instalatorach częściej dostępne są pakiety z non-free-firmware, dzięki czemu instalacja na nowych serwerach rackowych czy microserwerach przebiega bez dodatkowych trików. Dotyczy to przede wszystkim:

• kart sieciowych 10/25/40/100GbE,
• kontrolerów RAID i HBA,
• niektórych kontrolerów dysków NVMe,
• układów Wi-Fi (głównie na desktopach, ale nie tylko).

W środowiskach wirtualnych (KVM, VMware, Hyper-V, chmury publiczne) zmiana jest mniej odczuwalna, ale nadal istotna dla obrazów bazowych. Wiele chmur korzysta z wirtualnych kart sieciowych i kontrolerów dyskowych wymagających minimalnego zestawu sterowników i firmware, który Debian 13 ma lepiej skatalogowany i dostępny w spójnym komponencie.

Mit, z którym często zmagali się admini: „na Debianie stable nowy serwer się nie instaluje, trzeba dać jakiegoś rolling’a”. Debian 13 redukuje ten problem – oczywiście nie w 100%, ale wyraźnie częściej „po prostu działa” na nowszym sprzęcie bez ręcznego kombinowania z firmware. Jednocześnie sposób wydzielenia non-free-firmware zostawia tym, którzy chcą trzymać się wyłącznie wolnego oprogramowania, możliwość świadomej rezygnacji z zamkniętych komponentów.

Kluczowe zaktualizowane komponenty: kernel, systemd, narzędzia bazowe

Jądro Linuksa w Debianie 13 pochodzi z nowszej generacji niż w Debianie 12. To skutkuje lepszą obsługą nowego sprzętu (CPU, chipsety, kontrolery), nowszymi sterownikami sieciowymi, lepszym wsparciem wirtualizacji i konteneryzacji. Dla adminów oznacza to np.:

• lepszą obsługę nowoczesnych funkcji CPU wykorzystywanych przez hypervisory,
• stabilniejsze działanie storage’u opartego na NVMe i nowoczesnych macierzach,
• nowsze funkcje bezpieczeństwa w jądrze (np. rozszerzone mechanizmy izolacji).

Systemd w Debianie 13 jest w wersji znacznie bliższej bieżącym wydaniom upstream. To wpływa na zachowanie jednostek, logikę restartów usług, integrację z journald oraz mechanizmy sandboxingu. Z jednej strony zyskuje się dostęp do usprawnień (lepsze logowanie, nowe typy jednostek, bardziej granularne limity zasobów), z drugiej – część dawnych obejść „pod systemd” przestaje działać lub wymaga aktualizacji.

Do tego dochodzą zaktualizowane narzędzia sieciowe (iproute2), biblioteki C (glibc), narzędzia kryptograficzne i kompilatory. W wielu przypadkach różnice będą widoczne dopiero przy kompilacji aplikacji lub specyficznych konfiguracjach sieci, ale dla adminów oznacza to generalnie lepsze wsparcie dla współczesnych stosów aplikacyjnych (np. nowsze wersje runtime’ów języków, bibliotek TLS, sterowników bazodanowych).

Repozytoria security, updates i backports

Repozytoria bezpieczeństwa i aktualizacji utrzymywanych w stable mają krytyczne znaczenie w pracy administratora. W Debianie 13 zachowane zostają dobrze znane kanały:

• stable – główne repozytorium, praktycznie niezmienne poza poważnymi poprawkami,
• stable-updates – nieliczne, ważne aktualizacje wymagające szybszego wypuszczenia niż zwykłe point-release,
• security – dedykowane aktualizacje bezpieczeństwa, wydawane równolegle,
• backports – nowsze wersje wybranych pakietów skompilowane przeciwko bibliotekom z aktualnego stable.

W Debianie 13 większy nacisk kładzie się na to, aby backporty były pełnoprawnym narzędziem dla adminów, a nie „ostatnią deską ratunku”. Więcej kluczowych pakietów serwerowych i narzędzi będzie utrzymywanych w backports, co pozwala w sposób kontrolowany „podnosić” pojedyncze komponenty bez rozbijania całego systemu przez mieszanie stable z testing.

Z kolei repozytorium security jest jeszcze mocniej zsynchronizowane z głównym wydaniem, zarówno jeśli chodzi o mechanizmy podpisywania, jak i struktury katalogów. Dzięki temu konfiguracja sources.list staje się prostsza i mniej podatna na literówki czy niejednoznaczne wpisy. To szczególnie ważne przy automatyzacji konfiguracji repozytoriów przez narzędzia IaC.

Zarządzanie repozytoriami w Debianie 13 – apt i sources.list

Zalecana składnia wpisów w sources.list

W Debianie 13 zalecany jest nadal ten sam, przejrzysty sposób definiowania repozytoriów, ale zmienia się kilka szczegółów. Admini, którzy od lat kopiują te same linijki, powinni odświeżyć konfigurację, aby uwzględnić m.in. komponent non-free-firmware i osobne repozytoria security.

Typowa, zalecana konfiguracja dla systemu produkcyjnego może wyglądać tak:

deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
deb-src http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware

deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware
deb-src http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware

deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
deb-src http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware

W Debianie 13 równoważna konfiguracja (z odpowiednią nazwą wydania) pozostaje standardem. Coraz bardziej promowane jest także trzymanie osobnych plików w /etc/apt/sources.list.d/ dla dodatkowych repozytoriów, zamiast „upiększania” głównego sources.list. Ułatwia to późniejsze usuwanie lub wyłączanie pojedynczych źródeł.

Przykładowe profile konfiguracji: stable, security, backports

Dla przejrzystości warto wyróżnić kilka typowych scenariuszy konfiguracji repozytoriów, z których korzystają administratorzy przy Debianie 13.

Czysty stable + security

Klasyczny wariant dla serwerów, gdzie priorytetem jest stabilność i minimalna liczba zmian:

Stable + security + backports dla wybranych usług

Gdy trzeba połączyć stabilność systemu z nowszymi wersjami kilku kluczowych pakietów (np. nginx, PostgreSQL, kernel dla konkretnych funkcji), naturalnym wyborem staje się włączenie backports. Ważne, by nie traktować backports jako „drugiego stable”, tylko jako dokładnie kontrolowane źródło kilku pakietów.

deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware
deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware

deb http://deb.debian.org/debian bookworm-backports main contrib non-free non-free-firmware

Do tego sensowne jest skonfigurowanie priorytetów w /etc/apt/preferences.d/backports tak, by pakiety z backports nie wskakiwały samoczynnie zamiast stable:

Package: *
Pin: release a=bookworm-backports
Pin-Priority: 100

Wówczas instalacja nowszego pakietu jest zawsze świadoma:

apt install -t bookworm-backports nginx

Mit: „jak dodasz backports, to system przestaje być stable”. Problemy zwykle biorą się z bezrefleksyjnego mieszania repozytoriów i braku pinowania priorytetów, nie z samych backports. Kontrolowane użycie backports bywa mniej ryzykowne niż ręczne dodawanie zewnętrznych repo z losowych stron.

Dodatkowe repozytoria firm trzecich

Coraz więcej vendorów dostarcza własne repozytoria Debiana (Docker, HashiCorp, GitLab, producent bazy danych). W Debianie 13 rozsądnie jest każde z nich separować:

• /etc/apt/sources.list.d/docker.list,
• /etc/apt/sources.list.d/hashicorp.list,
• /etc/apt/sources.list.d/gitlab.list itd.

To ułatwia w przyszłości usunięcie lub wyłączenie pojedynczego dostawcy bez ryzyka rozjechania całej konfiguracji. Przy IaC (Ansible, Puppet, Salt) pozwala też dokładnie kontrolować, na których hostach pojawia się dane zewnętrzne źródło.

Rzeczywistość jest taka, że w produkcji rzadko kończy się na „czystym” stable. Sztuka polega na tym, żeby każde dodatkowe repozytorium było dodane celowo, opisane (komentarz w pliku) i miało sensowne priorytety.

Nowe mechanizmy apt: uwierzytelnianie, podpisy, bezpieczeństwo

apt w Debianie 13 to nie jest rewolucja, ale w tle dzieje się sporo usprawnień dotyczących bezpieczeństwa i ergonomii. Dotyczy to głównie zarządzania kluczami, weryfikacji podpisów oraz reakcji na niejednoznaczną konfigurację.

Przechowywanie kluczy GPG poza trusted.gpg

Stary nawyk: wgrywanie kluczy vendorów do globalnego /etc/apt/trusted.gpg lub trusted.gpg.d. Debian 13 konsekwentnie promuje nowy wzorzec: dla każdego zewnętrznego repozytorium osobny plik klucza w /usr/share/keyrings i powiązanie go z repo przez parametr signed-by w sources.list.

# przykład dla Dockera
curl -fsSL https://download.docker.com/linux/debian/gpg | 
  gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] 
https://download.docker.com/linux/debian bookworm stable" 
> /etc/apt/sources.list.d/docker.list

Taki sposób ma prostą zaletę: klucz Dockera nie jest domyślnie ufany dla całej reszty repozytoriów. Jeśli vendor wypuści błędnie podpisany pakiet lub dojdzie do wycieku klucza, zakres szkód jest mniejszy.

Reakcja na błędy podpisu i niespójności repozytoriów

apt jest bardziej stanowczy tam, gdzie dawniej przymykał oko. Błędny podpis, niepasujący Release file, uszkodzona lista pakietów – to coraz częściej blokada, a nie tylko ostrzeżenie. Na pierwszy rzut oka bywa to irytujące, ale dla administratora produkcji to plus: skrypty aktualizujące nie „przeklikają” w milczeniu ostrzeżeń o potencjalnym ataku MITM.

W praktyce będzie się to objawiało m.in. tak:

• przy problemach z podpisem apt update kończy się błędem, a nie sukcesem z żółtym komunikatem,
• zniknięcie repozytorium lub istotna zmiana struktury (np. u zewnętrznego vendora) wymusi poprawę wpisu przed kolejnym upgrade.

Konfiguracja apt.conf.d: domyślne zachowania i polityki

Coraz częściej konfigurację apt „programuje się” poprzez pliki w /etc/apt/apt.conf.d/, zamiast polegać wyłącznie na opcjach linii poleceń. W Debianie 13 sensowne ustawienia dla serwera produkcyjnego to m.in.:

Acquire::Retries "5";
APT::Install-Recommends "false";
APT::Install-Suggests "false";

Druga i trzecia linijka chronią przed niekontrolowanym wciąganiem dziesiątek dodatkowych pakietów jako „rekomendowanych”, co ma znaczenie przy serwerach o ograniczonym obrazie bazowym lub hostach, gdzie ważna jest minimalna powierzchnia ataku.

Kluczowe zmiany dla adminów: systemd, sieć, logowanie, usługi

Systemd w Debianie 13: nowe możliwości i pułapki

Systemd w Debianie 13 nadgania upstream, co w praktyce oznacza zarówno nowe funkcje, jak i konieczność porzucenia niektórych historycznych obejść. Dla adminów nie chodzi o teorię, tylko o kilka obszarów: start usług, restart po błędach, izolacja procesów i integracja z logowaniem.

Jednostki usług: Restart=, TimeoutStartSec, zależności

Nowe wersje systemd bardziej restrykcyjnie traktują źle opisane usługi. Jednostka bez sensownie ustawionych timeoutów czy restartów może zachowywać się inaczej niż w Debianie 11/12. Warto przeglądnąć kluczowe serwisy i dołożyć parametry:

• Restart=on-failure lub on-abnormal dla usług krytycznych,
• TimeoutStartSec= i TimeoutStopSec= dopasowane do realnego czasu startu/stopu,
• StartLimitIntervalSec= i StartLimitBurst= – by uniknąć „flapowania” usług.

Mit: „systemd sam się domyśli sensownych ustawień”. Domyślne wartości są konserwatywne lub wręcz zbyt restrykcyjne dla obciążonych usług (np. baza danych startująca kilka minut po awarii dysku). Ręczne dopasowanie parametrów ratuje przed fałszywymi alarmami i nieplanowanymi restartami.

Sandboxing i ograniczenia zasobów

Nowszy systemd oferuje sporo opcji izolacji: ProtectSystem=, ProtectHome=, PrivateTmp=, NoNewPrivileges=, a także ograniczenia typu MemoryMax=, CPUQuota=, IPAddressDeny=. Debian 13 nie włącza ich masowo w istniejących jednostkach, ale nowe pakiety częściej z nich korzystają.

Dobrą praktyką jest wzbogacenie własnych unitów o minimalny zestaw zabezpieczeń, np. dla prostego serwisu HTTP:

[Service]
User=www-data
Group=www-data
NoNewPrivileges=true
ProtectSystem=full
ProtectHome=true
PrivateTmp=true

Taki sandbox nie zastępuje tradycyjnego hardeningu, ale znacząco utrudnia eskalację po przejęciu pojedynczej usługi.

Override’y jednostek i drop-iny

Zamiast edycji plików w /lib/systemd/system lepiej używać drop-inów w /etc/systemd/system/<unit>.d/. Debian 13 niczego tu rewolucyjnie nie zmienia, ale im więcej pakietów przychodzi z „bogatszymi” unitami, tym większa szansa, że lokalne modyfikacje przy nadpisywaniu pliku zostaną utracone.

systemctl edit nazwa.service

Uruchomienie tej komendy tworzy bezpieczny szkielet w /etc. Przy IaC drop-iny można kontrolować jak zwykłe pliki konfiguracyjne, a aktualizacje pakietów nie skasują zmian.

Sieć: ifupdown, systemd-networkd, NetworkManager

Konfiguracja sieci w Debianie od lat jest tematem spornym: klasyczny ifupdown, nowszy ifupdown2, systemd-networkd, wreszcie NetworkManager. Debian 13 nie narzuca jednej drogi, ale widać mocniejsze wsparcie dla integracji z systemd.

ifupdown vs systemd-networkd na serwerach

W środowiskach serwerowych nadal bardzo popularny jest klasyczny plik /etc/network/interfaces. Dla prostych konfiguracji (jeden interfejs, kilka VLAN-ów, trasy statyczne) to wystarcza. Jednak przy bardziej złożonych scenariuszach (automatyczne wykrywanie, bonding, sieci SR-IOV, integracja z kontenerami) coraz więcej adminów przechodzi na systemd-networkd.

Przykładowa prosta konfiguracja static przez systemd-networkd w Debianie 13:

# /etc/systemd/network/10-lan.network
[Match]
Name=enp1s0

[Network]
Address=192.0.2.10/24
Gateway=192.0.2.1
DNS=192.0.2.53

Dla hostów, gdzie systemd już zarządza wszystkim innym, takie podejście upraszcza debugowanie: logi, stan interfejsów, zależności z usługami – wszystko w jednym ekosystemie narzędzi.

NetworkManager w środowiskach mieszanych

Na serwerach, gdzie admini nie wyobrażają sobie pracy bez interfejsu tekstowego i plików konfiguracyjnych, NetworkManager bywa traktowany jak zło konieczne. Tymczasem przy hostach „brzegowych” (serwery w roli gateway’a, hosty z Wi-Fi, laptop-admin z Debianem) NetworkManager w Debianie 13 jest znacznie bardziej przewidywalny niż kilka wydań temu.

Są jednak dwa warunki:

• albo NetworkManager, albo ręczne /etc/network/interfaces dla danego interfejsu,
• świadome wyłączenie zarządzania niektórymi interfejsami (np. VLAN-ami do storage) poprzez konfigurację NM.

Mit: „NetworkManager jest tylko dla desktopów”. W praktyce dobrze się sprawdza na serwerach, które często zmieniają miejsce, adresację lub typ połączenia, o ile ma się pod kontrolą, które interfejsy faktycznie obsługuje.

Logowanie: journald, rsyslog i rotacja logów

Debian 13 kontynuuje kurs na journald jako centralny mechanizm logowania, ale tradycyjny syslog (rsyslog/syslog-ng) nadal jest obecny i wspierany. Dla admina kluczowe jest wybranie modelu:

• journald jako bufor + rsyslog jako „długoterminowe” logi – typowe w scenariuszach z SIEM, logstachem, zewnętrznymi serwerami syslog,
• journald jako główne źródło prawdy – logi w strukturze binarnej, dostępne przez journalctl i eksportowane okresowo na zewnątrz.

Przy drugim podejściu trzeba zwrócić uwagę na retencję: plik /etc/systemd/journald.conf oraz parametry takie jak SystemMaxUse=, SystemMaxFileSize=, MaxRetentionSec=. Domyślne ustawienia mogą być zbyt zachowawcze dla długich śledztw po incydencie.

W środowiskach o wysokich wymaganiach audytowych sensowny schemat to: journald lokalnie, rsyslog tylko jako forwarder do centralnego sysloga lub stacka ELK/Graylog, bez zbędnej lokalnej retencji plików w /var/log. Zyskuje się w ten sposób mniej ruchomych części na każdym hoście.

Bezpieczeństwo i twardnienie systemu w Debianie 13

Domyślne ustawienia bezpieczeństwa: co się zaostrzyło

Debian tradycyjnie był ostrożny z domyślnym „twardnieniem”, żeby nie psuć kompatybilności. Debian 13 stopniowo przesuwa granicę, szczególnie w obszarze kompilacji pakietów, mechanizmów kernela i crypto.

Wzmocnienia na poziomie kompilacji

Coraz więcej pakietów w Debianie 13 jest budowanych z domyślnymi flagami zabezpieczającymi: PIE, RELRO, stack protector, fortify, LTO tam, gdzie ma to sens. Dla administratora nie oznacza to żadnej dodatkowej pracy, ale efekt jest konkretny: exploitacja prostych błędów w stylu „klasyczny buffer overflow” jest zauważalnie trudniejsza.

Kernel: lockdown, seccomp, BPF

Nowe wydania jądra w Debianie 13 dostarczają więcej gotowych mechanizmów bezpieczeństwa:

• tryby lockdown ograniczające możliwość manipulacji jądrem z przestrzeni użytkownika,
• bogatsza obsługa seccomp (filtry syscalle),
• rozbudowane możliwości BPF, ale coraz częściej obwarowane dodatkowymi kontrolami.

Jeśli w środowisku wykorzystywane są narzędzia typu Falco, Cilium, eBPF-based monitoring, różnice między Debianem 11/12 a 13 będą zauważalne. Czasem oznacza to konieczność podniesienia samych narzędzi – nie zawsze stare wersje rozumieją nowe ograniczenia kernela.

Podpisywanie i weryfikacja: Secure Boot, UEFI, shim

Secure Boot w praktyce serwerowej

Secure Boot przestał być wyłącznie problemem stacji roboczych. Coraz więcej serwerów bare metal i platform cloudowych ma go domyślnie włączonego. Debian 13 jest lepiej przygotowany na takie środowiska: nowocześniejszy shim, odświeżone certyfikaty, poprawiona integracja z signed kernelami i modułami.

Mit: „na serwerach Secure Boot tylko przeszkadza”. Problemem zwykle nie jest sam mechanizm, ale prowizoryczne obejścia – np. ręczne wyłączanie SB na części hostów, brak spójnej polityki kluczy lub mieszanie samopodpisanych modułów z dystrybucyjnymi. Debian 13 ułatwia podejście: domyślne łańcuchy zaufania są sensowniejsze, a dokumentacja sposobu podpisywania własnych modułów jądra jest mniej rozproszona niż kiedyś.

W środowiskach, gdzie używane są moduły out-of-tree (np. sterowniki od vendorów storage, IDS-y kernelowe), trzeba uwzględnić ich podpisywanie i dystrybucję kluczy:

• utrzymywać wewnętrzny CA do podpisywania modułów,
• wstrzyknąć jego klucz publiczny do DB/KEK w firmware albo do MOK (Machine Owner Key),
• sprowadzić instalację modułów do powtarzalnego procesu (np. pipeline w CI), a nie ręcznych komend na każdym hoście.

Secure Boot staje się częścią łańcucha zgodności (audyt, regulacje branżowe). Gdy Debian 11 był wprowadzany na starszy hardware, często temat odkładano „na potem”. Przy Debianie 13 i nowym sprzęcie to „potem” zwykle oznacza od razu.

Tryby lockdown jądra i ich wpływ na narzędzia administracyjne

Lockdown kernelowy ma coraz większy wpływ na codzienne zarządzanie. Tryb „integrity” czy „confidentiality” potrafi zaskoczyć, gdy nagle przestaje działać ulubione narzędzie do analizy pamięci czy „sprytny” debugger wpięty bezpośrednio w /dev/mem.

Rzeczywistość jest taka, że spora część starszych poradników „debug jądra pod Debiana” nie przystaje już do nowych ustawień. Narzędzia, które próbują ingerować bezpośrednio w przestrzeń kernela, często są po prostu blokowane. Debian 13 stawia po stronie bezpieczeństwa, co wymusza na adminach lekką aktualizację nawyków:

• więcej narzędzi korzysta z eBPF i oficjalnych interfejsów tracerów (perf, ftrace), zamiast odwoływać się do /dev/kmem,
• monitoring oparty na „hackach” z czasów jądra 3.x zwykle kończy życie – trzeba przejść na wspierane API,
• starsze skrypty backupujące „surową” pamięć i struktury kernela trzeba zweryfikować; często w ogóle nie da się ich uruchomić bez poluzowania lockdownu.

Dla środowisk z silnymi wymaganiami compliance sensowniejszą drogą jest dostosowanie narzędzi do lockdownu, a nie wyłączanie go globalnie na wszystkich hostach tylko po to, by nie przerabiać starych skryptów.

Crypto i biblioteki: wymuszenie silniejszych algorytmów

Debian 13 podciąga do góry minimalne poziomy bezpieczeństwa w bibliotekach kryptograficznych. Pojawia się więcej domyślnie wyłączonych, przestarzałych algorytmów i protokołów, szczególnie w OpenSSL i GnuTLS. Efektem ubocznym są przerwane połączenia z bardzo starymi urządzeniami i aplikacjami.

Mit: „to tylko kwestia podbicia wersji klienta”. W praktyce problem częściej tkwi po drugiej stronie – stare load balancery, kontrolery SAN, urządzenia sieciowe, które nie znają nowoczesnych krzywych ECDSA ani TLS 1.3. Debian 13 po stronie klienta czy serwera www robi „to, co trzeba”, ale świat po drugiej stronie łącza bywa uwięziony w epoce TLS 1.0.

Dobre podejście to przeprowadzenie inwentaryzacji przed migracją:

1. przepuścić ruch przez skaner protokołów (np. test TLS/SSH z osobnego hosta z Debianem 13),
2. spisać wszystkie systemy, które akceptują tylko stare protokoły/algorytmy,
3. wymusić aktualizacje lub zaplanować segmentację – np. trzymać je na osobnych VLAN-ach i proxy z osobną polityką crypto.

Świadome obniżanie poziomu kryptografii w konfiguracji Debiana 13 (np. dopuszczanie SHA1 w SSH) powinno być wyjątkiem, a nie regułą. Lepiej ograniczyć problem do kilku kontrolowanych punktów, niż rozluźnić politykę na całym systemie.

Migracja z Debiana 11/12 do 13 – scenariusze i strategia

Jak podejść do planowania migracji w środowisku produkcyjnym

Upgrade z jednego stable do kolejnego bywa traktowany jako „apt full-upgrade i modlitwa”. Przy Debianie 13 takie podejście jest tym bardziej ryzykowne, że kumulują się zmiany w kernelu, systemd, kryptografii i domyślnych konfiguracjach niektórych demonów.

Rozsądna strategia składa się z kilku etapów:

• Segmentacja środowiska – podział hostów na klasy: krytyczne (DB, storage, kluczowe API), średnio krytyczne, pomocnicze (bastiony, batch, narzędziowe).
• Pilot na najmniej krytycznych hostach – np. serwery CI, stage, testowe instancje aplikacji, które da się łatwo odtworzyć z IaC.
• Wzór procesu – spisanie check-listy upgrade’u na podstawie pilota i jej powtarzanie (a nie wymyślanie wszystkiego od nowa przy każdym hoście).
• Okna serwisowe – szczególnie przy systemach, gdzie nie ma pełnego HA; lepiej 2–3 krótsze, ale kontrolowane okna, niż jedno „wielkie przejście w weekend”.

Przy dużej flocie dobrą praktyką jest wydzielenie „kanarka” – kilku hostów w każdej roli, które są aktualizowane jako pierwsze, trafiają pod wzmożony monitoring, a dopiero potem rusza reszta maszyn tego typu.

Bezpośrednio 11 → 13 czy po kolei?

Standardowa zasada Debiana się nie zmienia: aktualizacje wspierane są krok po kroku, czyli 11 → 12 → 13. Oficjalne narzędzia i instrukcje nie przewidują pomijania wydań, tak jak nie ma bezpośredniej ścieżki 10 → 13 jednym skokiem.

Mit: „da się, bo apt to przełknie”. Może i przełknie, ale ryzyko niespójności konfiguracji, przerwanych skryptów maintainerów czy pozostawionych „osieroconych” zależności jest zbyt duże. Admin, który później będzie debugował dziwne zachowania pakietów, często już nie skojarzy, że kilka lat wcześniej był zrobiony „skok w bok” w procesie migracji.

Praktyczne podejście:

• jeśli host jest jeszcze na 11 – zaplanować dwustopniowy upgrade (11 → 12, stabilizacja, dopiero potem 12 → 13),
• jeśli obecnie działa na 12 – przygotowania pod 13 można zacząć od razu, ale i tak warto zrobić jeden pilotaż.

Kontenery i maszyny wirtualne jako poligon

Scenariusz, który sprawdza się w praktyce: najpierw aktualizacja w „miniaturze” pod kontrolą, dopiero później na fizycznym serwerze. Debian 13 jest wystarczająco podobny do 12, by kontenerowa migracja dobrze odzwierciedlała problemy, które wyjdą w produkcji.

Prosty schemat dla aplikacji uruchomionej na gołym systemie:

1. zbudować obraz kontenera z bazową 13 (oficjalne obrazy Debiana),
2. zainstalować tę samą wersję aplikacji i konfiguracji, co na serwerze 11/12,
3. uruchomić ten kontener obok starej instancji, przeprowadzić smoketest,
4. zidentyfikować brakujące zależności, zmiany w zachowaniu bibliotek, ostrzeżenia w logach po starcie.

Dopiero po takim „suchym biegu” jest sens ruszać właściwy host. Taki poligon dobrze ujawnia np. wymuszenie nowszych wersji OpenSSL, zmiany w domyślnych locale, nowe domyślne ścieżki w demonsach czy problemy z uprawnieniami katalogów.

Zmiany w repozytoriach a migracja

Przy przeskoku do Debiana 13 często ujawniają się stare „grzechy” w sources.list: nieaktualne PPA, własne repozytoria bez podpisów, mieszanie stable + testing + unstable na jednym hoście. W nowym wydaniu apt jest trochę mniej tolerancyjny wobec takich konstrukcji.

Przed migracją opłaca się:

• zredukować liczbę zewnętrznych repozytoriów do minimum absolutnego,
• sprawdzić, które repo mają już gałąź dla 13, a które są porzucone,
• zastąpić stare repo vendora (często bez GPG lub z przeterminowanym kluczem) nowszymi pakietami dostępnymi bezpośrednio w Debianie 13.

Jeśli nie da się uniknąć zewnętrznego repozytorium, warto od początku mieć dla niego osobny plik w /etc/apt/sources.list.d/ i stosować Signed-By= dla konkretnych kluczy, zamiast wrzucać wszystko do globalnego zaufania w /etc/apt/trusted.gpg.d/.

Testy regresyjne: co realnie sprawdzić po migracji

Full stack testów e2e nie zawsze jest możliwy na środowisku produkcyjnym, ale minimalny pakiet testów po migracji warto zdefiniować. Sensowne minimum to:

• czy startują wszystkie usługi systemowe z listy „krytyczne” (DB, HTTP, cache, logowanie, monitoring),
• czy agenty monitoringu i backupu raportują pełny sukces,
• czy aplikacja widzi wszystkie potrzebne zasoby (bazy, kolejki, zewnętrzne API),
• czy logi nie są zalewane powtarzającymi się błędami lub ostrzeżeniami.

Scenariusz z praktyki: po migracji kilku serwerów do Debiana 13 okazało się, że agent backupu korzystał z przestarzałej biblioteki TLS, która w nowym systemie była już „przykręcona”. Monitoring usług był zielony, ale okno backupowe zaczęło się wydłużać, a część zadań kończyła się retry. Problem wyszedł dopiero przy analizie logów – bez świadomie zdefiniowanych testów po-upgrade taka usterka mogłaby wisieć tygodniami.

Praktyka aktualizacji: krok po kroku dist-upgrade do Debiana 13

Przygotowanie systemu przed dist-upgrade

Dist-upgrade na „zarośniętym” systemie to proszenie się o kłopoty. Zanim pojawi się pierwsze apt full-upgrade, przydaje się kilka porządków:

• aktualizacja do najnowszego stanu w ramach bieżącego wydania – apt update && apt full-upgrade na Debianie 11/12, żeby mieć aktualne skrypty maintainerów,
• usunięcie pakietów osieroconych – apt autoremove plus przegląd narzędziami typu deborphan,
• backup konfiguracji – nie tylko snapshot VM, ale też zrzut /etc, listy zainstalowanych pakietów (dpkg --get-selections), eksport kluczowych danych (bazy, konfiguracje demonów),
• sprawdzenie miejsca na dysku – upgradeki potrafią chwilowo wykorzystać sporo przestrzeni w /var (cache APT, unpack, logi).

Mit: „snapshot VM wystarczy jako plan awaryjny”. Snapshot jest konieczny, ale nie rozwiązuje problemu, gdy trzeba odtworzyć pojedynczy host bare metal albo przeanalizować, które pliki konfiguracyjne zmieniły się w trakcie upgrade’u. Dodatkowy backup konfiguracji i danych daje wygodniejsze pole manewru.

Aktualizacja sources.list do Debiana 13

Podstawowy krok to przełączenie repozytoriów ze starego stable (bullseye/bookworm) na nowe stable. Najprostszy przykład dla hosta korzystającego z głównego archiwum i security:

# /etc/apt/sources.list
deb http://deb.debian.org/debian/ trixie main contrib non-free-firmware
deb http://security.debian.org/debian-security trixie-security main contrib non-free-firmware
deb http://deb.debian.org/debian/ trixie-updates main contrib non-free-firmware

Należy przy tym:

• usunąć lub wyłączyć wpisy dla starego wydania (bullseye/bookworm),
• upewnić się, że wszystkie potrzebne sekcje (contrib, non-free, non-free-firmware) są obecne, jeśli były wykorzystywane wcześniej,
• zaktualizować wpisy w sources.list.d/ – część zewnętrznych repozytoriów zmienia nazwy gałęzi lub jeszcze nie ma supportu dla 13.

Symulacja i właściwy dist-upgrade

Kiedy repozytoria są ustawione, pierwszym krokiem powinno być uruchomienie symulacji:

apt update
apt -o APT::Get::Trivial-Only=true dist-upgrade

Jeśli symulacja przechodzi bez błędów, można wykonać właściwy upgrade:

apt update
apt full-upgrade

Na serwerach produkcyjnych bezpieczniejsza jest sekwencja „dwustopniowa”:

1. apt upgrade – aktualizacja bez agresywnego usuwania/zmiany pakietów,
2. apt full-upgrade – dopiero potem wykonanie pełnego dist-upgrade, gdy już wiadomo, że podstawowe zależności są w porządku.