기존 패키지 관리

소프트웨어 설치/관리는 리눅스 시스템 관리자의 중요한 업무중 하나이다. 과거에는 관리자가 시스템에 소프트웨어를 설치할 때 크게 다음과 같은 방법을 사용하였다.

Source 에서 빌드후 설치

일반적으로 소스를 배포할 때 tar 로 묶은 후에 gzip 으로 압축한 단일 .tar.gz 파일을 주로 배포한다. tar.gz 또는 .tgz 확장자를 갖는 이 파일들을 Source Tarball 이라고 부르며  이 파일을 다운로드한 후에 압축을 해제하고 autoconf 로 빌드 환경을 구성하고 make 를 사용하여 빌드한 후에 설치하는 경우가 많았다.

이 방법은 아직 패키지화 되지 않은 최신 버전을 사용할 수 있다는 장점이 있었지만 소스 컴파일이 번거롭고 컴파일이 안 될 경우 소스를 직접 수정하여 하며 여러 대의 서버에 설치와 버전 업그레이드가 힘든 등의 단점이 많아서 최근에는 많이 사용되지는 않는다.

미리 컴파일된 패키지로 설치

필자가 처음 사용해 본 리눅스는 슬랙웨어라는 배포판이었고 버전은 2.1 이었다. 슬랙웨어는 당시 리눅스를 사용하려면 거의 유일한 대안이었으며 쉘 스크립트 기반의 설치 프로그램을 제공하여 패키지 관리를 할 수 있었다. 당시의 패키지는 컴파일된 바이너리와 데이타, 설치 스크립트를 tar.gz 으로 묶어서 배포하였고 패키지 관리 프로그램은 tar.gz 를 지정된 경로에 압축을 해제하고 패키지 안에 있는 쉘 스크립트를 실행하여 설치를 실행하였다.

위와 같은 패키지 관리 방법은 간결하고 잘 동작했지만 사용하면서 다음과 같은 문제가 발생했다.

• 소프트웨어간의 의존성을 알 수가 없음
  프로그램 a 는 lib-b 라는 라이브러리가 필요하나 tar.gz 으로 묶인 패키지는 이런 정보를 가질 수 없다. 그래서 a 를 설치후에 구동이 안 되는 원인을 찾느라 많은 시간을 소비해야 했고 익숙하지 않은 사용자들은 문제 해결이 힘든 경우가 많았다.
• 소프트웨어 업그레이드가 어려움
  의존성을 관리하지 않아 프로램이나 라이브러리가 업데이트 될 경우 제대로 구동되지 않거나 필요한 라이브러리를 덮어 써서 문제가 발생할 수 있으며 업그레이드가 힘들어 백업후 재설치를 하여야 했다.
• 소프트웨어의 유효성 검증 불가
  tar.gz 는 파일에 대해 전자 서명을 할 수가 없다. 그러므로 해커가 악의적으로 변조된 .tar.gz 파일을 FTP 사이트등에 올려 놓을 경우 이 파일이 원저자가 배포한 것인지 확인하기가 어렵으므로 잘못된 소프트웨어를 설치하고 시스템이 피해를 입을 수 있다.
• 재설치/복구가 어려움
  여러 가지 이유로 소프트웨어를 재설치하고 설정을 초기화 해야 하는 경우가 있다. tar.gz 은 설치시 기존 설정 파일이 있어도 덮어 쓰므로 재설치나 업그레이드시 설정 파일을 수작업으로 백업해 두어야 했다.

Red Hat의 역사 - http://www.redhat.com/about/company/history.html.

이후 레드햇 리눅스를 발표한 레드햇사에서 사용자들에게 가장 크게 부각한 기능은 rpm 이라는 패키지 관리 프로그램이었다. rpm 은 슬랙웨어 패키지 관리 방식의 단점을 제거한 전용 패키지 포맷으로 유용성이 널리 알려지면서 슬랙웨어 사용자들이 레드햇 리눅스로 이동하는데 큰 공헌을 하였다. 

rpm

rpm 은 Red Hat Package Manager 또는 RPM Package Manager 의 약자로 기존 슬랙웨어의 tar.gz 방식의 패키지 관리를 대체하기 위해 개발되었다. rpm 방식으로 패키징된 소프트웨어는 .rpm 이라는 확장자를 갖게 되며 파일명은 다음과 같이 패키지명-버전.릴리즈.벤더.아키텍처 형식으로 배포가 된다.

