Ubuntu LTS czy wydanie tymczasowe na serwer?

Ubuntu LTS a wydania tymczasowe: krótka odpowiedź

Wybór między Ubuntu LTS a wydaniem tymczasowym na serwerze sprowadza się do jednej liczby: czasu, przez jaki wydanie otrzymuje aktualizacje bezpieczeństwa. Wersja LTS otrzymuje pięć lat standardowego wsparcia technicznego. Wydanie tymczasowe otrzymuje dziewięć miesięcy wsparcia, po czym aktualizacje ustają, co wymusza aktualizację systemu lub jego ponowną instalację. Wersję LTS należy stosować w przypadku usług, od których zależą inni użytkownicy. Wydania tymczasowe należy stosować tylko tam, gdzie ponowna instalacja systemu nie wymaga niczyjej zgody.

LTS oznacza long term support. Canonical publikuje jedno wydanie LTS co dwa lata, w kwietniu lat parzystych, oraz jedno wydanie tymczasowe co sześć miesięcy w międzyczasie. 26.04 LTS ukazało się 23 kwietnia 2026, a jego standardowe wsparcie bezpieczeństwa trwa do 2031 roku. Premiera 26.10 zaplanowana jest na 15 października 2026; jest to wydanie tymczasowe, więc jego cykl życia kończy się w lipcu 2027 roku.

Czas wsparcia poszczególnych wydań Ubuntu

[
  {
    "label": "LTS, standard support",
    "support_months": 60,
    "upgrades_over_5_years": 1
  },
  {
    "label": "LTS with Ubuntu Pro",
    "support_months": 120,
    "upgrades_over_5_years": 0
  },
  {
    "label": "Interim release",
    "support_months": 9,
    "upgrades_over_5_years": 10
  }
]

Poniższe dane stanowią oficjalną politykę firmy Canonical według stanu na sierpień 2026 roku i nie są wynikami pomiarów z serwera testowego. Wydanie LTS obejmuje 60 miesięcy standardowego wsparcia bezpieczeństwa, co przekłada się na 1 planowaną aktualizację wydania w ciągu pięciu lat. Wydanie tymczasowe (interim) jest wspierane przez 9 miesięcy. Pozostanie na ścieżce wydań tymczasowych przez ten sam okres pięciu lat wymaga wykonania 10 aktualizacji, ponieważ nie można pominąć żadnego wydania, a w ciągu pięciu lat ukazuje się ich dziesięć.

Subskrypcja Ubuntu Pro wydłuża okres wsparcia dla wersji LTS do 120 miesięcy, czyli dziesięciu lat, oraz rozszerza zakres ochrony z komponentu main na całe archiwum. Według stanu na sierpień 2026 roku, subskrypcja Pro jest bezpłatna do użytku osobistego na maksymalnie pięciu maszynach, co pokrywa zapotrzebowanie większości małych flot VPS. Dla wydań tymczasowych nie istnieje odpowiednik tej usługi. Dziewięć miesięcy to pełna oferta i żadna subskrypcja jej nie wydłuża.

Koszty dziewięciu miesięcy na serwerze produkcyjnym

Przyjmijmy 26.10 jako przykład roboczy. Wersja ta ma premierę 15 października 2026 roku, a jej wsparcie bezpieczeństwa kończy się w lipcu 2027 roku. To ten sam dziewięciomiesięczny cykl, który zakończył wsparcie 25.10 w lipcu 2026 roku. Patrząc na kalendarz, można odnieść wrażenie, że okno serwisowe przypada raz na trzy kwartały. Taka interpretacja jest błędna i prowadzi do niedoszacowania kosztów.

Aktualizacja wydania zastępuje system operacyjny w miejscu. do-release-upgrade nadpisuje źródła apt, wyłącza repozytoria stron trzecich, zmienia wersję niemal każdego zainstalowanego pakietu, przerywa proces, aby zapytać o edytowane pliki konfiguracyjne i na końcu wymusza restart. Dlatego jest to zaplanowane okno serwisowe, a nie zadanie działające w tle.

