Fedora Server na VPS: cykl życia i aktualizacje

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 koniec jej cyklu życia zaplanowano na czerwiec 2027. Fedora 42 została wydana w kwietniu 2025 i osiągnęła koniec cyklu życia 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 żadnych błędów po stronie 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 wydawania poprawek. Poniżej przedstawiono dane publikowane przez poszczególne projekty dla wydań dostępnych do instalacji w dniu dzisiejszym.

[
  {
    "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 perspektywie 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 Debian odnosi się do 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 (uptime). Przyczyny różnic w cyklach wydawniczych zostały opisane w różnice między Ubuntu LTS a wydaniami tymczasowymi na serwerze. Istotne jest tutaj obciążenie pracą, jakie generuje każde z tych rozwiązań.

Na czym polega aktualizacja wersji Fedora

DNF 5 jest domyślnym menedżerem pakietów od wersji Fedora 41, a dnf go obsługuje. Polecenie system-upgrade jest częścią samego dnf5, więc nie ma potrzeby instalowania dodatkowych wtyczek. Jeśli przechodzisz z systemu Debian lub Ubuntu, większość codziennych poleceń ma bezpośredni odpowiednik w dnf, jednak poniższa aktualizacja wersji jest jednym z niewielu zadań, które nie mają swojego odpowiednika. Rozpocznij od bieżącego wydania, w pełni załatanego:

sudo dnf upgrade --refresh
sudo reboot

Restart jest istotny, ponieważ aktualizacja jest weryfikowana względem zainstalowanego i uruchomionego oprogramowania. Częściowo wdrożona aktualizacja jądra lub glibc utrudnia diagnozę ewentualnych problemów. Teraz przygotuj nowe wydanie. Zastąp 44 numerem wydania, do którego przechodzisz:

sudo dnf system-upgrade download --releasever=44

To polecenie rozwiązuje całą transakcję, pobiera wszystkie pakiety i nie zmienia niczego w działającym systemie. Należy spodziewać się kilku tysięcy pakietów oraz pobrania od jednego do trzech gigabajtów danych na małym serwerze. Jeśli dnf nie może rozwiązać transakcji, zatrzymuje się w tym miejscu i wskazuje pakiet, który ją zablokował. Jest to korzystny scenariusz, ponieważ awaria nastę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 jest przygotowana i oczekuje. dnf system-upgrade reboot restartuje maszynę do trybu transakcji offline: minimalnego środowiska startowego, w którym transakcja RPM jest wykonywana samodzielnie. Działa to w ten sposób, ponieważ zastępowanie glibc i systemd pod działającymi usługami prowadzi do niepełnej instalacji systemu. Serwer jest niedostępny przez cały czas trwania transakcji, zazwyczaj przez kilka minut na małym VPS, a następnie ponownie restartuje się do nowego wydania. Zaplanuj dwa restarty oraz czas, w którym SSH nie będzie odpowiadać.

Po powrocie systemu:

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 tego startu offline, co stanowi jedyny zapis tego, co wydarzyło się, gdy nie miałeś dostępu do powłoki. distro-sync aktualizuje wszelkie pozostałe elementy do wersji z nowego wydania. repoquery --extras wyświetla zainstalowane pakiety, które nie znajdują się już w żadnym włączonym repozytorium; w ten sposób znajdziesz pozostałości po repozytoriach, które nie zostały wydane dla nowej wersji systemu.

Wykonaj migawkę dysku przed krokiem pobierania. Transakcja przebiega w czasie, gdy nie widzisz ekranu, więc jeśli nie powiedzie się podczas startu offline, SSH nie będzie dostępne, a jedyną drogą dostępu pozostanie konsola dostarczona przez dostawcę, VNC lub połączenie szeregowe. Upewnij się, że masz dostęp do konsoli lub migawki przed rozpoczęciem, a nie po fakcie.

Jeszcze jedna kontrola, którą ludzie pomijają:

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

Gdy pakiet dostarcza nowy domyślny plik konfiguracyjny, a Ty edytowałeś stary, RPM nie nadpisuje Twojego pliku. Zapisuje wersję pakietową obok jako .rpmnew. Dzięki temu sshd lub nginx zachowują się dokładnie tak, jak w starym wydaniu, podczas gdy nowe ustawienia domyślne pozostają nieodczytane na dysku. Przeglądaj te pliki po każdej aktualizacji. Zainstalowanie rpmconf i uruchomienie sudo rpmconf -a pozwala przejrzeć je jeden po drugim i wskazuje różnice.

Zewnętrzne repozytoria są przyczyną niepowodzeń aktualizacji

Własne pakiety Fedora są aktualizowane jednocześnie w dniu wydania nowej wersji. Oprogramowanie pochodzące z zewnętrznych źródeł jest aktualizowane zgodnie z harmonogramem ich dostawców. Większość repozytoriów zewnętrznych zawiera $releasever w swoim adresie URL, więc w momencie aktualizacji system dnf zaczyna odpytywać o ścieżkę, 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 Fedora, przeprowadź test względem docelowej wersji 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 błędó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. Odczekaj kilka tygodni, aż dostawca opublikuje aktualizację, co zazwyczaj jest zalecanym krokiem. Alternatywnie wykonaj aktualizację bez tego 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 usuwanie zainstalowanych pakietów w celu rozwiązania konfliktów, dlatego przed zaakceptowaniem zmian należy dokładnie przejrzeć listę usuwanego oprogramowania. To właśnie na tej liście można przeoczyć serwer bazy danych, który miał zostać zachowany.

Co dzieje się z serwerem Fedora po przekroczeniu terminu wsparcia

W dniu wygaśnięcia wsparcia nie dzieje się nic. Problem pojawia się 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, przez co dnf upgrade kończy się błędem podczas pobierania metadanych, zwracając kod 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 dysponuje wspieraną metodą załatania 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 wymaga aktualizacji o jedno lub dwa wydania jednocześnie, więc w przypadku systemu starszego o cztery wersje konieczne jest wykonanie kilku skoków z rzędu. Każdy z nich wiąże się z ryzykiem awarii oraz koniecznością pracy w trybie offline. W przypadku VPS, ponowna instalacja systemu z aktualnego obrazu i przeniesienie danych jest zazwyczaj szybszym i bezpieczniejszym rozwiązaniem, wymagającym nakładu pracy porównywalnego z pierwszymi dziesięcioma minutami 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 trybu 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 okres 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 stanowi dobry wybór, 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 enterprise 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ę wyłącznie 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, zatem oprogramowanie budowane i uruchamiane dzisiaj na Fedorze jest testowane pod kątem platformy enterprise, która pojawi się za kilka lat.
• Maszyna z założenia ma krótki cykl życia. Serwer budowania (build runner) lub środowisko testowe, które zostanie usunięte za dwa miesiące, nigdy nie osiągnie daty końca wsparcia (EOL). Ta sama logika dotyczy tymczasowych maszyn wirtualnych udostępnianych agentom programistycznym, gdzie system jest przebudowywany znacznie częściej niż następują wydania Fedory.
• Istnieje osoba odpowiedzialna za aktualizacje. Fedora sprawdza się na serwerze, który ma przypisanego właściciela i zaplanowane zadania konserwacyjne. Jest natomiast nieodpowiednia dla maszyn, o których wszyscy zapomnieli.

Złoty środek: aktualne pakiety na stabilnej bazie

Większość osób oczekujących od serwera systemu Fedora potrzebuje dwóch lub trzech aktualnych pakietów, a nie aktualnego systemu operacyjnego. Te kwestie można rozdzielić. Należy uruchomić dystrybucję LTS lub kompilację klasy enterprise jako bazę, a następnie pobrać nowe oprogramowanie tylko tam, gdzie jest ono faktycznie wymagane. Obraz kontenera dostarcza nową wersję aplikacji na hosta, którego nigdy nie trzeba z tego powodu aktualizować (uruchamianie Docker na VPS). Repozytorium dostawcy dla pojedynczego pakietu, który jest istotny, na przykład PostgreSQL lub nginx, pozwala zaktualizować 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 pomaga, 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 kosztuje coroczne okno serwisowe.

Jeśli wybór padnie na Fedorę dla serwera, należy wpisać cykl wydawniczy do kalendarza. Gdy nowa wersja ma premierę, warto odczekać kilka tygodni, aż repozytoria dostawców zostaną zaktualizowane, wykonać snapshot, przeprowadzić aktualizację, a następnie zweryfikować, czy usługi działają poprawnie. Ten rytm kosztuje około godziny rocznie i sprawdza się w praktyce. Wersja, która zawodzi, to ta, 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 wyższej. 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ższą, a przeskakiwanie o dwa wydania jest standardowym sposobem pracy w cyklu aktualizacji raz na rok. Dalsze przeskoki nie są wspieraną ścieżką, a każde dodatkowe wydanie zwiększa ryzyko, że zmiana nazwy pakietu lub formatu konfiguracji przerwie transakcję. Jeśli maszyna jest już kilka wydań za obecną wersją i przekroczyła datę końca wsparcia, ponowna instalacja z aktualnego obrazu jest zazwyczaj szybsza niż łańcuch aktualizacji.

Co się dzieje, gdy serwer z systemem Fedora osiągnie koniec wsparcia?

System działa nadal, ale przestaje otrzymywać poprawki. Kolejne wywołanie dnf upgrade zakończy się błędem 404 przy próbie pobrania adresu URL metalink dla danego wydania, 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ć aktualizacje etapami lub zainstalować serwer od nowa na wspieranym wydaniu. 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 pełna aktualizacja systemu operacyjnego co rok, bezterminowo, na maszynie, której wolelibyśmy nie modyfikować. Wybierz system Fedora, gdy potrzebujesz jądra lub przestrzeni użytkownika nowszej niż ta oferowana w wydaniach LTS, lub gdy serwer z założenia ma krótki cykl życia. Wybierz wydanie LTS lub dystrybucję typu enterprise, jeśli chcesz aktualizować serwer przez lata bez zmiany jego wersji.