指南

作者： Matt Connor 2026-08-21 · 已更新 2026-08-27

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，因為其中許多套件依賴只有 CRB 提供的函式庫。在版本 8 中，儲存庫 ID 是 powertools，不是 crb。

Q: 為什麼 dnf 顯示 no such command: config-manager？

因為 config-manager 是 dnf plugin，不是內建命令，而 minimal 或 container image 通常未包含 dnf-plugins-core。訊息本身已提供修正方式：sudo dnf install -y 'dnf-command(config-manager)'；這裡加上引號，是為了避免 shell 解讀括號。如果目前還無法安裝任何套件，請執行 grep -rl crb /etc/yum.repos.d/，開啟它指定的檔案，然後在 [crb] 區段中手動設定 enabled=1。

Q: CRB 和 PowerTools 有何差異？

它們是同一個儲存庫的兩個名稱。版本 8 稱為 PowerTools，ID 為 powertools；版本 9 及後續版本稱為 CRB，ID 為 crb。Red Hat 自有產品則將這些內容稱為 CodeReady Linux Builder。該儲存庫提供開發標頭檔、靜態函式庫與建置時工具，且在 Rocky 和 AlmaLinux 9 上預設停用。AlmaLinux 10 從 10.0 起預設啟用，因此在該版本執行啟用命令前，請先檢查 dnf repolist --enabled。

Q: 如何再次移除 EPEL 而不造成問題？

先使用 dnf repository-packages epel list installed 建立清單，因為單獨移除 epel-release 套件不會移除從 EPEL 安裝的任何套件。這些套件會留在磁碟上，失去更新來源，且不再取得安全修正；過程中不會出現任何錯誤提示。逐一評估套件，移除或替換不再需要的套件，最後才執行 sudo dnf remove epel-release。如果某個 EPEL 套件沒有取代其他套件，且確定必須移除，sudo dnf repository-packages epel remove 可在單一 transaction 中清除整組套件；確認前請仔細閱讀預定移除的清單。

dnf 出現「No match for argument」時，了解 BaseOS、AppStream 與 CRB 的差異，依 Rocky Linux 和 AlmaLinux 版本安全加入 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 幾乎會在所有 cloud image 上啟用，因此通常不會遇到這個問題。Red Hat 系列以不同方式拆分套件，預設提供的內容也較少。修正方式只需要 3 個指令。本指南接下來說明第 1 週通常不會有人告訴您的內容：這些軟體庫提供哪些保證、不提供哪些保證，以及如何避免第三方軟體庫在沒有明顯提示的情況下接管您的基礎系統。

這些指令的檢查方式。我們的指令測試容器只執行 Ubuntu，因此下方的 dnf 指令並未在我們自己的測試機器上執行。這些指令依循 Rocky Linux 和 AlmaLinux 文件。每個步驟都列出您應該看到的輸出，請在自己的伺服器上逐一檢查，不要一次貼上整個區塊。

什麼是 BaseOS、AppStream 與 CRB？

BaseOS 就是作業系統本身：核心、glibc、systemd 及核心使用者空間工具。這裡的版本會在主要版本的生命週期內維持不變，安全性修正則會回溯套用至這些固定版本。BaseOS 中看起來已有多年歷史的版本號，不代表套件未修補，而是已套用修補的舊版本。這正是企業級發行版的設計目的。

AppStream 存放在作業系統上執行的元件：網頁伺服器、資料庫、語言執行環境、編輯器及監控代理程式。在 version 8 中，AppStream 的許多內容以具備替代 stream 的 modules 提供，因此 dnf module list 很重要；例如，您可以選擇某個 PHP stream。Version 9 幾乎移除了所有 modularity，因此在 Rocky 9 和 Alma 9 上，通常會直接取得某個元件的一個版本，不必先啟用 module。

Extras 預設已啟用，內容很少。它主要存放其他 repository 的 release packages，而 epel-release 本身就是從這裡取得。正因如此，在 Rocky 或 Alma 上安裝 EPEL 時，絕不需要信任隨機 URL。

CRB 是 CodeReady Builder repository，在 version 8 中稱為 PowerTools。它存放發行版的建置元件：開發標頭檔、靜態函式庫，以及套件在建置時需要的測試與文件工具。它已位於 mirror 上，但預設停用。在 Red Hat 自有產品中，相同內容稱為 CodeReady Linux Builder，並隨訂閱提供；Red Hat 表示該內容不在支援範圍內。Rocky 和 Alma 同時沿用這些內容，以及預設停用的設定。

對於從 Debian 或 Ubuntu 轉來的讀者：main 會在同一個 archive 中混合 runtime packages 與 -dev headers，因此不需要在其中啟用 CRB。與 EPEL 最接近的是 universe；它由社群維護，不提供廠商支援承諾。

EPEL 是什麼，以及由誰維護