Uruchomienie procesu przez ssh sprawia, że narzędzie chroni przed skutkami zerwania połączenia. Inicjuje ono własną sesję screen i otwiera drugą instancję sshd, o czym informuje użytkownika:

To make recovery in case of failure easier, an additional sshd will
be started on port '1022'. If anything goes wrong with the running ssh
you can still connect to the additional one.

Należy na to pozwolić. Jeśli firewall lub zewnętrzny firewall dostawcy blokuje port 1022, mechanizm awaryjny nie zadziała, a zerwane połączenie pozostawi system z częściowo zaktualizowanymi pakietami. Uruchomienie procesu wewnątrz tmux lub screen zapewnia taką samą ochronę na każdej maszynie.

Monity dotyczące plików konfiguracyjnych sprawiają, że piętnastominutowa aktualizacja zmienia się w godzinną:

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?

Zachowanie własnego pliku oznacza pominięcie zmian w nowych ustawieniach domyślnych. Przyjęcie pliku opiekuna pakietu oznacza utratę własnych zabezpieczeń do czasu ich ręcznego przywrócenia. Żadna z tych odpowiedzi nie jest bezpieczna bez wiedzy o zmianach w danym wydaniu, dlatego czytanie informacji o wydaniu (release notes) jest częścią okna serwisowego, a nie opcjonalnym zadaniem domowym.

Następnie należy pomnożyć to przez liczbę maszyn. Jeden VPS na ścieżce interim to dziesięć okien aktualizacyjnych w ciągu pięciu lat. Pięć maszyn VPS to pięćdziesiąt okien, chyba że każda maszyna jest traktowana jako jednorazowa i odtwarzana z obrazu. Pięć maszyn na ścieżce LTS to pięć aktualizacji w tym samym okresie, przy czym sam wybierasz miesiąc, w którym każda z nich się odbędzie.

Dlaczego nie można pominąć wydania Ubuntu

Ścieżki aktualizacji są sztywne. Wydanie tymczasowe aktualizuje się do kolejnego wydania, niezależnie od tego, jakie ono jest. Wydanie LTS aktualizuje się bezpośrednio do następnego LTS lub do kolejnego wydania tymczasowego, jeśli użytkownik o to poprosi. Żaden proces nie aktualizuje systemu o dwa kroki jednocześnie. Przejście z 26.10 do 28.04 LTS wymaga przejścia przez 27.04 oraz 27.10 lub ponownej instalacji systemu.

Warto znać ten mechanizm, ponieważ pokazuje on, że zasada ta nie podlega negocjacjom. do-release-upgrade pobiera plik meta-release z changelogs.ubuntu.com, a następnie pobiera narzędzie aktualizacyjne przygotowane dla jednego, konkretnego przejścia. Canonical tworzy i testuje przejścia pojedynczo, więc skok pomijający wydanie nie posiada dedykowanego narzędzia ani testów. Mechanizm aktualizacji nie odmawia działania z nadmiernej ostrożności. Po prostu nie ma w nim odpowiednich danych do przeprowadzenia takiej operacji.

To, jakie wydanie zostanie zaproponowane, zależy od jednej linii konfiguracji:

grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Prompt=lts oferuje wyłącznie następne wydanie LTS. Prompt=normal oferuje następne wydanie, niezależnie od tego, czy jest to LTS, czy nie. Prompt=never nie oferuje niczego; jest to sposób na powstrzymanie współpracownika przed rozpoczęciem nieplanowanej aktualizacji. W systemie, który nie jest wydaniem LTS, lts zachowuje się dokładnie tak samo jak normal, ponieważ kolejnym wydaniem po 26.10 jest 27.04, niezależnie od wybranego ustawienia. Sprawdzenie wyświetla Checking for a new Ubuntu release, a następnie linię New release ... available. lub No new release found..

