第二十章、 RPM 与 SRPM 套件管理员 - for Fedora Core 4

RPM 全名是『 RedHat Package Manager 』简称则为 RPM 啦！顾名思义，当初这个套件管理的程序是由 Red Hat 这家公司发展出来的， 但其实在很多的其他套件也有相类似的套件管理程序。不过由于 RPM 使用上很方便，所以就成了目前最热门的套件管理程序啦！

那么什么是 RPM 呢？说的简单一点， RPM 是以一种数据库记录的方式来将你所需要的套件安装到你的 Linux 主机的一套管理程序。他最大的特点就是将您要安装的套件先编译过( 如果需要的话 )并且打包好了，通过包装好的套件里头缺省的数据库记录， 记录这个套件要安装的时候必须要的相依属性模块( 就是你的 Linux 主机需要先存在的几个必须的套件 )，当安装在你的 Linux 主机时， RPM 会先依照套件里头的纪录数据查找 Linux 主机的相依属性套件是否满足， 若满足则予以安装，若不满足则不予安装。那么安装的时候就将该套件的信息整个写入 RPM 的数据库中，以便未来的查找、验证与反安装！这样一来的优点是：

1. 由于已经编译完成并且打包完毕，所以安装上很方便( 不需要再重新编译 )；
2. 由于套件的信息都已经记录在 Linux 主机的数据库上，很方便查找、升级与反安装；

但是这也造成很大的困扰，由于 RPM 程序是已经包装好的数据，也就是说， 里面的数据已经都『编译完成』了！所以， 安装的时候一定需要当初安装时的主机环境才能安装 ，也就是说，当初创建这个套件的安装环境必须也要在你的主机上面出现才行！例如 rp-pppoe 这个 ADSL 拨接套件，他必须要在 ppp 这个套件存在的环境下才能进行安装！如果你的主机并没有 ppp 这个套件，那么很抱歉，除非您先安装 ppp 否则 rp-pppoe 就是不让你安装的( 当然您可以强制安装，但是通常都会有点问题发生就是了！ )。

所以，通常不同的 distribution 所发布的 RPM 文件，并不能用在其他的 distributions 里面，举例来说， Fedora 发布的 RPM 文件，通常无法直接在 Mandriva 上面进行安装的，更有甚者， 不同版本之间也无法互通，例如 Fedora Core 4 的 RPM 文件就无法直接套用在 FC3 上面！因此，这样可以发现他的缺点是：

1. 安装的环境必须与打包时的环境需求一致或相当；
2. 需要满足套件的相依属性需求；
3. 反安装时需要特别小心，最底层的套件不可先移除，否则可能造成整个系统的问题！

那怎么办？呵呵！还好，还有 SRPM 这个东西！ SRPM 是什么呢？顾名思义，他是 Source RPM 的意思，也就是这个 RPM 文件里面含有原代码( Source Code )哩！特别注意的是，这个 SRPM 所提供的套件内容『并没有经过编译』， 他提供的是原代码喔！

通常 SRPM 的扩展名是以 ***.src.rpm 这种格式来命名的 。不过，既然 SRPM 提供的是原代码，那么为什么我们不使用 Tarball 直接来安装就好了？！这是因为 SRPM 虽然内容是原代码， 但是他仍然含有该套件所需要的相依性套件说明、以及所有 RPM 文件所提供的数据，同时，他与 RPM 不同的是，他也提供了参数设置档( 就是 configure 与 makefile 啦！ )。所以，如果我们下载的是 SRPM ，那么要安装该套件时，RPM 套件管理员将会(1)先将该套件以 RPM 管理的方式编译，(2)然后将编译完成的 RPM 文件安装到 Linux 系统当中。与 RPM 文件相比， SRPM 多了一个重新编译的动作， 而且 SRPM 编译完成会产生 RPM 文件。

怪了，怎么 SRPM 这么麻烦呐！还要重新编译一次，那么我们直接使用 RPM 来安装不就好了！？通常一个套件在发布的时候，都会同时发布该套件的 RPM 与 SRPM 。我们现在知道 RPM 文件必须要在相同的 Linux 环境下才能够安装，而 SRPM 既然是原代码的格式，自然我们就可以通过修改 SRPM 内的参数设置档，然后重新编译产生能适合我们 Linux 环境的 RPM 文件，如此一来，不就可以将该套件安装到我们的系统当中，而不必与原作者打包的 Linux 环境相同了？这就是 SRPM 的用处了！

好啦！现在我们已经知道 RPM 与 SRPM 的格式了，分别为：

xxxxxxxxx.rpm   <==RPM 的格式，已经经过编译且包装完成的 rpm 文件；
xxxxx.src.rpm   <==SRPM的格式，包含未编译的原代码信息。

那么我们怎么知道这个套件的版本、适用的平台、打包的次数呢？呵呵！只要通过文件名就可以知道了！例如 rp-pppoe-3.1-5.i386.rpm 这的文件的意义为：

rp-pppoe -        3.1    -     5        .i386        .rpm
套件名称   套件的版本信息 发布的次数 适合的硬件平台 扩展名

除了后面适合的硬件平台与扩展名外，主要是以『-』来隔开各个部分， 这样子可以很清楚的发现该套件的名称、版本信息、打包次数与操作的硬件平台！ 好了，来谈一谈每个不同的地方吧：

• 套件名称：
  当然就是每一个套件的名称了！上面的范例就是 rp-pppoe 。


• 版本信息：
  每一次更新版本就需要有一个版本的信息，否则如何知道这一版是新是旧？ 这里通常又分为主版本跟次版本，以上面为例，主版本为 3 ，在主版本的架构下更动部分原代码内容，而发布一个新的版本，就是次版本啦！ 以上面为例，就是 1 啰！


