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

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

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

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

이 명령어들을 확인한 방법. 저희의 명령어 테스트 컨테이너는 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에 존재하는 패키지를 현재 엔터프라이즈 릴리스용으로 다시 빌드한 것입니다. 이 패키지들은 주로 Fedora 커뮤니티의 자원봉사자들로 구성된 EPEL 특별 관심 그룹(Special Interest Group)이 유지 관리합니다. Red Hat은 빌드 및 미러 인프라를 호스팅하며, 일부 Red Hat 엔지니어들이 패키지 유지 관리에 참여하기도 합니다. 관계는 딱 여기까지입니다. EPEL은 Red Hat 제품이 아닙니다. EPEL 패키지에 대해서는 RHEL이나 RHEL 기반 재배포판을 막론하고 지원 계약이나 SLA(서비스 수준 협약)가 제공되지 않습니다.

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

수명에 대한 약속 또한 기본 배포판과 다르며, 이는 3년 차에 접어들 때 문제가 되곤 합니다. BaseOS 패키지 버전은 메이저 릴리스의 10년 수명 동안 고정됩니다. 반면 EPEL 유지 관리자는 훨씬 짧은 기간, 즉 최소 한 번의 RHEL 마이너 릴리스 또는 13개월 중 더 짧은 기간 동안만 유지 보수를 약속합니다. 실제로는 대부분의 패키지가 그보다 훨씬 오래 유지 관리됩니다. 하지만 유지 관리자가 활동을 중단하면 패키지가 폐기되기도 하고, EPEL은 Fedora를 따르기 때문에 배포판 수명 중간에 새로운 메이저 버전으로 판올림되기도 합니다. 따라서 일상적인 dnf upgrade 작업 중에 안정적이라고 생각했던 서버의 EPEL 도구가 새로운 메이저 버전으로 업데이트될 수 있으며, 의존하던 패키지가 별도의 공지 없이 업데이트 중단 상태가 될 수도 있습니다. 또한 새로운 버전은 이미 실행 중인 서비스에 즉시 적용되지 않으므로, 트랜잭션 완료 후 어떤 프로세스가 여전히 이전 바이너리를 사용 중인지 확인하려면 needs-restarting을 사용해야 합니다.

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)'

dnf install 명령은 실패하는데 두 번째 명령에서 패키지 이름이 확인된다면 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이 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로 대체되며, 하나의 파일에 각각 고유한 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는 이제 1:1 재빌드보다는 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을 제거하려면 어떻게 해야 합니까?

epel-release 패키지만 제거한다고 해서 EPEL에서 설치한 패키지들이 함께 삭제되지는 않으므로, 먼저 dnf repository-packages epel list installed로 설치된 패키지 목록을 확인하십시오. EPEL 패키지를 그대로 두면 디스크에 남은 상태로 업데이트 경로가 끊기며, 오류 메시지 없이 보안 패치를 받지 못하게 됩니다. 패키지별로 필요 여부를 결정하여 삭제하거나 대체한 뒤, 마지막에 sudo dnf remove epel-release을 실행하십시오. EPEL에서 설치한 패키지를 모두 삭제해야 한다면 sudo dnf repository-packages epel remove를 통해 한 번에 처리할 수 있으나, 확인하기 전에 제안된 패키지 목록을 주의 깊게 읽어보십시오.