Fedora Server na VPS: cykl życia i aktualizacje wersji

Jak długo wydanie Fedora otrzymuje aktualizacje bezpieczeństwa?

Serwer z systemem Fedora wymaga aktualizacji wersji mniej więcej raz w roku przez cały okres eksploatacji maszyny. Fedora publikuje nowe wydanie mniej więcej co sześć miesięcy. Każde wydanie jest wspierane do około czterech tygodni po premierze wersji wydanej dwie edycje później, co przekłada się na około 13 miesięcy aktualizacji. Po tej dacie wydanie przestaje otrzymywać jakiekolwiek poprawki bezpieczeństwa. Maszyna nadal działa, ale z zestawem pakietów, których nikt już nie aktualizuje.

Daty pozwalają na konkretne zobrazowanie sytuacji. Według stanu na sierpień 2026 wspieranymi wydaniami są Fedora 43 oraz Fedora 44. Fedora 44 została wydana 28 kwietnia 2026, a jej koniec wsparcia zaplanowano na czerwiec 2027. Fedora 42 została wydana w kwietniu 2025 i osiągnęła koniec wsparcia w maju 2026, cztery tygodnie po premierze systemu Fedora 44. Serwer zbudowany na bazie obrazu Fedora 42 utracił zatem wsparcie trzynaście miesięcy później, bez popełnienia jakiegokolwiek błędu przez administratora.

Fedora w porównaniu z LTS, w miesiącach

LTS oznacza wsparcie długoterminowe (long term support): wydanie, które dostawca aktualizuje przez lata, a nie miesiące. EOL oznacza koniec cyklu życia (end of life), czyli datę zaprzestania publikowania poprawek. Poniżej przedstawiono dane publikowane przez poszczególne projekty dla wydania, które można zainstalować dzisiaj.

[
  {
    "distro": "Fedora 44",
    "support_window": 13,
    "upgrades_per_decade": 10
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "support_window": 60,
    "upgrades_per_decade": 2
  },
  {
    "distro": "Debian 13 stable",
    "support_window": 36,
    "upgrades_per_decade": 3
  },
  {
    "distro": "AlmaLinux 10",
    "support_window": 120,
    "upgrades_per_decade": 1
  }
]

Fedora zapewnia 13 miesięcy wsparcia na wydanie. Ubuntu LTS oferuje 60, a dystrybucja typu enterprise rebuild, taka jak AlmaLinux, zapewnia 120. Druga kolumna określa koszt utrzymania. W ciągu dziesięciu lat Fedora wymaga około 10 aktualizacji całego systemu operacyjnego, w porównaniu do 2 w przypadku Ubuntu LTS. Wartość 36 miesięcy dla Debiana dotyczy standardowego wsparcia bezpieczeństwa, przy czym oddzielny zespół LTS wydłuża okres wsparcia większości wydań do około pięciu lat.

Są to opublikowane okresy wsparcia, zweryfikowane w sierpniu 2026 roku, a nie zmierzony czas pracy bez przestojów. Przyczyny różnic w cyklach wydawniczych zostały opisane w różnice między Ubuntu LTS a wydaniami interim na serwerze. Istotne jest tutaj obciążenie pracą, jakie generuje każde z tych rozwiązań.

Na czym polega aktualizacja wersji systemu Fedora

DNF 5 jest domyślnym menedżerem pakietów od wersji Fedora 41, a dnf go obsługuje. Polecenie system-upgrade stanowi integralną część dnf5, więc nie ma potrzeby instalowania dodatkowych wtyczek. Rozpocznij od w pełni zaktualizowanej bieżącej wersji systemu:

sudo dnf upgrade --refresh
sudo reboot

Restart jest konieczny, ponieważ proces aktualizacji odnosi się do zainstalowanego i uruchomionego oprogramowania, a częściowo wdrożona aktualizacja jądra lub glibc utrudnia diagnozę ewentualnych problemów. Teraz przygotuj pliki nowej wersji. Zastąp 44 numerem wersji, do której przeprowadzasz migrację:

sudo dnf system-upgrade download --releasever=44

Polecenie to rozwiązuje zależności całej transakcji i pobiera wszystkie pakiety, nie wprowadzając żadnych zmian w działającym systemie. Należy spodziewać się pobrania kilku tysięcy pakietów o łącznym rozmiarze od jednego do trzech gigabajtów na małym serwerze. Jeśli dnf nie jest w stanie rozwiązać zależności, proces zostanie przerwany, a system wskaże pakiet blokujący aktualizację. Jest to sytuacja korzystna, ponieważ błąd występuje, gdy maszyna jest wciąż uruchomiona i masz dostęp do powłoki.