• 发布版本次数：
  也就是编译的次数啦！那么为何需要重复的编译呢？ 这是由于同一版的套件中，可能由于有某些 bug 或者是安全上的顾虑，所以必须要重新设置当初打包时候的设置参数， 设置完成之后重新编译并打包成 RPM 文件！因此就有不同的打包数出现了！( 注：这个时候原代码其实还是 3.1 那个版本，只是下达编译时的参数不同而已！ )


• 操作硬件平台：
  这是个很好玩的地方，由于 RPM 可以适用在不同的操作平台上， 但是由于不同的平台设置的参数还是有所差异性！并且，我们可以针对比较高端的 CPU 来进行优化参数的设置，所以就有所谓的 i386, i586, i686 与 noarch 等的文件名称出现了！
  
  

  平台名称	适合平台说明
  i386	几乎适用于所有的 x86 平台，不论是旧的 pentum 或者是新的 pentum-IV 与 K7 系列的 CPU等等，都可以正常的工作！那个 i 指的是 Intel 兼容的 CPU 的意思，至于 386 不用说，就是 CPU 的等级啦！
  i586	就是 586 等级的电脑，那是哪些呢？包括 pentum 第一代 MMX CPU， AMD 的 K5, K6 系列 CPU ( socket 7 插脚 ) 等等的 CPU 都算是这个等级；
  i686	在 pentun II 以后的 Intel 系列 CPU ，及 K7 以后等级的 CPU 都属于这个 686 等级！
  noarch	就是没有任何硬件等级上的限制。一般来说，这种类型的 RPM 文件，里面应该没有 binary file 存在。

  
  需要额外说明的是， i386 的文件可以在任何的机器上面安装， 不论是 586 或者是 686 的机器，但是 i686 则不一定可以使用于 386 或者是 586 的硬件上面，这是因为 i686 的 RPM 文件在编译的时候，主要是针对 686 硬件等级的 CPU 来进行优化编译，而 386/586 等级的硬件可能由于无法支持该优化参数， 所以无法使用呢！另外，在 686 的机器上使用 i686 的文件会比使用 i386 的文件，性能可能比较好一些！无论如何，使用 i386 应该就是比较没有问题的啦！另外，由于不同的 distirbution 会有不同的环境与函数库，所以在 i386 之后也有可能会额外再加上该套件的简写！

RPM 有以下的优点：

• RPM 文件本身为已经编译过的 binary 文件，可以让 client 端的用户免除重新编译的困扰；
• RPM 文件在被安装之前，RPM 会先检查系统的硬盘容量、操作系统版本等，可避免文件被安装错误；
• RPM 文件本身提供套件版本信息、相依属性套件名称、套件用途说明、套件所含文件等信息，便于了解套件；
• RPM 管理的方式使用数据库记录 RPM 文件的相关参数，便于升级、移除、查找与验证。

为什么 RPM 在使用上很方便呢？我们前面提过， RPM 这个套件管理员所处理的套件，是由套件提供者在特定的 Linux 作业平台上面将该套件编译完成，并且打包好，那用户只要拿到这个打包好的套件， 然后将里头的文件放置到应该要摆放的目录，不就完成安装啰？！对啦！就是这样！ 但是有没有想过，我们在前一章原代码与 Tarball 里面提过的，有些套件是有相关性的，例如要安装网络卡驱动程序，就得要有 kernel source 与 gcc 及 make 等套件。那么我们的 RPM 套件是否一定可以安装完成呢？！ 如果该套件安装之后，却找不到他相关的前驱套件，那不是挺麻烦的吗？因为安装好的套件也无法使用啊！

为了解决这种具有相关性套件之间的问题，就是所谓的套件相依属性，RPM 就在提供套件打包的文件时，同时加入一些消息登录的功能，这些消息包括套件的版本、 打包套件者、相依属性的套件、套件的功能说明、该套件的所有文件与目录纪录、等等，然后在 Linux 系统上面亦创建一个 RPM 套件数据库( database )，如此一来，当您要安装某个以 RPM 型态提供的套件时，在安装的过程中， RPM 会去检验一下数据库里面是否已经存在相关的套件了， 如果数据库显示不存在，那么这个 RPM 文件『缺省』就不能安装( 会显示一些错误消息 )。呵呵！没有错，这个就是 RPM 类型的文件最为人所诟病的『 套件的属性相依』问题啦！

虽然 RPM 有套件属性相依的问题，但是 RPM 的优点实在是比缺点要好的多，所以很多用户还是偏好使用 RPM 来管理自己的套件，在这样的情况下，如何解决 RPM 的属性相依问题呢？最简单的方式就是在安装 RPM 文件的时候，发生套件相依的问题时，手动去下载前驱套件，先安装好这些套件， 然后再安装最终想要安装的套件即可。但是，如此一来很花费用户的精神与时间，挺麻烦的啦！ 有没有比较快速的方法呢？

呵呵！有的，由于 RPM 类型的文件里面含有属性相依的消息存在，如果我们可以通过分析这些消息， 再让程序自行去寻找未安装的前驱套件，并事先加以安装，如此一来不就解决了属性相依的困扰了吗？！ 没错！是这样！这就是目前所谓的 urpmi/apt/yum 等服务的由来啦！这些服务都是通过分析 RPM 文件的相依信息，然后自行取得相依属性套件， 自行完成安装的动作，呵呵！相当的方便呢！这些信息我们会在 服务器架设篇 里面进行介绍，在这个章节当中，我们主要还是以单纯的 RPM 为主喔！

