第十八章、RPM 与 Tarball 套件管理员 - for Mandrake 9

为何需要升级套件

这真是一个很有趣的课题，为何需要升级套件？如果我的机器运作的好好的，那么我干嘛需要升级？通常我们升级的原因主要有三个：

• 需要新的功能，但旧有主机并没有，所以需要安装新的套件；
• 旧版本的套件上面可能有安全上的顾虑，所以需要更新到新版的套件；
• 旧版的套件运行性能不彰，或者运行的能力不能让管理者满足。

在上面的需求当中，尤其需要注意的是第二点，当一个套件有安全上的顾虑时，千万不要怀疑，赶紧更新套件吧！否则造成网络危机，那可不是闹着玩的?那么更新的方法有哪些呢？其实，目前在 Linux 里面有相当多的不同的更新套件的方式，包括了 Red Hat 发展的 RPM 与 up2date 的在线更新模式； Debian 这个 distribution 里头使用的 dpkg 方法；Sun Unix 上面使用的 pkg 升级方式；目前越来越流行的 apt 在线更新模式；还有原代码里头最常使用的 Tarball 编译方法等等，如果要一个一个说明的话那也太累人了?所以，这里我们以目前在 Mandrake, Red Hat, OpenLinux 等 Linux distributions 内常见的 RPM 与 Tarball 的套件升级方式来进行说明：

• RPM

目前使用最广泛的套件管理程序之一，利用数据库管理的方式来进行套件的安装，具有相当容易的操作接口，而且套件查找验证的功能相当强大，不过麻烦的地方在于他的属性相依的问题；

• Tarball

直接以原代码( source code )经过编译后，进行安装。在安装上面具有较大的灵活度，可以随时更改用户喜好的参数。但是需要其他的套件协助，例如 gcc compiler, kernel-header, make 套件等等，并且在反安装上面具有一定程度的困难度；

这两种方法是各有优缺点啦，我们这里想要来谈一谈 RPM 与 Tarball 的安装方式了！

RPM套件管理员：

接下来我们先谈论一下广为流传与使用的 RPM 套件管理员的相关使用方法喔！
　


---

• 什么是 RPM 、 SRPM ？

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 文件，并不能用在其他的 distribution 里面，举例来说， Red Hat 发布的 RPM 文件，通常无法直接在 Mandrake 上面进行安装的，更有甚者，不同版本之间也无法互通，例如 Mandrake 9.0 的 RPM 文件就无法直接套用在 8.2 上面！因此，这样可以发现他的缺点是：
　
1. 安装的环境必须与打包时的环境需求一致或相当；
2. 需要满足套件的相依属性需求；
3. 反安装时需要特别小心，最底层的套件不可先移除，否则可能造成整个系统的问题！
　
那怎么办？呵呵！还好，还有 SRPM 这个东西！ SRPM 是什么呢？他也是一种 RPM 啦！但是由于里面连同当初编译之前的原代码都在里头，所以可以进行重新编译的动作。通常 SRPM 的附文件名是 ****.src.rpm 这一种文件格式。由于 SRPM 包含了原代码及参数设置文件，所以在安装之前则必须重新的编译创建起包装的信息文件套件才行！当然啰，如果在编译的过程中发生了问题，也可以借由里头的原代码更动来修正问题的所在呢！所以说， RPM 与 SRPM 最大的差异就是在于有没有包含原代码的程序啦！
　


---

• 什么是 i386, i586, i686, noarch

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

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

　
OK！那么 rpm 文件有没有什么版本或者是套件名称的称呼呢？有的，你可以这样来看待一个 rpm 的文件，例如 rp-pppoe-2.6-5.i386.rpm
　

rp-pppoe            -      2.6         -       5          .      i386        .rpm 第一个部分是套件名称 这是套件的版本信息 这是发布版本的次数 这是适合的硬件平台 附文件名而已

　
这样子可以很清楚的发现该套件的名称、版本信息、打包次数与操作的硬件平台！好了，来谈一谈每个不同的地方吧：
　
• 套件名称：当然就是每一个套件的名称了！
　
• 版本信息：每一次更新版本就需要有一个版本的信息，否则如何知道这一版是新是旧？这里通常又分为主版本跟次版本，反正版本很多啦！
　
• 发布版本次数：也就是编译的次数啦！那么为何需要重复的编译呢？这是由于同一版的套件中，可能由于有某些 bug 或者是安全上的顾虑，所以必须要重新设置当初打包时候的设置参数，设置完成之后重新编译并打包成 RPM 文件！因此就有不同的打包数出现了！
　
• 操作硬件平台：这是个很好玩的地方，由于 RPM 可以适用在不同的操作平台上，但是由于不同的平台设置的参数还是有所差异性！所以就有所谓的 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：就是没有任何硬件等级上的限制。
需要额外说明的是， i386 的文件可以在任何的机器上面安装，不论是 586 或者是 686 的机器，但是 i686 则不一定可以使用于 586 或者是 386 的硬件上面，另外，在 686 的机器上使用 i686 的文件会比使用 i386 的文件在运行上，性能可能比较好一些！无论如何，使用 i386 应该就是比较没有问题的啦！另外，由于不同的 distirbution 会有不同的环境与函数库，所以在 i386 之后也有可能会额外再加上该套件的简写！
　
好了！接下来我们来谈一谈安装的时候所需要使用到的目录！
　


