SSD Nodes Learn 🎉 VPS від $5.50/міс
Посібники Matt ConnorВід Matt Connor · Оновлено 2026-08-13

Ubuntu LTS чи проміжний випуск для сервера

Проміжний Ubuntu має 9 місяців оновлень і вимагає примусового переходу. LTS дає 5 років. Порівняйте реальну ціну кожного варіанта для сервера.

Ubuntu LTS та проміжні випуски: коротка відповідь

Вибір між Ubuntu LTS і проміжним випуском для сервера залежить від одного показника: як довго цей випуск отримує оновлення безпеки. LTS має 5 років стандартного супроводу безпеки. Проміжний випуск має 9 місяців, після чого оновлення припиняються, тому систему потрібно оновити або перебудувати. Використовуйте LTS для всього, від чого залежать інші користувачі. Проміжний випуск використовуйте лише там, де перебудову можна виконати без погодження з іншими.

LTS означає довгострокову підтримку. Canonical випускає один LTS кожні два роки, у квітні парних років, і один проміжний випуск кожні шість місяців між ними. 26.04 LTS випущено 23 квітня 2026 року, а його стандартний супровід безпеки триватиме до 2031 року. 26.10 має вийти 15 жовтня 2026 року. Це проміжний випуск, тому його період оновлень завершиться в липні 2027 року.

Скільки часу підтримується кожен випуск 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
  }
]

Це опубліковані Canonical нормативні показники станом на August 2026, а не результати вимірювань на тестовому сервері. Для LTS передбачено 60 місяців стандартного обслуговування безпеки. Це означає 1 планове оновлення випуску за п’ять років. Для проміжного випуску передбачено 9 місяців. Якщо протягом тих самих п’яти років залишатися на проміжних випусках, потрібно виконати 10 оновлень випуску, оскільки пропускати випуски не можна, а за п’ять років виходить десять таких випусків.

Підписка Ubuntu Pro збільшує період підтримки LTS до 120 місяців, тобто до десяти років, і розширює покриття з компонента main на весь архів. Станом на August 2026 Ubuntu Pro безкоштовний для особистого використання на щонайбільше п’яти машинах, чого достатньо для більшості невеликих флотів VPS. Для проміжних випусків еквівалентної пропозиції немає. Дев’ять місяців — це весь доступний період підтримки, і жодна підписка його не подовжує.

Скільки коштує дев’ять місяців на реальному сервері

Візьмімо 26.10 як практичний приклад. Цей випуск вийшов 15 October 2026, а його security maintenance завершується в July 2027. Це та сама дев’ятимісячна схема, за якою підтримка 25.10 завершилася в July 2026. Якщо дивитися лише на календар, здається, що одне maintenance window припадає на кожні три квартали. Це неправильний висновок, причому з фінансово невигідного боку.

Ланцюжок дедлайнів на практиці

Встановіть 26.10 у October 2026 і чекайте до останнього безпечного моменту. У June 2027, незадовго до завершення підтримки 26.10, ви оновлюєтеся до 27.04. Але 27.04 вийшов у April 2027, а його власні дев’ять місяців підтримки завершуються в January 2028. Другий дедлайн настає через сім місяців після першого, а не через дев’ять.

У December 2027 знову оновіться до 27.10. Він вийшов у October 2027, а його підтримка завершується в July 2028. Далі схема стає фіксованою. Ви завжди відстаєте на один випуск від поточного, тому дедлайн настає приблизно кожні шість місяців. Дев’ять місяців — це тривалість підтримки одного випуску. Це не інтервал між вашими maintenance window.

Оновлення випуску замінює операційну систему безпосередньо на місці. do-release-upgrade переписує apt sources, вимикає сторонні репозиторії, змінює версію майже кожного встановленого пакета, зупиняється, щоб запитати про відредаговані вами конфігураційні файли, а наприкінці перезавантажує систему. Тому це заплановане maintenance window, а не фонова задача.

Якщо запускати оновлення через ssh, інструмент захищає вас від розриву власного з’єднання. Він запускає окрему сесію screen і відкриває другий sshd, попередньо повідомляючи про це:

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.

