[法律專欄] 善用自由軟體資訊清單有效降低法律糾紛的風險

[源碼新聞] 帶著台灣開源社群向前邁進的土虱－TOSSUG

[技術專欄] CentOS 基礎設定（下）

前言

在前二篇文章 CentOS 基礎設定（上）以及 CentOS 基礎設定（中），我們學習了 CentOS 主機的基礎設定。這些設定分別是：建立一般使用者帳號以便管理時使用；網路連線設定及連通測試；了解 SELinux 安全增強機制；將遠端允許 root 管理帳號登入的權限移除，以降低 CentOS 主機被密碼暴力測試工具攻擊的機會；了解  CentOS 主機的啟動流程，以及知悉何謂啟動模式等級 RunLevel；建立順手的操作環境 Shell 及檔案編輯器 VIM 環境設定；透過 sudo 建立管理者帳號的使用機制；將套件管理工具 YUM 下載來源由國外重新指向至台灣本地鏡像網站，以便縮短軟體套件及相依套件的下載時間。

本篇文章是 CentOS 基礎設定系列文章的最後一篇。首先要學習的是，當 CentOS 主機安裝設定完成後設定上線運作的方法，使系統定期自動寄送系統的相關記錄，並發至 CentOS 主機管理人員的郵件信箱內。這些相關紀錄包含：主機硬碟空間的使用率、郵件發送情況、網路服務運作狀況等資訊。因此企業中忙碌的 IT 管理人員，每天僅需檢查所收到的系統資訊郵件內容、檢查磁碟空間是否足夠、注意主機有無被攻擊的狀況等，並進行適當的調整即可，而不需要每天手動遠端登入至 CentOS 主機查看相關訊息，以節省寶貴的時間。

接下來學習的是，CentOS 遠端連線 SSH 的基本安全性保護設定，並在主機上線後，將系統時間定時自動與網際網路上的時間伺服器，或者與企業內部自行架設的時間伺服器校對時間。了解系統在進入啟動模式等級 RunLevel 後，會將哪些服務啟動，以及開啟哪些相對應的 Port。同時視系統需求關閉不必要的服務，以減少系統的負載並降低系統被攻擊的機會。最後，則是透過安裝 RPMforge，來增加 YUM 套件管理工具中可安裝的套件數量。

實作環境

* CentOS 5.5  32bit (Kernel 2.6.18-194.el5)
* sendmail-8.13.8-8.el5
* logwatch-7.3-8.el5
* xinetd-2.3.14-10.el5
* tcp_wrappers-7.6-40.7.el5
* pstree (PSmisc) 22.2
* yum-3.2.22-26.el5.centos
* rpmforge-release-0.5.2-2.el5

收集系統資訊後定期寄送給管理人員

當 CentOS 主機安裝、設定完畢並上線運作之後，我們希望主機能夠在固定時間（如每小時、每天、每週、每月）發送相關資訊至主機管理人員清單位址，讓主機管理人員能獲取系統上的服務運作狀態和硬體使用狀況相關資訊。主機的管理人員只要定期查看每台管理主機的資訊郵件內容，即可進行適當的處理，或轉交給相對應的人員接手處理。

CentOS 主機的預設排程為每小時的 01 分、每天凌晨 4 點 02 分、每週日凌晨 4 點 22 分，以及每月 1 號凌晨 4 點 22 分。此時，系統會執行預先撰寫好的自動維護 Shell Script 執行檔，進行系統相關的清理及備份工作，並使用預設的郵件轉送代理 (Mail Transfer Agnet, MTA) Sendmail 寄送資訊郵件。欲使用別的郵件轉送代理像是 Postfix、Qmail 等 ，屆時只要在設定檔內進行指定即可。若讀者有興趣了解系統定期執行的詳細內容，可切換至 /etc 目錄下的四個資料夾，分別是：每小時 (cron.hourly)、每天 (cron.daily)、每週 (cron.weekly)、每月 (cron.monthly)，每個資料夾內都有相關的自動維護 Shell Script ，查看後即可了解系統維護主機的相關內容。

▲ 圖1 查看主機系統排程資訊

在 CentOS 系統中，LogWatch 套件負責收集系統狀態及相關網路服務運作資訊（預設情況下會安裝至系統）。我們可以在每天定期發送的 cron.daily 資料夾中，發現 0logwatch 這隻 Script。也就是說，系統會在每天凌晨 4 點 02 分時，透過此 Script 將系統中系統、硬體、服務的資訊收集後，寄送給各個管理者。接下來便說明相關資訊的設定方法，如：由哪台主機寄出收集後的資訊、寄件對象、系統資訊收集分析的等級、收集主機服務運作的狀態設定等。

我們可以將相關設定值寫入至 LogWatch 設定檔 "/etc/logwatch/conf/logwatch.conf" 內，操作中相關設定值參數及說明如下：

