Linux 에서 RPM 을 이용한 패키지 관리

소개

이 실습에서는 강력한 rpm 명령줄 도구를 사용하여 RPM 기반 Linux 배포판에서 소프트웨어 패키지를 관리하는 기본 원리를 배웁니다. 상세한 패키지 정보 조회, 설치된 패키지의 무결성 검증, RPM 파일의 내용물 조사 등 필수적인 패키지 관리 작업에 대한 실무 경험을 쌓게 됩니다.

각 단계를 진행하며 특정 rpm 명령어를 사용하여 파일이 어떤 패키지에 속해 있는지 확인하고, 패키지 의존성 및 설정 파일 목록을 나열하며, 역의존성을 확인하는 방법을 익힙니다. 또한, 시스템에 미치는 영향을 파악하기 위해 패키지 삭제를 안전하게 시뮬레이션하는 방법과 rpm2cpio 및 cpio와 같은 도구를 사용하여 설치 전 RPM 패키지 파일의 내부를 살펴보는 방법도 배우게 됩니다.

rpm -qi 및 rpm -qf를 이용한 기본 패키지 정보 조회

이 단계에서는 Red Hat 패키지 관리자 (rpm) 를 사용하여 설치된 패키지에 대한 정보를 조회하는 방법을 배웁니다. rpm은 CentOS, Fedora, RHEL 과 같은 RPM 기반 Linux 배포판에서 소프트웨어를 관리하기 위한 강력한 명령줄 유틸리티입니다. 여기서는 상세 패키지 정보를 가져오는 -qi 옵션과 특정 파일이 어느 패키지에 속하는지 확인하는 -qf 옵션이라는 두 가지 핵심 조회 옵션에 집중하겠습니다.

먼저, 시스템에 이미 설치된 패키지의 상세 정보를 확인해 보겠습니다. bash 쉘은 시스템의 핵심 구성 요소이므로 아주 좋은 예시가 됩니다. -q 플래그는 'query(조회)'를 의미하며, i 플래그는 'information(정보)'을 의미합니다.

터미널에서 다음 명령어를 실행하여 bash 패키지에 대한 정보를 조회하십시오.

rpm -qi bash

패키지의 다양한 속성을 나열하는 상세 출력이 표시됩니다. 출력 내용은 다음과 유사할 것입니다 (버전 번호와 날짜는 다를 수 있습니다).

Name        : bash
Version     : 4.4.20
Release     : 5.el8
Architecture: x86_64
Install Date: <some_date>
Group       : System Environment/Shells
Size        : 4989189
License     : GPLv3+
Signature   : RSA/SHA256, <some_date_and_time>, Key ID <some_key_id>
Source RPM  : bash-4.4.20-5.el8.src.rpm
Build Date  : <some_date>
Build Host  : <some_build_host>
Relocations : (not relocatable)
Vendor      : CentOS
URL         : http://www.gnu.org/software/bash
Summary     : The GNU Bourne-Again Shell
Description :
The GNU Bourne-Again Shell (Bash) is a shell or command language
interpreter that is compatible with the Bourne shell (sh). Bash
incorporates useful features from the Korn shell (ksh) and the C
shell (csh).  Most sh scripts can be run by bash without
modification.

이 출력은 패키지 버전, 용도 요약, 상세 설명 등 풍부한 정보를 제공합니다.

이제 시스템에 /usr/bin/bash에 위치한 bash 실행 파일과 같은 파일이 있는데, 이 파일을 어떤 패키지가 설치했는지 알고 싶다고 가정해 봅시다. 이는 시스템 감사나 문제 해결 시 자주 발생하는 작업입니다. 이 경우 -qf 플래그를 사용할 수 있으며, 여기서 f는 'file(파일)'을 의미합니다.

다음 명령어를 실행하여 /usr/bin/bash 파일을 소유한 패키지를 찾으십시오.

rpm -qf /usr/bin/bash

명령어는 해당 파일을 제공하는 패키지의 전체 이름을 반환합니다.

bash-5.1.8-9.el9.x86_64

보시는 것처럼 시스템은 /usr/bin/bash가 bash 패키지에서 왔음을 정확히 식별하며, 이는 앞서 확인한 정보와 일치합니다. rpm -qif /usr/bin/bash를 실행하여 파일을 소유한 패키지에 대한 정보를 직접 가져오도록 플래그를 조합할 수도 있습니다.