---

• SRPM 与 RPM 工作时候所需要的安装目录

SRPM 的编译过程：
刚刚提到 SRPM 里头含有的是未经编译的原代码，所以我们需要将 SRPM 进行编译打包的动作！那么编译是在哪里进行呢？由于编译的时候会将原代码解压缩出来，并且将附有的参数控制选项也同时的解开，所以就有一些数据会出现了，那么这些数据放在哪里呢？你可以到你的 /usr/src 这个目录里面去查看一下，通常每个 distribution 提供的目录都不太相同，以 Mandrake 9.0 为例，他是以 /usr/src/RPM 为工作目录， Red Hat 是以 /usr/src/redhat 为工作目录， Openlinux 则是以 /usr/src/openlinux 为工作目录！无论如何，反正就是在 /usr/src 这个目录下就对了！好了，既然我们是在 Mandrake 9.0 ，所以就到 /usr/src/RPM 里头去看一看呦：
　
• /usr/src/RPM/SPEC：这个目录当中放置的是该套件的设置档，例如这个套件的信息参数、设置项目等等都放置在这里；
• /usr/src/RPM/SOURCE：这个目录当中放置的是该套件的源文件（*.tar.gz的文件）以及 config 这个设置档；
• /usr/src/RPM/BUILD：在编译的过程中，有些暂存的数据都会放置在这个目录当中；
• /usr/src/RPM/RPMS：经过编译之后，并且顺利的编译成功之后，将打包完成的文件放置在这个目录当中。里头有包含了 i386, i586, i686, noarch.... 等等的次目录。
　
此外，在编译的过程当中，可能会发生不明的错误，或者是设置的错误，这个时候就会在 /tmp 底下产生一个相对应的错误档，您可以根据该错误档进行调试的工作呢！等到所有的问题都解决之后，也编译成功了，那么刚刚解压缩之后的文件，就是在 /usr/src/RPM/SPEC, SOURCE, BUILD 等等的文件都会被杀掉，而只剩下放置在 /usr/src/RPM/RPMS 底下的文件了！
　
RPM 的安装过程：
RPM 在安装的时候，会先去读取 套件 内的设置参数内容，就是刚刚我们在 /usr/src/RPM/SPEC 的相关信息啦！然后将该数据用来比对 Linux 系统的环境，这些环境包括了这个欲安装的套件的前驱套件，例如目前 postfix 这个 e-mail 套件当中，大都支持了cyrus-sasl 这个套件的身份认证功能，所以，要安装 postfix 就必需先安装 cyrus-sasl 这个套件，否则 postfix 就不让你安装了！还有类似版本的信息等等，这些都是 RPM 环境的要求，如果环境相符就予以安装，如果不符就会显示出不符合的内容所在！等到安装完毕之后， rpm 就会将套件的信息写入：/var/lib/rpm 这个目录中去！所以，往后您在进行查找的时候或者是预计要升级的时候，相关的信息就会由 /var/lib/rpm 这个目录的内容数据来提供啰！此外，在安装 RPM 的套件时，这些套件通常会使用到底下的目录：
　
•   /etc    一些设置档放置的目录，例如 /etc/samba
•   /usr/bin   一些可运行文件
•   /usr/lib   一些程序使用的动态函数库
•   /usr/share/doc  一些基本的软件使用手册与说明档
•   /usr/share/man  一些 man page 文件
　
底下我们先针对 RPM 的相关指令来进行说明啰！

---

• RPM 的指令使用：安装、升级与更新、查找、验证、反安装与重建数据库

RPM 提供了『安装』、『升级与更新』、『查找』、『验证』、『反安装与重建数据库』等功能，底下我们一个一个来说明吧！

---

• 安装：

从无到有就是安装啦！那么安装的方式为何呢？若是 RPM 则使用 ivh 啦！如果是 SRPM 就使用 rebuild 或是 recompiler 啰！
　

[root @test /root]# rpm --rebuild   rp-pppoe-2.6-5.src.rpm  <==SRPM [root @test /root]# rpm --recompile rp-pppoe-2.6-5.src.rpm  <==SRPM [root @test /root]# rpm -ivh        rp-pppoe-2.6-5.i386.rpm <==RPM

　
• --rebuild：这个参数会将后面的 SRPM 进行『编译』与『打包』的动作，但是并没有安装，当您使用 --rebuild 的时候，最后通常会发现一行字体：

　
Wrote: /usr/src/RPM/RPMS/i386/rp-pppoe-2.6-5.i386.rpm
　
这个就是编译完成的 RPM 文件啰！那么这个文件就可以用来安装啦！安装的时候请加绝对路径来安装即可！
　
• --recompile：这个动作会直接的『编译』『打包』并且『安装』啰！请注意， rebuild 仅『编译并打包』而已，而 recompile 不但进行编译跟打包，还同时进行『安装』了！
　
• -ivh：就是用来安装 RPM 的参数而在这个参数之下，由于会有一些『相依属性』的问题，或者是曾经安装过的文件的问题，所以您可以再加以下的参数来『强制』安装：
• --nodeps：不考虑相依属性的关系，给他强制的安装下去；
• --replacepkgs：如果这个套件之前安装过，您想要覆盖这个套件，那么不需要反安装后再安装，可以直接加上 --replacepkgs 强制覆盖；
　
• --replacefiles：那么如果这个套件安装完毕之后，曾经被你修改过文件呢？就是安装过程中会出现『confilcting files 』的话，那么直接以 --replacefiles 覆盖掉这种文件吧！

　