Istnieje jeszcze jedna zasada harmonogramowania, która często zaskakuje użytkowników. Aktualizacja z LTS do LTS nie jest oferowana w dniu premiery nowego wydania LTS. Zostaje ona udostępniona wraz z pierwszym wydaniem punktowym, a 26.04.1 jest zaplanowane na 27 sierpnia 2026. Maszyna z 24.04 i ustawieniem Prompt=lts, która przez całe lato 2026 odpowiadała No new release found., nie była uszkodzona. Działała zgodnie z przyjętą polityką. Gdy ścieżka zostanie otwarta, aktualizacja z 24.04 do 26.04 LTS będzie procesem, który należy zaplanować i przetestować.

Kiedy wydanie pośrednie jest właściwym wyborem

Cztery przypadki, w których jest to korzystne rozwiązanie:

• Wymagana jest wersja jądra lub przestrzeni użytkownika, której nie zawiera repozytorium LTS, a jest ona niezbędna na danej maszynie w tym momencie.
• Maszyna pełni rolę serwera budowania, agenta CI lub środowiska testowego, które jest odtwarzane z obrazu, więc aktualizacja oznacza wdrożenie nowej instancji zamiast okna serwisowego.
• Funkcjonalność sprzętu lub hiperwizora pojawiła się po zamrożeniu wersji LTS i nie istnieje dla niej żaden backport.
• Sprawdzana jest zawartość przyszłego wydania LTS. Wersja 28.04 jest budowana na bazie 26.10, 27.04 oraz 27.10, a wykrycie zmian powodujących regresję na zapasowym VPS jest mniej kosztowne niż na serwerze produkcyjnym.

Większość osób sięgających po wydanie pośrednie potrzebuje tylko jednego nowszego pakietu, a nie nowszej dystrybucji. Istnieją dwa tańsze rozwiązania. Stos włączenia sprzętu (Hardware Enablement stack) wprowadza jądra z późniejszych wydań do wersji LTS: w 24.04 jest to sudo apt install linux-generic-hwe-24.04, a wersja ta jest aktualizowana w każdym kolejnym wydaniu punktowym, począwszy od drugiego. W przypadku pojedynczej aplikacji, obraz kontenera lub własne repozytorium dostawcy pozwala na aktualizację jednego komponentu zamiast całego systemu operacyjnego.

Kiedy wydanie tymczasowe jest niewłaściwym wyborem

• Każdy system obsługujący płacących użytkowników lub objęty dyżurem technicznym. Akceptujesz wtedy obowiązkową aktualizację dwa razy w roku w zamian za wersje pakietów, których możesz nigdy nie użyć.
• Każdy serwer, na którym unattended-upgrades odpowiada za poprawki bezpieczeństwa. Ta automatyzacja jest skuteczna tylko w takim stopniu, w jakim aktualne jest repozytorium, z którego pobiera pakiety.
• Infrastruktura aktualizowana ręcznie, ponieważ rzeczywisty koszt to czas jednego okna serwisowego pomnożony przez liczbę maszyn.
• Każda usługa, którą instalujesz i do której nie zaglądasz przez rok. Wydanie tymczasowe, o którym zapomniałeś, po dziewięciu miesiącach staje się niezałatatanym serwerem wystawionym na działanie Internetu.

Ostatni z wymienionych problemów przebiega w sposób cichy, co czyni go niebezpiecznym. Gdy wsparcie dla wydania kończy się, pakiety są przenoszone do old-releases.ubuntu.com, przez co sudo apt update zaczyna zgłaszać błędy 404 przy próbie połączenia z archive.ubuntu.com. Listy pakietów na dysku stają się nieaktualne. unattended-upgrades kontynuuje działanie zgodnie z harmonogramem i zapisuje w /var/log/unattended-upgrades/unattended-upgrades.log linie o następującej treści:

No packages found that can be upgraded unattended and no pending auto-removals

Ta linia wygląda identycznie na w pełni załatatanym serwerze, jak i na maszynie, której wydanie straciło wsparcie cztery miesiące temu. Jeśli nikt nie analizuje błędów apt lub nie śledzi daty zakończenia wsparcia, żaden element systemu nie poinformuje o stanie, w jakim znajduje się serwer.

