Сколько живёт Fedora Server на VPS

Как долго Fedora получает обновления безопасности?

Для Fedora Server примерно раз в год требуется обновление версии, пока существует сервер. Fedora выпускает новую версию примерно раз в шесть месяцев. Поддержка каждой версии продолжается примерно до четырех недель после выпуска версии, которая на две версии новее. В результате версия получает обновления примерно 13 месяцев. После этой даты для версии больше не выпускаются исправления безопасности. Сервер продолжает работать, но его набор пакетов больше никто не обновляет.

Даты позволяют увидеть это на конкретном примере. По состоянию на август 2026 года поддерживаются Fedora 43 и Fedora 44. Fedora 44 была выпущена 28 апреля 2026 года, а окончание ее поддержки запланировано на июнь 2027 года. Fedora 42 была выпущена в апреле 2025 года и достигла конца срока поддержки в мае 2026 года, через четыре недели после выхода Fedora 44. Поэтому сервер, созданный из образа Fedora 42, потерял поддержку через тринадцать месяцев, хотя администратор не допустил никаких ошибок.

Fedora против LTS: срок поддержки в месяцах

LTS означает long term support — долгосрочную поддержку: выпуск, для которого поставщик выпускает обновления безопасности в течение нескольких лет, а не месяцев. EOL означает end of life — окончание жизненного цикла, то есть дату прекращения выпуска обновлений. Ниже указано, что каждый проект публикует для выпуска, который вы установили бы сегодня.

[
  {
    "distro": "Fedora 44",
    "support_window": 13,
    "upgrades_per_decade": 10
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "support_window": 60,
    "upgrades_per_decade": 2
  },
  {
    "distro": "Debian 13 stable",
    "support_window": 36,
    "upgrades_per_decade": 3
  },
  {
    "distro": "AlmaLinux 10",
    "support_window": 120,
    "upgrades_per_decade": 1
  }
]

Fedora предоставляет 13 месяцев поддержки для каждого выпуска. Ubuntu LTS предоставляет 60, а корпоративный rebuild, такой как AlmaLinux, — 120. Во втором столбце указано количество необходимых обновлений. За десять лет Fedora требует примерно 10 обновлений всей операционной системы, тогда как для Ubuntu LTS это значение составляет 2. Значение 36 месяцев для Debian относится к стандартной поддержке безопасности, а отдельная команда LTS продлевает поддержку большинства выпусков примерно до пяти лет.

Это опубликованные сроки поддержки, проверенные в August 2026, а не измеренный uptime. Причины различий в периодичности описаны в материале о различиях между Ubuntu LTS и промежуточными выпусками на сервере. Здесь важно то, какой объём работ создаёт каждый вариант для вас.

Что на самом деле происходит при обновлении версии Fedora

DNF 5 — менеджер пакетов по умолчанию начиная с Fedora 41, и dnf запускает его. Команда system-upgrade входит в состав самого dnf5, поэтому сначала устанавливать плагин не нужно. Если вы переходите с сервера Debian или Ubuntu, для большинства повседневных команд есть прямой эквивалент apt в dnf, а приведённое ниже обновление версии — одна из немногих задач без полноценного аналога. Начните с текущего выпуска, полностью обновив пакеты:

sudo dnf upgrade --refresh
sudo reboot

Перезагрузка важна, потому что обновление учитывает установленные и работающие компоненты. Если обновление kernel или glibc применилось не полностью, следующий этап будет сложнее анализировать. Теперь подготовьте новый выпуск. Замените 44 на номер выпуска, до которого вы обновляетесь:

sudo dnf system-upgrade download --releasever=44

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

Затем запустите обновление:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status подтверждает, что транзакция подготовлена и ожидает запуска. dnf system-upgrade reboot перезагружает машину в режим offline transaction: минимальную загрузку, во время которой RPM выполняет транзакцию самостоятельно. Это необходимо, потому что замена glibc и systemd под работающими сервисами приводит к частично установленной системе. Сервер будет недоступен в течение всей транзакции, обычно несколько минут на небольшом VPS, после чего снова перезагрузится уже в новый выпуск. Запланируйте две перезагрузки и период, когда SSH не будет отвечать.

После возвращения сервера:

cat /etc/fedora-release
sudo dnf system-upgrade log --number=-1
sudo dnf distro-sync
sudo dnf repoquery --extras

/etc/fedora-release должна вывести строку вида Fedora release 44 (Forty Four). Подкоманда log выводит журнал транзакции из этой offline boot. Это единственная запись о том, что происходило, пока у вас не было shell. distro-sync устанавливает на новом выпуске версии всего, что осталось от старого. repoquery --extras выводит установленные пакеты, которых больше нет ни в одном включённом репозитории. Так можно найти остатки репозитория, для которого не был опубликован новый выпуск.

Создайте snapshot диска до этапа загрузки пакетов. Транзакция выполняется, пока вы не видите экран, поэтому при сбое во время offline boot SSH не вернётся. Единственным способом доступа будет консоль, которую предоставляет провайдер: VNC или serial. Убедитесь, что у вас есть консоль или snapshot, до начала операции, а не после неё.