예로 아파치 웹서버의 패키지명은 httpd-2.2.15-30.el6.centos.x86_64 이며 이는 패키지명은 httpd 이고 버전은 2.2.15-30 이며 릴리즈는 el6 이며 벤더는 centos이며 64비트용 패키지라는 의미이다. 32비트일 경우 x86_64 대신 i686으로 표시가 된다. 패키지가 python 이나 perl 같은 스크립트일 경우 32비트, 64비트 상관없이 동작하므로 x86_64나 i686 대신 noarch 라고 표시된다.

레드햇의 경우 httpd-2.2.15-29.el6_4.x86_64.rpm 처럼 벤더명이 빠지고 릴리즈가 마이너까지 표시가 되는 점이 CentOS 와 다른점이다.

rpm 은 소프트웨어의 의존성을 관리하므로 설치나 업그레이드가 용이해지고 패키지에 전자 서명을 추가할수 있으며 패키지의 위변조 여부를 검증할 수 있으므로 해커가 악의적으로 변조한 rpm을 배포하는 걸 막을 수 있다.

rpm 은 많은 기능과 옵션을 갖고 있지만 그중에서 가장 많이 쓰는 명령과 옵션을 살펴 보자.

명령 모드의 종류

rpm 은 다음 표와 같이 크게 6가지 명령 모드로 분류할 수 있으며 각각 모드마다 사용할 수 있는 옵션들이 다르다. rpm 은 GNU getopt 를 사용했으므로 짧은 옵션과 긴 옵션 모두 사용이 가능하다.

모드와 상관없이 사용할 수 있는 옵션도 몇 가지 있는데 그중 중요한 옵션은 다음과 같다.

• -?, --help rpm 의 사용에 대한 상세한 도움말 출력하고 프로그램을 종료한다.
• -v  실행시 진행 내역에 대한 자세한 정보를 출력한다.

설치/삭제 모드

설치와 업그레이드

설치(-i)와 업그레이드(-U) 모드에 주로 사용하는 추가 옵션은 v와 h 이며 의미는 다음과 같다.

• -v: verbose 자세한 정보 출력
• -h: 설치 진행 내역을 # 문자를 이용하여 표시한다.

rpm 으로 프로그램을 설치할 경우 다음 명령과 옵션을 사용하며 마지막에 설치할 패키지 파일을 기술한다. 다음은 아파치 웹서버가 HTTPS 보안 프로토콜을 지원할 수 있게 해주는 모듈인 mod_ssl 을 설치하는 예제이다.

rpm 은 패키지의 의존성을 관리하므로 mod_ssl 에 필요한 패키지가 설치되어 있지 않다면 위와 같이 설치가 실패하며 의존성있는 패키지의 목록을 출력한다. 관리자는 의존성 있는 패키지를 구해서 먼저 설치후에 mod_ssl 패키지를 설치해야 한다.

기존에 있는 패키지의 업그레이드 버전을 구했다면 -U 옵션으로 업그레이드할 수 있다. 사용법은 설치때와 동일하며 mod_ssl 이 2.2.16 으로 업그레이드 되었다면 다음과 같이 반영할 수 있다.

설치와 마찬가지로 의존성있는 패키지가 먼저 설치되어야 하므로 의존성있는 패키지 파악후 사전에 시스템에 반영해야 한다.

설치나 업그레이드시 패키지 파일의 경로는 로컬 파일시스템이 아니라 URL 형식으로 기술할 수 있다. 이럴 경우 파일을 다운로드 받고 다시 rpm 으로 설치하는 두 가지 과정을 거치지 않아도 되므로 편리하다. 다음은 위의 mod_ssl 을 http 로 다운로드 받아서 바로 설치하는 예제이다.

삭제

-e 옵션뒤에 패키지를 기술하면 삭제할 수 있다. 패키지는 전체를 기술하지 않고 패키지명만 기술해도 된다.

rpm의 의존성 관리 기능때문에 삭제하려는 패키지에 의존하는 패키지가 있을 경우 삭제되지 않으므로 먼저 의존하는 패키지를 찾아서 지워야 한다. 다음은 아파치 웹서버를 삭제하는 예제이며 httpd에 의존성하는 mod_ssl 이 있으므로 삭제가 실패한다.