* MailFrom：通常填入此台主機的主機名稱 (Hostname)，或是該主機所擔任的企業服務名稱（如 Web1）。
* MailTo：填入管理者們的郵件信箱 (Email)。若有多筆郵件位址，則使用逗點 (, ) 加上空格進行隔開即可。
* Detail：指定收集主機資訊後分析的等級，共有三種等級可供選擇。分別為低級（Low 或數字 0）、中級（Med 或數字 5）、高級（High 或數字 10）。
* Service：指定收集主機服務運作的項目，LogWatch 支援收集服務的項目為 /usr/share/logwatch/scripts/services 目錄下的服務名稱，您可以使用參數 All 來表示要收集該主機所有運作的服務。若不想分析某個服務，則可於服務名稱前加上減號 ( - )，則系統便會排除收集該項服務的運作狀態。

下列為筆者的 LogWatch 設定檔設定內容，若您需要更詳細的參數設定內容可參考 "/usr/share/logwatch/default.conf/logwatch.conf" 設定檔內容


▲ 圖2 LogWatch 設定檔內容

設定完畢之後，CentOS 主機便會自動於每天凌晨 4 點 02 分時，收集主機資訊後寄送至管理者郵件信箱內。如果您想要立即收到資訊郵件，可以手動執行 logwatch 指令，命令主機立刻收集資訊並寄送郵件，或配合參數 --print 直接顯示收集到的資訊，查看收集到的資訊而不寄送郵件（此資訊和資訊郵件的內容完全相同）。您還可以配合參數 --service ，僅顯示收集的服務名稱運作狀態。


▲ 圖3 logwatch 查看指令以及立即寄送資訊郵件操作

如果您已經設定完成，但並沒有定期收到資訊郵件的話，可以先用 mailq 指令，查看郵件是否被佇列 (Queue) 住。接著，檢查郵件記錄檔 /var/log/maillog 內容以及主機的 DNS 設定，分析並查找管理者沒有定期收到主機所收集資訊郵件的原因。此外，由於系統會在隔一段時間後才送出郵件，若您執行 logwatch 指令寄送郵件時，發現郵件在郵件佇列中而未立即寄出，可執行 sendmail 指令，配合參數 –q，使主機立刻寄出郵件佇列中所有郵件。


▲ 圖4 檢查郵件佇列及查看郵件記錄檔以及立刻寄送郵件出去


▲ 圖5 管理人員收到的每日系統資訊郵件內容

SSH 基礎安全防護設定

在 CentOS 主機中，我們可以利用許多機制來保護主機服務。IPTables 防火牆功能強大，是安全防護選項之一，但本文中並不打算講解有關 IPTables 防火牆設定（若要講解的話得再開一系列文章），而是要介紹另一個設定簡單，有一定保護程度的安全機制 TCP Wrappers 達到保護 SSH 遠端連線服務的效果。此服務與系統內的 xinetd 服務有很深的關聯，下圖便清楚表達了當網路封包進入 CentOS 主機時，Firewall、TCP Wrappers 及 xinetd 服務的封包走向關係圖。


▲ 圖6 圖片來源 CentOS 官方網站 Deployment_Guide - 42.5. TCP Wrappers and xinetd，採用 Open Publication License

預設情況下，TCP Wrappers 在安裝 CentOS 主機過程中便已安裝完成。而顧名思義，此安全防護機制僅能保護 TCP daemon，而無法保護 UDP daemon（仍有例外狀況）。相信您會接著問，那 TCP Wrappers 能夠保護主機上哪些服務項目呢？ 答案是，只要該服務中含有 libwrap 函式庫 (Library)，即可受到 TCP Wrappers 保護。經由下列操作，我們便可了解如何檢查該服務內是否含有 libwrap 函式庫。在圖 7 中，我們可以看到 SSH 服務 (sshd) 含有 libwrap 函式庫，而 Apache 服務 (httpd) 則沒有包含 libwrap 函式庫。所以雖然都是 TCP daemon ，但 TCP Wrappers 可以保護 SSH 服務，而無法保護 Apache 服務。


▲ 圖7 查詢 TCP Wrappers 是否可以保護該服務

接著要說明的是 TCP Wrappers 的保護規則。在安全防護設定上，TCP Wrappers 非常簡單易懂，不像防火牆設定那麼複雜。其安全防護規則採用 First Match 方式，意即先讀取到的規則直接套用執行後，便不需要理會後面的規則。

TCP Wrappers 的防護規則分為 "/etc/hosts.allow" 及 "/etc/hosts.deny" 二個設定檔。這二個設定檔中，首先讀取的設定檔為 hosts.allow，若此設定檔中有設定服務名稱，則允許封包通過，接著讀取 hosts.deny 則為禁止封包通過。筆者建議僅設定 "/etc/hosts.allow" 設定檔便可達到防護效果。

在修改 TCP Wrappers 保護規則設定檔 (/etc/hosts.allow) 以前，我們先了解設定檔的內容及相關參數的意義。設定檔內容可以分成三個小區段來看，分別是「服務名稱 (deamon)、來源 IP 位址或網域名稱 FQDN、連線回應為允許 (allow) 或拒絕 (deny)」。每個小區段之間使用冒號 (:) 作為分隔符號，在前面二個小區段中並支援相關進階參數，使保護規則運作更靈活。但是，若使用 KNOWN、UNKNOWN、PARANOID 參數時，請注意此三個參數是依靠 DNS 名稱解析服務，因此必須要注意主機上的 DNS 名稱解析是否運作正常，相關進階參數說明如下：

