Ubuntu LTS или промежуточный релиз для сервера

Ubuntu LTS против промежуточных релизов: краткий ответ

Выбор между Ubuntu LTS и промежуточным релизом для сервера сводится к одному показателю: длительности получения обновлений безопасности. Версия LTS получает стандартную поддержку безопасности в течение 5 лет. Промежуточный релиз поддерживается 9 месяцев, после чего обновления прекращаются, и вам потребуется выполнить обновление системы или её переустановку. Используйте LTS для любых сервисов, от которых зависят другие пользователи. Используйте промежуточный релиз только там, где переустановка системы не требует согласования с кем-либо.

LTS означает long term support (долгосрочная поддержка). Canonical выпускает один релиз LTS каждые 2 года, в апреле чётных лет, и один промежуточный релиз каждые 6 месяцев в промежутках между ними. Версия 26.04 LTS вышла 23 апреля 2026 года, и её стандартная поддержка безопасности продлится до 2031 года. Релиз 26.10 ожидается 15 октября 2026 года; это промежуточный релиз, поэтому его поддержка завершится в июле 2027 года.

Сроки поддержки релизов 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
  }
]

Это официальные данные Canonical по состоянию на август 2026 года, а не результаты измерений на тестовом стенде. Релиз LTS включает 60 месяцев стандартного обслуживания безопасности, что соответствует 1 плановым обновлениям версии за пять лет. Промежуточный релиз поддерживается в течение 9 месяцев. Использование промежуточных релизов в течение тех же пяти лет потребует 10 обновлений версии, так как пропуск релиза невозможен, а за пять лет выходит десять версий.

Подписка Ubuntu Pro увеличивает срок поддержки LTS до 120 месяцев (десять лет) и расширяет покрытие с компонента main на весь архив. По состоянию на август 2026 года подписка Pro бесплатна для личного использования на пяти машинах, что покрывает потребности большинства небольших парков VPS. Для промежуточных релизов аналогичного предложения не существует. Девять месяцев — это полный срок поддержки, и никакая подписка его не продлевает.

Что на самом деле означают девять месяцев поддержки на сервере

Возьмем для примера 26.10. Этот релиз выходит 15 октября 2026 года, а его поддержка безопасности заканчивается в июле 2027 года. Это тот же девятимесячный цикл, который завершился для 25.10 в июле 2026 года. Если смотреть на календарь, кажется, что окно обслуживания открывается раз в три квартала. Такое прочтение календаря ошибочно, причем ошибка ведет к дополнительным расходам.

Обновление релиза заменяет операционную систему «на месте». 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.

Разрешите это. Если ваш межсетевой экран или сетевой экран провайдера блокирует порт 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 ?

Если оставить свой файл, вы пропустите изменения в новых параметрах по умолчанию. Если принять файл от мейнтейнера, ваши настройки безопасности будут сброшены, пока вы не вернете их обратно. Ни один из вариантов не является безопасным без понимания того, что изменилось в релизе, поэтому чтение примечаний к выпуску — это часть работы в окне обслуживания, а не необязательное домашнее задание.

Теперь умножьте это на количество серверов. Один VPS на промежуточной ветке — это десять окон обновления за пять лет. Пять VPS — это пятьдесят окон, если только каждый сервер не является «одноразовым» и не разворачивается из образа. Пять серверов на ветке LTS — это пять обновлений за тот же период, причем вы сами выбираете месяц, в который каждое из них произойдет.

Почему нельзя пропускать релизы 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. Оно становится доступным только с выходом первого точечного релиза (point release), а 26.04.1 запланирован на 27 августа 2026 года. Точечный релиз — это не новая версия Ubuntu, а тот же самый релиз с накопленными за четыре месяца исправлениями, включенными в установочный образ. Ожидание необходимо для того, чтобы путь обновления прошел четыре месяца тестирования, прежде чем его предложат пользователям. Если система 24.04 с настройкой Prompt=lts в течение лета 2026 года отвечала No new release found., это не означало поломку. Система следовала политике обновлений. Когда путь будет открыт, обновление с 24.04 до 26.04 LTS станет той задачей, которую следует спланировать и протестировать.

Когда промежуточный релиз — верный выбор

Четыре случая, когда это действительно оправдано:

