[Redhat] 다운 받은 패키지 YUM REPOSITORY 구성

 CVE 보안 패치용 RPM 패키지를 이용해 로컬 YUM 리포지토리를 구성하고, 여러 시스템에 손쉽게 업데이트하는 방법을 단계별로 설명합니다.


로컬 YUM 리포지토리를 구성하는 이유

보안 패치나 특정 패키지를 설치할 때 RPM 파일을 수동으로 다운로드한 후 yum localinstall 명령어로 설치할 수도 있지만, 의존성 문제를 해결하거나 여러 서버에 반복 배포할 경우 비효율적일 수 있습니다. YUM 리포지토리를 구성하면 패키지 관리가 자동화되어 설치와 업데이트가 훨씬 안정적으로 수행됩니다.

이번 글에서는 보안 취약점(CVE-2024-1086) 대응을 위해 준비된 18개의 패키지를 기반으로 로컬 YUM 리포지토리를 구성하고, 이를 통해 시스템에 커널 패치를 적용하는 과정을 설명합니다. CD 이미지를 이용한 방식이 아닌, 개별 패키지 기반 리포지토리 구성법입니다.


 만약 CD 이미지를 local repo로 구성하는 방법을 원하시면 LOCAL REPO를 참조하실 수 있습니다.

 


패키지 준비 및 메타데이터 생성

먼저 설치 대상인 RPM 파일들을 한 디렉터리에 모읍니다. 예제에서는 /root/cve-2024-1086 디렉터리에 커널 및 관련 패키지 18개를 준비했습니다. 이들은 모두 동일한 보안 패치 버전(4.18.0-513.24.1.el8_9)을 기반으로 합니다.

[root@rhel8 cve-2024-1086]# pwd
/root/cve-2024-1086

[root@rhel8 cve-2024-1086]# ls
bpftool-4.18.0-513.24.1.el8_9.x86_64.rpm
bpftool-debuginfo-4.18.0-513.24.1.el8_9.x86_64.rpm
kernel-4.18.0-513.24.1.el8_9.x86_64.rpm
kernel-abi-stablelists-4.18.0-513.24.1.el8_9.noarch.rpm
kernel-core-4.18.0-513.24.1.el8_9.x86_64.rpm
kernel-cross-headers-4.18.0-513.24.1.el8_9.x86_64.rpm
kernel-devel-4.18.0-513.24.1.el8_9.x86_64.rpm
kernel-doc-4.18.0-513.24.1.el8_9.noarch.rpm
kernel-headers-4.18.0-513.24.1.el8_9.x86_64.rpm
kernel-modules-4.18.0-513.24.1.el8_9.x86_64.rpm
kernel-modules-extra-4.18.0-513.24.1.el8_9.x86_64.rpm
kernel-tools-4.18.0-513.24.1.el8_9.x86_64.rpm
kernel-tools-debuginfo-4.18.0-513.24.1.el8_9.x86_64.rpm
kernel-tools-libs-4.18.0-513.24.1.el8_9.x86_64.rpm
perf-4.18.0-513.24.1.el8_9.x86_64.rpm
perf-debuginfo-4.18.0-513.24.1.el8_9.x86_64.rpm
python3-perf-4.18.0-513.24.1.el8_9.x86_64.rpm
python3-perf-debuginfo-4.18.0-513.24.1.el8_9.x86_64.rpm


이후 createrepo 패키지를 설치하고, 준비한 디렉터리에서 메타데이터를 생성합니다. 이는 YUM이 패키지 목록과 의존성을 인식할 수 있도록 해주는 핵심 단계입니다.


로컬 레포지토리를 생성하려면 createrepo 패키지가 필요합니다. 아래 명령어를 사용하여 설치합니다.

[root@rhel8 cve-2024-1086]# yum install createrepo -y
...

Installed:
  createrepo_c-0.17.7-6.el8.x86_64        createrepo_c-libs-0.17.7-6.el8.x86_64
  drpm-0.4.1-3.el8.x86_64

Complete!


패키지가 준비된 디렉터리에서 createrepo 명령어를 사용하여 메타데이터를 생성합니다.

