鳥哥私房菜 - 第十八章、RPM 與 Tarball 套件管理員

為何需要升級套件
RPM 套件管理程式

什麼是 RPM 、 SRPM ？
什麼是 i386, i586, i686, noarch ？
SRPM 與 RPM 所需要的安裝目錄
RPM 的指令使用：

安裝
升級與更新
查詢
驗證
反安裝與重建資料庫

Tarball 管理方法

什麼是 Tarball ( source code )
Tarball 需要的基礎套件
Tarball 安裝的基本步驟
Tarball 的移除與升級

要選擇 RPM 還是 Tarball？
函式庫資料： ldconfig, ldd
檢驗軟體正確性： md5sum
網路資源

為何需要升級套件

這真是一個很有趣的課題，為何需要升級套件？如果我的機器運作的好好的，那麼我幹嘛需要升級？通常我們升級的原因主要有三個：

需要新的功能，但舊有主機並沒有，所以需要安裝新的套件；

舊版本的套件上面可能有安全上的顧慮，所以需要更新到新版的套件；

舊版的套件執行效能不彰，或者執行的能力不能讓管理者滿足。

在上面的需求當中，尤其需要注意的是第二點，當一個套件有安全上的顧慮時，千萬不要懷疑，趕緊更新套件吧！否則造成網路危機，那可不是鬧著玩的?那麼更新的方法有哪些呢？其實，目前在 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 、 SRPM ？

RedHat Package Manager

由於已經編譯完成並且打包完畢，所以安裝上很方便；
由於套件的資訊都已經記錄在 Linux 主機的資料庫上，很方便查詢、升級與反安裝；

安裝的環境必須與打包時的環境需求一致或相當；
需要滿足套件的相依屬性需求；
反安裝時需要特別小心，最底層的套件不可先移除，否則可能造成整個系統的問題！

通常 SRPM 的附檔名是 ****.src.rpm 這一種檔案格式

什麼是 i386, i586, i686, noarch

xxxxxxxxx.rpm 　<==RPM 的格式，已經包裝完成的 rpm 檔案；
xxxxx.src.rpm 　<==SRPM的格式，包含為編譯的原始碼資訊。

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：就是沒有任何硬體等級上的限制。

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.... 等等的次目錄。

RPM 的安裝過程：

/etc 一些設定檔放置的目錄，例如 /etc/samba
/usr/bin 一些可執行檔案
/usr/lib 一些程式使用的動態函式庫
/usr/share/doc 一些基本的軟體使用手冊與說明檔
/usr/share/man 一些 man page 檔案

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

--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 則是『僅升級在您的系統裡面存在的套件』，所以有的朋友在大量的進行套件版本修補的時候，他們都是這樣做的：

先到各發展商的 errata 網站上捉下來最新的 i386 檔案；
使用 -Fvh 來將您的系統內曾安裝過的套件進行修補與升級！（真是方便呀！）

查詢：

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

反安裝與重建資料庫：

[root @test /root]# rpm -e re-pppoe <==解安裝 rp-pppoe
[root @test /root]# rpm --rebuilddb <==重建資料庫

Tarball 套件管理員：

tar

gzip

什麼是 Tarball ( source code )

tar

(1)最重要的原始碼

(2)針對各個不同的平台編譯與操作參數而訂定的偵測與參數設定檔

最好將 tarball 的原始資料解壓縮到 /usr/local/src 當中；
安裝時，最好安裝到 /usr/local 這個預設路徑下；
考慮未來的反安裝步驟，最好可以將每個套件單獨的安裝在 /usr/local 底下，例如安裝 rp-pppoe-2.6.tar.gz 時，則可以指定該套件需要安裝於 /usr/local/rp-pppoe 當中，如此一來，如果該套件會將所有的資料都寫入 /usr/local/rp-pppoe 當中，因此，未來如果要移除該套件，只要將該目錄刪除即可視為成功的移除了！
不過單獨安裝某個套件在某一特定路徑下的作法，會導致當有 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 需要的基礎套件

需要 Kernel sources files：常常一些 Tarball 在安裝時，會使用到 Kernel 的原始檔案，亦即在 /usr/src/linux 這個目錄底下的檔案，而該目錄是需要安裝或者編譯過核心才會存在的目錄！這個問題最常發生在『驅動程式的安裝與編譯』方面。所以當您在安裝 Linux 的時候沒有選擇 Kernel source 或者在之後沒有編譯核心時，呵呵！那麼可能就沒有辦法安裝了！

需要 make 及 autoconfig 等套件：需要另外注意的就是，我們還需要 make 這個套件才行！除此之外，還有 autoconfig 等等的套件也需要安裝才行！這兩個東西可以讓參數設定檔( 通常就是 Makefile 這個檔案 )順利的被執行。