Дозвольте це зробити. Якщо ваш firewall або окремий мережевий firewall провайдера блокує 1022, резервний канал буде недоступний. У разі розриву з’єднання це залишить систему з частково оновленим набором пакетів. Якщо самостійно працювати всередині tmux або screen, ви отримуєте такий самий захист на будь-якому сервері.

Запити щодо конфігураційних файлів перетворюють п’ятнадцятихвилинне оновлення на годинну процедуру:

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 ?

Якщо залишити свій файл, ви пропустите зміни в новому файлі за замовчуванням. Якщо взяти файл від package maintainer, ваші налаштування hardening зникнуть, доки ви не відновите їх. Жоден варіант не є безпечним без розуміння змін у цьому випуску. Тому читання release notes є частиною maintenance window, а не необов’язковим завданням.

Тепер помножте це на кількість серверів. Один VPS на interim track потребує десяти upgrade window за п’ять років. П’ять VPS — це п’ятдесят, якщо тільки кожен сервер не є disposable і не перебудовується з image. П’ять серверів на LTS track потребують п’яти оновлень за той самий період, і ви самі обираєте місяць для кожного з них.

Чому не можна пропускати випуск Ubuntu

Шляхи оновлення фіксовані. Проміжний випуск оновлюється до наступного випуску, незалежно від його типу. LTS оновлюється безпосередньо до наступного LTS або до наступного проміжного випуску, якщо ви явно цього попросите. Оновлення одразу через два випуски не підтримується. Щоб перейти з 26.10 на 28.04 LTS, потрібно послідовно пройти через 27.04 і 27.10 або перевстановити систему.

Механізм варто знати, оскільки він пояснює, чому це правило не можна обійти. do-release-upgrade отримує файл meta-release із changelogs.ubuntu.com, а потім завантажує інструмент оновлення, створений для конкретного переходу. Canonical створює та тестує переходи по одному, тому для переходу через випуск немає ні інструмента, ні результатів тестування. Інструмент оновлення не відмовляє з міркувань обережності. Для нього просто не існує відповідного сценарію.

Випуск, який вам буде запропоновано, визначається одним рядком конфігурації:

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

Prompt=lts пропонує лише наступний LTS. Prompt=normal пропонує наступний випуск, незалежно від того, є він LTS чи ні. Prompt=never нічого не пропонує. Так можна не дозволити колезі запустити оновлення, якого ви не планували. Для випуску, який не є LTS, lts працює так само, як normal, оскільки наступним випуском після 26.10 у будь-якому разі є 27.04. Перевірка виводить Checking for a new Ubuntu release, а потім або рядок New release ... available., або No new release found.

Є ще одне правило планування, про яке часто забувають. Оновлення з одного LTS до наступного LTS не пропонується в день виходу нового LTS. Воно стає доступним після першого point release, а вихід 26.04.1 заплановано на 27 August 2026. Система на 24.04 із Prompt=lts, яка протягом літа 2026 року повертала No new release found., не була несправною. Вона дотримувалася політики. Коли шлях стане доступним, оновлення з 24.04 до 26.04 LTS — це процедура, яку потрібно запланувати та відпрацювати.

Коли варто обрати проміжний реліз

Є чотири випадки, коли він справді має перевагу:

  • Вам потрібна версія kernel або userspace, якої немає в LTS archive, саме на цьому сервері й уже зараз.
  • Машина є build host, CI runner або тестовим сервером, який ви відновлюєте з image. Тоді оновлення означає створення нового екземпляра, а не maintenance window.
  • Підтримка hardware або функція hypervisor з’явилися після заморожування LTS, і backport відсутній.
  • Ви перевіряєте, що входитиме до наступного LTS. 28.04 збирається на основі 26.10, 27.04 і 27.10, а виявити несумісну зміну на резервному VPS дешевше, ніж на важливому сервері.

