Обновление Fedora Server: жизненный цикл и риски

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

Серверу Fedora требуется обновление версии примерно раз в год на протяжении всего срока службы машины. 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, а корпоративные пересборки, такие как AlmaLinux, дают 120. Рассматривайте второй столбец как объем работ. За десять лет Fedora потребует примерно 10 обновлений всей операционной системы, в то время как для Ubuntu LTS это число составит 2. Показатель Debian в 36 месяцев относится к стандартной поддержке безопасности, при этом отдельная команда LTS продлевает срок жизни большинства релизов примерно до пяти лет.

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

Из чего на самом деле состоит обновление версии Fedora

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

sudo dnf upgrade --refresh
sudo reboot

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

sudo dnf system-upgrade download --releasever=44

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

Затем выполните:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status подтверждает, что транзакция подготовлена и ожидает выполнения. dnf system-upgrade reboot перезагружает машину в режим офлайн-транзакции: это минималистичная загрузка, при которой 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 выводит лог транзакции из офлайн-режима — это единственный способ узнать, что происходило в системе, пока у вас не было доступа к оболочке. distro-sync обновляет оставшиеся пакеты до версий, соответствующих новому релизу. repoquery --extras выводит список установленных пакетов, которые больше не числятся ни в одном из включенных репозиториев; именно здесь обнаруживаются «хвосты» от репозиториев, которые не были обновлены для нового релиза.

Создайте снапшот диска перед этапом загрузки. Транзакция выполняется без вашего контроля, поэтому в случае сбоя во время офлайн-загрузки SSH не поднимется, и единственным способом доступа останется консоль, предоставляемая провайдером (VNC или serial). Убедитесь в наличии доступа к консоли или снапшота до начала процесса, а не после.

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

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

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

Сторонние репозитории — причина сбоев при обновлении

Все пакеты Fedora обновляются одновременно в день релиза. Стороннее ПО обновляется по собственному графику. Большинство репозиториев поставщиков используют $releasever в URL, поэтому сразу после обновления 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 завершается ошибкой при получении метаданных, выдавая 404 для URL metalink вашего релиза:

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 — удачный выбор, если приоритетом является использование новейшего программного обеспечения.

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

Золотая середина: актуальные пакеты на стабильной основе

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

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

Если вы все же выбрали Fedora для сервера, внесите цикл обновлений в календарь. Когда выходит новый релиз, подождите несколько недель, пока репозитории поставщиков обновятся, сделайте снимок системы, выполните обновление, а затем убедитесь, что сервисы возобновили работу. Этот ритм требует около часа в год и работает эффективно. Версия, которая выходит из строя — это та, об обновлении которой вспоминают только тогда, когда что-то уже сломалось.

FAQ

Как долго поддерживается релиз Fedora?

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

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

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

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

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

Является ли Fedora плохим выбором для промышленного сервера?

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