When trying to run yum, I get the following error:

Another app is currently holding the yum lock; waiting for it to exit...

The other application is: yum

I've manually killed each yum process id, but it keeps on occurring (other application is: yum), although the days ago become more recent (used to be 3 days ago, then 1 day ago)..

Any idea what's wrong?



Another app is currently holding the yum lock; waiting for it to exit...






Probably because yum has previously been shutdown uncleanly it's left behind an old lock file.

Try

sudo killall yum
sudo rm /var/run/yum.pid


This howto explains howto install Google Chrome Web browser on Fedora 14Fedora 13Fedora 12 and Red Hat 6 (RHEL 6). Best way to install and keep up-to-date with Google Chrome browser is use Google’s own YUM repository.

Enable Google YUM repository

Add following to /etc/yum.repos.d/google.repo file:
32-bit

[google]
name=Google - i386
baseurl=http://dl.google.com/linux/rpm/stable/i386
enabled=1
gpgcheck=1
gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub

64-bit

[google64]
name=Google - x86_64
baseurl=http://dl.google.com/linux/rpm/stable/x86_64
enabled=1
gpgcheck=1
gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub

Note: Both 32-bit and 64-bit repos can be placed in the same file.

Install Google Chrome with YUM (as root user)

Install Google Chrome Stable Version

## Install Google Chrome Stable version ##
yum install google-chrome-stable

Install Google Chrome Beta Version

## Install Google Chrome Beta version ##
yum install google-chrome-beta

Install Google Chrome Unstable Version

## Install Google Chrome Unstable version ##
yum install google-chrome-unstable

'리눅스관련' 카테고리의 다른 글

[fedora15] apache web server - httpd install  (0) 2011.06.10
ubuntu 11.4 에서 unity 2D 설치  (0) 2011.06.09
CentOS Network 설정  (0) 2011.06.06
CentOS 설정파일 위치  (0) 2011.06.06
Centos 5.X에서 MP3재생  (0) 2011.06.06



Linux 학습, 기초 과정: RPM 및 YUM 패키지 관리


소프트웨어 새로 추가 및 시스템을 최신 상태로 유지




Ian Shields, 선임 프로그래머, IBM Japan


요약: Linux® 시스템에서 패키지를 설치, 업그레이드 및 관리하는 방법을 학습할 수 있는 기회입니다.이 기사에서는 Red Hat에서 개발한 RPM(Red Hat Package Manager)뿐 아니라, 원래는 듀크대학교 물리학과에서 Red Hat Linux 시스템을 관리하기 위해 개발한 YUM(Yellowdog Updater Modified)에 초점을 맞춰 설명합니다. 이 기사에 소개된 자료를 이용해 Linux 시스템 관리자 인증을 획득하기 위한 LPI 101 시험에 대비한 공부를 하거나, 그냥 소프트웨어를 새로 추가하고 시스템을 최신 상태로 유지하는 최선의 방법을 탐구할 수도 있습니다






개요


이 기사에서는 RPM과 YUM 도구를 사용하여 Linux 시스템에서 패키지를 관리하는 방법을 학습할 수 있다. 그 내용은 다음과 같다.


RPM과 YUM을 사용하여 패키지 설치, 다시 설치, 업그레이드 및 제거


버전, 상태, 종속성, 무결성 및 서명을 포함하여, RPM 패키지에 관한 정보 획득


패키지에서 제공하는 파일 확인 및 특정 파일이 어떤 패키지에서 온 것인지 찾기




이 기사는 Linux Professional Institute의 Junior Level Administration(LPIC-1) 시험 101의 Topic 102에서 Objective 102.5에 대비하는 데 도움이 된다. 이 목적의 가중치는 3이다.


전제 조건


본 시리즈에 수록된 기사에서 최대한 많은 도움을 받으려면 Linux에 대한 기초적 지식과 이 기사에서 다루는 명령을 실습할 수 있도록 작동 중인 Linux 시스템이 있어야 한다. 때로는 한 프로그램의 다른 버전들이 서로 결과물 형식이 다를 때도 있으므로, 결과가 항상 여기서 예시하는 내용 및 표시하는 그림과 정확히 일치 않을 수도 있다. 특히, 여기서 보여주는 결과물 중 다수는 이미 시스템에 설치되어 있는 패키지에 따라 큰 차이가 난다. 독자 자신의 결과물도 다를 수 있지만, 중요한 공통 사항을 인식할 수 있어야 한다.






패키지 관리 소개


Ian과 연락하기


Ian은 가장 인기있고 많은 글을 쓰는 저자 중 한 명이다. developerWorks에 실린Ian의 모든 기사를 살펴보자. My developerWorks에서 Ian의 프로파일을 볼 수 있으며 Ian과 다른 저자 및 그를 좋아하는 여러 독자와 연락할 수 있다.




과거에는 많은 Linux 프로그램이 소스 코드로 배포되었고, 사용자는 필요한 매뉴얼 페이지, 구성 파일 등과 함께, 필수 프로그램 또는 프로그램 세트에 Linux 프로그램을 빌드했다. 요즘에는 대부분의 Linux 배포자가패키지라고 하는 미리 빌드된 프로그램 또는 프로그램 세트를 사용하며, 이런 패키지는 배포 시 바로 설치할 수 있도록 출고된다. 이 기사에서는 패키지를 설치, 업데이트 및 제거하는 데 도움이 되는 패키지 관리 도구에 관한 내용을 학습할 수 있다. 이 기사에서는 Red Hat에서 개발한RPM(Red Hat Package Manager)뿐 아니라, 원래는 듀크대학교 물리학과에서 Red Hat Linux 시스템을 관리하기 위해 개발한YUM(Yellowdog Updater Modified)에 초점을 맞춰 설명한다. 본 시리즈의 또 다른 기사인 "Learn Linux 101: Debian package management"에서는 Debian 시스템에서 사용하는 패키지 관리 도구에 대해 다룬다.


사용자 관점에서 볼 때, 기본적인 패키지 관리 기능은 명령에 의해 제공된다. Linux 개발자들이 Linux를 더 사용하기 쉽게 만들기 위해 노력한 결과, 기본 도구의 일부 복잡한 부분을 최종 사용자에게는 보이지 않도록 숨겨주는 GUI 도구를 비롯한 다른 도구들로 기본 도구를 보완했다. 다른 도구 중 몇 가지에 관해서는 독자의 이해를 돕기 위해 언급하겠지만, 본 기사와 Debian package management에 관한 기사에서는 기본 도구에 초점을 맞춰 설명한다.


RPM, YUM 및 APT(Debian 시스템용)는 유사한 점이 많다. 이들 모두 패키지를 설치하고 제거할 수 있다. 설치한 패키지에 관한 정보는 데이터베이스에 보관된다. 이 세 가지 모두 기본적인 명령행 기능이 있고, 추가 도구를 통해 사용자에게 친숙한 인터페이스를 제공할 수 있다. 또한, 이들 모두 인터넷에서 패키지를 검색할 수 있다.


Linux 시스템을 설치할 때, 일반적으로 다수의 패키지를 선택하여 설치하게 된다. 이렇게 선택하는 패키지 세트는 서버, 데스크탑 또는 개발자 워크스테이션과 같이 시스템의 용도에 따라 사용자 정의할 수 있다. 그리고 언젠가는 추가된 기능을 위해 새 패키지를 설치하거나, 가지고 있는 패키지를 업데이트하거나, 더 이상 필요하지 않거나 새 패키지의 등장으로 쓸모없어진 패키지를 제거해야 할 때가 있을 것이다. 이런 작업을 수행하는 방법과 어떤 패키지에 특정 명령이 들어 있을지 찾는 것과 같은 관련 과제 중 몇 가지를 살펴보자.


RPM


Red Hat에서는 1995년에 RPM을 선보였다. RPM은 현재 LSB(Linux Standard Base)에서 패키징을 위해 사용되는 패키지 관리 시스템이다. rpm 명령 옵션은 다음 작업에 대해 세 가지 하위 그룹으로 분류된다.


패키지 쿼리 및 확인


패키지 설치, 업그레이드 및 제거


기타 기능 수행




본 기사에서는 첫 두 명령 옵션 세트에 초점을 맞춰 설명하기로 한다. RPM에 대한 매뉴얼 페이지에서 기타 기능에 관한 정보를 찾을 수 있다.


또한, rpm은 RPM에서 사용되는 기본 명령의 명령 이름인 반면, .rpm은 RPM 파일에 사용하는 확장자라는 점에 유의해야 한다. 따라서 "rpm" 또는 "xxx rpm"은 일반적으로 RPM 파일을 지칭하고, rpm은 보통 명령을 가리킨다.


YUM


YUM은 종속성 관리를 포함한 자동 업데이트 및 패키지 관리 기능을 RPM 시스템에 추가한 것이다. 시스템에 설치된 패키지를 이해하는 것 외에, Debian APT(Advanced Packaging Tool)와 같은 YUM은 일반적으로 네트워크 연결을 통해 액세스할 수 있는 패키지 콜렉션인 저장소에서 작동한다.






