Linux的RPM与Tarball套件管理工具_Linux教程

为何需要升级套件

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

　　·需要新的功能，但旧有主机并没有，所以需要安装新的套件;

　　·旧版本的套件上面可能有安全上的顾虑，所以需要更新到新版的套件;

　　·旧版的套件执行效能不彰，或者执行的能力不能让管理者满足。

　　在上面的需求当中，尤其需要注意的是第二点，当一个套件有安全上的顾虑时，千万不要怀疑，赶紧更新套件吧!否则造成网路危机，那可不是闹着玩的?那么更新的方法有哪些呢?其实，目前在 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 上面!因此，这样可以发现他的缺点是：

　　3.安装的环境必须与打包时的环境需求一致或相当;

　　4.需要满足套件的相依属性需求;

　　5.反安装时需要特别小心，最底层的套件不可先移除，否则可能造成整个系统的问题!

　　那怎么办?呵呵!还好，还有 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 第一个部分是套件名称这是套件的版本资讯 这是释出版本的次数 这是适合的硬体平台附档名而已

　　这样子可以很清楚的发现该套件的名称、版本资讯、打包次数与操作的硬体平台!好了，来谈一谈每个不同的地方吧：

　　o套件名称：当然就是每一个套件的名称了!

　　o版本资讯：每一次更新版本就需要有一个版本的资讯，否则如何知道这一版是新是旧?这里通常又分为主版本跟次版本，反正版本很多啦!

　　o释出版本次数：也就是编译的次数啦!那么为何需要重复的编译呢?这是由于同一版的套件中，可能由于有某些 bug 或者是安全上的顾虑，所以必须要重新设定当初打包时候的设定参数，设定完成之后重新编译并打包成 RPM 档案!因此就有不同的打包数出现了!

　　o操作硬体平台：这是个很好玩的地方，由于 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 的机器，但是 i386 则不一定可以使用于 586 或者是 686 的硬体上面，另外，在 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 里头去看一看呦：

　　o/usr/src/RPM/SPEC：这个目录当中放置的是该套件的设定档，例如这个套件的资讯参数、设定项目等等都放置在这里;

　　o/usr/src/RPM/SOURCE：这个目录当中放置的是该套件的原始档(*.tar.gz的档案)以及 config 这个设定档;

　　o/usr/src/RPM/BUILD：在编译的过程中，有些暂存的资料都会放置在这个目录当中;

　　o/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 的套件时，这些套件通常会使用到底下的目录：

　　o /etc 一些设定档放置的目录，例如 /etc/samba

　　o /usr/bin 一些可执行档案

　　o /usr/lib 一些程式使用的动态函式库

　　o /usr/share/doc 一些基本的软体使用手册与说明档

　　o /usr/share/man 一些 man page 档案

　　底下我们先针对 RPM 的相关指令来进行说明啰!

　　·RPM 的指令使用：安裝、升級與更新、查詢、驗證、反安裝與重建資料庫

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

　　o安装：

　　从无到有就是安装啦!那么安装的方式为何呢?若是 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 <==直接覆盖掉被修改过的问题档案

　　o升级：

　　使用 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 来将您的系统内曾安装过的套件进行修补与升级!(真是方便呀!)

　　o 查询：

　　查询也是 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 <== 查询这个套件里面有多少的档案内容存在

　　o

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

　　rpm -qa | grep pakagename 来选择出适当的套件!

　　若使用 -qi 则可以了解这个套件的主要资讯!

　　§ 寻找套件档案：常常我们忘记一个套件内容含有的档案时，可以使用 -ql 来查询该套件，会列出相当多的档案呦!

　　§ 由档案寻找套件：这是最长发生的问题，就是您『误砍』了某个档案，偏偏不知道他是哪一个套件的，呵呵!那么你可以请跟你同样系统的朋友，使用 -qf 来查询该档案所属的套件，然后重新安装该套件就可以就回来啦!

　　o 验证：

　　验证的功能主要在于提供系统管理员一个有用的管理机制!作用的方式是『使用 /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 已经被改过了?那么如果该档案的变更是『预期中的』，那么就没有什么大问题，但是如果该档案是『非预期的』，那么是否被入侵了呢?呵呵!得注意注意啰!

　　o 反安装与重建资料库：

　　反安装就是将套件解除安装啦!要注意的是，『解安装的过程一定要由最上层往下解除』，以 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 软体之安装的指令下达方式：

　　5../configure ：这个步骤就是在建立 Makefile 这的档案啰!通常程式开发者会写一支 scripts 来检查您的 Linux 系统、相关的套件属性等等，这个步骤相当的重要，因为未来您的安装资讯都是这一步骤内完成的!另外，这个步骤的相关资讯应该要参考一下该目录下的 README 或 INSTALL 相关的档案!!基本上，这个步骤完成之后会建立(或修改)一个 Makefile ，这就是参数档啦!

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

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

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

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

　　·Tarball 的移除与升级：

　　再来就要谈到恼人的 tarball 的移除跟升级了?Tarball的移除难易度跟(1)当初设定参数档时候的安装目录与(2)这个套件本身要求的档案放置目录有关。如果我们以 apache 这个软体来说明的话( 您的系统不见得有装 )，那么如果您以 RPM 的安装方式来安装时，会发现他的档案放在哪里呢?大多是放在：

　　o /etc/httpd

　　o /usr/lib

　　o /usr/bin

　　o /usr/share/man

　　我们会发现他大致上是摆在 etc, lib, man, bin 等目录当中，分别代表『设定、函式库、线上说明档、执行档』，一个套件通常会将他的内容分为这四个目录来放置，好了，那么你是以 tarball 来安装时呢?如果是放在预设的 /usr/local 里面，由于 /usr/local 原本就预设这几个目录了，所以你的资料就会被放在：

　　o /usr/local/etc

　　o /usr/local/bin

　　o /usr/local/lib

　　o /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 计算一次，嘿嘿!指纹改变了～～这说明了我们的档案被修改过了，与原先的内容不相同啰!

　　好了，那么如何使用这个东西呢?基本上，您必须要为您的这些重要的档案进行指纹资料库的建立(好象在做户口调查!)，将底下这些档案建立资料库：

　　o /etc/passwd

　　o /etc/shadow(假如你不让使用者改密码了)

　　o /etc/group

　　o /usr/bin/passwd

　　o /sbin/portmap

　　o /bin/login (这个也很容易被骇!)

　　o /bin/ls

　　o /bin/ps

　　o /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 网页：http://www.redhat.com/apps/support/errata/