[root @test /root]# rpm -ivh rp-pppoe-2.6-5.i386.rpm [root @test /root]# rpm -ivh --nodeps       rp-pppoe-2.6-5.i386.rpm <==不考虑相依模块 [root @test /root]# rpm -ivh --replacepkgs  rp-pppoe-2.6-5.i386.rpm <==直接覆盖掉曾安装过的套件 [root @test /root]# rpm -ivh --replacefiles rp-pppoe-2.6-5.i386.rpm <==直接覆盖掉被修改过的问题文件

　

---

• 升级：

使用 RPM 来升级真是太简单了！就以 Uvh 来升级即可！但是在比较大量的升级版本中，使用 Fvh 则是比较好的作法。但是需要注意的是，如果您使用的是 Fvh ，偏偏您的机器上尚无这一个套件，那么很抱歉，该套件并不会被安装在您的 Linux 主机上面，所以请重新以 ivh 来安装吧！
　

[root @test /root]# rpm -Uvh rp-pppoe-2.6-5.i386.rpm  [root @test /root]# rpm -Fvh *.rpm       <==所有在你 Linux 主机上面安装过的套件才升级

　
注意的是， Uvh 是升级您所写入的套件，至于 Fvh 则是『仅升级在您的系统里面存在的套件』，所以有的朋友在大量的进行套件版本修补的时候，他们都是这样做的：
　
1. 先到各发展商的  errata 网站上捉下来最新的 i386 文件；
2. 使用 -Fvh 来将您的系统内曾安装过的套件进行修补与升级！（真是方便呀！）
　


---

• 查找：

查找也是 RPM 的重要功能之一，因为他提供了这个套件的版本、用途等信息，是相当有用的！那么如何查找呢？底下列出只要的查找参数：
　

1. 从系统查找（由 /var/lib/rpm 数据库取得的数据） [root @test /root]# rpm -q rp-pppoe                 <==仅列出 rp-pppoe 这个套件的版本； [root @test /root]# rpm -qa                     <==列出所有安装过的套件与版本； [root @test /root]# rpm -qi rp-pppoe            <==列出 rp-pppoe 这个套件的详细信息 [root @test /root]# rpm -ql rp-pppoe            <==列出 rp-pppoe 这个套件安装的文件与路径； [root @test /root]# rpm -qf /etc/rc.d/init.d/pppoe  <==查找 pppoe 这个文件属于哪一个套件？ 2. 由文件查找文件的内容 [root @test /root]# rpm -qpi rp-pppoe-2.6-5.src.rpm  <==查找这个套件的详细信息； [root @test /root]# rpm -qpl rp-pppoe-2.6-5.src.rpm  <== 查找这个套件里面有多少的文件内容存在

　
• 查找套件：查找安装过的套件可以使用 -q 即可知道他的套件版本，但是如果忘记套件的全名，那么可以使用

rpm -qa | grep pakagename 来选择出适当的套件！
若使用 -qi 则可以了解这个套件的主要信息！
• 寻找套件文件：常常我们忘记一个套件内容含有的文件时，可以使用 -ql 来查找该套件，会列出相当多的文件呦！
• 由文件寻找套件：这是最长发生的问题，就是您『误砍』了某个文件，偏偏不知道他是哪一个套件的，呵呵！那么你可以请跟你同样系统的朋友，使用 -qf 来查找该文件所属的套件，然后重新安装该套件就可以就回来啦！
　


---

• 验证：

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

[root @test /root]# rpm -V rp-pppoe   <==单纯检查 rp-pppoe 这个已安装套件的文件内容与原先是否相同 [root @test /root]# rpm -Va           <==检查所有的 /var/lib/rpm 底下的数据库与 Linux 系统下是否相同的文件！ 范例： [root @test /root]# rpm -V xinet S.5....T c /etc/xinetd.d/echo S.5....T c /etc/xinetd.d/echo-udp S.5....T c /etc/xinetd.d/time S.5....T c /etc/xinetd.d/time-udp 在文件名称前面的参数说明 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（文件的创建时间已被改变） [root@test RPM]# rpm -ql crontabs   <==查找 crontabs 有哪些文件？ /etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly /etc/crontab [root@test RPM]# rpm -V crontabs    <==这些文件有哪些已经被修改了？ S.5....T c /etc/crontab

　
例如上面的范例中，我们知道了 crontabs 有五个文件或目录，其中，如果验证一下的话，就会发现 /etc/crotab 已经被改过了?那么如果该文件的变更是『预期中的』，那么就没有什么大问题，但是如果该文件是『非预期的』，那么是否被入侵了呢？呵呵！得注意注意啰！
　


---

• 反安装与重建数据库：