* ALL：表示 「全部 」，用於第一個小區段（服務名稱欄位）表示全部服務，用於第二個小區段（連線來源）表示全部的 IP 位址或網域名稱 FQDN。
* LOCAL：表示「本機」，也就是不含點 (.) 的主機名稱例如 localhost。
* KNOWN：表示「可解析主機」，也就是可以解析其 IP 位址及網域名稱 FQDN。
* UNKNOWN：表示「無法解析主機」，也就是無法解析其 IP 位址及網域名稱 FQDN。
* PARANOID：表示「正反解析必須一致」，也就是 DNS 正解（FQDN 解析 IP 位址）及 DNS 反解（IP 位址解析 FQDN）二者的解析記錄必須一致。
* EXCEPT：表示「排除」的意思，例如允許 192.168.1.0 這個網段的所有主機，但排除 192.168.1.99 這個 IP 位址。

在設定之前，還有三個小地方要提醒讀者注意。首先是來源 IP 網段的遮罩設定值，TCP Wrappers 支援的網路遮罩為 255.255.255.0 這種型式，而不是 /24 這種 CIDR 表示方法。若您設定 /24 這種網路遮罩，則該行防護設定規則將無法運作（但若是來源位址使用 IPv6 位址則支援此種表示方法）。第二點要注意的是，修改 TCP Wrappers 設定檔內容後，當您存檔離開的那一剎那，所設定的防護內容便立刻生效（不需要重新啟動或載入 xinetd 服務）。最後要注意的是，防護規則僅套用於「新進 Session」，也就是說，設定阻擋規則時主機上若已經存在有舊的連線 Session，並不會自動斷線離開，而是新進來的 Session 才會阻擋。

CentOS 在預設情況下並不會安裝 xinetd 套件，我們可以透過前一篇介紹的 yum 指令來安裝 xinetd 套件。此次我們以防護主機上的 SSH 服務為例，設定只有允許的 IP 網段可以使用 SSH 遠端登入此台 CentOS 主機（允許連線後接著才進行使用者帳號及密碼驗證），並且拒絕允許的 IP 網段中，其中一台主機的連線要求。最後，其餘的 IP 位址欲嘗試使用 SSH 遠端登入主機時，則拒絕其連線要求。由於已經拒絕連線要求封包，因此主機自然就不需要回應使用者帳號及密碼的驗證動作，此舉能夠有效減低 CentOS 主機被進行密碼暴力測試工具攻擊的機會，提升主機整體安全性。

下列操作步驟包含利用 yum 套件管理工具安裝 xinetd 套件，查看 xinetd 服務是否在 CentOS 主機啟動時自動啟動 xinetd 服務，確認無誤後啟動 xinetd 服務。接著設定 TCP Wrappers 設定檔 (/etc/hosts.allow)，其內容為允許 192.168.1.0 整個 C Class 網段主機 SSH 遠端連線至此台 CentOS 主機，除了 192.168.1.99 禁止連接。最後，其餘 IP 網段若發出 SSH 遠端連線要求時，則直接拒絕該連線封包。


▲ 圖8 安裝 xinetd 套件及設定 TCP Wrappers 安全防護規則

上述 TCP Wrappers 防護規則設定完成後，我們可以進行驗證，檢查剛才設定是否生效。我們由 192.168.1.99 主機對目前 CentOS 主機 (192.168.1.50) 發出 SSH 遠端連線要求，並得到 Connection closed 的連線拒絕回應。在 CentOS 主機上，我們查看 secure 記錄檔也可看到 192.168.1.99 主機嘗試 SSH 遠端連線此台主機，並遭到拒絕連線 (refused connect) 的回應。而 192.168.1.0 網段中的其它主機發出 SSH 連線要求時，則會出現驗證帳號密碼的動作。


▲ 圖9 驗證 TCP Wrappers 防護規則是否生效

經過上述實作驗證後，相信讀者已經了解如何用簡單的 TCP Wrappers 安全防護規則，來保護 CentOS 主機。若您認為 TCP Wrappers 只有這些功能的話，那您就大錯特錯了。TCP Wrappers 支援更進階的安全防護規則內容，例如嘗試連線記錄、結合 Shell 指令等功能。但是在這些進階的防護功能中， 嘗試連線記錄必須要搭配系統的日誌服務 (syslogd) 才得以運作，而結合 Shell 指令功能，除了必須對系統指令有一定程度了解之外，還必須了解如何搭配相關的參數，才得以發揮強大效果。建議有興趣更深入的讀者，可以參考 CentOS 官方文件 Deployment_Guide - 42.5. TCP Wrappers and xinetd 內有進階設定的詳細說明。

 

系統時間自動校對

網路時間協定 NTP (Network Time Protocol) 最初由德拉瓦州大學 (Delaware University) 的大衛米爾斯 (David L. Mills) 所設計，主要目的為透過網路封包交換 (UDP Protocol, Port 123)，將二端電腦的時鐘進行同步校對。若讀者想更詳細了解整個 NTP 協定的規範、實作、分析等詳細內容，請參考 RFC 1305 (NTP version 3)、RFC 5905 (NTP version 4)。