Rodzaj zmian trafiających najpierw do wydań tymczasowych

W marcu 2026 roku inżynier Canonical zaproponował na forum Ubuntu usunięcie podpisanego bootloadera GRUB, który jest dostarczany w wersji 26.10 w ramach mechanizmu secure boot. Propozycja zakłada usunięcie sterowników systemów plików btrfs, hfsplus, xfs i zfs, parserów obrazów JPEG i PNG, tablic partycji Apple, /boot na LVM, programowych macierzy RAID innych niż RAID 1 oraz zaszyfrowanych partycji LUKS /boot. Podanym powodem jest fakt, że parsery wewnątrz bootloadera stanowią powracające źródło błędów bezpieczeństwa, a logika obsługi pamięci masowej i szyfrowania powinna znajdować się w initramfs, czyli małym początkowym systemie plików RAM, który jądro montuje przed właściwym systemem root. Według stanu na sierpień 2026 roku jest to propozycja poddawana dyskusji, a nie wdrożona zmiana.

W przypadku większości instancji VPS nie zmieniłoby to niczego, ponieważ uruchamiają się one bez secure boot z prostego systemu plików ext4 /boot na tablicy partycji GPT. Należy to sprawdzić, zamiast zakładać stan faktyczny. Jeśli system root znajduje się na ZFS, lub /boot korzysta z btrfs albo znajduje się wewnątrz LUKS, jest to dokładnie ten rodzaj zmiany, który napotyka się najpierw w wydaniach tymczasowych. Rada udzielona w wątku użytkownikom, których to dotyczy, brzmi: pozostać przy wersji LTS. Ta rada stanowi cały argument w jednym zdaniu. Wydania tymczasowe służą do testowania zmian. Wersja LTS to miejsce, do którego trafiają one po dwóch latach, gdy wydania tymczasowe wykażą, co uległo awarii.

Ten sam schemat pojawia się w mniejszej skali przy każdym wydaniu tymczasowym. Domyślne wersje baz danych, środowisk uruchomieniowych języków programowania oraz konfiguracji init ulegają zmianie, przez co pliki konfiguracyjne, które działały, mogą przestać funkcjonować. Przesuwanie domyślnych ustawień do przodu jest zadaniem wydania tymczasowego, co oznacza, że lektura informacji o wydaniu przed każdą z tych dziesięciu aktualizacji jest częścią ceny, na którą użytkownik wyraził zgodę.

Wybór ścieżki wydawniczej podczas przygotowywania serwera

Ścieżkę wydawniczą należy wybrać w momencie instalacji, ponieważ późniejsza zmiana wymaga reinstalacji lub serii aktualizacji. Na nowym serwerze cztery polecenia pozwalają określić bieżący stan:

lsb_release -a
grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c
pro security-status

lsb_release -a powinno wskazywać wydanie, które miało zostać zainstalowane, a w przypadku wersji LTS linia opisu kończy się frazą LTS. Linia Prompt powinna odpowiadać wybranej ścieżce, a nie obrazowi dostarczonemu przez dostawcę. Polecenie do-release-upgrade -c na aktualnym wydaniu LTS powinno zwrócić No new release found.. Jeśli system oferuje wydanie tymczasowe, oznacza to, że Prompt jest ustawione na normal i należy ustalić, czy było to działanie zamierzone. pro security-status raportuje, ile zainstalowanych pakietów jest objętych danym strumieniem aktualizacji i informuje wprost, gdy maszyna nie jest przypisana do subskrypcji.

Następnie należy zapisać datę zakończenia wsparcia (end of life) w miejscu, w którym będzie łatwo dostępna, obok pozostałych notatek dotyczących konfiguracji serwera. Czynność ta powinna zostać wykonana wraz z innymi zadaniami opisanymi w pierwsze dziesięć minut na nowym VPS, ponieważ data wsparcia przechowywana jedynie w pamięci jest tą, która mija niezauważenie. Jeśli celem jest całkowite uniknięcie sześciomiesięcznego cyklu wydawniczego, warto poświęcić godzinę na lekturę model wydawniczy FreeBSD w porównaniu z Linux przed podjęciem decyzji o wyborze systemu dla całej infrastruktury.