[root@rhel8 cve-2024-1086]# createrepo /root/cve-2024-1086
Directory walk started
Directory walk done - 18 packages
Temporary output repo path: /root/cve-2024-1086/.repodata/
Preparing sqlite DBs
Pool started (with 5 workers)
Pool finished

메타데이터 생성 결과 확인

createrepo 명령 실행 후 디렉터리 내부를 확인해 보면 repodata라는 하위 디렉터리가 생성된 것을 볼 수 있습니다. 이 디렉터리에는 패키지 정보를 담은 .xml.gz 및 .sqlite.bz2 파일들이 포함되어 있으며, YUM 클라이언트는 이 정보를 참조하여 패키지를 인식하고 의존성을 해결합니다.

[root@rhel8 cve-2024-1086]# tree
.
├── bpftool-4.18.0-513.24.1.el8_9.x86_64.rpm
├── bpftool-debuginfo-4.18.0-513.24.1.el8_9.x86_64.rpm
├── kernel-4.18.0-513.24.1.el8_9.x86_64.rpm
├── kernel-abi-stablelists-4.18.0-513.24.1.el8_9.noarch.rpm
├── kernel-core-4.18.0-513.24.1.el8_9.x86_64.rpm
├── kernel-cross-headers-4.18.0-513.24.1.el8_9.x86_64.rpm
├── kernel-devel-4.18.0-513.24.1.el8_9.x86_64.rpm
├── kernel-doc-4.18.0-513.24.1.el8_9.noarch.rpm
├── kernel-headers-4.18.0-513.24.1.el8_9.x86_64.rpm
├── kernel-modules-4.18.0-513.24.1.el8_9.x86_64.rpm
├── kernel-modules-extra-4.18.0-513.24.1.el8_9.x86_64.rpm
├── kernel-tools-4.18.0-513.24.1.el8_9.x86_64.rpm
├── kernel-tools-debuginfo-4.18.0-513.24.1.el8_9.x86_64.rpm
├── kernel-tools-libs-4.18.0-513.24.1.el8_9.x86_64.rpm
├── perf-4.18.0-513.24.1.el8_9.x86_64.rpm
├── perf-debuginfo-4.18.0-513.24.1.el8_9.x86_64.rpm
├── python3-perf-4.18.0-513.24.1.el8_9.x86_64.rpm
├── python3-perf-debuginfo-4.18.0-513.24.1.el8_9.x86_64.rpm
└── repodata
    ├── 788d5db18f3d135b023071e10e5f3e6fa7a60ecbc284c4de54b0764f1b6fa878-primary.sqlite.bz2
    ├── a84c3d792399056c5530f29240ce29e813a0aa990351865397e4428ac59503cf-other.xml.gz
    ├── ae68e553964a2a388daf483f582a265dc78469698d7ac70184c1aa3cb3dc7bc0-filelists.xml.gz
    ├── ce8c41910479d5326bd38c50c6d684131199ff463901ec09396ab244406bf370-primary.xml.gz
    ├── d00a4bcc53f246cddc73d31b44d8d1ceb91534c398666789e98f19dff7eaf22b-filelists.sqlite.bz2
    ├── f07daedaf8a444b2d245c3fcbe263b497777731c62e50ed924b14f3281e7a1d7-other.sqlite.bz2
    └── repomd.xml

1 directory, 25 files

메타데이터가 정상적으로 생성되었다면 다음 단계로 이 디렉터리를 YUM 리포지토리로 등록할 수 있습니다.

 

YUM 리포지토리 등록

리포지토리를 등록하기 전 현재 등록된 저장소 목록을 확인해 봅니다. 기본적으로는 AppStream, BaseOS 같은 기본 저장소만 보일 것입니다.

[root@rhel8 yum.repos.d]# yum repolist
...
repo id                                                  repo name
AppStream                                                AppStream
BaseOS                                                   BaseOS
[root@rhel8 yum.repos.d]#

이제 /etc/yum.repos.d/ 디렉터리에 .repo 파일을 생성하여 로컬 리포지토리를 등록합니다.

