가이드

작성자 Matt Connor 2026-10-11

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

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에서만 제공하는 라이브러리에 의존하기 때문입니다. 버전 8에서는 저장소 ID가 crb가 아니라 powertools입니다.

Q: dnf에서 왜 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을 직접 설정하십시오.

Q: 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를 확인하십시오.

Q: 시스템에 문제를 일으키지 않고 EPEL을 제거하려면 어떻게 해야 합니까?

EPEL에서 설치된 패키지는 epel-release 패키지만 제거한다고 해서 함께 삭제되지 않으므로, 먼저 dnf repository-packages epel list installed으로 설치 목록을 확인하십시오. 제거하지 않은 패키지는 디스크에 그대로 남으며, 업데이트 소스를 잃게 되어 보안 패치를 받을 수 없게 되지만 별도의 오류 메시지는 표시되지 않습니다. 패키지별로 필요 여부를 결정하여 제거하거나 대체한 뒤에 sudo dnf remove epel-release을 실행하십시오. EPEL에서 설치한 패키지를 한 번에 모두 제거해야 한다면 sudo dnf repository-packages epel remove를 사용하여 일괄 삭제할 수 있으므로, 확인하기 전에 제안된 목록을 주의 깊게 검토하십시오.

dnf install 명령어 실행 시 No match for argument 오류가 발생하는 원인을 설명합니다. BaseOS, AppStream, CRB 저장소의 차이를 이해하고 EPEL 저장소를 안전하게 추가하여 패키지 설치 문제를 해결하는 방법을 안내합니다.

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)되지만, 마이너 릴리스에서 핵심 구성 요소가 최신 업스트림 버전으로 리베이스(rebase)되는 경우도 있습니다(예: AlmaLinux 9.2는 SELinux 사용자 공간 패키지를 3.5 버전으로 업데이트했습니다). BaseOS에서 수년 전의 버전 번호를 보더라도 패치가 적용되지 않은 패키지가 아닙니다. 이는 엔터프라이즈 배포판의 핵심 목적인, 패치가 적용된 구버전입니다.

AppStream은 웹 서버, 데이터베이스, 언어 런타임, 편집기, 모니터링 에이전트 등 그 위에서 실행하는 소프트웨어를 담고 있습니다. 버전 8에서는 AppStream의 상당 부분이 대체 스트림을 가진 모듈 형태로 제공되었으므로 dnf module list가 중요했으며, 예를 들어 하나의 PHP 스트림을 선택해야 했습니다. 버전 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라고 불렸습니다. 여기에는 개발용 헤더, 정적 라이브러리, 패키지 빌드 시 필요한 테스트 및 문서화 도구 등 배포판의 빌드 측면을 담당하는 요소들이 포함되어 있습니다. 이 저장소는 미러 서버에 이미 존재하지만 기본적으로 비활성화되어 있습니다. 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 유지 관리자는 훨씬 짧은 기간을 약속합니다. EPEL 릴리스 기반 패키지 수명 제안서에 따르면, 최소 한 번의 RHEL 마이너 릴리스 기간 또는 13개월 중 짧은 쪽을 따릅니다. 실제로는 대부분의 패키지가 그보다 훨씬 오래 유지 관리됩니다. 유지 관리자가 활동을 중단하면 패키지가 폐기되기도 하고, EPEL은 Fedora를 따르기 때문에 배포판 수명 중간에 메이저 버전이 변경되기도 합니다. 따라서 일상적인 dnf upgrade 작업 중에 안정적이라고 생각했던 서버의 EPEL 도구가 새로운 메이저 버전으로 업데이트될 수 있으며, 의존 중인 패키지가 별도의 공지 없이 업데이트를 중단할 수도 있습니다. 또한 새로운 버전은 이미 실행 중인 서비스에 즉시 적용되지 않으므로, 트랜잭션 완료 후 어떤 프로세스가 여전히 이전 바이너리를 사용 중인지 확인하려면 needs-restarting을 사용해야 합니다.

활성화하기 전에 알아두어야 할 또 다른 결과가 있습니다. 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-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 명령에서 보이지 않게 만듭니다. 버전 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은 서로 패키지가 설치될 정도로 가깝지만, 그 결과로 만들어진 시스템은 누구도 기술 지원을 할 수 없을 만큼 멀어져 있습니다. 이들이 왜 그렇게 가까운지, 그리고 왜 특히 Stream이 RHEL의 옆이 아닌 앞단에 위치하게 되었는지는 Red Hat Linux가 Fedora와 RHEL로 분리된 과정과 CentOS의 변화에서 확인할 수 있습니다.

핵심 기제는 버전 번호입니다. CentOS Stream 9은 RHEL 9보다 앞서 나가며, Red Hat은 Stream 코드를 차기 RHEL 마이너 릴리스가 될 코드라고 설명합니다. 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은 널리 사용되며, 기본 배포판의 패키지를 대체하지 않는다는 원칙에 따라 빌드되므로 활성화해도 BaseOS나 AppStream에서 제공하는 패키지에는 영향을 주지 않습니다. 주의할 점은 지원 여부입니다. EPEL은 서비스 수준 협약(SLA)이 없는 자원봉사자 기반의 Fedora 프로젝트이며, 패키지 유지 관리 정책에 따라 관리자는 RHEL 마이너 릴리스 1회 또는 13개월 동안만 패키지를 유지할 수 있습니다. dnf repository-packages epel list installed로 설치된 패키지 목록을 관리하고, 고객 대상 서비스가 의존하는 EPEL 패키지에는 dnf versionlock을 사용하십시오.

dnf에서 왜 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에서 설치된 패키지는 epel-release 패키지만 제거한다고 해서 함께 삭제되지 않으므로, 먼저 dnf repository-packages epel list installed으로 설치 목록을 확인하십시오. 제거하지 않은 패키지는 디스크에 그대로 남으며, 업데이트 소스를 잃게 되어 보안 패치를 받을 수 없게 되지만 별도의 오류 메시지는 표시되지 않습니다. 패키지별로 필요 여부를 결정하여 제거하거나 대체한 뒤에 sudo dnf remove epel-release을 실행하십시오. EPEL에서 설치한 패키지를 한 번에 모두 제거해야 한다면 sudo dnf repository-packages epel remove를 사용하여 일괄 삭제할 수 있으므로, 확인하기 전에 제안된 목록을 주의 깊게 검토하십시오.

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