Następnie wykonaj aktualizację:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status potwierdza, że transakcja została przygotowana i oczekuje na realizację. dnf system-upgrade reboot restartuje maszynę w tryb transakcji offline: minimalne środowisko startowe, w którym transakcja RPM wykonywana jest samodzielnie. Działa to w ten sposób, ponieważ zastępowanie glibc i systemd w trakcie pracy usług prowadzi do niestabilności systemu. Serwer będzie niedostępny przez cały czas trwania transakcji, zazwyczaj przez kilka minut w przypadku małego VPS, po czym nastąpi ponowny restart do nowej wersji systemu. Zaplanuj dwa restarty oraz czas, w którym połączenie SSH nie będzie odpowiadać.

Po ponownym uruchomieniu:

cat /etc/fedora-release
sudo dnf system-upgrade log --number=-1
sudo dnf distro-sync
sudo dnf repoquery --extras

/etc/fedora-release powinno wyświetlić linię podobną do Fedora release 44 (Forty Four). Podpolecenie log wyświetla dziennik transakcji z rozruchu offline, co stanowi jedyny zapis zdarzeń z czasu, gdy nie było dostępu do powłoki. distro-sync aktualizuje pozostałe pakiety do wersji zgodnych z nowym wydaniem. repoquery --extras wyświetla zainstalowane pakiety, które nie znajdują się już w żadnym włączonym repozytorium; jest to miejsce, w którym można znaleźć pozostałości po repozytoriach, które nie zostały wydane dla nowej wersji systemu.

Przed etapem pobierania wykonaj migawkę dysku. Transakcja przebiega w czasie, gdy nie masz wglądu w ekran, więc jeśli nie powiedzie się podczas rozruchu offline, połączenie SSH nie zostanie nawiązane, a jedynym sposobem dostępu będzie konsola udostępniona przez dostawcę, VNC lub port szeregowy. Upewnij się, że masz dostęp do konsoli lub wykonanej migawki przed rozpoczęciem procesu, a nie po fakcie.

Jeszcze jedna kontrola, którą często pomija się:

sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'

Gdy pakiet zawiera nowy domyślny plik konfiguracyjny, a użytkownik edytował stary, RPM nie nadpisuje pliku. Zapisuje nową wersję obok, z rozszerzeniem .rpmnew. Dzięki temu sshd lub nginx zachowują się tak samo jak w starej wersji, podczas gdy nowe ustawienia domyślne pozostają nieprzeczytane na dysku. Po każdej aktualizacji należy przejrzeć te pliki. Zainstalowanie rpmconf i uruchomienie sudo rpmconf -a pozwala na ich przeglądanie jeden po drugim i wyświetlenie różnic.

Zewnętrzne repozytoria są przyczyną niepowodzeń aktualizacji

Własne pakiety Fedora są aktualizowane jednocześnie w dniu wydania nowej wersji. Oprogramowanie pochodzące spoza Fedory jest aktualizowane zgodnie z harmonogramem zewnętrznych dostawców. Większość repozytoriów zewnętrznych zawiera $releasever w adresie URL, więc w momencie aktualizacji system dnf zaczyna żądać ścieżki, która może jeszcze nie istnieć.

Wyświetl listę posiadanych repozytoriów:

sudo dnf repo list --enabled
grep -R -e baseurl -e metalink /etc/yum.repos.d/

Dla każdego repozytorium, które nie należy do Fedory, przeprowadź test zgodności z docelową wersją systemu przed podjęciem jakichkolwiek działań:

sudo dnf --releasever=44 --repo=docker-ce-stable makecache

Jeśli dostawca opublikował pakiety dla danej wersji, dnf pobierze metadane i zakończy działanie bez komunikatów. W przeciwnym razie otrzymasz błąd 404 dla ścieżki takiej jak https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml, a ten sam błąd zatrzyma proces system-upgrade download w późniejszym etapie. W pierwszych tygodniach po wydaniu nowej wersji Fedora jest to najczęstsza przyczyna niepowodzenia aktualizacji.

Dostępne są dwa rozwiązania. Można odczekać kilka tygodni, aż dostawca opublikuje aktualizację, co zazwyczaj jest zalecanym krokiem. Można również przeprowadzić aktualizację bez danego repozytorium:

sudo dnf system-upgrade download --releasever=44 --disable-repo=docker-ce-stable

Wyłączenie repozytorium nie powoduje usunięcia zainstalowanych z niego pakietów. Pozostają one w systemie jako niezarządzane, a jeśli blokują transakcję, dnf poinformuje o tym fakcie. Dodanie flagi --allowerasing pozwala dnf na usunięcie zainstalowanych pakietów w celu rozwiązania konfliktu, dlatego przed zaakceptowaniem zmian należy dokładnie przejrzeć listę usuwanych elementów. To właśnie na tej liście użytkownicy często nieświadomie usuwają serwery baz danych, które zamierzali zachować.