질의 모드

기존 tar.gz 기반 패키지에 비해 가장 큰 장점중 하나는 다양한 질의를 사용할 수 있는 점이다. rpm 은 -q 명령으로 패키지의 정보를 질의할 수 있으며 다양한 하위 옵션이 있으므로 다양한 질의를 사용할 수 있다. 그중에 가장 많이 쓰이는 옵션을 알아 보자.

전체 설치 패키지 보기

시스템에 설치된 전체 패키지의 목록을 보려면 질의 모드의 메인 명령인 -q에 -a, --all 옵션을 추가하면 된다. 다음은 -qa 옵션으로 전체 패키지 목록을 출력하는 예제이다.  

자세한 정보 보기

설치 목록에서 무슨 용도인지 잘 모르는 패키지인 libssh2 를 발견했다. 이 패키지에 대한 더 많은 정보를 보려면 -i, --info 옵션을 주면 패키지명과 버전, 설명과 빌드 날자, 설치 날자등 자세한 정보를 볼 수 있다. 

만약 설치하기전에 패키지의 정보를 보고 싶다면 -p 옵션을 추가하고 뒤에 패키지의 경로를 입력하면 된다. -p 옵션은 아래의 다른 질의 상황에서도 사용할 수 있다.

설치 목록 보기

패키지에 대한 자세한 정보는 보았는데 이 패키지가 어떤 파일들을 어떤 경로에 설치했는지 궁금할 수 있다. 목록은 -l, --list 옵션을 주면 알수 있다.

마찬가지로 -p 옵션으로 설치하기전 패키지의 목록을 볼 수 있다. -p 옵션 사용시 패키지가 다른 디렉터리에 있을 경우 패키지명에 절대, 또는 상대 경로도 포함시켜야 한다.

파일이 속한 패키지 알기

이제 패키지의 내용과 설치 경로를 알수 있게 됐지만 반대로 어떤 프로그램이나 파일이 어떤 패키지로부터 설치되었는지 궁금할 수도 있다.  이럴 경우 -f ,–file 옵션을 추가하면 파일이 포함된 패키지를 알 수 있으며 여러 개의 파일에 대해서 알고 싶을 경우 공백을 구분자로 파일의 절대 경로를 기술해 주면 된다. /etc/httpd/conf/magic 이란 파일과  /usr/bin/vim 파일은 어떤 패키지에서 설치됐는지 확인해 보자.

위와 같이 httpd와 vim-enhanced 패키지에서 설치되었다고 알려 준다.

패키지의 의존성 목록 보기

rpm 의 가장 큰 장점중 하나는 의존성 관리 기능이다. -R, --requires 옵션을 이용하면 해당 패키지가 필요로 하는 프로그램이나 라이브러리의 의존성 목록을 확인할 수 있다. mod_ssl 패키지는 어떤 프로그램과 라이브러리를 필요로 하는지 확인해 보자.

의존성을 표시할때 버전도 같이 명시가 되며 특정 버전이 필요할 경우 = 문자가 표시되며 특정 버전 이상인 경우 >= 로 표시된다.

mod_ssl 은 아파치 웹서버 패키지인 httpd 가 2.2.15 버전(httpd = 0:2.2.15-31.el6.centos)이어야 하며 ssl 을 처리하는 openssl 라이브러리가 0.9.7f-4 이상의 버전(openssl >= 0.9.7f-4)이 있어야 한다고 표시하고 있다.

패키지의 변경 이력 보기

패키지가 업데이트 되었을 때 어떤 기능이 개선되고 어떤 버그나 보안 취약점이 해결되었는지 확인하고 싶은 경우가 있다. 질의 모드에서 --changelog 옵션을 사용하면  패키지의 개정 이력을 확인할 수 있다.

다음 명령어는 2014년에 상반기에 큰 이슈가 되었던 openssl 의 heartbeat 로 인한 보안 취약점(CVE-2014-0160 - HeartBleed 라 불림)이 해결되었는지 확인하기 위해 변경 이력을 확인하는 명령어이다.

변경 이력을 스크롤하여 하단을 살펴 보면 2014년 4월 7일에 해당 보안 취약점이 해결되었고 해결된 openssl 패키지의 버전은 1.0.1e-16.7 임을 확인할 수 있다.