Есть ещё одна проверка, которую часто пропускают:

sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'

Если пакет поставляет новый файл конфигурации по умолчанию, а вы изменили старый файл, RPM не перезаписывает его. Вместо этого он сохраняет упакованную версию рядом с ним под именем .rpmnew. Поэтому ваш sshd или nginx продолжает работать точно так же, как в старом выпуске, а новые значения по умолчанию остаются непрочитанными на диске. После каждого обновления просматривайте эти файлы. Установите rpmconf и запустите sudo rpmconf -a: команда последовательно обработает эти файлы и покажет различия.

Сторонние репозитории мешают обновлению

Собственные пакеты Fedora обновляются согласованно в день выхода релиза. Пакеты из внешних репозиториев обновляются по другому графику. В URL большинства репозиториев поставщиков есть $releasever, поэтому сразу после обновления dnf начинает запрашивать путь, которого может ещё не существовать.

Выведите список репозиториев:

sudo dnf repo list --enabled
grep -R -e baseurl -e metalink /etc/yum.repos.d/

Для каждого репозитория, который не относится к Fedora, проверьте его поддержку целевого релиза до начала обновления:

sudo dnf --releasever=44 --repo=docker-ce-stable makecache

Если поставщик уже опубликовал репозиторий для этого релиза, dnf загрузит метаданные и завершит работу без сообщений об ошибках. Если нет, вы получите ошибку 404 для пути вроде https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml, и позднее та же ошибка остановит system-upgrade download. В первые недели после выхода релиза Fedora это самая распространённая причина, по которой обновление не начинается.

Есть два варианта. Подождать несколько недель, пока поставщик опубликует нужные пакеты. Обычно это правильный вариант. Либо выполнить обновление без этого репозитория:

sudo dnf system-upgrade download --releasever=44 --disable-repo=docker-ce-stable

Отключение репозитория не удаляет установленные из него пакеты. Они остаются установленными и не управляются репозиторием. Если они блокируют транзакцию, dnf сообщит об этом. Параметр --allowerasing разрешает dnf удалить установленные пакеты для устранения конфликта, поэтому перед подтверждением внимательно проверьте список удаляемых пакетов. Именно из-за этого списка можно случайно удалить сервер базы данных, который планировалось сохранить.

Что происходит с сервером Fedora, для которого пропущено окно обновления

В сам день окончания поддержки ничего не происходит. Сбой возникает при следующем обращении к менеджеру пакетов. Выпуски, для которых закончился жизненный цикл, убирают из зеркальной сети и перемещают в архив. Поэтому dnf upgrade завершается ошибкой при загрузке метаданных: URL metalink для вашего выпуска возвращает 404:

Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-42&arch=x86_64

Машина продолжает обслуживать трафик, поэтому проблему легко не заметить. Обновления безопасности больше не поступают. Установить пакеты также нельзя. Поэтому в день публикации уязвимости в OpenSSH или nginx у вас не будет поддерживаемого способа установить исправление.

Исправить ситуацию можно, но это займёт время. Вы можете перенаправить репозитории в архив Fedora по адресу https://dl.fedoraproject.org/pub/archive/fedora/linux/ и выполнить обновление оттуда. Fedora предполагает переход через один или два выпуска за раз. Поэтому сервер, отстающий на четыре выпуска, потребует несколько последовательных переходов. Каждый переход может завершиться ошибкой, а при загрузке в автономном режиме вы будете работать вслепую. На VPS обычно быстрее и безопаснее создать сервер на актуальном образе и перенести на него данные. Это та же работа, что и первые десять минут на новом VPS.

Автоматические обновления устанавливают исправления в рамках выпуска. Они не обновляют сам выпуск.

Fedora может устанавливать обновления по таймеру:

sudo dnf install -y dnf5-plugin-automatic
sudo systemctl enable --now dnf5-automatic.timer

Параметры хранятся в /etc/dnf/automatic.conf. Этот файл переопределяет значения по умолчанию из /usr/share/dnf5/dnf5-plugins/automatic.conf. apply_updates по умолчанию отключён, поэтому сразу после установки таймер скачивает обновления, но ничего не устанавливает. upgrade_type выбирает между default и security. reboot принимает значения never, when-changed или when-needed.

Это поддерживает систему в актуальном состоянии в рамках текущего выпуска. Fedora 43 никогда не будет автоматически обновлена до Fedora 44, поскольку обновление версии — отдельная запланированная операция, которая перезагружает систему для выполнения транзакции в автономном режиме. В этом заключается практическое отличие от LTS. В Ubuntu автоматические обновления безопасности поддерживают систему в актуальном состоянии в течение всего пятилетнего периода без изменения версии, а само обновление версии выполняется как запланированная операция, например обновление с 24.04 до 26.04, раз в несколько лет.

Когда Fedora подходит для сервера