[root@rhel8 cve-2024-1086]# vim /etc/yum.repos.d/cve-2014-1086.repo
[cve-2024-1086]
name=cve-2024-1086 repo
baseurl=file:///root/cve-2024-1086
enabled=1
gpgcheck=0

등록 후 yum repolist 명령어를 다시 실행하면 새로운 리포지토리가 추가된 것을 확인할 수 있습니다.


리포지토리 등록 결과 확인

.repo 파일을 등록한 뒤 yum repolist를 실행하면, cve-2024-1086이라는 ID의 저장소가 목록에 표시됩니다. 이 저장소는 /root/cve-2024-1086 경로를 기준으로 패키지를 제공합니다.

[root@rhel8 cve-2024-1086]# yum repolist
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use subscription-manager to register.

repo id                                               repo name
AppStream                                             AppStream
BaseOS                                                BaseOS
cve-2024-1086                                         cve-2024-1086 repo

-v 옵션을 이용해 보면 총 18개의 패키지가 cve-2024-1086 레포에서 제공되는 걸 확인할 수 있는데 이는 /root/cve-2024-1086 디렉터리에서 제공하는 패키지 개수와 정확히 일치합니다.

[root@rhel8 cve-2024-1086]# yum repolist -v cve-2024-1086
Loaded plugins: builddep, changelog, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, groups-manager, kpatch, needs-restarting, playground, product-id, repoclosure, repodiff, repograph, repomanage, reposync, subscription-manager, system-upgrade, uploadprofile
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use subscription-manager to register.

YUM version: 4.7.0
cachedir: /var/cache/dnf
Last metadata expiration check: 0:00:11 ago on Mon 17 Jun 2024 11:08:07 AM KST.
Repo-id            : cve-2024-1086
Repo-name          : cve-2024-1086 repo
Repo-status        : enabled
Repo-revision      : 1718589140
Repo-updated       : Mon 17 Jun 2024 10:52:20 AM KST
Repo-pkgs          : 18
Repo-available-pkgs: 18
Repo-size          : 291 M
Repo-baseurl       : file:///root/cve-2024-1086
Repo-expire        : 172,800 second(s) (last: Mon 17 Jun 2024 11:08:07 AM KST)
Repo-filename      : /etc/yum.repos.d/cve-2014-1086.repo
Total packages: 18

 

YUM을 이용한 패키지 업데이트

이제 등록한 리포지토리를 통해 커널 패키지를 업데이트합니다. "kernel-*" 와일드카드를 사용하여 커널 관련 패키지를 한 번에 업데이트할 수 있습니다.

[root@rhel8 ~]# yum update "kernel-*" -y
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use subscription-manager to register.

Last metadata expiration check: 0:02:21 ago on Mon 17 Jun 2024 11:16:25 AM KST.
Dependencies resolved.
=================================================================================================================
 Package                      Architecture      Version                           Repository                Size
=================================================================================================================
Upgrading:
 kernel-headers               x86_64            4.18.0-513.24.1.el8_9             cve-2024-1086             11 M
 kernel-tools                 x86_64            4.18.0-513.24.1.el8_9             cve-2024-1086             10 M
 kernel-tools-libs            x86_64            4.18.0-513.24.1.el8_9             cve-2024-1086             10 M
Installing dependencies:
 kernel-core                  x86_64            4.18.0-513.24.1.el8_9             cve-2024-1086             43 M
 kernel-modules               x86_64            4.18.0-513.24.1.el8_9             cve-2024-1086             36 M
Installing weak dependencies:
 kernel-devel                 x86_64            4.18.0-513.24.1.el8_9             cve-2024-1086             24 M

Transaction Summary
=================================================================================================================
...
Complete!

 이 명령은 kernel-headers, kernel-tools, kernel-core, kernel-modules, kernel-devel 등 관련된 패키지를 자동으로 식별하고 설치합니다. 이때 필요한 의존성도 함께 처리되어 편리하게 패치가 적용됩니다.


업데이트 완료 후 부팅 이미지 확인

업데이트가 완료되면 새 커널 버전에 맞는 initramfs 이미지와 vmlinuz 커널 파일이 /boot 디렉터리에 생성됩니다. 이를 통해 새로운 커널이 실제로 설치되었는지를 확인할 수 있습니다.