一般来说，RPM 类型的文件在安装的时候，会先去读取文件内记载的设置参数内容，然后将该数据用来比对 Linux 系统的环境( 例如属性相依的套件 )，例如目前 SSH 这个远程连接软件( 请参考服务器篇 )使用的是 OpenSSL 的加密机制，所以，要安装 SSH 的时候，就得要先安装好 OpenSSL 才行啊，如果没有安装 OpenSSL 的话， SSH 就不让您安装了！这些都是 RPM 环境的要求， 如果环境相符就予以安装，如果不符就会显示出不符合的内容所在！ 等到安装完毕之后， rpm 就会将套件的信息写入：/var/lib/rpm 这个目录中去！所以， 往后您在进行查找的时候或者是预计要升级的时候，相关的信息就会由 /var/lib/rpm 这个目录的内容数据来提供啰！

一般来说，由于 RPM 有数据库来纪录套件相关的信息，所以 RPM 类型的套件所拥有的文件都放置在系统缺省放置的目录底下，亦即如同我们在 文件属性与目录配置 一文当中提到的：

/etc	一些设置档放置的目录，例如 /etc/crontab
/usr/bin	一些可运行文件
/usr/lib	一些程序使用的动态函数库
/usr/share/doc	一些基本的软件使用手册与说明档
/usr/share/man	一些 man page 文件

好了，底下我们就来针对每个 RPM 的相关指令来进行说明啰！

安装就是 install 嘛！所以啰，使用 rpm 来安装就很简单啦！假设我要安装一个文件名为 rp-pppoe-3.1-5.i386.rpm 的文件，那么我可以这样( 记得某些套件可能需要以系统管理员的身份来安装 )：

[root@linux ~]# rpm -i rp-pppoe-3.1-5.i386.rpm

不过，这样的参数其实无法显示安装的进度，所以，通常我们会这样下达安装指令：

[root@linux ~]# rpm -ivh package_name
参数：
-i ：install 的意思
-v ：察看更细部的安装信息画面
-h ：以安装信息列显示安装进度
范例：

范例一：安装 rp-pppoe-3.1-5.i386.rpm
[root@linux ~]# rpm -ivh rp-pppoe-3.1-5.i386.rpm
Preparing...     ####################################### [100%]
   1:rp-pppoe    ####################################### [100%] 

范例二、一口气安装两个以上的套件时：
[root@linux ~]# rpm -ivh a.i386.rpm b.i386.rpm *.rpm
# 后面直接接上许多的套件文件！

范例三、直接由网络上面的某个文件安装，以网址来安装：
[root@linux ~]# rpm -ivh http://website.name/path/pkgname.rpm

另外，如果我们在安装的过程当中发现问题，或者已经知道会发生的问题， 而还是『执意』要安装这个套件时，可以使用如下的参数『强制』安装上去：

可下达的参数	代表意义
--nodeps	使用时机： 如果您在安装某个套件时，老是发现 rpm 告诉你『有属性相依的套件尚未安装』， 而您又想要直接强制安装这个套件时，可以加上 --nodeps 告知 RPM 不要去检查套件的相依性。 危险性： 套件会有相依性的原因是因为彼此会使用到对方的机制或功能，如果强制安装而不考虑套件的属性相依， 则可能会造成该套件的无法正常使用！
--nomd5	使用时机： 不想检查 RPM 文件所含的 MD5 信息时。 说明： 还记得我们在前一章有提到的 MD5 这个指纹辨识吧？！没错，这里指的就是不要检查 RPM 套件的 MD5 信息。但除非您很清楚这个套件的来源，否则不建议使用这个参数。
--noscripts	使用时机： 不想让该套件自行激活或者自行运行某些系统指令。 说明： RPM 的优点除了可以将文件放置到定位之外，还可以自动运行一些前置作业的指令，例如数据库的初始化。 如果您不想要让 RPM 帮您自动运行这一类型的指令，就加上他吧！
--replacefiles	使用时机： 如果在安装的过程当中出现了『某个文件已经被安装在您的系统上面』的信息， 又或许出现版本不合的消息( confilcting files )时，可以使用这个参数来直接覆盖文件。 危险性： 覆盖的动作是无法复原的！所以，您必须要很清楚的知道被覆盖的文件是真的不重要喔！否则会欲哭无泪！
--replacepkgs	使用时机： 重新安装某个已经安装过的套件！
--force	使用时机： 这个参数其实就是 --replacefiles 与 --replacepkgs 的综合体！
--test	使用时机： 想要测试一下该套件是否可以被安装到用户的 Linux 环境当中。范例为： rpm -ivh pkgname.i386.rpm --test

一般来说，安装的指令大约就是这些了。通常鸟哥建议直接使用 -ivh 就好了， 如果安装的过程中发现问题，一个一个去将问题找出来，尽量不要使用『 暴力安装法 』，因为可能会发生很多不可预期的问题呢！ 除非您很清楚的知道使用上面的参数后，安装的结果是您预期的！

使用 RPM 来升级真是太简单了！就以 -Uvh 或 -Fvh 来升级即可( 注：vh 的功能仍是在于显示细部信息与安装进度而已 )！不过，这两种升级方式是不太一样的：

-Uvh	后面接的套件即使没有安装过，则系统将予以直接安装； 若后面接的套件有安装过旧版，则系统自动更新至新版；
-Fvh	如果后面接的套件并未安装到您的 Linux 系统上，则该套件不会被安装；亦即只有安装至您 Linux 系统内的套件会被『升级』！

由上面的说明来看，如果您想要大量的升级系统旧版本的套件时( 例如刚安装完操作系统，而想要更新套件至最新 )，使用 -Fvh 则是比较好的作法。但是需要注意的是，如果您使用的是 Fvh ，偏偏您的机器上尚无这一个套件，那么很抱歉，该套件并不会被安装在您的 Linux 主机上面，所以请重新以 ivh 来安装吧！

通常有的朋友在进行整个操作系统的旧版套件修补时，喜欢这么进行：

1. 先到各发展商的 errata 网站或者是国内的 FTP 映像站捉下来最新的 RPM 文件；
2. 使用 -Fvh 来将您的系统内曾安装过的套件进行修补与升级！(真是方便呀！)

