23.1. 软件管理员简介
在前一章我们提到以原始码的方式来安装软件，也就是利用厂商释出的 Tarball 来进行软件的安装。不过，你应该很容易发现，那就是每次安装软件都需要侦测操作系统与环境、设定编译参数、实际的编译、 最后还要依据个人喜好的方式来安装软件到定位。这过程是真的很麻烦的，而且对于不熟整个系统的朋友来说，还真是累人啊！
那有没有想过，如果我的 Linux 系统与厂商的系统一模一样，那么在厂商的系统上面编译出来的执行档， 自然也就可以在我的系统上面跑！也就是说，厂商先在他们的系统上面编译好了我们用户所需要的软件， 然后将这个编译好的可执行的软件直接释出给用户来安装，如此一来，由于我们本来就使用厂商的 Linux distribution ，所以当然系统 (硬件与操作系统) 是一样的，那么使用厂商提供的编译过的可执行文件就没有问题！ 说的比较白话一些，那就是利用类似 Windows 的安装方式，由程序开发者直接在已知的系统上面编译好，再将该程序直接给用户来安装，如此而已。
那么如果在安装的时候还可以加上一些与这些程序相关的信息，将他建立成为数据库，那不就可以进行安装、反安装、 升级与验证等等的相关功能 (类似 Windows 底下的『新增移除程序』)？确实如此，在 Linux 上面至少就有两种常见的这方面的软件管理员，分别是 RPM 与 Debian 的 dpkg 。我们的 CentOS 主要是以 RPM 为主，但也不能不知道 dpkg ！所以底下就来约略介绍一下这两个玩意儿。
23.1.1. Linux 界的两大主流: RPM 与 DPKG
由于自由软件的蓬勃发展，加上大型 Unix-Like 主机的强大效能，让很多软件开发者将他们的软件使用 Tarball 来释出。 后来 Linux 发展起来后，由一些企业或社群将这些软件收集起来制作成为 distributions 以发布这好用的 Linux 操作系统。但后来发现到，这些 distribution 的软件管理实在伤脑筋， 如果软件有漏洞时，又该如何修补呢？使用 tarball 的方式来管理吗？又常常不晓得到底我们安装过了哪些程序？ 因此，一些社群与企业就开始思考 Linux 的软件管理方式。
如同刚刚谈过的方式，Linux 开发商先在固定的硬件平台与操作系统平台上面将需要安装或升级的软件编译好， 然后将这个软件的所有相关档案打包成为一个特殊格式的档案，在这个软件档案内还包含了预先侦测系统与相依软件的脚本， 并提供记载该软件提供的所有档案信息等。最终将这个软件档案释出。客户端取得这个档案后，只要透过特定的指令来安装， 那么该软件档案就会依照内部的脚本来侦测相依的前驱软件是否存在，若安装的环境符合需求，那就会开始安装， 安装完成后还会将该软件的信息写入软件管理机制中，以达成未来可以进行升级、移除等动作。
目前在 Linux 界软件安装方式最常见的有两种，分别是：
- dpkg：
这个机制最早是由 Debian Linux 社群所开发出来的，透过 dpkg 的机制， Debian 提供的软件就能够简单的安装起来，同时还能提供安装后的软件信息，实在非常不错。 只要是衍生于 Debian 的其他 Linux distributions 大多使用 dpkg 这个机制来管理软件的， 包括 B2D, Ubuntu 等等。 - RPM：
这个机制最早是由 Red Hat 这家公司开发出来的，后来实在很好用，因此很多 distributions 就使用这个机制来作为软件安装的管理方式。包很 Fedora, CentOS, SuSE 等等知名的开发商都是用这咚咚。
如前所述，不论 dpkg/rpm 这些机制或多或少都会有软件属性相依的问题，那该如何解决呢？ 其实前面不是谈到过每个软件档案都有提供相依属性的检查吗？那么如果我们将相依属性的数据做成列表， 等到实际软件安装时，若发生有相依属性的软件状况时，例如安装 A 需要先安装 B 与 C ，而安装 B 则需要安装 D 与 E 时，那么当你要安装 A ，透过相依属性列表，管理机制自动去取得 B, C, D, E 来同时安装， 不就解决了属性相依的问题吗？
没错！您真聪明！目前新的 Linux 开发商都有提供这样的『在线升级』机制，透过这个机制， 原版光盘就只有第一次安装时需要用到而已，其他时候只要有网络，你就能够取得原本开发商所提供的任何软件了呢！ 在 dpkg 管理机制上就开发出 APT 的在线升级机制，RPM 则依开发商的不同，有 Red Hat 系统的 yum ， SuSE 系统的 Yast Online Update (YOU)， Mandriva 的 urpmi 软件等。
我们这里使用的是 CentOS 系统嘛！所以说：使用的软件管理机制为 RPM 机制，而用来作为在线升级的方式则为 yum ！底下就让我们来谈谈 RPM 与 YUM 的相关说明吧！
23.1.2. 什么是 RPM 与 SRPM
RPM 全名是『 RedHat Package Manager 』简称则为 RPM ！顾名思义，当初这个软件管理的机制是由 Red Hat 这家公司发展出来的。 RPM 是以一种数据库记录的方式来将你所需要的软件安装到你的 Linux 系统的一套管理机制。
他最大的特点就是将你要安装的软件先编译过， 并且打包成为 RPM 机制的包装档案，透过包装好的软件里头默认的数据库记录， 记录这个软件要安装的时候必须具备的相依属性软件，当安装在你的 Linux 主机时， RPM 会先依照软件里头的数据查询 Linux 主机的相依属性软件是否满足， 若满足则予以安装，若不满足则不予安装。那么安装的时候就将该软件的信息整个写入 RPM 的数据库中，以便未来的查询、验证与反安装！这样一来的优点是：
- 由于已经编译完成并且打包完毕，所以软件传输与安装上很方便 (不需要再重新编译)；
- 由于软件的信息都已经记录在 Linux 主机的数据库上，很方便查询、升级与反安装 ；
但是这也造成些许的困扰。由于 RPM 档案是已经包装好的数据，也就是说， 里面的数据已经都『编译完成』了！所以，该软件档案几乎只能安装在原本默认的硬件与操作系统版本中。 也就是说，你的主机系统环境必须要与当初建立这个软件档案的主机环境相同才行！ 举例来说，rp-pppoe 这个 ADSL 拨接软件，他必须要在 ppp 这个软件存在的环境下才能进行安装！如果你的主机并没有 ppp 这个软件，那么很抱歉，除非你先安装 ppp 否则 rp-pppoe 就是不让你安装的 (当然你可以强制安装，但是通常都会有点问题发生就是了！)。
所以，通常不同的 distribution 所释出的 RPM 档案，并不能用在其他的 distributions 上。举例来说，Red Hat 释出的 RPM 档案，通常无法直接在 SuSE 上面进行安装的。更有甚者，相同 distribution 的不同版本之间也无法互通，例如 CentOS 4.x 的 RPM 档案就无法直接套用在 CentOS 5.x ！因此，这样可以发现这些软件管理机制的问题是：
- 软件档案安装的环境必须与打包时的环境需求一致或相当；
- 需要满足软件的相依属性需求；
- 反安装时需要特别小心，最底层的软件不可先移除，否则可能造成整个系统的问题！
那怎么办？如果我真的想要安装其他 distributions 提供的好用的 RPM 软件档案时？还好，还有 SRPM 这个东西！SRPM 是什么呢？顾名思义，他是 Source RPM 的意思，也就是这个 RPM 档案里面含有原始码 ！特别注意的是，这个 SRPM 所提供的软件内容『并没有经过编译』， 他提供的是原始码！
通常 SRPM 的扩展名是以 *.src.rpm 这种格式来命名的。不过，既然 SRPM 提供的是原始码，那么为什么我们不使用 Tarball 直接来安装就好了？这是因为 SRPM 虽然内容是原始码， 但是他们仍含有该软件所需要的相依性软件说明、以及所有 RPM 档案所提供的数据。同时，他与 RPM 不同的是，他也提供了参数配置文件 (就是 configure 与 makefile)。所以，如果我们下载的是 SRPM ，那么要安装该软件时，你就必须要：
- 先将该软件以 RPM 管理的方式编译，此时 SRPM 会被编译成为 RPM 档案；
- 然后将编译完成的 RPM 档案安装到 Linux 系统当中；
怎么 SRPM 这么麻烦！还要重新编译一次，那么我们直接使用 RPM 来安装不就好了？通常一个软件在释出的时候，都会同时释出该软件的 RPM 与 SRPM 。我们现在知道 RPM 档案必须要在相同的 Linux 环境下才能够安装，而 SRPM 既然是原始码的格式，自然我们就可以透过修改 SRPM 内的参数配置文件，然后重新编译产生能适合我们 Linux 环境的 RPM 档案，如此一来，不就可以将该软件安装到我们的系统当中，而不必与原作者打包的 Linux 环境相同了？这就是 SRPM 的用处了！
23.1.3. 什么是 i386, i586, i686, noarch, x86_64
从上面的说明，现在我们知道 RPM 与 SRPM 的格式分别为：
那么我们怎么知道这个软件的版本、适用的平台、编译释出的次数呢？只要透过档名就可以知道了！例如 rp-pppoe-3.1-5.i386.rpm 这的档案的意义为：
除了后面适合的硬件平台与扩展名外，主要是以『-』来隔开各个部分，这样子可以很清楚的发现该软件的名称、 版本信息、打包次数与操作的硬件平台！好了，来谈一谈每个不同的地方吧：
- 软件名称：
当然就是每一个软件的名称了！上面的范例就是 rp-pppoe 。 - 版本信息：
每一次更新版本就需要有一个版本的信息，否则如何知道这一版是新是旧？这里通常又分为主版本跟次版本。以上面为例，主版本为 3 ，在主版本的架构下更动部分原始码内容，而释出一个新的版本，就是次版本啦！以上面为例，就是 1 啰！ - 释出版本次数：
通常就是编译的次数！那么为何需要重复的编译呢？这是由不同一版的软件中，可能由于有某些 bug 或者是安全上的顾虑，所以必须要进行小幅度的 patch 或重设一些编译参数。 设定完成之后重新编译并打包成 RPM 档案！因此就有不同的打包数出现了！ - 操作硬件平台：
由于 RPM 可以适用在不同的操作平台上，但是不同的平台设定的参数还是有所差异性！ 并且，我们可以针对比较高阶的 CPU 来进行优化参数的设定，这样才能够使用高阶 CPU 所带来的硬件加速功能。 所以就有所谓的 i386, i586, i686, x86_64 与 noarch 等的文件名出现了！
- 受惠于目前 x86 系统的支持方面，新的 CPU 都能够执行旧型 CPU 所支持的软件，也就是说硬件方面都可以向下兼容的， 因此最低等级的 i386 软件可以安装在所有的 x86 硬件平台上面，不论是 32 位还是 64 位。但是反过来说就不行了。举例来说，目前硬件大多是 64 位的等级，因此你可以在该硬件上面安装 x86_64 或 i386 等级的 RPM 软件。但在你的旧型主机，例如 P-III/P-4 32 位机器上面，就不能够安装 x86_64 的软件！
根据上面的说明，其实我们只要选择 i386 版本来安装在你的 x86 硬件上面就肯定没问题。但是如果强调效能的话， 还是选择搭配你的硬件的 RPM 档案吧！毕竟该软件才有针对你的 CPU 硬件平台进行过参数优化的编译！
23.1.4. RPM 的优点
由于 RPM 是透过预先编译并打包成为 RPM 文件格式后，再加以安装的一种方式，并且还能够进行数据库的记载。 所以 RPM 有以下的优点：
- RPM 内含已经编译过的程序与配置文件等数据，可以让用户免除重新编译的困扰；
- RPM 在被安装之前，会先检查系统的硬盘容量、操作系统版本等，可避免档案被错误安装；
- RPM 档案本身提供软件版本信息、相依属性软件名称、软件用途说明、软件所含档案等信息，便于了解软件；
- RPM 管理的方式使用数据库记录 RPM 档案的相关参数，便于升级、移除、查询与验证。
为什么 RPM 在使用上很方便呢？我们前面提过， RPM 这个软件管理员所处理的软件，是由软件提供者在特定的 Linux 作业平台上面将该软件编译完成并且打包好。那使用者只要拿到这个打包好的软件， 然后将里头的档案放置到应该要摆放的目录，就完成安装了！
但是有没有想过，我们在前一章里面提过的，有些软件是有相关性的，例如要安装网卡驱动程序，就得要有 kernel source 与 gcc 及 make 等软件。那么我们的 RPM 软件是否一定可以安装完成呢？如果该软件安装之后，却找不到他相关的前驱软件， 那不是挺麻烦的吗？因为安装好的软件也无法使用啊！
为了解决这种具有相关性的软件之间的问题 (就是所谓的软件相依属性)，RPM 就在提供打包的软件时，同时加入一些讯息登录的功能，这些讯息包括软件的版本、 打包软件者、相依属性的其他软件、本软件的功能说明、本软件的所有档案记录等等，然后在 Linux 系统上面亦建立一个 RPM 软件数据库，如此一来，当你要安装某个以 RPM 型态提供的软件时，在安装的过程中， RPM 会去检验一下数据库里面是否已经存在相关的软件了， 如果数据库显示不存在，那么这个 RPM 档案『预设』就不能安装。没有错，这个就是 RPM 类型的档案最为人所诟病的『软件的属性相依』问题！
23.1.5. RPM 属性相依的克服方式： YUM 在线升级
为了重复利用既有的软件功能，因此很多软件都会以函式库的方式释出部分功能，以方便其他软件的呼叫应用， 例如 PAM 模块的验证功能。此外，为了节省用户的数据量，目前的 distributions 在释出软件时， 都会将软件的内容分为一般使用与开发使用 (development) 两大类。所以你才会常常看到有类似 pam-x.x.rpm 与 pam-devel-x.x.rpm 之类的档名啊！而预设情况下，大部分的 software-devel-x.x.rpm 都不会安装，因为终端用户大部分不会去开发软件！
因为有上述的现象，因此 RPM 软件档案就会有所谓的属性相依的问题产生 (其实所有的软件管理几乎都有这方面的情况存在)。 那有没有办法解决啊？前面不是谈到 RPM 软件档案内部会记录相依属性的数据吗？要是我将这些相依属性的软件先列表， 在有要安装软件需求的时候，先到这个列表去找，同时与系统内已安装的软件相比较，没安装到的相依软件就一口气同时安装起来， 那不就解决了相依属性的问题了吗？有没有这种机制啊？有啊！那就是 YUM 机制的由来！
CentOS 先将释出的软件放置到 YUM 服务器内，然后分析这些软件的相依属性问题，将软件内的记录信息写下来 (header)。 然后再将这些信息分析后记录成软件相关性的列表。这些列表数据与软件所在的位置可以称呼为容器 (repository)。 当客户端有软件安装的需求时，客户端主机会主动的向网络上面的 yum 服务器的容器网址下载清单列表， 然后透过列表的数据与本机 RPM 数据库已存在的软件数据相比较，就能够一口气安装所有需要的具有相依属性的软件了。 整个流程可以简单的如下图说明：
当客户端有升级、安装的需求时， yum 会向容器要求清单的更新，等到清单更新到本机的 /var/cache/yum 里面后， 等一下更新时就会用这个本机清单与本机的 RPM 数据库进行比较，这样就知道该下载什么软件。接下来 yum 会跑到容器服务器 (yum server) 下载所需要的软件，然后再透过 RPM 的机制开始安装软件！这就是整个流程！ 谈到最后，还是需要动到 RPM 的！所以下个小节就让我们来谈谈 RPM 这咚咚吧！
23.2. RPM 软件管理程序： rpm
RPM 的使用其实不难，只要使用 rpm 这个指令即可！我最喜欢的就是 rpm 指令的查询功能了，可以让我很轻易的就知道某个系统有没有安装我要的软件！此外， 我们最好还是得要知道一下，到底 RPM 类型的档案他们是将软件的相关档案放置在哪里呢？还有，我们说的那个 RPM 的数据库又是放置在哪里呢？
23.2.1. RPM 默认安装的路径
一般来说，RPM 类型的档案在安装的时候，会先去读取档案内记载的设定参数内容，然后将该数据用来比对 Linux 系统的环境，以找出是否有属性相依的软件尚未安装的问题。例如 Openssh 这个联机软件需要透过 Openssl 这个加密软件的帮忙，所以得先安装 openssl 才能装 openssh 的意思。那你的环境如果没有 openssl ， 你就无法安装 openssh 的意思。
若环境检查合格了，那么 RPM 档案就开始被安装到你的 Linux 系统上。安装完毕后，该软件相关的信息就会被写入 /var/lib/rpm/ 目录下的数据库档案中了。 上面这个目录内的数据很重要！因为未来如果我们有任何软件升级的需求，版本之间的比较就是来自于这个数据库， 而如果你想要查询系统已经安装的软件，也是从这里查询的！同时，目前的 RPM 也提供数字签名信息， 这些数字签名也是在这个目录内记录的！所以这个目录得要注意不要被删除了！
那么软件内的档案到底是放置到哪里去啊？当然与文件系统有关对吧！我们在第六章的目录配置谈过每个目录的意义， 这里再次的强调：
好了，底下我们就来针对每个 RPM 的相关指令来进行说明！
23.2.2. RPM 安装 (install)
因为安装软件是 root 的工作，因此你得要是 root 的身份才能够操作 rpm 这指令的。 用 rpm 来安装很简单！假设我要安装一个档名为 rp-pppoe-3.5-32.1.i386.rpm 的档案，那么我可以这样：
不过，这样的参数其实无法显示安装的进度，所以，通常我们会这样下达安装指令：
另外，如果我们在安装的过程当中发现问题，或者已经知道会发生的问题， 而还是『执意』要安装这个软件时，可以使用如下的参数『强制』安装上去：
一般来说，rpm 的安装选项与参数大约就是这些了。通常建议直接使用 -ivh 就好了， 如果安装的过程中发现问题，一个一个去将问题找出来，尽量不要使用『 暴力安装法 』，就是透过 –force 去强制安装！ 因为可能会发生很多不可预期的问题！除非你很清楚的知道使用上面的参数后，安装的结果是你预期的！
23.2.3. RPM 升级与更新 (upgrade/freshen)
使用 RPM 来升级真是太简单了！就以 -Uvh 或 -Fvh 来升级即可，而 -Uvh 与 -Fvh 可以用的选项与参数，跟 install 是一样的。不过， -U 与 -F 的意义还是不太一样的，基本的差别是这样的：
由上面的说明来看，如果你想要大量的升级系统旧版本的软件时，使用 -Fvh 则是比较好的作法，因为没有安装的软件才不会被不小心安装进系统中。但是需要注意的是，如果你使用的是 -Fvh ，偏偏你的机器上尚无这一个软件，那么很抱歉，该软件并不会被安装在你的 Linux 主机上面，所以请重新以 ivh 来安装吧！
通常有的朋友在进行整个操作系统的旧版软件修补时，喜欢这么进行：
- 先到各发展商的 errata 网站或者是国内的 FTP 映像站捉下来最新的 RPM 档案；
- 使用 -Fvh 来将你的系统内曾安装过的软件进行修补与升级！(真是方便呀！)
所以，在不晓得 yum 功能的情况下，你依旧可以到 CentOS 的映设站台下载 updates 数据，然后利用上述的方法来一口气升级！ 当然升级也是可以利用 –nodeps/–force 等等的参数！
23.2.4. RPM 查询 (query)
RPM 在查询的时候，其实查询的地方是在 /var/lib/rpm/ 这个目录下的数据库档案！另外， RPM 也可以查询未安装的 RPM 档案内的信息！那如何去查询呢？ 我们先来谈谈可用的选项有哪些？
在查询的部分，所有的参数之前都需要加上 -q 才是所谓的查询！查询主要分为两部分， 一个是查已安装到系统上面的的软件信息，这部份的信息都是由 /var/lib/rpm/ 所提供。另一个则是查某个 rpm 档案内容， 等于是由 RPM 档案内找出一些要写入数据库内的信息就是了，这部份就得要使用 -qp (p 是 package 的意思)。 那就来看看几个简单的范例吧！
常见的查询就是这些了！要特别说明的是，在查询本机上面的 RPM 软件相关信息时， 不需要加上版本的名称，只要加上软件名称即可！因为他会由 /var/lib/rpm 这个数据库里面去查询， 所以我们可以不需要加上版本名称。但是查询某个 RPM 档案就不同了，我们必须要列出整个档案的完整档名才行～ 这一点朋友们常常会搞错。底下我们就来做几个简单的练习吧！
23.2.5. RPM 验证与数字签名 (Verify/signature)
验证 (Verify) 的功能主要在于提供系统管理员一个有用的管理机制！作用的方式是『使用 /var/lib/rpm 底下的数据库内容来比对目前 Linux 系统的环境下的所有软件档案 』也就是说，当你有数据不小心遗失， 或者是因为你误杀了某个软件的档案，或者是不小心不知道修改到某一个软件的档案内容， 就用这个简单的方法来验证一下原本的文件系统吧！好让你了解这一阵子到底是修改到哪些档案数据了！验证的方式很简单：
那么我怎么知道到底我的档案被更动过的内容是什么？例如上面的范例二。简单的说明一下吧！ 例如，我们检查一下 logrotate 这个软件：
你会发现在档名之前有个 c ，然后就是一堆奇怪的文字了。那个 c 代表的是 configuration ， 就是配置文件的意思。至于最前面的八个信息是：
- S ：(file Size differs) 档案的容量大小是否被改变；
- M ：(Mode differs) 档案的类型或档案的属性 (rwx) 是否被改变？如是否可执行等参数已被改变 ；
- 5 ：(MD5 sum differs) MD5 这一种指纹码的内容已经不同；
- D ：(Device major/minor number mis-match) 装置的主/次代码已经改变；
- L ：(readLink(2) path mis-match) Link 路径已被改变；
- U ：(User ownership differs) 档案的所属人已被改变；
- G ：(Group ownership differs) 档案的所属群组已被改变；
- T ：(mTime differs) 档案的建立时间已被改变；
所以，如果当一个配置文件所有的信息都被更动过，那么他的显示就会是：
至于那个 c 代表的是『 Config file 』的意思，也就是档案的类型，文件类型有底下这几类：
- c ：配置文件 (config file)；
- d ：文件数据文件 (documentation) ；
- g ：鬼档案～通常是该档案不被某个软件所包含，较少发生！(ghost file)；
- l ：许可证文件 (license file)；
- r ：自述文件 (read me)；
经过验证的功能，你就可以知道那个档案被更动过。那么如果该档案的变更是『预期中的』， 那么就没有什么大问题，但是如果该档案是『非预期的』，那么是否被入侵了呢？得注意注意！ 一般来说，配置文件 (configure) 被更动过是很正常的，万一你的 binary program 被更动过呢？ 那就得要特别特别小心啊！
一、数字签名
谈完了软件的验证后，不知道你有没有发现一个问题，那就是，验证只能验证软件内的信息与 /var/lib/rpm/ 里面的数据库信息而已，如果该软件档案所提供的数据本身就有问题，那你使用验证的手段也无法确定该软件的正确性啊！ 那如何解决呢？在 Tarball 与档案的验证方面，我们可以使用前一章谈到的 md5 指纹码来检查， 不过，连指纹码也可能会被窜改的！那怎办？没关系，我们可以透过数字签名来检验软件的来源的！ 就像你自己的签名一样，我们的软件开发商原厂所推出的软件也会有一个厂商自己的签章系统！ 只是这个签章被数字化了而已。厂商可以数字签名系统产生一个与属于该软件的签章，并将该签章的公钥 (public key) 释出。 当你要安装一个 RPM 档案时：
- 首先你必须要先安装原厂释出的公钥档案；
- 实际安装原厂的 RPM 软件时， rpm 指令会去读取 RPM 档案的签章信息，与本机系统内的签章信息比对；
- 若签章相同则予以安装，若找不到相关的签章信息时，则给予警告并且停止安装。
我们 CentOS 使用的数字签名系统为 GNU 计划的 GnuPG (GNU Privacy Guard, GPG)(注1)。 GPG 可以透过哈希运算，算出独一无二的专属密钥系统或者是数字签名系统，有兴趣的朋友可以参考文末的延伸阅读， 去了解一下 GPG 加密的机制！这里我们仅简单的说明数字签名在 RPM 档案上的应用而已。 而根据上面的说明，我们也会知道首先必须要安装原厂释出的 GPG 数字签名的公钥档案啊！CentOS 的数字签名位于：
从上面的输出，你会知道该数字签名码其实仅是一个随机数而已，这个随机数对于数字签名有意义而已， 我们看不懂！那么这个档案如何安装呢？透过底下的方式来安装即可！
由于不同版本 GPG 密钥档案放置的位置可能不同，不过档名大多是以 GPG-KEY 来说明的， 因此你可以简单的使用 locate 或 find 来找寻，如以下的方式来搜寻即可：
那安装完成之后，这个密钥的内容会以什么方式呈现呢？基本上都是使用 pubkey 作为软件的名称的！ 那我们先列出密钥软件名称后，再以 -qi 的方式来查询看看该软件的信息为何：
重点就是最后面出现的那一串乱码！那可是作为数字签名非常重要的一环！ 如果你忘记加上数字签名，很可能很多原版软件就不能让你安装了～除非你利用 rpm 时选择略过数字签名的选项。
23.2.6. RPM 反安装与重建数据库 (erase/rebuilddb)
反安装就是将软件卸载！要注意的是，『解安装的过程一定要由最上层往下解除』，以 rp-pppoe 为例，这一个软件主要是依据 ppp 这个软件来安装的，所以当你要解除 ppp 的时候，就必须要先解除 rp-pppoe 才行！否则就会发生结构上的问题！这个可以由建筑物来说明， 如果你要拆除五、六楼，那么当然要由六楼拆起，否则先拆的是第五楼时，那么上面的楼层难道会悬空？ 移除的选项很简单，就透过 -e 即可移除。不过，很常发生软件属性相依导致无法移除某些软件的问题！ 我们以底下的例子来说明：
从范例一我们知道 pam 所提供的函式库是让非常多其他软件使用的，因此你不能移除 pam ，除非将其他相依软件一口气也全部移除！你当然也能加 –nodeps 来强制移除， 不过，如此一来所有会用到 pam 函式库的软件，都将成为无法运作的程序，我想，你的主机也只好准备停机休假了吧！ 至于范例二中，由于 pam-devel 是依附于 pam 的开发工具，你可以单独安装与单独移除！
由于 RPM 档案常常会安装/移除/升级等，某些动作或许可能会导致 RPM 数据库 /var/lib/rpm/ 内的档案破损。果真如此的话，那你该如何是好？别担心，我们可以使用 –rebuilddb 这个选项来重建一下数据库！ 作法如下：
23.3. SRPM 的使用： rpmbuild
谈完了 RPM 类型的软件之后，再来我们谈一谈包含了 Source code 的 SRPM 该如何使用呢？假如今天我们由网络上面下载了一个 SRPM 的档案，该如何安装他？又，如果我想要修改这个 SRPM 里面原始码的相关设定值，又该如何订正与重新编译呢？ 此外，最需要注意的是，新版的 rpm 已经将 RPM 与 SRPM 的指令分开了，SRPM 使用的是 rpmbuild 这个指令，而不是 rpm ！如果你是 Red Hat 7.3 以前的用户，那么请使用 rpm 来替代 rpmbuild ！
23.3.1. 利用默认值安装 SRPM 档案 (–rebuid/–recompile)
假设我下载了一个 SRPM 的档案，又不想要修订这个档案内的原始码与相关的设定值， 那与我可以直接编译并安装吗？当然可以！利用 rpmbuild 配合选项即可。选项主要有底下两个：
不过，要注意的是，这两个选项都没有修改过 SRPM 内的设定值，仅是透过再次编译来产生 RPM 可安装软件档案而已。 一般来说，如果编译的动作顺利的话，那么编译过程所产生的中间暂存盘都会被自动删除，如果发生任何错误， 则该中间档案会被保留在系统上，等待用户的除错动作！那么，该如何除错呢？如果想要自行除错， 或者是想要修改 SRPM 内的设定值时，就得要知道利用 SRPM 的时候，系统会动用到哪些重要的目录了！ 底下我们就来谈一谈当处理 SRPM 时，系统会使用到的目录。
23.3.2. SRPM 使用的路径与需要的软件
SRPM 既然含有 source code ，那么其中必定有配置文件，所以首先我们必需要知道，这个 SRPM 在进行编译的时候会使用到哪些目录呢？这样一来才能够来修改！你可以到你的 /usr/src 这个目录里面去查看一下，通常每个 distribution 提供的目录都不太相同，以 CentOS 5.x 为例，他是以 /usr/src/redhat/ 为工作目录， Openlinux 则是以 /usr/src/openlinux 为工作目录！无论如何，反正就是在 /usr/src 这个目录下就对了！好了，既然我们是 CentOS ， 请到 /usr/src/redhat 里头去看一看：
此外，在编译的过程当中，可能会发生不明的错误，或者是设定的错误，这个时候就会在 /tmp 底下产生一个相对应的错误档，你可以根据该错误档进行除错的工作！ 等到所有的问题都解决之后，也编译成功了，那么刚刚解压缩之后的档案，就是在 /usr/src/redhat/SPECS, SOURCES, BUILD 等等的档案都会被杀掉，而只剩下放置在 /usr/src/redhat/RPMS 底下的档案了！
由于 SRPM 需要重新编译，而编译的过程当中，我们至少需要有 make 与其相关的程序，及 gcc, c, c++ 等其他的编译用的程序语言来进行编译，更多说明请参考第二十二章原始码所需基础软件。 所以如果你在安装的过程当中没有选取软件开发工具之类的软件，得重新拿出你的光盘，然后再安装！只是得要克服一大堆的属性相依的问题就是了～ 这问题待会儿可以使用 yum 来处理，你当然也可以先使用『 yum groupinstall “Development Tools” 』来安装开发软件。 这里假设你已经安装了该软件群组。
23.3.3. 配置文件的主要内容 (*.spec)
除了使用 SRPM 内预设的参数来进行编译之外，我们还可以修改这些参数后再重新编译！那该如何处理呢？ 首先我们必须要将 SRPM 内的档案安置到 /usr/src/redhat/ 内的相关目录，然后再去修改配置文件即可！ 我们就拿刚刚上头那个 rp-pppoe 来说明好了，假设我们已经将该档案放置到 /root 中，然后：
好了，来看看我们的设定参数档，亦即是在 /usr/src/redhat/SPECS 内的 *.spec 档案！
要注意到的是 rp-pppoe.sepc 这个档案，这是主要的将 SRPM 编译成 RPM 的配置文件，他的基本规则可以这样看：
- 整个档案的开头以Summary为开始，这部份的设定都是最基础的说明内容；
- 然后每个不同的段落之间，都以%来做为开头，例如%prep与%install等；
我们来谈一谈几个常见的 SRPM 设定段落：
一、系统整体信息方面：
刚刚你看到的就有底下这些重要的咚咚：
上面几个资料通常都必需要写！但是如果你的软件没有相依属性的关系时，那么就可以不需要那个 Requires ！ 根据上面的设定，最终的档名就会是『{Name}-{Version}-{Release}.{ExclusiveArch}.rpm』的样式， 以我们上面的设定来说，档名应该会是『rp-pppoe-3.5-32.2.vbird.i686.rpm』的样子！
二、%description：
将你的软件做一个简短的说明！这个也是必需要的。还记得使用『 rpm -qi 软件名称 』会出现一些基础的说明吗？ 上面这些东西包括 Description 就是在显示这些重要信息的！所以，这里记得要详加解释！
三、%prep：
pre 这个关键词原本就有『在…之前』的意思，因此这个项目在这里指的就是『尚未进行设定或安装之前，你要编译完成的 RPM 帮你事先做的事情』，就是 prepare 的简写！那么他的工作事项主要有：
- 进行软件的补丁 (patch) 等相关工作；
- 寻找软件所需要的目录是否已经存在？确认用的！
- 事先建立你的软件所需要的目录，或者事先需要进行的任务；
- 如果待安装的Linux系统内已经有安装的时候可能会被覆盖掉的档案时，那么就必需要进行备份(backup)的工作了！
在本案例中，你会发现程序会使用 patch 去进行补丁的动作！
四、%setup：
这个项目就是在进行类似解压缩之类的工作！这个项目一定要写！不然你的 tarball 原始码是无法被解压缩的！
五、%build：
build 就是建立！所以当然这个段落就是在谈怎么 make 编译成为可执行的程序！ 你会发现在此部分的程序代码方面，就是 ./configure, make 等项目！
六、%install：
编译完成 (build) 之后，就是要安装！安装就是写在这里，也就是类似 Tarball 里面的 make install 的意思！
七、%clean：
编译与安装完毕后，必须要将一些暂存在 BuildRoot 内的数据删除才好， 因此这个时候这个 clean 的项目就重要了！这有点像是 make clean 的感觉～保持系统的干爽嘛！
八、%files：
这个软件安装的档案都需要写到这里来，当然包括了『目录』喔！所以连同目录请一起写到这个段落当中！以备查验呢！此外，你也可以指定每个档案的类型，包括文件档 (%doc 后面接的) 与配置文件 (%config 后面接的) 等等。
九、%changelog：
这个项目主要则是在记录这个软件曾经的更新记录！星号 (*) 后面应该要以时间，修改者， email 与软件版本来作为说明， 减号 (-) 后面则是你要作的详细说明！在这部份我就新增了两行，内容如下：
修改到这里也差不多了，您也应该要了解到这个 rp-pppoe.spec 有多么重要！我们用 rpm -q 去查询一堆信息时， 其实都是在这里写入的！这样了解否？接下来，就让我们来了解一下如何将 SRPM 给他编译出 RPM 来吧！
23.3.4. SRPM 的编译指令 (-ba/-bb)
要将在 /usr/src/redhat 底下的数据编译或者是单纯的打包成为 RPM 或 SRPM 时，就需要 rpmbuild 指令与相关选项的帮忙了！我们只介绍两个常用的选项给您了解一下：
这个时候系统就会这样做：
- 先进入到 BUILD 这个目录中，亦即是： /usr/src/redhat/BUILD 这个目录；
- 依照 *.spec 档案内的 Name 与 Version 定义出工作的目录名称，以我们上面的例子为例，那么系统就会在 BUILD 目录中先删除 rp-pppoe-3.5 的目录，再重新建立一个 rp-pppoe-3.5 的目录，并进入该目录；
- 在新建的目录里面，针对 SOURCES 目录下的来源档案，也就是 *.spec 里面的 Source 设定的那个档案，以 tar 进行解压缩，以我们这个例子来说，则会在 /usr/src/redhat/BUILD/rp-pppoe-3.5 当中，将 /usr/src/redhat/SOURCES/rp-pppoe-3.5.tar.gz 进行解压缩！
- 再来开始 %build 及 %install 的设定与编译！
- 最后将完成打包的档案给他放置到该放置的地方去，如果你的规定的硬件是在 i386 的系统，那么最后编译成功的 *.i386.rpm档案就会被放置在 /usr/src/redhat/RPMS/i386 里面！如果是 i686 那么自然就是 /usr/src/redhat/RPMS/i686 目录下！
整个步骤大概就是这样子！最后的结果数据会放置在 RPMS 那个目录底下就对了！我们这个案例中想要同时打包 RPM 与 SRPM ， 因此请您自行处理一下『 rpmbuild -ba rp-pppoe.spec 』吧！
老实说，应该会出现 i686 的档名才对！不过，可能是原始码本身没有支持 i686 之类的语法吧！ 所以仅出现 i386 的档名而已。另外，你可以看到档名确实是如同我们之前谈到的！ 那你可以自行制作出有你特殊名称的档名 (例如上面的 vbird )。
23.3.5. 一个打包自己软件的范例
我们自己来编辑一下自己制作的 RPM 怎么样？ 我们这里就举个例子来玩玩吧！还记得我们在前一章谈到 Tarball 与 make 时，曾经谈到的 main 这个程序吗？现在我们将这个程序加上 Makefile 后， 将他制作成为 main-0.1.i386.rpm 好吗？那该如何进行呢？底下就让我们来处理处理吧！
一、制作原始码档案 tarball 产生：
请将前一章你曾经处理过的 main.tgz 再次的捉下来一次，我们将这个档案放置到 /root 底下， 并且在 /usr/local/src 底下建立一个名为 main-0.1 的目录来解压缩！
这个时候在 /usr/src/redhat 底下的原始码就建立成功了！接下来就是 spec 档案的建立！
二、建立 *.spec 的配置文件
这个档案的建置是所有 RPM 制作里面最重要的课题！你必须要仔细的设定他，不要随便处理！仔细看看吧！
三、编译成为 RPM 与 SRPM
老实说，那个 spec 档案建置妥当后，后续的动作就简单的要命了！开始来编译吧！
很快的，我们就已经建立了几个 RPM 档案！接下来让我们好好测试一下打包起来的成果吧！
四、安装/测试/实际查询
用很简单的方式，就可以将自己的软件或者程序给他修改与设定妥当！以后你就可以自行设定你的 RPM ！当然，也可以手动修改你的 SRPM 的来源档内容！
23.4. YUM 在线升级机制
我们在本章一开始的地方谈到过 yum 这玩意儿，这个 yum 是透过分析 RPM 的标头资料后， 根据各软件的相关性制作出属性相依时的解决方案，然后可以自动处理软件的相依属性问题，以解决软件安装或移除与升级的问题。 详细的 yum 服务器与客户端之间的沟通，可以再回到前面的部分查阅一下图 1.5.1 的说明。
由于 distribution 必须要先释出软件，然后将软件放置于 yum 服务器上面，以提供客户端来要求安装与升级之用的。 因此我们想要使用 yum 的功能时，必须要先找到适合的 yum server 才行啊！而每个 yum server 可能都会提供许多不同的软件功能，那就是我们之前谈到的『容器』了！因此，你必须要前往 yum server 查询到相关的容器网址后，再继续处理后续的设定事宜。
事实上 CentOS 在释出软件时已经制作出多部映像站台 (mirror site) 提供全世界的软件更新之用。 所以，理论上我们不需要处理任何设定值，只要能够连上 Internet ，就可以使用 yum ！底下就让我们来玩玩看吧！
23.4.1. 利用 yum 进行查询、安装、升级与移除功能
yum 的使用真是非常简单，就是透过 yum 这个指令！那么这个指令怎么用呢？就让我们来简单的谈谈：
一、查询功能：yum [list|info|search|provides|whatprovides] 参数
如果想要查询利用 yum 来查询原版 distribution 所提供的软件，或已知某软件的名称，想知道该软件的功能， 可以利用 yum 相关的参数为：
透过上面的查询，你应该大致知道 yum 如何用在查询上面了吧？那么实际来应用一下：
二、安装/升级功能：yum [install|update] 软件
既然可以查询，那么安装与升级呢？就利用 install 与 update 这两项工作来处理即可！
你不必知道软件在哪里，你不必手动下载软件，你也不必拿出原版光盘出来 mount 之后查询再安装！全部不需要，只要有了 yum 这个家伙，你的安装、升级再也不是什么难事！ 而且还能主动的进行软件的属性相依处理流程，如上所示，一口气帮我们处理好了所有事情！
三、移除功能：yum [remove] 软件
那能不能用 yum 移除软件呢？将刚刚的软件移除看看，会出现啥状况啊？
连移除也这么简单！看来，似乎不需要 rpm 这个指令也能够快乐的安装所有的软件了！ 虽然是如此，但是 yum 毕竟是架构在 rpm 上面所发展起来的，所以，我认为你还是得需要了解 rpm 才行！不要学了 yum 之后就将 rpm 的功能忘记了呢！
23.4.2. yum 的配置文件
虽然 yum 是你的主机能够联机上 Internet 就可以直接使用的，不过，由于 CentOS 的映射站台可能会选错， 举例来说，我们在北京，但是 CentOS 的映射站台却选择到了日本去，要知道我们联机到日本的速度是非常慢的！那怎办？ 当然就是手动的修改一下 yum 的配置文件就好！
最重要的特色就是那个『 repodata 』的目录！该目录就是分析 RPM 软件后所产生的软件属性相依数据放置处！因此，当你要找容器所在网址时， 最重要的就是该网址底下一定要有个名为 repodata 的目录存在！那就是容器的网址了！ 其他的容器正确网址，就请各位看管自行寻找一下！现在让我们修改配置文件吧 ！
如上所示，仅列出 base 这个容器内容而已，其他的容器内容请自行查阅！上面的数据需要注意的是：
- [base]：代表容器的名字！中括号一定要存在，里面的名称则可以随意取。但是不能有两个相同的容器名称， 否则 yum 会不晓得该到哪里去找容器相关软件列表档案。
- name：只是说明一下这个容器的意义而已，重要性不高！
- mirrorlist=：列出这个容器可以使用的映射站台，如果不想使用，可以批注到这行；
- baseurl=：这个最重要，因为后面接的就是容器的实际网址！ mirrorlist 是由 yum 程序自行去捉映像站台， baseurl 则是指定固定的一个容器网址！我们刚刚找到的网址放到这里来！
- enable=1：就是让这个容器被启动。如果不想启动可以使用 enable=0 ！
- gpgcheck=1：还记得 RPM 的数字签名吗？这就是指定是否需要查阅 RPM 档案内的数字签名！
- gpgkey=：就是数字签名的公钥文件所在位置！使用默认值即可。
了解这个配置文件之后，接下来让我们修改整个档案的内容，让我们这部主机可以直接使用高速网络中心的资源吧！ 修改的方式我仅列出 base 这个容器项目而已，其他的项目请您自行依照上述的作法来处理即可！
接下来当然就是给他测试一下！如何测试呢？再次使用 yum 即可！
修改容器产生的问题与解决之道 ：由于我们是修改系统默认的配置文件，事实上，我们应该要在 /etc/yum.repos.d/ 底下新建一个档案， 该扩展名必须是 .repo 才行！但因为我们使用的是指定特定的映射站台，而不是其他软件开发生提供的容器， 因此才修改系统默认配置文件。但是可能由于使用的容器版本有新旧之分，你得要知道， yum 会先下载容器的清单到本机的 /var/cache/yum 里面去！那我们修改了网址却没有修改容器名称 (中括号内的文字)， 可能就会造成本机的列表与 yum 服务器的列表不同步，此时就会出现无法更新的问题了！
那怎么办啊？清除掉本机上面的旧数据即可！需要手动处理吗？不需要的， 透过 yum 的 clean 项目来处理即可！
23.4.3. yum 的软件群组功能
透过 yum 来在线安装一个软件是非常的简单，但是，如果要安装的是一个大型项目呢？ 举例来说，我使用预设安装的方式安装了测试机，这部主机就只有 GNOME 这个窗口管理员， 那我如果想要安装 KDE 呢？难道需要重新安装？当然不需要，透过 yum的软件群组功能即可！ 来看看指令先：
你会发现系统上面的软件大多是群组的方式一口气来提供安装的！还记全新安装 CentOS 时， 不是可以选择所需要的软件吗？而那些软件不是利用 GNOME/KDE/X Window … 之类的名称存在吗？ 其实那就是软件群组！如果你执行上述的指令后，在『Available Groups』底下应该会看到一个 『XFCE-4.4』的软件群组，想知道那是啥吗？就这样做：
你会发现那就是一个桌面环境 (desktop environment) ，也就是一个窗口管理员！ 至于底下就列出主要的与选择性 (optional) 的软件名称！让我们直接安装看看：
你会发现系统进行了一大堆软件的安装！整个安装 XFCE 这个窗口接口所需的所有软件！ 这个咚咚真是非常的方便！这个功能请一定要记下来，对你未来安装软件是非常有帮助的！
23.4.4. 全系统自动升级
我们可以手动选择是否需要升级，那能不能让系统自动升级，让我们的系统随时保持在最新的状态呢？ 当然可以啊！透过『 yum -y update 』来自动升级，那个 -y 很重要，因为可以自动回答 yes 来开始下载与安装！ 然后再透过 crontab 的功能来处理即可！假设我每天在台湾时间 3:00am 网络带宽比较轻松的时候进行升级， 你可以这样做的：
从此你的系统就会自动升级了！很棒吧！此外，你还是得要分析登录档与收集 root 的信件的， 因为如果升级的是核心软件 (kernel)，那么你还是得要重新启动才会让安装的软件顺利运作的！ 所以还是得分析登录档，若有新核心安装，就重新启动，否则就让系统自动维持在最新较安全的环境吧！ 真是轻松愉快的管理啊！
23.5. 管理的抉择：RPM 还是 Tarball
这一直是个有趣的问题：『如果我要升级的话，或者是全新安装一个新的软件， 那么该选择 RPM 还是 Tarball 来安装呢？』，事实上考虑的因素很多，不过通常是这样建议的：
- 优先选择原厂的 RPM 功能：
由于原厂释出的软件通常具有一段时间的维护期，举例来说， RHEL 与 CentOS 每一个版本至少提供五年以上的更新期限。这对于我们的系统安全性来说，实在是非常好的选项！ 何解？既然 yum 可以自动升级，加上原厂会持续维护软件更新，那么我们的系统就能够自己保持在软件最新的状态， 对于资安来说当然会比较好一些的！ 此外，由于 RPM 与 yum 具有容易安装/移除/升级等特点，且还提供查询与验证的功能，安装时更有数字签名的保护， 让你的软件管理变的更轻松自在！因此，当然首选就是利用 RPM 来处理！ - 选择软件官网释出的 RPM 或者是提供的容器网址：
不过，原厂并不会包山包海，因此某些特殊软件你的原版厂商并不会提供的！举例来说 CentOS 就没有提供 NTFS 的相关模块。此时你可以自行到官网去查阅，看看有没有提供相对到你的系统的 RPM 档案， 如果有提供容器网址，那就更好！可以修改 yum 配置文件来加入该容器，就能够自动安装与升级该软件！ 你说方不方便啊！ - 利用 Tarball 安装特殊软件：
某些特殊用途的软件并不会特别帮你制作 RPM 档案的，此时建议你也不要妄想自行制作 SRPM 来转成 RPM 啦！ 因为你只有区区一部主机而已，若是你要管理相同的 100 部主机，那么将原始码转制作成 RPM 就有价值！ 单机版的特殊软件，例如学术网络常会用到的 MPICH/PVM 等平行运算函式库，这种软件建议使用 tarball 来安装即可， 不需要特别去搜寻 RPM 啰！ - 用 Tarball 测试新版软件：
某些时刻你可能需要使用到新版的某个软件，但是原版厂商仅提供旧版软件，举例来说，我们的 CentOS 主要是定位于企业版，因此很多软件的要求是『稳』而不是『新』，但你就是需要新软件啊！ 然后又担心新软件装好后产生问题，回不到旧软件，那就惨了！此时你可以用 tarball 安装新软件到 /usr/local 底下， 那么该软件就能够同时安装两个版本在系统上面了！而且大多数软件安装数种版本时还不会互相干扰的！ 用来作为测试新软件是很不错的！只是你就得要知道你使用的指令是新版软件还是旧版软件了！
所以说，RPM 与 Tarball 各有其优缺点，不过，如果有 RPM 的话，那么优先权还是在于 RPM 安装上面，毕竟管理上比较便利，但是如果软件的架构差异性太大， 或者是无法解决相依属性的问题，那么与其花大把的时间与精力在解决属性相依的问题上，还不如直接以 tarball 来安装，轻松又惬意！