• Вам на этой машине прямо сейчас нужны версия ядра или пользовательского окружения, которых нет в LTS-репозитории.
• Машина является сборочным узлом, CI-раннером или тестовым стендом, который вы пересоздаете из образа, поэтому обновление означает развертывание нового экземпляра, а не окно обслуживания.
• Поддержка оборудования или функции гипервизора появилась после заморозки LTS, а бэкпортов не существует.
• Вы проверяете, что будет содержать следующий LTS. Версия 28.04 собирается на основе 26.10, 27.04 и 27.10, и обнаружить критические изменения на запасном VPS дешевле, чем на основном сервере.

Большинству пользователей, выбирающих промежуточный релиз, нужен один более свежий пакет, а не новая версия дистрибутива. Существует два более простых решения. Стек аппаратного обеспечения (Hardware Enablement stack) переносит ядра из более поздних релизов в LTS: в 24.04 это sudo apt install linux-generic-hwe-24.04, и он обновляется с каждым точечным релизом, начиная со второго. Для отдельного приложения контейнерный образ или собственный репозиторий поставщика позволяют обновить один компонент вместо всей операционной системы.

Когда промежуточный релиз — неудачный выбор

• Любая система с платными пользователями или дежурствами (on-call). Вы соглашаетесь на обязательное обновление дважды в год ради версий пакетов, которые могут вам никогда не понадобиться.
• Любой сервер, где unattended-upgrades выполняет установку патчей безопасности. Эффективность этой автоматизации ограничена качеством репозитория безопасности, из которого она берет пакеты.
• Парк серверов, которые вы обновляете вручную, так как реальные затраты — это время на одно окно обслуживания, умноженное на количество машин.
• Любой сервис, который вы установили и не проверяли в течение года. Промежуточный релиз, о котором вы забыли, через девять месяцев превращается в сервер с уязвимостями, доступный из Интернета.

Последняя проблема опасна тем, что она незаметна. Когда срок поддержки релиза истекает, его пакеты перемещаются на 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 отказаться от использования подписанного загрузчика GRUB, который поставляется для Secure Boot в версии 26.10. Предложение подразумевает исключение драйверов файловых систем btrfs, hfsplus, xfs и zfs, парсеров изображений JPEG и PNG, поддержки таблиц разделов Apple, /boot на LVM, программных RAID (кроме RAID 1), а также LUKS-шифрованных /boot. Указанная причина заключается в том, что парсеры внутри загрузчика являются постоянным источником уязвимостей, а логика работы с хранилищами и шифрованием должна находиться в initramfs — небольшой начальной файловой системе в оперативной памяти, которую ядро монтирует до подключения основного корня. По состоянию на август 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 на продуктовом сервере?

Почти всегда — нет. Промежуточный релиз перестает получать обновления безопасности через девять месяцев после выпуска. Использование такого релиза в продакшене означает необходимость обязательного обновления системы примерно дважды в год на постоянной основе. Исключение составляют машины, которые вы в любом случае пересоздаете из образа, например, CI-раннеры или сборочные узлы: там обновление равносильно развертыванию нового экземпляра. Если от сервера зависят реальные пользователи, установите LTS-версию, а сэкономленное время потратьте на другие задачи.

Как долго поддерживается промежуточный релиз Ubuntu?

Девять месяцев. Релиз 26.10 выходит 15 октября 2026 года, а его поддержка безопасности заканчивается в июле 2027 года. Аналогичный цикл был у 25.10, поддержка которого завершилась в июле 2026 года. Каждый промежуточный релиз следует этому графику: выход в апреле или октябре, завершение поддержки через девять месяцев. LTS-релиз получает пять лет стандартной поддержки безопасности, которая продлевается до десяти лет с помощью Ubuntu Pro. По состоянию на август 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 не сохраняет исходное ядро в течение всех пяти лет. Стек поддержки оборудования (HWE) переносит ядра из более поздних релизов в LTS-версии вместе с точечными обновлениями. При установке на сервер можно подключить поддержку HWE с помощью пакета, например linux-generic-hwe-24.04. Перед тем как делать вывод, что ядро является препятствием, проверьте текущую версию с помощью uname -r. Если проблема заключается в версии пользовательского пространства (userspace), а не в ядре, использование контейнера или стороннего репозитория будет гораздо менее радикальным изменением, чем перевод всей машины на промежуточный релиз.