rpm -qR 및 rpm -qc를 이용한 패키지 의존성 및 설정 파일 목록 확인

이 단계에서는 패키지의 의존성 및 관련 설정 파일 목록을 확인하는 방법을 배우며 rpm 활용법을 계속 탐구합니다. 대부분의 소프트웨어는 올바르게 작동하기 위해 다른 패키지에 의존하므로 의존성을 이해하는 것은 매우 중요합니다. 또한 설정 파일의 위치를 아는 것은 시스템 관리 및 사용자 정의에 필수적입니다.

먼저 bash 패키지가 요구하는 다른 패키지나 기능이 무엇인지 알아보겠습니다. 이를 위해 -qR(또는 --requires) 플래그를 사용합니다. 여기서 R은 'requires(요구 사항)'를 의미합니다.

다음 명령어를 실행하여 bash의 의존성을 확인하십시오.

rpm -qR bash

출력 결과는 bash가 의존하는 패키지 및 시스템 기능 목록입니다. 이 목록은 꽤 길 수 있습니다.

/bin/sh
config(bash) = 4.4.20-5.el8
filesystem >= 3
glibc
info
libc.so.6(GLIBC_2.17)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.28)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
...
rtld(GNU_HASH)

이 출력은 bash가 glibc(C 라이브러리인 libc.so.6 제공), filesystem 패키지 및 기타 시스템 수준 구성 요소를 필요로 함을 보여줍니다.

다음으로 bash 패키지의 일부로 설치된 설정 파일들을 찾아보겠습니다. 이는 새로운 사용자를 위해 쉘의 기본 동작을 수정해야 할 때 유용합니다. 이를 위해 -qc 플래그를 사용하며, 여기서 c는 'configfiles(설정 파일)'를 의미합니다.

이 명령어를 실행하여 bash의 설정 파일 목록을 확인하십시오.

rpm -qc bash

출력 결과에 설정 파일의 전체 경로가 표시됩니다.

/etc/skel/.bash_logout
/etc/skel/.bash_profile
/etc/skel/.bashrc

/etc/skel에 있는 이 파일들은 사용자 계정이 생성될 때 새 사용자의 홈 디렉토리로 복사되는 템플릿 파일입니다.

특정 명령어와 관련된 설정 파일을 찾기 위해 플래그를 조합할 수도 있습니다. 예를 들어 passwd 명령어가 사용하는 설정 파일을 보려면 -qcf를 사용할 수 있습니다. 이는 rpm에게 먼저 파일에 해당하는 패키지를 찾고 (-f /usr/bin/passwd), 그 다음 해당 패키지의 설정 파일을 나열 (-c) 하도록 지시합니다.

rpm -qcf /usr/bin/passwd

이 명령어는 passwd 유틸리티와 관련된 설정 파일을 보여줍니다.

/etc/pam.d/passwd

이는 명령어의 동작을 변경하기 위해 수정해야 할 파일을 신속하게 식별할 수 있는 강력한 방법입니다.

rpm -V를 이용한 패키지 무결성 및 파일 변경 사항 검증

이 단계에서는 rpm -V(또는 rpm --verify) 를 사용하여 설치된 패키지의 무결성을 검증하는 방법을 배웁니다. 이 명령어는 중요한 보안 및 문제 해결 도구입니다. 패키지에 의해 설치된 파일을 파일 크기, 권한, 체크섬 등 RPM 데이터베이스에 저장된 정보와 대조하여 확인합니다. 이를 통해 시스템 파일에 대한 무단 변경이나 실수로 인한 변경을 감지할 수 있습니다.

먼저, 검증 테스트에 사용할 유틸리티 패키지인 lsscsi와 at가 시스템에 설치되어 있는지 확인하겠습니다.

sudo dnf install -y lsscsi at

이제 lsscsi 패키지를 검증해 보겠습니다. 방금 설치했고 아무런 변경도 하지 않았으므로 검증 테스트를 통과해야 합니다. 검증에 성공하면 아무런 출력도 생성되지 않습니다.

rpm -V lsscsi

예상대로 명령 프롬프트가 아무런 메시지 없이 반환되며, 이는 lsscsi 패키지의 모든 파일이 원래 상태임을 나타냅니다.

다음으로, 설정 파일을 의도적으로 수정하고 rpm -V가 변경 사항을 어떻게 보고하는지 확인해 보겠습니다. at 패키지에 속하며 at 명령어 사용이 금지된 사용자를 제어하는 /etc/at.deny 파일에 한 줄을 추가하겠습니다.