RPM 패키지 설치


Lisp를 학습하고 싶은데, 한 동료가 gcl 명령을 사용해보라고 한다고 가정해보자. gcl --help를 사용해보거나 which gcl 또는type gcl을 사용해볼 수도 있을 것이다. 그러나 시스템에서 gcl을 찾을 수 없는 경우 Listing 1에 표시된 것과 유사한 출력이 나타날 수 있다.



Listing 1. gcl 명령이 없는 경우

[ian@echidna ~]$ gcl --help  bash: gcl: command not found    [ian@echidna ~]$ which gcl  /usr/bin/which: no gcl in (/usr/lib64/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerber  os/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/  sbin:/home/ian/bin)    [ian@echidna ~]$ type gcl  bash: type: gcl: not found





동료에게 다시 확인하여 어떤 패키지를 설치할지 찾아내거나 단지 gcl 명령이 gcl 패키지에 있을 것으로 추측할 수도 있을 것이다. 이런 추측이 종종 맞을 때도 있지만, 항상 옳은 것은 아니다. 나중에 올바른 패키지를 찾는 방법을 살펴보겠다. 이 경우에는 gcl 패키지가 반드시 필요하다. 패키지 사본을 다운로드하거나 어디선가 얻었다고 가정하면, Listing 2에 나타낸 것처럼 rpm 명령과 -i(install) 옵션을 사용하여 설치할 수 있을 것이다.



Listing 2. rpm으로 gcl 설치 - 1

[root@echidna ~]# rpm -i gcl-2.6.8-0.6.20090701cvs.fc12.x86_64.rpm  error: Failed dependencies:  gcl-selinux is needed by gcl-2.6.8-0.6.20090701cvs.fc12.x86_64





rpm 명령에서는 패키지에 종속성이 있다는 것을 알지만, 불행히도 이 명령으로 그런 종속성을 해결할 수는 없다. 종속 패키지를 구해 다시 시도한 후 추가적인 종속성이 있는지 확인해야 한다.—그리고 모든 종속성이 충족될 때까지 이 과정을 계속 수행한다. 한 가지 좋은 점은 rpm 명령에 설치할 패키지 목록을 제공할 수 있고, 모든 종속성이 충족되는 경우 이 명령으로 목록에 있는 모든 패키지를 옳은 순서대로 설치할 수 있다는 점이다. 따라서 최소한 각 패키지를 옳은 순서에 따라 수동으로 설치하지 않아도 된다는 점이 좋다.


Debian의 APT를 사용해왔다면, 아마 지금쯤은 종속 항목을 포함하여 필요한 것을 간단히 찾아서 이동하여 그냥 설치하면 되는 apt-get 명령과 같은 것이 있었더라면 하는 생각이 들 것이다. RPM 기반 시스템의 경우, YUM(Yellowdog Updater Modified)이 바로 그런 기능을 제공한다. Listing 3은 yum 명령과 install 옵션을 사용하여 gcl과 필수적인 gcl;-selinux 소프트웨어의 설치 방법을 나타낸 것이다.



Listing 3. yum을 이용한 gcl 설치

[root@echidna ~]# yum install gcl  Loaded plugins: presto, refresh-packagekit  Setting up Install Process  Resolving Dependencies  --> Running transaction check  ---> Package gcl.x86_64 0:2.6.8-0.7.20100201cvs.fc12 set to be updated  --> Processing Dependency: gcl-selinux for package: gcl-2.6.8-0.7.20100201cvs.fc12.x86_64  --> Running transaction check  ---> Package gcl-selinux.x86_64 0:2.6.8-0.7.20100201cvs.fc12 set to be updated  --> Finished Dependency Resolution    Dependencies Resolved    =====================================================================================   Package           Arch         Version                          Repository     Size  =====================================================================================  Installing:   gcl               x86_64       2.6.8-0.7.20100201cvs.fc12       updates       6.3 M  Installing for dependencies:   gcl-selinux       x86_64       2.6.8-0.7.20100201cvs.fc12       updates        17 k    Transaction Summary  =====================================================================================  Install       2 Package(s)  Upgrade       0 Package(s)    Total download size: 6.4 M  Installed size: 40 M  Is this ok [y/N]: y  Downloading Packages:  Setting up and reading Presto delta metadata  updates/prestodelta                                           | 964 kB     00:01       Processing delta metadata  Package(s) data still to download: 6.4 M  (1/2): gcl-2.6.8-0.7.20100201cvs.fc12.x86_64.rpm              | 6.3 MB     00:12       (2/2): gcl-selinux-2.6.8-0.7.20100201cvs.fc12.x86_64.rpm      |  17 kB     00:00       -------------------------------------------------------------------------------------  Total                                                398 kB/s | 6.4 MB     00:16       Running rpm_check_debug  Running Transaction Test  Transaction Test Succeeded  Running Transaction    Installing     : gcl-selinux-2.6.8-0.7.20100201cvs.fc12.x86_64                 1/2     Installing     : gcl-2.6.8-0.7.20100201cvs.fc12.x86_64                         2/2     Installed:    gcl.x86_64 0:2.6.8-0.7.20100201cvs.fc12                                                Dependency Installed:    gcl-selinux.x86_64 0:2.6.8-0.7.20100201cvs.fc12                                        Complete!





Listing 3의 출력을 보면 YUM이 "updates"라는 저장소에서 gcl.x86_64 0:2.6.8-0.7.20100201cvs.fc12와 gcl-selinux.x86_64 0:2.6.8-0.7.20100201cvs.fc12를 찾아(그에 관한 자세한 내용은 곧 설명함) 총 다운로드 크기를 결정했음을 알 수 있다. "y"로 응답하여 트랜잭션에 동의한 후, 두 패키지 모두 다운로드한 다음 종속 항목과 gcl을 차례대로 설치했다. 본 기사 후반부에 종속성에 관해 설명하겠다.






패키지 위치


이전 섹션에서 RPM 패키지 설치 방법을 살펴보았다. 하지만, RPM 패키지는 어디서 온 것일까? yum은 어디서 패키지를 다운로드할지 어떻게 아는 것일까? 출발점은 보통 여러 개의 repo 파일이 들어 있는 /etc/yum.repos.d/ 디렉토리이다. 이 디렉토리는 ropo 파일의 기본 위치이지만, YUM 구성 파일에 다른 위치(보통 /etc/yum.conf)가 지정될 수도 있다. Listing 4에서는 Fedora 12 시스템에 우리가 gcl을 설치한 위치에 해당하는 fedora-updates.repo를 보여준다.


전형적인 repo 파일은 세 개의 섹션으로 나뉘는데, 각각 일반 패키지, 디버그 패키지 및 원본 패키지를 위한 것이다. 보통, 다른 위치 또는 미러에서 사용 가능한 배포 패키지의 사본이 여러 개 있을 것이다. 따라서 repo 파일은 각 섹션에 대한 최신 미러 목록을 찾을 곳을yum에 알려준다. 배포 릴리스 레벨과 시스템 아키텍처가 매개변수화되므로, yum은 https://mirrors.fedoraproject.org/metalink?repo=updates-released-f12&arch=x86_64에서 내 x86_64 Fedora 12 시스템에 대한 목록을 다운로드한다.


저장소 위치 외에도, repo 파일은 특정 저장소를 사용하는지 여부와 다운로드한 패키지를 확인하는 데 GPG 서명을 사용해야 할지 여부를 알려준다.