EPEL 代表 Extra Packages for Enterprise Linux。它是 Fedora 專案：將 Fedora 中的套件針對目前的企業版重新建置，再由 EPEL Special Interest Group 維護；該群組成員主要是 Fedora 社群中的志願者。Red Hat 提供建置與鏡像基礎架構，也有部分 Red Hat 工程師維護其中的套件。雙方的關係僅止於此。EPEL 不是 Red Hat 產品。EPEL 套件不論用於 RHEL 或其重建版本，都沒有支援合約，也沒有 SLA（service level agreement）。

EPEL 能夠安全啟用，是因為它遵循一項政策：EPEL 套件絕不能取代基礎發行版中的套件。如果 AppStream 提供 nginx，EPEL 就不會提供該套件。這項規則由審查 EPEL 套件的人員執行，因此它只代表 EPEL 的承諾。它無法保護你之後加入的其他來源。

EPEL 對套件生命週期的承諾也不同於基礎發行版，這一點在第 3 年最容易造成問題。BaseOS 套件版本會在主要版本的整個 10 年生命週期內固定不變。EPEL 維護者承諾的期間短得多：至少 1 個 RHEL 次要版本週期或 13 個月，以較短者為準。實務上，多數套件的維護時間遠超過這段期間。有些套件會在維護者停止維護後退役；有些則會在你的發行版生命週期中途升級到新的主要版本，因為 EPEL 會跟隨 Fedora。因此，一次例行的 dnf upgrade 可能會在你以為穩定的機器上，安裝 EPEL 工具的新主要版本；你所依賴的套件也可能停止接收更新，而你不一定會收到公告。新版本也不會套用到已在執行的服務，因此交易完成後，needs-restarting 可告訴你哪些程序仍在使用舊的二進位檔。

啟用 EPEL 前，還有一項後果值得了解：EPEL 是以最新的 RHEL 次要版本為基礎建置。如果你使用固定的鏡像或供應商提供的特定版本套件庫，讓伺服器停留在較舊的次要版本，EPEL 套件可能會要求比目前版本更新的基礎函式庫。dnf 會將此回報為缺少相依性；表面上看起來像是鏡像問題，實際上是版本不一致問題。

啟用 CRB 並在 Rocky 或 Alma 上安裝 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 上，CRB 從 10.0 起預設已啟用（於 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 確實可連線，而不只是出現在清單中，請查詢只有該儲存庫提供的套件：

dnf repoquery --repo=epel htop

該命令會輸出套件名稱、版本和架構。沒有輸出表示儲存庫雖已啟用，但未傳回任何內容。這通常是 mirror 或中繼資料問題，而非設定問題，因此接著嘗試 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)'

請將它加上引號。括號是 shell 語法；未加引號的版本會產生語法錯誤，而不是 dnf 錯誤。

如果需要的儲存庫目前就是停用的儲存庫，導致無法安裝此外掛程式，請直接編輯檔案。找出包含該區段的檔案，開啟檔案，並在 [crb] 下設定 enabled=1：

grep -rl crb /etc/yum.repos.d/

這正是 config-manager 寫入的內容，因此手動修改不會遺漏任何設定。dnf repolist --enabled 會確認結果。

部分 EPEL 套件必須先啟用 CRB 才能安裝

第二個常見陷阱產生的錯誤訊息不會提到 CRB。某個 EPEL 套件若依賴只有 CRB 提供的程式庫，解析相依性時就會失敗。錯誤訊息會列出該程式庫，以及需要它的套件：

Error:
 Problem: conflicting requests
  - nothing provides libexample.so.0()(64bit) needed by examplepkg-1.4-2.el9.x86_64 from epel

原因是 CRB 未啟用，因此 dnf 找不到唯一提供該程式庫的儲存庫。請依序檢查以下兩項：

dnf repolist --enabled
dnf --enablerepo=crb repoquery --whatprovides 'libexample.so.0()(64bit)'

如果第二個命令列出某個套件，但直接安裝仍然失敗，表示 CRB 未啟用。這類錯誤相當常見，因此 AlmaLinux 在版本 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 會在第三欄顯示相同資訊，並在前方加上 @，因此 @epel 表示套件是從 EPEL 安裝，@System 表示 dnf 不知道套件來源，通常代表有人對下載的檔案執行了 rpm -i。repoquery 行會統計各軟體庫的套件數量。這是找出你接手的伺服器包含 40 個來自陌生軟體庫套件的最快方法。最後一個指令會列出某個軟體庫實際提供給你的所有內容。移除該軟體庫前，你需要先取得這份清單。

在 apt 中對應的習慣是 apt-cache policy <package>。第一個月建議在第二個分頁保留dnf 與 apt 指令對照，因為即使旗標不同，兩者的概念仍能直接對應。

如何停止第三方 repository 取代基礎套件？

EPEL 承諾不會這麼做。其他 repository 都沒有這項承諾。資料庫、agent 或語言 runtime 的廠商 repository 可能提供 BaseOS 也有的 library 自行建置版本，而 dnf 會安裝該版本，因為 dnf 的預設規則很簡單：無論版本來自哪個 repository，版本最高者勝出。

