Rocky Linux 및 AlmaLinux 패키지 설치 오류 해결 방법

dnf가 원하는 패키지를 찾지 못하는 이유

EPEL과 CRB는 새로 설치한 Rocky Linux나 AlmaLinux 서버에서 기본적으로 제공하지 않는 두 가지 저장소입니다. 이것이 바로 새 서버에서 dnf install htop를 실행했을 때 No match for argument: htop이라는 응답이 나오고, 이어서 Error: Unable to find a match: htop이 발생하는 이유입니다. 시스템이 고장 난 것도 아니며 미러 서버가 다운된 것도 아닙니다. 기본 배포판은 의도적으로 적은 수의 패키지만 포함하며, CRB는 존재하지만 비활성화되어 있고, EPEL은 사용자가 직접 추가해야 하는 별도의 커뮤니티 저장소입니다.

Ubuntu에서는 동일한 패키지가 universe에 포함되어 있으며, 거의 모든 클라우드 이미지에서 universe이 활성화되어 있기 때문에 이러한 문제가 발생하지 않습니다. Red Hat 계열은 패키지를 다르게 분류하며 기본적으로 더 적은 패키지를 제공합니다. 해결 방법은 세 가지 명령어를 실행하는 것입니다. 이 가이드의 나머지 부분은 입문 단계에서 아무도 알려주지 않는 내용으로, 각 저장소가 보장하는 것과 보장하지 않는 것, 그리고 제3자 저장소가 사용자의 기본 시스템을 임의로 점유하지 못하게 막는 방법을 다룹니다.

이 명령어들을 확인한 방법입니다. 테스트 컨테이너는 Ubuntu 환경에서만 실행되므로, 아래의 dnf 명령어들은 저희 테스트 머신에서 직접 실행되지 않았습니다. 이 명령어들은 Rocky Linux 및 AlmaLinux 공식 문서를 따릅니다. 각 단계마다 예상되는 출력 결과가 명시되어 있으므로, 전체 블록을 한꺼번에 복사해 붙여넣기보다는 서버에서 각 단계를 하나씩 확인하십시오.

BaseOS, AppStream, CRB란 무엇인가?

BaseOS는 운영체제 그 자체입니다. 커널, glibc, systemd, 핵심 사용자 공간(userland)으로 구성됩니다. 이 저장소의 버전은 메인 릴리스 수명 동안 고정되며, 보안 패치는 고정된 버전에 백포트(backport)됩니다. BaseOS에서 수년 전의 버전 번호가 보인다고 해서 패치되지 않은 패키지가 아닙니다. 이는 패치가 적용된 구버전이며, 이것이 바로 엔터프라이즈 배포판의 핵심 목적입니다.

AppStream은 그 위에서 실행하는 소프트웨어를 담고 있습니다. 웹 서버, 데이터베이스, 언어 런타임, 편집기, 모니터링 에이전트 등이 포함됩니다. 버전 8에서는 AppStream의 상당 부분이 대체 스트림을 가진 모듈 형태로 제공되었으므로 dnf module list가 중요했으며, 예를 들어 PHP 스트림 중 하나를 선택해야 했습니다. 버전 9에서는 모듈화가 거의 사라졌으므로, Rocky 9이나 Alma 9에서는 일반적으로 한 가지 버전만 제공되며 먼저 활성화해야 할 모듈도 없습니다.

Extras는 기본적으로 활성화되어 있으며 규모가 매우 작습니다. 주로 다른 저장소를 위한 릴리스 패키지를 담고 있으며, epel-release 자체가 여기서 제공됩니다. 이러한 세부 사항 덕분에 Rocky나 Alma에 EPEL을 설치할 때 출처를 알 수 없는 URL을 신뢰할 필요가 없습니다.

CRB는 CodeReady Builder 저장소로, 버전 8에서는 PowerTools라고 불렸습니다. 이 저장소는 배포판의 빌드 측면을 담당하며, 개발 헤더, 정적 라이브러리, 패키지 빌드 시 필요한 테스트 및 문서화 도구를 포함합니다. 이미 미러 서버에 존재하지만 기본적으로는 비활성화되어 있습니다. 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에 존재하는 패키지를 현재의 엔터프라이즈 릴리스용으로 재빌드한 것입니다. EPEL Special Interest Group이 유지보수를 담당하며, 이 그룹은 대부분 Fedora 커뮤니티의 자원봉사자로 구성됩니다. Red Hat은 빌드 및 미러 인프라를 호스팅하며, 일부 Red Hat 엔지니어가 패키지 유지보수에 참여하기도 합니다. 관계는 딱 여기까지입니다. EPEL은 Red Hat 제품이 아닙니다. EPEL 패키지에는 RHEL이나 RHEL 재빌드 배포판을 막론하고 지원 계약이나 SLA(서비스 수준 협약)가 제공되지 않습니다.