反安装就是将套件卸载啦！要注意的是，『解安装的过程一定要由最上层往下解除』，以 rp-pppoe 为例，这一个套件主要是依据 ppp 这个套件来安装的，所以当您要解除 ppp 的时候，就必须要先解除 rp-pppoe 才行！否则就会发生结构上的问题啦！这个可以由建筑物来说明，如果你要拆除五、六楼，那么当然要由六楼拆起，否则拆了第五楼，那么上面的楼层难道会悬空？
　
那么重建数据库呢？由于我们会一直在修改一些文件内容，例如 /etc/xinetd.d 里头的参数文件，加上可能自系统操作的过程中添加、移除等等的动作，导致系统的数据库有点乱，这个时候可以使用 --rebuilddb 来重建一下 rpm 的数据库！这两个方法的参数如下啰
　

[root @test /root]# rpm -e re-pppoe  <==解安装 rp-pppoe  [root @test /root]# rpm --rebuilddb  <==重建数据库

Tarball 套件管理员：

还记得我们使用过的打包指令 tar 吗？使用 tar 并且以 gzip 进行压缩的文件，就称为 Tarball 啦！这个是最原始的原代码文件喔！底下谈一谈他啰！
　


---

• 什么是 Tarball ( source code )

其实 tarball 就是以 *.tar.gz 压缩之后的 binary 源文件啦！还记得 tar 怎么使用吗？记得回去第二篇瞧一瞧去！由于软件开发商为了适应各种工作平台，所以通常他们都会将整个软件以较庞大的源文件案创建下来，里头除了(1)最重要的原代码之外，另外包含了(2)针对各个不同的平台编译与操作参数而订定的侦测与参数设置档，然后将这些东西以 tar 这个汇整压缩软件将整个软件下的目录压缩成一个文件，由于是经过类似打包压缩的动作，嘿嘿！那就是所谓的 tarball 啰！因此，当您看到一个 tarball 的文件，不要怀疑，里头通常是包含了原代码的！
　
刚刚说 tarball 可以适应在各个不同的平台上面，那么他是怎么办到的呢？因为各个平台的操作环境都不相同呐！嗯！为了要让用户便于安装，所以通常软件开发者会写一支小 scripts 来侦测用户的系统，以及侦测该软件所需要的前驱软件是否存在你的 Linux 环境中，以便利于后续的编译过程与安装步骤！利用这样的一个 script 几乎就可以完整的创建起基本的参数设置档了。基本上，如果前驱软件都已经安装完毕，那么使用 tarball 几乎『一定可以安装成功』的，而且安装上面也不麻烦，大多只要运行三~四个步骤即可安装完毕！而且，用户『可以自行设置安装的路径』，以便于管理。
　
不过， tarball 在另一方面有个相当严重的困扰，那就是反安装的部分。在 RPM 上面的反安装是蛮简单的一件事，只要克服了属性相依的问题之后，要反安装只要下达 rpm –e package 即可！但是 tarball 可没有这么简单呢！因为他并没有纪录当初安装文件的数据库，所以，要反安装的时候，可能需要一个文件一个文件的手动去除?嗄?这么麻烦？那么有没有什么方法可以比较容易管理呢？有呀！就是利用安装在特定的目录下的方式来管理，就会比较清楚一点！而且也会比较容易未来进行主机的移交作业?通常我们会给您这样的建议：
　
1. 最好将 tarball 的原始数据解压缩到 /usr/local/src 当中；
2. 安装时，最好安装到 /usr/local 这个缺省路径下；
3. 考虑未来的反安装步骤，最好可以将每个套件单独的安装在 /usr/local 底下，例如安装 rp-pppoe-2.6.tar.gz 时，则可以指定该套件需要安装于 /usr/local/rp-pppoe 当中，如此一来，如果该套件会将所有的数据都写入 /usr/local/rp-pppoe 当中，因此，未来如果要移除该套件，只要将该目录删除即可视为成功的移除了！
4. 不过单独安装某个套件在某一特定路径下的作法，会导致当有 man page 的时候，使用缺省的 MANPATH 会找不到相关的说明文件内容。这个时候就必须要将 man page 的路径加到 /etc/man.config 文件中了！否则使用 man 也查找不到指令的使用方法的。以上面的例子为例，如果是安装了 /usr/local/rp-pppoe 当中，通常 man page 会放在 /usr/local/rp-pppoe/man 当中，所以，您就必需要在 /etc/man.config 里面差不多 40~50 行左右的地方，加入底下这一行：
MANPATH /usr/local/rp-pppoe/man
这样就可以使用 man 来查找数据啰！
　


---

• Tarball 需要的基础套件

虽然 Tarball 在安装上面可以说『相当的简单』，因为只要顺着解开压缩之后目录里面的 README 或 INSTALL 就可以安装成功了！但是仍然有部分的困扰，例如：如果常常上 BBS 或者是新闻群组讨论区的朋友，应该不难发现这个发问『我在运行某个程序的侦测文件时，他都会告诉我没有 gcc 这个套件，这是怎么回事？』还有：『我没有办法使用 make 耶！这是什么问题？』呵呵！必须要告诉大家的是，使用 tarball 的安装时，『一定』需要几个对象才行！这些对象在 Mandrake 或者是其他的 distribution 时，『缺省都是不选择的』，所以在安装 Linux 的时候，请特别留意选择的类别呢！底下这些东西都是必需的：
 
