SSD Nodes Learn Hosting plans →
Przewodniki Matt ConnorAutor: Matt Connor · Zaktualizowano 2026-08-28

Ubuntu LTS czy wydanie tymczasowe na serwer?

Wybór między Ubuntu LTS a wersją tymczasową determinuje stabilność infrastruktury. LTS zapewnia 5 lat wsparcia, podczas gdy wydania tymczasowe wymagają aktualizacji co 9 miesięcy.

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 bezpieczeństwa. Wydanie tymczasowe otrzymuje dziewięć miesięcy, po czym aktualizacje ustają, co wymusza aktualizację systemu lub jego ponowną instalację. Wersję LTS należy stosować wszędzie tam, gdzie od stabilności systemu zależą inni użytkownicy. Wydania tymczasowe należy stosować tylko w środowiskach, w których ponowna instalacja 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. Wersja 26.04 LTS została wydana 23 kwietnia 2026, a jej 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

ChartSupport length and release upgrades needed over five years
The data behind this chart
[
  {
    "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
  }
]

Są to oficjalne zasady publikowane przez Canonical według stanu na sierpień 2026 roku, a nie pomiary z serwera testowego. Wydanie LTS obejmuje 60 miesięcy standardowej obsługi 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 te same pięć lat wymaga wykonania 10 aktualizacji, ponieważ nie można pominąć żadnego wydania, a w ciągu pięciu lat przypada 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 darmowa do użytku osobistego na maksymalnie pięciu maszynach, co obejmuje większość 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.

Ile kosztuje dziewięć miesięcy na rzeczywistym serwerze

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

Łańcuch terminów w praktyce

Instalujesz 26.10 w październiku 2026 i czekasz do ostatniego bezpiecznego momentu. Aktualizujesz system do 27.04 w czerwcu 2027, tuż przed końcem wsparcia 26.10. Jednak 27.04 ukazało się w kwietniu 2027, a jego dziewięciomiesięczny okres wsparcia kończy się w styczniu 2028. Twój drugi termin przypada siedem miesięcy po pierwszym, a nie dziewięć.

Kolejna aktualizacja w grudniu 2027 do 27.10, która ukazała się w październiku 2027 i kończy wsparcie w lipcu 2028. Od tego momentu schemat jest stały. Zawsze jesteś o jedną wersję za najnowszą, więc termin aktualizacji przypada mniej więcej co sześć miesięcy. Dziewięć miesięcy to długość wsparcia pojedynczego wydania, a nie odstęp między oknami serwisowymi.

Aktualizacja wydania zastępuje system operacyjny w miejscu. do-release-upgrade nadpisuje źródła apt, wyłącza repozytoria firm trzecich, zmienia wersję niemal każdego zainstalowanego pakietu, zatrzymuje się, aby zapytać o edytowane pliki konfiguracyjne i na końcu wykonuje 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 przerwaniem połączenia. Inicjuje ono własną sesję screen i otwiera drugą instancję sshd, informując o tym wcześniej:

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.

Pozwól na to. Jeśli firewall lub zewnętrzna zapora sieciowa dostawcy blokuje port 1022, ten mechanizm ratunkowy 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.

Pytania o pliki konfiguracyjne 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ń, dopóki nie zostaną przywrócone. Żadna z odpowiedzi nie jest bezpieczna bez wiedzy o tym, co zmieniło się w danej wersji, dlatego czytanie informacji o wydaniu (release notes) jest częścią okna serwisowego, a nie opcjonalnym zadaniem domowym.

Następnie pomnóż 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 jednorazowa i odtwarzana z obrazu. Pięć maszyn na ścieżce LTS to pięć aktualizacji w tym samym okresie, a miesiąc wykonania każdej z nich wybierasz samodzielnie.

Dlaczego nie można pominąć wydania Ubuntu

Ścieżki aktualizacji są sztywne. Wydanie tymczasowe aktualizuje się do kolejnego wydania, niezależnie od jego typu. Wydanie LTS aktualizuje się bezpośrednio do następnego wydania 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 i 27.10 lub ponownej instalacji systemu.

Warto znać ten mechanizm, ponieważ pokazuje on, że zasady nie podlegają negocjacjom. do-release-upgrade pobiera plik meta-release z changelogs.ubuntu.com, a następnie pobiera narzędzie aktualizacyjne przygotowane dla konkretnego przejścia. Canonical buduje i testuje tylko jedno przejście naraz, więc skok z pominięciem wydania nie posiada dedykowanego narzędzia ani testów. Mechanizm aktualizacji nie odmawia z nadmiernej ostrożności. Po prostu nie ma przygotowanej ścieżki do zaoferowania.

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 tylko kolejne wydanie LTS. Prompt=normal oferuje kolejne 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 przypadku wydania innego niż LTS, lts zachowuje się dokładnie tak samo jak normal, ponieważ kolejnym wydaniem po 26.10 jest 27.04 w obu ustawieniach. 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. Wydanie punktowe nie jest nową wersją Ubuntu, lecz tym samym wydaniem z czterema miesiącami poprawek włączonymi do nowego nośnika instalacyjnego. Okres oczekiwania istnieje po to, aby ścieżka aktualizacji przeszła cztery miesiące testów, zanim zostanie udostępniona użytkownikom. System 24.04 z ustawieniem Prompt=lts, który przez lato 2026 odpowiadał No new release found., nie był uszkodzony. Działał zgodnie z przyjętą polityką. Gdy ścieżka zostanie otwarta, aktualizacja z 24.04 do 26.04 LTS jest 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 archiwum 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.
  • Obsługa sprzętu lub funkcja hypervisora pojawiła się po zamrożeniu wersji LTS, a odpowiedni backport nie istnieje.
  • Weryfikowana jest zawartość przyszłego wydania LTS. Wersja 28.04 powstaje na bazie 26.10, 27.04 oraz 27.10, a wykrycie zmiany powodującej regresję na zapasowym VPS jest mniej kosztowne niż na serwerze produkcyjnym.