EPEL을 안심하고 활성화할 수 있는 이유는 단 하나의 정책 덕분입니다. EPEL 패키지는 기본 배포판의 패키지를 절대 대체하지 않습니다. AppStream이 nginx을 제공한다면, EPEL은 이를 제공하지 않습니다. 이 규칙은 EPEL 패키지를 검토하는 사람들에 의해 강제되므로, 오직 EPEL에 대해서만 보장되는 약속입니다. 따라서 나중에 추가하는 다른 요소들로부터는 보호받지 못합니다.

수명에 대한 약속 또한 기본 배포판과 다르며, 이는 3년 차에 문제가 되곤 합니다. BaseOS 패키지 버전은 메이저 릴리스의 10년 수명 동안 고정됩니다. 반면 EPEL 유지보수자는 훨씬 짧은 기간, 즉 최소한 RHEL 마이너 릴리스 1회 또는 13개월 중 더 짧은 기간 동안만 유지보수를 약속합니다. 실제로는 대부분의 패키지가 그보다 훨씬 오래 유지보수됩니다. 일부는 유지보수자가 떠나면 은퇴하며, 일부는 Fedora를 따르기 때문에 배포판 수명 중간에 새로운 메이저 버전으로 판올림되기도 합니다. 따라서 일상적인 dnf upgrade 작업 중에 안정적이라고 생각했던 서버에서 EPEL 도구의 새로운 메이저 버전이 설치될 수 있으며, 의존하고 있던 패키지가 아무런 예고 없이 업데이트를 중단할 수도 있습니다.

활성화하기 전에 알아두어야 할 또 다른 결과가 있습니다. 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 --enabled

이제 dnf repolist --enabled 명령을 실행하면 baseos, appstream, extras, crb 및 epel이 목록에 나타나야 합니다. epel-release가 추가하는 작은 epel-cisco-openh264 항목도 보일 수 있습니다. 만약 해당 목록에 crb이 없다면 활성화 단계가 적용되지 않은 것이며, 다음 섹션에서 그 이유를 설명합니다.

Rocky 8 및 Alma 8에서는 저장소 이름이 여전히 PowerTools이므로 중간 명령은 sudo dnf config-manager --set-enabled powertools이 됩니다. 저장소 ID는 대소문자를 구분하며, 이전 CentOS 8 문서에서는 대문자를 사용한 PowerTools로 표기되어 있으나 이는 일치하지 않습니다. AlmaLinux 10의 경우 10.0 버전부터(2025년 9월 변경) CRB 저장소가 기본적으로 활성화되어 있으므로 epel-release 단계만 수행하면 됩니다.

epel-release는 이미 활성화된 extras에서 제공되므로, 신뢰할 URL이나 수동으로 가져올 키는 없습니다. 패키지는 /etc/yum.repos.d/epel.repo을 작성하고 /etc/pki/rpm-gpg/ 경로에 EPEL 서명 키를 설치합니다. 해당 파일에서 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를 활성화해야 설치됩니다

두 번째로 흔한 함정은 오류 메시지에 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가 해당 라이브러리를 제공하는 유일한 저장소를 찾지 못하기 때문에 발생합니다. 다음 두 가지를 순서대로 확인하십시오.

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 명령어 대응표를 첫 달 동안 다른 탭에 띄워두는 것이 좋습니다. 플래그는 다르더라도 개념은 명확하게 대응되기 때문입니다.

서드 파티 저장소가 기본 패키지를 대체하지 못하게 하려면 어떻게 해야 합니까?

EPEL은 이를 방지하겠다고 약속하지만, 다른 저장소는 그렇지 않습니다. 데이터베이스, 에이전트, 언어 런타임을 위한 벤더 저장소는 BaseOS가 제공하는 라이브러리의 자체 빌드 버전을 배포할 수 있습니다. dnf의 기본 규칙은 출처와 상관없이 가장 높은 버전이 우선한다는 것이므로, dnf는 이를 설치하게 됩니다.