企業營運環境的伺服器為數眾多，倘若伺服器之間的時間不同步，可能會造成許多影響。例如伺服器之間的時間誤差超過 5 分鐘時，則將導致 Kerberos 的驗證失敗；或者，當企業購物平台的前端 AP 伺服器與後端資料庫伺服器時間不同步時，則使用者下單記錄可能在資料庫伺服器上顯示為未來時間，或是優惠活動時間明明已經結束，但使用者仍然可以下單購買，造成客服人員的困擾；再者，公司財務報表產生時，若伺服器之間的時間不同步，則會造成財務報表合併時在核對上出現困擾。以上舉例的種種問題，追究其原因，便是由於眾多伺服器之間時間不同步所造成。

在此次設定中，我們為 CentOS 主機安裝 OpenNTPD 客戶端，來進行系統運作時間校對。OpenNTPD 客戶端與一般的 NTP 客戶端時間校對方式有著明顯的不同，一般 NTP 客戶端的時間校對方式為「強迫性一次調整到位」，也就是不管現在系統時間，一律直接跟 NTP 伺服器校對後調整。偏向暴力性的一次到位調整時間的方式，在某些狀況下可能會對主機運作穩定性上產生問題。而此次安裝的 OpenNTPD 客戶端的時間校對方式為：當 OpenNTPD 客戶端與 NTP 時間伺服器有時間誤差時，OpenNTPD 客戶端會將主機每隔幾分鐘進行系統時間「微調」，慢慢調整，直到最後與時間伺服器上的標準時間達成一致。這樣溫和的時間調整方式，對於要求高穩定性的企業營運環境伺服器來說，相對而言是比較適合的。

在安裝 OpenNTPD 客戶端以前，請您先使用 rpm –qa 指令來確認 CentOS 主機是否已經安裝 gcc 及 make 套件（若系統沒有安裝，請使用 YUM 套件管理工具進行 yum –y install gcc make 安裝指令），以便在安裝 OpenNTPD 套件時能順利進行編譯 (Compile) 與安裝 (make)。在設定前，您可以故意先將 CentOS 主機系統時間調慢 5分鐘，待之後啟動 OpenNTPD 服務後，即可發現系統開始跟 NTP 時間伺服器慢慢進行時間校對。

在 CentOS 預設的 YUM 套件管理工具中，並未收錄 OpenNTPD 軟體套件，因此請自行從 OpenBSD 的鏡像站台下載、解壓縮、編譯，並安裝 OpenNTPD 套件。下列操作步驟為先利用 wget 指令下載 OpenNTPD 套件至 /tmp 資料夾下，並將 OpenNTPD 套件檔案解壓縮後執行 ./configure、make、make install 等指令，將 OpenNTPD 套件編譯並進行安裝。


▲ 圖10 OpenNTPD 套件下載、解壓縮、編譯、安裝

在上述最後執行套件安裝的動作 make install 時，我們可以看到，系統提示我們必須要為系統建立 _ntp 的使用者帳號及群組，以便屆時使用 _ntp 使用者帳號來啟動 OpenNTP 服務，而非使用 root 管理者帳號，以避免安全性問題。因此安裝完畢後，請使用 useradd 及 groupadd 指令，配合相關參數來新增 _ntp 使用者帳號及群組，接著設定 OpenNTPD 設定檔，指向至企業內部所架設的 NTP 伺服器或網際網路上的 NTP 伺服器 IP 位址。接下來如圖11 將 NTP 伺服器指向至國家時間與頻率標準實驗室，進行時間校對。最後，設定 OpenNTPD 記錄檔來記錄主機時間校時的狀況，並在完成後重新載入系統日誌服務 syslogd，讓其變更生效即可。


▲ 圖11 完成 OpenNTPD 客戶端相關設定，並建立記錄檔了解校時狀況

接著將 OpenNTPD 新增至 CentOS 內建的服務清單內，設定當 CentOS 重新開機時能夠自動啟動 OpenNTPD 服務，自動與國家時間與頻率標準實驗室 NTP 伺服器進行時間校對作業。完成設定後即可啟動 OpenNTPD 服務，並透過剛才建立的記錄檔來觀察目前主機與 NTP 伺服器進行時間校對的情況。


▲ 圖12 新增 OpenNTPD 為系統服務並查看主機校時情況

 

查看系統啟動服務及監聽 Port 號

了解系統啟動的服務以及該服務開啟的相應 Port ，也是主機安全防護的基本功。我們可以使用內建的 netstat 指令，配合 –tunpl 參數，顯示系統目前啟動服務及協定等相關資訊。使用到的 5 個參數意義為 t (TCP)、u (UDP)、n（IP 位址及 Port 號）、p（PID 名稱）、l (Listen) 服務，這些指令執行後顯示出來的相關欄位解釋如下：

* Proto：服務運作的協定，通常為 TCP 或 UDP Protocol
* Recv-Q：收到的封包 Bytes 數量
* Send-Q：傳送的封包 Bytes 數量
* Local Address：本地端的 IP 位址及 Port 號
* Foreign Address：遠端主機的 IP 位址及 Port 號
* State：連接狀態，此例中僅顯示 Listen 狀態，實際上還有已建立連線 (ESTABLISHED)、連線結束等待 Socket 關閉 (TIME_WAIT)、主動連線 SYN 封包 (SYN_SENT)、連線要求 SYN 封包 (SYN_RECV)等狀態。
* PID/Program name：該程序 (Process) 的名稱