1. 需要 Kernel sources files：常常一些 Tarball 在安装时，会使用到 Kernel 的源文件案，亦即在 /usr/src/linux 这个目录底下的文件，而该目录是需要安装或者编译过内核才会存在的目录！这个问题最常发生在『驱动程序的安装与编译』方面。所以当您在安装 Linux 的时候没有选择 Kernel source 或者在之后没有编译内核时，呵呵！那么可能就没有办法安装了！

　
2. 需要 make 及 autoconfig 等套件：需要另外注意的就是，我们还需要 make 这个套件才行！除此之外，还有 autoconfig 等等的套件也需要安装才行！ 这两个东西可以让参数设置档( 通常就是 Makefile 这个文件 )顺利的被运行。

　
3. 需要 gcc 或 cc 等编译软件 ( compiler )：如果没有编译的软件，那么自然也就无法将原始代码编译成可以运行的文件啦！所以至少要有一种编译器才行！在 GNU 架构的 Linux 上面，我们通常使用的是 gcc 这个加强功能的 C 语言编译器啦！请注意：除了 gcc 之外，连同上面的 make 等等的套件，几乎都在安装 Linux 的时候的那个 Software Development 咚咚里头！也就是说，若是您当初 安装 的时候，选择的是我建议的那种安装方式的话，那么您的 tarball 安装应该问题不大，若是没有安装的话，那么肯定很多的套件是无法编译成功的！这个时候只好拿出您的原版光盘，一个一个 RPM 套件加入您的 Linux 系统当中吧！ @_@

　
4. 特别留意安装时候的选择工具：由于在安装的时候『缺省选项并没有将 Kernel Development 及 Software Development 加入安装的行列』，所以您如果选择缺省选项的话，呵呵！那么使用 tarball 的工具就会显的力不从心！这一点还请特别特别留意呢！
　


---

• 一般安装步骤：

基本上， tarball 的安装主要就是：
　
1. 将 tarball 在 /usr/local/src 解压缩；
2. 在软件解压缩的路径下创建 Makefile 这个参数设置文件；
3. 以 make 这个程序并使用该目录下的 Makefile 做为他的参数设置档，来进行 make (编译或其他) 的动作；
4. 以 make 这个程序，并以 Makefile 这个参数设置档，依据 install 项目的指定来安装到正确的路径！
　
此外，通常在每个软件的 tarball 中，都会附上 INSTALL 或者是 README 这种文件名的说明档，这些说明档请『务必详细阅读』过一遍，通常这些文件会记录这个软件的安装要求、软件的工作项目、与软件的安装参数设置及技巧等，只要仔细的阅读完这些文件，基本上，要安装好 tarball 的文件，都不会有什么大问题啰?那么那个 make 在干嘛？一般而言， make 会依据 Makefile 这个文件的内容，去运行清除目标档(object file)或者是编译或者是安装的步骤，对于安装 source code 的人来说，这个 make 是相当重要的！在 Makefile 这个文件中，会有一些不同的步骤应该要进行的工作项目，例如 clean, install, compile 等等，而如果要运行清除的步骤，就是 make clean ，安装就下达 make install ，亦即 make 后面接欲进行的工作，那么 make 这个工具就会依据 Makefile 这个文件名的文件去读取相关的步骤消息，而进行该有的动作！
　
OK！我们底下约略提一下大部分的 tarball 软件之安装的指令下达方式：
　
1. ./configure ：这个步骤就是在创建 Makefile 这的文件啰！通常程序开发者会写一支 scripts 来检查您的 Linux 系统、相关的套件属性等等，这个步骤相当的重要，因为未来您的安装信息都是这一步骤内完成的！另外，这个步骤的相关信息应该要参考一下该目录下的 README 或 INSTALL 相关的文件！！基本上，这个步骤完成之后会创建（或修改）一个 Makefile ，这就是参数档啦！

　
2. make clean：make 会读取 Makefile 中关于 clean 的工作。这个步骤不一定会有，但是希望运行一下！为什么呢？因为在进行编译的时候，会产生一些 *.o 的文件，例如有个 abc.c 的原代码，经过编译后会变成 abc.o 的文件！我们称这些文件为 object file ，这些文件如果之前已经编译过并留下来的话，那么这次再编译的时候，就不会编译该文件，然而由于我们可能已经修改了部分的参数，因此该文件的编译结果事实上应该会有所不同！因此，为了避免前一次留下来的数据可能影响到这次编译的结果，所以通常可以进行一下这个步骤啰！

　
3. make：make 会依据 Makefile 当中的缺省工作进行编译的行为！编译的工作主要是进行 gcc 来将原代码编译成为可以被运行的 object files ，但是这些 object files 通常还需要一些函数库之类的 link 后，才能产生一个完整的运行档！使用 make 就是要将原代码编译成为可以被运行的可运行档，而这个可运行档会放置在目前所在的目录之下，尚未被安装到预定安装的目录中；

　
4. make install：通常这就是最后的安装步骤了，make 会依据 Makefile 这个文件里面关于 install 的项目，将上一个步骤所编译完成的数据给他安装到预定的目录中，就完成安装啦！

　
5. 特别留意：请注意，上面的步骤是一步一步来进行的，而其中只要一个步骤无法成功，那么后续的步骤就完全没有办法进行的！因此，要确定每一的步骤都是成功的才可以！举个例子来说，万一今天你在 ./configure 就不成功了，那么就表示 Makefile 无法被创建起来，要知道，后面的步骤都是根据 Makefile 来进行的，既然无法创建 Makefile ，后续的步骤当然无法成功啰！另外，如果在 make 无法成功的话，那就表示源文件案无法被编译成可运行档，那么 make install 主要是将编译完成的文件给他安装下去的，既然都没有成功的运行档了，怎么进行安装？所以啰，要每一个步骤都正确无误才能往下继续做！此外，如果安装成功，并且是安装在独立的一个目录中，例如 /usr/local/packages 这个目录中好了，那么您就必需手动的将这个套件的 man page 给他放到 /etc/man.config 里面去，设置的方法如前面提到的一般所示。
　