[root@rhel8 ~]# ls /boot/ | grep 513
initramfs-4.18.0-513.24.1.el8_9.x86_64.img
vmlinuz-4.18.0-513.24.1.el8_9.x86_64
...

해당 버전이 존재하면, 이제 시스템을 재부팅하여 새 커널을 적용해야 합니다.

[root@rhel8 ~]# reboot



재부팅 후 커널 버전 확인

시스템이 재시작되면 현재 적용된 커널 버전을 확인하여 업데이트가 성공적으로 적용되었는지 검증합니다.

[root@rhel8 ~]# uname -r
4.18.0-513.24.1.el8_9.x86_64

[root@rhel8 ~]# rpm -qa | grep kernel | grep 513
kernel-tools-libs-4.18.0-513.24.1.el8_9.x86_64
kernel-tools-4.18.0-513.24.1.el8_9.x86_64
kernel-modules-4.18.0-513.24.1.el8_9.x86_64
kernel-devel-4.18.0-513.24.1.el8_9.x86_64
kernel-headers-4.18.0-513.24.1.el8_9.x86_64
kernel-core-4.18.0-513.24.1.el8_9.x86_64
설치된 관련 패키지 목록을 확인해 보면, 모두 새 커널 버전에 맞게 반영되어 있는 것을 볼 수 있습니다.

마치며

로컬 YUM 리포지토리를 구성하면, 단순히 개별 패키지를 설치하는 것을 넘어 시스템 전반에 걸쳐 안정적이고 반복 가능한 배포 환경을 마련할 수 있습니다. 특히 보안 취약점(CVE) 대응과 같이 일관된 버전의 패키지를 여러 서버에 적용해야 할 경우, 이 방식은 매우 유용합니다.

물론 로컬 리포지토리를 구성하지 않고도 yum localinstall 명령어로 개별 RPM 파일을 설치할 수 있습니다. 그러나 의존성 문제 해결, 설치 자동화, 관리 효율성을 고려할 때 리포지토리를 구성하는 방법이 장기적으로 더 유리할 수 있습니다. 상황에 맞게 두 방법을 적절히 활용하시는 것을 권장드립니다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

[Linux] RHEL Local YUM Repository 구성

이미지
RHEL(Redhat Enterprise Linux)에 Local YUM Repository 구성하는 방법에 대하여 설명합니다. 레드햇 리눅스 같은 경우 기업환경의 인터넷이 되지 않는 환경에서 사용되는 경우가 많은데 Local YUM Repository를 구성하여 패키지를 쉽게 설치할 수 있습니다.   테스트 환경 • Red Hat Enterprise Linux (RHEL)   Local YUM Repository 구성 목적 Local YUM Repository를 구성하는 방법에 여러 가지가 있지만 가장 간단한 방법인 설치 CD를 이용해 구성하는 방법에 대해 소개합니다. 주로 이 방법은 OS 엔지니어가 RHEL을 설치 후 사용하며, local repo를 서버에 구성한 뒤 철수합니다. 그러면 애플리케이션 측에서 추가 패키지를 요청하여도 서버 관리자분들이 yum 명령어를 사용하여 쉽게 서버에 설치할 수 있습니다.   Local YUM Repository 설정 레드햇 설치 CD에는 기본 RHEL 서브스크립션에서 제공하는 RPM 패키지들이 모두 포함되어 있습니다. 따라서 RHEL을 설치한 버전과 동일한 ISO 파일 이 준비되어 있어야 하며, 이를 통해 로컬 저장소를 구성할 수 있습니다.   VMware Workstation을 기준으로 설명하자면, RHEL ISO 파일을 가상 머신에 마운트 하면 됩니다. ISO 파일이 마운트되면 시스템은 자동으로 /dev/sr0 장치를 생성하게 되며, 이는 udev 에 의해 처리됩니다.   CD가 삽입되면 시스템에서는 /dev/sr0 장치를 자동으로 생성합니다. 이 장치는 **광학 디스크 장치(CD/DVD)**로 인식되며, 이를 확인하는 가장 쉬운 방법은 lsblk 명령어를 사용하는 것입니다. # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 2G 0 disk └─mpatha ...
자세한 내용 보기

