Linux 基礎學習篇 - Mandrake 9

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

鳥哥的第一本書籍的主要內容,內容稍微與書籍不太一樣了!

最近更新時間: 2003/02/11

鳥哥的第一本書大約是在 2002 年的年底左右出版的,內容幾乎都是 Linux 基礎學習,一點也沒有談到伺服器的部份!這也是後來的雛型! 不過內容錯誤的地方很多,導致在 2003 年的年底推出了『基礎學習篇增訂版』的內容,大致上就是處理掉一些比較有嚴重錯誤的部份。 不過,因為 Linux 的版本變化非常快速,因此,寫完了這些文件之後,鳥哥還是持續在網站上更新文件內容,導致原本書籍內容的資料與網站資料差異太大! 這個問題直到鳥哥在 2008 年左右才發現!糟糕了!舊版的文件資料已經遺失~覺得相當扼腕~

因此,在底下的文件內容與當初的書籍內容雖然大同小異,不過章節的編排卻是有所不同!再花時間去一個一個處理,似乎也不太符合成本效益! 鳥哥僅是想要將自己以前的文件記錄下來而已,同時將過時的 big5 編碼改回 utf8 編碼,再加上可以支援 RWD 的樣式而已啦! 內容已經不多做編排~因此,如果內容文件你看不懂,那也是應該的! ^_^

建議您前往本站查詢最新版本的 Linux distribution 文章來閱讀,比較不會浪費時間。最新文章請前往鳥站首頁查閱囉!

為何需要升級套件

這真是一個很有趣的課題,為何需要升級套件?如果我的機器運作的好好的,那麼我幹嘛需要升級?通常我們升級的原因主要有三個:
  • 需要新的功能,但舊有主機並沒有,所以需要安裝新的套件;
  • 舊版本的套件上面可能有安全上的顧慮,所以需要更新到新版的套件;
  • 舊版的套件執行效能不彰,或者執行的能力不能讓管理者滿足。
