## 22.1 軟件管理員簡介 在前一章我們提到以源代碼的方式來安裝軟件，也就是利用廠商釋出的 Tarball 來進行軟件的安裝。不過，你應該很容易發現，那就是每次安裝軟件都需要偵測操作系統與環境、設置編譯參數、實際的編譯、 最后還要依據個人喜好的方式來安裝軟件到定位。這過程是真的很麻煩的，而且對于不熟整個系統的朋友來說，還真是累人啊！ 那有沒有想過，如果我的 Linux 系統與廠商的系統一模一樣，那么在廠商的系統上面編譯出來的可執行文件， 自然也就可以在我的系統上面跑啰！也就是說，廠商先在他們的系統上面編譯好了我們使用者所需要的軟件， 然后將這個編譯好的可執行的軟件直接釋出給使用者來安裝，如此一來，由于我們本來就使用廠商的 Linux distribution ，所以當然系統 （硬件與操作系統） 是一樣的，那么使用廠商提供的編譯過的可可執行文件就沒有問題啦！ 說的比較白話一些，那就是利用類似 Windows 的安裝方式，由程序開發者直接在已知的系統上面編譯好，再將該程序直接給使用者來安裝，如此而已。 那么如果在安裝的時候還可以加上一些與這些程序相關的信息，將他創建成為數據庫，那不就可以進行安裝、反安裝、 升級與驗證等等的相關功能啰 （類似 Windows 下面的“新增移除程序”）？確實如此，在 Linux 上面至少就有兩種常見的這方面的軟件管理員，分別是 RPM 與 Debian 的 dpkg 。我們的 CentOS 主要是以 RPM 為主，但也不能不知道 dpkg 啦！所以下面就來約略介紹一下這兩個玩意兒。 ### 22.1.1 Linux 界的兩大主流: RPM 與 DPKG 由于自由軟件的蓬勃發展，加上大型 Unix-Like 主機的強大性能，讓很多軟件開發者將他們的軟件使用 Tarball 來釋出。 后來 Linux 發展起來后，由一些企業或社群將這些軟件收集起來制作成為 distributions 以發布這好用的 Linux 操作系統。但后來發現到，這些 distribution 的軟件管理實在傷腦筋， 如果軟件有漏洞時，又該如何修補呢？使用 tarball 的方式來管理嗎？又常常不曉得到底我們安裝過了哪些程序？ 因此，一些社群與企業就開始思考 Linux 的軟件管理方式。 如同剛剛談過的方式，Linux 開發商先在固定的硬件平臺與操作系統平臺上面將需要安裝或升級的軟件編譯好， 然后將這個軟件的所有相關文件打包成為一個特殊格式的文件，在這個軟件文件內還包含了預先偵測系統與相依軟件的腳本， 并提供記載該軟件提供的所有文件信息等。最終將這個軟件文件釋出。用戶端取得這個文件后，只要通過特定的指令來安裝， 那么該軟件文件就會依照內部的腳本來偵測相依的前驅軟件是否存在，若安裝的環境符合需求，那就會開始安裝， 安裝完成后還會將該軟件的信息寫入軟件管理機制中，以達成未來可以進行升級、移除等動作呢。 目前在 Linux 界軟件安裝方式最常見的有兩種，分別是： * dpkg： 這個機制最早是由 Debian Linux 社群所開發出來的，通過 dpkg 的機制， Debian 提供的軟件就能夠簡單的安裝起來，同時還能提供安裝后的軟件信息，實在非常不錯。 只要是衍生于 Debian 的其他 Linux distributions 大多使用 dpkg 這個機制來管理軟件的， 包括 B2D, Ubuntu 等等。 * RPM： 這個機制最早是由 Red Hat 這家公司開發出來的，后來實在很好用，因此很多 distributions 就使用這個機制來作為軟件安裝的管理方式。包括 Fedora, CentOS, SuSE 等等知名的開發商都是用這咚咚。 如前所述，不論 dpkg/rpm 這些機制或多或少都會有軟件屬性相依的問題，那該如何解決呢？ 其實前面不是談到過每個軟件文件都有提供相依屬性的檢查嗎？那么如果我們將相依屬性的數據做成列表， 等到實際軟件安裝時，若發生有相依屬性的軟件狀況時，例如安裝 A 需要先安裝 B 與 C ，而安裝 B 則需要安裝 D 與 E 時，那么當你要安裝 A ，通過相依屬性列表，管理機制自動去取得 B, C, D, E 來同時安裝， 不就解決了屬性相依的問題嗎？ 沒錯！您真聰明！目前新的 Linux 開發商都有提供這樣的“線上升級”機制，通過這個機制， 原版光盤就只有第一次安裝時需要用到而已，其他時候只要有網絡，你就能夠取得原本開發商所提供的任何軟件了呢！ 在 dpkg 管理機制上就開發出 APT 的線上升級機制，RPM 則依開發商的不同，有 Red Hat 系統的 yum ， SuSE 系統的 Yast Online Update （YOU） 等。 | distribution 代表 | 軟件管理機制 | 使用指令 | 線上升級機制（指令） | | --- | --- | | Red Hat/Fedora | RPM | rpm, rpmbuild | YUM （yum） | | Debian/Ubuntu | DPKG | dpkg | APT （apt-get） | 我們這里使用的是 CentOS 系統嘛！所以說：使用的軟件管理機制為 RPM 機制，而用來作為線上升級的方式則為 yum ！下面就讓我們來談談 RPM 與 YUM 的相關說明吧！ ### 22.1.2 什么是 RPM 與 SRPM RPM 全名是“ RedHat Package Manager ”簡稱則為 RPM 啦！顧名思義，當初這個軟件管理的機制是由 Red Hat 這家公司發展出來的。 RPM 是以一種數據庫記錄的方式來將你所需要的軟件安裝到你的 Linux 系統的一套管理機制。 他最大的特點就是將你要安裝的軟件先編譯過， 并且打包成為 RPM 機制的包裝文件，通過包裝好的軟件里頭默認的數據庫記錄， 記錄這個軟件要安裝的時候必須具備的相依屬性軟件，當安裝在你的 Linux 主機時， RPM 會先依照軟件里頭的數據查詢 Linux 主機的相依屬性軟件是否滿足， 若滿足則予以安裝，若不滿足則不予安裝。那么安裝的時候就將該軟件的信息整個寫入 RPM 的數據庫中，以便未來的查詢、驗證與反安裝！這樣一來的優點是： 1. 由于已經編譯完成并且打包完畢，所以軟件傳輸與安裝上很方便 （不需要再重新編譯）； 2. 由于軟件的信息都已經記錄在 Linux 主機的數據庫上，很方便查詢、升級與反安裝 但是這也造成些許的困擾。由于 RPM 文件是已經包裝好的數據，也就是說， 里面的數據已經都“編譯完成”了！所以，該軟件文件幾乎只能安裝在原本默認的硬件與操作系統版本中。 也就是說，你的主機系統環境必須要與當初創建這個軟件文件的主機環境相同才行！ 舉例來說，rp-pppoe 這個 ADSL 撥接軟件，他必須要在 ppp 這個軟件存在的環境下才能進行安裝！如果你的主機并沒有 ppp 這個軟件，那么很抱歉，除非你先安裝 ppp 否則 rp-pppoe 就是不讓你安裝的 （當然你可以強制安裝，但是通常都會有點問題發生就是了！）。 所以，通常不同的 distribution 所釋出的 RPM 文件，并不能用在其他的 distributions 上。舉例來說，Red Hat 釋出的 RPM 文件，通常無法直接在 SuSE 上面進行安裝的。更有甚者，相同 distribution 的不同版本之間也無法互通，例如 CentOS 6.x 的 RPM 文件就無法直接套用在 CentOS 7.x ！因此，這樣可以發現這些軟件管理機制的問題是： 1. 軟件文件安裝的環境必須與打包時的環境需求一致或相當； 2. 需要滿足軟件的相依屬性需求； 3. 反安裝時需要特別小心，最底層的軟件不可先移除，否則可能造成整個系統的問題！ 那怎么辦？如果我真的想要安裝其他 distributions 提供的好用的 RPM 軟件文件時？ 呵呵！還好，還有 SRPM 這個東西！SRPM 是什么呢？顧名思義，他是 Source RPM 的意思，也就是這個 RPM 文件里面含有源代碼哩！特別注意的是，這個 SRPM 所提供的軟件內容“并沒有經過編譯”， 它提供的是源代碼喔！ 通常 SRPM 的擴展名是以 ***.src.rpm 這種格式來命名的。不過，既然 SRPM 提供的是源代碼，那么為什么我們不使用 Tarball 直接來安裝就好了？這是因為 SRPM 雖然內容是源代碼， 但是他仍然含有該軟件所需要的相依性軟件說明、以及所有 RPM 文件所提供的數據。同時，他與 RPM 不同的是，他也提供了參數配置文件 （就是 configure 與 makefile）。所以，如果我們下載的是 SRPM ，那么要安裝該軟件時，你就必須要： * 先將該軟件以 RPM 管理的方式編譯，此時 SRPM 會被編譯成為 RPM 文件； * 然后將編譯完成的 RPM 文件安裝到 Linux 系統當中 怪了，怎么 SRPM 這么麻煩吶！還要重新編譯一次，那么我們直接使用 RPM 來安裝不就好了？通常一個軟件在釋出的時候，都會同時釋出該軟件的 RPM 與 SRPM 。我們現在知道 RPM 文件必須要在相同的 Linux 環境下才能夠安裝，而 SRPM 既然是源代碼的格式，自然我們就可以通過修改 SRPM 內的參數配置文件，然后重新編譯產生能適合我們 Linux 環境的 RPM 文件，如此一來，不就可以將該軟件安裝到我們的系統當中，而不必與原作者打包的 Linux 環境相同了？這就是 SRPM 的用處了！ | 文件格式 | 文件名格式 | 直接安裝與否 | 內含程序類型 | 可否修改參數并編譯 | | --- | --- | | RPM | xxx.rpm | 可 | 已編譯 | 不可 | | SRPM | xxx.src.rpm | 不可 | 未編譯之源代碼 | 可 |  **Tips** 為何說 CentOS 是“社群維護的企業版”呢？ Red Hat 公司的 RHEL 釋出后，連帶會將 SRPM 釋出。 社群的朋友就將這些 SRPM 收集起來并重新編譯成為所需要的軟件，再重復釋出成為 CentOS，所以才能號稱與 Red Hat 的 RHEL 企業版同步啊！真要感謝 SRPM 哩！如果你想要理解 CentOS 是如何編譯一支程序的， 也能夠通過學習 SRPM 內含的編譯參數，來學習的啊！ ### 22.1.3 什么是 i386, i586, i686, noarch, x86_64 從上面的說明，現在我們知道 RPM 與 SRPM 的格式分別為： ``` xxxxxxxxx.rpm <==RPM 的格式，已經經過編譯且包裝完成的 rpm 文件； xxxxx.src.rpm <==SRPM的格式，包含未編譯的源代碼信息。 ``` 那么我們怎么知道這個軟件的版本、適用的平臺、編譯釋出的次數呢？只要通過文件名就可以知道了！例如 rp-pppoe-3.11-5.el7.x86_64.rpm 這的文件的意義為： ``` rp-pppoe - 3.11 - 5 .el7.x86_64 .rpm 軟件名稱 軟件的版本信息 釋出的次數 適合的硬件平臺 擴展名 ``` 除了后面適合的硬件平臺與擴展名外，主要是以“-”來隔開各個部分，這樣子可以很清楚的發現該軟件的名稱、 版本信息、打包次數與操作的硬件平臺！好了，來談一談每個不同的地方吧： * 軟件名稱： 當然就是每一個軟件的名稱了！上面的范例就是 rp-pppoe 。 * 版本信息： 每一次更新版本就需要有一個版本的信息，否則如何知道這一版是新是舊？這里通常又分為主版本跟次版本。以上面為例，主版本為 3 ，在主版本的架構下更動部分源代碼內容，而釋出一個新的版本，就是次版本啦！以上面為例，就是 11 啰！所以版本名就為 3.11 * 釋出版本次數： 通常就是編譯的次數啦！那么為何需要重復的編譯呢？這是由于同一版的軟件中，可能由于有某些 bug 或者是安全上的顧慮，所以必須要進行小幅度的 patch 或重設一些編譯參數。 設置完成之后重新編譯并打包成 RPM 文件！因此就有不同的打包數出現了！ * 操作硬件平臺： 這是個很好玩的地方，由于 RPM 可以適用在不同的操作平臺上，但是不同的平臺設置的參數還是有所差異性！ 并且，我們可以針對比較高階的 CPU 來進行最優化參數的設置，這樣才能夠使用高階 CPU 所帶來的硬件加速功能。 所以就有所謂的 i386, i586, i686, x86_64 與 noarch 等的文件名稱出現了！ ``` | 平臺名稱 | 適合平臺說明 | | --- | --- | | i386 | 幾乎適用于所有的 x86 平臺，不論是舊的 pentum 或者是新的 Intel Core 2 與 K8 系列的 CPU 等等，都可以正常的工作！那個 i 指的是 Intel 相容的 CPU 的意思，至于 386 不用說，就是 CPU 的等級啦！ | | i586 | 就是針對 586 等級的計算機進行最優化編譯。那是哪些 CPU 呢？包括 pentum 第一代 MMX CPU， AMD 的 K5, K6 系列 CPU （socket 7 插腳） 等等的 CPU 都算是這個等級； | | i686 | 在 pentun II 以后的 Intel 系列 CPU ，及 K7 以后等級的 CPU 都屬于這個 686 等級！ 由于目前市面上幾乎僅剩 P-II 以后等級的硬件平臺，因此很多 distributions 都直接釋出這種等級的 RPM 文件。 | | x86_64 | 針對 64 位的 CPU 進行最優化編譯設置，包括 Intel 的 Core 2 以上等級 CPU ，以及 AMD 的 Athlon64 以后等級的 CPU ，都屬于這一類型的硬件平臺。 | | noarch | 就是沒有任何硬件等級上的限制。一般來說，這種類型的 RPM 文件，里面應該沒有 binary program 存在， 較常出現的就是屬于 shell script 方面的軟件。 | ``` 截至目前為止 （2015），就算是舊的個人計算機系統，堪用與能用的設備大概都至少是 Intel Core 2 以上等級的計算機主機，泰半都是 64 位的系統了！ 因此目前 CentOS 7 僅推出 x86_64 的軟件版本，并沒有提供 i686 以下等級的軟件了！如果你的系統還是很老舊的機器， 那才有可能不支持 64 位的 Linux 系統。此外，目前僅存的軟件版本大概也只剩下 i686 及 x86_64 還有不分版本的 noarch 而已， i386 只有在某些很特別的軟件上才看到的到啦！ 受惠于目前 x86 系統的支持方面，新的 CPU 都能夠執行舊型 CPU 所支持的軟件，也就是說硬件方面都可以向下相容的， 因此最低等級的 i386 軟件可以安裝在所有的 x86 硬件平臺上面，不論是 32 位還是 64 位。但是反過來說就不行了。舉例來說，目前硬件大多是 64 位的等級，因此你可以在該硬件上面安裝 x86_64 或 i386 等級的 RPM 軟件。但在你的舊型主機，例如 P-III/P-4 32 位機器上面，就不能夠安裝 x86_64 的軟件！ 根據上面的說明，其實我們只要選擇 i686 版本來安裝在你的 x86 硬件上面就肯定沒問題。但是如果強調性能的話， 還是選擇搭配你的硬件的 RPM 文件吧！畢竟該軟件才有針對你的 CPU 硬件平臺進行過參數最優化的編譯嘛！ ### 22.1.4 RPM 的優點 由于 RPM 是通過預先編譯并打包成為 RPM 文件格式后，再加以安裝的一種方式，并且還能夠進行數據庫的記載。 所以 RPM 有以下的優點： * RPM 內含已經編譯過的程序與配置文件等數據，可以讓使用者免除重新編譯的困擾； * RPM 在被安裝之前，會先檢查系統的硬盤容量、操作系統版本等，可避免文件被錯誤安裝； * RPM 文件本身提供軟件版本信息、相依屬性軟件名稱、軟件用途說明、軟件所含文件等信息，便于了解軟件； * RPM 管理的方式使用數據庫記錄 RPM 文件的相關參數，便于升級、移除、查詢與驗證。 為什么 RPM 在使用上很方便呢？我們前面提過， RPM 這個軟件管理員所處理的軟件，是由軟件提供者在特定的 Linux 作業平臺上面將該軟件編譯完成并且打包好。那使用者只要拿到這個打包好的軟件， 然后將里頭的文件放置到應該要擺放的目錄，不就完成安裝啰？對啦！就是這樣！ 但是有沒有想過，我們在前一章里面提過的，有些軟件是有相關性的，例如要安裝網卡驅動程序，就得要有 kernel source 與 gcc 及 make 等軟件。那么我們的 RPM 軟件是否一定可以安裝完成呢？如果該軟件安裝之后，卻找不到他相關的前驅軟件， 那不是挺麻煩的嗎？因為安裝好的軟件也無法使用啊！ 為了解決這種具有相關性的軟件之間的問題 （就是所謂的軟件相依屬性），RPM 就在提供打包的軟件時，同時加入一些訊息登錄的功能，這些訊息包括軟件的版本、 打包軟件者、相依屬性的其他軟件、本軟件的功能說明、本軟件的所有文件記錄等等，然后在 Linux 系統上面亦創建一個 RPM 軟件數據庫，如此一來，當你要安裝某個以 RPM 型態提供的軟件時，在安裝的過程中， RPM 會去檢驗一下數據庫里面是否已經存在相關的軟件了， 如果數據庫顯示不存在，那么這個 RPM 文件“默認”就不能安裝。呵呵！沒有錯，這個就是 RPM 類型的文件最為人所詬病的“軟件的屬性相依”問題啦！ ### 22.1.5 RPM 屬性相依的克服方式： YUM 線上升級 為了重復利用既有的軟件功能，因此很多軟件都會以函數庫的方式釋出部分功能，以方便其他軟件的調用應用， 例如 PAM 模塊的驗證功能。此外，為了節省使用者的數據量，目前的 distributions 在釋出軟件時， 都會將軟件的內容分為一般使用與開發使用 （development） 兩大類。所以你才會常常看到有類似 pam-x.x.rpm 與 pam-devel-x.x.rpm 之類的文件名啊！而默認情況下，大部分的 software-devel-x.x.rpm 都不會安裝，因為終端用戶大部分不會去開發軟件嘛！ 因為有上述的現象，因此 RPM 軟件文件就會有所謂的屬性相依的問題產生 （其實所有的軟件管理幾乎都有這方面的情況存在）。 那有沒有辦法解決啊？前面不是談到 RPM 軟件文件內部會記錄相依屬性的數據嗎？那想一想，要是我將這些相依屬性的軟件先列表， 在有要安裝軟件需求的時候，先到這個列表去找，同時與系統內已安裝的軟件相比較，沒安裝到的相依軟件就一口氣同時安裝起來， 那不就解決了相依屬性的問題了嗎？有沒有這種機制啊？有啊！那就是 YUM 機制的由來！ CentOS （1）先將釋出的軟件放置到 YUM 服務器內，然后（2）分析這些軟件的相依屬性問題，將軟件內的記錄信息寫下來 （header）。 然后再將這些信息分析后記錄成軟件相關性的清單列表。這些列表數據與軟件所在的本機或網絡位置可以稱呼為容器或軟件倉庫或軟件庫 （repository）。 當用戶端有軟件安裝的需求時，用戶端主機會主動的向網絡上面的 yum 服務器的軟件庫網址下載清單列表， 然后通過清單列表的數據與本機 RPM 數據庫已存在的軟件數據相比較，就能夠一口氣安裝所有需要的具有相依屬性的軟件了。 整個流程可以簡單的如下圖說明： 圖22.1.1、YUM 使用的流程示意圖 **Tips** 所以軟件倉庫內的清單會記載每個文件的相依屬性關系，以及所有文件的網絡位置 （URL）！由于記錄了詳細的軟件網絡位置， 所以有需要的時候，當然就會自動的從網絡下載該軟件啰！ 當用戶端有升級、安裝的需求時， yum 會向軟件庫要求清單的更新，等到清單更新到本機的 /var/cache/yum 里面后， 等一下更新時就會用這個本機清單與本機的 RPM 數據庫進行比較，這樣就知道該下載什么軟件。接下來 yum 會跑到軟件庫服務器 （yum server） 下載所需要的軟件 （因為有記錄軟件所在的網址），然后再通過 RPM 的機制開始安裝軟件啦！這就是整個流程！ 談到最后，還是需要動到 RPM 的啦！所以下個小節就讓我們來談談 RPM 這咚咚吧！  **Tips** 為什么要做出“軟件庫”呢？由于 yum 服務器提供的 RPM 文件內容可能有所差異，舉例來說，原廠釋出的數據有 （1）原版數據； （2）更新數據 （update）； （3）特殊數據 （例如第三方協力軟件，或某些特殊功能的軟件）。 這些軟件文件基本上不會放置到一起，那如何分辨這些軟件功能呢？就用“軟件庫”的概念來處理的啦！ 不同的“軟件庫”網址，可以放置不同的功能的軟件之意！