Більшість користувачів, які обирають проміжний реліз, потребують новішого пакета, а не новішого дистрибутива. Є два дешевші варіанти. Hardware enablement stack додає до LTS kernel з новіших релізів: у 24.04 це sudo apt install linux-generic-hwe-24.04, і він оновлюється під час кожного point release, починаючи з другого. Для окремого застосунку container image або власний repository постачальника оновлює один компонент, а не всю операційну систему.

Коли проміжний реліз є неправильним вибором

  • Будь-який сервер із платними користувачами або чергуванням on-call. Вам доведеться виконувати обов’язкове оновлення двічі на рік в обмін на версії пакетів, якими ви можете ніколи не скористатися.
  • Будь-який сервер, де unattended-upgrades автоматично встановлює оновлення безпеки. Ця автоматизація залежить від актуальності security pocket, з якого вона отримує пакети.
  • Флот серверів, який ви оновлюєте вручну, оскільки реальна вартість — це одне вікно обслуговування, помножене на кількість серверів.
  • Будь-який сервер, який ви налаштували, а потім не перевіряєте протягом року. Забутий проміжний реліз через дев’ять місяців стає сервером із доступом з Інтернету, на якому не встановлено виправлення безпеки.

Остання проблема виникає непомітно, і саме тому вона небезпечна. Коли термін підтримки релізу завершується, його пакети переміщуються до old-releases.ubuntu.com, тому sudo apt update починає отримувати помилки 404 під час звернення до archive.ubuntu.com. Списки пакетів на диску застарівають. unattended-upgrades продовжує запускатися за розкладом і записує такі рядки у /var/log/unattended-upgrades/unattended-upgrades.log:

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

Цей рядок однаково виглядає на повністю оновленому сервері та на сервері, термін підтримки релізу якого завершився чотири місяці тому. Якщо ніхто не читає помилки apt і не відстежує дату завершення підтримки, ніщо на сервері не повідомить, який із цих двох випадків ви бачите.

Тип зміни, яка спочатку потрапляє до проміжного випуску

У березні 2026 року інженер Canonical запропонував на Ubuntu Discourse вилучити підписаний завантажувач GRUB, який постачається для secure boot у 26.10. Пропозиція передбачає вилучення драйверів файлових систем для btrfs, hfsplus, xfs і zfs, обробників зображень JPEG і PNG, таблиць розділів Apple, /boot у LVM, програмного RAID, крім RAID 1, а також зашифрованого LUKS /boot. Зазначена причина полягає в тому, що парсери всередині завантажувача регулярно стають джерелом вразливостей безпеки, а логіка роботи зі сховищами та шифруванням має належати initramfs — невеликій початковій файловій системі в RAM, яку ядро монтує перед справжньою кореневою файловою системою. Станом на серпень 2026 року це пропозиція, яку обговорюють, а не зміна, що вже постачається.

Для більшості VPS це нічого не змінить, оскільки вони завантажуються без secure boot із простого ext4 /boot у таблиці розділів GPT. Перевірте свою конфігурацію, а не робіть припущення. Якщо коренева файлова система — ZFS або /boot розташований у btrfs чи всередині LUKS, це саме той клас змін, який спочатку може зачепити вас у проміжному випуску. Власна порада в обговоренні для користувачів, яких це стосується, — залишатися на LTS. В одному реченні це пояснює весь підхід. Проміжні випуски призначені для випробування змін. До LTS зміни потрапляють після того, як два роки проміжних випусків покажуть, що саме вони ламають.

Та сама закономірність у меншому масштабі проявляється в кожному проміжному випуску. Версії бази даних, мовного середовища виконання та конфігурації init за замовчуванням оновлюються, тому конфігураційні файли, які працювали раніше, можуть перестати працювати. Оновлення версій за замовчуванням — це завдання, заради якого існує проміжний випуск. Тому читання приміток до випуску перед кожним із цих десяти оновлень є частиною ціни, на яку ви погодилися.

Вибір треку під час інсталяції системи

Виберіть трек під час інсталяції, оскільки його подальша зміна потребує повторної інсталяції або ланцюжка оновлень. На новому сервері чотири команди покажуть поточний стан:

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

