這真是一個很有趣的課題，為何需要升級套件？如果我的機器運作的好好的，那麼我幹嘛需要升級？通常我們升級的原因主要有三個：在上面的需求當中，尤其需要注意的是第二點，當一個套件有安全上的顧慮時，千萬不要懷疑，趕緊更新套件吧！否則造成網路危機，那可不是鬧著玩的?那麼更新的方法有哪些呢？其實，目前在 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/