FAQ

Czy powinienem uruchamiać wydanie tymczasowe Ubuntu na serwerze produkcyjnym?

W niemal każdym przypadku nie. Wydanie tymczasowe przestaje otrzymywać aktualizacje bezpieczeństwa dziewięć miesięcy po premierze, więc praca produkcyjna w tym cyklu oznacza konieczność przeprowadzania obowiązkowej aktualizacji mniej więcej dwa razy w roku, bez końca. Uczciwymi wyjątkami są maszyny, które i tak są odtwarzane z obrazu, takie jak CI runners czy hosty budujące, gdzie aktualizacja oznacza nową instancję, a nie okno serwisowe. Jeśli od serwera zależą realni użytkownicy, należy zainstalować wersję LTS, a zaoszczędzony czas poświęcić na inne zadania.

Jak długo wspierane jest wydanie tymczasowe Ubuntu?

Dziewięć miesięcy. Wersja 26.10 debiutuje 15 października 2026 roku, a jej wsparcie bezpieczeństwa kończy się w lipcu 2027 roku; analogicznie wsparcie dla 25.10 zakończyło się w lipcu 2026 roku. Każde wydanie tymczasowe podlega tej samej zasadzie: premiera w kwietniu lub październiku, zakończenie wsparcia dziewięć miesięcy później. Wydanie LTS otrzymuje pięć lat standardowego wsparcia bezpieczeństwa, rozszerzalnego do dziesięciu lat dzięki Ubuntu Pro, które od sierpnia 2026 roku jest darmowe do użytku osobistego na maksymalnie pięciu maszynach.

Czy mogę pominąć wydania Ubuntu podczas aktualizacji?

Nie. do-release-upgrade wykonuje proces krok po kroku: wydanie tymczasowe przechodzi do kolejnego wydania, a wersja LTS może przejść bezpośrednio do następnej wersji LTS. Przejście z 26.10 do 28.04 LTS wymaga przeprowadzenia aktualizacji najpierw przez 27.04 i 27.10 lub reinstalacji maszyny. Canonical buduje i testuje przejścia pojedynczo, a narzędzie aktualizujące pobiera dane dla konkretnego skoku, dlatego dla przeskoku dwuetapowego nie istnieje odpowiednie narzędzie i taka ścieżka nie jest oferowana.

Co się dzieje, gdy moje wydanie Ubuntu osiąga koniec cyklu życia?

Pakiety przenoszone są do old-releases.ubuntu.com, przez co sudo apt update zaczyna zwracać błędy 404 przy próbie połączenia z archive.ubuntu.com i żadne nowe aktualizacje bezpieczeństwa nie są już publikowane dla tego wydania. System nie informuje o tym fakcie. Serwer nadal działa i obsługuje ruch, podczas gdy każda nowo wykryta luka pozostaje otwarta. Odzyskanie sprawności wymaga przeprowadzenia aktualizacji wydania pod presją czasu lub przebudowy systemu, dlatego należy monitorować daty, zamiast czekać na wystąpienie objawów.

Czy jądro LTS jest zbyt stare dla nowego sprzętu?

Zazwyczaj nie, ponieważ wydanie LTS nie korzysta z tego samego jądra przez pięć lat. Stos wsparcia sprzętowego, HWE, wprowadza jądra z nowszych wydań do wersji LTS w ramach wydań punktowych, a instalacja serwerowa może skorzystać z tej opcji poprzez pakiet taki jak linux-generic-hwe-24.04. Przed założeniem, że jądro stanowi blokadę, należy sprawdzić aktualnie używaną wersję za pomocą uname -r. Jeśli brakującym elementem jest wersja przestrzeni użytkownika, a nie jądro, użycie kontenera lub repozytorium dostawcy jest znacznie mniejszą zmianą niż przenoszenie całego systemu na ścieżkę wydań tymczasowych.