Yum-HOWTO

출처 : http://wiki.kldp.org/wiki.php/Yum-HOWTO

Yum (Yellowdog Updater, Modified) HOWTO

Robert G. Brown, rgb at phy.duke.edu

Jonathan Pickard,fatboy at techno.co.za

0.3, 2003-09-24

---

이것은 Yum: Yellowdog Updater, Modified에 대한 HOWTO입니다. Yum은 rpm기반의 시스템을 위한 자동 업데이터이자 패키지 설치/삭제도구입니다. Yum은 자동적으로 의존성을 처리해주며 rpm 패키지들을 안전하게 설치, 삭제 및 업데이트하기 위해 반드시 해야할 일들을 스스로 해결합니다. 또한 Yum은 이미 설치되었거나 혹은 저장소에 설치가능한 패키지에 관한 정보를 효율적이고 쉽게 검색해옵니다. Yum은 rpm이나 다른 도구들처럼 일일이 수동으로 업데이트할 필요가 없으므로 수 많은 시스템들을 더욱 관리하기 쉽게 해줍니다. 한 조직 전체를 통괄하는 규모를 단지 한 두 명만으로 중앙집중적인 패키지 관리를 할 수 있도록, 패키지 그룹, 다수의 저장소, 대체 저장소 및 그 이상을 Yum이 관리해줍니다. 꼭 기억해 두세요! 이 HOWTO는 Yum의 초기 pre-release 개발 동안은 전적으로 유동적인 상태에 있습니다. 많은 섹션들이 비어있으며, 어떤 것들은 틀리기도하며, 모두가 과도기적 구성 상태에 있습니다. 그럼에도 불구하고, 저는 이 문서의 어떤 스냅샷이든 거기에 기반한 어느 누구로부터의 의견도 소중히 합니다.

---

Contents

1 소개

1.1 Yum으로 할 수 있는 것

1.2 Yum의 작동 방식

1.3 Yum, RPM, 그리고 Red Hat

1.4 Karmic Balance에 대한 호소

1.5 RPM 저장소의 무모함

1.6 저작권

1.7 책임의 한계

1.8 새소식

1.9 공로 및 감사

2 HOWTO 구성

2.1 본 HOWTO의 통독을 피하는 법

3 유용한 링크들:

4 일러두기

4.1 Superuser 요구사항

4.2 Yum 구하기

5 Yum 저장소 계획하기

5.1 단일 저장소 (Rsync 사용)

5.2 추가적인 저장소 및 서버

6 Yum을 위한 FTP 서버 설정

6.1 RPM 내려받기

6.2 FTP 서버 설치

6.3 vsftpd.conf 파일 편집

6.4 FTP 서버 시작

6.5 FTP 서버 시험

7 Yum 빌드하기

7.1 Root로 Yum RPM 만들기

7.2 User로 Yum RPM 만들기

8 Yum 설치하기

9 Yum에 최적화된 서버 구성: yum-arch

9.1 비기술적인 설명

9.2 FTP 서버를 위한 헤더 만들기

9.3 고급 명령어

10 Yum 클라이언트 설정

10.1 /etc/yum.conf

10.2 /etc/cron.daily/yum.cron

10.3 /var/cache/yum

10.4 설정 배포하기

11 Yum 클라이언트 사용하기

11.1 루트 권한이 필요한 Yum 명령어

11.2 정보를 제공하는 Yum 명령어

12 Yum 저장소를 위한 RPMs 빌드하기

13 보안

14 기타

15 더 많은 정보

[edit]

1 소개 ¶

Yum은 툴 및 응용프로그램 패키지들을 분산시킬 목적으로 만들어졌으며, Red Hat 패키지 관리 (RPM) 시스템을 사용하는 운영체제가 탑재된 워크스테이션 네트워크를 위한 패키지 관리 자동화 도구이다. 원래 Yellowdog Linux를 위해 개발된 자동 패키지 업데이터인 Yup으로부터 유래했으며, 따라서 이름: yum은 "Yellowdog Updater, Modified"를 뜻한다.

Yup은 처음에 Yellowdog Linux (다양한 세대의 애플 매킨토시를 구동하는 RPM 기반의 Linux 배포본)의 Dan Burcaw, Bryan Stillwell, Stephen Edie, 그리고 Troy Bengegerdes가 제작하고 관리했다. Yum은 Duke University의 Seth Vidal와 Michael Stenner가 제작했고 지금도 관리하고 있지만, 오픈 소스 GPL 프로젝트로서 많은 사람들이 (문서작성은 말할 것도 없이:-) 코드, 아이디어 및 버그 수정에 공헌했다. 위의 Yum링크에는 배포 tarball속의 AUTHORS가 그러하듯이, (거의) 모든 공헌자들의 목록이 나와 있다.

Yum은 Gnu Public License (GPL) 도구이다; 해당 라이센스 항목들을 지키는 한 어떠한 비용이나 사용료 없이 자유롭게 얻을 수 있고 사용, 개작 및 재배포가 가능하다.

[edit]

1.1 Yum으로 할 수 있는 것 ¶

(현재) Yum은 두 가지 툴로 구성되어 있다; 첫째, yum-arch는 적당한 서버에 (ftp나 http) 저장소를 구성하는 데에 사용된다, 둘째로 Yum은 일반적인 용도의 클라이언트이다. Yum 저장소가 준비(아래에 서술된 간단한 과정)되면 어떤 클라이언트도 저장소의 rpm 기반의 패키지를 설치, 업데이트, 또는 제거할 수 있다.

업데이트에 있어서의 Yum의 영리함은 관련된 툴들 중 가장 뛰어나다; Yum은 레드햇 7.1 시스템을 직접 7.3으로 실시간 업그레이드하는 데에 굉장히 성공적으로 이용되었다(물론 업그레이드의 성공 확률은 근본적으로 타겟 시스템이 얼마나 특화되었느냐와 중요한 설정 파일의 포맷이 초기 리비전과 최종 리비전 사이에 얼마나 바뀌었느냐에 따라서 달라진다. -YMMV: Your Mileage May Vary).

게다가, Yum 클라이언트는 다양한 정보처리 도구를 내포하고 있어서, 이미 설치되어 있거나 설치 가능한 rpm들 모두를 목록으로 만들 수 있고, 키워드나 globs에 기반한 rpm 헤더로 부터 정보를 뽑아내고 표시할 수 있으며, 특정한 파일을 제공하는 패키지를 찾을 수도 있다. 그러므로 Yum은 사설 혹은 LAN 환경의 워크스테이션 사용자에게 대단히 유용하다; Yum을 통해 "관심있는" 패키지가 있는 지 설치 가능한 패키지의 목록을 확인할 수 있으며, 특정 도구를 포함한 패키지를 찾거나 특정한 업무에 적용시키는 등, 그 이상의 일들을 할 수 있다.

Yum은 심지어 외부의 분산된 관리 영역까지도 보안과 상호작용성의 보장이 요구되는 한 "중앙집중적인" 패키지 관리를 가능하게 해주는, client-pull 도구로 설계되었다. Yum 클라이언트에는 아무런 root 권한도 필요하지 않다 -- Yum은 기껏해야 클라이언트로부터 저장소 서버(대개 중앙의 -- 그리고 그 만한 자격이 있는 -- 권위자에 의해 관리되는 곳)로의 익명 접근(제한이 있든 없든)을 요구한다. 이 사실은 한 무리의 기계들이 그 소유자와 자연적으로 생기는 수많은 네트워크 관리자들에의해 유지되는 (이를테면 대학과 같은), 분산된 네트워크 관리 환경하에서 리눅스 시스템들의 "중앙집중적" 확장 관리를 위해서 Yum이 가장 매력적인 도구가 되게 한다.

어떤 LAN 환경에서든 가장 보편적인 Yum 사용법 중 하나는 시스템의 모든 rpm 패키지를 , 모든 보안이나 기능 패치를 한 업데이트를 포함하여, 저장소에서 설치가능한 최신 버전으로 안전하게 업데이트하도록 각각의 Yum으로 관리하는 시스템에서 nightly cron 스크립트를 실행시키는 것이다. 만약 이러한 nightly 업데이트를 수행하도록 미리 설정된 rpm 버전으로 Yum을 설치한다면, 하나의 공통적인 저장소에 기반하여 시스템들을 설치하는 전체 캠퍼스는 배포와 리비전 및 보안에 있어서 완벽한 통일성을 이룰 수 있다. 보안 및 기타 업데이트는 어떤 클라이언트들에 대해서도 root권한이 필요없는 (믿을 수 있는) 관리자가 저장소에 업데이트된 rpm을 올린지 24시간이 채 넘지 않아 모든 네트워크로 연결된 클라이언트상에 나타날 것이다.

결과적으로 한 명의 믿을 수 있는 관리자가 Yum으로 대학 캠퍼스, 기업, 정부 협의회나 연구기관 전체에 대해서 신뢰할 만한 하나의 rpm 저장소(집합)를 유지할 수 있다. 한 배포본의 서로 다른 부분에 대한 책임을 구분된 저장소의 신뢰할 수 있는 여러 관리자들 사이에 안전하게 나눌 수 있고, 한 명의 지역 관리자가 캠퍼스 수준의 여러 저장소로부터의 제공을 추가하거나 덮어쓸 수 있는 하나의 신뢰할 수 있는 지역 저장소를 추가할 수 있다. 같은 리비전 수준의 모든 시스템들은 설치된 패키지 (지역 관리자이 덮어 쓴 것까지 포함)가 허락하는 한 일치성과 상호운용성이 보장된다. 그러므로 Yum은 한 명의 개인이 한 작업을 수 천대의 기계를 포괄하는 규모로 확장시킬 수 있는, 저장소 기반의 패키지 배포 및 시스템 관리를 위한 놀라울 정도로 강력한 도구이다.

그리고 Yum은 free이다. 이 보다 더 좋을 수는 없다...

[edit]

1.2 Yum의 작동 방식 ¶

Yum이 어떻게 작동하는지 이해하기 위해 몇몇 용어를 정의하는게 도움이 된다.