需要 gcc 或 cc 等編譯軟體 ( compiler )：如果沒有編譯的軟體，那麼自然也就無法將原始程式碼編譯成可以執行的檔案啦！所以至少要有一種編譯器才行！在 GNU 架構的 Linux 上面，我們通常使用的是 gcc 這個加強功能的 C 語言編譯器啦！請注意：除了 gcc 之外，連同上面的 make 等等的套件，幾乎都在安裝 Linux 的時候的那個 Software Development 咚咚裡頭！也就是說，若是您當初安裝的時候，選擇的是我建議的那種安裝方式的話，那麼您的 tarball 安裝應該問題不大，若是沒有安裝的話，那麼肯定很多的套件是無法編譯成功的！這個時候只好拿出您的原版光碟，一個一個 RPM 套件加入您的 Linux 系統當中吧！ @_@

特別留意安裝時候的選擇工具：由於在安裝的時候『預設選項並沒有將 Kernel Development 及 Software Development 加入安裝的行列』，所以您如果選擇預設選項的話，呵呵！那麼使用 tarball 的工具就會顯的力不從心！這一點還請特別特別留意呢！

一般安裝步驟：

基本上， tarball 的安裝主要就是：

將 tarball 在 /usr/local/src 解壓縮；
在軟體解壓縮的路徑下建立 Makefile 這個參數設定檔案；
以 make 這個程式並使用該目錄下的 Makefile 做為他的參數設定檔，來進行 make (編譯或其他) 的動作；
以 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 軟體之安裝的指令下達方式：

./configure ：這個步驟就是在建立 Makefile 這的檔案囉！通常程式開發者會寫一支 scripts 來檢查您的 Linux 系統、相關的套件屬性等等，這個步驟相當的重要，因為未來您的安裝資訊都是這一步驟內完成的！另外，這個步驟的相關資訊應該要參考一下該目錄下的 README 或 INSTALL 相關的檔案！！基本上，這個步驟完成之後會建立（或修改）一個 Makefile ，這就是參數檔啦！

make clean：make 會讀取 Makefile 中關於 clean 的工作。這個步驟不一定會有，但是希望執行一下！為什麼呢？因為在進行編譯的時候，會產生一些 *.o 的檔案，例如有個 abc.c 的原始碼，經過編譯後會變成 abc.o 的檔案！我們稱這些檔案為 object file ，這些檔案如果之前已經編譯過並留下來的話，那麼這次再編譯的時候，就不會編譯該檔案，然而由於我們可能已經修改了部分的參數，因此該檔案的編譯結果事實上應該會有所不同！因此，為了避免前一次留下來的資料可能影響到這次編譯的結果，所以通常可以進行一下這個步驟囉！

make：make 會依據 Makefile 當中的預設工作進行編譯的行為！編譯的工作主要是進行 gcc 來將原始碼編譯成為可以被執行的 object files ，但是這些 object files 通常還需要一些函式庫之類的 link 後，才能產生一個完整的執行檔！使用 make 就是要將原始碼編譯成為可以被執行的可執行檔，而這個可執行檔會放置在目前所在的目錄之下，尚未被安裝到預定安裝的目錄中；

make install：通常這就是最後的安裝步驟了，make 會依據 Makefile 這個檔案裡面關於 install 的項目，將上一個步驟所編譯完成的資料給他安裝到預定的目錄中，就完成安裝啦！

特別留意：請注意，上面的步驟是一步一步來進行的，而其中只要一個步驟無法成功，那麼後續的步驟就完全沒有辦法進行的！因此，要確定每一的步驟都是成功的才可以！舉個例子來說，萬一今天你在 ./configure 就不成功了，那麼就表示 Makefile 無法被建立起來，要知道，後面的步驟都是根據 Makefile 來進行的，既然無法建立 Makefile ，後續的步驟當然無法成功囉！另外，如果在 make 無法成功的話，那就表示原始檔案無法被編譯成可執行檔，那麼 make install 主要是將編譯完成的檔案給他安裝下去的，既然都沒有成功的執行檔了，怎麼進行安裝？所以囉，要每一個步驟都正確無誤才能往下繼續做！此外，如果安裝成功，並且是安裝在獨立的一個目錄中，例如 /usr/local/packages 這個目錄中好了，那麼您就必需手動的將這個套件的 man page 給他放到 /etc/man.config 裡面去，設定的方法如前面提到的一般所示。

Tarball 的移除與升級：

/etc/httpd
/usr/lib
/usr/bin
/usr/share/man

/usr/local/etc
/usr/local/bin
/usr/local/lib
/usr/local/man

/usr/local/apache/etc

/usr/local/apache/bin

/usr/local/apache/lib

/usr/local/apache/man

要選擇 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 網頁：http://www.redhat.com/apps/support/errata/

修改歷史：

2002/08/21：第一次完成
2003/02/11：重新編排與加入 FAQ
2004/04/10：已經更新至新版內容，這個網頁將不再維護！

Linux 基礎學習篇 - Mandrake 9

第十八章、RPM 與 Tarball 套件管理員 - for Mandrake 9