echo "labex" | sudo tee -a /etc/at.deny

파일을 수정했으므로 이제 at 패키지를 다시 검증해 봅니다.

sudo rpm -V at

이번에는 명령어가 출력을 생성하여 변경 사항이 감지되었음을 알립니다.

S.5....T.  c /etc/at.deny

이 출력을 분석해 보겠습니다.

• S: 파일 크기 (Size) 가 변경되었습니다.
• 5: MD5 체크섬이 변경되었습니다.
• T: 수정 시간 (Modification Time) 이 변경되었습니다.
• c: 이것이 설정 (configuration) 파일임을 나타냅니다.
• /etc/at.deny: 수정된 파일의 경로입니다.

8 글자 문자열 S.5....T.의 각 문자 위치는 서로 다른 테스트를 나타냅니다. .은 해당 테스트를 통과했음을 의미합니다. 이 출력은 /etc/at.deny 설정 파일이 설치 이후 변경되었음을 명확히 보여줍니다.

-qVf 플래그를 사용하여 특정 파일을 소유한 패키지를 직접 검증할 수도 있습니다.

sudo rpm -qVf /etc/at.deny

이 명령어는 먼저 /etc/at.deny를 소유한 패키지 (at) 를 찾은 다음 이를 검증하므로 동일한 결과를 출력합니다.

rpm -e --test를 이용한 역의존성 확인 및 패키지 삭제 시뮬레이션

이 단계에서는 역의존성을 확인하고 패키지 삭제를 안전하게 시뮬레이션하는 방법을 배웁니다. rpm -qR 명령어가 패키지가 필요로 하는 것(의존성) 을 보여준다면, rpm -q --whatrequires는 다른 어떤 패키지가 이 패키지를 필요로 하는지(역의존성) 를 보여줍니다. 패키지를 삭제하면 시스템의 다른 부분이 망가질 수 있으므로 삭제 전에 이를 확인하는 것이 매우 중요합니다.

패키지 삭제 결과를 안전하게 확인하려면 rpm -e --test 명령어를 사용할 수 있습니다. -e 플래그는 'erase(삭제)'를 의미하며, --test 플래그는 실제로 파일을 삭제하지 않고 모의 실행 (dry run) 을 수행하도록 RPM 에 지시합니다.

먼저 다른 많은 패키지가 의존하는 핵심 시스템 패키지를 살펴보겠습니다. glibc 패키지는 Linux 시스템의 거의 모든 프로그램에 필수적인 GNU C 라이브러리를 제공합니다. 어떤 패키지들이 glibc를 요구하는지 확인해 봅시다.

rpm -q --whatrequires glibc

출력 결과에 glibc에 의존하는 여러 패키지가 표시됩니다.

glibc-common-2.34-168.el9_6.19.x86_64
glibc-langpack-en-2.34-168.el9_6.19.x86_64
libstdc++-11.5.0-5.el9_5.x86_64
glibc-headers-2.34-168.el9_6.19.x86_64
pam-1.5.1-23.el9.x86_64
glibc-devel-2.34-168.el9_6.19.x86_64
nscd-2.34-168.el9_6.19.x86_64

보시는 것처럼 많은 중요한 시스템 패키지가 glibc에 의존하고 있습니다. 이제 glibc를 삭제하려고 하면 어떤 일이 일어나는지 확인해 보겠습니다. 시스템 전체를 망가뜨릴 수 있는 실제 삭제를 방지하기 위해 --test 플래그를 사용합니다.

sudo rpm -e --test glibc

너무 많은 패키지가 glibc를 필요로 하기 때문에 RPM 은 의존성 오류를 보고하고 삭제를 중단합니다. 출력에는 실패한 의존성 목록이 길게 표시됩니다.

error: Failed dependencies:
 glibc = 2.34-168.el9_6.19 is needed by (installed) glibc-common-2.34-168.el9_6.19.x86_64
 glibc = 2.34-168.el9_6.19 is needed by (installed) glibc-langpack-en-2.34-168.el9_6.19.x86_64
 glibc >= 2.34 is needed by (installed) libstdc++-11.5.0-5.el9_5.x86_64
 ... (추가 의존성 오류)

이제 의존성이 적은 패키지를 살펴보겠습니다. 앞서 설치한 lsscsi 패키지는 역의존성이 적은 유틸리티 패키지입니다. 무엇이 이 패키지를 요구하는지 확인해 봅시다.