---

• Tarball 的移除与升级：

再来就要谈到恼人的 tarball 的移除跟升级了?Tarball的移除难易度跟(1)当初设置参数档时候的安装目录与(2)这个套件本身要求的文件放置目录有关。如果我们以 apache 这个软件来说明的话( 您的系统不见得有装 )，那么如果您以 RPM 的安装方式来安装时，会发现他的文件放在哪里呢？大多是放在：
　
• /etc/httpd
• /usr/lib
• /usr/bin
• /usr/share/man
　
我们会发现他大致上是摆在 etc, lib, man, bin 等目录当中，分别代表『设置、函数库、在线说明档、运行档』，一个套件通常会将他的内容分为这四个目录来放置，好了，那么你是以 tarball 来安装时呢？如果是放在缺省的 /usr/local 里面，由于 /usr/local 原本就缺省这几个目录了，所以你的数据就会被放在：
　
• /usr/local/etc
• /usr/local/bin
• /usr/local/lib
• /usr/local/man
　
但是如果你每个套件都选择在这个缺省的路径下安装的话，那么所有的套件的文件都将放置在这四个目录当中，因此，如果你都安装在这个目录下的话，那么未来在想要升级或移除的时候，就会比较难以追查文件的来源啰?而如果您在安装的时候选择的是单独的目录，例如 /usr/local/apache 的话，那么您的文件目录就会变成：
　
/usr/local/apache/etc
/usr/local/apache/bin
/usr/local/apache/lib
/usr/local/apache/man
　
呵呵呵呵！自己的文件都在同一个目录之下，那么要移除就简单的多了！只要将该目录移除即可视为该套件已经被移除啰?当然啰，实际安装的时候还是得视该软件的 Makefile 里头的 install 信息才能知道到底他的安装情况为何的?
　
移除的方法是这样，那么升级呢？唉?升级有的时候也是很困扰啦！怎么说呢？我们还是以 apache 来说明好了，如果您安装的时候是使用 PHP + Apache + MySQL 的方式来安装的，那么每个套件在安装的时候『都有一定的顺序与进程！』因为他们三者之间具有相关性，所以安装时必需要三者同时考虑到他们的函数库与相关的编译参数。那么如果今天我只要升级 PHP 呢？有的时候因为只有涉及动态函数库的升级，那么我只要升级 PHP 即可！其他的部分或许影响不大。但是如果今天 PHP 需要重新编译的模块比较多，那么可能会连带的，连 Apache 这个程序也需要重新编译过才行?阿！真是有点给他头痛的?没办法啦！使用 tarball 确实有他的优点啦，但是在这方面，确实也有他一定的伤脑筋程度? @_@

要选择 RPM 还是 Tarball？

优先选择 RPM：
这一直是个有趣的问题：『如果我要升级的话，或者是全新安装一个新的套件，那么该选择 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 一个一个的安装，包括新套件的相依套件！ ^_^ .....我是不会这么做的啦！ ）

简易方法：
所以这个时候 Tarball 的方式就特别适合您的安装了！这是因为 Tarball 可以自行设置编译时的参数，此外，也可以自行设置『安装路径』，相当的适合于想要安装『多个不同版本的同一个套件』的情况！这是怎么说呢？！由于 RPM 必须要配合系统里面其他的相依属性的套件，所以基本上，他的安装路径（就是每个文件的放置路径）理论上是放死的，就是不能随意的改变他的安装路径，因此，当有两个不同版本的相同套件想要测试的时候，大概一定就得将原先的版本移除之后，才能安装使用先的版本啰！（此外，由于相依的套件几乎都已经包含在 tarball 当中了，所以安装上面其实并不难啦！）

然而 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 来安装，轻松又惬意！

函数库数据： ldconfig, ldd,