▲ 圖13 查看主機目前啟動的服務及相對應的 Port 號

透過運用 netstat 指令了解 CentOS 主機執行哪些服務 (daemon)，與開啟哪些 Port 號之後，我們可以進一步透過了解執行序，在系統或服務出現問題後利於除錯。若只是要查詢系統有哪些執行序時，我們可以使用內建的 ps 指令，配合相關參數進行查詢。但若是想要了解執行序的樹狀結構（意即母程序及子程序的樹狀關系）時，內建的 ps 指令可能就略顯不足。此時可以配合 pstree 套件來輔助我們即時了解執行序樹狀結構，例如我們查詢剛才執行的校時程序 ntpd 的執行序樹狀結構，可以看到整個 ntpd 的母程序 PID 為 21815，並且使用 _ntp 使用者帳號負責帶起子程序 PID 21816。

▲ 圖14 查詢 OpenNTPD 服務的執行序樹狀關系

接著我們可以使用 chkconfig 指令，以了解 CentOS 主機在開機時進入不同的 RunLevel 時會啟動的服務。我們以主機所擔任的服務，來判斷是否有些不會用到的服務，例如 acpid (Advanced Configuration and Power Interface) 電源進階設定，這個服務是將 CentOS 安裝於筆記型電腦上才會發揮效用，所以我們就可以將該服務關閉。此舉除了可以增加系統效能（啟動每個服務都會佔用記憶體），還可以避免該服務被攻擊，增加系統安全性。

下列操作為 CentOS 主機預設啟動程序在 RunLevel 3 的狀況下，我們使用指令 chkconfig 指令配合相關參數，來了解系統在 RunLevel 3 時，開機會自動啟動哪些服務：


▲ 圖15 檢查主機於 RunLevel 3 啟動時會啟動哪些服務

當您決定哪些服務要開啟，而哪些服務要關閉後，就可以執行「關閉啟動主機時不啟動服務」或是「停止該服務」。下列操作中，我們以 acpid 服務為例進行設定，當主機由 RunLevel 3 啟動模式啟動時，不會自動啟動該服務，並在目前運作模式下馬上停止該服務的運作：


▲ 圖16 關閉 acpid 於 RunLevel 3 時自動啟動，並立即停止該服務

 

擴充 YUM 套件管理工具 RPM 數量

雖然在上一篇文章中，我們已經將 YUM 套件管理工具的鏡像站台，設定為台灣鏡像站台來加快套件下載速度。不過雖然目前官方的 YUM 套件管理工具中套件數量已經不少，但目前官方套件數量中僅包含必要套件，例如常常用來管理 MySQL 資料庫的 PhpMyAdmin 套件，就未包含在內建的 YUM 套件庫 (RPM Repository) 當中。

雖然我們可以自行下載 PhpMyAdmin 套件並手動安裝到系統上，但筆者個人的主機管理習慣，是盡量使用 YUM 套件管理工具來處理 RPM 套件的安裝、移除、升級。因此在這裡要介紹讀者一套名為 RPM forge 的套件，我們可以安裝它來擴充 YUM 套件管理工具中的套件數量。

RPMforge 支援許多 Linux 發行版本，例如 RHEL、Fedora Core、CentOS、Scientific、Aurora 等。將 RPMforge 安裝於系統之後，可擴充系統 YUM 套件管理工具中的套件數量，例如剛才提到的 PhpMyAdmin 套件。我們可以在安裝 RPMforge 之後，透過 yum 指令來進行安裝，而不需要自行上網尋找該套件。

下列操作中，我們可以看到當系統尚未安裝 RPMforge 以前，其 YUM 管理工具套件庫 (RPM Repository) 中搜尋不到 PhpMyAdmin 套件。當安裝 RPMforge 之後，便可順利透過 yum 指令來進行安裝。每次安裝時，請安裝最新發行穩定版本的 RPMforge-Release，並注意您使用的 CentOS 主機是 32 位元或 64 位元的作業系統版本（本次實作為使用 CentOS 5.5 32 位元版本）：


▲ 圖17 未安裝 RPMforge 以前搜尋不到 PhpMyAdmin 套件


▲ 圖18 安裝 RPMforge 後可順利搜尋到 PhpMyAdmin 套件

 

結語

雖然網路上 Linux 相關參考資源及教學非常多，但筆者發現許多 Linux 初學者可能對於 CentOS 主機的系統基礎設定不熟悉，或者未設置相關設定，導致在學習上發生瓶頸。例如沒有把 YUM 套件管理工具的預設鏡像站台由國外設回國內，因此認為 CentOS 主機套件安裝速度相當緩慢。追究其原因，只是因為未更改鏡像站台至國內，加上所處的網路環境頻寬不是很理想，導致下載套件及相依套件時速度緩慢，而造成使用者的誤會。又或者因為沒有把 SELinux 安全機制暫時關閉，所架設的網路服務因而違反了 SELinux 的安全機制，導致服務啟動時被阻擋住而無法啟動成功。