当然啰，升级也是可以利用 --nodeps/--force 等等的参数啦！

RPM 在查找的时候，其实查找的地方是在 /var/lib/rpm 这个目录下的数据库文件啦！另外， RPM 也可以查找文件内的信息喔！那如何去查找呢？我们底下以 简单的范例来说明：

[root@linux ~]# rpm -qa
[root@linux ~]# rpm -q[licdR] 已安装的套件名称
[root@linux ~]# rpm -qf 存在于系统上面的某个文件
[root@linux ~]# rpm -qp[licdR] 未安装的某个文件名称
参数：
在查找的部分，所有的参数之前都需要加上 -q 才是所谓的查找！
查找主要分为两部分，一个是查已安装，另一个则是查某个 rpm 文件内容。
查找已安装套件的信息：
-q  ：仅查找，后面接的套件名称是否有安装；
-qa ：列出所有的，已经安装在本机 Linux 系统上面的所有套件名称；
-qi ：列出该套件的详细信息 (information)，包含开发商、版本与说明等；
-ql ：列出该套件所有的文件与目录所在完整文件名 (list)；
-qc ：列出该套件的所有设置档 (找出在 /etc/ 底下的文件名而已)
-qd ：列出该套件的所有说明档 (找出与 man 有关的文件而已)
-qR ：列出与该套件有关的相依套件所含的文件 (Required 的意思)
-qf ：由后面接的文件名称，找出该文件属于哪一个已安装的套件；
查找某个 RPM 文件内含有的信息：
-qp[icdlR]：注意 -qp 后面接的所有参数以上面的说明一致。但用途仅在于找出
	    某个 RPM 文件内的信息，而非已安装的套件信息！注意！
范例：

范例一：找出你的 Linux 是否有安装 logrotate 这个套件？
[root@linux ~]# rpm -q logrotate
logrotate-3.7.1-10
[root@linux ~]# rpm -q logrotating
package logrotating is not installed
# 注意到，系统会去找是否有安装后面接的套件名称。注意，
# 不必要加上版本喔！至于显示的结果，一看就知道有没有安装啦！

范例二：列出上题当中，该套件的所有目录与文件：
[root@linux ~]# rpm -ql logrotate
/etc/cron.daily/logrotate
/etc/logrotate.conf
......以下省略......
# 可以看出该套件到底提供了多少的文件与目录。

范例三：列出 logrotate 这个套件的相关说明数据：
[root@linux ~]# rpm -qi logrotate
Name        : logrotate                Relocations: (not relocatable)
Version     : 3.7.1                         Vendor: Red Hat, Inc.
Release     : 10                        Build Date: Fri Apr  1 03:54:42 2005
Install Date: Sat Jun 25 08:28:26 2005  Build Host: tweety.build.redhat.com
Group       : 系统环境/基础             Source RPM: logrotate-3.7.1-10.src.rpm
Size        : 47825                        License: GPL
Signature   : DSA/SHA1, Sat May 21 01:34:11 2005, Key ID b44269d04f2a6fd2
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Summary     : 循环、压缩、移除以及邮寄系统纪录文件。
Description :
The logrotate utility is designed to simplify the administration of
log files on a system which generates a lot of log files. Logrotate
allows for the automatic rotation, compression, removal, and mailing of
log files. Logrotate can be set to handle a log file daily, weekly,
monthly, or when the log file gets to a certain size. Normally,
logrotate runs as a daily cron job.
# 列出该套件的 information (信息)，里面的信息可多着呢，包括了套件名称、
# 版本、开发商、SRPM文件名称、打包次数、简单说明信息、套件打包者、
# 安装日期等等！如果想要详细的知道该套件的数据，用这个参数来了解一下

范例四：分别仅找出 logrotate 的设置档与说明档
[root@linux ~]# rpm -qc logrotate
[root@linux ~]# rpm -qd logrotate

范例五：若要成功安装 logrotate ，他还需要什么文件的帮忙？
[root@linux ~]# rpm -qR logrotate
/bin/sh
config(logrotate) = 3.7.1-10
libc.so.6
....以下省略....
# 由这里看起来，呵呵～还需要很多文件的支持才行喔！

范例六：由上面的范例五，找出 /bin/sh 是那个套件提供的？
[root@linux ~]# rpm -qf /bin/sh
bash-3.0-31
# 这个参数后面接的可是『文件』呐！不像前面都是接套件喔！
# 这个功能在查找系统的某个文件属于哪一个套件所有的。

范例七：假设我有下载一个 RPM 文件，想要知道该文件的需求文件，该如何？
[root@linux ~]# rpm -qpR filename.i386.rpm
# 加上 -qpR ，找出该文件需求的数据！

常见的查找就是这些了！要特别说明的是，在查找本机上面的 RPM 套件相关信息时， 不需要加上版本的名称，只要加上套件名称即可！因为他会由 /var/lib/rpm 这个数据库里面去查找， 所以我们可以不需要加上版本名称。但是查找某个 RPM 文件就不同了， 我们必须要列出整个文件的完整文件名才行～ 这一点朋友们常常会搞错。底下我们就来做几个简单的练习吧！

例题： 我想要知道我的系统当中，以 c 开头的套件有几个，如何实做？ rpm -qa | grep ^c | wc -l 我的 WWW 服务器为 Apache ，我知道他使用的 RPM 套件文件名为 httpd 。 现在，我想要知道这个套件的所有设置档放置在何处，可以怎么作？ rpm -qc httpd 承上题，如果查出来的设置文件已经被我改过，但是我忘记了曾经修改过哪些地方， 所以想要直接重新安装一次该套件，该如何作？ 假设该套件在网络上的网址为： http://web.site.name/path/httpd-x.x.xx.i386.rpm 则我可以这样做： rpm -ivh http://web.site.name/path/httpd-x.x.xx.i386.rpm --replacepkgs 如果我误砍了某个重要文件，例如 /etc/crontab，偏偏不晓得他属于哪一个套件，该怎么办？！ 虽然已经没有这个文件了，不过没有关系，因为 RPM 有纪录在 /var/lib/rpm 当中的数据库啊！所以直接下达： rpm -qf /etc/crontab 就可以知道是那个套件啰！重新安装一次该套件即可！

