这真是一个很有趣的课题，为何需要升级套件？如果我的机器运作的好好的，那么我干嘛需要升级？通常我们升级的原因主要有三个：在上面的需求当中，尤其需要注意的是第二点，当一个套件有安全上的顾虑时，千万不要怀疑，赶紧更新套件吧！否则造成网络危机，那可不是闹着玩的?那么更新的方法有哪些呢？其实，目前在 Linux 里面有相当多的不同的更新套件的方式，包括了 Red Hat 发展的 RPM 与 up2date 的在线更新模式； Debian 这个 distribution 里头使用的 dpkg 方法；Sun Unix 上面使用的 pkg 升级方式；目前越来越流行的 apt 在线更新模式；还有原始码里头最常使用的 Tarball 编译方法等等，如果要一个一个说明的话那也太累人了?所以，这里我们以目前在 Mandrake, Red Hat, OpenLinux 等 Linux distributions 内常见的 RPM 与 Tarball 的套件升级方式来进行说明：
- 需要新的功能，但旧有主机并没有，所以需要安装新的套件；
- 旧版本的套件上面可能有安全上的顾虑，所以需要更新到新版的套件；
- 旧版的套件执行效能不彰，或者执行的能力不能让管理者满足。
- RPM
目前使用最广泛的套件管理程序之一，利用数据库管理的方式来进行套件的安装，具有相当容易的操作接口，而且套件查询验证的功能相当强大，不过麻烦的地方在于他的属性相依的问题；这两种方法是各有优缺点啦，我们这里想要来谈一谈 RPM 与 Tarball 的安装方式了！
- Tarball
直接以原始码( source code )经过编译后，进行安装。在安装上面具有较大的灵活度，可以随时更改使用者喜好的参数。但是需要其它的套件协助，例如 gcc compiler, kernel-header, make 套件等等，并且在反安装上面具有一定程度的困难度；
| xxxxxxxxx.rpm
<==RPM 的格式，已经包装完成的 rpm 档案；
xxxxx.src.rpm <==SRPM的格式，包含为编译的原始码信息。 |
| rp-pppoe
- 2.6
- 5
. i386
.rpm
第一个部分是套件名称 这是套件的版本信息 这是释出版本的次数 这是适合的硬件平台 附文件名而已 |
| [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 |
| [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 <==直接覆盖掉被修改过的问题档案 |
| [root @test
/root]# rpm -Uvh rp-pppoe-2.6-5.i386.rpm
[root @test /root]# rpm -Fvh *.rpm <==所有在你 Linux 主机上面安装过的套件才升级 |
| 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 -V rp-pppoe <==单纯检查
rp-pppoe 这个已安装套件的档案内容与原先是否相同
[root @test /root]# rpm -Va <==检查所有的 /var/lib/rpm 底下的数据库与 Linux 系统下是否相同的档案！ 范例：
在文件名称前面的参数说明
[root@test RPM]#
rpm -ql crontabs <==查询 crontabs 有哪些档案？
|
| [root @test
/root]# rpm -e re-pppoe <==解安装
rp-pppoe
[root @test /root]# rpm --rebuilddb <==重建数据库 |
优先选择 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 底下）那么追踪反安装的路径就很烦人；所以说，RPM 与 Tarball 各有其优缺点，不过，如果有 RPM 的话，那么优先权还是在于 RPM 安装上面，毕竟管理上比较便利，但是如果套件的架构差异性太大，或者是无法解决相依属性的问题，那么与其花大把的时间与精力在解决属性相依的问题上，还不如直接以 tarball 来安装，轻松又惬意！
- 在线查询：
如果您的安装路径是在 /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 环境变量的方式将该路径加进去啦！确实是比较麻烦的啦！
- 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: SHA1c9a4d963a49e384e10dec9c2bd49ad73 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.orgiD8DBQE8z/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 网页：http://www.redhat.com/apps/support/errata/