著者 Rocky・AlmaLinuxでEPELとCRBを有効化する方法
Rocky LinuxやAlmaLinuxでdnfがパッケージを見つけられない原因を解説します。BaseOS、AppStream、CRBの違い、EPELの安全な追加方法、リポジトリを整理して保つ手順がわかります。
欲しいパッケージが dnf で見つからない理由
EPEL と CRB は、新規の Rocky Linux または AlmaLinux サーバーで最初から利用できない 2 つのリポジトリです。そのため、新しいサーバーで dnf install htop を実行すると No match for argument: htop が返され、その後 Error: Unable to find a match: htop になります。故障しているわけでも、ミラーが停止しているわけでもありません。ベースディストリビューションが意図的に提供するパッケージを少数に絞っており、CRB は存在するものの無効になっています。また、EPEL は別途追加が必要なコミュニティリポジトリです。
Ubuntu では、同じパッケージが universe に含まれており、universe はほぼすべてのクラウドイメージで有効になっています。そのため、この問題はほとんど発生しません。Red Hat 系ではパッケージの分割方法が異なり、初期状態で提供される範囲も狭くなっています。対処には 3 つのコマンドを実行します。このガイドの残りでは、最初の 1 週間では誰も教えてくれない点を説明します。各リポジトリが保証すること、保証しないこと、そしてサードパーティーリポジトリによってベースシステムが気付かないうちに置き換えられるのを防ぐ方法です。
これらのコマンドの確認方法。コマンドのテスト用コンテナは Ubuntu のみで実行しているため、以下の dnf コマンドはテスト環境で実行していません。Rocky Linux と AlmaLinux のドキュメントに従っています。各手順には表示されるはずの出力を記載しているため、ブロック全体を一度に貼り付けず、各コマンドを自分のサーバーで確認してください。
BaseOS、AppStream、CRB とは
BaseOS はオペレーティングシステムそのものです。カーネル、glibc、systemd、基本的なユーザーランドが含まれます。ここで提供されるバージョンはメジャーリリースのサポート期間中固定され、セキュリティ修正はその固定バージョンにバックポートされます。BaseOS で数年前に見えるバージョン番号が付いていても、未修正のパッケージではありません。修正済みの古いバージョンです。これがエンタープライズディストリビューションの基本的な考え方です。
AppStream には、その上で実行する Web サーバー、データベース、言語ランタイム、エディター、監視エージェントなどが含まれます。version 8 では、AppStream の多くが代替ストリームを持つモジュールとして提供されていたため、dnf module list が重要でした。たとえば、使用する PHP ストリームを選択する必要がありました。version 9 ではモジュール方式のほとんどが廃止されたため、Rocky 9 と Alma 9 では通常、各ソフトウェアについて 1 つのバージョンが提供され、最初に有効化するモジュールはありません。
Extras はデフォルトで有効になっており、規模も非常に小さいリポジトリです。主に他のリポジトリ用のリリースパッケージを格納しており、epel-release 自体もここから提供されます。このため、Rocky や Alma に EPEL をインストールする際、無関係な URL を信頼する必要はありません。
CRB は CodeReady Builder リポジトリです。version 8 では PowerTools と呼ばれていました。ディストリビューションのビルド側にあたる開発用ヘッダー、静的ライブラリ、パッケージのビルド時に必要なテストおよびドキュメント用ツールが含まれます。CRB はミラー上にすでに存在しますが、デフォルトでは無効です。Red Hat 自身の製品では、同じ内容を CodeReady Linux Builder と呼びます。サブスクリプションに含まれますが、Red Hat はサポート対象外であると明記しています。Rocky と Alma は、含まれる内容と無効化されたデフォルト設定の両方を引き継いでいます。
Debian または Ubuntu から移行してきた場合は、main が実行時パッケージと -dev ヘッダーを同じアーカイブに格納している点に注意してください。そのため、CRB に相当するリポジトリを有効化する必要はありません。EPEL に最も近いものは universe です。これはコミュニティーによって保守されており、ベンダーによるサポートは保証されません。
EPEL とは何か、どの組織が支えているか
EPEL は Extra Packages for Enterprise Linux の略です。Fedora のプロジェクトであり、Fedora に存在するパッケージを現在のエンタープライズリリース向けに再ビルドし、主に Fedora コミュニティのボランティアで構成される EPEL Special Interest Group が保守しています。Red Hat はビルドおよびミラーのインフラストラクチャをホストし、一部の Red Hat エンジニアもパッケージを保守しています。関係はそこまでです。EPEL は Red Hat の製品ではありません。 RHEL 上でも再構築版上でも、EPEL パッケージを対象とするサポート契約や SLA (service level agreement) はありません。
EPEL を安全に有効化できる根拠となるポリシーが 1 つあります。EPEL パッケージは、ベースディストリビューションのパッケージを置き換えてはなりません。AppStream に nginx が含まれている場合、EPEL には含まれません。このルールは EPEL パッケージをレビューする担当者によって適用されるため、EPEL にだけ適用される約束です。後から追加するものについては、何も保護しません。
ベースディストリビューションとは、ライフタイムに関する約束も異なります。3 年目に問題になりやすいのがこの点です。BaseOS のパッケージバージョンは、メジャーリリースの 10 年間のライフサイクル全体で固定されます。一方、EPEL のメンテナーが約束する期間ははるかに短く、少なくとも 1 つの RHEL マイナーリリースまたは 13 か月のうち、短い方です。実際には、これよりはるかに長く保守されるパッケージが大半です。メンテナーが担当を離れたために廃止されるものもあれば、ディストリビューションのライフサイクル途中で新しいメジャーバージョンへ移行するものもあります。これは EPEL が Fedora に追随するためです。そのため、通常の dnf upgrade によって、安定していると思っていたマシン上の EPEL ツールが新しいメジャーバージョンになることがあります。また、依存しているパッケージが、利用者に届く告知なしに更新を受け取らなくなることもあります。新しいバージョンは、すでに実行中のサービスには反映されません。そのため、トランザクション完了後も古いバイナリを使用しているプロセスを確認するには、needs-restarting を使用します。
有効化する前に知っておくべき影響が、もう 1 つあります。EPEL は、最新の RHEL マイナーリリースを基準にビルドされます。固定したミラーやベンダーのポイントリリースリポジトリを使用してサーバーを古いマイナーリリースに留めている場合、EPEL パッケージが、現在使用しているものより新しいベースライブラリを要求することがあります。dnf はこれを依存関係の不足として報告するため、実際にはバージョンの不整合であるにもかかわらず、ミラーの問題のように見えます。
Rocky または Alma で CRB を有効にして EPEL をインストールする
sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --set-enabled crb
sudo dnf install -y epel-release
sudo dnf makecache
dnf repolist --enableddnf repolist --enabled には、baseos、appstream、extras、crb、epel が表示されるはずです。epel-cisco-openh264 の小さなエントリが表示される場合もあります。これは epel-release が追加したものです。一覧に crb がない場合、有効化に失敗しています。理由は次のセクションで説明します。
Rocky 8 と Alma 8 では、リポジトリ名は PowerTools のままです。そのため、中間のコマンドは sudo dnf config-manager --set-enabled powertools になります。リポジトリ ID では大文字と小文字が区別されます。古い CentOS 8 のドキュメントでは、PowerTools のように大文字を使っていることがありますが、この表記は一致しません。AlmaLinux 10 では 10.0 以降、CRB リポジトリがデフォルトで有効になっています（2025 年 9 月に変更）。そのため、ここでは epel-release の手順だけ実行します。
epel-release は、すでに有効になっている extras から提供されます。そのため、信頼する URL を指定したり、鍵を手動でインポートしたりする必要はありません。このパッケージは /etc/yum.repos.d/epel.repo を書き込み、EPEL 署名鍵を /etc/pki/rpm-gpg/ にインストールします。そのファイルで gpgcheck=1 を確認してください。署名エラーを --nogpgcheck で回避するよう指示するガイドは無視してください。署名検証に失敗する場合、パッケージが主張どおりのものではないか、システムの時計が正しくありません。
Rocky では、epel-release により /usr/bin/crb に小さなヘルパーもインストールされます。そのため、sudo crb enable と crb status はプラグインなしで同じ処理を実行します。使用する前に command -v crb でインストール済みか確認してください。すべての再構築版のすべてのブランチに含まれているわけではありません。
EPEL が一覧に表示されるだけでなく到達可能であることを確認するには、EPEL だけが提供するパッケージを検索します。
dnf repoquery --repo=epel htopパッケージ名、バージョン、アーキテクチャが表示されます。何も表示されない場合、リポジトリは有効ですが応答を返していません。通常は設定の問題ではなく、ミラーまたはメタデータの問題です。次に sudo dnf clean all && sudo dnf makecache を試してください。
dnf で config-manager が「そのようなコマンドはありません」と表示される理由
ここでつまずく人が多く、VPS プロバイダーが提供するイメージでは特に発生します。
No such command: config-manager. Please use /usr/bin/dnf --help
It could be a DNF plugin command, try: "dnf install 'dnf-command(config-manager)'"config-manager は組み込みの dnf サブコマンドではなく、プラグインです。dnf-plugins-core に含まれています。完全なサーバーインストールではこのパッケージが導入されますが、最小構成イメージ、クラウドイメージ、コンテナイメージでは省かれています。dnf 自身が提示する方法で動作するのは、パッケージがこの仮想機能を宣言しているためです。
sudo dnf install -y 'dnf-command(config-manager)'この部分は引用してください。括弧はシェル構文なので、引用しないと dnf のエラーではなく構文エラーになります。
必要なリポジトリが無効になっているためにプラグインをインストールできない場合は、ファイルを直接編集します。セクションを含むファイルを特定して開き、[crb] の下に enabled=1 を設定します。
grep -rl crb /etc/yum.repos.d/これは config-manager が書き込む内容とまったく同じなので、手動で設定しても失われるものはありません。dnf repolist --enabled で結果を確認できます。
一部の EPEL パッケージは CRB を有効にするまでインストールできない
2 つ目によくある落とし穴では、CRB について一切触れないエラーが表示されます。CRB でのみ提供されるライブラリにリンクする EPEL パッケージは、依存関係の解決時に失敗します。このメッセージには、そのライブラリ名と、それを必要としたパッケージ名が表示されます。
Error:
Problem: conflicting requests
- nothing provides libexample.so.0()(64bit) needed by examplepkg-1.4-2.el9.x86_64 from epel原因は CRB が無効になっているため、dnf がそのライブラリを提供する唯一のリポジトリを参照できないことです。次の 2 点を順番に確認します。
dnf repolist --enabled
dnf --enablerepo=crb repoquery --whatprovides 'libexample.so.0()(64bit)'2 つ目のコマンドでパッケージ名が表示される一方、通常のインストールが失敗する場合は、CRB が無効になっています。この種のエラーは十分に多かったため、AlmaLinux は発生を防ぐ目的で version 10 から CRB をデフォルトで有効にしました。--enablerepo=crb は単一のインストールで一度だけ指定するフラグとしても使用できます。ただし、EPEL を使用する場合は CRB を常に有効にしてください。次回の EPEL 更新で、事前の警告なしに新しい CRB 依存関係が追加される可能性があるためです。
このパッケージはどのリポジトリから取得されたものですか？
4 つのリポジトリを有効にして数週間運用すると、重要な問いは「何がインストールされているか」から「どこから取得されたか」へ変わります。
dnf repolist --all
dnf info htop
dnf repoquery --installed --qf '%{from_repo} %{name}' | sort | uniq -c | sort -rn
dnf repository-packages epel list installedインストール済みパッケージに対する dnf info は、From repo 行を出力します。dnf list installed は 3 列目の先頭に @ を付けて同じ情報を表示します。そのため、@epel は EPEL からインストールされたことを示し、@System は dnf が取得元を認識していないことを示します。通常は、ダウンロードしたファイルに対して誰かが rpm -i を実行した場合です。repoquery 行にはリポジトリごとの件数が表示されます。これは、引き継いだサーバーに、存在を知らなかったリポジトリのパッケージが 40 個も入っていることを発見する最も速い方法です。最後のコマンドは、1 つのリポジトリから取得したパッケージだけを一覧表示します。リポジトリを削除する前に必要なのは、この一覧です。
ここでの apt の習慣は apt-cache policy <package> です。最初の 1 か月は、dnf と apt のコマンド対応表を 2 つ目のタブで開いておくと便利です。フラグが異なっていても、概念はそのまま対応するためです。
サードパーティーリポジトリによるベースパッケージの置き換えを防ぐにはどうすればよいですか？
EPEL はこのような置き換えを行わないとしています。他のリポジトリには、その保証はありません。データベース、エージェント、言語ランタイム用のベンダーリポジトリが、BaseOS でも提供されているライブラリを独自にビルドして配布することがあります。この場合、dnf はそのパッケージをインストールします。dnf のデフォルトのルールは単純で、どこから提供されたかにかかわらず、最も高いバージョンを選ぶためです。
主に使用する制御機能は 2 つです。どちらも /etc/yum.repos.d/ 配下のリポジトリーファイルに記述します。
priority= は、同じパッケージ名を複数のリポジトリが提供している場合に、どのリポジトリを優先するかを決めます。数値が小さい方が優先され、デフォルトは 99 です。そのため、ベースリポジトリには小さい値を、サードパーティーリポジトリには大きい値を設定します。これにより、サードパーティー版の方が新しくても、dnf はベースパッケージを選びます。現在の dnf はこの処理を自動的に行うため、CentOS 7 時代の個別の yum-plugin-priorities パッケージは、もはや解決策の一部ではありません。
includepkgs= は、フィルターオプションの中でより強力です。excludepkgs= は、リポジトリから除外するパッケージ名を指定します。ただし、そのリポジトリが配布する可能性のあるパッケージを事前に予測する必要があります。includepkgs= はこの動作を反転します。このリポジトリは指定した名前のパッケージだけを提供できます。独自のエージェントだけを提供させたいベンダーリポジトリなら、1 行で設定できます。
[vendor-tools]
name=Vendor tools for EL9
baseurl=https://packages.example.com/el9/x86_64/
enabled=1
gpgcheck=1
gpgkey=https://packages.example.com/RPM-GPG-KEY-vendor
priority=90
includepkgs=vendor-agent,vendor-agent-pluginsversion 8 では、もう 1 つ確認すべき設定があります。サードパーティーリポジトリのパッケージは、同じ名前を AppStream モジュールが提供している場合に非表示になることがあります。そのリポジトリのセクションにある module_hotfixes=1 は、dnf に対してそのパッケージのフィルタリングを停止するよう指示します。dnf repoquery にはパッケージが表示されるのに、version 8 のホストでインストールできない場合は、通常これが原因です。version 9 ではモジュールのほとんどが削除されたため、この問題はほとんど発生しません。
1 つのパッケージを 1 つのバージョンに固定するには、python3-dnf-plugin-versionlock をインストールして sudo dnf versionlock add <package> を使用します。これは apt-mark hold に相当します。Debian から移行した場合に混乱しやすい逆の仕様に注意してください。apt では大きい Pin-Priority が優先されますが、dnf では小さい priority が優先されます。
RHEL 系リポジトリを混在させるとサーバーをアップグレードできなくなる理由
Rocky、Alma、CentOS Stream、Oracle Linux、RHEL は、互いのパッケージをインストールできる程度には近く、誰もサポートできないシステムになってしまう程度には異なります。なぜこれらが近い関係にあり、特に Stream が現在は RHEL と並列ではなく先行する位置にあるのかについては、Red Hat Linux が Fedora と RHEL に分かれ、CentOS がどうなったかの経緯を参照してください。
仕組みの鍵はバージョン番号です。CentOS Stream 9 は RHEL 9 より先行するため、Rocky 9 のサーバーを Stream リポジトリに一度でも、1 パッケージだけでも向けると、Rocky が今後提供することのない、より新しいバージョンのパッケージがインストールされます。次の Rocky マイナーリリースが登場しても、そのパッケージのバージョンは現在のものより低いため、dnf upgrade はそれに触れません。これで、その構成を誰もテストしていない状態でサーバーが動作し、パッチが適用されていると思い込んだまま、何年も気付かずに残ることになります。
症状としては、dnf upgrade が更新対象なしと報告する一方で、sudo dnf distro-sync が多数のパッケージのダウングレードを提案します。修復には distro-sync を使用します。これはインストール済みの全パッケージを、有効なリポジトリが実際に提供する内容に一致させるツールで、ダウングレードも実行します。最初に外部のリポジトリを無効化し、次にこれを実行してください。適用を承認する前に、提案された一覧を確認します。ミラーに古い RPM が残っていない場合、修復は失敗します。その時点では、依存関係の解決に時間をかけるより、クリーンなイメージからサーバーを再構築するほうが速く、安全です。
ELevate の残骸も、この問題でよくある別の形です。ELevate は Leapp を基盤とする AlmaLinux の移行ツールで、CentOS 7 のサーバーを移行したり、再構築版ディストリビューション間で変換したりするために使用します。移行を急いで実行すると、/etc/yum.repos.d/ に EL7 のリポジトリファイルが残り、EL7 パッケージもインストールされたままになります。rpm -qa | grep el7 でそれらを検出できます。これらは、有効なリポジトリから更新できないパッケージです。後で Leapp を実行すると、対応付けできないパッケージとして報告され、手作業で解消するアップグレードの阻害要因になります。次のメジャーアップグレードが必要になった当日ではなく、サーバーが安定しているうちに削除してください。
ベンダーリポジトリが AppStream のパッケージを上書きするケースは、同じ問題の軽い例です。上記の includepkgs の行が解決策になります。典型例はコンテナツールです。Docker 独自のリポジトリにある containerd.io は AppStream の runc と競合するため、どちらかを削除する必要があります。方針を決めたら、除外設定を記録し、既知の手順に従って作業してください。Rocky Linux への Docker のインストールの手順では、先に削除するディストリビューションパッケージを説明しています。
リポジトリにおける apt から dnf への対応関係
/etc/apt/sources.list.d/*.sourcesは/etc/yum.repos.d/*.repoに相当します。1 つのファイルに複数の[sections]を記述でき、それぞれに独自の id を設定します。add-apt-repository universeはdnf install epel-releaseに相当します。ただし、universeは引き続き Ubuntu 自身のアーカイブ内にあり、EPEL は独立したプロジェクトです。apt updateに相当するものはないため、覚えておく必要があります。dnf は独自のスケジュールでメタデータを更新し、dnf makecacheを実行すると直ちに更新します。apt-cache policy <pkg>はdnf info <pkg>に相当し、dnf list --showduplicates <pkg>を追加すると提供されているすべてのバージョンを確認できます。apt-mark holdはpython3-dnf-plugin-versionlockのdnf versionlock addに相当します。/etc/apt/preferences.d/の Pinning は、リポジトリセクションではpriority=に相当します。番号の大小関係は逆です。dpkg -S /path/to/fileはrpm -qf /path/to/fileに相当します。
自動更新は構文ではなく、考え方として対応します。ここには unattended-upgrades がないためです。タイマー、設定ファイル、再起動するかどうかの判断については、Rocky と Alma の dnf-automaticで説明します。
リポジトリ一覧は短く保つ
CRB を有効にして epel-release をインストールしたら、実施した内容と理由を、構成管理システムまたはサーバー上のプレーンテキストファイルに記録します。サーバーが導入から 3 年経過し、別の担当者が管理している状況では、この記録が想像以上に役立ちます。
追加する前に検索します。dnf search、続いて dnf info を実行し、その後で新しいリポジトリを検討します。EPEL を有効にする理由の多くは、すでに AppStream に含まれています。システム監視がその最も分かりやすい例です。Performance Co-Pilot はベースリポジトリで提供されているため、サードパーティのリポジトリは必要ありません。リポジトリを追加するたびに、別の提供元からパッケージが配布される可能性が生じます。また、追加したリポジトリが多いほど、次回のメジャーアップグレードは難しくなります。
まだ 2 つのディストリビューションから選んでいる段階であれば、この構成はどちらでも同じで、epel-release も同じように動作します。実際の違いは別の点にあります。Rocky Linux と AlmaLinux の比較では、再構築に対する方針を説明しています。AlmaLinux は現在、1 行単位の再構築ではなく、ABI（application binary interface）互換性を目標にしているためです。
FAQ
Rocky Linux 9 または AlmaLinux 9 で EPEL を有効にするにはどうすればよいですか？
まず sudo dnf install -y dnf-plugins-core、次に sudo dnf config-manager --set-enabled crb、その後 sudo dnf install -y epel-release を実行します。dnf repolist --enabled で確認します。baseos、appstream、extras、crb、epel が表示されるはずです。EPEL パッケージをインストールする前に CRB を有効にしてください。多くのパッケージが、CRB でのみ提供されるライブラリに依存しているためです。バージョン 8 では、リポジトリー ID は crb ではなく powertools です。
本番サーバーで EPEL を有効にしても安全ですか？
EPEL は広く利用されています。また、EPEL パッケージがベースディストリビューションのパッケージを置き換えない方針で構築されているため、有効にしても BaseOS や AppStream の内容は変わりません。注意点はサポートです。EPEL はボランティアによる Fedora プロジェクトであり、サービスレベル合意はありません。メンテナーがパッケージを維持する期間も、RHEL のマイナーリリース 1 つ分、または 13 か月に限られる場合があります。dnf repository-packages epel list installed でインベントリを管理し、顧客向けサービスが依存する EPEL パッケージには dnf versionlock を使用してください。
dnf で no such command: config-manager と表示されるのはなぜですか？
config-manager は組み込みコマンドではなく dnf のプラグインであり、最小構成またはコンテナーのイメージには dnf-plugins-core が含まれていないためです。メッセージ自体に解決方法が示されています。シェルが括弧を解釈しないように引用符で囲んだ sudo dnf install -y 'dnf-command(config-manager)' を実行してください。まだ何もインストールできない場合は grep -rl crb /etc/yum.repos.d/ を実行し、指定されたファイルを開いて、[crb] セクションの enabled=1 を手動で設定します。
CRB と PowerTools の違いは何ですか？
同じリポジトリーに付けられた 2 つの名前です。バージョン 8 では PowerTools と呼ばれ、ID は powertools です。バージョン 9 以降では CRB と呼ばれ、ID は crb です。Red Hat 独自の製品では、このコンテンツを CodeReady Linux Builder と呼びます。開発用ヘッダー、静的ライブラリ、ビルド時のツールを提供します。Rocky と AlmaLinux 9 では、デフォルトで無効になっています。AlmaLinux 10 では 10.0 からデフォルトで有効になっているため、そこで有効化コマンドを実行する前に dnf repolist --enabled を確認してください。
既存の環境を壊さずに EPEL を削除するにはどうすればよいですか？
まず dnf repository-packages epel list installed でインベントリを確認してください。epel-release パッケージだけを削除しても、EPEL からインストールしたパッケージは削除されないためです。これらのパッケージはディスク上に残り、更新元を失います。その結果、セキュリティ修正も提供されなくなりますが、それを知らせるエラーは表示されません。パッケージごとに判断し、不要になったものを削除または置き換えてから、sudo dnf remove epel-release を実行してください。EPEL のパッケージが何も置き換えておらず、単純に削除する必要がある場合は、sudo dnf repository-packages epel remove で対象一式を 1 回のトランザクションで削除できます。実行を確定する前に、提示された一覧を注意深く確認してください。