Fedora на VPS: оновлення версії кожні 13 місяців

Скільки часу випуск Fedora отримує оновлення безпеки?

Для сервера Fedora приблизно раз на рік потрібно оновлювати версію протягом усього строку експлуатації машини. Fedora випускає нову версію приблизно кожні шість місяців. Кожен випуск підтримується приблизно до чотирьох тижнів після виходу версії, що на дві позиції новіша. У результаті випуск отримує оновлення протягом приблизно 13 місяців. Після цієї дати випуск більше не отримує жодних виправлень безпеки. Сервер продовжує працювати, але його набір пакетів більше ніхто не оновлює.

Дати дають змогу побачити це на конкретному прикладі. Станом на August 2026 підтримуються Fedora 43 і Fedora 44. Fedora 44 випущено 28 April 2026, а завершення її життєвого циклу заплановано на June 2027. Fedora 42 випущено в April 2025, а її життєвий цикл завершився в May 2026, через чотири тижні після виходу Fedora 44. Тому сервер, створений з образу Fedora 42, втратив підтримку через тринадцять місяців, хоча ніхто не припустився помилки.

Fedora проти LTS: у місяцях

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

[
  {
    "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, а не вимірювання доступності. Причини відмінностей у циклах описано в розділі про різницю між Ubuntu LTS та проміжними релізами на сервері. Тут важливо те, який обсяг робіт створює кожен варіант для вас.

Що насправді передбачає оновлення версії Fedora

DNF 5 є стандартним менеджером пакетів, починаючи з Fedora 41, і dnf запускає його. Команда system-upgrade входить до складу самого dnf5, тому спочатку не потрібно встановлювати плагін. Почніть із поточного випуску, повністю оновленого:

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 перезавантажує машину в автономну транзакцію: мінімальне завантаження, під час якого 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 виводить журнал транзакції з цього автономного завантаження. Це єдиний запис про події, що відбувалися, поки у вас не було shell. distro-sync переносить усе, що залишилося, на версії нового випуску. repoquery --extras показує встановлені пакети, яких більше немає в жодному ввімкненому репозиторії. Саме тут можна знайти залишки репозиторію, який не публікував пакети для нового випуску.

Створіть snapshot диска перед етапом завантаження. Транзакція виконується, коли ви не можете бачити екран. Якщо під час автономного завантаження станеться помилка, SSH не відновить підключення, і єдиним способом доступу буде консоль, яку надає провайдер, VNC або послідовна консоль. Переконайтеся, що у вас є доступ до консолі або 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 не може отримати метадані та повертає помилку 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, якому ще приблизно рік до появи в enterprise-релізі. Fedora також переходить на нові upstream-ядра протягом життєвого циклу релізу, тому перевага не обмежується моментом встановлення.
• Ви перевіряєте компоненти, які мають потрапити до RHEL (Red Hat Enterprise Linux). Fedora є основою для CentOS Stream, а CentOS Stream — для RHEL. Тому програмне забезпечення, яке сьогодні збирається та працює у Fedora, тестується на платформі, що стане enterprise-платформою через кілька років.
• Машина за задумом має короткий життєвий цикл. Build runner або тестова машина, яку знищать через два місяці, не дочекається завершення строку підтримки. Та сама логіка стосується одноразових VM, які ви передаєте coding agents, якщо машину перебудовують значно частіше, ніж виходять релізи Fedora.
• За оновлення відповідає конкретна людина. Fedora підходить для сервера, за який призначено відповідального та заплановано оновлення в календарі. Для машини, про яку всі забули, це невдалий вибір.

Середній шлях: актуальні пакети на стабільній базі

Більшість користувачів, яким потрібна Fedora на сервері, хочуть отримати два або три актуальні пакети, а не актуальну операційну систему. Це різні речі. Візьміть за основу LTS або корпоративний rebuild, а нове програмне забезпечення встановлюйте лише там, де воно справді потрібне. Образ контейнера надає нову версію застосунку на хості, який не потрібно оновлювати заради цього застосунку (запуск 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. Ви можете змінити repository files так, щоб вони вказували на цей архів, і виконати оновлення поетапно, або перевстановити сервер на підтримуваний випуск. Поки ви не виконаєте один із цих варіантів, на машину не надходитимуть оновлення безпеки, і жоден пакет не встановиться.

Чи є Fedora невдалим вибором для production-сервера?

Це невдалий вибір за замовчуванням, але обґрунтований вибір у відповідних випадках. Недолік полягає в необхідності щороку повністю оновлювати операційну систему на машині, яку ви, можливо, волієте не змінювати. Обирайте Fedora, якщо вам потрібні новіші kernel або userspace, ніж доступні у випуску LTS, або якщо сервер від початку розрахований на короткий строк роботи. Обирайте LTS або enterprise rebuild, якщо хочете роками встановлювати оновлення на сервері без зміни його версії.