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

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

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

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

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. Показник Debian у 36 місяців означає стандартний період підтримки безпеки. Окрема команда LTS продовжує підтримку більшості випусків приблизно до п’яти років.

Це опубліковані періоди підтримки, перевірені в серпні 2026 року, а не виміряний час безвідмовної роботи. Причини відмінностей у циклах описано в матеріалі про різницю між 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 перезавантажує машину для виконання офлайн-транзакції: мінімального завантаження, під час якого 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 або serial. Переконайтеся, що у вас є консоль або snapshot, до початку операції, а не після неї.

Є ще одна перевірка, яку часто пропускають:

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

Якщо пакет постачає новий файл конфігурації за замовчуванням, а ви редагували старий файл, RPM не перезаписує його. Натомість він записує версію з пакета поруч із ним як .rpmnew. Тому ваш sshd або nginx продовжує працювати точно так само, як у старому випуску, а нові значення за замовчуванням залишаються непрочитаними на диску. Переглядайте ці файли після кожного оновлення. Встановлення rpmconf і запуск sudo rpmconf -a послідовно опрацьовує їх та показує відмінності.

Сторонні репозиторії блокують оновлення

Усі пакети 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, який пропустив період підтримки

У сам день завершення підтримки нічого не відбувається, і пізніше система також не виходить з ладу помітним чином. Сервіс дзеркал Fedora продовжує відповідати для версій, життєвий цикл яких завершено. URL metalink для вашої версії й далі повертає чинний список дзеркал, а ці дзеркала тепер надають вашу версію з архівного дерева Fedora, зокрема dl.fedoraproject.org. Тому dnf upgrade і далі завантажує метадані, не знаходить нічого нового й завершує роботу так, ніби сервер актуальний. Сервіс metalink повертає 404 лише для версії, яку Fedora ніколи не випускала. Станом на 10 жовтня 2026 року це стосується Fedora 42, життєвий цикл якої завершився у травні 2026 року, а також версій аж до Fedora 20. Перевірити, звідки надається ваша версія, можна так:

curl -s 'https://mirrors.fedoraproject.org/metalink?repo=fedora-42&arch=x86_64' | grep -m 3 archive

Сервер продовжує обслуговувати мережевий трафік, що й робить цю ситуацію непомітною та небезпечною. Він не отримує оновлень безпеки, оскільки для цієї версії більше ніколи не публікуватимуть нових пакетів. dnf і далі читає незмінний архів, тому ніщо на сервері не виглядає зламаним. Але коли з’являється рекомендація щодо OpenSSH або nginx, виправленого пакета для вашої версії вже немає, і підтримуваного способу встановити виправлення не існує.

Вийти з цієї ситуації можливо, але це повільний процес. Оскільки метадані вашої версії й далі спрямовуються до архіву Fedora за адресою https://dl.fedoraproject.org/pub/archive/fedora/linux/, оновлення можна виконати безпосередньо з поточного стану. Вручну змінювати файли репозиторіїв і вказувати цей архів потрібно лише тоді, коли metalink перестає працювати. 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 і distro-sync. reboot приймає значення never, when-changed або when-needed.

Це підтримує актуальний стан системи в межах однієї версії. Fedora 43 ніколи не буде автоматично оновлено до Fedora 44, оскільки оновлення версії є окремою запланованою операцією, яка перезавантажує систему для виконання офлайн-транзакції. У цьому полягає практична відмінність від LTS. В Ubuntu автоматичні оновлення безпеки підтримують машину в актуальному стані протягом усього п’ятирічного періоду без зміни версії. А саме оновлення версії виконується як запланована операція, подібна до оновлення з 24.04 до 26.04, раз на кілька років.

Коли Fedora є правильним вибором для сервера

Fedora добре підходить, коли новизна є головною вимогою.

• Вам потрібні kernel або userspace новіші, ніж у будь-якому LTS-релізі: для нового обладнання або стека контейнерів і systemd, до enterprise-релізу якого ще близько року. Fedora також переходить на нові upstream kernel протягом життєвого циклу релізу, тому це не лише одноразова перевага під час встановлення.
• Ви перевіряєте компоненти, які мають увійти до RHEL (Red Hat Enterprise Linux). Fedora формує основу для CentOS Stream, а CentOS Stream — для RHEL. Тому програмне забезпечення, яке сьогодні збирається та працює у Fedora, тестується на платформі, що стане enterprise-платформою через кілька років.
• Машина за задумом має короткий життєвий цикл. Build runner або тестовий сервер, який знищують через два місяці, не доживе до дати завершення підтримки. Та сама логіка стосується одноразових VM, які ви надаєте coding agents, якщо сервер перебудовують набагато частіше, ніж виходять релізи Fedora.
• За оновлення відповідає конкретна людина. Fedora підходить для сервера, за який призначено відповідального і для оновлення якого є запис у календарі. Вона погано підходить для сервера, про який усі забули.

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

Більшість тих, хто хоче Fedora на сервері, потребує двох або трьох актуальних пакетів, а не актуальної операційної системи. Це різні речі. Використовуйте LTS або enterprise rebuild як базову систему, а нове програмне забезпечення встановлюйте лише там, де воно справді потрібне. Образ контейнера надає нову версію застосунку на хості, який не потрібно оновлювати заради цього (запуск Docker на VPS). Репозиторій постачальника для потрібного вам окремого пакета, наприклад PostgreSQL або nginx, оновлює лише цей компонент і не змінює базову систему.

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

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

FAQ

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

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

Чи можна пропустити версію Fedora й одразу оновитися на дві версії вперед?

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

Що станеться, якщо сервер Fedora досягне завершення життєвого циклу?

Він продовжить працювати, але перестане отримувати виправлення. Наступний запуск dnf upgrade також завершиться без помилки, оскільки сервіс дзеркал Fedora продовжує спрямовувати вашу версію до її архівної копії, зокрема dl.fedoraproject.org. Але він не знаходить нічого нового, тому система вас про це не попереджає. Після цього можна оновлювати систему послідовними переходами або створити сервер заново на основі версії, яка підтримується. Поки не буде виконано один із цих варіантів, для машини більше ніколи не опублікують оновлення безпеки.

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

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