Linux的RPM与Tarball套件管理工具(3)

出处:台湾省Linux社区　

 

要选择 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 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 包装档案管理程式：
·中文 RPM HOW-TO：
·RPM 的使用：
·大家来作 RPM ：
·一本 RPM 的原文书：
·Red Hat 的 Errata 网页：