验证的功能主要在于提供系统管理员一个有用的管理机制！作用的方式是『 使用 /var/lib/rpm 底下的数据库内容来比对目前 Linux 系统的环境下的所有套件文件 』也就是说，当您有数据不小心遗失， 或者是因为您误杀了某个套件的文件，或者是不小心不知道修改到某一个套件的文件内容， 就用这个简单的方法来验证一下原本的文件系统吧！ 好让您了解这一阵子到底是修改到哪些文件数据了！验证的方式很简单：

[root@linux ~]# rpm -Va
[root@linux ~]# rpm -V  已安装的套件名称
[root@linux ~]# rpm -Vp 某个 RPM 文件的文件名
[root@linux ~]# rpm -Vf 在系统上面的某个文件
参数：
-V  ：后面加的是套件名称，若该套件所含的文件被更动过，才会列出来；
-Va ：列出目前系统上面所有可能被更动过的文件；
-Vp ：后面加的是文件名称，列出该套件内可能被更动过的文件；
-Vf ：列出某个文件是否被更动过～
范例：

范例一：列出你的 Linux 内的 logrotate 这个套件是否被更动过？
[root@linux ~]# rpm -V logrotate
# 如果没有出现任何消息，恭喜你，该套件没有被更动过。
# 如果有出现任何消息，才是有出现状况啊！

范例二：查找一下，你的 /etc/crontab 是否有被更动过？
[root@linux ~]# rpm -Vf /etc/crontab
S.5....T  c /etc/crontab
# 瞧！因为有被更动过，所以会列出被更动过的信息！

好了，那么我怎么知道到底我的文件被更动过的内容是什么？呵呵！简单的说明一下吧！ 例如，我们检查一下 logrotate 这个套件：

[root@linux ~]# rpm -ql logrotate
/etc/cron.daily/logrotate
/etc/logrotate.conf
/etc/logrotate.d
/usr/sbin/logrotate
/usr/share/doc/logrotate-3.7.1
/usr/share/doc/logrotate-3.7.1/CHANGES
/usr/share/man/man8/logrotate.8.gz
/var/lib/logrotate.status
# 呵呵！共有八个文件啊！ 

[root@linux ~]# rpm -V logrotate
..5....T c /etc/logrotate.conf
# 上面的信息是这样的：
S ：file Size differs
    文件的容量大小是否被改变
M ：Mode differs (includes permissions and file type)
    文件的类型或文件的属性，如是否可运行等参数已被改变
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
    文件的创建时间已被改变

所以，如果当一个文件所有的信息都被更动过，那么他的显示就会是：

SM5DLUGT c filename

至于那个 c 代表的是『 Config file 』的意思，也就是文件的类型，文件类型有底下这几类：

• c ：设置档(config file)
• d ：文档数据档(documentation)
• g ：鬼文件～通常是该文件不被某个套件所包含，较少发生！(ghost file)
• l ：授权文件(license file)
• r ：读我文件(read me)

经过验证的功能，您就可以知道那个文件被更动过。那么如果该文件的变更是『预期中的』， 那么就没有什么大问题，但是如果该文件是『非预期的』，那么是否被入侵了呢？呵呵！ 得注意注意啰！

再来，由于数字签证的盛行，我们 Linux 的 RPM 也可以利用数字签证来判断待安装的套件文件是否有问题喔！一般我们使用的是 GPG 的密钥( public key )。应用的方法很简单，首先， 当我们想要使用某个团体发布的套件时，就需要将他们发布的 GPG 密钥先安装在自己的 Linux 系统上。然后，当安装该团体发布的套件时，就会检查两者的 key 是否相同，如果相同就直接安装，如果不同就会在屏幕上面显示消息告知您并未安装该团体的 GPG 密钥！

安装密钥的方法很简单，例如 Red Hat 本身就有密钥在系统当中，安装如下：

[root@linux ~]# rpm --import /usr/share/rhn/RPM-GPG-KEY

一般来说，您的 Linux distributions 都会发布自己的 GPG Key 的，如果是 Red Hat 系统的话， 可以使用：

[root@linux ~]# locate GPG-KEY

来进行搜索文件的工作，至于这些密钥的内容，我们可以这样查找喔：

[root@linux ~]# rpm -qa | grep gpg
libgpg-error-1.0-2
gpg-pubkey-4f2a6fd2-3f9d9d3b
[root@linux ~]# rpm -qi gpg-pubkey-4f2a6fd2-3f9d9d3b
Name        : gpg-pubkey               Relocations: (not relocatable)
Version     : 4f2a6fd2                      Vendor: (none)
Release     : 3f9d9d3b                  Build Date: Sat Jun 25 22:13:00 2005
Install Date: Sat Jun 25 22:13:00 2005  Build Host: localhost
Group       : Public Keys               Source RPM: (none)
Size        : 0                            License: pubkey
Signature   : (none)
Summary     : gpg(Fedora Project <fedora@redhat.com>)
Description :
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: rpm-4.4.1 (beecrypt-3.0.0)

mQGiBD+dnTsRBACwnlz4AhctOLlVBAsq+RaU82nb5P3bD1YJJpsAce1Ckd2sBUOJD11NUCqH
.....中间省略.....
=mJAx
-----END PGP PUBLIC KEY BLOCK-----

这样就能看到相关的信息啰！ ^_^