Większość użytkowników sięgających po wydanie pośrednie potrzebuje jednego nowszego pakietu, a nie nowszej dystrybucji. Istnieją dwa tańsze rozwiązania. Stos wsparcia sprzętowego (Hardware Enablement stack) wprowadza jądra z nowszych wydań do wersji LTS: w 24.04 jest to sudo apt install linux-generic-hwe-24.04, który jest aktualizowany w każdym wydaniu punktowym, począwszy od drugiego. W przypadku pojedynczej aplikacji, obraz kontenera lub własne repozytorium dostawcy pozwala zaktualizować jeden element 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 są repozytoria, z których 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ę nieaktualnym serwerem wystawionym na działanie Internetu.

Ostatni z wymienionych problemów przebiega w sposób cichy, co czyni go niebezpiecznym. Gdy wsparcie dla wydania wygasa, 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 pracę 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

Ten wpis wygląda identycznie na w pełni zaktualizowanym serwerze oraz na maszynie, której wydanie straciło wsparcie cztery miesiące temu. Jeśli nikt nie analizuje błędów apt ani nie śledzi daty zakończenia wsparcia, system nie informuje w żaden sposób, z którym przypadkiem masz do czynienia.

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 z obsługą 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, programowego RAID innego niż RAID 1 oraz zaszyfrowanej partycji /boot z użyciem LUKS. Podanym powodem jest fakt, że parsery wewnątrz bootloadera są częstym źródłem 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 podlegająca dyskusji, a nie wdrożona zmiana.

Dla 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ć samodzielnie, zamiast zakładać stan faktyczny. Jeśli system root znajduje się na ZFS, a /boot na btrfs lub wewnątrz LUKS, jest to dokładnie ten rodzaj zmiany, z którym użytkownik spotyka się najpierw w wydaniu tymczasowym. Wątek dyskusyjny zawiera poradę dla dotkniętych użytkowników: pozostać przy wersji LTS. Ta porada stanowi sedno argumentacji. Wydania tymczasowe służą testowaniu zmian. Wersja LTS otrzymuje je dopiero po dwóch latach, gdy wydania tymczasowe pozwolą wykryć wszelkie problemy.

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 dotychczas działające pliki konfiguracyjne mogą przestać funkcjonować. Aktualizacja domyślnych ustawień jest zadaniem wydań tymczasowych, 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ż jej późniejsza zmiana wymaga reinstalacji systemu 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 być zgodna z wybraną ścieżką, a nie z obrazem dostarczonym przez dostawcę. Polecenie do-release-upgrade -c na aktualnym wydaniu LTS powinno zwrócić No new release found.. Jeśli system proponuje wydanie pośrednie, oznacza to, że Prompt jest ustawione na normal i należy podjąć decyzję, czy było to działanie zamierzone. pro security-status raportuje, ile zainstalowanych pakietów jest objętych danym strumieniem aktualizacji oraz 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 ona widoczna, obok pozostałych notatek dotyczących konfiguracji serwera. Informacja ta powinna znaleźć się wraz z innymi zadaniami w pierwsze dziesięć minut na nowym VPS, ponieważ data wsparcia zapisana jedynie w pamięci jest tą, która mija niezauważona. 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, zanim flota serwerów zostanie przypisana do konkretnego systemu.

FAQ

Czy należy uruchamiać wydania 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 utrzymywanie środowiska produkcyjnego na tej ścieżce oznacza konieczność przeprowadzania obowiązkowej aktualizacji mniej więcej dwa razy w roku, bezterminowo. Uczciwymi wyjątkami są maszyny, które i tak są odtwarzane z obrazu, takie jak CI runners czy hosty budujące, gdzie aktualizacja polega na wdrożeniu nowej instancji, a nie na oknie serwisowym. 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 temu samemu cyklowi: premiera w kwietniu lub październiku, zakończenie wsparcia dziewięć miesięcy później. Wersja LTS otrzymuje pięć lat standardowego wsparcia bezpieczeństwa, rozszerzalnego do dziesięciu lat dzięki Ubuntu Pro, które od sierpnia 2026 roku jest bezpłatne do użytku osobistego na maksymalnie pięciu maszynach.

Czy podczas aktualizacji można pominąć wydania Ubuntu?

Nie. do-release-upgrade realizuje 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 nigdy nie jest oferowana.

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

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

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

Zazwyczaj nie, ponieważ wersja LTS nie zachowuje swojego pierwotnego 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 tego mechanizmu 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łej maszyny na ścieżkę wydań tymczasowych.