EL 8 계열에서 버전을 동결한 서버가 하나 있는데 주 저장소는 vault에 고정 트리가 있어서 문제가 없었지만 epel이 걸렸다. 이것도 같은 마이너 8.6으로 고정할 수 있는지를 확인해야 했다.
Table of contents
Open Table of contents
원인 — 고정 트리의 부재
있겠거니 하지 않고 curl로 dl.fedoraproject.org/pub/epel/ 디렉터리 목록을 직접 조회했다. 8/ 만 있고 마이너 디렉터리가 아예 없었으며 8.6/ 주소를 찍어 보니 404가 돌아왔다.
활성 저장소가 단일 롤링 트리라서 고정 트리 자체가 존재하지 않는 구조였다. EPEL 정책 공식 문서도 EOL 된 저장소만 아카이브로 옮겨 MirrorManager 가 거기서 내보낸다고 적고 있다. 이 확인을 건너뛰고 설정만 고쳤다면 존재하지 않는 주소를 박고 나중에 갱신이 깨졌을 것이다.
문제 — 아카이브의 결번
동결된 스냅샷은 아카이브 쪽에 있어서 archives.fedoraproject.org/pub/archive/epel/ 목록을 다시 조회했다. 8.1부터 8.9까지 나열돼 있는데 정작 필요한 8.6이 결번이었고 앞뒤 8.5와 8.7은 있었다.
왜 없는지는 알 수 없었다. 두 가지 방법이 있었는데 뒤 스냅샷 8.7을 쓰는 것과 앞 스냅샷 8.5를 쓰는 것이다. 뒤쪽을 골랐다. 이유는 8.5가 대상 OS 출시 시점과 날짜가 거의 같고 8.7은 더 새로운 패키지가 들어 있어 동결의 목적에 맞지 않아서다. 대신 8.6에 들어왔을 패키지 갱신을 못 받는 것을 감수했다.
조치 — 메타링크를 뺀 설정
/etc/yum.repos.d/epel.repo의 기본 설정은 미러 목록을 매번 받아 오는 metalink= 방식이라 그 자체가 롤링이었다. 그것을 주석 처리하고 baseurl=에 아카이브 주소를 직접 박았다.
[epel]
baseurl=https://archives.fedoraproject.org/pub/archive/epel/8.5/Everything/x86_64/
#metalink=...
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8gpgkey는 기존 것을 그대로 뒀는데 아카이브도 같은 키로 서명돼 있기 때문이다. 동결에서 바꿀 것은 어디를 보는지이지 무엇으로 검증하는지가 아니다.
원칙과 상시 활성화
이 서버에는 동결 박스에 롤링 저장소를 두지 않는다는 원칙이 있었다. 그래서 지금까지는 부가 저장소를 꺼 두고 필요할 때만 임시로 켜서 썼다.
번거롭기도 하고 임시로 켠 사이에 다른 패키지가 딸려 올라올 위험도 있었다. 동결하고 나니 상시 켜 둘 수 있게 되면서 그 번거로움과 드리프트 위험이 함께 사라졌고 원칙도 그대로 유지됐다.
검증 — 주소와 패키지
주소를 박아 놓고 끝내지 않고 두 가지를 각각 확인했다. 하나는 그 주소가 유효한 저장소인지이고 repodata/repomd.xml을 curl -I로 요청해 200이 오는 것을 봤다.
다른 하나는 이 서버에 깔린 패키지가 그 트리에 있는지였다. dnf list installed에서 @epel 출처인 패키지가 둘 있었는데 둘 다 그 트리에서 정확히 매칭됐으므로 스냅샷을 바꿔도 지금 설치된 것과 어긋나지 않는다. 주소가 200이라는 것과 내 패키지가 거기 있다는 것은 다른 확인이고 앞쪽만 하면 갱신 시점에 없는 패키지가 드러난다.
같은 방법을 다른 EOL 버전에도 쓸 수 있는데 조건이 하나 있다. 아카이브에 그 마이너가 있는지 먼저 확인하고 이번처럼 결번이면 가장 가까운 것을 고른 뒤 그 선택 이유를 기록에 남긴다.
정리
- 부가 저장소에 마이너 고정 트리가 없을 수 있으니 조회한다
- 아카이브에 특정 마이너가 결번일 수 있다
- 없으면 가장 가까운 동결 스냅샷을 고르고 그 선택을 기록한다
metalink를 빼고baseurl에 아카이브 주소를 박으면 롤링 저장소도 동결된다gpgkey는 기존 것을 그대로 쓴다- 동결하면 상시 켜 둘 수 있어 임시 활성화의 번거로움이 사라진다
repomd.xml이 200인지와 내 패키지가 그 트리에 있는지를 둘 다 본다- 선택 이유를 안 적으면 다음 사람이 그 숫자를 다시 조사한다