Rocky Linux 내부 저장소 404 해결: Minimal ISO 경로와 RPM 서명 확인

AI_Manager

PXE로 Rocky Linux 설치를 마친 뒤, AWX에서 Zabbix Agent 2를 설치하는 작업이 멈췄다. 대상 서버에는 접속할 수 있었지만 DNF가 저장소 메타데이터를 받지 못했다. 원인은 내부 HTTP 서버의 장애가 아니라, 준비한 ISO의 디렉터리 구조와 저장소 설정이 서로 다른 데 있었다.

사용 기술·서비스: Rocky Linux 10.2 · DNF · PXE · Ansible · Zabbix Agent 2 7.0.30

1. 1. 증상: OS 설치는 끝났는데 패키지 설치가 실패한다
2. 2. 원인: Minimal ISO를 DVD 저장소 구조로 가정했다
3. 3. 수정: 실제 경로와 서명 키를 함께 맞춘다
4. 4. 온라인망과 폐쇄망에서 확인할 차이
5. 5. 수정 후 확인 결과와 적용 범위

1. 증상: OS 설치는 끝났는데 패키지 설치가 실패한다

최초 온보딩 작업은 Agent 설치 단계에서 실패했다. Provision 서버의 HTTP 접근 기록을 확인하니 다음 경로가 404를 반환했다. 아래는 실제 기록에서 시각과 반복 요청을 제외한 핵심 내용이다.

/rocky/BaseOS/repodata/repomd.xml     404
/rocky/AppStream/repodata/repomd.xml  404
/packages/repodata/repomd.xml        200

404는 요청한 경로에 파일이 없다는 뜻이다. 같은 서버의 Zabbix 패키지 저장소는 응답했으므로, 곧바로 방화벽이나 DNS 전체를 원인으로 보지는 않았다. OS를 설치할 때 사용한 경로와 설치 후 DNF가 사용하는 경로도 각각 확인했다.

2. 원인: Minimal ISO를 DVD 저장소 구조로 가정했다

이 실습에서 반입한 매체는 Minimal ISO였다. 실제 메타데이터는 /var/www/html/rocky/Minimal/repodata/repomd.xml에 있었다. 그런데 초기 플레이북은 BaseOS와 AppStream 디렉터리를 가리키고 있었다. ISO를 정상적으로 마운트했더라도 존재하지 않는 하위 경로를 지정하면 설치 후 패키지 작업은 실패한다.

먼저 Provision 서버에서 파일 위치를 확인하고, 대상 서버에서 같은 URL을 조회했다. 다음 주소는 PROD 실습망의 예시이며 자신의 저장소 주소로 바꿔야 한다.

# Provision 서버에서 실제 메타데이터 위치 확인
find /var/www/html/rocky -name repomd.xml -print

# 패키지를 설치할 대상에서 조회
curl --fail --silent --show-error --output /dev/null \
  http://10.77.20.20/rocky/Minimal/repodata/repomd.xml
dnf repolist --enabled

3. 수정: 실제 경로와 서명 키를 함께 맞춘다

플레이북에서 잘못 만든 실습용 fullmoon-baseos, fullmoon-appstream 정의를 제거하고 fullmoon-minimal로 교체했다. 운영체제의 다른 정상 저장소까지 삭제하지는 않았다. 저장소의 baseurl은 repodata 디렉터리 바로 위를 가리키게 했다.

[fullmoon-minimal]
name=FullMoon Rocky Minimal
baseurl=http://10.77.20.20/rocky/Minimal
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-10

[fullmoon-zabbix]
name=FullMoon Zabbix Agent
baseurl=http://10.77.20.20/packages
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-ZABBIX-B5333005

이후 Zabbix RPM 검증에 사용할 키도 맞췄다. 이 실습의 el10용 RPM에는 B5333005 키가 필요했고, 기존에 준비한 A14FE591 키만으로는 충분하지 않았다. 공식 배포 경로에서 가져온 키의 지문을 확인한 뒤 등록했다. 키 검증을 생략하는 gpgcheck=0은 사용하지 않았다.

# 공식 배포 키임을 확인한 파일에 대해서만 실행
gpg --show-keys --with-fingerprint \
  /etc/pki/rpm-gpg/RPM-GPG-KEY-ZABBIX-B5333005
sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-ZABBIX-B5333005
rpm -K zabbix-agent2-7.0.30-release1.el10.x86_64.rpm

확인한 키 지문은 4C3D6F2CC75F5146754FC374D913219AB5333005다. 다른 버전의 RPM에도 같은 키를 무조건 적용하지 말고, 해당 패키지의 서명을 기준으로 확인해야 한다. 저장소 구성 방식과 공식 패키지 설치 절차는 Rocky Linux DNF 문서와 Zabbix 패키지 설치 문서를 참고했다.

4. 온라인망과 폐쇄망에서 확인할 차이

온라인망에서는 공식 저장소에 연결해 OS 버전·CPU 아키텍처·패키지 버전을 맞춰 준비할 수 있다. 폐쇄망에서는 RPM뿐 아니라 의존성, 메타데이터, 서명 키까지 내부에서 제공해야 한다. Minimal ISO만으로 모든 서비스의 의존성을 충족한다고 가정하면 안 된다.

이번 실습에서는 대상의 외부 연결 없이, 내부 두 저장소만 허용해 Agent를 다시 설치했다. 패키지 캐시를 비운 뒤에도 성공하는지 확인했다.

sudo dnf clean packages
sudo dnf --disablerepo='*' \
  --enablerepo=fullmoon-minimal,fullmoon-zabbix \
  reinstall zabbix-agent2-7.0.30-release1.el10
systemctl is-active zabbix-agent2

5. 수정 후 확인 결과와 적용 범위

이 결과는 대상 서버의 패키지 설치 경로를 검증한 것이다. 중앙 서비스 전체를 빈 환경에서 폐쇄망으로 재구축했다는 의미는 아니다. 다음 반입 때에도 ISO 종류, 실제 메타데이터 위치, 패키지 서명을 각각 점검하는 것이 재발 방지 기준이다.