Co dzieje się z serwerem Fedora po przekroczeniu terminu wsparcia

W dniu zakończenia wsparcia nie dzieje się nic. Awaria występuje przy kolejnej próbie użycia menedżera pakietów. Wydania, których cykl życia dobiegł końca, są usuwane z sieci serwerów lustrzanych do archiwum, co powoduje, że dnf upgrade kończy się niepowodzeniem podczas pobierania metadanych, zwracając błąd 404 dla adresu URL metalink przypisanego do danej wersji:

Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-42&arch=x86_64

Maszyna kontynuuje obsługę ruchu, co czyni ten stan cichym i niebezpiecznym. Serwer nie otrzymuje żadnych aktualizacji bezpieczeństwa. Nie można również zainstalować żadnego oprogramowania, więc w dniu publikacji biuletynu bezpieczeństwa dla OpenSSH lub nginx, administrator nie posiada wspieranej metody na załatanie systemu.

Wyjście z tej sytuacji jest możliwe, lecz czasochłonne. Można przekierować repozytoria na archiwum Fedory pod adresem https://dl.fedoraproject.org/pub/archive/fedora/linux/ i przeprowadzić aktualizację z tego poziomu. Fedora zakłada przeskakiwanie o jedno lub dwa wydania jednocześnie, więc serwer opóźniony o cztery wersje wymaga kilku kolejnych aktualizacji. Każda z nich niesie ryzyko awarii i odbywa się w trybie pracy bez wsparcia. W przypadku VPS, przebudowa systemu na aktualnym obrazie i przeniesienie danych jest zazwyczaj krótszym i bezpieczniejszym zadaniem, wymagającym tyle samo pracy, co pierwsze dziesięć minut na nowym VPS.

Automatyczne aktualizacje instalują poprawki dla danego wydania. Nigdy nie przeprowadzają one aktualizacji wersji systemu.

Fedora może instalować aktualizacje zgodnie z harmonogramem:

sudo dnf install -y dnf5-plugin-automatic
sudo systemctl enable --now dnf5-automatic.timer

Ustawienia znajdują się w /etc/dnf/automatic.conf, co nadpisuje domyślne wartości zawarte w /usr/share/dnf5/dnf5-plugins/automatic.conf. Opcja apply_updates jest domyślnie wyłączona, więc w konfiguracji fabrycznej timer pobiera aktualizacje, ale nie instaluje żadnych pakietów. Parametr upgrade_type pozwala wybrać między default a security. Wartość reboot przyjmuje never, when-changed lub when-needed.

Mechanizm ten utrzymuje system w aktualnym stanie w ramach jednego wydania. Nigdy nie przeniesie on Fedory 43 do Fedory 44, ponieważ aktualizacja wersji jest oddzielną, celową operacją, która wymaga restartu do transakcji offline. Jest to praktyczna różnica w porównaniu z systemami LTS. W systemie Ubuntu automatyczne aktualizacje bezpieczeństwa pozwalają utrzymać maszynę przez cały pięcioletni cykl wsparcia bez zmiany wersji, a sama zmiana wersji jest planowanym zadaniem, takim jak aktualizacja z 24.04 do 26.04, wykonywanym raz na kilka lat.

Kiedy Fedora jest właściwym wyborem dla serwera

Fedora jest dobrym wyborem, gdy priorytetem jest nowoczesność oprogramowania.

• Wymagane jest jądro lub przestrzeń użytkownika nowsza niż w jakimkolwiek wydaniu LTS: dotyczy to obsługi najnowszego sprzętu lub stosu kontenerów i systemd, które w wydaniach korporacyjnych pojawią się dopiero za rok. Fedora aktualizuje jądra do nowszych wersji upstream w trakcie cyklu życia wydania, więc korzyść ta nie ogranicza się tylko do momentu instalacji.
• Weryfikowane jest oprogramowanie, które trafi do RHEL (Red Hat Enterprise Linux). Fedora zasila CentOS Stream, który z kolei zasila RHEL, więc oprogramowanie budowane i uruchamiane na Fedorze jest testowane pod kątem platformy korporacyjnej, która będzie standardem za kilka lat.
• Maszyna z założenia ma krótki cykl życia. Serwer budowania (build runner) lub środowisko testowe, które zostanie zniszczone za dwa miesiące, nigdy nie osiągnie daty końca wsparcia (EOL). Ta sama logika dotyczy jednorazowych maszyn wirtualnych przekazywanych agentom programistycznym, gdzie system jest przebudowywany znacznie częściej niż następują wydania Fedory.
• Ktoś odpowiada za aktualizacje. Fedora sprawdza się na serwerze, który ma wyznaczonego opiekuna i zaplanowane w kalendarzu prace. Jest natomiast złym wyborem dla maszyny, o której wszyscy zapomnieli.

