Klasyczny CentOS 8 dziś jest przede wszystkim problemem operacyjnym, a nie nowym wyborem systemowym. Najważniejsze pytania brzmią: co naprawdę oznacza brak wsparcia, czy taki serwer można jeszcze bezpiecznie utrzymywać i na co najlepiej przejść dalej. W tym tekście porządkuję różnicę między dawnym CentOS Linux a CentOS Stream, pokazuję realne ryzyka i podaję sensowne ścieżki migracji.
Najważniejsze fakty, które warto znać od razu
- CentOS Linux 8 zakończył życie 31 grudnia 2021 roku, więc nie dostaje już poprawek bezpieczeństwa ani nowych wydań pakietów.
- CentOS Stream 8 również nie jest już aktywną ścieżką budowy, bo jego buildy zakończyły się 31 maja 2024 roku.
- W produkcji nie traktuję tej platformy jako rozwiązania docelowego - dziś to raczej dług techniczny niż stabilny fundament.
- Najrozsądniejsze kierunki to AlmaLinux, Rocky Linux albo RHEL, a w środowiskach testowych czasem CentOS Stream 9 lub 10.
- Największe ryzyko zwykle nie leży w samym kernelu, tylko w repozytoriach, zależnościach aplikacji i braku aktualizacji bezpieczeństwa.
- Jeśli system ma zostać jeszcze na chwilę, trzeba go izolować, monitorować i ograniczyć jego ekspozycję na internet.
Najpierw ustalmy, czym naprawdę jest ta wersja
W praktyce pod hasłem CentOS najczęściej kryje się dawny CentOS Linux 8, czyli klasyczna, stabilna gałąź zgodna binarnie z RHEL. To nie to samo co CentOS Stream, który jest modelem bardziej „pomiędzy” Fedora a RHEL i służy do śledzenia nadchodzących zmian, a nie do odtwarzania zamrożonego wydania enterprise. To rozróżnienie jest ważne, bo od niego zależy, czy mówimy o systemie do utrzymania, czy o systemie do zastąpienia.
Ja patrzę na to prosto: jeśli ktoś dziś mówi „mam CentOS 8”, zwykle chodzi o serwer, który stoi na starej bazie EL8 i wymaga decyzji architektonicznej. W 2026 roku nie jest to już temat o wyborze dystrybucji „na start”, tylko o tym, jak bezboleśnie wyjść z technologii, która zakończyła swój cykl życia. I właśnie dlatego dalsza część artykułu skupia się na skutkach, a nie na encyklopedycznej definicji.
To prowadzi bezpośrednio do najważniejszego pytania: co naprawdę znaczy brak wsparcia, kiedy system nadal się uruchamia i „wydaje się działać”.
Brak wsparcia to nie detal, tylko realne ryzyko
Po zakończeniu wsparcia nie ma nowych aktualizacji bezpieczeństwa, poprawek błędów ani sensownego powodu, by liczyć na świeże wersje pakietów z oficjalnych repozytoriów. Archiwalne pakiety trafiły do vault, czyli magazynu z zamrożonymi wydaniami, a nie do normalnego kanału aktualizacji. W praktyce oznacza to, że system może działać, ale przestaje się rozwijać i przestaje nadążać za resztą stosu technologicznego.
Najbardziej bolą trzy rzeczy:
- rosnące ryzyko podatności, bo błędy bezpieczeństwa nie są już łatane,
- problemy z nowymi zależnościami, gdy aplikacje wymagają nowszych bibliotek,
- większy koszt utrzymania, bo każdy kolejny miesiąc zwiększa różnicę między systemem a aktualnym ekosystemem Linuksa.
Do tego dochodzi jeszcze jeden szczegół, który często bywa ignorowany: dawny model nie migruje się sam. Nie ma automatycznego przejścia na nowszą gałąź, więc administrator musi sam zaplanować, kiedy i jak wymienić platformę. Jeśli serwer jest wystawiony do internetu, obsługuje dane klientów albo trzyma sekrety aplikacyjne, to ja nie zostawiałbym go w takim stanie ani na kolejne kwartały, ani tym bardziej na kolejne lata.
Zanim jednak wpiszesz wszystko do jednego worka „do wymiany”, warto sprawdzić, czy dany host jest jeszcze krytyczny i jak dokładnie jest używany.
Jak sprawdzić, czy taki system nadal ma sens u ciebie
Nie każdy stary serwer wymaga tej samej reakcji. Inaczej oceniam maszynę produkcyjną, inaczej wewnętrzny lab, a jeszcze inaczej urządzenie offline, które obsługuje jeden zamknięty proces. Gdybym miał szybko ocenić taki system, zacząłbym od prostych pytań:
- czy host ma dostęp z internetu albo przyjmuje ruch z zewnątrz,
- czy obsługuje dane wrażliwe, płatności, logowanie lub usługi dla klientów,
- czy ktoś jeszcze rozumie, po co ta maszyna istnieje,
- czy aplikacje na niej wymagają pakietów z zewnętrznych repozytoriów,
- czy da się odtworzyć środowisko na nowej dystrybucji bez utraty funkcji.
Pomagają też szybkie komendy kontrolne: cat /etc/os-release pokaże realne wydanie systemu, dnf repolist ujawni aktywne repozytoria, a rpm -qa | wc -l da przynajmniej orientację, jak rozbudowany jest stos pakietów. Jeśli widzisz w konfiguracji stare adresy mirrorów albo aplikacja nie instaluje się bez ręcznych obejść, to zwykle znak, że system jest już technicznie zamrożony.
W takiej sytuacji nie rozstrzygam pytania „czy działa”, tylko „czy nadal ma prawo istnieć w tej formie”. To naturalnie prowadzi do wyboru następnej dystrybucji.
Na co przejść zamiast niego
Jeśli zależy ci na zgodności z ekosystemem RHEL, najczęściej sens mają AlmaLinux, Rocky Linux albo płatny RHEL. Gdy potrzebujesz środowiska bliżej upstreamu, z którego częściej wynikają wcześniejsze zmiany, można rozważyć CentOS Stream, ale nie jako bezpośredni odpowiednik starego modelu „zamrożonego” CentOS. Ja dobieram cel migracji według tego, czy ważniejsza jest stabilność, wsparcie producenta, czy tempo zmian.
| Opcja | Kiedy ma sens | Co zyskujesz | Na co uważam |
|---|---|---|---|
| AlmaLinux 8 | Gdy chcesz możliwie mało zmieniać i utrzymać zgodność z EL8 | Stabilność, zgodność binarna, wsparcie do 2029 | Trzeba sprawdzić własne repozytoria i pakiety zewnętrzne |
| Rocky Linux 8 | Gdy szukasz konserwatywnej, przewidywalnej platformy serwerowej | Podobny model do klasycznego CentOS, wsparcie do 2029 | To nadal ten sam rodzinny model EL8, więc nie rozwiązuje wszystkich problemów aplikacyjnych |
| AlmaLinux 9 | Gdy możesz przy okazji wykonać szerszy upgrade | Nowocześniejszy stos, wsparcie do 2032 | Większy skok wersji oznacza więcej testów po stronie aplikacji |
| Rocky Linux 9 | Gdy potrzebujesz dłuższego horyzontu i nowej bazy | Wydłużony cykl życia, wsparcie do 2032 | Niektóre starsze aplikacje wymagają dostosowania konfiguracji |
| RHEL 8 lub 9 | Gdy potrzebujesz certyfikacji, vendor supportu i formalnych gwarancji | Wsparcie producenta, dokumentacja, ścieżki korporacyjne | Koszt i zależność od subskrypcji są realne, nie symboliczne |
| CentOS Stream 9 lub 10 | Gdy chcesz śledzić rozwój RHEL i akceptujesz szybsze zmiany | Bliższy kontakt z przyszłymi zmianami w ekosystemie | To nie jest najspokojniejszy wybór dla konserwatywnej produkcji |
Jeśli pytasz mnie o rekomendację dla typowego serwera po dawnym CentOS, najczęściej wybieram AlmaLinux albo Rocky Linux. Gdy klient i tak planuje większą modernizację, częściej opłaca się przeskoczyć od razu na 9 niż zamieniać jedną starą bazę EL8 na inną, bardzo podobną, ale nadal starszą. To właśnie tu widać różnicę między ruchem „na szybko” a ruchem sensownie zaplanowanym.
Gdy już wiesz, dokąd chcesz iść, trzeba jeszcze zrobić to tak, żeby nie wyłożyć produkcji przy pierwszym restarcie.
Jak przeprowadzić migrację bez nerwów
Najbezpieczniej traktować migrację jako proces, a nie pojedyncze polecenie. In-place migration, czyli konwersja bez reinstalacji, bywa wygodna, ale nie jest magicznym przyciskiem „napraw wszystko”. W praktyce zaczynam od uporządkowania środowiska, a dopiero potem uruchamiam narzędzie migracyjne albo decyduję się na czystą instalację.
- Spisz usługi, pakiety i repozytoria, z których faktycznie korzysta serwer.
- Zrób snapshot albo pełny backup konfiguracji i danych.
- Usuń stare lub zewnętrzne repozytoria, które mogą blokować konwersję.
- Jeśli system jest bardzo stary w obrębie EL8, najpierw doprowadź go do ostatniego dostępnego stanu 8.5 z archiwalnych repozytoriów.
- Wykonaj migrację na nową dystrybucję i od razu zweryfikuj boot, usługi oraz logi.
W środowiskach o małej liczbie usług konwersja może być szybka. W systemach z wieloma dodatkowymi repozytoriami, niestandardowym PHP, własnymi sterownikami albo oprogramowaniem zależnym od starego kernela, czysta instalacja bywa po prostu mniej ryzykowna. Ja zwykle wolę wybrać rozwiązanie, które daje przewidywalny wynik, nawet jeśli oznacza to więcej pracy na początku.
Po migracji sprawdzam nie tylko, czy system się uruchamia, ale też czy firewalld, SELinux, harmonogramy i integracje zewnętrzne działają tak samo jak wcześniej. To właśnie te szczegóły najczęściej ujawniają prawdziwy koszt zaniedbanego planu.
Jeśli musisz jeszcze zostać na starym systemie
Zdarzają się sytuacje, w których wymiana nie może nastąpić od razu: urządzenie działa offline, obsługuje zamkniętą linię produkcyjną albo jest częścią starego, trudnego do ruszenia procesu. W takim przypadku celem nie jest „udawać, że wszystko jest w porządku”, tylko ograniczyć ryzyko do minimum.
- Odseparuj maszynę od internetu, jeśli tylko to możliwe.
- Nie dokładaj nowych, zewnętrznych repozytoriów bez wyraźnej potrzeby.
- Włącz i utrzymuj SELinux w trybie enforcing.
- Ogranicz dostęp administracyjny do kilku zaufanych osób.
- Monitoruj logi, procesy i integralność konfiguracji, bo to jedyne sygnały ostrzegawcze, które zostają.
To nadal jest strategia tymczasowa, nie docelowa. Im dłużej taki system zostaje bez aktualizacji, tym bardziej rośnie koszt awaryjnego działania, a maleje liczba opcji dostępnych bez przestoju.
Najrozsądniejszy plan na 2026
Gdybym miał zamknąć ten temat jednym zdaniem, powiedziałbym tak: klasyczny CentOS 8 nie powinien już być platformą, na której buduje się nowe decyzje infrastrukturalne. W 2026 rozsądny plan wygląda zwykle tak: albo migrujesz do AlmaLinux lub Rocky Linux, jeśli chcesz zachować model podobny do dawnych serwerów EL8, albo wykorzystujesz okazję, żeby przejść na 9 i od razu wydłużyć sobie horyzont wsparcia.
Najgorsze, co można zrobić, to traktować działający serwer jak dowód bezpieczeństwa. Działanie nie oznacza jeszcze zgodności, aktualności ani przewidywalności. Jeśli ten system nadal gdzieś stoi, to moim zdaniem trzeba go już planować do wymiany, a nie do dalszego „przeczekania”.
