Ubuntu LTS чи проміжний випуск для сервера
Проміжний Ubuntu має 9 місяців оновлень і вимушене оновлення. LTS отримує 5 років. Порівняйте реальну ціну кожного варіанта для сервера.
Ubuntu LTS та проміжні випуски: коротка відповідь
Вибір між Ubuntu LTS і проміжним випуском для сервера зводиться до одного показника: як довго цей випуск отримує оновлення безпеки. LTS отримує 5 років стандартного супроводу безпеки. Проміжний випуск отримує 9 місяців оновлень, після чого вони припиняються, тому потрібно оновити систему або виконати її повторне розгортання. Використовуйте LTS для всього, від чого залежать інші користувачі або системи. Проміжний випуск використовуйте лише там, де повторне розгортання можна виконати без узгодження з іншими.
LTS означає long term support. Canonical випускає один LTS кожні 2 роки, у квітні парних років, і один проміжний випуск кожні 6 місяців між ними. 26.04 LTS випущено 23 April 2026, а його стандартний супровід безпеки триватиме до 2031. Випуск 26.10 заплановано на 15 October 2026. Це проміжний випуск, тому його цикл оновлень завершиться в July 2027.
Скільки часу підтримується кожен випуск Ubuntu
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. Якщо дивитися лише на календар, здається, що вікно обслуговування виникає раз на три квартали. Але такий підхід помилковий, причому з дорогими наслідками.
Ланцюжок дедлайнів на практичному прикладі
Встановіть 26.10 у October 2026 і дочекайтеся останнього безпечного моменту. У June 2027, незадовго до завершення підтримки 26.10, ви оновлюєтеся до 27.04. Але 27.04 вийшов у April 2027, а його власні дев’ять місяців підтримки завершуються в January 2028. Другий дедлайн настає через сім місяців після першого, а не через дев’ять.
У December 2027 знову оновіть систему — до 27.10, який вийшов у October 2027 і підтримується до July 2028. Далі схема стає сталою. Ви завжди відстаєте від поточного випуску на один реліз, тому дедлайн настає приблизно кожні шість місяців. Дев’ять місяців — це тривалість підтримки одного випуску. Це не інтервал між вашими вікнами обслуговування.
Оновлення випуску замінює операційну систему безпосередньо на місці. do-release-upgrade переписує джерела apt, вимикає сторонні репозиторії, змінює версії майже всіх встановлених пакетів, зупиняється, щоб запитати про змінені вами конфігураційні файли, а наприкінці перезавантажує систему. Тому це заплановане вікно обслуговування, а не фонове завдання.
Якщо запускати оновлення через 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 ?Якщо залишити свій файл, можна пропустити зміни, внесені до нового стандартного варіанта. Якщо взяти файл супроводжувача пакета, усі ваші налаштування hardening буде втрачено, доки ви не внесете їх повторно. Жоден із варіантів не є безпечним без розуміння змін у цьому випуску. Тому читання release notes є частиною вікна обслуговування, а не необов’язковим підготовчим завданням.
Далі врахуйте кількість серверів. Один VPS на interim track потребує десяти вікон оновлення за п’ять років. Для п’яти VPS це вже п’ятдесят вікон, якщо тільки кожен сервер не є одноразовим і не перебудовується з 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 -cPrompt=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. Point release — це не нова версія Ubuntu, а той самий випуск із чотирма місяцями накопичених виправлень, доданими до нового інсталяційного носія, і цей період очікування потрібен, щоб шлях оновлення пройшов чотири місяці тестування до того, як його запропонують користувачам. Система 24.04 із Prompt=lts, яка протягом літа 2026 року відповідала No new release found., не була несправною. Вона дотримувалася політики. Коли шлях стане доступним, оновлення з 24.04 до 26.04 LTS — це процедура, яку потрібно спланувати й відрепетирувати.
Коли проміжний випуск є правильним вибором
Чотири випадки, у яких він справді має перевагу:
- Вам потрібна версія kernel або userspace, якої немає в LTS-архіві, саме на цьому сервері й уже зараз.
- Машина є build host, CI runner або test box, який ви перебудовуєте з image. Тому оновлення створює новий instance, а не потребує maintenance window.
- Підтримка hardware або hypervisor з’явилася після заморожування LTS, а backport не існує.
- Ви перевіряєте, що міститиме наступний LTS. 28.04 формується на основі 26.10, 27.04 і 27.10, тому виявити breaking change на запасному 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 автоматично встановлює оновлення безпеки. Ця автоматизація залежить від того, наскільки актуальним і безпечним є 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 або не відстежує дату завершення підтримки, система сама не повідомляє, який із цих випадків має місце.
Тип зміни, яка спочатку потрапляє до interim track
У березні 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, це саме той клас змін, з яким ви вперше стикаєтеся в interim track. Уласна порада з обговорення для таких користувачів — залишатися на LTS. В одному реченні ця порада пояснює все. У interim-релізах тестують зміни. У LTS вони потрапляють після того, як два роки interim-релізів показали, що саме ці зміни ламають.
Та сама закономірність проявляється в меншому масштабі під час кожного interim-релізу. Версії бази даних, середовища виконання мови програмування та конфігурації init за замовчуванням оновлюються, тому конфігураційні файли, які працювали раніше, можуть перестати працювати. Оновлення значень за замовчуванням — це завдання, заради якого існує interim-реліз. Тому читання приміток до випуску перед кожним із цих десяти оновлень є частиною ціни, яку ви погодилися сплатити.
Вибір треку під час встановлення системи
Оберіть трек під час встановлення, оскільки його подальша зміна означає перевстановлення або ланцюжок оновлень. На новому сервері чотири команди покажуть поточний стан:
lsb_release -a
grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c
pro security-statuslsb_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 на такому треку означає обов’язкове оновлення приблизно двічі на рік і без кінцевої дати. Реальним винятком є машини, які все одно відновлюють з image, наприклад CI runners і build hosts. Для них оновлення означає створення нового екземпляра, а не заплановане вікно робіт. Якщо від сервера залежать реальні користувачі, встановіть LTS і використайте зекономлені вікна для інших завдань.
Як довго підтримується проміжний випуск Ubuntu?
Дев’ять місяців. 26.10 виходить 15 October 2026, а його security maintenance завершується в July 2027. Такий самий цикл завершився для 25.10 у July 2026. Кожен проміжний випуск проходить цей цикл: виходить у April або October і завершує підтримку через дев’ять місяців. LTS отримує п’ять років стандартного security maintenance, а з 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, а нові оновлення безпеки для цього випуску взагалі не публікуються. Машина не повідомляє про це окремо. Сервер продовжує працювати й обслуговувати network traffic, тоді як кожна нова вразливість у ньому залишається невиправленою. Відновлення означає виконати оновлення випуску під тиском часу або перебудувати систему. Тому стежте за датою, а не чекайте на симптоми.
Чи не надто старе ядро LTS для нового обладнання?
Зазвичай ні, оскільки LTS не використовує початкове ядро протягом усіх п’яти років. Hardware enablement stack, HWE, додає ядра з новіших випусків до LTS у point releases. Серверну інсталяцію можна підключити до цього стека за допомогою пакета, наприклад linux-generic-hwe-24.04. Перед тим як вважати ядро причиною проблеми, перевірте поточну версію за допомогою uname -r. Якщо бракує версії userspace, а не ядра, контейнер або vendor repository буде значно меншою зміною, ніж переведення всієї машини на проміжний трек.