反安装就是将套件卸载啦！要注意的是，『解安装的过程一定要由最上层往下解除』，以 rp-pppoe 为例，这一个套件主要是依据 ppp 这个套件来安装的，所以当您要解除 ppp 的时候，就必须要先解除 rp-pppoe 才行！否则就会发生结构上的问题啦！这个可以由建筑物来说明， 如果你要拆除五、六楼，那么当然要由六楼拆起，否则拆了第五楼，那么上面的楼层难道会悬空？

那么重建数据库呢？由于我们会一直在修改一些文件内容，例如 /etc/xinetd.d 里头的参数文件，加上可能自系统操作的过程中添加、移除等等的动作，导致系统的数据库有点乱， 这个时候可以使用--rebuilddb 来重建一下 rpm 的数据库！这两个方法的参数如下啰：

[root@linux ~]# rpm -e logrotate  <==解安装 logrotate 套件
[root@linux ~]# rpm --rebuilddb   <==重建数据库

假设我下载了一个 SRPM 的文件，又不想要修订这个文件内的原代码与相关的设置值， 那么我可以直接编译并安装吗？当然可以！利用 rpmbuild 配合参数即可。参数主要有底下两个：

--rebuild	这个参数会将后面的 SRPM 进行『编译』与『打包』的动作，最后会产生 RPM 的文件，但是产生的 RPM 文件并没有安装到系统上。当您使用 --rebuild 的时候，最后通常会发现一行字体： Wrote: /usr/src/RPM/RPMS/i386/pkgname.i386.rpm 这个就是编译完成的 RPM 文件啰！那么这个文件就可以用来安装啦！安装的时候请加绝对路径来安装即可！
--recompile	这个动作会直接的『编译』『打包』并且『安装』啰！请注意， rebuild 仅『编译并打包』而已，而 recompile 不但进行编译跟打包，还同时进行『安装』了！

一般来说，如果编译的动作顺利的话，那么编译过程所产生的中间暂存盘都会被自动删除， 如果发生任何错误，则该中间文件会被保留在系统上，等待用户的调试动作！那么， 该如何调试呢？！如果想要自行调试，就得要知道利用 SRPM 的时候，系统会动用到哪些重要的目录了！底下我们就来谈一谈当处理 SRPM 时，系统会使用到的目录。

SRPM 既然含有 source code ，那么其中必定有设置档啰，所以首先我们必需要知道，这个 SRPM 在进行编译的时候，会使用到哪些目录呢？这样一来才能够来修改嘛！你可以到你的 /usr/src 这个目录里面去查看一下，通常每个 distribution 提供的目录都不太相同，以 FC4 为例，他是以 /usr/src/redhat/ 为工作目录， Openlinux 则是以 /usr/src/openlinux 为工作目录！无论如何，反正就是在 /usr/src 这个目录下就对了！好了到 /usr/src/redhat 里头去看一看呦：

/usr/src/redhat/SPEC	这个目录当中放置的是该套件的设置档，例如这个套件的信息参数、设置项目等等都放置在这里；
/usr/src/redhat/SOURCE	这个目录当中放置的是该套件的源文件（*.tar.gz的文件）以及 config 这个设置档；
/usr/src/redhat/BUILD	在编译的过程中，有些暂存的数据都会放置在这个目录当中；
/usr/src/redhat/RPMS	经过编译之后，并且顺利的编译成功之后，将打包完成的文件放置在这个目录当中。里头有包含了 i386, i586, i686, noarch.... 等等的次目录。

此外，在编译的过程当中，可能会发生不明的错误，或者是设置的错误，这个时候就会在 /tmp 底下产生一个相对应的错误档，您可以根据该错误档进行调试的工作呢！ 等到所有的问题都解决之后，也编译成功了，那么刚刚解压缩之后的文件，就是在 /usr/src/redhat/SPEC, SOURCE, BUILD 等等的文件都会被杀掉，而只剩下放置在 /usr/src/redhat/RPMS 底下的文件了！

由于 SRPM 需要重新编译，而编译的过程当中，我们至少需要有 make 与其相关的程序，及 gcc, c, c++ 等其他的编译用的编程语言来进行编译，所以， 如果您在安装的过程当中没有选取软件开发工具之类的套件，呵呵！得重新拿出你的光盘， 然后再安装喔！哈哈！只是得要克服一大堆的属性相依的问题就是了～ 嗯！还是建议您再次的看一下如何安装吧！