Fedora подходит, когда главным преимуществом является использование самых новых компонентов.

• Вам нужно ядро или пользовательское окружение новее, чем в любом LTS-релизе: например, для нового оборудования либо для стека контейнеров и systemd, которому до корпоративного релиза ещё около года. Fedora также переходит на новые upstream-ядра в течение жизненного цикла релиза, поэтому преимущество проявляется не только один раз при установке.
• Вы проверяете компоненты, которые войдут в RHEL (Red Hat Enterprise Linux). Fedora служит основой для CentOS Stream, а CentOS Stream — для RHEL. Поэтому программное обеспечение, которое сегодня собирается и работает в Fedora, проверяется с платформой, которая через пару лет станет корпоративной.
• Сервер изначально рассчитан на короткий срок работы. Build runner или тестовый сервер, который удаляют через два месяца, не доживает до даты окончания поддержки. Та же логика применима к одноразовым виртуальным машинам, которые вы передаёте агентам для написания кода, если сервер пересоздаётся намного чаще, чем выходят новые релизы Fedora.
• За обновление отвечает конкретный человек. Fedora подходит для сервера с назначенным владельцем и запланированным обновлением в календаре. Для сервера, о котором все забыли, это плохой выбор.

Средний путь: актуальные пакеты на стабильной базе

Большинству пользователей, которым нужен Fedora на сервере, требуются два или три актуальных пакета, а не актуальная операционная система. Это разные задачи. Используйте LTS-систему или пересобранный enterprise-дистрибутив в качестве базы, а новое программное обеспечение устанавливайте только там, где оно действительно необходимо. Образ контейнера позволяет получить новую версию приложения на хосте, который не требуется обновлять ради этого приложения (запуск Docker на VPS). Репозиторий поставщика для нужного пакета, например PostgreSQL или nginx, обновит только этот компонент и не затронет базовую систему.

Компромисс есть в обоих случаях. Контейнер предоставляет новое пользовательское окружение поверх старого ядра хоста, поэтому он не решает проблему, если требуется именно новое ядро. Репозиторий поставщика предоставляет один новый пакет на базе, которую поставщик тестировал менее тщательно. В обоих случаях обновления безопасности базовой системы остаются привязанными к циклу LTS. Именно этот цикл требует ежегодного окна обслуживания при использовании Fedora.

Если вы всё же выбираете Fedora для сервера, внесите цикл обновлений в календарь. После выхода релиза подождите несколько недель, чтобы репозитории поставщиков успели обновиться, создайте snapshot, выполните обновление и проверьте, что сервисы снова запустились. Такой процесс занимает около часа в год и работает. Проблемы возникают, когда об обновлении вспоминают только после того, как уже что-то сломалось.

FAQ

Сколько времени поддерживается выпуск Fedora?

Около 13 месяцев. Fedora выпускает новую версию примерно каждые шесть месяцев и поддерживает каждую из них примерно до истечения четырех недель после выпуска версии, которая выходит через две версии. Fedora 44 была выпущена 28 April 2026 года, а окончание срока поддержки запланировано на June 2027 года. После этой даты выпуск перестает получать обновления безопасности, а его пакеты переносятся с зеркал в архив Fedora.

Можно ли пропустить выпуск Fedora и обновиться сразу на две версии?

Да, в определенных пределах. dnf system-upgrade download --releasever= принимает в качестве цели выпуск, который находится на одну или две версии впереди. Переход через две версии за раз — именно так обычно выполняют ежегодное обновление. Переход через большее число версий не поддерживается. Кроме того, с каждым пропущенным выпуском повышается вероятность, что переименование пакета или изменение формата конфигурации прервет транзакцию. Если машина уже отстает на несколько выпусков и срок ее поддержки истек, обычно быстрее заново установить систему из текущего образа, чем выполнять цепочку обновлений.

Что произойдет, если срок поддержки сервера Fedora истечет?

Сервер продолжит работать, но перестанет получать исправления. Следующая команда dnf upgrade завершится ошибкой 404 для URL metalink вашего выпуска, поскольку выпуски с истекшим сроком поддержки переносятся в архив по адресу dl.fedoraproject.org. Можно изменить файлы репозиториев так, чтобы они указывали на этот архив, а затем обновлять систему поэтапно. Другой вариант — заново установить сервер на поддерживаемый выпуск. Пока не выполнен один из этих вариантов, обновление безопасности не сможет попасть на машину, и ни один пакет не установится.

Является ли Fedora плохим выбором для production-сервера?

Это плохой вариант по умолчанию, но при наличии обоснованной причины Fedora может подойти. Основной недостаток — полное обновление операционной системы каждый год и постоянная необходимость выполнять эту операцию на машине, которую вы предпочли бы не изменять. Выбирайте Fedora, если вам нужны kernel или userspace новее тех, что входят в LTS, либо если сервер изначально рассчитан на короткий срок работы. Выбирайте LTS или enterprise rebuild, если хотите годами устанавливать обновления безопасности на сервер, не меняя его версию.