著者 Fedora Serverの運用：年1回のアップグレードが必要な理由
Fedoraの各リリースはサポート期間が約13ヶ月と短く、サーバー運用には年1回のOSアップグレードが必須です。LTSを採用するOSと比較した運用コストや、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 の各リリースのサポート期間は 13 ヶ月です。Ubuntu LTS は 60、AlmaLinux のようなエンタープライズ向けリビルド版は 120 となっています。2 列目の数値は、運用コストの目安として捉えてください。10 年間で換算すると、Fedora では OS 全体のアップグレードが約 10 回必要ですが、Ubuntu LTS では 2 回で済みます。Debian の 36 ヶ月という数値は通常のセキュリティサポート期間であり、別途 LTS チームによってほとんどのリリースが約 5 年間まで延長されます。
これらは 2026 年 8 月時点で確認された公開サポート期間であり、稼働時間を測定したものではありません。なぜリリース間隔が異なるのかについては、Ubuntu LTS とサーバー向け中間リリースの違いを参照してください。ここで重要なのは、それぞれの選択肢が管理者にどの程度の作業負荷をもたらすかという点です。
Fedora のバージョンアップグレードの実際
Fedora 41 以降、DNF 5 が標準のパッケージマネージャーとなり、dnf がこれを実行します。system-upgrade コマンドは dnf5 自体に含まれているため、事前にプラグインをインストールする必要はありません。Debian や Ubuntu から移行した場合、日常的な操作のほとんどには apt と dnf の直接的な対応関係 がありますが、以下のバージョンアップグレードは対応する操作が存在しない数少ない作業の一つです。まずは現在のリリースを最新の状態に更新します。
sudo dnf upgrade --refresh
sudo reboot再起動は重要です。アップグレードはインストール済みかつ実行中の環境に基づいて解決されるため、カーネルや glibc の更新が中途半端な状態だと、次のステップでのトラブルシューティングが困難になるからです。次に、新しいリリースをステージングします。44 の部分は移行先のリリース番号に置き換えてください。
sudo dnf system-upgrade download --releasever=44このコマンドはトランザクション全体を解決して全パッケージをダウンロードしますが、実行中のシステムには何も変更を加えません。小規模なサーバーであれば、数千個のパッケージで 1 GB から 3 GB 程度の容量を消費します。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 やシリアルコンソールが唯一のアクセス手段となります。開始前に、コンソールへのアクセス手段またはスナップショットがあることを必ず確認してください。
多くの人が見落とすもう一つの確認事項です。
sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'パッケージが新しいデフォルト設定ファイルを提供し、既存のファイルを編集済みである場合、RPM は既存のファイルを上書きしません。代わりにパッケージ版を .rpmnew として隣に保存します。そのため、sshd や nginx は古いリリースのまま動作し、新しいデフォルト設定はディスク上で読み込まれないままになります。アップグレード後は必ずこれらのファイルを確認してください。rpmconf をインストールし sudo rpmconf -a を実行すると、ファイルを一つずつ確認しながら差分を表示できます。
サードパーティ製リポジトリがアップグレードを阻害する原因
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 つあります。ベンダーが公開するまで数週間待つのが通常は適切な判断です。あるいは、そのリポジトリを除外してアップグレードします。
sudo dnf system-upgrade download --releasever=44 --disable-repo=docker-ce-stableリポジトリを無効にしても、そのパッケージは削除されません。インストールされたまま管理外となり、もしトランザクションを阻害する場合は dnf がその旨を通知します。--allowerasing を追加すると、dnf は競合を解決するためにインストール済みパッケージを削除できるようになります。そのため、承諾する前に削除リストを必ず確認してください。そのリストには、保持するつもりだったデータベースサーバーが含まれている可能性があります。
Fedora サーバーがサポート期間を過ぎた場合
当日中に何かが起こるわけではありません。問題が表面化するのは、次にパッケージマネージャーを操作した時です。サポート終了（EOL）となったリリースはミラーネットワークからアーカイブへ移動されるため、dnf upgrade はメタデータの取得に失敗し、リリースの metalink URL で 404 エラーが発生します。
Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-42&arch=x86_64サーバーはトラフィックを処理し続けますが、これがこの問題を静かで危険なものにしています。セキュリティアップデートは一切提供されません。また、パッケージのインストールも不可能なため、OpenSSH や nginx の脆弱性情報が公開されたとしても、サポートされた方法でパッチを適用することはできません。
脱出は可能ですが、時間がかかります。リポジトリの参照先を https://dl.fedoraproject.org/pub/archive/fedora/linux/ の Fedora アーカイブへ変更し、そこからアップグレードを行うことができます。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 年間のサポート期間全体を通じてマシンを運用でき、バージョン変更自体は 24.04 から 26.04 へのアップグレードのように数年に一度計画的に行われる作業となります。
Fedora がサーバーとして適している場合
Fedora は、最新であることが重要である場合に適した選択肢です。
- LTS が提供するものよりも新しいカーネルやユーザー空間が必要な場合：最新のハードウェアを使用している、あるいはエンタープライズ版のリリースまでまだ1年かかるようなコンテナや systemd スタックが必要な場合です。Fedora はリリース期間中も新しいアップストリームカーネルへ移行するため、インストール時の一時的なメリットにとどまりません。
- RHEL (Red Hat Enterprise Linux) に導入される予定の機能を検証する場合：Fedora は CentOS Stream に供給され、それが RHEL に供給されます。そのため、現在 Fedora でビルドおよび実行できるソフトウェアは、数年後のエンタープライズプラットフォームに向けたテストを受けていることになります。
- マシンが設計上短命である場合：2か月で破棄されるビルドランナーやテスト用ボックスは、サポート終了日を迎えることがありません。同じ論理が コーディングエージェントに渡す使い捨て VM にも当てはまります。この場合、Fedora のリリースサイクルよりもはるかに頻繁にボックスが再構築されます。
- アップグレードを管理する担当者がいる場合：Fedora は、管理者が明確で、スケジュールが管理されているサーバーであれば問題ありません。誰も存在を忘れてしまったようなサーバーには不向きです。
中道：安定したベース上の最新パッケージ
サーバーで Fedora を利用したいと考える人の多くは、OS 全体が最新であることを求めているのではなく、特定のパッケージを 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 のリリースを飛ばして、一度に 2 つ先のバージョンへアップグレードできますか？
はい、制限の範囲内であれば可能です。dnf system-upgrade download --releasever= は 1 つまたは 2 つ先のリリースをターゲットとして受け入れます。2 つずつ飛ばすアップグレードは、年に 1 回のアップグレードサイクルとして一般的に行われています。それ以上飛ばすことはサポートされておらず、リリースをまたぐほどパッケージ名の変更や設定フォーマットの変更により処理が失敗する可能性が高まります。すでに数世代前のリリースでサポートも終了している場合は、アップグレードを繰り返すよりも、現在のイメージで再構築する方が通常は高速です。
Fedora サーバーのサポートが終了するとどうなりますか？
サーバーは稼働し続けますが、パッチは提供されなくなります。サポート終了後のリリースは dl.fedoraproject.org のアーカイブへ移動されるため、次の dnf upgrade はメタリンク URL で 404 エラーとなり失敗します。リポジトリファイルをそのアーカイブへ向けて段階的にアップグレードするか、サポートされているリリースでサーバーを再構築する必要があります。どちらかの対応を行うまで、セキュリティ更新は適用されず、パッケージのインストールもできません。
Fedora は本番環境のサーバーとして不適切ですか？
デフォルトの選択肢としては不適切ですが、明確な理由がある場合には妥当な選択肢となります。運用コストとして、触れたくないサーバーであっても毎年 OS 全体のアップグレードが必要になります。LTS が提供するよりも新しいカーネルやユーザー空間が必要な場合や、設計上サーバーの寿命が短い場合には Fedora を選択してください。バージョンを変更せずに数年間パッチを適用し続けたい場合は、LTS またはエンタープライズ向けの再構築版を選択してください。