著者 Fedoraサーバーの13か月問題とアップグレード費用
Fedoraは約13か月でセキュリティ更新が終了します。VPSで毎年必要になるバージョンアップの負担と、Fedoraを選ぶ価値を具体的に解説します。
Fedora リリースにセキュリティ更新が提供される期間
Fedora サーバーでは、マシンを使用する限り、約 1 年に 1 回のバージョンアップが必要です。Fedora はおよそ 6 か月ごとに新しいリリースを公開します。各リリースのサポートは、2 つ後のリリースが公開されてから約 4 週間後まで続きます。これは、更新が提供される期間にして約 13 か月です。その日を過ぎると、そのリリースにはセキュリティ修正が一切提供されません。サーバーは動き続けますが、パッケージは誰からも修正されなくなります。
日付を確認すると、状況が具体的になります。2026 年 8 月時点でサポート対象なのは Fedora 43 と Fedora 44 です。Fedora 44 は 2026 年 4 月 28 日に公開され、サポート終了は 2027 年 6 月に予定されています。Fedora 42 は 2025 年 4 月に公開され、Fedora 44 の公開から 4 週間後の 2026 年 5 月にサポート終了となりました。したがって、Fedora 42 のイメージから構築したサーバーは、誰かが誤った操作をしなくても、13 か月後にはサポート対象外になっていました。
Fedora と LTS の比較（単位：月）
LTS は Long Term Support（長期サポート）を意味します。ベンダーが数か月ではなく数年間、リリースへのパッチ提供を続ける仕組みです。EOL は End of Life（サポート終了）を意味し、パッチ提供が停止する日を指します。ここでは、現在インストールするリリースについて各プロジェクトが公開している内容を示します。
The data behind this chart
[
{
"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 の 1 リリースあたりのサポート期間は 13 か月です。Ubuntu LTS は 60、AlmaLinux などのエンタープライズ向け再構築版は 120 です。2 列目は、必要になる更新作業の負担として読んでください。10 年間では、Fedora の場合、オペレーティングシステム全体のアップグレードが概ね 10 回必要です。Ubuntu LTS では 2 回です。Debian の 36 か月という数字は、通常のセキュリティサポート期間です。別の LTS チームが、ほとんどのリリースを約 5 年間まで延長します。
これらは 2026 年 8 月に確認した、公開されているサポート期間です。実測した稼働時間ではありません。更新サイクルが異なる理由については、サーバーにおける Ubuntu LTS と中間リリースの違いで説明します。ここで重要なのは、それぞれの選択によって必要になる作業です。
Fedora のバージョンアップグレードで実際に行われること
Fedora 41 以降、デフォルトのパッケージマネージャーは DNF 5 で、dnf がこれを実行します。system-upgrade コマンドは dnf5 自体に含まれているため、先にプラグインをインストールする必要はありません。現在のリリースを完全に更新した状態から開始します。
sudo dnf upgrade --refresh
sudo reboot再起動が重要なのは、アップグレードがインストール済みで実行中の状態を基準に解決されるためです。カーネルや glibc の更新が途中までしか適用されていないと、次の手順の判断が難しくなります。次に、新しいリリースを準備します。移行先のリリースに合わせて 44 を置き換えてください。
sudo dnf system-upgrade download --releasever=44この処理はトランザクション全体を解決し、すべてのパッケージをダウンロードします。実行中のシステムは変更しません。小規模なサーバーでは、数千個のパッケージと 1 から 3 ギガバイト程度を見込んでください。dnf がトランザクションを解決できない場合、ここで停止し、処理を妨げているパッケージを表示します。これは良い状態です。マシンがまだ稼働しており、シェルも利用できる間に失敗するためです。
続いて実行します。
sudo dnf offline status
sudo dnf system-upgrade rebootdnf offline status は、トランザクションが準備され、実行待ちであることを確認します。dnf system-upgrade reboot はマシンを再起動し、オフラインのトランザクションを実行します。これは、RPM トランザクションだけが動作する最小構成のブートです。実行中のサービスの下で glibc と systemd を置き換えると、インストール途中のシステムになるため、この方式が使われます。トランザクション全体の間、サーバーには接続できません。小規模な VPS では通常数分かかり、その後、新しいリリースで再び再起動します。再起動が 2 回発生し、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、またはシリアル接続だけになります。開始前に、コンソールまたはスナップショットを利用できることを確認してください。開始後では間に合いません。
もう 1 つ、見落とされがちな確認があります。
sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'パッケージに新しいデフォルト設定ファイルが含まれていて、古い設定ファイルを編集している場合、RPM は既存のファイルを上書きしません。パッケージ版を .rpmnew として、既存のファイルと同じ場所に保存します。そのため、sshd や nginx は古いリリースとまったく同じ動作を続け、新しいデフォルト設定はディスク上で未確認のまま残ります。アップグレードのたびに、これらのファイルを確認してください。rpmconf をインストールして sudo rpmconf -a を実行すると、ファイルを 1 つずつ確認し、差分を表示できます。
サードパーティーリポジトリがアップグレードを妨げます
Fedora 自身のパッケージは、リリース日にまとめて更新されます。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 はメタデータをダウンロードして何も表示せず終了します。未公開であれば、https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml のようなパスに対する 404 が返り、後で同じ失敗によって system-upgrade download も停止します。Fedora のリリース後数週間は、アップグレードが開始できない原因としてこれが最も一般的です。
対処方法は 2 つあります。通常は、ベンダーが公開するまで数週間待つのが適切です。もう 1 つは、そのリポジトリを無効にしてアップグレードする方法です。
sudo dnf system-upgrade download --releasever=44 --disable-repo=docker-ce-stableリポジトリを無効にしても、そのリポジトリのパッケージは削除されません。パッケージはインストール済みのまま、管理対象外になります。パッケージがトランザクションを妨げている場合、dnf はそのことを通知します。--allowerasing を追加すると、競合を解決するために dnf がインストール済みパッケージを削除できるようになります。そのため、承認する前に削除一覧を確認してください。残すつもりだったデータベースサーバーを失うのは、その一覧を確認しなかった場合です。
サポート期間を過ぎた Fedora サーバーで起きること
その当日に何かが起きるわけではありません。問題が発生するのは、次にパッケージマネージャーを操作したときです。サポートが終了したリリースはミラーネットワークからアーカイブへ移されます。そのため、dnf upgrade はメタデータの取得時に失敗し、リリース用の metalink URL で 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 では、通常 1 つまたは 2 つのリリースを順に移行します。そのため、4 リリース遅れたサーバーでは、複数回の移行を連続して実行する必要があります。各移行には失敗する可能性があり、オフラインブート中に手探りで作業することになります。VPS では、現行イメージで再構築してデータを移行する方が、通常は短時間で安全です。これは 新しい VPS で最初の 10 分間に行う作業と同じです。
自動更新はリリース内のパッチを適用します。リリース自体をアップグレードすることはありません。
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 では、自動セキュリティ更新 によって、バージョンを変更せずに 5 年間のサポート期間全体を通してマシンを最新の状態に保てます。バージョン変更自体は、数年に 1 回実施する 24.04 から 26.04 へのアップグレード のような計画作業です。
Fedora がサーバーに適している場合
新しさが重要な場合は、Fedora が適しています。
- LTS が提供するものより新しい kernel または userspace が必要な場合です。対象には、新しい hardware や、enterprise release までまだ 1 年かかる container と systemd の stack があります。Fedora は release 中にも新しい upstream kernel へ移行するため、これはインストール時だけの利点ではありません。
- RHEL (Red Hat Enterprise Linux) に取り込まれる機能を検証する場合です。Fedora は CentOS Stream に反映され、CentOS Stream は RHEL に反映されます。そのため、現在 Fedora で build および実行できる software は、数年後の enterprise platform に向けてテストされています。
- マシンを意図的に短期間だけ使用する場合です。2 か月で破棄する build runner や test box が、end of life を迎えることはありません。同じ考え方は、coding agent に渡す使い捨ての VM にも当てはまります。このような box は Fedora の release よりはるかに頻繁に再構築されるためです。
- upgrade の担当者が決まっている場合です。担当者と予定が明確なサーバーであれば、Fedora は問題ありません。誰も管理していないサーバーには適していません。
安定したベースに最新パッケージを組み合わせる中間案
サーバーで Fedora を使いたい人の多くが必要としているのは、最新のオペレーティングシステムではなく、最新のパッケージが 2 つか 3 つある環境です。これらは分けて扱えます。ベースには LTS またはエンタープライズ系の再構築版を使い、必要なソフトウェアだけを新しいものに置き換えます。コンテナーイメージを使えば、ホストをアップグレードせずに、必要なアプリケーションの新しいバージョンを実行できます（VPS 上で Docker を実行する）。PostgreSQL や nginx など、必要な単一パッケージ用のベンダーリポジトリを使えば、そのパッケージだけを更新し、ベースはそのまま維持できます。
この方法には、双方に明確なトレードオフがあります。コンテナーでは、ホストの古いカーネル上で新しいユーザー空間を実行します。そのため、必要なのがカーネルの更新である場合には役立ちません。ベンダーリポジトリでは、ベースシステム上の 1 つのパッケージだけを新しくしますが、ベンダーによるテストの範囲は狭くなります。どちらの方法でも、ベースシステムのセキュリティ更新は LTS の更新周期に従います。Fedora では、この周期によって毎年メンテナンス時間を確保する必要が生じます。
サーバーに Fedora を選ぶ場合は、更新周期を予定表に登録してください。リリースが公開されたら、ベンダーリポジトリが追随するまで数週間待ち、スナップショットを作成してからアップグレードし、サービスが復旧したことを確認します。この手順に必要な時間は、年間で約 1 時間です。問題なく機能します。失敗するのは、すでに何かが壊れたときにだけ、アップグレードの必要性を思い出す場合です。
FAQ
Fedora のリリースはどのくらいの期間サポートされますか？
約 13 か月です。Fedora はおよそ 6 か月ごとにリリースされ、各リリースは 2 つ後のバージョンがリリースされてから約 4 週間後までサポートされます。Fedora 44 は 2026 年 4 月 28 日にリリースされ、サポート終了は 2027 年 6 月に予定されています。この日を過ぎると、そのリリースにはセキュリティ更新が提供されなくなり、パッケージはミラーから Fedora のアーカイブへ移されます。
Fedora のリリースを 1 つ飛ばして、2 バージョンまとめてアップグレードできますか？
はい。ただし制限があります。dnf system-upgrade download --releasever= では 1 つまたは 2 つ先のリリースを移行先として指定できます。2 つまとめて移行する方法は、年 1 回のアップグレード運用にそのまま適しています。さらに先のリリースへの移行はサポートされていません。リリースを 1 つ飛ばすごとに、パッケージ名の変更や設定形式の変更によってトランザクションが停止する可能性が高まります。すでに複数のリリース遅れていて、サポート終了後の状態であれば、アップグレードを連続して行うより、現行イメージで再構築するほうが通常は速く済みます。
Fedora サーバーがサポート終了を迎えるとどうなりますか？
サーバーは動作し続けますが、パッチは提供されなくなります。次回の dnf upgrade は、使用中のリリースの metalink URL に対する 404 で失敗します。サポート終了後のリリースは dl.fedoraproject.org のアーカイブへ移されるためです。リポジトリファイルの参照先をそのアーカイブに変更して段階的にアップグレードするか、サポート対象のリリースでサーバーを再構築できます。どちらかを実施するまで、セキュリティ更新はマシンに届かず、パッケージもインストールできません。
Fedora は本番サーバーには不適切ですか？
デフォルトの選択としては不適切ですが、理由がある場合は妥当な選択です。サーバーのバージョンを変えずに運用したい場合でも、毎年、継続的にオペレーティングシステム全体をアップグレードする必要があります。LTS が提供するものより新しいカーネルやユーザー空間が必要な場合、またはサーバーを設計上短期間だけ使用する場合は Fedora を選んでください。バージョンを変えずに何年もサーバーへパッチを適用したい場合は、LTS またはエンタープライズ系の再構築版を選んでください。