ガイド

著者 Matt Connor 2026-10-11

Rocky・AlmaLinuxでEPELとCRBを有効化する方法

Q: 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 を有効にしてください。多くの EPEL パッケージは、CRB でのみ提供されるライブラリに依存しているためです。version 8 では、repository id が crb ではなく powertools になります。

Q: dnf が no such command: config-manager と表示するのはなぜですか？

config-manager は dnf の組み込みコマンドではなく、dnf plugin だからです。minimal image や container image には dnf-plugins-core が含まれていません。このメッセージ自体が解決方法を示しています。シェルが括弧を解釈しないように引用符で囲んだ sudo dnf install -y 'dnf-command(config-manager)' を実行してください。まだ何もインストールできない場合は grep -rl crb /etc/yum.repos.d/ を実行し、表示されたファイルを開いて、[crb] セクションの enabled=1 を手動で設定します。

Q: 問題を起こさずに EPEL を削除するにはどうすればよいですか？

まず dnf repository-packages epel list installed で一覧を確認してください。epel-release パッケージだけを削除しても、EPEL からインストールしたパッケージは削除されないためです。これらのパッケージはディスク上に残り、更新元を失います。その結果、エラーが表示されないまま security fix も受け取れなくなります。パッケージごとに判断し、不要なものを削除または置き換えてから、sudo dnf remove epel-release を実行してください。EPEL のパッケージが何も置き換えておらず、単純に削除する必要がある場合は、sudo dnf repository-packages epel remove で一度の transaction により対象一式を削除できます。実行前に、提示された一覧を慎重に確認してください。

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、コアユーザーランドが含まれます。ここに含まれるバージョンは、メジャーリリースのライフサイクル中にほとんど変わりません。セキュリティ修正を含むほとんどの修正は、既存のバージョンにバックポートされます。ただし、マイナーリリースでコアコンポーネントが新しいアップストリームバージョンにリベースされることもあります。たとえば AlmaLinux 9.2 では、SELinux ユーザー空間パッケージがバージョン 3.5 に更新されました。BaseOS で数年前のものに見えるバージョン番号は、未修正のパッケージを意味しません。修正が適用された古いバージョンです。これがエンタープライズディストリビューションの目的です。

AppStream には、オペレーティングシステム上で実行するソフトウェアが含まれます。Web サーバー、データベース、言語ランタイム、エディター、監視エージェントなどです。バージョン 8 では、AppStream の多くが代替ストリームを持つモジュールとして提供されていたため、dnf module list が重要でした。たとえば、PHP のストリームを 1 つ選択する必要がありました。バージョン 9 では、各アプリケーションのデフォルトバージョンが通常のパッケージとして提供されます。そのため Rocky 9 と Alma 9 では、通常の dnf install を指定するだけでそのバージョンを利用でき、先にモジュールを有効化する必要はありません。代替バージョンは引き続きモジュールストリームとして提供されます。RHEL 9 では、PHP 8.0 が通常の php パッケージ、PHP 8.1 と 8.2 がそれぞれ php:8.1 ストリームと php:8.2 ストリームとして記載されています。また、AlmaLinux 9.8 では、MariaDB 11.8、PostgreSQL 18、Ruby 4.0 などの新しいストリームが追加されました。デフォルト以外のバージョンが必要な場合は、9 でも dnf module list が重要です。

Extras はデフォルトで有効になっており、規模も非常に小さいリポジトリです。主に他のリポジトリ用のリリースパッケージを格納しています。epel-release 自体もそこから提供されます。この仕組みにより、Rocky や Alma に EPEL をインストールする際、任意の URL を信頼する必要はありません。

CRB は CodeReady Builder リポジトリです。バージョン 8 では PowerTools と呼ばれます。ディストリビューションのビルドに必要なものを格納しています。開発用ヘッダー、静的ライブラリ、パッケージのビルド時に必要なテストおよびドキュメント用ツールなどです。CRB はすでにミラー上にありますが、デフォルトでは無効です。Red Hat 独自の製品では、同じ内容を CodeReady Linux Builder と呼びます。サブスクリプションに含まれますが、Red Hat はサポート対象外としています。Rocky と Alma は、内容とデフォルトで無効になっている設定の両方を引き継いでいます。

Debian または Ubuntu から移行してきた読者向けに説明すると、main はランタイムパッケージと -dev ヘッダーを 1 つのアーカイブに混在させています。そのため、そこで 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のメンテナーが約束する期間ははるかに短く、EPELのリリースベースのパッケージライフタイム提案では、少なくとも1つのRHELマイナーリリースまたは13か月のうち、短い方とされています。実際には、これよりはるかに長く保守されるパッケージが大半です。ただし、メンテナーが担当を離れた際に廃止されるパッケージもあります。また、EPELはFedoraに追随するため、ディストリビューションのライフタイム途中で新しいメジャーバージョンへ移行するパッケージもあります。そのため、通常のdnf upgradeによって、安定していると思っていたマシン上のEPELツールが新しいメジャーバージョンになることがあります。依存しているパッケージが、利用者に届く告知なしに更新されなくなる可能性もあります。新しいバージョンは、すでに実行中のサービスには適用されません。そのため、トランザクション完了後にどのプロセスが古いバイナリを使い続けているかを確認するには、needs-restartingを使用します。