두 가지 설정이 대부분의 문제를 해결하며, 두 설정 모두 /etc/yum.repos.d/ 아래의 저장소 파일에 위치합니다.

priority=은 동일한 패키지 이름을 가진 저장소가 여러 개일 때 어떤 저장소를 우선할지 결정합니다. 숫자가 낮을수록 우선순위가 높으며 기본값은 99입니다. 따라서 기본 저장소에는 낮은 숫자를, 서드 파티 저장소에는 높은 숫자를 부여하십시오. 이렇게 하면 서드 파티 버전이 더 최신이더라도 dnf는 기본 패키지를 선택합니다. 최신 dnf는 이를 자체적으로 처리하므로, CentOS 7 시절의 별도 yum-plugin-priorities 패키지는 더 이상 해결책이 아닙니다.

includepkgs=는 더 강력한 필터 옵션입니다. excludepkgs=은 특정 저장소에서 지정된 패키지를 차단하는데, 이는 해당 저장소가 무엇을 배포할지 예측해야 한다는 단점이 있습니다. includepkgs=은 이를 반전시킵니다. 즉, 해당 저장소는 지정된 패키지만 제공할 수 있고 그 외에는 아무것도 제공하지 못하게 합니다. 자체 에이전트만 제공해야 하는 벤더 저장소라면 한 줄의 설정으로 해결됩니다.

[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

버전 8에는 알아두어야 할 설정이 하나 더 있습니다. 서드 파티 저장소의 패키지는 AppStream 모듈이 동일한 이름을 제공할 때 숨겨질 수 있으며, 해당 저장소 섹션의 module_hotfixes=1 설정은 dnf가 이를 필터링하지 않도록 지시합니다. 패키지가 dnf repoquery에서는 보이지만 버전 8 시스템에서 설치되지 않는다면, 대개 이 설정이 원인입니다. 버전 9에서는 거의 모든 모듈이 제거되었으므로 이 문제가 발생하는 경우는 드뭅니다.

특정 패키지를 특정 버전으로 고정하려면 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은 서로 패키지가 설치될 정도로 유사하지만, 그 결과물은 누구도 기술 지원을 할 수 없는 상태가 될 만큼 차이가 납니다.

이 문제의 핵심은 버전 번호입니다. 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가 되며, 하나의 파일에 각각 고유한 ID를 가진 여러 [sections]을 포함할 수 있습니다.
• 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은 기본 저장소에 포함되어 제공되므로 타사 소프트웨어가 전혀 필요하지 않습니다. 저장소를 하나 추가할 때마다 화요일에 패키지를 배포할 수 있는 제3자가 하나 늘어나는 셈이며, 이는 향후 메이저 업그레이드를 더욱 어렵게 만듭니다.

두 배포판 사이에서 고민 중이라면, 전체적인 구성은 양쪽 모두 동일하며 epel-release도 똑같이 동작합니다. 실제 차이점은 다른 곳에 있습니다. Rocky Linux와 AlmaLinux 비교 문서를 보면 재빌드 철학을 확인할 수 있는데, AlmaLinux는 이제 코드 한 줄까지 똑같은 재빌드가 아닌 ABI(애플리케이션 바이너리 인터페이스) 호환성을 목표로 하기 때문입니다.

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를 활성화하십시오. 버전 8에서는 저장소 ID가 crb이 아니라 powertools입니다.

운영 서버에서 EPEL을 활성화해도 안전합니까?

EPEL은 널리 사용되며, EPEL 패키지는 기본 배포판의 패키지를 대체하지 않는다는 원칙에 따라 빌드되므로 활성화해도 BaseOS나 AppStream이 제공하는 패키지에는 영향을 주지 않습니다. 주의할 점은 지원 여부입니다. EPEL은 서비스 수준 협약(SLA)이 없는 자원봉사자 기반의 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의 차이점은 무엇입니까?

두 이름은 같은 저장소를 가리킵니다. 버전 8에서는 ID powertools을 사용하는 PowerTools라고 부르며, 버전 9 이상에서는 ID crb을 사용하는 CRB라고 부릅니다. Red Hat 제품에서는 이를 CodeReady Linux Builder라고 지칭합니다. 여기에는 개발 헤더, 정적 라이브러리, 빌드 도구가 포함되어 있으며, Rocky Linux와 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를 통해 한 번에 정리할 수 있습니다. 실행 전 제안된 목록을 주의 깊게 확인하십시오.