lsb_release -a має назвати потрібний вам реліз, а в LTS рядок опису має закінчуватися на LTS. Рядок Prompt має відповідати вибраному треку, а не треку, який випадково постачався в образі провайдера. do-release-upgrade -c у поточній LTS має повернути No new release found.. Якщо натомість пропонується проміжний реліз, для Prompt встановлено значення normal, і потрібно визначити, чи було це зроблено навмисно. pro security-status показує, скільки інстальованих пакетів охоплює кожен потік оновлень, і прямо повідомляє, якщо машина не підключена до підписки.

Потім запишіть дату завершення підтримки там, де ви знову її побачите, поруч з іншими нотатками щодо розгортання цього сервера. Це слід зробити разом з іншими діями з перших десяти хвилин на новому VPS, оскільки дата підтримки, яка зберігається лише в чиїйсь пам’яті, закінчується непомітно. Якщо ви намагаєтеся повністю уникнути шестимісячного циклу оновлень, перед тим як закріпити за одним із варіантів цілий парк серверів, варто годину почитати про модель релізів FreeBSD у порівнянні з Linux.

FAQ

Чи варто запускати проміжний випуск Ubuntu на production-сервері?

Майже завжди — ні. Проміжний випуск припиняє отримувати оновлення безпеки через дев’ять місяців після релізу. Тому production на такому треку означає обов’язкове вікно оновлення приблизно двічі на рік без визначеного кінця. Виправданий виняток — машини, які все одно щоразу розгортаються з образу, наприклад CI-runner і build-host. Для них оновлення означає створення нового екземпляра, а не планове вікно обслуговування. Якщо від сервера залежать реальні користувачі, встановіть LTS і використайте зекономлені вікна обслуговування для інших завдань.

Як довго підтримується проміжний випуск Ubuntu?

Дев’ять місяців. 26.10 виходить 15 October 2026, а його security maintenance завершується в July 2027. Такий самий цикл мав 25.10, підтримка якого завершилася в July 2026. Кожен проміжний випуск має такий самий цикл: виходить у April або October і завершується через дев’ять місяців. LTS отримує п’ять років стандартної підтримки безпеки. З Ubuntu Pro цей період збільшується до десяти років. Станом на August 2026 Ubuntu Pro безкоштовний для персонального використання на щонайбільше п’яти машинах.

Чи можна пропустити випуски Ubuntu під час оновлення?

Ні. do-release-upgrade переходить на один крок за раз: проміжний випуск оновлюється до наступного випуску, а LTS можна безпосередньо оновити до наступного LTS. Щоб перейти з 26.10 на 28.04 LTS, спочатку потрібно виконати оновлення через 27.04 і 27.10 або перевстановити машину. Canonical створює та тестує кожен перехід окремо, а засіб оновлення завантажує інструмент для конкретного переходу. Тому для переходу через два випуски немає відповідного інструмента, і такий перехід ніколи не пропонується.

Що станеться, коли для мого випуску Ubuntu завершиться підтримка?

Його пакети переміщуються до old-releases.ubuntu.com. Через це sudo apt update починає отримувати помилки 404 під час звернення до archive.ubuntu.com, а нові оновлення безпеки для цього випуску взагалі більше не публікуються. Машина не повідомляє про це окремо. Сервер продовжує працювати й обслуговувати мережевий трафік, але кожна нова вразливість у ньому залишається невиправленою. Відновлення означає оновлення випуску в умовах обмеженого часу або повторне розгортання. Тому стежте за датою завершення підтримки, а не чекайте появи симптомів.

Чи не надто старе ядро LTS для нового обладнання?

Зазвичай ні, оскільки LTS не використовує початкове ядро протягом усіх п’яти років. Стек hardware enablement, HWE, додає до LTS ядра з новіших випусків у point release. Серверну інсталяцію можна підключити до цього стека за допомогою пакета, такого як linux-generic-hwe-24.04. Перед тим як вважати ядро причиною проблеми, перевірте поточну версію за допомогою uname -r. Якщо бракує версії userspace, а не ядра, контейнер або репозиторій постачальника буде значно меншою зміною, ніж переведення всієї машини на проміжний трек.