有効化する前に知っておくべき影響がもう1つあります。EPELは、サーバーで固定している可能性がある古いマイナーリリースを対象にビルドされるとは限りません。FedoraのEPELポリシーでは、EPEL 10の先行するマイナーバージョンをCentOS Stream 10に対してビルドし、後続するEPEL 10のマイナーバージョンを特定のRHEL 10マイナーリリースに対してビルドします。EPEL 8と9にも、それぞれ独自のターゲット定義があります。サーバーを古いマイナーリリースのまま固定し、凍結したミラーやベンダーのポイントリリースリポジトリを使用している場合、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 --enabled

dnf 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-plugins

Version 8 では、もう 1 つ確認すべき設定があります。第三者リポジトリのパッケージは、同じ名前を AppStream モジュールが提供している場合に非表示になることがあります。そのリポジトリのセクションで module_hotfixes=1 を指定すると、dnf はそのパッケージをフィルタリングしなくなります。ベンダーリポジトリが確実に提供しているパッケージが見つからない、または 8 のシステムでインストールできない場合、通常はこれが原因です。モジュールによるフィルタリングによって、そのパッケージは競合として報告されるのではなく、多くの dnf コマンドから見えなくなります。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 と並列ではなく RHEL より先行している理由については、Red Hat Linux が Fedora と RHEL に分かれ、CentOS がどうなったかの経緯を参照してください。

仕組みの鍵はバージョン番号です。CentOS Stream 9 は RHEL 9 より先行しており、Red Hat は Stream のコードを次の RHEL マイナーリリースになるものとして説明しています。Rocky 9 のシステムを Stream リポジトリに向けると、たとえ 1 回だけ、1 パッケージだけであっても、現在 Rocky が提供しているものより新しいバージョンのパッケージが残ります。後続の Rocky マイナーリリースが追いつく可能性はありますが、そのパッケージを同じバージョン以上で提供する保証はありません。提供されるまで、dnf upgrade はそのパッケージに触れません。システムは誰もテストしていない組み合わせで動作することになり、パッチ適用済みだと思い込んだまま、何年もその状態が続くことがあります。

症状としては、dnf upgrade が更新対象なしと報告する一方で、sudo dnf distro-sync が多数のパッケージのダウングレードを提案します。distro-sync が修復ツールです。インストール済みのすべてのパッケージを、有効なリポジトリが実際に提供する内容に一致させます。ダウングレードも実行します。まず外部のリポジトリを無効にしてから実行し、承認する前に提案された一覧を確認してください。古い RPM がミラー上に残っていない場合、修復は失敗します。その時点では、依存関係ソルバーと格闘するより、クリーンなイメージからサーバーを再構築する方が速く、安全です。

ELevate の残骸も、この問題でよくある別の形です。ELevate は Leapp を基盤とする AlmaLinux の移行ツールで、CentOS 7 のシステムを移行したり、rebuild 間で変換したりするために使用します。移行を急いで実行すると、/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 を有効にしてください。多くの EPEL パッケージは、CRB でのみ提供されるライブラリに依存しているためです。version 8 では、repository id が crb ではなく powertools になります。

本番サーバーで EPEL を有効にしても安全ですか？

EPEL は広く利用されています。また、EPEL パッケージがベースディストリビューションのパッケージを置き換えない方針で構築されているため、有効にしても BaseOS や AppStream が提供する内容は変わりません。ただし、サポートには注意が必要です。EPEL はボランティアによる Fedora プロジェクトであり、サービスレベル契約はありません。さらに、EPEL のパッケージ存続期間に関する提案では、メンテナーがパッケージを維持する期間を、RHEL の minor release 1 回分、または 13 か月という短い期間とすることも認めています。dnf repository-packages epel list installed でパッケージ一覧を管理し、顧客向けサービスが依存する EPEL パッケージには dnf versionlock を使用してください。

dnf が no such command: config-manager と表示するのはなぜですか？

config-manager は dnf の組み込みコマンドではなく、dnf plugin だからです。minimal image や container image には dnf-plugins-core が含まれていません。このメッセージ自体が解決方法を示しています。シェルが括弧を解釈しないように引用符で囲んだ sudo dnf install -y 'dnf-command(config-manager)' を実行してください。まだ何もインストールできない場合は grep -rl crb /etc/yum.repos.d/ を実行し、表示されたファイルを開いて、[crb] セクションの enabled=1 を手動で設定します。

CRB と PowerTools の違いは何ですか？

同じ repository を別の名前で呼んでいるだけです。version 8 では PowerTools と呼ばれ、id は powertools です。version 9 以降では CRB と呼ばれ、id は crb です。Red Hat の製品では、CodeReady Linux Builder という名前で提供されています。開発用ヘッダー、static library、build 時に使用するツールが含まれています。Rocky ではデフォルトで無効になっており、AlmaLinux 9 でもデフォルトで無効です。AlmaLinux 10 では 10.0 からデフォルトで有効になっているため、そこで有効化コマンドを実行する前に dnf repolist --enabled を確認してください。

問題を起こさずに EPEL を削除するにはどうすればよいですか？

まず dnf repository-packages epel list installed で一覧を確認してください。epel-release パッケージだけを削除しても、EPEL からインストールしたパッケージは削除されないためです。これらのパッケージはディスク上に残り、更新元を失います。その結果、エラーが表示されないまま security fix も受け取れなくなります。パッケージごとに判断し、不要なものを削除または置き換えてから、sudo dnf remove epel-release を実行してください。EPEL のパッケージが何も置き換えておらず、単純に削除する必要がある場合は、sudo dnf repository-packages epel remove で一度の transaction により対象一式を削除できます。実行前に、提示された一覧を慎重に確認してください。

#rocky-linux #almalinux #dnf#epel#repositories