서명 모드

시스템에 C 컴파일러가 필요해졌는데 확인해 보니 gcc 라는 패키지를 설치하면 된다는 걸 알았다. 어찌어찌 찾아 들어간 사이트에서 gcc-4.4.7-4.el6.x86_64.rpm 란 패키지를 다운로드 받았다. 파일명에 centos 가 들어가지만 이게 과연 centos 팀이 패키징한게 맞는지 확인을 한 후에 설치하고 싶을 경우 rpm 의 서명 검증 기능을 사용하면 이런 의문을 해결할 수 있다.

다음은 gcc 패키지가 위변조되었는지 검증하는 방법이다. -K 옵션뒤에 검증할 패키지명을 입력해 주면 되며 정상적으로 검증이 끝난 결과이다.

만약 rpm 패키지가 위 변조되었거나 혹은 서명자의 KEY 를 모를 경우 에러가 발생하게 된다. 다음은 위변조된 rpm 을 검증한 결과이다.

mod_ssl-2.2.15-29.el6.centos.x86_64.rpm: rsa sha1 (MD5) PGP MD5 NOT OK

다른 벤더가 패키징하고 서명후에 rpm 을 배포할 수도 있으며 예로 MySQL 의 리눅스용 버전은 오라클이 서명하여 배포하며 오라클의 전자서명 검증키가 기본적으로 시스템에 설치되어 있지 않으므로 검증 에러가 발생할 수 있다. 이럴 경우 제조사의 서명 검증키를 구해서 --import 옵션으로 추가해야 한다.

검증 모드

rpm 은 설치 정보도 모두 데이타 베이스화하여 갖고 있으므로 설치이후 패키지내 파일의 변경 내역을 확인할 수 있다. -V 옵션을 사용하면 다양한 검증 질의를 할 수 있다. 검증시 표시하는 정보들중 중요한 항목들의 의미는 다음과 같다.

• S : 파일 크기가 다름
• M : 모드가 다름 (권한 및 파일 형식 포함)
• 5 : MD5 해쉬값이 다름(파일이 변경됨)
• U: 사용자 소유권이 변경됨
• T: 파일의 변경 시간이 다름(파일이 설치후에 변경됨)

이제 httpd 의 설치 정보를 검증해 보자. 주요 설정 파일은 httpd.conf가 S5T 라고 표시되는 것은 설정 파일을 수정하여 파일의 크기(S)와, MD5 해쉬값(5), 변경시간(T) 이 달라졌기 때문이다. 

이제 rpm 의 주요 명령어와 옵션에 대해서 살펴 보았지만 rpm 으로 패키지 관리시 맞닥드리게 되는 문제를 이미 접해본 독자들이 많을 것이다.

rpm 으로 패키지를 관리하다 보면 다음과 같은 문제가 발생한다.

• 의존성 관리는 하지만 의존성 있는 패키지를 관리해 주지는 않는다. mod_ssl 설치시 httpd와 openssl 외 다수의 패키지가 필요하지만 rpm 은 알려주기만 하고 다운로드해 주지는 않는다. 관리자가 필요 패키지를 직접 다운로드후 설치해야 하지만 필요 패키지가 또 다른 패키지를 필요로 하는 경우 부가적인 작업이 매우 많아진다.
• 패키지의 업데이트가 있는지 알려면 수동으로 확인하는 수 밖에는 없다. 이 경우 관심있는 패키지가 아닐 경우 심각한 보안 문제나 버그가 있고 이를 해결한 패키지가 업데이트됐어도 모르고 예전 문제있는 버전을 그대로 사용하게 된다.
• 패키지를 그룹으로 설치하거나 관리할 수 없다. 예로 컴파일러, 디버거, 프로파일러등 개발용 도구를 설치하고 싶은 경우 각각 구해서 설치해야 한다.
• 어떤 소프트웨어가 필요할 경우 rpm 패키지로 있는지 검색하려면 검색 엔진에서 찾아야 한다.

이런 문제를 해결하기 위해 yum 이라는 패키지 관리 시스템이 개발되었고 많은 장점이 있어서 rpm 을 사용하는 리눅스 배포판은 yum 을 사용하게 되었다.

같이 보기

• rpm command 정리 및 사용법