什么是函数库呢？由于我们使用的 Linux 是一个相当不算小的操作系统，里头的数据可是相当多的，然而有些运行程序所使用的系统资源都是相同的，例如登录的时候不论 ftp, ssh, telnet 都需要使用到 pam 模块，那么是不是所有的运行程序都需要将 pam 的数据写入程序当中呢？当然不需要了！因为系统本身就已经有 pam 了呀！那么如何使用这些系统提供的信息呢？呵呵！这个时候动态的函数库就不可或缺了！同时，需要特别留意的是，有相当多的函数库都是『根据 kernel 的版本来设置的』，所以不同版本的 kernel 最好不要随意的互相更换呦！容易造成很多运行程序无法使用其函数库，而挂点的情况发生的！底下我们来谈一谈怎么获得函数库的数据！

---

• ldconfig

　

[root @test /root]# ldconfig [-f conf] [-C cache] [-p] 参数说明： -f conf ：使用 conf 作为 libarary 函数库的取得，而不以 /etc/ld.so.conf 为默认值 -C cache：使用 cache 作为缓存暂存的函数库数据，而不以 /etc/ld.so.cache 为默认值 -p　　　：列出目前有的所有函数库数据内容（在 /etc/ld.so.cache 内的数据！） 范例： [root @test /root]# ldconfig -p 333 libs found in cache `/etc/ld.so.cache'         libz.so.1 (libc6) => /usr/lib/libz.so.1         libz.so (libc6) => /usr/lib/libz.so         libxsltbreakpoint.so.1 (libc6) => /usr/lib/libxsltbreakpoint.so.1         libxslt.so.1 (libc6) => /usr/lib/libxslt.so.1         libxrx.so.6 (libc6) => /usr/X11R6/lib/libxrx.so.6         libxrx.so (libc6) => /usr/X11R6/lib/libxrx.so ........ [root @test /root]# more /etc/ld.so.conf /usr/kerberos/lib /usr/X11R6/lib [root @test /root]# ldconfig  <==以 /etc/ld.so.conf 的内容进行函数库的重建（ /etc/ld.so.cache ）

说明：
系统缺省的函数库都是由 ldconfig 设置后写入 /etc/ld.so.cache 当中！然后供系统来读取使用！那么您如何知道目前的函数库有多少呢？呵呵！使用 ldconfig 就可以知道啦！以 ldconfig -p 可以列出 /etc/ld.so.cache 的内容呢！那么 /etc/ld.so.conf 又是什么呢？！很简单，那就是『目前你的系统中主要的函数库放置的目录』，以上式为例，则主要的 XFree86 函数库放置在 /usr/X11R6/lib 当中，另外还有常用的 kerberos 的函数库也摆在其中！如果您的其他函数库需要写入系统中，让系统可以很快的找到该函数库而予以取用的话，那么将你所安装的套件（通常是 tarball 的套件）所产生的 lib 目录，给他写到 /etc/ld.so.conf 这个文件中，然后再以 ldconfig 重新创建 /etc/ld.so.cache 即可！

---

• ldd

　

[root @test /root]# ldd [-vdr] [filename] 参数说明： -v ：列出所有内容信息； -d ：重新将数据有遗失的 link 点秀出来！ -r ：将 ELF 有关的错误内容秀出来！ 范例： [root @test /root]# cd /lib [root @test /lib]# ldd libdb.so         libc.so.6 => /lib/libc.so.6 (0x400ae000)         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) [root @test /lib]# ldd -v libdb.so         libc.so.6 => /lib/libc.so.6 (0x400ae000)         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)         Version information:         ./libdb.so:                 libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6                 libc.so.6 (GLIBC_2.1) => /lib/libc.so.6                 libc.so.6 (GLIBC_2.2) => /lib/libc.so.6                 libc.so.6 (GLIBC_2.0) => /lib/libc.so.6         /lib/libc.so.6:                 ld-linux.so.2 (GLIBC_2.1.1) => /lib/ld-linux.so.2                 ld-linux.so.2 (GLIBC_2.2.3) => /lib/ld-linux.so.2                 ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2                 ld-linux.so.2 (GLIBC_2.2) => /lib/ld-linux.so.2                 ld-linux.so.2 (GLIBC_2.0) => /lib/ld-linux.so.2

说明：
如果您常常升级安装 RPM 的套件时，应该常常会发现那个『相依属性』的问题吧！？没错！我们可以先以 ldd 来视察『相依函数库』之间的相关性！以先取得了解！例如上面的例子中，我们检查了 libc.so 这个在 /lib 当中的函数库，结果发现他其实还跟 libc.so.6 有关呢！也与 ld-linux.so.2 有关说！所以我们就需要来了解一下，那个文件到底是什么套件的函数库呀！？使用 -v 这个参数还可以得知该函数库来自于哪一个套件！像上面的数据中，就可以得到该 libc.so.6 其实可以支持 GLIBC_2.1.1 等的版本！

检验软件正确性