在上面的需求當中,尤其需要注意的是第二點,當一個套件有安全上的顧慮時,千萬不要懷疑,趕緊更新套件吧!否則造成網路危機,那可不是鬧著玩的?那麼更新的方法有哪些呢?其實,目前在 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 上面!因此,這樣可以發現他的缺點是:
     
    1. 安裝的環境必須與打包時的環境需求一致或相當;
    2. 需要滿足套件的相依屬性需求;
    3. 反安裝時需要特別小心,最底層的套件不可先移除,否則可能造成整個系統的問題!
     
    那怎麼辦?呵呵!還好,還有 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
    第一個部分是套件名稱 這是套件的版本資訊 這是釋出版本的次數 這是適合的硬體平台 附檔名而已 
     
    這樣子可以很清楚的發現該套件的名稱、版本資訊、打包次數與操作的硬體平台!好了,來談一談每個不同的地方吧:
     
    • 套件名稱:當然就是每一個套件的名稱了!
     
    • 版本資訊:每一次更新版本就需要有一個版本的資訊,否則如何知道這一版是新是舊?這裡通常又分為主版本跟次版本,反正版本很多啦!
     
    • 釋出版本次數:也就是編譯的次數啦!那麼為何需要重複的編譯呢?這是由於同一版的套件中,可能由於有某些 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:就是沒有任何硬體等級上的限制。
      需要額外說明的是, i386 的檔案可以在任何的機器上面安裝,不論是 586 或者是 686 的機器,但是 i686 則不一定可以使用於 586 或者是 386 的硬體上面,另外,在 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 裡頭去看一看呦:
     
    • /usr/src/RPM/SPEC:這個目錄當中放置的是該套件的設定檔,例如這個套件的資訊參數、設定項目等等都放置在這裡;
    • /usr/src/RPM/SOURCE:這個目錄當中放置的是該套件的原始檔(*.tar.gz的檔案)以及 config 這個設定檔;
    • /usr/src/RPM/BUILD:在編譯的過程中,有些暫存的資料都會放置在這個目錄當中;
    • /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 的套件時,這些套件通常會使用到底下的目錄:
     
    •   /etc    一些設定檔放置的目錄,例如 /etc/samba
    •   /usr/bin   一些可執行檔案
    •   /usr/lib   一些程式使用的動態函式庫
    •   /usr/share/doc  一些基本的軟體使用手冊與說明檔
    •   /usr/share/man  一些 man page 檔案
     
    底下我們先針對 RPM 的相關指令來進行說明囉!


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

  • RPM 提供了『安裝』、『升級與更新』、『查詢』、『驗證』、『反安裝與重建資料庫』等功能,底下我們一個一個來說明吧!

    • 安裝:

    • 從無到有就是安裝啦!那麼安裝的方式為何呢?若是 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 <==直接覆蓋掉被修改過的問題檔案
         

    • 升級

    • 使用 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 來將您的系統內曾安裝過的套件進行修補與升級!(真是方便呀!)
       

    • 查詢

    • 查詢也是 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  <== 查詢這個套件裡面有多少的檔案內容存在

       
      • 查詢套件:查詢安裝過的套件可以使用 -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

       
      例如上面的範例中,我們知道了 crontabs 有五個檔案或目錄,其中,如果驗證一下的話,就會發現 /etc/crotab 已經被改過了?那麼如果該檔案的變更是『預期中的』,那麼就沒有什麼大問題,但是如果該檔案是『非預期的』,那麼是否被入侵了呢?呵呵!得注意注意囉!
       

    • 反安裝與重建資料庫:

    • 反安裝就是將套件解除安裝啦!要注意的是,『解安裝的過程一定要由最上層往下解除』,以 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 行左右的地方,加入底下這一行:
      1. 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.  
    3. 需要 make 及 autoconfig 等套件:需要另外注意的就是,我們還需要 make 這個套件才行!除此之外,還有 autoconfig 等等的套件也需要安裝才行! 這兩個東西可以讓參數設定檔( 通常就是 Makefile 這個檔案 )順利的被執行。

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

    6.  
    7. 特別留意安裝時候的選擇工具:由於在安裝的時候『預設選項並沒有將 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 軟體之安裝的指令下達方式:
     
    1. ./configure :這個步驟就是在建立 Makefile 這的檔案囉!通常程式開發者會寫一支 scripts 來檢查您的 Linux 系統、相關的套件屬性等等,這個步驟相當的重要,因為未來您的安裝資訊都是這一步驟內完成的!另外,這個步驟的相關資訊應該要參考一下該目錄下的 README 或 INSTALL 相關的檔案!!基本上,這個步驟完成之後會建立(或修改)一個 Makefile ,這就是參數檔啦!

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

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

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

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

  • Tarball 的移除與升級:

  • 再來就要談到惱人的 tarball 的移除跟升級了?Tarball的移除難易度跟(1)當初設定參數檔時候的安裝目錄與(2)這個套件本身要求的檔案放置目錄有關。如果我們以 apache 這個軟體來說明的話( 您的系統不見得有裝 ),那麼如果您以 RPM 的安裝方式來安裝時,會發現他的檔案放在哪裡呢?大多是放在:
     
    • /etc/httpd
    • /usr/lib
    • /usr/bin
    • /usr/share/man
     
    我們會發現他大致上是擺在 etc, lib, man, bin 等目錄當中,分別代表『設定、函式庫、線上說明檔、執行檔』,一個套件通常會將他的內容分為這四個目錄來放置,好了,那麼你是以 tarball 來安裝時呢?如果是放在預設的 /usr/local 裡面,由於 /usr/local 原本就預設這幾個目錄了,所以你的資料就會被放在:
     
    • /usr/local/etc
    • /usr/local/bin
    • /usr/local/lib
    • /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 計算一次,嘿嘿!指紋改變了~~這說明了我們的檔案被修改過了,與原先的內容不相同囉!
    好了,那麼如何使用這個東西呢?基本上,您必須要為您的這些重要的檔案進行指紋資料庫的建立(好像在做戶口調查!),將底下這些檔案建立資料庫:
     
    • /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 網頁提供大家參考囉!
修改歷史:
  • 2002/08/21:第一次完成
  • 2003/02/11:重新編排與加入 FAQ
  • 2004/04/10:已經更新至新版內容,這個網頁將不再維護!
伺服器篇文件
各版本彙整說明
CentOS 6.x