Złoty środek: aktualne pakiety na stabilnej bazie

Większość użytkowników oczekujących Fedory na serwerze potrzebuje dwóch lub trzech aktualnych pakietów, a nie aktualnego systemu operacyjnego. Te kwestie można rozdzielić. Należy uruchomić dystrybucję LTS lub rebuild klasy enterprise jako bazę, a następnie pobrać nowe oprogramowanie tylko tam, gdzie jest to faktycznie wymagane. Obraz kontenera dostarcza nową wersję aplikacji na hoście, którego nigdy nie trzeba z tego powodu aktualizować (uruchamianie Docker na VPS). Repozytorium dostawcy dla konkretnego pakietu, na przykład PostgreSQL lub nginx, aktualizuje tylko ten jeden element, pozostawiając bazę bez zmian.

Kompromis jest uczciwy w obu przypadkach. Kontener zapewnia nową przestrzeń użytkownika na starym jądrze hosta, więc nie rozwiązuje problemu, gdy to właśnie jądro wymaga aktualizacji. Repozytorium dostawcy dostarcza jeden nowy pakiet na bazie, która była przez niego mniej przetestowana. Oba rozwiązania pozostawiają aktualizacje bezpieczeństwa systemu bazowego w cyklu LTS, a ten cykl jest właśnie tym, co w przypadku Fedory wymusza coroczne okno serwisowe.

Jeśli wybór padnie na Fedorę w zastosowaniach serwerowych, należy wpisać cykl wydawniczy do kalendarza. Po wydaniu nowej wersji systemu warto odczekać kilka tygodni, aż repozytoria dostawców zostaną zaktualizowane, wykonać snapshot, przeprowadzić aktualizację, a następnie zweryfikować, czy usługi zostały poprawnie uruchomione. Ten rytm kosztuje około godziny rocznie i sprawdza się w praktyce. Wersja, która zawodzi, to taka, o której aktualizacji pamięta się dopiero wtedy, gdy coś już przestało działać.

FAQ

Jak długo wspierane jest wydanie Fedora?

Około 13 miesięcy. Fedora publikuje nowe wydanie mniej więcej co sześć miesięcy i wspiera każde z nich do około czterech tygodni po premierze wersji o dwa numery nowszej. Fedora 44 została wydana 28 kwietnia 2026 roku, a koniec jej wsparcia zaplanowano na czerwiec 2027 roku. Po tej dacie wydanie przestaje otrzymywać aktualizacje bezpieczeństwa, a jego pakiety są przenoszone z serwerów lustrzanych do archiwum Fedora.

Czy można pominąć wydanie Fedora i zaktualizować system o dwie wersje jednocześnie?

Tak, w określonych granicach. dnf system-upgrade download --releasever= akceptuje wersję docelową o jedno lub dwa wydania wyżej, a przeskakiwanie o dwie wersje jest standardowym sposobem na utrzymywanie rocznego cyklu aktualizacji. Aktualizacja o więcej niż dwa wydania nie jest wspieraną ścieżką, a każde dodatkowe wydanie zwiększa ryzyko, że zmiana nazwy pakietu lub formatu konfiguracji przerwie transakcję. Jeśli maszyna jest kilka wydań za wersją bieżącą i przekroczyła datę końca wsparcia, ponowna instalacja z aktualnego obrazu jest zazwyczaj szybsza niż łańcuch aktualizacji.

Co się stanie, jeśli mój serwer Fedora osiągnie koniec wsparcia?

System będzie nadal działał, ale przestanie otrzymywać poprawki. Kolejne polecenie dnf upgrade zakończy się błędem 404 przy próbie pobrania metalink dla danej wersji, ponieważ wydania po zakończeniu wsparcia są przenoszone do archiwum pod adresem dl.fedoraproject.org. Można przekierować pliki repozytoriów na to archiwum i przeprowadzić aktualizację etapami lub zainstalować serwer od nowa w oparciu o wspieraną wersję. Do momentu wykonania jednej z tych czynności, na maszynę nie trafią żadne aktualizacje bezpieczeństwa i nie będzie można zainstalować żadnego pakietu.

Czy Fedora to zły wybór dla serwera produkcyjnego?

Jest to zły wybór domyślny, ale rozsądny, jeśli istnieją ku temu konkretne powody. Kosztem jest konieczność przeprowadzania pełnej aktualizacji systemu operacyjnego co roku, bezterminowo, na maszynie, której wolelibyśmy nie dotykać. Wybierz Fedorę, gdy potrzebujesz jądra lub przestrzeni użytkownika nowszych niż te oferowane w wydaniach LTS, lub gdy serwer z założenia ma krótki cykl życia. Wybierz system LTS lub dystrybucję typu enterprise, gdy chcesz aktualizować serwer przez lata bez zmiany jego wersji głównej.