在我们的 Linux 系统当中，为了怕系统商（ distribution ）推出的文件被修改过，因此都会有所谓的 MD5 的软件指纹验证功能！例如在南台湾最大的 ftp 学术网站 中山大学的 ftp 网站 里头的 Red Hat 7.3 这个可开机光盘的完整套件，在该目录底下，除了完整的的可开机光盘的镜像档(image)之外，还会附上一个文件名为 MD5SUM 的文件，这个文件的内容有点像这样：
　

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 c9a4d963a49e384e10dec9c2bd49ad73  valhalla-SRPMS-disc1.iso 41b03d068e84d2a17147aa27e704f79b  valhalla-SRPMS-disc2.iso cb91810ce8173039fed24420407e4c59  valhalla-i386-disc1.iso ec1b813d32ffdc8edc2be261735d17de  valhalla-i386-disc2.iso 5dc81ce523cfddf99b4d4d63e91bcaa7  valhalla-i386-disc3.iso -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8z/oCIZGAzdtCpg4RAsMvAJ9+xOn4Pw1T0mp8zVT64cEDWuqqKwCfblTd 4Lw0SvJC+v/6JbGIxJWL7aA= =0xs+ -----END PGP SIGNATURE-----

　
这说明的是，『在 valhalla-i386-disc1.iso 这个文件中，有个 MD5SUM 的文件指纹表，如果该文件是原本开发厂商提供的文件时（没有被修改过！），则以 md5sum 这支程序进行检验时，会得到左边的指纹表！』那有什么用呢？！呵呵！用途可大了，前一阵子不是常常发现有些免费的软件被利用来作为收集用户的电子邮件、常上网站数据，及其他用户私人的信息吗？嘿嘿！那就是利用软件的特性来『偷』用户的咚咚，那么万一 Red Hat 提供的光盘镜像档(image)被下载之后，让有心人士偷偷修改过，再转到 Internet 上面流传，那么你下载的这个文件偏偏不是原厂提供的，呵呵！你能保证该文件的内容完全没有问题吗？！当然不能对不对？！是的，这个时候就有 md5sum 这个文件指纹的咚咚出现啦！说说他的用法吧！

---

• md5sum

　

[root @test /root]# md5sum [-bct] filename [root @test /root]# md5sum [--status|--warn] --check filename 参数说明： -b ：使用 binary 的读档方式，缺省为 Windows/DOS 文件型态的读取方式； -c ：检验 md5sum 文件指纹； -t ：以文本型态来读取 md5sum 的文件指纹。 范例： [root @test /root]# md5sum -t logfile.sh　　　　　<==使用文本型态来检验文件的 md5 2a6da1ba121c7a83496fa2afc3e522bb  logfile.sh　　　<==显示出的这个文件的 md5 内容 [root @test /root]# echo testing >> logfile.sh　　<==改变一下文件内容看看； [root @test /root]# md5sum -t logfile.sh　　　　　<==再检查一下 dc39058c7acbad49fbd13946407c2152  logfile.sh　　　<==嘿嘿！密码的内容不一样了！！ [root @test /root]# md5sum --status --check logfile.sh <==看此文件有无 md5sum 的指纹创建 md5sum: logfile.sh: no properly formatted MD5 checksum lines found 因为这个文件是我自己创建的，并没有写入任何的 md5 数据，所以....

说明：
一般而言，每个系统里面的文件内容大概都不相同，例如你的系统中的 /etc/passwd 这个登录信息档与我的一定不一样，因为我们的用户与密码、 Shell 及家目录等大概都不相同，所以由 md5sum 这个文件指纹分析程序所自行计算出来的指纹表当然就不相同啰！以上面的例子来说明，当原本的 logfile.sh 被改变之后，在经由 md5sum 计算一次，嘿嘿！指纹改变了～～这说明了我们的文件被修改过了，与原先的内容不相同啰！
好了，那么如何使用这个东西呢？基本上，您必须要为您的这些重要的文件进行指纹数据库的创建（好像在做户口调查！），将底下这些文件创建数据库：
　
• /etc/passwd
• /etc/shadow（假如你不让用户改密码了）
• /etc/group
• /usr/bin/passwd
• /sbin/portmap
• /bin/login （这个也很容易被骇！）
• /bin/ls
• /bin/ps
• /usr/bin/top
　
等等，这几个文件最容易被修改了！因为很多木马程序运行的时候，还是会有所谓的『运行序, PID』为了怕被 root 追查出来，所以他们都会修改这些检查调度的文件，如果你可以替这些文件创建指纹数据库（就是使用 md5sum 检查一次，将该文件指纹记录下来，然后常常以 shell script 的方式由程序自行来检查指纹表是否不同了！），那么对于文件系统会比较安全啦！！

网络资源

刚刚最前面说过了，套件升级最主要的考量就是『安全性』啦！所以请随时注意安全性方面的问题！目前国内的主要安全网站为：『台湾网络危机处理小组』这个组织，请随时注意上面发布的新闻！另外，如果跟鸟哥一样使用的是 Red Hat 的 distrubution 的话，那么 Red Hat 的 Errata 网页则不可不光临！好啦！底下列出几个 RPM 相关的网页与 Red Hat 的 Errata 网页提供大家参考啰！

• RPM 包装文件管理程序：http://www.study-area.org/tips/rpm.htm
• 中文 RPM HOW-TO：http://www.linux.org.tw/CLDP/RPM-HOWTO.html
• RPM 的使用：http://linux.tnc.edu.tw/techdoc/rpm-howto.htm
• 大家来作 RPM ：http://freebsd.ntu.edu.tw/bsd/4/3/2/29.html
• 一本 RPM 的原文书：http://linux.tnc.edu.tw/techdoc/maximum-rpm/rpmbook/
• Red Hat 的 Errata 网页：https://#/apps/support/errata/