[Linux Command] sudo command 설명

이미지
  이번 글에서는 Linux 명령어 중 sudo 명령어에 대해 알아보겠습니다. 일반 사용자에게 "root" 권한을 부여하려면 보통 root 계정의 비밀번호를 제공해야 합니다. 이후 사용자는 su 명령어를 통해 root 계정으로 로그인할 수 있습니다. root 계정은 시스템 내 모든 명령을 실행할 수 있는 강력한 권한을 가지고 있기 때문에, 신중한 관리가 필요합니다. 리눅스에 익숙하지 않은 사용자가 root 권한을 사용할 경우, 시스템 운영에 필요한 핵심 파일이 삭제되거나 권한 설정이 변경되는 등의 사고가 발생할 수 있습니다. sudo 기능을 사용하면 root 전체 권한이 아닌 특정 명령어만 일반 사용자에게 허용할 수 있어 이러한 위험을 줄일 수 있습니다. 또한, 사용 권한은 부여하되 root 비밀번호를 공개하지 않아도 된다는 점도 sudo 의 중요한 장점 중 하나입니다.   환경 : Red Hat Enterprise Linux (RHEL)   sudo command 개념 명령어 사용법을 보기 전에, sudo 명령어로 어떤 작업이 가능한지 먼저 알아보겠습니다. 일반 사용자가 /etc/shadow 파일을 열려고 하면 권한 부족으로 인해 파일을 열 수 없습니다. 아래는 실제 출력 예시입니다. 일반유저로 shadow파일 오픈 실패 [user1@localhost ~]$ cat /etc/shadow cat: /etc/shadow: Permission denied 또한 mount 명령어도 일반 사용자 권한으로는 실행할 수 없습니다. 일반 유저로 mount 명령 실패 [user1@localhost sbin]$ mount /dev/sr0 /media mount: only root can do that 이제 일반 사용자에게 mount 명령어만 sudo 를 통해 root 권한으로 실행할 수 있도록 설정해보겠습니다. [user1@localhost ~]$ sudo mount /dev/...
자세한 내용 보기

[Ansible Modules] Fetch module 설명 및 활용

이미지
  Ansible modules 중 하나인 Fetch module에 대해 알아보겠습니다. Fetch는 관리 대상 노드에서 제어 노드로 파일을 복사해 오는 데 사용되는 모듈입니다 Fetch module 이란 Fetch는 영어로 "가져오다"라는 의미입니다. Ansible의 copy 모듈과 반대로 동작하는 기능으로, copy 가 제어 노드에서 관리 노드로 파일을 전송하는 데 사용된다면, fetch 는 그 반대 방향으로, 관리 대상 노드의 파일을 제어 노드로 복사해 오는 데 사용됩니다. 여기서 제어 노드(control node)는 Ansible을 실행하는 노드를, 관리 노드(managed node)는 Ansible로 관리되는 대상 시스템을 의미합니다. Ansible modules(fetch_module) Fetch module 옵션   fetch 모듈에서 주로 사용되는 주요 옵션은 다음과 같습니다: src : 관리 대상 노드에서 복사해 올 파일의 경로입니다. dest : 제어 노드에 파일을 저장할 경로입니다. flat (기본값: false ) false : {{ inventory_hostname }}/path/to/file 형태의 디렉토리 구조로 파일이 저장됩니다. 호스트별로 디렉토리가 생성되므로 여러 노드에서 같은 파일 경로를 가져올 때 유용합니다. true : 파일 경로 구조 없이 파일만 단순 복사됩니다. 이름이 같은 파일은 덮어써지기 때문에, 관리 노드가 하나이거나 파일명이 충돌하지 않는 경우에 적합합니다. 또한 디렉토리를 지정할 경우 dest 경로 끝에 슬래시( / )를 반드시 붙여야 합니다. Fetch module 사용 방법 예제에서는 다음과 같은 인벤토리 파일을 사용합니다. [test] rocky86.lab.example.com rocky84.lab.example.com   예제 1. 기본값( flat: false )으로 파일 가져오기 fetch  모듈을 이용해 관리 노드의...
자세한 내용 보기