• 서버: 서버라는 용어는 대개 저장소에 접근을 제공하는 물리적 시스템을 일컫는다.그러나 Yum이 처음 개발되었을 때는 대개 저장소당 오직 하나의 서버가 있고 서버는 때때로 저장소의 동의어로 쓰였다. 아래에서는 전자의 의미 -- 저장소 자체가 아니라 저장소에 접근을 제공하는 특정한 웹, ftp, nfs 서버 -- 로만 쓸 것이다.
• 저장소: 저장소는 어떤 파일시스템 트리 아래에 있는 rpm의 모임이다. Yum과 관련된 대개의 목적을 위해, 저장소는 두가지 중요한 추가적인 특성을 가진다. 트리아래에서 실행하는 명령어인 yum-arch가 있으며, 이것은 그 트리아래의 모든 rpm에 대한 헤더및 경로 정보를 포함하는 "headers"라는 디렉토리를 만들어 낸다. 한편, 저장소는 URL (그 저장소 트리에 대해 하나 또는 그 이상의 http://my.webserver.ext/path, ftp://my.ftp.server.ext/path, file://full/file/path)을 통해 접근이 가능하다.
• serverid: 위에 적은 것처럼, Yum의 초기 버전에서는 서버와 저장소 간에 일대일 대응이 존재했다. 그러나, 이 대응은 다대다가 아니다. 하나의 저장소가 많은 서버에 미러될 수 있고, 하나의 서버가 많은 저장소를 가질 수 있다. 저장소에 "확고한" 접근을 구성할 때 (이것은 어떤 저장소의 주서버가 죽었을 때 같은 저장소에 대체 서버로의 URL을 제공하는 것을 뜻한다) 서버나 저장소 자체만으로는 명백히 불가능한 일인, 일종의 고유한 id를 저장소에 붙이는 것이 필요하게 되었다. 그래서 serverid는 주어진 하나의 baseurl 아래에 있는 모든 저장소들이 서로간의 (그럴듯 한) 미러라는 것을 가리키기 위해 yum.conf 에서 사용되는 고유한 라벨이다.
• RPM: "Red Hat Package Manager"를 뜻하며, linux 배포본을 위한 도구, 라이브러리, 바이너리 및 데이터의 "패키지들"을 배포하고 관리하기위해 Red Hat이 개발한 툴셋이다. 완전한 오픈 소스이며 Red Hat 뿐만 아니라 수 많은 linux 배포본의 기반이 되고 있다. 아래 문서에서 "rpm"을 말할 땐, 대개 패키지이름-버전.rpm으로 명명되는 단일 패키지를 일컫는다. Yum이 어떻게 작동하는지 이해하려면, rpm의 구조에 대한 약간의 이해가 필요하다.
  
  

RPM은 기본적으로 세 부분: 헤더, 서명 및 (대개 압축된) 파일 그 자체로 구성된다. 헤더는 완벽한 파일 목록, 패키지의 설명, 제공하는 기능 및 라이브러리들의 목록, 제대로 작동하기 위해 (다른 패키지로부터) 필요로 하는 도구들의 목록, 충돌을 일으키는 (알려진) 다른 패키지들의 존재, 그리고 그외 여러가지를 포함한다. 기본적인 rpm 도구는 다음과 같은 방식으로 하나의 패키지를 설치(혹은 삭제!)하기위해 헤더 속의 정보를 요구한다.:

• 이 패키지를 설치하는 것이 이미 설치된 패키지들을 망가뜨리지 않는다. (재귀적으로, 기존의 패키지들은 자신의 패키지들이 설치되기를 요구하므로)
• 이 패키지가 제대로 동작하기 위해 필요한 모든 패키지들이 선택된 패키지와 함께 재귀적으로 (이미 설치되어 있거나) 설치된다.
• 이 패키지의 최신버전이 (잘못하여) 그 패키지의 기존버전을 교체하지 않는다.
  
  

유사한 방법들이 삭제에도 적용됨을 명심하라; 이를테면, 어떤 패키지를 삭제하는 것이 남아있는 다른 패키지들을 망가뜨려서는 안된다 등.

이 과정은 일반적으로 "패키지 의존성 해결"로 알려져 있으며 패키지 관리에서 가장 어려운 부분 중의 하나이다. 두 세개의 라이브러리 및 툴을 요구하는 어떤 패키지를 설치하고 싶을 때가 있다. 계속해서 라이브러리들이 다른 라이브러리를, 툴이 다른 툴을 요구할 지도 모른다. 설치가 완료될 무렵에는, 그 패키지의 설치가 기존에 설치된 패키지들 중 어떤 것과도 충돌하지 않거나 남아있는 어떤 패키지들도 망가뜨리지 않는, 여섯개 혹은 여덟개의 다른 패키지들을 요구했을 것이다.

만약 지금까지 rpm들을 수동으로 관리하기를 시도해왔다면, 모든 헤더들과 의존성을 추적해내고 모든 충돌을 해결하는 것이 쉽지 않다는 것과 시스템 관리자로서 어떤 시스템에서는 이것을 업데이트하고, 다른 시스템에서는 저것을, 여기서 어떤 패키지를 리빌드하고, 저기서는 지역적으로 /usr/local에 설치하는 등의 처지라면 실제로 상황이 더욱 어려워 진다는 사실을 알 것이다. 결국에는 (때로는 완전한 좌절감으로) 어떤 rpm을 --force 옵션으로 설치하게 되고, 그 후에는 시스템의 rpm 데이터베이스 자체가 불일치성을 갖게되며 어떤 rpm의 설치도 실패하게 되어 계속해서 --force를 하게 될 수도 있다. 네트워크가 점점 무질서해지고, 그 때문에 보안의 위험과 오동작을 야기하게 된다.

그렇다고 패키지를 업데이트하지 않는 것 또한 난처한 상황이다. 만약 배포본 기반의 설치를 손대지 않고 둔다면 깔끔한 상태로 있게 된다. 그러나, 그 일부는 설치시에 망가졌을 수도 있다. -- 가장 주의를 기울이는 주요 배포본들의 경우에도 항상 버그가 있게 마련이다. 그러한 버그 중의 몇몇은 보안 버그이며, 크래커가 그것을 발견하고 취약점이 빠르게 전개된되면 "시스템을 패치하지 않으면 기생충을 어서 오라고 내버려 두는 격"이 되고 만다. 이것은 모든 운영체제의 전체적인 문제이다; 심지어 (바이러스와 크래커에게 취약하기로 악명높은) Windows 기반의 시스템들도 철저하게 최신의 상태로 유지한다면 상당히 안전하게 만들 수 있다. 결국, 사용자들은 작업에 중대한 영향을 미치는 -- 원래의 깨끗하고 일관된 설치가 아닌 -- 이 패키지 저 패키지를 요구하고 찾게 된다.

고려해보면, 어떤 전문적인 LAN 관리자도 (혹은 심지어 조잡한 단일 리눅스 워크스테이션 소유자조차도) 거의 선택의 여지가 없다; 시스템에 이미 설치한 패키지들을 최신의, 패치된, 안전한, 버그가 해결된 버전으로 업데이트하는 것과, 처음의 기본 설치로 의존하는 배포본에 없었던 것들을 포함한 새로운 패키지들을 설치하는 것에 있어서 일종의 메커니즘을 가지고 있어야만 한다. 다만 문제는: 어떠한 메커니즘을 사용해야 하며 그에 따라서 어떤 (금전적인 면 뿐만 아니라 시간, 노력, 학습 및 신뢰성에 있어서의) 비용이 드는 지일 것이다. 이제 이 문제를 고려해보자.:

통상적인 저장소(repository)에는 수많은 패키지들(대략 수천 개)이 들어 있으며, 여기에는 수많은 헤더(header)들이 포함되어 있다. 내가 지금 작업을 진행하고 있는 시스템에는 대략 700개의 패키지들이 설치되어 있다. 어쨌든, 각각의 패키지 구성에서 {압축 파일}(archive) 부분은, 이 부분은 실질적인 바이너리(binary)들과 라이브러리(library)들과 설치되는 문서 등등을 포함하는데, 거의 대부분을 차지한다. -- 그래서 일반적인 경우에 rpm 전체 크기는 거기에 포함된 헤더보다 대략 10의 2 제곱 배에서 4 제곱 배 정도[1] 정도 더 크다. 예를 들면, `오픈 오피스'(매우 큰 패키지 중의 하나임)의 헤더는 전부 합해서 100 킬로바이트 정도의 크기이다. 반면에, 그 rpm 자신의 크기는 약 30 메가바이트이다. 그것의 헤더는 일 초의 몇 분의 일 정도의 짧은 시간 동안이면 대부분의 네트워크들에서 충분히 전송이 가능하다. 반면, 그 rpm 자신은 100BT[2]인 네트워크를 통해서 전송해도 수 초 이상이 걸리며, 예를 들어, DSL, 케이블, 또는 상대적으로 느린 편에 속하는 어떤 종류의 네트워크를 통해서도 수 분 정도가 걸린다. 전자(前者)[3]는 저장소의 물리적 서버에서 미소한 시간만을 점유하지만, 후자(後者)[4]는 해당 서버에 무시 못할, 지체를 유발하는 부하(負荷)[5]를 일으킨다. 이 모든 것은, 대충 수천 대의 클라이언트(client)와 한 대의 물리적 서버에 여러 개의 각기 다른 저장소를 두려고 계획하는 규모를 가진 갱신(update) 설비를 설계하거나 골라 잡으려 할 때에는 심각하게 고려되어야 할 사항이다.

초창기의 자동화된 갱신 도구들은 로컬[6]에 마운트(mount)된 저장소 디렉토리를 요구하며 그로 인해 모든 헤더들을 빠르게 접근할 수 있도록 만들었거나 (비록 상대적으로 느린 편인 CD-ROM 드라이브라고 할지라도 적절한 속도로 rpm들을 전송하여 거기에 들어 있는 헤더를 뽑아내서 처리하는 데에 지장이 없을 정도로 빠르기 때문이다.) 또 다른 방식으로는, 갱신시키려는 client로 각각의 연결된 rpm을 통째로 네트워크를 통해 전송되도록 요구했는데, 이는 단지 헤더를 읽어내려는 목적때문이었다. `앞의 것'은 로컬 측에서는 빠르지만, 로컬 측에 커다란 디스크 공간을 차지해 버리고, (게다가 새로운 골칫거리가 생기는데, 그것은 모든 로컬 측의 복사본을 원본(master) 저장소와 {일치하도록 갱신되게}(synchronized) 계속 유지하는 작업이다.) "뒤의 것"은 엄청나게 느리다. 게다가 양쪽 모두 네트워크 자원을 상당히 소모한다.

----

• [1] 역자주: 원문은 "two to four orders of magnitude larger"이며, 그 뜻은 야후 영영사전 검색결과 특히 제2번풀이를 보시오
• [2] 100BaseT, 더 자세한 것은 100BaseT에 대한 empas검색 결과를 볼 것.
• [3] 역자주: "앞의 것", 이 글에서는, "{rpm 헤더}만을 전송하는 것"을 뜻함
• [4] 역자주: "뒤의 것", 이 글에서는, "rpm을 통째로 전송하는 것"을 뜻함
• [5] 역자 주: 무거운 짐
• [6] 역자 주: 이 말은 원래 "국부적인", "지역적인", "범위가 좁은"이라는 뜻의 일반 단어였으나, 컴퓨터 네트워크 통신에서 이 말을 빌려가서 자기들 분야의 전문 용어로 사용한 단어로써, 이 문맥에서는 네트워크에서 상대 편이 아닌, 네트워크 연결에서의 이쪽 편, 네트워크가 단절되어도 내 손으로 직접 조작을 할 수 있는 이쪽 편의 기계 장비를 뜻한다. 일반 단어로서의 "local"의 반대말은 "global"(광범위한)이지만, 네트워크 전문용어로써의 반대말은 "remote"(멀리 떨어진, 저쪽의)라는 점을 생각하면 이해가 쉬울 것이다. 예: "local host"의 반대말은 "global host"가 아닌 "remote host"임.

DeleteMe doob 여기부터 아래의 DeleteMe doob까지 doob이 번역하기로 찜했습니다 -- doob 2004-01-24 06:02:50

이것은 Yum이 해결해주는 기본적인 문제이다. Yum splits off the headers on the repository side (which is the job of its only repository-side tool, yum-arch). The headers themselves are thus available to be downloaded separately, and quickly, to the yum client, where they are typically cached semi-permanently in a small footprint in /var/cache/yum/serverid (recall that serverid is a label for a single repository that might be mirrored on several servers and available on a fallback basis from several URL's). Yum clients also cache (space permitting or according to the requirements and invocation schema selected by the system's administrator) rpm's when they are downloaded for an actual install or update, giving a yum client the best of both the options above -- a local disk image of (just the relevant part of) the repository that is automatically and transparently managed and rapid access to just the headers.

An actual download of all the headers associated with packages found on your system occurs the first time a yum client is invoked and thereafter it adds to or updates the cached headers (and downloads and caches the required rpm's) only if the repository has more recent versions or if the user has deliberately invoke yum's "clean" command to empty all its caches. All of yum's dependency resolution then proceeds from these cached header files, and if for any reason the install or update requires an rpm already in the cache to be reinstalled, it is immediately available.

As a parenthetical note, the author has used yum's caches in a trick to create a "virtual" update repository on his homogeneous, DSL-connected home LAN. By NFS exporting and mounting (rw,no_root_squash) /var/cache/yum to all the LAN clients, once normal updates have caused a header or rpm to be retrieved for any local host, they are available to all the local hosts over a (much faster than DSL) 100BT NFS mount. This saves tremendously on bandwidth and (campus) server load, using instead the undersubscribed server capacity of a tiny but powerful LAN. Best of all, there "is no setup"; what I just described is the works. A single export and a mount on all the clients and yum itself transparently does all of the work.

DeleteMe doob 여기까지 doob이 번역하기로 찜했습니다. -- doob 2004-01-24 06:02:50

However, it is probably better in many cases to use rsync or other tools to provide a faithful mirror of the repository in question and use yum's fallback capability to accomplish the same thing (single use of a limited DSL channel) by design. This gives one a much better capability of standing alone should update access go away on the "server" of the yum cache NFS exported across a LAN.

With the header information (only) handy on high-speed local media, the standard tools used to maintain rpm's are invoked by yum and can quickly proceed to resolve all dependencies, determine if it is safe to proceed, what additional packages need to be installed, and so forth. Note well that yum is designed (by a highly experienced systems administrator, Seth Vidal, with the help of all the other highly experienced systems administrators on the yum list) to be safe. It will generally not proceed if it encounters a dependency loop, a package conflict, or a revision number conflict.

If yum finds that everything is good and the package can be safely installed, removed, or updated, it can either be invoked in such a way that it does so automatically with no further prompts so it can run automagically from cron, or (the general default when invoked from a command line) it can issue a user a single prompt indicating what it is about to do and requesting permission to proceed. If it finds that the requested action is in fact not safe, it will exit with as informative an error message as it can generate, permitting the system's administrator to attempt to resolve the situation by hand before proceeding (which may, for example, involve removing certain conflicting packages from the client system or fixing the repository itself).

From the overview given above, it should be apparent that yum is potentially a powerful tool indeed, using a single clever idea (the splitting off of the rpm headers) to achieve a singular degree of efficiency. One can immediately imagine all sorts of ways to exploit the information now so readily available to a client and wrap them all up in a single interface to eliminate the incredibly arcane and complex commands otherwise required to learn anything about the installed package base on a system and what is still available. The yum developers have been doing just that on the yum list - dreaming up features and literally overnight implementing the most attractive ones in new code. At this point yum is very nearly the last thing you'll ever need to manage packages on any rpm based system once it has gotten past its original, distribution vendor based, install.

Indeed, it is now so powerful that it risks losing some of its appealing simplicity. This HOWTO is intended to document yum's capabilities so even a novice can learn to use it client-side effectively in a very short time, and so that LAN administrators can have guidance in the necessarily more complex tasks associated with building and maintaining the repositories from which the yum clients retrieve headers and rpm's.

Yum의 개발은 아직 완료 되지 않았다. 지원자들이 GUI 환경하에서 작업 중이다.(...) Yum's development is far from over. Volunteers are working on a GUI (to encapsulate many of yum's features for tty-averse users). Some of yum's functionality may be split off so that instead of a single client command there are two, or perhaps three (each with a simpler set of subcommand options and a clear differentiation of functionality). The idea of making yum's configuration file XML (to facilitate GUI maintenance and extensibility) is being kicked around. And of course, new features are constantly being requested and discussed and implemented or rejected. Individuals with dreams of their own (and some mad python or other programming skills:-) are invited to join the yum list and participate in the grand process of open source development.

[edit]

1.3 Yum, RPM, 그리고 Red Hat ¶

Because yum invokes the same tools and python bindings used by e.g. Red Hat to actually resolve dependencies and perform installations (functioning as basically a supersmart shell for rpm and anaconda that can run directly from the local header cache) it has proven remarkably robust over several changes to the rpm toolset that have occurred since its inception, some of them fairly major. It is at least difficult for yum to "break" without Red Hat's own rpm installation toolset breaking as well, and after each recent major change yum has functioned again after a very brief period of tuneup.

It is important to emphasize, however, that yum is not a tool for administering Red Hat (only) repositories. Red Hat will be prominently mentioned in this HOWTO largely because we (Duke) currently use a Red Hat base for our campuswide linux distribution, maintain a primary (yum-enabled) Red Hat mirror, and are literally down the road a few miles from Red Hat itself. Still, if anything, yum is in (a friendly, open source) competition with Red Hat's own up2date mechanism and related mechanisms utilized by other distribution vendors.

So Note Well: Yum itself is designed for, and has been successfully used to support, rpm repositories of any operating system or distribution that relies on rpm's for package management and contains or can be augmented with the requisite rpm-python tools. Yum has been tested on or is in production on just about all the major rpm-based linuces, as well as at least one Solaris repository. Its direct conceptual predecessor (with which it shares many design features and ideas, although very little remaining actual code) is Yellowdog Linux's updater tool yup, which had nothing whatsoever to do with Red Hat per se. Yum truly is free like the air, and distribution-agnostic by deliberate design.

[edit]

1.4 Karmic Balance에 대한 호소 ¶

It is worth taking a short moment here and put in a bit of a plug for the distribution providers, Red Hat, Mandrake, SuSE, Yellowdog and all the rest. Yum is a tool that (clearly) can completely short circuit some, if not all, of their expected/hopeful income streams. Using the methods described below, one can literally scale any distribution over the entire Internet, working directly from a mirror (of a mirror of a mirror...) from their original web distribution, in such a way that all maintenance is fully automated and yet makes the distribution provider absolutely no money for doing the toplevel maintenance on the base distribution itself.

There are obvious ethical and practical issues here. Ethically one should exchange value to remain in karmic balance with the world ecology, including the amorphous and chaotic one that encompasses all of linux. There are two ways to do so in the open source world: share in the work of providing the services or pay some money (to help pay for the time and profit of those that do the work for you).

Practically one should be aware that if a distribution provider doesn't make enough money to pay for the actual work and capital investment required to assemble, test, debug, maintain, and distribute the software (plus a fair profit) they will either go out of business or alter their business model in ways that make it more difficult for us all to work efficiently and scalably from their distribution without paying them some money.

For both reasons I would urge that even though one can obtain linux using the methodologies described in this HOWTO, install it on ten thousand systems in a single organization, and maintain it completely automagically with yum for free, one seriously consider meeting one's ethical and practical responsibilities and ensuring that you pay the global mind back, either way.

I personally do both. I'm writing this HOWTO, and have written GPL packages in the past and made them publically available. I have participated in all sorts of linux development processes and am on a dozen high level linux lists. I still make sure that I buy something inexpensive from Red Hat (my current primary distribution) every two or three years so that they make a buck or two for every one of the systems I personally run in my house, per year.

It would be lovely if the primary distribution vendors made this easier. Obviously, I install via dulug and maintain via yum, so the RH 9 box set I purchased was a complete waste (and I'll cheerfully give it away if I can find anybody to give it to). I'd have rather found a paypal link on the RH website where one could utterly voluntarily kick in a payment and NOT get a damn thing back from them -- no updates, no free support services, nothing at all but continued free access to their distribution via the chain of mirrors I use to install and maintain it. Pure revenue for them, pure karmic peace for me.

[edit]

1.5 RPM 저장소의 무모함 ¶

A moment or two of meditation upon dependency resolution should suffice to convince one that Great Evil is possible in a large rpm repository. You have hundreds, perhaps thousands of rpm packages. Some are commercial, some are from some major distribution(s), others are local homebrew. What if, in all of these packages built at different times and by different people, you ever find that there exist rpm's such that (e.g.) rpm A requires rpm B, which conflicts with rpm C (already installed)? What if rpm A requires rpm B (revision 1.1.1) but rpm B (revision 1.2.1) is already installed and is required in that revision by rpm C (also already installed)? It is entirely possible to assemble an "rpm repository from hell" such that nearly any attempt to install a package will break something or require something that breaks something.

(As yet another parenthetical note, this was the thing that made many rpm-based distribution users look at Debian with a certain degree of longing. Apt untangles all of this for you and works entirely transparently from a single distribution "guaranteed to be consistent", and provides some lovely tools (some of which are functionally cloned in yum) for package management and dependency resolution. However, as is made clear on the yum site, yum is a better solution in many ways than apt or, for that matter, Current or up2date. I believe that the designers are working fairly aggressively to make sure it stays that way.)

A cynical (but correct) person would note that this was why rpmfind and other rpm "supertools" ultimately failed. Yes, rpmfind could locate any rpm on the planet in its superrepository a matter of a few seconds, BUT (big but) resolving dependencies was just about impossible. If one was lucky, installing an e.g. Mandrake rpm on a Red Hat system that used SuSE libraries rpm's would work. Sometimes one required luck to install the Red Hat rpm's it would find on a Red Hat system, as they were old or built with non-updated libraries. Sometimes things would "kind of work". Other times installing an rpm would break things like all hell, more or less irreversibly.

Untangling and avoiding this mess is what earns the major (rpm-based or not) linux distribution providers their money. They provide an entire set of rpm's (or other packages) "all at once" that are guaranteed to be consistent in the distribution snapshot on the CD's or ISO images or primary website. All rpm's required by any rpm in the set are in the set. No rpm's in the provided set conflict with other rpm's in the set. Consequently any rpm in the set can be selected to be installed on any system built from the distribution with the confidence that, once all the rpm dependencies are resolved, the rpm (along with its missing dependencies) can be successfully installed. The set provided is at least approximately complete, so that one supposedly has little incentive or need to install packages not already in the distribution (except where so doing requires the customer to "buy" a more expensive distribution from the vendor:-).

In the real world this ideal of consistency and completeness is basically never achieved. All the distributions I've ever tried or know about have bugs, often aren't totally consistent, and certainly are not complete. A "good" distribution can serve as a base for a repository and support e.g. network installs as well as disk or CD local installs, but one must be able to add, delete, update packages new and old to the repository and distribute them to all the systems that rely on the repository for update management both automatically and on demand.

Alas, rpm itself is a terrible tool to use for this purpose, a fact that has driven managers of rpm-based systems to regularly tear their hair for years now. Using rpm directly to manage rpm installs, the most one can do is look one step ahead to try to resolve dependencies. Since dependency loops are not at all uncommon on real-world repositories where things are added and taken away (and far from unknown even in box-set linux distributions that are supposed to be dependency-loop free) one can literally chase rpm's around in loops or up a tree trying to figure out what has to be installed before finally succeeding in installing the one lonely application you selected originally.

rpm doesn't permit one to tell it to "install package X and anything else that it needs, after YOU figure out what that might be". Yum, of course, does.

Even yum, though, can't "fix" a dependency loop, or cope with all the arcane revision numbering schemes or dependency specifications that appear in all the rpm's one might find and rebuild or develop locally for inclusion in a central repository. When one is encountered, a Real Human has to apply a considerable amount of systems expertise to resolve the problem. This suggests that building rpm's from sources in such a way that they "play nice" in a distribution repository, while a critical component of said repository, is not a trivial process. So much so that many rpm developers simply do not succeed.

Also, yum achieves its greatest degree of scalability and efficiency if only rpm-based installation is permitted on all the systems using yum to keep up to date. Installing locally built software into /usr/local becomes Evil and must be prohibited as impossible to keep up to date and maintained. Commercial packages have to have their cute (but often dumb) installation mechanisms circumvented and be repackaged into some sort of rpm for controlled distribution.

Consequently, repository maintainers must willy-nilly become rpm builders to at least some extent. If SuSE releases a lovely new tool in source rpm form that isn't in your current Red Hat based repository, of course you would like to rebuild it and add it. If your University has a site license for e.g. Mathematica and you would like to install it via the (properly secured and license controlling) repository you will need to turn it into an rpm. If nothing else, you'll need to repackage yum itself for client installations so that its configuration files point to your repositories and not the default repositories provided in the installation rpm's /etc/yum.conf.

For all of these reasons an entire section of this HOWTO is devoted to a guide for repository maintainers and rpm builders, including some practices which (if followed) would make dependency and revision numbering problems far less common and life consequently good.

In the next few sections we will see where to get yum, how to install it on the server side, and then how to set up and test a yum client. Following that there will be a few sections on advanced topics and design issues; how to set up a repository in a complex environment, how to build rpm's that are relatively unlikely to create dependency and revision problems in a joint repository, how to package third party (e.g. site licensed) software so it can be distributed, updated, and maintained via yum (linux software distributors take note!) and more.

[edit]

1.6 저작권 ¶

Yum HOWTO Copyright (c) 2003 by Robert G. Brown

이 문서는 어떤 형태로든 자유롭게 복사 및 배포 (판매나 제공)할 수 있다. 수정이나 비평은 문서 관리자에게 보내주길 바란다. 만약 다음 사항들을 지킨다면 파생본을 만들고 배포해도 좋다.:

• 파생본을 (sgml과 같이 가장 알맞은 형식을 갖추어서) LDP (Linux 문서 프로젝트)에 보내거나 혹은 그와 비슷하게 인터넷에 올릴 것. LDP에 보낸 것이 아니라면, 그 문서의 위치를 LDP에게 알릴 것.
• 파생본의 저작권은 이 문서와 같은 것을 쓰거나 GPL을 사용할 것. 저작권 공지는 물론 적어도 사용한 저작권의 링크를 포함할 것.
• 이전의 저작자와 주요한 공헌자들의 공로를 표시할 것.
  
  

만약 번역이 아닌 파생본 제작을 고려한다면, 그 계획을 현재의 문서 관리자와 의논하길 바란다.

[edit]

1.7 책임의 한계 ¶

이 문서의 정보를 자기가 책임지고 사용하라. 나는 이 문서의 내용에 대한 어떠한 잠재적인 책임도 부인한다. 이 문서에 포함된 개념, 예제 및 기타 내용들의 사용은 전적으로 자신의 책임이다.

별다른 방법으로 표시하지 않더라도, 모든 저작권은 그 소유자에게 있다. 이 문서에 포함된 용어 사용은 어떠한 상표나 서비스권의 유효성에 영향을 끼치는 것으로 간주되어서는 안된다.

특별한 상품이나 상표를 거론하는 것은 그에대한 지지로 여겨서는 안된다.

중대한 설치전에 시스템을 백업할 것과 규칙적인 간격으로 백업을 만들 것을 강력히 권고한다.

[edit]

1.8 새소식 ¶

이것은 본 문서의 첫 릴리즈이므로, 그다지 소식이 없다.

궁극적으로 이 문서의 최종 버전이 http://www.linux.duke.edu/projects/yum/yum_HOWTO.html (아마 아직은 동작하지 않음)과 같은 URL에서 얻을 수 있기를 희망한다.

[edit]

1.9 공로 및 감사 ¶

Greg Wildman gregw at techno.co.za Stein Gjoen sgjoen at nyx.net Russ Herrold Seth Vidal Michael Stenner

(그 외 Yum 리스트에 있는 사람들).

특히 rgb는 이 HOWTO가 유래된 기본 문서를 포함해서 Yum을 지속적으로 제작하고 관리한 Seth Vidal과 Michael Stenner는 물론, 이 문서가 대충 파생되었다고 볼 수 있는 최초의 non-HOWTO 온라인 Yum 문서의 작성에 도움을 준 Russ Herrold에게도 깊이 감사한다. 어떠한 비평이나 제안도 받아 들인다 : yum mailing list. 웹사이트 yum mailing list를 방문해도 좋다.

[edit]

2 HOWTO 구성 ¶

[edit]

2.1 본 HOWTO의 통독을 피하는 법 ¶

이 HOWTO는 세 부류의 독자들을 위해 설계되었다.

• 단독시스템 사용자: 만약 하나 또는 그 이상의 시스템을 가지고 있고, 자신의 저장소를 설정하는데는 관심이 없으며, 다만 새 소프트웨어 패키지를 찾아서 설치하고 시스템을 최신의 상태로 유지하기 위해서 Yum의 사용법을 배우고자 한다면, 이는 단독시스템 사용자이다. 그렇다면 일러두기 부분과 Yum 설치하기 및 yum.conf 그리고 Yum 클라이언트 자체에 대한 부분까지는 그냥 지나쳐도 된다. 만약 시간 또는 흥미가 있고 한 개 이상의 시스템에 관여해야 한다면 다른 부분들도 대강 읽어보는 것이 좋다. - 생각하는 것보다 저장소 미러를 설정하는 것은 쉽다. 게다가 중요 도구들에 대해 많이 알 필요도 전혀 없다. 시작하는데 추가적인 도움을 얻기 위해 Yum 메일링 리스트에 가입하는것을 원하거나 그렇지 않을 지도 모른다. -- 일단 시작했으면 필요 없을 것이다.
  
  
• 워크스테이션 네트워크의 시스템 관리자: 만약 하나 혹은 더 이상의 시스템들을 소유하거나 책임져야하고 한 개 혹은 그 이상의 저장소를 구성하려고 한다면, 전체 문서를 적어도 대강 훑어 보거나 읽을 필요가 있다. 이 HOWTO 는 사실 이 사람들을 우선적인 독자로 여기고 설계되었다. 본 문서의 몇 부분들(배경지식이 더 부족한 독자들을 위해 삽입한 부분들)은 그냥 지나쳐도 되지만, 살펴보면 무엇인지 알 수 있을 것이다. 추가적인 지원이나 개발에 참여하기 위해 Yum 개발자 메일링 리스트에 가입할 필요가 있거나 가입을 원하거나 혹은 그렇지 않을 지도 모른다.
  
  
• 개발자: 만약 직접적인 배포 수단으로 Yum을 사용하거나 Yum 자체의 개발 참여에 관심이 있는 소프트웨어 개발자라면, 역시 전체 문서를 대강 훑어 보거나 읽는 것이 필요하겠지만, 이 문서로는 부적절할 것이다. 아래의 공식 Yum 웹사이트에 링크된 Yum 리스트에 거의 분명 가입해야 될 것이다.
  
  

[edit]

3 유용한 링크들: ¶

다음은 Yum을 공부하는 사람들에게 유용한 링크들이다.:

• Yum 공식 웹사이트: http://www.linux.duke.edu/projects/yum
• Yum HOWTO (최신 버전): http://www.phy.duke.edu/~rgb/General/yum_HOWTO.php
• Yum에 대한 기사: http://www.phy.duke.edu/~rgb/General/yum_articicle.php 이것은 Yum에 관한 짧은 글로서, 일종의 "입문서"이다.
• Duke University Linux Users Group (DULUG) Red Hat 저장소 미러: http://mirror.dulug.duke.edu/pub/yum-repository/redhat 이 저장소 모음은 Yum에 최적화되었으며 Red Hat Linux 7.1부터 9까지 지원한다. Red Hat Linux가 내년 (2004)부터 이 버전들을 더이상 지원하지 않으므로 대부분의 사용자들이 Fedora를 선호하여 Red Hat Linux는 소용없게 되었다. 이것은 현재 기본 yum.conf에 포함된 저장소로서, Yum이 대부분의 Red Hat 사용자들을 위한 RPM 박스와 얼마간 자동으로 동작하도록 한다.
  
  

[edit]

4 일러두기 ¶

[edit]

4.1 Superuser 요구사항 ¶

리눅스와 유닉스는 일반사용자가 소프트웨어, 라이브러리, 또는 중요한 설정 정보를 설치, 제거, 변경하는 것을 막는다. On a networked, professionally run installation of workstations the need for this sort of control to ensure security and functionality is obvious. On a privately owned and controlled workstation, the need is less obvious but just as profound. Even there the owner of the workstation needs to take extreme care whenever working with the fundamental system configuration and package installation or they will likely break the system or leave it vulnerable to crackers.

To ensure that an adequate degree of care is exercised when doing things that could render a system unusable or vulnerable, linux and Unices require the owner of such a workstation to assume root privileges, usually by means of the su command. In order to execute the privileged commands to add or remove software from your system, you must therefore become root. To do this, enter (in a tty window such as an xterm):

$ su

root 암호를 입력한다. 프롬프트는 sharp 기호 `#'가 된다

# yum list

to remind you to be sharp as root.

경고! It is essential that you heed this advice to "be sharp" as you can destroy your system's installation with a careless keystroke, especially one involving wildcards such as '*' or '?'. Certain yum commands (notably upgrade and remove) can have unexpected side effects depending on the whims of the maintainers of RPMs in the repository, so caution and testing are advised. Be certain that you understand what a command will do, including side effects, before invoking it, especially with commands that delete files.

Some yum commands will actually work fine for ordinary, unprivileged users. In general these are the informational yum commands, discussed next. Note that the unprivileged commands do require that the yum header cache exist, so they will not work at all correctly if run before root has run a yum command to create current images of the header files.

[edit]

4.2 Yum 구하기 ¶

"Yum을 구하는 방법"에는 여러가지가 있다. :

• If you are only trying to obtain a copy of yum to install on your personal workstation so you can use it as a client, directing it for updates to one of the growing number of public repositories that support yum-based access, then you can download the prebuilt rpm's from the yum website linked below.
• If you are setting up a repository to serve a LAN (or even a WAN) or you are planning to install yum for use as a client only on a LAN, again directing it to one of the public repositories that support yum, and are not interested in participating actively in yum development, then you should get the yum tarball (.tgz compressed source directory) from the yum website linked below.
• Finally, if you are setting up yum for a LAN and either want to participate in yum's ongoing development (joining the yum list to get help and submit bug reports and patches) or encounter difficulty getting the stable version of yum downloaded from the yum website working (perhaps because your system is very new or not one of the distributions already well-supported), you will likely want to access the CVS repository and get a tarball of the current yum snapshot.
  
  

각각의 방법들은 아래에서 자세히 설명한다.

Yum RPM 내려받기

If your goal is just to get yum and install it on a client, you will likely just want to get yum in a ready-to-install-and-run rpm from from the main yum website. One can select and download the appropriate rpm for your architecture (which matters) from the yum website http://www.linux.duke.edu/projects/yum.

To explain the importance of matching architecture for a tool written in a presumably agnostic and slowly varying scripting language, note that yum is written in python (the agnostic and slowly varying language:-) and uses the python rpm bindings, the same as Red Hat's anaconda and up2date. Ahh, good news and bad news, same as always.

The good news is that the basic python code is indeed quite stable, and using the python-rpm bindings makes yum relatively unlikely to break, at least for long, as Red Hat has a vested interest in making these binding work for their own products.

The bad news is that as rpm changes (fairly rapidly in recent releases) the bindings change and yum needs revision. Hence there are thus several versions of yum available for download at this time, each matching a quite recent revision of rpm and (not coincidentally) a release number of Red Hat Linux.

Fortunately, there is a short table of download links on the server above where you can find ready to install rpm's for yum built for each of the recent major linux releases. If you have difficulty picking, ask on the yum list for help or try using the tarball of yum sources to build the right version automagically. Or both!

Note Well: The yum rpm's you will download from this site have an /etc/yum.conf that is preconfigured to point to a public repository that supports yum, probably http://mirror.dulug.duke.edu. Naturally, if the entire Internet got yum and started updating clients from this site, at some point it would pretty much get hammered to where it no longer worked. DULUG is not google, and this is a single not-particularly powerful server, not a web farm. You may well want to look over the list of public yum repositories and edit /etc/yum.conf to use one of the alternatives, or (if you are a LAN manager with a publically accessible webserver) set up a repository of your own and add it to the list, following the instructions in this HOWTO!

Yum Tarball 내려받기

To set up a repository of your own to serve a private LAN or public WAN or both, you will need the yum tarball so that you can build your own yum rpm with its configuration files and %post installation instructions customized for your site (following the instructions given in the next couple of sections). If you are new to yum, you should likely start with the stable tarball, not the development tree, and join the yum list. You'll know when it is time to move up and start using the public CVS repository to get the latest tarball snapshot instead of using the stable tarball.

To get the stable tarball is simple. Just visit the yum website, http://www.linux.duke.edu/projects/yum, and download it. Then skip ahead to the sections on planning a repository and building a custom yum rpm.

익명 CVS

As noted above, it is also possible to get yum directly from the CVS tree on the linux@duke repository. Most "normal humans" won't need or want to do this -- you are accessing the raw development tree, which might have cool new features or support a broader range of cutting edge distributions and releases, but which also might have bugs. Even immediately fatal bugs -- some snapshots you might grab will simply be pre-broken and need immediate replacement.

To use the CVS repository you don't quite need mad skills, but you do need to be familiar with and comfortable with the open source development process. Joining the yum mailing list is essential for example, and in fact if you are reading this in preparation for doing a CVS download I'm going to hope that you've been on the list already for a while, and are grabbing the CVS-based snapshot fully understanding that if it doesn't work you'll submit an immediate bug report and wait for (or help find) a solution, not scream because it "breaks" your production network.

It should almost never break your production network because anybody who participates in this sort of development cycle knows better than to immediately deploy such a snapshot without a fair bit of testing on clients and servers where if it turns out to be broken "it doesn't matter".

Don't let these dire-sounding warnings deter you, though. The entire operating system you are using (presuming that you are using Linux) was built by precisely this process, and many hands contributing a small bit of work, intelligently directed, can create incredibly powerful tools. Come on in, the water's fine! Especially if you have mad python skills and some clever ideas...;-)

To pull yum from cvs do the following:

cd ~
mkdir cvsroot
cd cvsroot
cvs -d :pserver:anonymous@devel.linux.duke.edu:/cvsroot/yum/cvs/\
  login
cvs -d :pserver:anonymous@devel.linux.duke.edu:/cvsroot/yum/cvs/\
  get yum

To update it once you've gotten it:

cd ~
cd cvsroot
cvs -d :pserver:anonymous@devel.linux.duke.edu:/cvsroot/yum/cvs/\
  upd yum 

{*Thanks to Russ Herrold for providing the above instructions*}

As noted above, it is strongly recommended that one become pretty thoroughly familiar with yum from using a stable release version and at least listening in on the yum list (which is mailman-managed and hence can easily be digested or throttled altogether) before tackling a CVS tree build. Knowing python is probably a good idea as well.

Once you have yum sources from either the stable tarball or the CVS tree, it is time to plan out your repository. This is detailed in the next section

[edit]

5 Yum 저장소 계획하기 ¶

시작하기 전에 용어를 몇 개 정의하자. When we refer to a "server" below, let me remind you that we are referring to a piece of hardware. Beware! In e.g. "man yum.conf" a server is really a label for a repository, not a web, ftp or file server that might be one of several that provide mirrored access to the same repository. This is made clear later in the man page, where it is referenced in practice as serverid. A single physical "server" might well offer several repositories, each identified by a unique URL path on the server and by a unique serverid in /etc/yum.conf on the clients. Each serverid may similarly have several fallback URL's for the same repository (generally on different servers). This may initially be confusing, but it makes sense and provides for extremely robust operation.

As discussed in the Introduction, yum works by means of accessing a "yummified" repository -- a URL-accessible path where yum-arch has been run on the server to create a special directory with a known relative path displacement from the RPMS directory used to actually provide the downloads, into which all of the split-off headers are placed so they can be separately downloaded and cached on the client side.

Simple as this is (really!) there is a bit of work that should be expended planning out a yum repository, especially if you are starting from scratch and don't already have an rpm repository in place to which you are planning to "add yum support". It is probably wise to start simple and work up to a complex system of repositories and servers gradually and as need dictates (many sites will ONLY need a single monolithic server, maintained by a single wise administrator, with a single repository apiece for each distribution supported).

However, it never hurts to know a bit about what can be done in terms of repository design. To meet specific needs of the fairly wide variety of systems persons already using yum and participating in its active development, some fairly slick features have been added: the ability to operate from multiple servers and repositories in an overlaid/prioritized fashion with failover, for example.

In a small LAN this is total overkill. If one is using yum to support an entire University, however, where each department has its own "special, must have" packages or (a more common case) some rpm's that set up e.g. /etc with the appropriate configuration for just that department, the ability to specify multiple repositories on different servers that are checked in a particular order lets those departments manage just the rpm's they require that are department specific or otherwise customized.

This keeps the manager of the central/primary repository(s) sane, as that individual does not have to juggle lots of departmental configuration rpm's with names like physics-stuff-0.1.1.noarch.rpm, biology-stuff-0.1.1.noarch.rpm,... and keeps the central/primary server secure, as the departmental lan managers do not need any sort of trusted access to the primary server. This has nothing to do with whether or not these departmental managers are fundamentally "trusted" -- it is simply always a good idea to heavily restrict and regulate root-level access to a server the cracking of which de facto cracks an entire network! Putting rabid mastiffs outside the door to the server room isn't out of the question.

The following is an approximate (probably incomplete, as features are constantly being discussed on the yum list and added) list of some of the options and True Facts to consider when planning, building, or modifying a yum-based rpm repository (set):

• Yum can currently work from either http (recommended) or ftp or nfs/file servers. All that is required is that the repository be accessible via a URL from the client(s) in question.
• Yum is configured in /etc/yum.conf to automagically access a list of repositories...
• Which are just URL's -- server paths to directories that contain rpms...
• According to a policy that determines the order they are checked...
• With failover, so rpms can be reliably delivered...
• And optional GPG signature checking, so rpms can be securely delivered...
• And control over architecture specificity, so one can load (e.g.) Athlon or i686 where it matters but i386 or noarch where it does not...
• And control over distribution specificity, so one doesn't accidentally update in a way that breaks things silently.
• In the True Facts category, since yum is designed to facilitate distributed maintenance (automated updates) of an rpm-based distribution of something -- operating systems, complete distribution, or even just a finite set of packages on some system installed and maintained with completely different tools -- the repository should be designed and built so that it remains up to date!
  
  

Some people won't need any of these bells and whistles. Start simple, yum's defaults are probably what you want anyway. Most people won't need more than one or two servers, perhaps a base distribution server (with primary repository images) plus an overlay server which might also mirror the primary repositories, used in a specified order, with GPG checking, for example. Some people, generally toplevel and local systems managers co-maintaining a repository network for a large organization, will use all of these features and even clamour for more on the yum list.

In the subsections below a strategy for planning out a yum repository/server set will be indicated that lets one smoothly move from a single server of a single repository (possibly originally mirrored from and updated from one of the existing distribution repositories) through to a really complex set of repositories on multiple servers that use all of the features.

[edit]

5.1 단일 저장소 (Rsync 사용) ¶

To set up your first repository, it probably makes sense to clone a repository from an existing server. Yum works to support pretty much any kind of rpm-based repository for any of the major Linux distributions across several hardware architectures, as well as for other operating systems that either already support rpm package management or upon which the rpm toolkits and python can be built. Unfortunately, that makes giving detailed instructions for EVERY ONE of those possibilities impossibly complex. It is probably better to give an example and leave it up to you to figure out what you need to do to set up a "leaping frog linux" distribution repository or a repository for all of the rpm's required to do molecular dynamics off of a common set of tools and data on a small cluster.

Ordinarily as a very first step one would pick a server/repository to mirror. Be cautious. Some repositories are public and their servers have lots of capacity. Others may require permission to use. Some will support rsync, others will require wget or worse as retrieval agents. Usually the repository itself will tell you what its policy is with respect to mirroring (and of course won't let you in at all if it is truly restricted), but it never hurts to ask if there is any doubt.

Rsync is probably the tool of choice for mirroring and maintenance. It only downloads files if it needs to and is very smart and (one hopes) reasonably secure. So we'll use rsync in our examples below. However, not everybody sets it up on their servers. So what do you do if the repository you wish to mirror doesn't support rsync?

At least one possibility (there are probably others) is to use wget. wget is a common tool that can be used to get whole branches, recursively, from a website in order to create a locally rereferenced copy or a mirror. It is beyond the scope of this HOWTO to detail all the steps at this point; but the wget documentation is fairly clear. Basically, one simply substitutes the appropriate wget invocation, (recursive and to an adequate depth and probably with links rereferenced, with the possibly different source url) for rsync in the examples below

For specificity only, then, the following example describes one way to set up a repository that is a mirror of the rsync-enabled dulug (primary, tier1) Red Hat mirror, and we'll even more specifically restrict ourselves to version 9 i386 and pretend that yum is not already installed on the repository.

We start by trying:

rgb@lilith|T:121>rsync mirror.dulug.duke.edu::
mirror.dulug.duke.edu
 - This rsync server is currently available to any/all people.
 - This is subject to change with little or limited notice.
 - We may in the not-so-distant-future restrict rsync access
   to tier2 red hat mirrors.


Modules:

archive         Everything
redhat-ftp      Red Hat FTP Site
redhat-base     Red Hat FTP Site
redhat-beta     Red Hat Linux beta releases
redhat-rawhide  Rawhide FTP Site
redhat-updates  Updates FTP Site
redhat-contrib  Red Hat, Inc. -- Contrib FTP Site



archive         Main Tree
redhat-ftp      Red Hat FTP Site
redhat-base     Red Hat FTP Site
redhat-beta     Red Hat Linux beta releases
redhat-rawhide  Rawhide FTP Site
redhat-updates  Updates FTP Site
redhat-contrib  Red Hat, Inc. -- Contrib FTP Site

Oh, good. Anonymous rsync is supported on this repository, and the repository's policy says we can go ahead, at least for now, and mirror any repository to be found on this site ourselves. However, it also notes that quite possibly access to this mirror in the near future will be restricted to tier2 mirrors (basically sites that let other people mirror them and hence REDUCE the load on the tier1 sites) if load gets to be more than it can handle, so perhaps you (who read this) might consider using a mirror of one of the tier2 mirrors instead, unless you are hoping to set up a site that will be a tier2 mirror and publically available in turn.

Base Repository

After a little bit of monkeying around with rsync and/or a web browser, we find the path we're looking for to a suitable "base" Red Hat 9 tree that will constitute our repository. In actual fact we'd probably want to mirror one level up from here even for a "version 9 only" repository, as one level up we'd find e.g. documentation and iso images for the release which we'd almost certainly like to have handy even if yum itself points to a repository path one directory down. For the purposes of this example, however, we go to our (already set up) web or ftp server and create a suitably named path to our new repository.

This path should probably contain something that indicates distribution and revision it contains as part of its eventual URL; http://whatever.org/base is probably a bad choice, but http://whatever.org/RedHat9/base might be ok, or something much longer if you have lots of distributions or revisions or other repositories on the server.

After creating the path, enter the directory and enter (for example):

rgb@lucifer|T:27#rsync -avH
mirror.dulug.duke.edu::redhat-ftp/redhat/linux/9/en/os .
mirror.dulug.duke.edu
 - This rsync server is currently available to any/all people.
 - This is subject to change with little or limited notice.
 - We may in the not-so-distant-future restrict rsync access
   to tier2 red hat mirrors.


Modules:

archive         Everything
redhat-ftp      Red Hat FTP Site
redhat-base     Red Hat FTP Site
redhat-beta     Red Hat Linux beta releases
redhat-rawhide  Rawhide FTP Site
redhat-updates  Updates FTP Site
redhat-contrib  Red Hat, Inc. -- Contrib FTP Site



receiving file list ... done
os/
os/i386/
os/i386/RedHat/
os/i386/RELEASE-NOTES-it.html
os/i386/dosutils/
os/i386/dosutils/fips15c/
os/i386/dosutils/fips20/
os/i386/images/
os/i386/RELEASE-NOTES-ja.html
...

(for a few hundred directories packages and files more) and we're off to the races.

Depending on your bandwidth, you will have a brand, spanking new Red Hat 9 repository in minutes to hours (however long it takes to transfer a few GB of RPM's and support materials). Obviously, a nearly identical process would work for any other distribution that has rsync-enabled originals or mirror servers. Don't forget to consider buying SOMETHING from the original distribution provider (if they sell anything) to help them make some money from providing the tremendous value you are about to distribute at zero marginal cost across a whole network of systems!

Updates Repository

The next thing to worry about is keeping the new base repository itself up to date. There are two levels to even this -- one is rsync'ing the repository itself with the master on a periodic basis. This is accomplished with a simple cron script that changes to the appropriate directory and reruns the rsync command. rsync is smart enough to only download and replace files if they've changed. rsync can be run to either delete files that disappear from the master (remaining absolutely faithful to the master image) or to get new files and update changed ones but leave the old copies of ones that disappear. You have to decide which policy is right for your site, as both have risks.

You may want to quit there, and if the primary repository image already contains an "updates" path where updates automatically appear as bugs are fixed and security holes plugged, you may be able to. The repository just installed should support basic network installs (if the distribution does in the first place) and automated yum updates to the images in the repository once your clients are appropriately configured.

However, in many cases you will need to worry about keeping this base system correctly updated outside of the automatic updates provided by the distribution maintainer or vendor.

There are a couple of reasons for this. One is that not every distribution will handle updates the same way. Some distributions may be very aggressive and maintain updates that match and replace their distribution tree with a numbering/dating scheme that yum can understand and that changes rapidly as security, performance, and bug patches are released (Red Hat does). Others might replace files in their master distribution silently, after you've come to rely on a feature that suddenly goes away. Others might be lazy and not update their master distribution at all, or may have specialized tools for detecting and retrieving updates. Finally, even if your master distribution is very reliable and aggressively maintained, you may wish to override its offerings and update from a local copy of some of the rpm's, perhaps because they contain custom patches or local data.

One solution to these various dilemnas is to add an updates repository separate (different URL/path, recall, quite possibly on the same physical server). Here you can again choose to rsync to an updates server somewhere else, or you can create one all your own and split updates out of the distribution itself any way you like.

[edit]

5.2 추가적인 저장소 및 서버 ¶

In addition to a separate update repository, you may well want (eventually) to add still more repositories, and possibly more servers (viewing a repository, recall as a specific path to a single URL source of rpm's not necessarily on a distinct server). Perhaps you want to make a games rpm repository available to everybody on campus, but not on the main server which is owned by philistines that view games as a waste of time. Perhaps you want to overlay department rpm's on top of a base distribution repository (set, including updates) on a central server.

The outline above, and the example of the more or less required base repository, should be enough to enable you to set up arbitrary URL pathways to new repositories for whatever purpose you like. However, yum cannot use these repositories yet. First one has to install yum on the server(s) and run the yum-arch command on each repository. This causes the rpm headers to be extracted and paths to be dereferenced in a way that makes yum ultimately very fast and efficient.

Once this step is completed, yum then allows clients, via options in yum.conf on the various clients, to access the repositories and servers in whatever order they like (or more likely, in the order specified in the yum client rpm they automatically loaded at install time from one of those repositories).

[edit]

6 Yum을 위한 FTP 서버 설정 ¶

FTP server를 설정하는 것은 아주 쉽다. 순서는 다음과 같다.:

• RPM 내려받기
• RPM 설치하기
• .conf 파일 편집
• FTP 서버 시작
• 연결 시험
  
  

[edit]

6.1 RPM 내려받기 ¶

리눅스에서 사용가능한 ftp가 많다. 대부분의 서버는 똑같은 것을 하므로 선택은 당신에게 달려있다. 내가 사용하기 좋아하는 ftp 서버는 vsftpd이다. The rpm is usually available from the installation discs or can be downloaded from rpmfind or just use google. vsftpd is used by many large companies as the ftp server of choice and is very secure (it's part of the name so it must be true, right?).

[edit]

6.2 FTP 서버 설치 ¶

VSFTPD가 당신의 기계에 이미 설치되어있는지 본다. 이것은 아래와 같이 쉽게 할 수 있다:

root@cartman> rpm -q vsftpd

The system will tell you if the server is installed or not. If you get this message 'package vsftpd is not installed' then you will need to install the ftp server.

First download the latest version of VSFTPD from your preferred mirror and save it to e.g. /tmp on the server. The ftp directory structure required for your repository is unlikely to exist yet so you will need to create the repository directories that you planned out above, for example:

root@cartman> mkdir -p /var/ftp/pub/9/updates/ 

(the -p flag tells mkdir to create the whole tree of directories as required).

To install/upgrade the ftp server run the following as root:

root@cartman>rpm -Uvh /tmp/vsftpd-1.1.3-8.i386.rpm

Note that one will want this rpm to be in a repository the server itself uses to yum update from in the long run. It is very likely to be in a primary distribution repository you mirror, but you may have to put it in a local/update repository you maintain yourself from some other source.

(You can of course use rpm -ivh vsftpd-1.1.3-8.i386.rpm to install the package if the package is not already installed. The flag -U is for upgrade and -i is for install. No big deal, they will both work if the package does not exist on your system, IMHO -U is just better practise. It is not a good idea to use rpm -i if a previous version of the package already exists on your system.)

[edit]

6.3 vsftpd.conf 파일 편집 ¶

After the ftp package has been installed you will need to edit the vsftp.conf file. This is usually found at /etc/vsftpd/vsftpd.conf. If it is not here then just run:

jdip@cartman>rpm -ql vsftpd

and look in the list where the .conf file is. To edit the .conf file you can use kate, gedit, vi or any other text editor. This is the configuration file for the ftp server. You will need to be root to change the file:

root@cartman>vi /etc/vftp/vsftp.conf

If your network is secure and behind a firewall then you can leave the following option in the .conf file. This option allows for anonymous ftp access to your server:

# Allow anonymous FTP? (Beware - allowed by default if you comment this out).
anonymous_enable=YES

You can also change the welcome message of the ftp server.

# You may fully customise the login banner string:
ftpd_banner=Welcome to yum FTP service.

If you want increased security for your ftp server then set the flag anonymous_enable=NO. This will force the user to log into the ftp server to get access to the packages. If you want to use this option then you will need to create a yum user on the server that can be used by the yum client to access the server. It is prudent to make users log into the ftp server, but if this is your private server then it may not be necessary.

Save the .conf file.

You will need to (re)start the service to activate the changes to the ftp server (see next section).

[edit]

6.4 FTP 서버 시작 ¶

If you installed VSFTPD from the rpm then VSFTPD can be started as a service:

root@cartman>service vsftpd restart

You should get this message:

Shutting down vsftpd:                               [  OK  ] or [ FAILED ]
Starting vsftpd for vsftpd:                         [  OK  ]

You will want your ftp server to start every time you start Linux so it is also prudent to run:

root@cartman>chkconfig vsftpd on
root@cartman>chkconfig --list vsftpd

아래와 같은 메시지를 보게 된다:

vsftpd          0:off   1:off   2:on    3:on    4:on    5:on    6:off

당신의 ftp server 는 이 기계에서 리눅스를 시작할 때마다 시작될 것이다. ftp server가 올라오고 연결을 기다리고 있다.

[edit]

6.5 FTP 서버 시험 ¶

It is a good idea to test that the ftp server is working correctly. This is easily done by logging onto the ftp server:

jdip@cartman>ftp 127.0.0.1
Connected to 127.0.0.1 (127.0.0.1).
220 Welcome to yum FTP service.
Name (127.0.0.1:root): anonymous
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

만약에 ls라고 프롬프트에서 친다면 'pub' 디렉토리의 내용이 보일 것이다. 보이는 것은 /var/ftp/pub 안의 내용이다. 이 경로(지금 설정된 저장소의 전체경로)는 미러사이트에서 rsync를 사용하여 빌드할 때 중요하다, for when you use yum-arch to "yummify" the repository (see below), and for setting up a local yum.conf for your local clients so that they can update from this ftp-based repository.

That is it. ftp 서버가 돌아가고 연결을 기다리고 있다. Skip ahead to where it describes how to get and install yum and yummify the repository.

[edit]

7 Yum 빌드하기 ¶

Before proceeding further, we need to have yum itself handy, specifically the yum-arch command and its current documentation. If you are working from the rpm's, you've probably already installed them on your repository (I mean actually installed the program, not necessarily inserted the rpm's into a server on the repository) and one or two test clients. If not, please do, and skip ahead to the sections on installing yum or setting up a server with yum-arch and creating a suitable /etc/yum.conf.

However, if you get the sources via tarball or from the CVS repository, you will have to locally build yum. If you plan to repackage it (basically required if you are setting up a repository ) so that yum clients automatically use the yum-based repositories you set up in their /etc/yum.conf, you will need the tarball (yum-*.tgz) anyway.

The steps required to transform the provided tarball into an rpm are given below. Note that many of these steps are not yet fully documented in the source README or INSTALL files and are a major reason a HOWTO is sorely needed by the project. Most of yum's current systems manager users are already sufficiently expert to be able to build rpm's without additional instructions, but of course many who would like to use yum are not, and in any event it never hurts to document a moderately complicated process even for the experts.

Experts can also disagree. The steps below are ONE way of proceeding, but there are many others. Some managers will be working in monolithic (topdown) management models where they have root control of all clients and will prefer to push /etc/yum.conf out to the clients directly, not de facto pull it onto clients during an install from a repository where it is available, preconfigured for the site in rpm form. Tools exist to make this simple enough (cfengine, rsync, more).

Different people also have different ways of building rpms. Some always proceed as root, for example, using /usr/src/redhat (which exists for that purpose, after all). However, in my own mind working as root is something to be avoided as much as possible because of the risk of unintended consequences when one makes a mistake. Some of you reading this HOWTO may be very uncomfortable working as root for this very reason. I therefore provide step by step instructions on how to turn the yum tarball into an rpm as either a user or as root.

Naturally, the rpm will have to be installed as root either way

Or at least, I'll provide them later. For the moment, I'm all tapped out and have to go anyway. I may not even return to this project for a few days. Told ya' it was a work in progress....

[edit]

7.1 Root로 Yum RPM 만들기 ¶

[edit]

7.2 User로 Yum RPM 만들기 ¶

[edit]

8 Yum 설치하기 ¶

Yum is installed (originally) more or less like any other rpm you add to an existing system. After downloading one of the rpm's above you simply:

rpm -Uvh yum.X.rpm

where X is, of course, the revision number you downloaded. Do this initially on the server(s) you wish to use as yum repositories and perhaps a single test client only. If this install fails, be sure that yum's dependencies are satisfied on your system. As of right now its dependency list reads something like:

rgb@lilith|T:167>rpm -qR yum
/bin/sh
/bin/sh
/bin/sh
/sbin/chkconfig
/sbin/service
/usr/bin/python
config(yum) = 1.97-20030522
python
rpm-python >= 4.2
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1

on Red Hat 9. Version numbers will of course change, but this gives you an idea of what it will need in order to install. If you simply cannot get an install to work, try a different rpm or seek help from the yum list.

It is beyond the scope of this HOWTO to describe how to set up any of the servers that can be used as vehicles for a yum repository. Fortunately, documentation for setting up an FTP or HTTP server on a linux (or general Unix) server exists in abundance. Interested novices are referred to The Linux Documentation Project website, where one can find HOWTO's (like this one), FAQ's, and outright books on doing nearly anything complex on a linux system. Your favorite technical bookstore is likely to have good books on at least the more important tools (such as apache).

For our purposes here, we will assume that you already have a functional HTTP or FTP server that you wish to make into a repository. It will need good bandwidth to all the clients you wish it to serve. It may need mechanisms to be in place to restrict access to the server to a local domain, or you may be comfortable permitting the server to be used by outsiders. It should be very strictly controlled in terms of access and security as it is an obvious target for crackers seeking to take over an entire network by slipping a malware rpm onto your repository for "automated update" to an entire network at once.

A double-barrelled shotgun behind the server room door, loaded with salt and tacks, is not out of the question.

With this given, we will now present instructions for setting up an rpm repository and preparing it so that yum clients can use it for all of their operations.

[edit]

9 Yum에 최적화된 서버 구성: yum-arch ¶

[edit]

9.1 비기술적인 설명 ¶

기본적으로 yum-arch가 하는 모든 것은 디렉토리에 들어있는 rpm들을 간추리고 각각의 rpm을 위한 헤더를 만들어내는 것이다. 이 말은 "매우 고차원적"이며 yum-arch 프로그램의 중요성을 격하시킬 의도가 아니다. yum-arch는 Yum의 초석이다. 이것이 없다면 rpm을 고수하는 것이 차라리 낫다.

[edit]

9.2 FTP 서버를 위한 헤더 만들기 ¶

yum-arch를 root로 실행해야 할 필요가 있을 것이다.

정확한 디렉토리에 Yum 헤더를 생성하는 것은 중요한 사항이다. 만약 그렇게 하고 싶다면, 저장소의 시작 디렉토리에서 yum-arch를 실행하여 모든 rpm 해더들을 포함한 하나의 커다란 headers 디렉토리를 생성할 수 있다. 하지만 꼭 그렇게 해야 하는 것은 아니다.

생성된 headers 디렉토리는 yum.conf 파일을 작성하는 데 있어서 직접적인 영향을 끼치므로 주의깊게 고려해야 한다. Yum이 (yum.conf를 통해) headers 디렉토리를 가리킬 수 있도록 해야 하는데, 그렇지 않으면 Yum은 headers를 찾지 못하고 따라서 패키지들도 찾을 수 없게 된다.

디렉토리 구조를 깔끔하고 정확하게 구성하는 것을 확실히 해두어야 한다. 이것은 어떤 일이 잘못 되었을 때 처리가 쉽도록 해준다. 뿐만 아니라 원격 서버 디렉토리 구조를 복제했을 경우 로컬 미러를 rsync하기 쉽도록 해준다.

/var/ftp/pub 내의 예제 트리는 다음과 같을 수 있다:

        /9/
          /base/
               /athlon
               /i386
               /i586
               /i686
          /freshrpms
          /fedora
          /kde/
              /3.1.2
              /3.1.3
          /rawhide
          /updates/
                  /athlon
                  /i386
                  /i586
                  /i686

따라서 다음 명령을 실행하면

root@cartman>yum-arch /var/ftp/pub/9

yum-arch는 'headers' 디렉토리를 /var/ftp/pub/9 속에 생성할 것이고 /9/ 아래 전체의 트리를 위한 모든 헤더 파일들을 그 디렉토리 속에 담아둘 것이다.

디렉토리 구조는 다음과 같아질 것이다:

        /9/
          /base/
               /athlon
               /i386
               /i586
               /i686
          /freshrpms
          /fedora
          /headers              # yum-arch가 여기에 헤더들을 생성함.
          /kde/
              /3.1.2
              /3.1.3
          /rawhide
          /updates/
                  /athlon
                  /i386
                  /i586
                  /i686

이것은 제대로 동작할 것이지만 yum-arch를 사용하는 가장 깔끔한 방법은 아니다. 모든 헤더들이 하나의 디렉토리에 담겨졌을 때, 그룹과 같은 몇가지 새로운 기능상의 문제들 또한 발생한다.

따라서 한가지 해결책은 저장소 트리내의 개별적인 부저장소에서 yum-arch를 실행하는 것이다. 이것의 예제는 다음과 같다:

root@cartman>yum-arch /var/ftp/pub/9/base
root@cartman>yum-arch /var/ftp/pub/9/freshrpms
root@cartman>yum-arch /var/ftp/pub/9/fedora
               등등...

yum-arch가 모든 rpm들을 간추린 후에는 각각의 부저장소에 headers 디렉토리가 생길 것이고 디렉토리 구조는 다음과 같게 된다:

        /9/
          /base/
               /athlon
               /headers
               /i386
               /i586
               /i686
          /freshrpms/
                    /headers
          /fedora/
                 /headers
          /kde/
              /3.1.2
              /3.1.3
              /headers
          /rawhide/
                  /headers
          /updates/
                  /athlon
                  /headers
                  /i386
                  /i586
                  /i686

이제 헤더들을 손수 생성했으므로 yum의 사용개시를 위해 클라이언트가 headers를 가르키도록 yum.conf 파일을 관리할 필요가 있을 것이다.

[edit]

9.3 고급 명령어 ¶

yum-arch는 헤더를 생성하는 방식에 영향을 줄 수 있는 다양한 옵션을 가지고 있다.

root@cartman>yum-arch [options] directory

트리내의 의존성 및 충돌을 체크 (-d)

root@cartman>yum-arch -d directory

이 명령은 저장소에 수많은 rpm들이 있는 상황에서 단지 가장 최근의 rpm들을 위한 헤더만을 생성하고 싶을 때 매우 유용하다. yum-arch -d는 매우 장황해서, yum-arch가 하는 일에 대한 다량의 정보를 보여준다. 수많은 충돌과 의존성이 있을 수 있으므로 이것을 파일로 출력하는 것은 좋은 생각이 될 수 있다.

이것은 충돌의 한 예제이다:

Checking deps 91 % complete warning: package samba-client = 3.0.0-5rc1 was already added, replacing with samba-client <= 3.0.0-5rc1

그리고 이것은 의존성 실패의 한 예제이다:

depcheck: package xmms-devel needs xmms = 1.2.7

이러한 메시지들은 매우 유용하며 문제점들이 저장소의 어디에서 발생하고 있는 지를 지적해 준다. 많은 사람들이 이러한 메시지들을 무시하는데 그것은 그들의 선택사항이다. 메시지들은 이유가 있기 때문에 거기에 있는 것이다.

충돌에 대한 가능성 있는 해결책

이것은 매우 간단하다. 저장소에서 가장 오래된 rpm들을 지워라. 이것은 (앞서 말했듯이) rsync를 사용하여 행해져야 한다. 원격 미러를 로컬로 복제하기위해 사용하는 rsync는 원격 서버에 존재하지 않는 로컬 파일들을 삭제하도록 설정할 수 있다.

의존성 문제에 대한 가능성 있는 해결책

이것은 간단할 수도 그렇지 않을 수도 있다.

만약 미러중인 어떠한 저장소에도 없는 패키지에 대한 요구로 의존성 문제가 발생했다면, rpmfind에서 그 패키지를 찾거나 혹은 (패키지를 위한 소스들이나 데이터가 있다면) 직접 rpm을 제작해야 한다. rpm 제작은 아래에 소개되어 있다.

경고 한 마디: (만약 완벽한 미러를 유지하기 위해 --delete 옵션을 사용한다면) 미러에 없는 어떠한 패키지들도 rsync에 의해 로컬 저장소에서 삭제될 수 있으므로 이러한 사이트-로컬 패키지들을 "따로" 저장소에 보관해둘 필요가 있다. 분명히 경고했다.

만약 의존성 문제가 더 복잡하다면 (제작자들이 이름/버전붙이기 규칙을 다르게 사용하는 서로 다른 저장소로 부터 온 두개 혹은 그 이상의 패키지들을 사용하거나, 대부분의 응용프로그램들이 최근의 라이브러리를 요구하는데 오래된 버전의 라이브러리를 요구하는 독자적인 혹은 비공개소스의 패키지인 "legacy"를 사용한다면 문제가 매우 복잡해질 수 있다. 그렇다면) 그 문제들을 해결하기 위해 훨씬 더 열심히 작업을 해야만 할 것이다. 실제로, 어떤 경우에는 속수무책일 수도 있다. -- 중요한 임무수행을 하는 응용프로그램들 중의 하나가 특정한 배포본 및 그것의 바이너리들에 얽힌 libc나 기타 라이브러리를 요구한다는 이유로 세상에는 "시대에 뒤진" linux 배포본을 구동하는 수많은 사이트들이 있다.

운좋게도, 마치 Yum이 손쉬운 업그레이드를 해주는 것처럼 (그렇다면 왜 복잡한 저장소 트리가 필요한가?) 복잡한 저장소 트리를 쉽게 관리할 수 있도록 해주므로, 최악의 경우 그 해결책은 충돌하지 않는 배포본에 대한 저장소 트리를 따로 유지하는 것이다. 물론, 이것은 좋지는 않지만, 공개 소스 세계에서는 (혹은 같은 문제로 비공개 소스의 세계에서도) 공통의 규칙들을 준수하는 중요 패키지의 제작자를 지정할 수 없고, 단지 그들이 그 일을 해 주기를 바라며 그렇지 못할 때는 그것을 처리해 주기를 바랄 뿐이다.

출력을 장황하게 만들기 (-v 와 -vv)

root@cartman>yum-arch -v directory

이 명령어는 yum-arch 가 당신의 저장소에 있는 모든 패키지들과 함께 무었을 하는지 볼수 있게 하는데 매우 유용하다. 많은 양의 정보가 만들어지기 때문에 당신은 그것을 이용하기 위해 그 정보를 파일로 출력하기를 바랄것이다. 여기 장황한 출력의 예가 있다.:

ignoring older pkg: redhat/9/i386/openssh-askpass-gnome-3.5p1-6.9.i386.rpm
Digesting rpm - openssh-askpass-3.5p1-6.9.i386.rpm - 95/3202
Already found tuple: openssh-askpass i386

ignoring older pkg: redhat/9/i386/openssh-askpass-3.5p1-6.9.i386.rpm
Digesting rpm - openssh-3.5p1-6.9.i386.rpm - 96/3202
Already found tuple: openssh i386

ignoring older pkg: redhat/9/i386/openssh-3.5p1-6.9.i386.rpm
Digesting rpm - openssl096-0.9.6-17.i386.rpm - 97/3202
Digesting rpm - openssl-0.9.7a-5.i386.rpm - 98/3202
Digesting rpm - pam_smb-1.1.6-9.9.i386.rpm - 99/3202
Digesting rpm - php-4.2.2-17.2.i386.rpm - 100/3202
Digesting rpm - php-devel-4.2.2-17.2.i386.rpm - 101/3202
Digesting rpm - php-imap-4.2.2-17.2.i386.rpm - 102/3202
Digesting rpm - php-ldap-4.2.2-17.2.i386.rpm - 103/3202
Digesting rpm - php-manual-4.2.2-17.2.i386.rpm - 104/3202

얼마나 더 많은 정보가 필요한가? 일단 yum-arch가 제대로 동작하고 정확한 헤더를 생성해낸 것에 만족한다면 출력이 더 장황할 필요는 없다. yum-arch는 보통 cron으로 실행되므로 실제로 그 출력에 대해 잘 알지 못한다. 출력이 존재하며 과거에 몇몇 이상들을 잘 설명해주었다는 사실을 아는 것만으로도 좋다.

헤더를 생성하지 않기 (-n)

root@cartman>yum-arch -n directory

의존성을 체크할 때, 실제로 헤더를 생성하고 싶지 않을 수도 있다. 정말로 중대한 충돌문제가 존재한다면 헤더 집합이 "망가질" 창구를 제공하고 싶지는 않을 것이고, 다만 막 새 패키지를 추가했을 때 그것이 충돌을 일으키는지 여부만 알고 싶을 것이다. -n 옵션은 헤더의 자동 생성을 억제하도록 해준다.

출력을 더 잠잠하게 하기 (-q)

root@cartman>yum-arch -q directory

쉬이이잇.

-q 옵션은 yum-arch가 생성하는 정보의 양을 정말로 줄이기는 하지만 그렇다고 yum-arch가 절대적으로 조용해지지는 않는다. 화면에 충돌여부나 간추린 패키지들이 나타날 것이다. 일단 yum-arch가 원하는 일을 수행해냈다는 사실에 만족한다면 (즉, 다음번에 실행할 때는) yum-arch를 매일 실행되는 cron 작업으로 만들 것이다. yum-arch가 헤더를 생성하고 단지 경고들만 알려주는 정도로 사용할 때 -q 옵션은 최상의 플래그이다.

gpg와 md5로 패키지 검사하기 (-c), -n과는 (명백히) 함께 쓸 수 없음

root@cartman>yum-arch -c directory

흠... 이 명령으로는 혼란만 가중시킬 뿐이다. 간혹 사용하기는 하지만 모든 패키지가 MD5 체크섬을 가지고 있다거나 gpg 서명을 가지고 있는 것은 아니다. 만약 보안에 민감하며 내려받은 패키지에 대한 확신을 갖고 있지 않다면 그때 이 옵션을 사용하라.

{이 플래그가 내겐 동작하지 않았음 -- jp}

gzip으로 헤더를 압축하기 (-z)

root@cartman>yum-arch -z directory

....

심볼릭링크를 처리하기 (기본값은 심볼릭링크 무시) (-l)

root@cartman>yum-arch -l directory

.....

...정말로 해야할 꼭 필요한 것

root@cartman>yum-arch directory

저장소를 위한 헤더를 생성하기 위해 yum-arch를 사용할 때, yum-arch는 항상 화면 보고의 맨 끝에 다음과 같은 두 줄을 출력한다. (-q는 제외):

   Total: 3202                  #Total packages read
   Used: 1521                   #Total headers created

이것이 바로 정말로 알아야 할 모든 것이다. 이 두 줄이 무엇을 말해주는 것일까? 우선 패키지의 반 이상이 헤더가 생성되지 않았으므로 저장소를 정리할 필요가 있다. 이것은 보통 몇몇 패키지가 저장소에서 중복되었거나 충돌하기 때문에 기인한다. 아마도 저장소에 rawhide 패키지들이 있기 때문에 발생하는 것이다. 최신식 그것이 원인이다.

[edit]

10 Yum 클라이언트 설정 ¶

[edit]

10.1 /etc/yum.conf ¶

yum.conf 파일에는 두 부분의 섹션이 존재한다.: main 과 server 이다. main은 모든 전체설정 옵션을 정의한다. server 섹션(들)은 각각의 서버에 대해서 정의한다.

yum이 어떤 동작을 하기 위해서는 main 섹션이 반드시 있어야한다. 아래 보이는 것이 일반적인 main 세션의 형태이다.:

[main]
cachedir=/var/cache/yum
debuglevel=2
logfile=/var/log/yum.log
pkgpolicy=newest
distroverpkg=redhat-release

Here is the meaning of the various options (straight from "man yum.conf", in case you haven't read this yet). All options are of the form:

option=value

Note that most of the options can be left at the default and yum will function just fine.

• cachedir: Directory where yum should store its cache and db files.
• debuglevel: debug level. valid numbers are 0-10. default is 2.
• errorlevel: another debug level. valid numbers are 0-2. default is 2.
• logfile: full directory and file name for where yum should write its log file.
• assumeyes: 1 or 0 - tells yum whether or not to prompt you for confirmation of actions. Same as -y on the command line. Default to 0.
• tolerant: 1 or 0 - Tells yum to be tolerant of errors on the command line with regard to packages. For example: if you request to install foo, bar and baz and baz is installed; yum won't error out complaining that baz is already installed. same as -t on the command line. Default to 0(not tolerant)
• pkgpolicy: newest or last - Package sorting order. When a package is available from multiple servers, newest will install the most recent version of the package found. last will sort the servers alphabetically by serverid and install the version of the package found on the last server in the resulting list. If you don't understand the above then you're best left not including this option at all and letting the default (newest) occur.
• exclude: list of packages to exclude from updates or installs. This should be a space separated list. Filename globs *,?,., etc are allowed.
• exactarch: 1 or 0 - set to 1 to make yum update only update the architectures of packages that you have installed. i.e.-- with this enabled yum will not install an i686 package to update an i386 package.
• commands: list of functional commands to run if no functional commands are specified on the command line. i.e: commands = update foo bar baz quux none of the short options (-y, -e, -d, etc) will be taken in the field.
• distroverpkg: package to use to determine the "version" of the distribution - can be any package you have installed - defaults to redhat-release.
• diskspacecheck: set this to 0 to disable the checking for sufficient diskspace before the rpm transaction is run. default is 1 (to perform the check)
• retries: Set the number of times any attempt to retrieve a file should retry before returning an error. Setting this to 0 makes it try forever. Default to 3.
• kernelpkgnames: list of package names that are kernels - this is really only here for the kernel updating portion - this should be removed out in 2.1 series.
• installonlypkgs: list of packages that should only ever be installed, never updated - kernels in particular fall into this category. Defaults to kernel, kernel-smp, kernel-bigmem, kernel-enterprise, kernel-debug, kernel-unsupported.
  
  

In addition, there must be at least one server section. Note well that "server" here does not refer to a single physical machine, nor does it necessarily refer to a single repository, a server id (this is made clear in the man page for yum.conf). As such it is an arbitrary but unique label attached to a set of (usually identical/mirrored) repositories that will in general be on different physical machines to provide a measure of fallback robustness in operation.

Note well that yum creates cache directories according to the label in the server tag. If the fallback repositories are not in fact mirrors and consistent with the primary repository, odd things can be expected to occur that are very likely not going to be what you intended to happen.

Server sections inherit global options from main, but also have options of their own. Consider the following example:

[duke-base]
name=Linux@Home $releasever - $basearch - Base
baseurl=http://192.168.1.2/dulug/$releasever/$basearch/
        http://install.dulug.duke.edu/pub/dulug/base/$releasever/$basearch
gpgcheck=0

[duke-distrib]
name=Linux@Home Distributable add-on packages - $releasever $basearch
baseurl=http://192.168.1.2/dulug/$releasever/$basearch-distrib/
        http://install.dulug.duke.edu/pub/dulug/add-on/distrib/$releasever/$basearch
gpgcheck=0

[duke-nondistrib]
name=Linux@Home Nondistributable add-on packages - $releasever $basearch
baseurl=http://192.168.1.2/dulug/$releasever/$basearch-duke/
        install.dulug.duke.edu/pub/dulug/add-on/duke/$releasever/$basearch
        http://localhost:33333/pub/dulug/add-on/duke/$releasever/$basearchgpgcheck=0
gpgcheck=0

[home]
name=Linux@Home personal add-on packages - $releasever $basearch
baseurl=http://192.168.1.2/dulug/$releasever/$basearch-local/
gpgcheck=0

[ayo]
name=freshrpms
baseurl=http://ayo.freshrpms.net/redhat/9/i386/freshrpms/
gpgcheck=0

This example illustrates much of the power of yum. There are five distinct repositories indicated. The first, duke-base, is linux@duke's Red Hat 9 public repository. However, I use yum at home to keep my LAN up to date through a low-bandwidth DSL link. I have some ten computers that update nightly and don't want to have to move headers and rpm's through the link for each one. So I maintain a full mirror via rsync of this repository, and use it by preference rather than the repository at Duke.

Duke has two more collections of packages it provides in different repositories. One is open source/free add-ons to the base Red Hat distribution. This repository is open to the public, but less likely to be of use to people who aren't associated with Duke. I use some packages from this repository and so include in yum.conf, again first from a local mirror in my home LAN and from Duke through the DSL link only as a fallback.

The second repository contains packages that for one reason or another cannot be openly distributed. There are proprietary, site-licensed packages there, or packages with private data, for example. Although as a Duke faculty person I'm entitled to use these packages at home, only duke.edu addresses can access the repository. However, I connect via an ISP.

The duke-nondistrib entry thus tries to update from the home mirror (which I have to rsync via an ssh forwarded port). If this doesn't work it tries to access it directly (which might succeed on e.g. my laptop, if I've brought it into Duke). Finally, if neither of these work it tries localhost:33333, hoping that I've hotwired an ssh port forward at that address in case my laptop is not at home or at Duke, but I suddenly need access while I'm on the road.

The home entry is where I put those rpm's I build at home strictly for local/home distribution. This is surprisingly useful -- a good way to move around certain configuration files, for example, and there are a few packages I find to install that aren't maintained at Duke at all.

The ayo entry is a public rpm repository that contains one or two libraries that I need that aren't at Duke and that I don't want to build locally.

As one can see, yum can be amazingly powerful and flexible in the way that it is configured to use repositories (and their fallback mirros) in layers, each layer providing a different set of packages. Most yum clients will need a much simpler yum.conf than this -- in many cases one with a single server entry. However, systems managers who wish to install packages in layers from a common public repository and one or more private repositories will find that yum is designed to accomplish this in the most natural manner possible.

[edit]

10.2 /etc/cron.daily/yum.cron ¶

[edit]

10.3 /var/cache/yum ¶

[edit]

10.4 설정 배포하기 ¶

yum RPM을 곧장 작동가능하게 리빌드하기

Push tools

[edit]

11 Yum 클라이언트 사용하기 ¶

yum을 위한 현행 명령어 일람은 다음과 같다.:

    사용법:  yum [옵션] <update | upgrade | install | info | remove | list |
            clean | provides | search | check-update | groupinstall | groupupdate |
            grouplist >
                
         옵션:
          -c [설정 파일] - 사용할 설정 파일 지정
          -e [오류 수준] - 오류 기록 수준 설정
          -d [디버그 수준] - 디버그 수준 설정
          -y 모든 질문에 yes로 응답
          -t 패키지 명령에 관한 오류는 용인
          -R [분 단위의 시간] - 무작위로 실행되는 최대 시간 설정
          -C 캐시에 대해서만 실행 - 캐시를 갱신하지 않음
          --installroot=[경로] - 설치 루트 위치를 설정 (기본값은 '/')
          --version - yum의 버전을 출력
          -h, --help 이 화면

(버전 2.0.4에 한함).

[edit]

11.1 루트 권한이 필요한 Yum 명령어 ¶

다음의 명령들은 파일들을 설치, 갱신 및 삭제함으로써 파일시스템을 변경한다. 처음으로 yum을 실행하면, /etc/yum.conf에 지정한 장소로 모든 헤더 파일들을 내려받고 캐시하는데, 이것 또한 루트 권한을 요구한다. 그 후에는 특별한 권한이 필요없는 명령들은 모든 사용자가 일반적으로 동작시킬 수 있지만, 아래에 나열한 명령들은 오직 루트로만 동작할 것이다.

Yum으로 패키지 설치하기

  # yum install 패키지1 [패키지2 패키지3...]

Yum은 패키지1이 이미 설치되어 있고 최신 버전인지 체크할 것이다. 만약 그렇지 않다면, 패키지1{그리고 모든 의존관계에 있는 패키지들}을 (캐시 디렉토리에 저장하면서) 내려받고 설치한다. 추가적으로 설치할 패키지들은 같은 명령줄에 나열하면 된다. 패키지 이름은 표준 파일시스템 glob으로 지정할 수도 있다. 몇가지 예를 들면:

  # yum install jpilot

이것은 jpilot 패키지(팜 파일럿을 위한 매력적인 인터페이스를 제공하는 도구)를 탐색하여 이 패키지가 존재하는 yum 저장소가 하나라도 있다면 이 패키지를 설치할 것이다.

  # yum install festival\*

이것은 festival speech generation 프로그램과 speech 분석을 해주는 개발 소프트웨가 실행되기위해 필요한 모든 패키지들(예: festival 및 festival-devel)을 설치할 것이다. 쉘에서 "*" 문자를 처리하기 위해 "\"가 필요함에 유의하라.

Yum으로 패키지 업데이트하기

  # yum update 패키지1 [패키지2 패키지3...]

Yum은 패키지1이 이미 설치되어 있고 최신 버전인지 체크할 것이다. 만약 그렇지 않다면, 패키지1{그리고 모든 의존관계에 있는 패키지들}을 (캐시 디렉토리에 저장하면서) 내려받고 (효과적으로 업그레이드하면서) 재설치할 것이다. 추가적으로 업데이트할 패키지들은 같은 명령줄에 나열하면 된다. 패키지 이름은 표준 파일시스템 glob으로 지정할 수도 있다. 몇가지 예를 들면:

  # yum update

어떤 면에서는 이를 위해 yum이 개발되었다고도 할 수 있는, 가장 중요하고 유용한 yum 명령어들 중의 하나이다. 이 명령은 시스템에 설치된 모든 패키지들을 저장소들에 있는 최신 버전으로 업데이트한다. 이는 시스템을 단순한 스크립트 하나로 최신의 상태로 유지할 수 있게 하며, 필요할 때 언제든지 어떤 패키지라도 업데이트할 수 있게 한다.

  # yum update jpilot

이것은 jpilot 패키지(팜 파일럿을 위한 매력적인 인터페이스를 제공하는 도구)를 탐색하여 이 패키지가 존재하는 yum 저장소가 하나라도 있다면 이 패키지를 업데이트할 것이다.

  # yum update festival\*

이것은 마침 시스템에 설치되어 있는 festival speech generation suit에 포함된 모든 패키지들을 업데이트할 것이다. 쉘에서 "*" 문자를 처리하기 위해 "\"가 필요함에 유의하라.

Yum으로 패키지 삭제하기

패키지를 삭제할 때는 항상 주의를 기울여야 한다. 그 이유는 의존성 관계 때문이다. - 만약 설치되어 있는 다른 패키지들이 (그 패키지의 공유 라이브러리를 사용하기 위해서, 설정 파일을 읽기 위해서, 심지어 바이너리를 참조하기 위해서) 의존하는 어떤 패키지를 삭제한다면 의존관계에 있던 다른 패키지들은 "덩그러니" 남게 되고 부분적 혹은 전체적인 기능장애 상태로 있게 될 것이다. Yum은 패키지 삭제와 관련해서 가능한 파괴의 부작용을 피하도록 도와주는데, 이런 부류의 일들이 항상 그렇듯이, 사용자로 하여금 이를 사용할 때 주의깊게 생각하도록 요구하는 것이다. 그러므로 패키지를 삭제할 때 비대화식으로 Yum을 사용하는 것은 가장 현명하지 못한 것이다.

절대로 시스템을 불일치된/깨진 상태로 만들지 않는다는 것이 Yum의 기본 설계 철학이므로 (Yum은 어떠한

--force

와 같은 옵션도 지원하지 않는다.) 만약 yum으로 어떤 패키지 삭제를 요청한다면, yum은 그 패키지에 의존적인 모든 패키지들 또한 삭제하려 시도할 것이다. 패키지 삭제의 과정은 모든 의존관계를 따라서 반복되므로 만약 삭제하려는 패키지가 X 자체나 아파치가 의존하고 있는 것이라면, 그것은 마치 {사용자 환경 전체}나 {웹서버 전체}를 삭제하려는 것과도 같다. 대부분의 경우, 이것은 원하는 바가 아닐 것이다.

상황을 이해해보자. 어떤 경우에 단지 맨 위 수준의 패키지 하나만 지우려고 의도하지만, 설치된 다른 패키지들이 그 패키지에 의존적이라는 사실을 깨닫지 못할 수도 있다. 이러한 경우에 Yum은, 다른 어떤 것에 정말 필요하다는 사실을 깨닫지 못한 채 어떤 패키지를 삭제하는 것을 방지하는 일종의 서비스를 제공한다. 다른 경우로, 단지 그 의존성을 만족시켜주는 또 다른 패키지로 대체하려고 어떤 패키지를 삭제하려는 것 뿐인데, 막 의존성이 결여된 패키지들을 다시 연결시켜 주려는 참인데 왜 yum이 관련된 모든 패키지들을 지우려고 드는지에 대해 따지고 싶을 지도 모른다.

여러가지 이유들이 있다. 한 가지 이유는, 만약 상호연결된 의존성 트리를 심혈을 기울여 완벽하게 확장시켜오지 못했고, 해당 의존성 트리에서 모든 프로그램 및 도구들을 철저하게 테스트해보지 못했다면, 지금 잠깐 삭제하려는 패키지가 정말로 완전히 대체되어 동작할 지는 알 수 없다는 것이다. 대체 패키지가 필요한 파일이나 프로그램 혹은 라이브러리를 제공한다는 사실을 아는 것 만으로는 불충분하다. -- 시간에 따라 바뀔 수 있고 정말 그렇기도 하므로, 필요한 파일이나 프로그램 혹은 라이브러리의 버전 의존성에 대해 철저히 작업해야만 한다. 새 기능이 추가되고, 구 기능은 사라지며, 똑같은 일반적인 목적을 수행하는 같은 이름의 두 프로그램도 결정적으로 다른 인자들을 취하게 된다.

물론 어떤 경우에는 단지 한 패키지를 삭제하고 그것을 같은 이름을 가진 더 최신의 패키지로 대체하길 원한다. However, this is what the update command above does for you already as an atomic entity that never leaves the dependencies dangling, and in general you should use it instead, as it is likely to do a far more careful job of resolving the dependencies and ensuring that the updated package will still suffice.

There is one more place where this sort of remove-and-replace activity is likely to occur - when a package is obsoleted by another package. A package is obsoleted when it is removed entirely from an entire distribution/dependency tree and replace by a completely different package (different name, possibly different contents). This happens fairly regularly, if rarely, especially when the obsoleted package provides a configuration file that is shared by several tools. RPM's obsoletion process is very tricky, and can break things even when used correctly as it depends on all the packages in the dependency tree doing the right thing. Package are often obsoleted when a distribution changes its revision number, as that is the right time to manipulate entire branches of the tree with minimal impact.

The yum upgrade command listed below is the solution to the problem of obsoletion. It functions much like update, except that it manages the RPM obsoletes.

어떤 경우든, 패키지 삭제를 위한 명령어 구조는 다음과 같다.:

  # yum remove 패키지1 [패키지2 패키지3...]

앞서 말했듯이, 이 명령은 패키지1과 더불어 이 패키지에 의존적인 모든 패키지들을 삭제한다. (아마 설정 자료에 관한 한 복구할 수 없을 수도 있다). 계속 진행하기전에 삭제된 패키지의 목록이 확인한 것과 일치하는지 확실히 해 두어라. 추가적으로 삭제할 패키지들은 같은 명령줄에 나열하면 되며, 패키지 이름은 표준 파일시스템 glob으로 지정할 수 있지만 삭제할 목록을 확인하는 문제를 훨씬 힘들게 만든다.

yum upgrade

Upgrading is the same as updating (and takes similar arguments) except that, as noted above, it also resolves and manages RPM package obsoletes, which remove core packages upon which many things depend and replace them (and as many of the dangling dependencies as possible) with a new, consistent branch in the dependency tree. This is not a completely safe thing to do in many cases because the overall replacement process can be very wide-reaching and have side effects that are difficult to fully explore in a testing process.

Note that under ordinary circumstances one should almost never encounter obsoletes unless you are actually upgrading from one distribution revision to another or are mixing packages from two different distributions revisions into your repository. For a variety of reasons, the latter is a really bad idea unless you love administrative pain. For a variety of reasons, it is often done anyway, and one of the things that tempts the use of

rpm --force

and consequently "breaks" the RPM database so that it becomes nearly impossible to safely resolve dependencies in the future. Yum upgrade at least gives you your best chance not to egregiously break something in this process without fair warning.

Even the legitimate purpose of doing a full revision upgrade is fraught with peril. For example, in revision upgrades the entire format of key configuration files in /etc might well change, and all tools and functions that depend on them might also need to change all the way down at the API or ABI level. It is again difficult to know that the RPMs for the entire upgraded tree are sufficiently carefully built that they can manage to both remove the old configuration files and preserve their contents and port the contents into the newly supported format, if possible. It is not at all unlikely that configuration data may be lost across an upgrade and that a system will therefore require a certain judicious amount of reconfiguration afterwards to regain full functionality.

For a specific example of this, consider the gradual replacement of the old Unix

lpr

printing system with the newer

CUPS

(Common Unix Printing System). Every aspect of printing configuration changes between the two, and it is nearly impossible to upgrade from one to the other without totally redoing the way printing is managed.

Because of these issues and yum's desire to function and do no harm in the process, it is likely the the

yum upgrade

function will be deprecated in the not horribly distant future. For that reason it is listed last in this HOWTO. In the meantime, it can certainly be a useful command and yum often does extraordinarily well at doing an upgrade, for all the dire warnings above. The author (rgb) of this HOWTO has used yum to upgrade Red Hat based systems on several occasions with complete satisfaction. He no longer does this - better practice is to develop e.g. a kickstart description of the systems in question that permits a full (re)install at any time into a perfectly functional state. This kickstart file is a much safer basis for upgrading the system to new distributions as they are released, as a full install eliminates the obsolescence process altogether, or at least forces one to confront precisely the relevant configuration issues as the emerge.

Yum의 그룹 설치/삭제 명령어

  # yum group[install,update] 그룹1 [그룹2 그룹3...]

최근 Yum에는 다소 유사한 인자를 가진, (아래에 나오는 리스트 기능은 물론) 시스템에 정의된 "패키지 그룹"의 단위로 설치 및 업데이트 기능을 수행하는 능력이 추가되었다. 이는 패키지 그룹들이 정의된 시스템에서, 하나의 전체 소프트웨어 블록을 단번에 비교적 설치하기 쉽게 해준다.

This can be very useful if one is using yum as a full scale system installation tool in its own right. For example, it is possible to put X onto a server originally installed without it by means of:

  # yum groupinstall "X Window System" "X Software Development"

The

groupupdate

function is likely to be only infrequently required, as of course a

yum update

will update all packages on the system whether or not they were originally installed as a part of a group. One could imagine, perhaps, a circumstance where one wishes to update a particular group to current but not update the rest of your software installation to current, but I (rgb) have never encountered one.

[edit]

11.2 정보를 제공하는 Yum 명령어 ¶

Yum으로 설치 가능하거나 이미 설치된 패키지의 목록 만들기

Yum으로 패키지에서 정보 얻어오기

Yum으로 패키지속의 내용 보여주기

Yum으로 설치되었거나 그렇지 않은 패키지속의 파일 검색하기

[edit]

12 Yum 저장소를 위한 RPMs 빌드하기 ¶

[edit]

13 보안 ¶

[edit]

14 기타 ¶

[edit]

15 더 많은 정보 ¶