Listing 4. /etc/yum.repos.d/*.repo

[ian@echidna ~]$ cat /etc/yum.repos.d/fedora-updates.repo  [updates]  name=Fedora $releasever - $basearch - Updates  failovermethod=priority  #baseurl=http://download.fedoraproject.org/pub/fedora/linux/updates/$releasever  /$basearch/  mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$r  eleasever&arch=$basearch  enabled=1  gpgcheck=1  gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch    [updates-debuginfo]  name=Fedora $releasever - $basearch - Updates - Debug  failovermethod=priority  #baseurl=http://download.fedoraproject.org/pub/fedora/linux/updates/$releasever  /$basearch/debug/  mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-deb  ug-f$releasever&arch=$basearch  enabled=0  gpgcheck=1  gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch    [updates-source]  name=Fedora $releasever - Updates Source  failovermethod=priority  #baseurl=http://download.fedoraproject.org/pub/fedora/linux/updates/$releasever  /SRPMS/  mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-sou  rce-f$releasever&arch=$basearch  enabled=0  gpgcheck=1  gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch





YUM과 RPM은 로컬 데이터베이스를 사용하여 어떤 패키지가 설치되어 있는지 확인한다. 로컬 데이터베이스에 저장되어 있는 패키지에 관한 메타데이터는 사용되는 저장소에서 검색된다. 로컬 데이터베이스에 대해 걱정할 필요는 거의 없겠지만, yum clean 명령을 사용하여 로컬에 저장된 다양한 정보를 정리하고 yum makecache 명령을 사용하여 사용하는 repo에 관한 정보를 로컬 데이터베이스에서 작성한다. 예를 들어, repo 구성을 변경하는 경우 이 작업을 하게 될 것이다.






RPM 패키지 제거


패키지를 제거하려면 yum의 remove 옵션이나 rpm의 -e 옵션을 사용하면 된다. rpm -e를 사용하여 gcl을 제거하기 위한 테스트 실행이 Listing 5에 표시되어 있다. 패키지를 제거할 수 있는 경우 출력은 없다.



Listing 5. gcl 제거 테스트

[root@echidna ~]# rpm -e --test gcl





apt-get을 이용한 Debian 패키지의 시뮬레이션 제거와는 달리, RPM 시스템에서는 자동으로 추가된 패키지에 관한 정보는 유지하지 않으므로, 어떤 종속성도 제거될 수 있는지 찾을 수 있는 분명한 방법은 없다. 하지만, 단일 명령으로 제거할 패키지를 여러 개 지정하면 종속성을 가진 패키지에 앞서 종속성이 없는 패키지가 먼저 제거된다.


rpm을 사용하여 패키지를 제거하는 경우, 패키지를 설치할 때와는 달리 패키지가 제거되기 전에는 프롬프트가 나타나지 않는다. 하지만, 다른 패키지에 필수적인 패키지를 제거하려 하는 경우 제거 작업이 수행되지 않고 Listing 6에 표시된 것과 같은 오류 메시지가 나타난다.



Listing 6. rpm으로 종속 패키지 제거

[root@echidna ~]# rpm -e gcl-selinux  error: Failed dependencies:   gcl-selinux is needed by (installed) gcl-2.6.8-0.7.20100201cvs.fc12.x86_64





yum remove를 대신 사용하는 경우에는 트랜잭션 테스트가 수행된 후 프롬프트가 표시된다. 제거하려는 패키지가 설치된 다른 패키지에 대한 종속 패키지인 경우에는, Listing 7에 나타낸 것처럼 YUM이 해당 패키지뿐 아니라 종속 패키지까지 제거한다.



Listing 7. yum으로 종속 패키지 제거

[root@echidna ~]# yum remove gcl-selinux  Loaded plugins: presto, refresh-packagekit  Setting up Remove Process  Resolving Dependencies  --> Running transaction check  ---> Package gcl-selinux.x86_64 0:2.6.8-0.7.20100201cvs.fc12 set to be erased  --> Processing Dependency: gcl-selinux for package: gcl-2.6.8-0.7.20100201cvs.fc12.x86_64  --> Running transaction check  ---> Package gcl.x86_64 0:2.6.8-0.7.20100201cvs.fc12 set to be erased  --> Finished Dependency Resolution    Dependencies Resolved    =====================================================================================   Package          Arch        Version                            Repository     Size  =====================================================================================  Removing:   gcl-selinux      x86_64      2.6.8-0.7.20100201cvs.fc12         @updates       90 k  Removing for dependencies:   gcl              x86_64      2.6.8-0.7.20100201cvs.fc12         @updates       40 M    Transaction Summary  =====================================================================================  Remove        2 Package(s)  Reinstall     0 Package(s)  Downgrade     0 Package(s)    Is this ok [y/N]: n  Exiting on user Command  Complete!  









RPM 패키지 업그레이드


이제 RPM을 설치 및 제거하는 방법을 알고 있으므로, RPM 패키지를 새 레벨로 업그레이드하는 방법을 살펴보자. yum update를 사용하여 전체 시스템을 업데이트하거나 단일 패키지 또는 와일드카드 스펙을 지정할 수 있다. Listing 8은 이름이 "gr"로 시작되는 패키지를 전부 업데이트하는 방법을 설명한 것이다. 아포스트로피를 사용하여 "*"의 쉘 확장을 막는다는 점에 유의한다.



Listing 8. yum update를 이용한 업데이트

[root@echidna ~]# yum update 'gr*'  Loaded plugins: presto, refresh-packagekit  Setting up Update Process  Resolving Dependencies  --> Running transaction check  ---> Package grep.x86_64 0:2.6.3-1.fc12 set to be updated  ---> Package groff.x86_64 0:1.18.1.4-20.fc12 set to be updated  --> Finished Dependency Resolution    Dependencies Resolved    =====================================================================================   Package         Arch             Version                    Repository         Size  =====================================================================================  Updating:   grep            x86_64           2.6.3-1.fc12               updates           228 k   groff           x86_64           1.18.1.4-20.fc12           updates           1.5 M    Transaction Summary  =====================================================================================  Install       0 Package(s)  Upgrade       2 Package(s)    Total download size: 1.7 M  Is this ok [y/N]: y  Downloading Packages:  Setting up and reading Presto delta metadata  Processing delta metadata  Download delta size: 854 k  http://fedora.fastsoft.net/pub/linux/fedora/linux/updates/12/x86_64/drpms/grep-2.5.3-  6.fc12_2.6.3-1.fc12.x86_64.drpm: [Errno 14] HTTP Error 404 : http://fedora.fastsoft.n  et/pub/linux/fedora/linux/updates/12/x86_64/drpms/grep-2.5.3-6.fc12_2.6.3-1.fc12.x86_  64.drpm   Trying other mirror.  (1/2): grep-2.5.3-6.fc12_2.6.3-1.fc12.x86_64.drpm             | 214 kB     00:00       (2/2): groff-1.18.1.4-18.fc12_1.18.1.4-20.fc12.x86_64.drpm    | 640 kB     00:00       Finishing rebuild of rpms, from deltarpms  <delta rebuild>                                               | 1.7 MB     00:02       Presto reduced the update size by 52% (from 1.7 M to 854 k).  Running rpm_check_debug  Running Transaction Test  Transaction Test Succeeded  Running Transaction    Updating       : grep-2.6.3-1.fc12.x86_64                                      1/4     Updating       : groff-1.18.1.4-20.fc12.x86_64                                 2/4     Cleanup        : grep-2.5.3-6.fc12.x86_64                                      3/4     Cleanup        : groff-1.18.1.4-18.fc12.x86_64                                 4/4     Updated:    grep.x86_64 0:2.6.3-1.fc12             groff.x86_64 0:1.18.1.4-20.fc12                Complete!





RPM 파일이 있는 곳을 알거나 RPM 파일을 다운로드한 경우, rpm 명령을 사용하여 업데이트할 수도 있다. 이는 -i 옵션 대신 -U 또는 -F 옵션을 사용하는 점을 제외하면 설치와 유사하다. 이 두 옵션의 차이점은 -U 옵션을 사용하면 기존 패키지가 업그레이드되거나 이미 설치된 패키지가 없는 경우 패키지가 설치되는 반면, -F 옵션을 사용하면 이미 설치된 패키지만 업그레이드되거나 새로 갱신된다는 점이다. 이 때문에, 특히 명령행에 RPM 목록이 포함되어 있을 때 -U 옵션이 자주 사용된다. 이런 식으로, 설치 안 된 패키지가 설치되고 이미 설치된 패키지는 업그레이드된다. 진행률을 나타내기 위해 -v(verbose) 및 -h(hash 표시)의 두 가지 다른 옵션이 자주 사용된다. Listing 9는 rpm 명령을 사용하여 vim-common, vim-enhanced 및 vim-minimal 패키지를 업데이트하는 방법을 나타낸 것이다. 루트의 홈 디렉토리에 이미 다운로드한 vim-common 및 vim-enhanced 패키지가 있으며, 업데이트 미러 중 하나에서 vim-minimal 패키지를 검색한다.



Listing 9. rpm을 이용한 패키지 업데이트

[root@echidna ~]# ls *.rpm  vim-common-7.2.411-1.fc12.x86_64.rpm  vim-enhanced-7.2.411-1.fc12.x86_64.rpm  [root@echidna ~]# rpm -Uvh *.rpm http://mirrors.usc.edu/pub/linux/distributions\  > /fedora/linux/updates/12/x86_64/vim-minimal-7.2.411-1.fc12.x86_64.rpm  Retrieving http://mirrors.usc.edu/pub/linux/distributions/fedora/linux/updates/12/x86  _64/vim-minimal-7.2.411-1.fc12.x86_64.rpm  Preparing...                ########################################### [100%]     1:vim-common             ########################################### [ 33%]     2:vim-enhanced           ########################################### [ 67%]     3:vim-minimal            ########################################### [100%]  









RPM 패키지 쿼리


앞의 예에서 rpm 명령으로 rpm을 설치하려면 gcl-2.6.8-0.6.20090701cvs.fc12.x86_64.rpm과 같은 패키지 파일의 전체 이름(또는 URL)이 필요하다. 이에 반해, yum으로 설치하거나 어느 한 명령으로 rpm을 제거하려면 gcl과 같은 패키지 이름만 있으면 된다. APT와 마찬가지로, RPM은 설치된 패키지의 내부 데이터베이스를 유지하므로, 패키지 이름을 사용하여 설치된 패키지를 조작할 수 있다. 이 섹션에서는 rpm 명령의 -q(query) 옵션이나 연관된 yum 쿼리를 사용하여 이 데이터베이스에서 사용 가능한 몇 가지 정보를 살펴본다.


기본 쿼리에서는 단순히 패키지 설치 여부만 묻고, 설치된 경우 어떤 버전인지 묻는다. -i 옵션을 추가하고 패키지에 관한 정보를 얻는다. 패키지를 설치, 업그레이드 또는 제거하려면 루트 권한이 있어야 하지만, 루트 권한이 없는 사용자는 rpm 데이터베이스를 상대로 쿼리를 수행할 수 있다.



Listing 10. gcl에 관한 정보 표시

                      [ian@echidna ~]$ yum list gcl  Loaded plugins: presto, refresh-packagekit  Installed Packages  gcl.x86_64                  2.6.8-0.7.20100201cvs.fc12                  @updates  [ian@echidna ~]$ rpm -q gcl  gcl-2.6.8-0.7.20100201cvs.fc12.x86_64    [ian@echidna ~]$ yum info gcl  Loaded plugins: presto, refresh-packagekit  Installed Packages  Name       : gcl  Arch       : x86_64  Version    : 2.6.8  Release    : 0.7.20100201cvs.fc12  Size       : 40 M  Repo       : installed  From repo  : updates  Summary    : GNU Common Lisp  URL        : http://www.gnu.org/software/gcl/  License    : GPL+ and LGPLv2+  Description: GCL is a Common Lisp currently compliant with the ANSI standard.             : Lisp compilation produces native code through the intermediary of             : the system's C compiler, from which GCL derives efficient             : performance and facile portability. Currently uses TCL/Tk as GUI.    [ian@echidna ~]$ rpm -qi gcl  Name        : gcl                          Relocations: (not relocatable)  Version     : 2.6.8                             Vendor: Fedora Project  Release     : 0.7.20100201cvs.fc12          Build Date: Tue 23 Mar 2010 03:20:36 PM EDT  Install Date: Wed 05 May 2010 01:01:34 PM EDT      Build Host: x86-02.phx2.fedoraproject.  org  Group       : Development/Languages         Source RPM: gcl-2.6.8-0.7.20100201cvs.fc12.sr  c.rpm  Size        : 41667750                         License: GPL+ and LGPLv2+  Signature   : RSA/8, Tue 23 Mar 2010 04:14:06 PM EDT, Key ID 9d1cc34857bbccba  Packager    : Fedora Project  URL         : http://www.gnu.org/software/gcl/  Summary     : GNU Common Lisp  Description :  GCL is a Common Lisp currently compliant with the ANSI standard.  Lisp  compilation produces native code through the intermediary of the  system's C compiler, from which GCL derives efficient performance and  facile portability. Currently uses TCL/Tk as GUI.





더 광범위한 목록에는 RPM 패키지와 연관될 수 있는 태그 중 일부도 함께 표시된다. rpm과 yum은 약간 다른 형식으로 약간 다른 정보를 표시하는 것을 알 수 있다. 본 기사에서는 표준 출력 옵션에서 제공하는 기본 출력을 고수하기로 한다. rpm --queryformat 옵션을 사용하여 사용자 정의 쿼리 출력을 빌드하려면 매뉴얼 페이지를 참조한다. 가지고 있는 rpm 버전에서 지원하는 모든 태그를 알고 싶으면 rpm --querytags를 실행해보면 된다.


Listing 10에 나타낸 것처럼, yum을 사용하여 설치된 패키지를 나열할 수 있다. 또한, 사용 가능한 업데이트가 있는 패키지, 설치를 위해 사용 가능한 패키지, 사용되지 않음 또는 최근에 저장소에 추가됨과 같은 다른 특성을 가진 패키지를 나열할 수도 있다. 더구나 yum을 사용하여 패키지를 검색할 수도 있다. Listing 11에는 texmacs 패키지는 설치되어 있지 않지만 fedora 저장소에서 사용 가능한 것을 볼 수 있다. "texmacs"를 검색하면 texmacs를 언급하는 4개의 패키지가 나타난다. TeXmacs* 패키지가 검색된 이유를 쉽게 알 수 있다. yum info pydot를 사용하여 pydot 패키지도 언급된 이유를 찾아낸다.



Listing 11. gcl에 관한 정보 표시

                      [ian@echidna ~]$ yum list texmacs  Loaded plugins: presto, refresh-packagekit  Available Packages  TeXmacs.x86_64                         1.0.7.2-2.fc12                          fedora  [ian@echidna ~]$ yum search texmacs  Loaded plugins: presto, refresh-packagekit  ================================= Matched: texmacs ==================================  TeXmacs-devel.i686 : Development files for TeXmacs  TeXmacs-devel.x86_64 : Development files for TeXmacs  TeXmacs.x86_64 : Structured wysiwyg scientific text editor  pydot.noarch : Python interface to Graphviz's Dot language  





나머지 쿼리 예제에서는 주로 rpm을 사용하는데, 여기에 더 광범위한 옵션 세트가 있기 때문이다. 이들 예제 중 다수는 yum으로도 수행할 수 있는데, yum에는 기본적인 rpm 옵션에는 없는 기능이 몇 가지 있다. 자세한 내용은 매뉴얼 페이지를 참조한다.


RPM 패키지와 그에 포함된 파일


패키지에 무엇이 들어 있는지, 특정 파일이 어떤 패키지에 있던 것인지 등을 알고 싶을 때가 종종 있을 것이다. gcl 패키지에 있는 파일 목록을 보려면 Listing 12에 나타낸 것처럼 -ql 옵션을 사용한다. 이 패키지에는 수많은 파일이 있으므로, 출력 중 일부만 표시했다.



Listing 12. gcl 패키지에 있는 파일 표시

[ian@echidna ~]$ rpm -ql gcl  /usr/bin/gcl  /usr/lib/gcl-2.6.8  /usr/lib/gcl-2.6.8/clcs  /usr/lib/gcl-2.6.8/clcs/sys-proclaim.lisp  /usr/lib/gcl-2.6.8/cmpnew  /usr/lib/gcl-2.6.8/cmpnew/gcl_cmpmain.lsp  /usr/lib/gcl-2.6.8/cmpnew/gcl_cmpopt.lsp  /usr/lib/gcl-2.6.8/cmpnew/gcl_collectfn.lsp  .  .  .  /usr/share/info/gcl-tk.info.gz  /usr/share/info/gcl.info-1.gz  /usr/share/info/gcl.info-2.gz  /usr/share/info/gcl.info-3.gz  /usr/share/info/gcl.info-4.gz  /usr/share/info/gcl.info-5.gz  /usr/share/info/gcl.info-6.gz  /usr/share/info/gcl.info-7.gz  /usr/share/info/gcl.info-8.gz  /usr/share/info/gcl.info-9.gz  /usr/share/info/gcl.info.gz  /usr/share/man/man1/gcl.1.gz





쿼리에 -c 옵션을 추가하여 나열되는 파일을 구성 파일로만 한정할 수 있다. 이와 유사하게, -d 옵션을 사용하면 표시되는 파일이 문서 파일만으로 제한된다.


패키지 파일 쿼리


위 패키지 쿼리 명령은 RPM 데이터베이스에 설치된 패키지에 대해 쿼리한다. 방금 패키지를 다운로드한 상태에서 같은 종류의 정보를 원하는 경우, (패키지 설치에 사용할) 패키지 파일 이름을 지정하는 것 외에도, 쿼리에 -p(package file) 옵션을 사용하여 이 정보를 얻을 수 있다. Listing 13에는 앞서 다운로드한 두 vim 패키지에 대해 이 정보가 표시된다. 파일이 루트의 홈 디렉토리에 있었기 때문에 이것을 루트로만 실행한다. -l과 같은 다른 쿼리 옵션을 추가하여 파일 목록을 표시하거나 -i 옵션을 추가하여 정보를 나열할 수 있다.



Listing 13. 두 개의 vim 패키지에 대한 패키지 파일 정보 표시

[root@echidna ~]# rpm -qp *.rpm  vim-common-7.2.411-1.fc12.x86_64  vim-enhanced-7.2.411-1.fc12.x86_64





설치된 모든 패키지 쿼리


-a 옵션을 사용하면 설치된 모든 패키지에 쿼리가 적용된다. 이렇게 하면 많은 출력이 생성될 수 있으므로 대개의 경우 하나 이상의 필터와 함께 이 옵션을 사용하는데, 목록을 정렬하려면 sort, 목록 페이지를 전후로 이동하려면 more 또는 less, 패키지 또는 파일 수를 확인하려면 wc, 이름이 확실치 않아 패키지를 검색하려면 grep을 사용한다. Listing 14는 다음 쿼리를 나타낸 것이다.


시스템에 있는 모든 패키지가 정렬되어 표시되는 목록


시스템에 있는 모든 패키지의 개수


시스템에 있는 모든 패키지에 있는 모든 파일의 개수


RPM과 함께 설치된 모든 문서 파일의 개수


이름에 "gcl"(대/소문자 구분)이 포함된 모든 패키지 검색





Listing 14. 모든 패키지에 대한 쿼리

                      [ian@echidna ~]$ rpm -qa | sort | more  aalib-libs-1.4.0-0.18.rc5.fc12.x86_64  abrt-1.0.8-2.fc12.x86_64  abrt-addon-ccpp-1.0.8-2.fc12.x86_64  abrt-addon-kerneloops-1.0.8-2.fc12.x86_64  abrt-addon-python-1.0.8-2.fc12.x86_64  abrt-desktop-1.0.8-2.fc12.x86_64  abrt-gui-1.0.8-2.fc12.x86_64  abrt-libs-1.0.8-2.fc12.x86_64  abrt-plugin-bugzilla-1.0.8-2.fc12.x86_64  abrt-plugin-logger-1.0.8-2.fc12.x86_64  abrt-plugin-runapp-1.0.8-2.fc12.x86_64  abyssinica-fonts-1.0-5.fc12.noarch  acl-2.2.49-2.fc12.x86_64  ...  [ian@echidna ~]$ rpm -qa | wc -l  1792  [ian@echidna ~]$ rpm -qal | wc -l  281052  [ian@echidna ~]$ rpm -qad | wc -l  45686  [ian@echidna ~]$ rpm -qa | grep -i gcl  gcl-selinux-2.6.8-0.7.20100201cvs.fc12.x86_64  gcl-2.6.8-0.7.20100201cvs.fc12.x86_64  





rpm -qa를 사용하면 여러 시스템을 손쉽게 관리할 수 있다. 한 시스템에 있는 파일로 정렬된 출력을 리디렉션한 후 다른 시스템에서도 똑같이 하는 경우, diff 프로그램을 사용하면 차이점을 찾을 수 있다.


어떤 패키지가 파일을 소유하고 있는가?


모든 패키지와 패키지에 있는 모든 파일의 목록을 표시할 수 있으므로, 어떤 패키지에 어떤 파일이 있는지 찾기 위해 필요한 정보를 모두 가지고 있는 셈이다. 하지만, rpm 명령을 사용할 때 -f(또는 --file) 옵션을 추가하면 어떤 파일이 있는 패키지를 찾는 데 도움이 된다. 앞서 본 vim 패키지 중 어떤 패키지에서 실제로 vim 명령을 제공하는지 알고 싶다고 해보자. 파일의 전체 경로가 필요할 것이다. Listing 15는 which 명령을 사용하여 vim 명령에 대한 전체 경로를 찾는 방법과 이 출력을 rpm -qf 명령에 대한 입력으로 사용하기 위한 편리한 팁을 나타낸 것이다. `which guile-config`를 둘러싼 눈금 표시가 역방향의 눈금으로 표시된다는 점에 유의한다. Bash 쉘에서 이것을 다르게 사용하는 방법은 $(which vim)을 사용하는 것이다.



Listing 15. vim 실행 파일을 제공하는 패키지 찾기

                      [ian@echidna ~]$ which vim  /usr/bin/vim  [ian@echidna ~]$ rpm -qf `which vim`  vim-enhanced-7.2.411-1.fc12.x86_64  [ian@echidna ~]$ rpm -qf $(which vim)  vim-enhanced-7.2.411-1.fc12.x86_64





RPM 종속성


앞에서 종속성 때문에 gcl-selinux 패키지 지우기에 실패한 것을 보았다. 파일 외에도, RPM 패키지에는 다른 패키지가 종속될 수 있는 임의의 기능이 포함될 수 있다.


앞서 본 바와 같이, 이 문제는 보통 잘 풀린다. 한 번에 여러 개의 패키지를 설치해야 하고 이들 중 일부 패키지가 다른 패키지에 종속될 수 있는 경우에는 단순히 yum을 사용하거나 rpm -Uvh 명령에 전체 목록을 제공하면 종속성이 분석되고 설치 작업이 올바른 순서로 수행된다.


패키지를 설치하거나 지우고 오류 메시지를 받는 것 외에도, 패키지에서 꼭 필요하거나 패키지가 종속되는 파일이나 기능이 무엇인지 찾는 방법이 있다.


rpm 명령에서는 설치된 패키지나 패키지 파일이 어떤 기능에 종속되거나 어떤 기능을 요구하는지 찾기 위해 이런 패키지나 패키지 파일을 조사하는 옵션을 제공한다. 이는 --requires 옵션으로, -R로 줄여서 표시할 수 있다. Listing 16은 gcl에서 필수적인 기능을 나타낸 것이다. RPM 데이터베이스 대신 패키지 파일을 쿼리하려면 -p 옵션을 추가하고 전체 RPM 파일 이름을 사용한다.



Listing 16. gcl에서 필수적인 것

[ian@echidna ~]$ rpm -qR gcl  /bin/sh    /bin/sh    /bin/sh    /sbin/install-info    /sbin/install-info    gcl-selinux    libX11.so.6()(64bit)    libc.so.6()(64bit)    libc.so.6(GLIBC_2.11)(64bit)    libc.so.6(GLIBC_2.2.5)(64bit)    libc.so.6(GLIBC_2.3)(64bit)    libc.so.6(GLIBC_2.3.4)(64bit)    libc.so.6(GLIBC_2.4)(64bit)    libc.so.6(GLIBC_2.7)(64bit)    libc.so.6(GLIBC_2.8)(64bit)    libdl.so.2()(64bit)    libgmp.so.3()(64bit)    libm.so.6()(64bit)    libm.so.6(GLIBC_2.2.5)(64bit)    libreadline.so.6()(64bit)    libtcl8.5.so()(64bit)    libtk8.5.so()(64bit)    libz.so.1()(64bit)    rpmlib(CompressedFileNames) <= 3.0.4-1  rpmlib(FileDigests) <= 4.6.0-1  rpmlib(PayloadFilesHavePrefix) <= 4.0-1  rtld(GNU_HASH)    rpmlib(PayloadIsXz) <= 5.2-1  





기능과 그 기능을 제공하는 패키지를 일치시키는 것은 다소 미묘한 문제일 수 있다. 여기서는 yum 명령과 deplist 옵션을 함께 사용하면 도움이 될 수 있다. 해당 버전에서 규정되지 않은 패키지 이름만 제공하면 알려진 다른 버전에 대한 목록을 얻을 수 있다. Listing 17은 설치되어 있는 gcl의 버전에 대한 종속성 목록만 얻는 방법을 나타낸 것이다.



Listing 17. yum deplist를 사용하여 gcl에서 필요한 것을 찾는 방법

[ian@echidna ~]$ yum deplist $(rpm -q gcl)  Loaded plugins: presto, refresh-packagekit  Finding dependencies:   package: gcl.x86_64 2.6.8-0.7.20100201cvs.fc12    dependency: libc.so.6(GLIBC_2.3.4)(64bit)     provider: glibc.x86_64 2.11-2     provider: glibc.x86_64 2.11.1-6    dependency: gcl-selinux     provider: gcl-selinux.x86_64 2.6.8-0.6.20090701cvs.fc12     provider: gcl-selinux.x86_64 2.6.8-0.7.20100201cvs.fc12    dependency: libgmp.so.3()(64bit)     provider: gmp.x86_64 4.3.1-5.fc12    dependency: libc.so.6(GLIBC_2.8)(64bit)     provider: glibc.x86_64 2.11-2     provider: glibc.x86_64 2.11.1-6    dependency: libc.so.6(GLIBC_2.4)(64bit)     provider: glibc.x86_64 2.11-2     provider: glibc.x86_64 2.11.1-6    dependency: libc.so.6()(64bit)     provider: glibc.x86_64 2.11-2     provider: glibc.x86_64 2.11.1-6    dependency: /sbin/install-info     provider: info.x86_64 4.13a-7.fc12     provider: info.x86_64 4.13a-9.fc12    dependency: libX11.so.6()(64bit)     provider: libX11.x86_64 1.3-1.fc12    dependency: libc.so.6(GLIBC_2.7)(64bit)     provider: glibc.x86_64 2.11-2     provider: glibc.x86_64 2.11.1-6    dependency: libtcl8.5.so()(64bit)     provider: tcl.x86_64 1:8.5.7-4.fc12     provider: tcl.x86_64 1:8.5.7-5.fc12    dependency: libc.so.6(GLIBC_2.11)(64bit)     provider: glibc.x86_64 2.11-2     provider: glibc.x86_64 2.11.1-6    dependency: libtk8.5.so()(64bit)     provider: tk.x86_64 1:8.5.7-2.fc12     provider: tk.x86_64 1:8.5.7-3.fc12    dependency: libc.so.6(GLIBC_2.3)(64bit)     provider: glibc.x86_64 2.11-2     provider: glibc.x86_64 2.11.1-6    dependency: libm.so.6()(64bit)     provider: glibc.x86_64 2.11-2     provider: glibc.x86_64 2.11.1-6    dependency: libz.so.1()(64bit)     provider: zlib.x86_64 1.2.3-23.fc12    dependency: rtld(GNU_HASH)     provider: glibc.i686 2.11-2     provider: glibc.x86_64 2.11-2     provider: glibc.x86_64 2.11.1-6     provider: glibc.i686 2.11.1-6    dependency: libdl.so.2()(64bit)     provider: glibc.x86_64 2.11-2     provider: glibc.x86_64 2.11.1-6    dependency: libreadline.so.6()(64bit)     provider: readline.x86_64 6.0-3.fc12    dependency: /bin/sh     provider: bash.x86_64 4.0.33-1.fc12     provider: bash.x86_64 4.0.35-3.fc12    dependency: libc.so.6(GLIBC_2.2.5)(64bit)     provider: glibc.x86_64 2.11-2     provider: glibc.x86_64 2.11.1-6    dependency: libm.so.6(GLIBC_2.2.5)(64bit)     provider: glibc.x86_64 2.11-2     provider: glibc.x86_64 2.11.1-6





이 목록에는 각각의 기능에 대해 가능한 공급자도 표시된다. 한 패키지에 대해 둘 이상의 다른 레벨에서 대부분의 종속성이 제공될 수 있음을 알 수 있다. 예를 들어, /bin/sh는 두 가지 레벨의 bash 중 하나에서 가져올 수 있다. Listing 18에 나타낸 것처럼, 약간 창의적인 필터링을 이용해 이 출력을 패키지 이름 목록으로 줄일 수 있다.



Listing 18. 패키지 이름만 표시하도록 yum deplist 출력을 줄이는 방법

[ian@echidna ~]$ yum deplist $(rpm -q gcl) | grep "provider:" | \  > awk '{ print $2 }'|sort|uniq  bash.x86_64  gcl-selinux.x86_64  glibc.i686  glibc.x86_64  gmp.x86_64  info.x86_64  libX11.x86_64  readline.x86_64  tcl.x86_64  tk.x86_64  zlib.x86_64





어떤 패키지를 설치해야 할 것인지만 알면 되는 경우, 항상 yum install을 실행하면 설치 제안 사항에 동의하라는 프롬프트가 나타나기 전에 목록부터 확인할 수 있다.


패키지에서 어떤 기능이 필요한지 알아내는 것 외에도, 어떤 패키지에서 특정 기능을 제공하는지 알아내야 할 수도 있다. 위에서 어떤 패키지가 특정 파일을 소유하고 있는지 찾는 방법을 살펴보았다. Listing 19는 rpm 또는 yum을 사용하여 어떤 패키지에서 gcl-selinux(x86-64) 기능을 제공하는지 찾는 방법을 나타낸 것이다. 설치된 패키지 중 해당 기능을 제공하는 패키지에 관한 정보 외에, YUM을 사용하면 저장소에서 사용 가능한 패키지나 버전도 표시된다. 이들은 fedora 저장소에 있는 원본 2.6.8-0.6 버전과 업데이트 저장소에서 구할 수 있는 업데이트된 2.6.8-0.7 버전이다.



Listing 19. gcl-selinux(x86-64) 기능을 제공하는 패키지 찾기

[ian@echidna ~]$ rpm -q --whatprovides 'gcl-selinux(x86-64)'  gcl-selinux-2.6.8-0.7.20100201cvs.fc12.x86_64  [ian@echidna ~]$ yum whatprovides 'gcl-selinux(x86-64)'  Loaded plugins: presto, refresh-packagekit  gcl-selinux-2.6.8-0.6.20090701cvs.fc12.x86_64 : SELinux policy for GCL images  Repo        : fedora  Matched from:  Other       : gcl-selinux(x86-64)        gcl-selinux-2.6.8-0.7.20100201cvs.fc12.x86_64 : SELinux policy for GCL images  Repo        : updates  Matched from:  Other       : gcl-selinux(x86-64)        gcl-selinux-2.6.8-0.7.20100201cvs.fc12.x86_64 : SELinux policy for GCL images  Repo        : installed  Matched from:  Other       : Provides-match: gcl-selinux(x86-64)









RPM 패키지 파일의 무결성


무결성 확인을 위해, RPM 패키지에는 MD5 또는 SHA1과 같은 다이제스트가 포함되어 있고 보통 디지털 서명이 되어 있다. 디지털 서명이 되어 있는 패키지는 확인을 위한 공개 키가 필요하다. RPM 패키지 파일의 무결성을 확인하려면 rpm의 --checksig(약어는 -K) 옵션을 사용한다. 일반적으로 더 자세한 출력을 얻으려면 -v 옵션을 추가하는 것이 유용하다는 사실을 알 수 있을 것이다. Listing 20은 vim-enhanced RPM에 대한 예제를 나타낸 것이다.



Listing 20. vim-enhanced 패키지 파일의 무결성 확인

                      [root@echidna ~]# rpm -vK vim-enhanced-7.2.411-1.fc12.x86_64.rpm  vim-enhanced-7.2.411-1.fc12.x86_64.rpm:      Header V3 RSA/SHA256 signature: OK, key ID 57bbccba      Header SHA1 digest: OK (f9a199545a515f7ff0716729768b41eb68fe29a8)      V3 RSA/SHA256 signature: OK, key ID 57bbccba      MD5 digest: OK (d4045f1f72d48073e3f401ee9d1f71cf)





다음과 같은 출력 행이 나타날 수 있다.


V3 DSA 서명: NOKEY, 키 ID 16a61572


이것은 서명된 패키지는 있지만 RPM 데이터베이스에 필요한 공개 키는 없다는 의미이다. RPM의 이전 버전에서는 다른 확인 결과를 표시할 수도 있다.


어떤 패키지가 서명되어 있고 이를 어떤 서명에 대해 확인하려는 경우, 알맞은 서명 파일을 찾아서 RPM 데이터베이스로 가져와야 한다. 우선, 키를 다운로드하고 키의 지문을 확인한 후 rpm --import 명령을 사용하여 키를 가져와야 한다. 자세한 내용은 RPM 매뉴얼 페이지를 참조한다. RPM 홈 페이지(링크는 참고자료 참조)에서 서명된 2진 파일에 관한 자세한 내용을 확인할 수도 있다.






설치된 패키지 확인


rpm의 무결성 확인과 같이, rpm -V를 사용하여 설치된 파일의 무결성을 확인할 수도 있다. 이 단계에서는 rpm에서 파일이 설치된 이후로 파일이 수정된 적이 없음을 확인한다. Listing 21에 표시된 것처럼, 패키지가 여전히 양호한 상태이면 이 명령을 실행할 때 아무 것도 출력되지 않지만, -v 옵션을 추가하면 훨씬 더 자세한 출력 결과를 얻을 수 있다.



Listing 21. 설치된 vim-common 패키지 확인

                      [ian@echidna ~]$ rpm -V vim-common





루트 권한을 가진 상태에서 /usr/bin/xxd를 삭제하고 /usr/share/vim/vim72/syntax/bindzone.vim /bin/bash를 바꾸어 vim-common 설치를 손상시켜 보자. 그리고 다시 확인을 해보자. Listing 22에 결과가 표시된다.



Listing 22. vim-common 패키지 무단 변경

                      [root@echidna ~]# rpm -qf /usr/bin/xxd /usr/share/vim/vim72/syntax/bindzone.vim  vim-common-7.2.411-1.fc12.x86_64  vim-common-7.2.411-1.fc12.x86_64  [root@echidna ~]# rm /usr/bin/xxd  rm: remove regular file `/usr/bin/xxd'? y  [root@echidna ~]# cp /bin/bash /usr/share/vim/vim72/syntax/bindzone.vim  cp: overwrite `/usr/share/vim/vim72/syntax/bindzone.vim'? y  [root@echidna ~]# rpm -V vim-common  missing     /usr/bin/xxd  S.5....T.    /usr/share/vim/vim72/syntax/bindzone.vim





이 출력 결과는 /usr/share/vim/vim72/syntax/bindzone.vim 파일이 MD5 합계, 파일 크기 및 mtime 테스트에 실패하는 것을 나타낸다. 이 문제를 해결하는 한 가지 방법은 패키지를 제거한 후 다시 설치하는 것이지만, vim-common에 종속되고 여전히 양호한 상태로 설치되어 있는 다른 패키지가 있다. 이에 대한 해결책은 rpm의 --force 옵션 또는 yum의 reinstall 함수를 사용하여 패키지를 강제로 다시 설치하는 것이다. Listing 23은 yum으로 다시 설치한 후 패키지가 현재 양호하고 삭제된 파일이 복원되었는지 확인하는 방법을 나타낸 것이다.



Listing 23. vim-common 패키지 다시 설치

                      [root@echidna ~]# yum reinstall vim-common  Loaded plugins: presto, refresh-packagekit  Setting up Reinstall Process  Resolving Dependencies  --> Running transaction check  ---> Package vim-common.x86_64 2:7.2.411-1.fc12 set to be updated  --> Finished Dependency Resolution    Dependencies Resolved    =====================================================================================   Package            Arch           Version                     Repository       Size  =====================================================================================  Reinstalling:   vim-common         x86_64         2:7.2.411-1.fc12            updates         6.0 M    Transaction Summary  =====================================================================================  Remove        0 Package(s)  Reinstall     1 Package(s)  Downgrade     0 Package(s)    Total download size: 6.0 M  Installed size: 17 M  Is this ok [y/N]: y  Downloading Packages:  Setting up and reading Presto delta metadata  updates/prestodelta                                           | 969 kB     00:00       Processing delta metadata  Package(s) data still to download: 6.0 M  vim-common-7.2.411-1.fc12.x86_64.rpm                          | 6.0 MB     00:01       Running rpm_check_debug  Running Transaction Test  Transaction Test Succeeded  Running Transaction  Warning: RPMDB altered outside of yum.    Installing     : 2:vim-common-7.2.411-1.fc12.x86_64                            1/1     Installed:    vim-common.x86_64 2:7.2.411-1.fc12                                                     Complete!  [root@echidna ~]# rpm -V vim-common  [root@echidna ~]# ls /usr/bin/xxd  /usr/bin/xxd  





더 강력한 기능이 필요한 경우


대체로 패키지 관리 시스템에서는 패키지를 순서대로 보관한다. 하지만, 패키지의 중요한 부분인 어떤 파일을 어떻게 해서든 삭제하고—패키지를 제거하지 않고 다시 설치해도 문제가 해결되지 않는 경우—패키지를 제거한 후 다시 설치해야 할 수도 있다. 그런 경우, 아마 기존 사본에 종속되지 않는 모든 패키지를 설치 제거하고 다시 설치할 필요 없이 기존 사본을 삭제하고 다시 설치하고 싶을 것이다. 이렇게 하려면 패키지를 제거할 때 rpm 명령의 --nodeps 옵션을 사용하여 종속성 확인을 생략하면 된다. Listing 24는 앞서 실습한 것처럼 이렇게 하면 vim-common 패키지의 일부인 /usr/bin/xxd 파일을 실수로 제거한 경우 어떻게 되는지를 나타낸 것이다.



Listing 24. rpm을 이용한 패키지 업데이트

[root@echidna ~]# rm /usr/bin/xxd  rm: remove regular file `/usr/bin/xxd'? y  [root@echidna ~]# # Oops! we needed that file  [root@echidna ~]# rpm -Fvh vim-common-7.2.411-1.fc12.x86_64.rpm   [root@echidna ~]# ls /usr/bin/xxd  ls: cannot access /usr/bin/xxd: No such file or directory  [root@echidna ~]# # Oh! Freshening the package didn't replace the missing file  [root@echidna ~]# rpm -e vim-common  error: Failed dependencies:   vim-common = 2:7.2.411-1.fc12 is needed by (installed) vim-enhanced-2:7.2.411-1.f  c12.x86_64  [root@echidna ~]# # Can't remove vim-common because vim-enhanced needs it  [root@echidna ~]# rpm -e --nodeps vim-common  [root@echidna ~]# # Bypassing the dependency check allowed removal  [root@echidna ~]# rpm -Uvh vim-common-7.2.411-1.fc12.x86_64.rpm   Preparing...                ########################################### [100%]     1:vim-common             ########################################### [100%]  [root@echidna ~]# # Update (or install) vim-common again  [root@echidna ~]# ls /usr/bin/xxd  /usr/bin/xxd  [root@echidna ~]# # And /usr/bin/xxd is back  





이제는 사고가 발생하여 통상적인 업데이트 프로세스에 실패하는 경우 업데이트하거나 복구하기 위한 몇 가지 접근 방식을 알게 되었을 것이다. RPM을 설치할 때 종속성 확인을 생략할 수도 있지만, 이는 대체로 좋은 방법이 아니다.






저장소에서 RPM 다운로드


yum을 사용하면 저장소에서 패키지가 자동으로 검색되지만, 네트워크로 연결되지 않은 시스템에 RPM을 설치하거나 그 내용을 검사하거나 다른 이유로 RPM을 다운로드하여 저장하고 싶을 때가 있을 것이다. Listing 25에 나타낸 것처럼 yumdownloader 명령을 사용할 수 있다. 예제의 경우, 패키지가 이미 설치되어 있으므로 추가로 다운로드할 패키지는 없다. 그런 패키지가 있는 경우 --resolve 옵션을 사용하면 패키지도 다운로드된다.



Listing 25. gcl 패키지 다운로드

[ian@echidna ~]$ yumdownloader --resolve gcl  Loaded plugins: presto, refresh-packagekit  adobe-linux-i386                                                               17/17  --> Running transaction check  ---> Package gcl.x86_64 0:2.6.8-0.7.20100201cvs.fc12 set to be updated  --> Finished Dependency Resolution  gcl-2.6.8-0.7.20100201cvs.fc12.x86_64.rpm                     | 6.3 MB     00:01     









rpm2cpio 사용


RPM을 다운로드한 후 설치하지 않고 그 내용을 검사할 필요가 있는 경우, rpm2cpio 명령을 사용하면 내용을 cpio 아카이브로 변환한 다음 cpio 명령을 통해 아카이브를 필터링하여 패키지에 있는 개별 파일이나 모든 파일을 추출할 수 있다. Listing 26은 gcl-selinux 패키지에 대해 이 작업을 수행하는 방법과 어떤 파일과 디렉토리의 압축이 풀렸는지를 나타낸 것이다. 이들 명령에 관한 추가 정보는rpm2cpio 및 cpio의 매뉴얼 페이지를 참조한다.



Listing 26. rpm2cpio로 gcl-selinux 패키지 압축 풀기

[ian@echidna ~]$ yumdownloader gcl-selinux  Loaded plugins: presto, refresh-packagekit  gcl-selinux-2.6.8-0.7.20100201cvs.fc12.x86_64.rpm        |  17 kB     00:00       [ian@echidna ~]$ mkdir gcl-selinux  [ian@echidna ~]$ cd gcl-selinux  [ian@echidna gcl-selinux]$ rpm2cpio ../gcl-selinux*.rpm | cpio -idv  ./usr/share/selinux/packages/gcl  ./usr/share/selinux/packages/gcl/gcl.pp  182 blocks  [ian@echidna gcl-selinux]$ find .  .  ./usr  ./usr/share  ./usr/share/selinux  ./usr/share/selinux/packages  ./usr/share/selinux/packages/gcl  ./usr/share/selinux/packages/gcl/gcl.pp







RPM 찾기


앞에서 YUM이 패키지 이름뿐 아니라 설명도 검색하는 검색 기능을 제공한다는 사실을 살펴보았다. 설치되어 있지 않은 프로그램이 어떤 패키지에 들어 있는지 찾아야 하는 경우, 다른 방법이 몇 가지 있다.


어떤 패키지에 해당 프로그램이 들어 있는지 추측하여 설치는 하지 않고 패키지를 다운로드할 수 있다. 패키지를 다운로드한 후 패키지를 조사할 수 있다.


인터넷을 검색할 수 있다.


아래에서 설명하는 command-not-found 기능을 사용할 수도 있다.




시스템 도구를 통해 특정 RPM을 찾을 수 없는 경우, RPM을 찾는 데 유용한 인터넷 자원은 Rpmfind.Net 서버이다(링크는 참고자료 참조).


Command not found


Bash 쉘에서 어떤 명령을 검색했는데 찾지 못하는 경우, 쉘에서는 command_not_found_handle이라는 이름의 쉘 함수를 검색한다.command_not_found_handle 함수가 있는 경우 이 함수는 원래 명령과 원래 인수를 자신의 인수로 하여 호출되고 함수의 종료 상태는 쉘의 종료 상태가 된다. 이 함수가 정의되어 있지 않은 경우 쉘에서는 오류 메시지를 인쇄하고 종료 상태인 127을 리턴한다. 이 함수는 보통 시스템 /etc/bash.bashrc 파일에서 설정된다. Listing 27은 command-not-found 기능을 검색한 후 설치한 방법을 나타낸 것이다.



Listing 27. command-not-found 기능을 찾아서 설치하는 방법

[root@echidna ~]# yum search command-not-found  Loaded plugins: presto, refresh-packagekit  ========================== Matched: command-not-found ==========================  PackageKit-command-not-found.x86_64 : Ask the user to install command line                                      : programs automatically  You have new mail in /var/spool/mail/root  [root@echidna ~]# yum install PackageKit-command-not-found.x86_64  Loaded plugins: presto, refresh-packagekit  Setting up Install Process  Resolving Dependencies  --> Running transaction check  ---> Package PackageKit-command-not-found.x86_64 0:0.5.7-2.fc12 set to be updated  --> Finished Dependency Resolution    Dependencies Resolved    ================================================================================   Package                          Arch       Version          Repository   Size  ================================================================================  Installing:   PackageKit-command-not-found     x86_64     0.5.7-2.fc12     updates     102 k    Transaction Summary  ================================================================================  Install       1 Package(s)  Upgrade       0 Package(s)    Total download size: 102 k  Installed size: 262 k  Is this ok [y/N]: y  Downloading Packages:  Setting up and reading Presto delta metadata  Processing delta metadata  Package(s) data still to download: 102 k  PackageKit-command-not-found-0.5.7-2.fc12.x86_64.rpm     | 102 kB     00:00       Running rpm_check_debug  Running Transaction Test  Transaction Test Succeeded  Running Transaction    Installing     : PackageKit-command-not-found-0.5.7-2.fc12.x86_64         1/1     Installed:    PackageKit-command-not-found.x86_64 0:0.5.7-2.fc12                                Complete!  





Listing 28은 PackageKit-command-not-found를 설치한 후 함수 핸들이 어떻게 정의되는지를 나타낸 것이다. 함수에서 검색을 수행할 수 없는 경우 함수는 표준 시스템 작동을 모방하여 127을 리턴한다.



Listing 28. command_not_found_handle

[ian@echidna ~]$ type command_not_found_handle  command_not_found_handle is a function  command_not_found_handle ()   {       runcnf=1;      retval=127;      [ ! -S /var/run/dbus/system_bus_socket ] && runcnf=0;      [ ! -x /usr/sbin/packagekitd ] && runcnf=0;      if [ $runcnf -eq 1 ]; then          /usr/libexec/pk-command-not-found $1;          retval=$?;      else          echo "bash: $1: command not found";      fi;      return $retval  }





Listing 1에서 했던 것처럼 gcl을 실행하기 전에 command_not_found_handle이 설치되어 있었다면 Listing 29와 같은 결과를 얻었을 것이다.



Listing 29. command_not_found_handle로 gcl 시도

[ian@echidna ~]$ gcl  Command not found. Install package 'gcl' to provide command 'gcl'? [N/y]   







기타 도구


yum과 rpm 외에, 배포자는 저장소에서 패키지를 설치하거나 전체 시스템을 업데이트하기 위해 다른 도구를 제공할 수 있다. 이런 도구는 그래픽 도구나 명령행 도구 또는 두 가지 모두일 수 있다. 몇 가지 예를 들면 다음과 같다.


YaST(SUSE)


up2date(Red Hat)


Mandrake Software Management(Mandriva)




보통 이런 도구들은 자동 또는 반자동 방식으로 여러 가지 패키지 업데이트를 처리한다. 또한, 저장소의 내용을 표시하거나 패키지를 검색하기 위한 기능을 제공할 수도 있다. 자세한 내용은 배포 제품의 설명 문서를 참조한다.






PackageKit


소프트웨어 설치 및 업데이트를 더 쉽게 만들기 위해 디자인된 시스템인 PackageKit을 언급하지 않고 패키지 설치에 관한 논의를 마칠 수는 없다. 이는 다른 배포 버전에서 사용되는 모든 소프트웨어 그래픽 도구를 통합하자는 취지이다. PackageKit은 시스템에서 활성화된 디먼을 사용하는데, 이는 디먼이 필요할 때만 활성화된다는 뜻이다. Packagekit에는 Gnome(gnome-packagekit) 및 KDE(KPackageKit)에 대한 버전이 있다. 위에서 설명한 command-not-found 핸들 역시 PackageKit에 속한다. Packagekit에는 콘솔에서 패키지 관리 기능을 수행하기 위한 pkcon 명령과 패키지 킷 활동을 모니터하기 위한 pkmon 명령이 포함된다. 또한, 소프트웨어 패키지를 추가하거나 시스템을 업데이트하기 위한 그래픽 도구도 포함된다. 그림 1은 Software Update 그래픽 인터페이스의 예를 나타낸 것이다.



그림 1. Fedora 12(Gnome)의 Software Update 그래픽 인터페이스


여기서 다룬 것보다 훨씬 많은 RPM 및 YUM 패키지 관리 시스템이 있다. 추가 링크는 참고자료를 참조한다.



참고자료


교육


developerWorks roadmap for LPIC-1에서 2009년 4월 시험 목적을 바탕으로 실시되는 LPIC-1 인증 시험 공부에 도움이 되는 developerWorks 기사를 찾을 수 있다.




LPIC Program 사이트를 방문하면 Linux Professional Institute에서 제공하는 세 가지 레벨의 Linux 시스템 관리 인증에 대한 자세한 목적, 과제 목록 및 샘플 문제를 확인할 수 있다. 특히, LPI exam 101과 LPI exam 102에 대해서는 2009년 4월 시험 목적을 확인한다. 최신 시험 목적은 항상 LPIC Program 사이트를 참조한다.




Linux 기초를 학습하고 2009년 4월 이전의 LPI 시험 목적을 바탕으로 하는 시스템 관리자 인증 시험을 준비하려면 developerWorks에 관한 전체 LPI exam prep series를 검토한다.




RPM 홈 페이지에서 RPM 소프트웨어 패키징 도구에 관한 최신 정보와 RPM에 관한 더 많은 정보를 볼 수 있는 포인터를 찾을 수 있다. 




Maximum RPM(도서)에서는 RPM의 모든 측면을 포괄적이고 체계적으로 다룬 내용을 살펴볼 수 있다. 하드카피와 소프트카피 형식으로 모두 제공된다. 




LSB Home에서 표준 2진 운영 환경을 개발하기 위한 FSG(Free Standards Group) 프로젝트인 LSB(Linux Standard Base)에 관해 학습할 수 있다. 




PackageKit에 대한 자세한 내용은 PackageKit 홈 페이지를 참조한다.




Linux Documentation Project에는 특히 HOWTO(기술 노하우)를 포함한 다양하고 유용한 문서가 수록되어 있다. 




developerWorks 리눅스 영역에서는 Linux 개발자와 관리자에게 도움이 되는 수백 편의 사용법 기사 및 튜토리얼과 다운로드, 토론 포럼 및 기타 다양한 참고자료를 볼 수 있다. 




developerWorks 기술 행사 및 웹 캐스트를 통해 다양한 IBM 제품 및 IT 산업 주제에 대한 최신 정보를 얻을 수 있다. 




무료 developerWorks Live! briefing을 통해 최신 IBM 제품 및 도구에 대한 정보뿐만 아니라 IT 업계의 최신 경향까지도 빠르게 확인할 수 있다. 




developerWorks on-demand demos에서는 입문자를 위한 제품 설치 및 설정부터 숙련된 개발자를 위한 고급 기능까지 망라된 다양한 데모를 제공한다. 




Twitter의 developerWorks를 팔로우(follow)하거나 developerWorks에 대한 Linux 트윗(tweet)의 피드를 구독하자. 






제품 및 기술 얻기


Fedora/12 Public Active Mirrors와 같은 배포 미러 중 하나에 있는 패키지를 찾아본다.




Rpmfind.Net과 RPM Search에서 해당 배포 버전에 맞는 RPM을 검색한다. 




자신에게 가장 적합한 방법으로 IBM 제품을 평가해 보자. 시험판 제품을 다운로드하거나 온라인으로 제품을 사용해 보거나 클라우드 환경에서 제품을 사용하거나 SOA Sandbox에서 SOA(Service Oriented Architecture)를 효과적으로 구현하는 방법을 배울 수 있다. 






토론


포럼에 참여하기.




My developerWorks 커뮤니티에 참여하자. 개발자 중심 블로그, 포럼, 그룹 및 Wiki 검색 중에 다른 developerWorks 사용자와 의견을 교환해 보자. 






필자소개


Ian Shields는 developerWorks 리눅스 영역을 위한 리눅스 프로젝트 다수를 수행하고 있다. Shields는 노스 캐롤라이나 주 소재 IBM 리서치 트라이앵글 파크에서 선임 프로그래머로 일한다. Shields는 1973년 시스템 엔지니어로 오스트레일리아, 캔베라에 있는 IBM 사무실에 들어갔으며 캐나다 몬트리얼과 노스 캐롤라이나 주 RTP에서 통신 시스템과 배포 컴퓨팅 부문에서 일해왔다. Shields는 특허 여러 건을 획득했으며, 논문 여러 건을 발표했다. Shields는 순수 수학과 철학 학사 학위를 오스트레일리안 국립 대학에서 받았다. 노스 캐롤라이나 주립 대학에서 컴퓨터 과학 분야를 대상으로 석사와 박사 학위를 받았다. 전자편지 주소는 ishields@us.ibm.com이다.








'리눅스관련' 카테고리의 다른 글

Debian VMware Tools 설치하기  (0) 2011.06.06
ubuntu taxt 모드 에서 사용하는 명령어  (0) 2011.06.06
Git 명령어 정리  (0) 2011.06.06
samba IP allow setting  (0) 2011.06.06
CenOS 유용한 명령어  (0) 2011.06.06

+ Recent posts