刚刚我们在上面提过了，SRPM 还可以更改一些设置的内容，那么要如何修改这些设置的内容呢？我们以简单的 rp-pppoe 这个套件来说明好了。比较可惜的是， rp-pppoe 的官方网站目前 (2005/10) 似乎不再提供新的 SRPM 文件了，所以，我们是由 rpmfind.net ( http://rpmfind.net/ ) 找到给 FC4 使用的 SRPM 文件 (是测试版喔！) ， 你可以自行查阅一下这个 rp-pppoe 相关的信息以及 rpmfind.net 网站提供的信息。

• rp-pppoe 的官方网站：
  http://www.roaringpenguin.com/pppoe/
• rpmfind.net 与 FC 系列有关的 rp-pppoe 说明与下载点：
  http://rpmfind.net//linux/RPM/fedora/devel/src/rp-pppoe-3.5-30.src.html
  ftp://rpmfind.net/linux/fedora/core/development/SRPMS/rp-pppoe-3.5-30.src.rpm

至于基本的过程如下：(鸟哥在这里假设你已经将 rp-pppoe-3.5-30.src.rpm 下载到 /root 底下了)

[root@linux ~]# rpm -i /root/rp-pppoe-3.5-30.src.rpm
# 这个过程不会显示任何东西，他只会将 SRPM 的文件解开后，放置到 
# /usr/src/redhat 下！

[root@linux ~]# find /usr/src/redhat/ -type f
/usr/src/redhat/SOURCES/rp-pppoe-3.5-buildroot.patch
/usr/src/redhat/SOURCES/adsl-stop
/usr/src/redhat/SOURCES/adsl-start
/usr/src/redhat/SOURCES/adsl-setup
/usr/src/redhat/SOURCES/rp-pppoe-3.4-redhat.patch
/usr/src/redhat/SOURCES/adsl-status
/usr/src/redhat/SOURCES/rp-pppoe-3.5-firewall.patch
/usr/src/redhat/SOURCES/adsl-connect
/usr/src/redhat/SOURCES/rp-pppoe-3.5.tar.gz
/usr/src/redhat/SPECS/rp-pppoe.spec
# 主要含有原代码与一个重要的设置档啊！ rp-pppoe.spec ！

好了，来看看我们的设置参数档，亦即是在 /usr/src/redhat/SPECS 内的 *.spec 文件啰！

[root@linux ~]# cd /usr/src/redhat/SPECS
[root@linux SPECS]# vi rp-pppoe.spec
# 1. 首先，这个部分在介绍整个套件的基本相关信息！不论是版本还是发布次数等。
Summary: A PPP over Ethernet client (for xDSL support).
Name: rp-pppoe
Version: 3.5
Release: 30
License: GPL
Group: System Environment/Daemons
Url: http://www.roaringpenguin.com/pppoe/
Source: http://www.roaringpenguin.com/rp-pppoe-%{version}.tar.gz
Source1: adsl-connect
Source2: adsl-setup
.....中间省略.....

# 2. 这部分则是在设置相依属性需求的地方！
Prereq: /sbin/chkconfig
Prereq: /sbin/service
Prereq: fileutils
Requires: ppp >= 2.4.2
Requires: initscripts >= 5.92
Requires: iproute >= 2.6
ExcludeArch: s390 s390x

%description
PPPoE (Point-to-Point Protocol over Ethernet) is a protocol used by
many ADSL Internet Service Providers. This package contains the
Roaring Penguin PPPoE client, a user-mode program that does not
require any kernel modifications. It is fully compliant with RFC 2516,
the official PPPoE specification.

# 3. 编译前的预处理，以及编译过程当中所需要进行的指令，都写在这里
#    尤其 %build 底下的数据，几乎就是 makefile 里面的信息啊！
%prep
%setup -q
%patch0 -p1 -b .config
%patch1 -p1 -b .buildroot
%patch2 -p1 -b .ipchains

%build
cd src
autoconf
CFLAGS="-D_GNU_SOURCE" %configure
make

install -m 0755 %{SOURCE1} scripts
install -m 0755 %{SOURCE2} scripts
install -m 0755 %{SOURCE3} scripts
install -m 0755 %{SOURCE4} scripts
install -m 0755 %{SOURCE5} scripts

%install
rm -rf $RPM_BUILD_ROOT
.....中间省略.....

# 4. 这里列出，这个套件发布的文件有哪些的意思！
%files
%defattr(-,root,root)
%doc doc/LICENSE scripts/adsl-connect scripts/adsl-setup scripts/adsl-init
%doc scripts/adsl-start scripts/adsl-status scripts/adsl-stop
%doc configs
%config(noreplace) %{_sysconfdir}/ppp/pppoe-server-options
%config(noreplace) %{_sysconfdir}/ppp/firewall*
/sbin/*
%{_sbindir}/*
%{_mandir}/man?/*

# 5. 列出这个套件的更改历史纪录档！
%changelog
* Mon Aug 15 2005 Than Ngo <than@redhat.com> 3.5-30
- defaultroute should not overridden #152014
.....中间省略.....
* Wed May 31 2000 Than Ngo <than@redhat.de>
- adopted for Winston.

注意到的是rp-pppoe.sepc这个文件，这是主要的将SRPM编译成RPM的设置档，他的基本规则可以这样看：

1. 整个文件的开头以Summary为开始，这部份的设置都是最基础的说明内容；
2. 然后每个不同的段落之间，都以%来做为开头，例如%prep与%install等；

我们来谈一谈几个常见的SRPM设置段落：

系统整体信息方面：

%description

%prep

%setup

%build

%install

%files

%changelog

好了，那么如果您有自订的信息想要加入的话，就选择你要加入的那个段落，将他修改一下吧！ 例如，如果你在设置 Makefile 的时候，希望能够多一些额外的参数设置，那么就找到 %setup 或 %build 那个段落，将他修改成您所需要的样子，就可以啰！

再来呢？嗯！没错，修改完成了，自然就是要将他编译成可以安装的 RPM 文件啦！ 这个时候我们就可以直接在 /usr/src/redhat/SPECS 底下下达：

[root@linux ~]# rpmbuild -bb rp-pppoe.spec  <==编译成RPM文件
[root@linux ~]# rpmbuild -ba rp-pppoe.spec  <==打包成SRPM文件

这个时候系统就会这样做：

1. 先进入到 BUILD 这个目录中，在 Fedora 底下就是 /usr/src/redhat/BUILD 这个目录；
2. 依照 *.spec 文件内的 Name 与 Version 设置定义出工作的目录名称， 以我们上面的例子为例，那么系统就会在 BUILD 目录中先删除 rp-pppoe-3.5 的目录，再重新创建一个 rp-pppoe-3.5 的目录，并进入该目录；
3. 在新建的目录里面，针对 SOURCES 目录下的来源文件，也就是 *.spec 里面的 Source 设置的那个文件，以 tar 进行解压缩，以我们这个例子来说，则会在 /usr/src/redhat/BUILD/rp-pppoe-3.5 当中，将 /usr/src/redhat/SOURCES/rp-pppoe-3.5.tar.gz 进行解压缩啦！
4. 然后就开始 %setup 的工作；
5. 再来开始 %build 及 %install 的设置与编译！
6. 最后将完成打包的文件给他放置到该放置的地方去，如果你的规定的硬件是在i386的系统，那么最后编译成功的*.i386.rpm文件就会被放置在/usr/src/RPM/RPMS/i386里面啰！如果是i586那么自然就是 /usr/src/redhat/RPMS/i586目录下啰！

整个步骤大概就是这样子！最后的结果数据会放置在RPMS那个目录底下就对啦！

这一直是个有趣的问题：『如果我要升级的话，或者是全新安装一个新的套件， 那么该选择 RPM 还是 Tarball 来安装呢？』！基本上，如果有 RPM 可以提供给您的 distribution 来安装，并且没有严重的相依属性的问题时，呵呵！选择 RPM 来安装会是一个比较好的解决方案， Why ？这是由于刚刚上面就提到的 RPM 的好处 啦！可以具有文件与数据均有纪录的优点，这就是上面提到的 /var/lib/rpm 这个目录里面的数据库，这个记录可以让你在管理上更为便利，包括上面提到的 RPM 的升级、安装、验证与移除等等。尤其是在查找上面！可以让你在管理你的系统上面更为便利。

但是 RPM 也不是没有缺点的，包括最为大家所抱怨连连的『 属性相依 』的问题，每一个不同版本之间，就必须要以不同的 RPM 文件来安装！此外，如果要升级『某一个套件』而已时， 通常还需要连带其他的套件也必须要一起升级才行，否则会有问题！此外，当一个套件经过了『 大幅度的修改 』之后，通常旧的 RPM 与新的 RPM 之间已经几乎无法『完全兼容』时， 呵呵！那么升级或者是移除的手续可是会累坏人的！

例如前两年朋友们常常问到的 Apache 1.3.xx 与 2.0.xx 的版本升级问题！ 由于这两个版本之间的架构差异性太大，加上版本属性相依问题，所以很难得到一个完满的解决方案，这个时候 RPM 就不那么合适了。( 除非您要一个一个的将 Apache 移除，连同其相依的套件，然后再将 Apache 一个一个的安装，包括新套件的相依套件！ ^_^ .....鸟哥是不会这么做的啦！ )

如果 RPM 文件并不是这么容易取得的话，这个时候 Tarball 的方式就特别适合您的安装了！这是因为 Tarball 可以自行设置编译时的参数，此外，也可以自行设置『安装路径』， 相当的适合于想要安装『多个不同版本的同一个套件』的情况( 说穿了就是测试机器 )！

这是怎么说呢？！由于 RPM 必须要配合系统里面其他的相依属性的套件，所以基本上， 他的安装路径( 就是每个文件的放置路径 )理论上是必须要放在固定的目录的，就是不能随意的改变他的安装路径。 因此，当有两个不同版本的相同套件想要测试的时候，大概一定就得将原先的版本移除之后， 才能安装使用新的版本啰！(此外，由于相依的套件几乎都已经包含在 tarball 当中了，所以安装上面其实并不难啦！)

相对于 RPM 的制式格式， tarball 可就灵活多了！你可以自行编译套件并且将他安装在不同的路径， 只要在启动的时候选择正确的版本，那么不同版本的套件可以同时的存在于一个系统当中， 而且可以通过选择启动的文件来启动不同的版本。当然啰！你也可以让 tarball 的安装与 RPM 的安装同时存在于一个系统当中，但是需要特别留意的是， 你在启动该套件的时候，千万记得你的启动路径！免得启动到了错误的版本了！呵呵！( 这也是一个系统存在不同多个版本的套件容易发生的错误！ 希望大家都能够了解这个问题呢！ )

所以说，为了避免这种路径上的错误困扰，基本上，我们都希望 Tarball 的安装路径可以设置在 Linux 原本就规划要给大家安装的路径『 /usr/local 』这个路径下！这样可以省去相当多寻找文件的时间！ 而且在管理上面也会比较容易！呵呵！

不过， Tarball 最麻烦的地方有几点：

• 反安装：
  Tarball 最麻烦的地方就在于他的『解安装』了！ 相当的讨厌！如果是简单的直接将所有的套件安装在一个目录下的话，例如 /usr/local/mrtg 时，那么解安装还算简单，就是将该路径杀掉就 OK 啦！但是如果是类似 sendmail 这一种呢？他的路径都是已经放置死的( 需要在 /etc/sendmail.cf、/etc/mail 底下 )那么追踪反安装的路径就很烦人；


• 在线查找：
  如果您的安装路径是在 /usr/local 底下的话，那么运行档会被放置到 /usr/local/bin ，或者是 /usr/local/sbin 底下，参数档会放在 /usr/local/etc 底下，在线查找文件会放在 /usr/local/man 底下，所以在设置上面还有查找上面还算简单( 路径设置一下即可！ )，不过，如果你是将套件安装在单独的路径下呢？例如 /usr/local/mrtg 底下，那么运行档变成了 /usr/local/mrtg/bin 底下，最麻烦的地方就是 man page ( 在线查找 )放置的地点会变成在 /usr/local/mrtg/man 底下了！糟糕！那么缺省的 man page 路径就找不到该说明档啰！ 这个时候就必须要手动的将该路径加入 /etc/man.conf 这个文件中！而且运行档放置的路径也没有指定，可以经由 (1)Link 的方式或者 (2)设置 PATH 环境变量的方式将该路径加进去啦！确实是比较麻烦的啦！

所以说，RPM 与 Tarball 各有其优缺点，不过，如果有 RPM 的话，那么优先权还是在于 RPM 安装上面，毕竟管理上比较便利，但是如果套件的架构差异性太大， 或者是无法解决相依属性的问题，那么与其花大把的时间与精力在解决属性相依的问题上，还不如直接以 tarball 来安装，轻松又惬意！