rpm -q --whatrequires lsscsi

lsscsi를 요구하는 패키지가 없다는 출력이 표시되어야 합니다.

no package requires lsscsi

lsscsi에 의존하는 패키지가 없으므로 삭제 시뮬레이션을 안전하게 수행할 수 있습니다.

sudo rpm -e --test lsscsi

이 명령어는 오류 없이 완료되어야 하며, 이는 lsscsi를 삭제해도 시스템의 다른 패키지에 영향을 주지 않음을 나타냅니다.

이를 통해 패키지 삭제의 영향을 예측하고, 역의존성을 먼저 확인하여 시스템 장애를 방지하는 방법을 익혔습니다.

rpm2cpio 및 cpio 를 이용한 RPM 패키지 내용물 조사

이 단계에서는 RPM 패키지 파일을 설치하지 않고 그 내용물을 조사하는 강력한 기술을 배웁니다. 이는 설치 전에 패키지에 포함된 파일을 확인하거나, 손상되거나 삭제된 파일을 복구하기 위해 패키지에서 단일 파일을 추출할 때 유용합니다. 이 과정에는 두 가지 명령어가 사용됩니다. RPM 파일을 cpio 아카이브로 변환하는 rpm2cpio와 해당 아카이브에서 파일을 나열하거나 추출할 수 있는 cpio입니다.

먼저 조사할 실제 .rpm 파일이 필요합니다. dnf 패키지 관리자를 사용하여 bash 패키지 파일을 현재 디렉토리 (~/project) 로 다운로드하겠습니다. download 하위 명령어는 패키지를 설치하지 않고 파일만 가져옵니다.

sudo dnf download bash

파일이 성공적으로 다운로드되었다는 출력이 표시됩니다. 파일 이름에는 버전과 아키텍처가 포함됩니다.

Last metadata expiration check: ...
bash-<version>.<arch>.rpm

이제 ls 명령어를 사용하여 ~/project 디렉토리에 .rpm 파일이 있는지 확인하십시오.

ls bash-*.rpm

RPM 파일이 준비되었으므로 이제 rpm2cpio와 cpio 명령어를 함께 사용하여 내용물을 나열할 수 있습니다. rpm2cpio 명령어는 RPM 파일을 읽어 표준 출력으로 cpio 아카이브를 내보냅니다. 그런 다음 이 출력을 파이프 (|) 를 통해 표준 입력으로 아카이브를 읽는 cpio 명령어로 전달합니다. cpio의 -t 플래그는 목차를 나열하도록 지시합니다.

rpm2cpio bash-*.rpm | cpio -t

그러면 bash 패키지에 포함된 모든 파일과 디렉토리의 긴 목록이 생성됩니다. 출력은 다음과 유사할 것입니다.

.
./etc
./etc/skel
./etc/skel/.bash_logout
./etc/skel/.bash_profile
./etc/skel/.bashrc
./usr
./usr/bin
./usr/bin/bash
./usr/bin/sh
./usr/share
./usr/share/doc
...

이 기술을 통해 패키지의 페이로드를 전체적으로 파악할 수 있으며, 패키지를 설치할 경우 시스템의 어느 위치에 어떤 파일이 배치될지 정확히 확인할 수 있습니다.

요약

이 실습에서는 Linux 환경에서 RPM 유틸리티를 사용하여 소프트웨어 패키지를 관리하고 조회하는 방법을 배웠습니다. rpm -qi로 설치된 패키지의 상세 정보를 가져오고 rpm -qf로 특정 파일이 속한 패키지를 식별하는 것으로 시작했습니다. 또한 rpm -qR로 패키지의 의존성을 나열하고 rpm -qc로 설정 파일의 위치를 파악하여 패키지가 시스템에 어떻게 통합되는지 종합적으로 살펴보았습니다.

이러한 조회 기술을 바탕으로 rpm -V를 사용하여 설치된 패키지 파일의 무결성을 검증하고 변경 사항을 확인하는 방법을 익혔습니다. 또한 역의존성을 안전하게 확인하고 rpm -e --test로 패키지 삭제를 시뮬레이션하여 변경 사항을 적용하지 않고도 잠재적인 영향을 이해하는 방법을 탐구했습니다. 마지막으로 rpm2cpio와 cpio를 사용하여 설치 전에 RPM 패키지 파일의 내용물을 추출하고 나열하는 능력을 갖추게 되었습니다.