若因為不熟悉這些設定而放棄學習 CentOS，是非常可惜的一件事。筆者期望能夠透過這三篇 CentOS 基礎設定文章，讓讀者對於 CentOS 作業系統有初步的認識，並在配合相關基礎設定的實作之後，能夠協助讀者建立一個屬於自己，順手好用又安全的 CentOS 作業系統。

[源碼秘技] 用自由軟體 Plone 來架設網站(9)一多媒體結合

允許 HTML 標籤

使用模組展示圖檔

使用模組展示影片

使用模組批次上傳

中文訊息的支援機制

訊息字串的翻譯

結論

[自由專欄] 自由的危機與維基的自由

被誤解的自由維基

維基百科的 Slogan 是「自由的百科全書」，首頁掛著「海納百川，有容乃大」的訓言。這種簡短的口號相當有力，但是也經常導致誤會。在英文裡 Free Software 的 Free 經常被誤解為「免費」而不是「自由」，中文裡的「自由」固然沒有雙關語的困擾，但是也常引發以下的誤會：

誤解一、認為維基百科對任何看法都是可以收納的。此誤解發生在許多新手身上，特別是被自由理念吸引，而亟欲為某些弱勢團體發聲的編者身上。他們經常發生幾種情況，導致編輯被取消或是條目被刪除，最後引起糾紛。這些情況包括：加入沒有可靠來源的資料，並宣稱來源是被「打壓」才無法透過可靠媒介發表；以帶有批判意味的文字撰寫條目，試圖彰顯正義；或是加入自己原創的研究，並宣稱其所做的考證才是真理，可查證的主流說法是以訛傳訛。

誤解二、認為維基百科應該有高度的言論自由。在社群討論的場合可以開啟任何討論話題，提出任何提議。即使這些話題只是煽風點火，無助於百科的編寫，也應該被保留。

誤解三、認為維基百科應該有自由國家裡的一切制度。如要求擁有「民主」表決的權利；或是誤將「方針」與「指引」（這兩項在維基中，可以視為規範）當成法典，要求管理員或社群不得禁止方針或指引中未明文規定的不妥行為，實行所謂的「法治」。有此類誤解的維基人，特別容易對中國大陸出身的管理員產生敵意，將其不在方針規定範圍內的作為解讀為「和諧、獨裁」等等。

事實上，維基百科只是一部百科全書，既不是論壇也不是「民主試驗場」。維基百科的「海納百川」，不意味著可以收納一些極端言論，或是明顯被科學否證的胡言亂語。全面的自由，只會使維基百科成為混亂的論壇空間以及真偽難辨的知識+，形成知識分享的危機。

維基百科的自由

在加入維基百科編寫行列的同時，要正確的體認維基百科的「自由」，才能夠讓這樣一個空間真正發揮它的功能。這些自由包括：

1. 編寫的自由。在維基百科上，「編寫」是自由的，任何人皆可以參與，無需掛上專家的頭銜，甚至連註冊維基帳號都不需要。除此之外，因為 Wiki 是個多人協作的系統，又具強大的歷史版本儲存功能，編寫者的技術門檻極低－很多新手因為不熟悉 wiki 語法而裹足不前，但事實上，新手可以只添加內容、將語法問題留給其他老練的編輯者來補充完成。

2. 使用與分享的自由。維基百科採用的是 CC-BY-SA 3.0 與 GFDL 雙授權，在合乎授權的情況下都可以自由的分享、應用，包括引用內容，甚至商業出版。

理解了維基百科的「自由」所指何物，才能抱著正確的理念進入到維基的社群。在面臨眾人協作過程中難以避免的磨擦時，也才能夠基於維基精神，與其他編者在良好的互動中找出共識。畢竟維基計劃的成功，重視的是團隊戰力，為了無關百科協作的「自由」而產生紛擾，社群為了爭議爭執而不是共同合作，並不是有心貢獻知識的編者所樂見的。

▲ 圖1 香港與中國社群在罷免案中形成嚴重對立（本圖截自 http://zh.wikipedia.org/wiki/File:Shizhao_RFDA7_votelocation_bar.png，原圖版權由作者  Waihorace 採 CC-BY-SA 3.0 授權釋出）

作者簡介

Reke，台灣維基社群成員，PTT 電影板板主，主業為文字工作者。著迷於電影，耽溺於文字；在現實裡怯弱地柔從，在評論裡驕傲地反抗。電影部落格：http://rekegiga.blogspot.com/

[企業應用] 從 Red Hat 變更 RHEL 釋出方式來探討 GPL 對原始碼範圍的定義

筆者發現台灣目前多數開發者及公司，對於 GPL 授權原始碼的定義範圍不甚清楚，結果導致商業模式的情勢錯估，在極端的狀況下，有時後果甚至反而比完全不採用自由／開放源碼軟體進行產品開發的商業策略還要糟。有鑑於此、在本篇文章中，我們可以從 Red Hat 去年 11 月釋出的 RHEL 6 (Red Hat Enterprise Linux 6) 一例中，進行自由／開放源碼軟體商業模式的初步探討，並一窺軟體社群對於 GPL 原始碼範圍寬嚴有別的認知態度。