兩項控制項就能處理大部分情況，而且兩者都位於 /etc/yum.repos.d/ 下的 repository 檔案中。

priority= 決定多個 repository 提供相同套件名稱時，由哪個 repository 勝出。數值越低者優先，預設值為 99，因此請為基礎 repository 設定較低的數值，並為第三方 repository 設定較高的數值。如此一來，即使第三方版本較新，dnf 仍會採用基礎套件。現代版本的 dnf 會自行處理這項功能，因此 CentOS 7 時代的獨立 yum-plugin-priorities 套件已不再是解決方案的一部分。

includepkgs= 是較強的篩選選項。excludepkgs= 會封鎖 repository 中指定名稱的套件，因此必須預測該 repository 可能提供哪些套件。includepkgs= 則反向運作：此 repository 只能提供指定名稱的套件，不能提供其他套件。若某個廠商 repository 只應提供自有的 agent，只需設定一行即可。

[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 上，還有一項設定需要注意。當 AppStream module 提供相同名稱時，第三方 repository 的套件可能會被隱藏；該 repository 區段中的 module_hotfixes=1 會告訴 dnf 停止篩選該套件。如果套件在 dnf repoquery 中可見，但無法在 version 8 的主機上安裝，通常就是這個原因。version 9 幾乎移除了所有 module，因此這種情況很少在該版本出現。

若要將一個套件固定為特定版本，請安裝 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 儲存庫一次，甚至只安裝一個套件，也會留下版本超前、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；單一檔案可包含多個 [sections]，每個都有自己的 id。
add-apt-repository universe 對應 dnf install epel-release，但 universe 仍位於 Ubuntu 自有的 archive 中，而 EPEL 是獨立專案。
apt update 沒有需要記住的對應項目。dnf 會依自己的排程重新整理 metadata，而 dnf makecache 會立即強制執行。
apt-cache policy <pkg> 對應 dnf info <pkg>，另加 dnf list --showduplicates <pkg> 以查看所有可用版本。
apt-mark hold 對應 dnf versionlock add，來源為 python3-dnf-plugin-versionlock。
/etc/apt/preferences.d/ 中的套件釘選，在 repository 區段中對應為 priority=，但數字順序相反。
dpkg -S /path/to/file 對應 rpm -qf /path/to/file。

自動更新應視為概念上的轉換，而不是語法上的轉換，因為這裡沒有 unattended-upgrades。timer、設定檔，以及是否重新開機的問題，請參閱 Rocky 和 Alma 上的 dnf-automatic。

縮短軟體庫清單

啟用 CRB、安裝 epel-release，然後在組態管理系統或主機上的純文字檔中記錄執行的操作及原因。當伺服器使用三年後由其他人接手維護時，這份記錄的價值超乎想像。

新增前先搜尋。執行 dnf search，再執行 dnf info，之後才考慮新增軟體庫。人們啟用 EPEL 的原因，有相當一部分其實已由 AppStream 提供。系統監控就是最明顯的例子，因為 Performance Co-Pilot 已在基礎軟體庫中提供，完全不需要第三方軟體庫。每個額外的軟體庫都代表另一個可能在某個星期二向你提供套件的供應方，而且每個軟體庫都會讓下一次主要版本升級更加困難。

如果你仍在兩個發行版之間做選擇，兩者的整體配置方式相同，epel-release 的行為也完全一致。真正的差異在其他地方：Rocky Linux 與 AlmaLinux 的比較涵蓋重建方式，因為 AlmaLinux 現在以 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 是 powertools，不是 crb。

在 production server 上啟用 EPEL 是否安全？

EPEL 使用廣泛，並採用套件不取代 base distribution 套件的政策，因此啟用 EPEL 不會改變 BaseOS 或 AppStream 提供的內容。但支援範圍需要注意：EPEL 是由志願者維護的 Fedora 專案，不提供服務水準協議，且維護者對單一套件的承諾可能只有一個 RHEL minor release 或 13 個月。使用 dnf repository-packages epel list installed 維護套件清單，任何面向客戶的服務若依賴 EPEL 套件，請使用 dnf versionlock。

為什麼 dnf 顯示 no such command: config-manager？

因為 config-manager 是 dnf plugin，不是內建命令，而 minimal 或 container image 通常未包含 dnf-plugins-core。訊息本身已提供修正方式：sudo dnf install -y 'dnf-command(config-manager)'；這裡加上引號，是為了避免 shell 解讀括號。如果目前還無法安裝任何套件，請執行 grep -rl crb /etc/yum.repos.d/，開啟它指定的檔案，然後在 [crb] 區段中手動設定 enabled=1。

CRB 和 PowerTools 有何差異？

它們是同一個儲存庫的兩個名稱。版本 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 可在單一 transaction 中清除整組套件；確認前請仔細閱讀預定移除的清單。

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