成功的自由／開放源碼軟體商業模式

根據市場研究機構 Gartner 於 2011 年 4 月 28 日的研究數據顯示，Red Hat 在 2010 年的營收達到 6.1 億美元，比 2009 年還高了 18 個百分點。這無疑地證明了 Red Hat 在採用自由／開放源碼軟體的企業裡，是在商業營利模式上發展良好的一個成功範例。Red Hat 的營利模式主要靠的是訂閱模式 (Subscription Business Model)，也就是說，讓使用者向其購買技術支援、客製化需求與自動化的穩定升級服務等等，來獲取利潤。細部來說，這些服務方式又劃分為電話支援 (Phone Support)、網頁支援 (Web Support) 及事件處理上的持續支援 (Unlimited Incidents)。

然而、成功的案例往往會吸引其他的競爭對手搶食利益的大餅，Red Hat 歷史上的競爭對手中，包括過去同樣善用自由／開放源碼進行商業服務的 Novell（已於 2010 年 11 月 23 日被 Attachmate 公司收購）。因此，為了在此高度競爭的環境下保持獲利，Red Hat 與 Novell 等公司，不約而同地投入了大量的人力，透過主動貢獻相關自由／開放源碼軟體原始碼的方式，以商業模式驅動的態度、將這些程式碼回饋給社群夥伴進行研究和開發。也正因為如此，可以說 RHEL 的成功，有很大一部份是奠基於自由／開放源碼軟體，透過企業團隊與社群夥伴的良性互動，提昇了 RHEL 在執行效能與穩定性方面的表現。而按照 GPL 授權條款的要求，Red Hat 相關的程式改作也必須提供原始碼，並且同樣依照 GPL 律定的授權方式釋出，這當中亦包括了 Linux Kernel 方面的改作。

這樣的雙向回饋系統（社群、商業模式雙贏），初期促進了 CentOS 及 Scientific Linux 發行套件的誕生。這些發行套件直接取用了 Red Hat 釋出的原始碼，並將其中屬於 Red Hat 公司本身著作權的軟體去除後，再重新編譯、整理，最後再行對外散布。就筆者所知，RHEL 中完全屬於 Red Hat 著作之軟體並不多（因為基於 GPL 的互惠性原則，高度相依於 GPL 授權元件的軟體，在後續散布時也必須同樣以 GPL 進行授權。），因此即使在 CentOS 及 Scientific Linux 在去除掉這些程式碼後，仍然保有絕大多數 RHEL 的功能。雖然從表面上來看，CentOS 及 Scientific Linux 這種透過少量自我努力，卻可以贏得多數 RHEL 既成成果的方式，似乎對於 Red Hat 的持續獲利會有某種程度的影響，但其實實際上的效果有限，主因是 CentOS 及 Scientific Linux 兩者皆為社群驅動的發行版本，非屬於營利公司推行的商業版本，所以就市場利益的競合上對 Red Hat 尚無太大的影響。

然而、真正壓垮駱駝的最後一根稻草的不是別人，正是 Red Hat 在商業服務上的長期合作伙伴－Oracle。Oracle 試圖改作 RHEL，並重新發行了屬於自己的 Unbreakable Enterprise Kernel。Oracle 對外宣稱 Unbreakable Enterprise Kernel 完全相容於 RHEL、但執行效能更快，並且對於 Oracle 其他軟體服務方案的支援亦更好。從道德層面來說 Oracle 的作法不無爭議，但從 GPL 授權條款方面來看，其對於 RHEL 中以 GPL 授權的部份，確實具有合法的改作以及再散布的權利。那麼、面對 Oracle 這樣來勢洶洶的直接挑戰與威脅，Red Hat 就一個營利公司的本位，亦不得不調整作法，設立出新版原始碼釋出的「保護政策」。在 RHEL 5 以前，Red Hat 對於 Linux Kernel 相關的原始碼皆是採用獨立原始碼修正 (Diff Patch) 的方式釋出，此種方式的好處，是讓開發者可以方便知道該改作的功能、目的及範圍，所以、對於像 Oracle 這種搭便車 (Free Rider) 的商業公司，也可以很方便的得知哪部分是他想要的，哪部分是他所不需要的，很快的就可以根據 RHEL 這些程式原始碼，重新改作散布其自己的商業發行版本。

於是在商業模式受到 Oracle 刻意衝擊之後，Red Hat 從 RHEL 6 開始，採用了較不便利後手修改的「保護政策」，其將 Linux Kernel 相關的原始碼改採「完整源碼」的方式釋出，不再延用原始碼修正 (Diff Patch) 的作法，也不再以獨立修正的檔案呈現。這樣的方式雖然令搭便車的人不再方便利用，但也同時讓社群開發者難以快速得知 RHEL 新版本的改作功能、目的及範圍！

讀者有興趣的話，可以參照下列的方法來自行感受 RHEL 5 與 RHEL 6 前後的差異。

首先下載 RHEL 5 的 Linux Kernel 原始碼包，下載位址於 http://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/kernel-2.6.18-92.el5.src.rpm。

及 RHEL 6 的 Linux Kernel 原始碼包，下載位址於 http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/kernel-2.6.32-71.el6.src.rpm。

在 Linux/BSD 下解開此兩個檔案還需要額外安裝 rpm2cpio 軟體，在 Debian/Ubuntu 的讀者，可以使用 apt-get 或 Synaptic 圖形化的安裝介面，下述範例為使用 apt-get 指令列的安裝方式：


▲ 圖1 以 apt-get 指令在 Debian/Ubuntu下安裝 rpm2cpio

安裝完成後，可以直接對該兩個 Linux Kernel 原始碼包解壓縮。


▲ 圖2 輸入指令解壓縮 Linux Kernel 的原始碼

解壓縮完成後，即可看到兩者的差異，例如 RHEL 5 的 Linux Kernel 原始碼包資料夾解壓縮後顯示如下。


▲ 圖3 RHEL 5 的 Linux Kernel 原始碼包解壓後顯示圖

這是 RHEL 6 的 Linux Kernel 原始碼包資料夾，


▲ 圖4 RHEL 6 的 Linux Kernel 原始碼包解壓後顯示圖

其中的 linux-2.6.32-71.el6.tar.bz2 就是之前稱的「完整源碼」，對這個檔案再次解壓縮後，呈現為以下的圖示。


▲ 圖5 RHEL 6 內 Linux Kernel 「完整源碼」解壓後目錄結構顯示圖


從 RHEL 6 的保護政策探究軟體社群對於 GPL 原始碼範圍的認知態度

不可諱言的，許多自由／開放源碼軟體的社群開發者，對於 Red Hat 改採的「原始碼保護政策」不滿，認為這樣的行為違反了 GPL-2.0 授權條款對於原始碼範圍的要求。然而、是否這樣的行為嚴格違反了 GPL-2.0 定義範圍，其實不同的評論者有著寬嚴不同的解釋與看法，因為在 GPL-2.0 授權條款中對於原始碼的定義為：

"The source code for a work means the preferred form of the work for making modifications to it."

這中間存在一個爭議點，那就是對於何謂 "Preferred Form" 的定義界限，產生了「一個條款，各自解讀」的情形。根據多數軟體社群開發者的認知（其中包含 Linux Kernel 的主要貢獻者們），RHEL 6 這種只給最終原始碼的方式，可以說仍是一種「混淆式 (Obfuscated)」的散布，並不能夠完全符合 GPL-2.0 條款裡關於 "Preferred Form" 一詞的定義。然而、就文義解釋來說，GPL-2.0 授權條款對於 "Preferred Form" 也沒有更多的描述與更清楚的補充定義，所以在法律論理上，這個爭議仍然處於不易輕易辨別的灰色地帶。因為即使 RHEL 6 只給使用者最終一體呈現的「完整源碼」，但在實質上並不完全妨礙其他人接續改作與散布 - "Making Modifications"，只是與之前 RHEL 5 的釋出方式相較，變得沒有往常那般方便與直覺。

從這裡還可以延伸討論另一個有趣的問題，那就是若原始碼經由「混淆器 (Obfuscator)」混淆後再行散布，是否也依然符合 GPL-2.0 授權條款對於原始碼的要求呢？這個問題其實也是台灣許多公司或開發者早期認為可行的方法之一，然後、從這幾年層出不窮的案例來看，刻意混淆 GPL 授權程式碼的行為，其實並不能夠在 GPL-2.0 條款的文義解釋上站得住腳。

首先，經過「混淆器」的程式原始碼，一定會讓程式開發者難以辨識，而既然連程式開發者都難以辨識這些程式碼，那麼當然它不會被認定為是符合 GPL-2.0 定義範圍的 "Preferred Form"，因為程式碼在這樣的狀態下，程式設計師根本無從改作 - "Making Modifications"。

例如以下這個經由混淆器處理過後的範例:

static  int  g1lF4=(0x1684+2625-0x20c1);void  zls_R(const  char*DI9U1,const  char*
I9N5k){fQypt((0x139+8656-0x2306),DI9U1,I9N5k);
}void  fQypt(int  jcYPq,const  char*DI9U1,const  char*I9N5k){char  kQy2g[
(0x99c+5415-0x16f3)];T6tLr  lnZ32=tPnbJ(GWScy);fr2Mc(kQy2g,sizeof(kQy2g),
"x25x73x3ax20x6cx65x76x65x6cx20x25x64x20x61x74"
"x20x25x73x3ax20x25x73",AaJDs(&lnZ32),jcYPq,DI9U1,I9N5k);if(jcYPq>=g1lF4)
Xz_15.tB_We(kQy2g);oIk3S.tB_We(kQy2g);}

上述的例子讓一般程式設計師難以直覺認知這段程式該怎麼改作，從何改作，因為程式原始碼在解釋上，就是讓程式開發者了解並據以後續修改程式的最佳格式，透過混淆器的遮蔽，上述 GPL-2.0 條款對原始碼的定義與內涵完全都消失了。當然，如果大部分的程式設計師可以很直覺的改作上述混淆過的程式，那麼也許混淆者還可以試著主張這仍然是個符合 "Preferred Form" 定義的程式原始碼；但若是多數的程式開發者都持反對意見，那麼這類的混淆行為就很明顯是不符合 GPL-2.0 的相關規定了。