Apache 服務簡介html
Web 服務器也稱爲 WWW 服務器或 HTTP 服務器 (HTTP Server),它是 Internet 上最多見也是使用最頻繁的服務器之一,Web 服務器可以爲用戶提供網頁瀏覽、論壇訪問等等服務。linux
因爲用戶在經過 Web 瀏覽器訪問信息資源的過程當中,無須再關心一些技術性的細節,並且界面很是友好,於是 Web 在 Internet 上一推出就獲得了爆炸性的發展。如今 Web 服務器已經成爲 Internet 上最大的計算機羣,Web 文檔之多、連接的網絡之廣,也使人難以想像。所以,Web 服務器軟件的數量也開始增長,Web 服務器軟件市場的競爭也愈來愈激烈。本文所討論的就是一款最經常使用的 Web 服務器軟件—— Apache。web
Apache 是一個免費的軟件,用戶能夠免費從 Apache 的官方網站下載。任何人均可以參加其組成部分的開發。Apache 容許世界各地的人對其提供新特性。當新代碼提交到 Apache Group 後,Apache Group 對其具體內容進行審查並測試和質量檢查。若是他們滿意,該代碼就會被集成到 Apache 的主要發行版本中。算法
Apache 的其餘主要特徵有:數據庫
通常說來,Apache 服務器主要面臨以下幾種網絡威脅:apache
要應對上述這些安全威脅,要從 Apache 服務器端配置、運行環境、通訊鏈路安全保障、安全模塊使用、日誌管理等各方面、全方位的進行保障,下面將進行分門別類的詳細介紹。編程
通常狀況下,在 Linux 下啓動 Apache 服務器的進程 httpd 須要 root 權限。因爲 root 權限太大,存在許多潛在的對系統的安全威脅。一些管理員爲了安全的緣由,認爲 httpd 服務器不可能沒有安全漏洞,於是更願意使用普通用戶的權限來啓動服務器。http.conf 主配置文件裏面有以下 2 個配置是 Apache 的安全保證,Apache 在啓動以後,就將其自己設置爲這兩個選項設置的用戶和組權限進行運行,這樣就下降了服務器的危險性。瀏覽器
User apache安全
Group apache服務器
須要特別指出的是:以上 2 個配置在主配置文件裏面是默認選項,當採用 root 用戶身份運行 httpd 進程後,系統將自動將該進程的用戶組和權限改成 apache,這樣,httpd 進程的權限就被限制在 apache 用戶和組範圍內,於是保證了安全。
Apache 服務器的版本號能夠做爲黑客入侵的重要信息進行利用,他們一般在得到版本號後,經過網上搜索針對該版本服務器的漏洞,從而使用相應的技術和工具備針對性的入侵,這也是滲透測試的一個關鍵步驟。所以,爲了不一些沒必要要的麻煩和安全隱患,能夠經過主配置文件 httpd.conf 下的以下兩個選項進行:
(1)ServerTokens:該選項用於控制服務器是否響應來自客戶端的請求,向客戶端輸出服務器系統類型或者相應的內置模塊等重要信息。Red Hat Enterprise Linux 5 操做系統在主配置文件中提供全局默認控制閾值爲 OS,即 ServerTokens OS。它們將向客戶端公開操做系統信息和相關敏感信息,因此保證安全狀況下須要在該選項後使用「ProductOnly」,即 ServerTokens ProductOnly。
(2)ServerSignature:該選項控制由系統生成的頁面(錯誤信息等)。默認狀況下爲 off,即 ServerSignature off,該狀況下不輸出任何頁面信息。另外一狀況爲 on,即 ServerSignature on,該狀況下輸出一行關於版本號等相關信息。安全狀況下應該將其狀態設爲 off。
圖 1 和圖 2 爲安全設定這兩個選項先後正常狀況下和錯誤狀況下的輸出頁面(經過 Rhel5 中的 Mozilla Firefox 瀏覽器訪問 Rhel5 中的 Apache 服務器)的詳細對比。能夠清楚看到,安全設定選項後,能夠充分地向客戶端用戶隱藏 Linux 操做系統信息和 Apache 服務器版本信息。
圖 1. 錯誤狀況下未設定安全選項前示意
圖 2. 操做狀況下使用安全設定後的對比
要從主目錄之外的其餘目錄中進行發佈,就必須建立虛擬目錄。虛擬目錄是一個位於 Apache 的主目錄外的目錄,它不包含在 Apache 的主目錄中,但在訪問 Web 站點的用戶看來,它與位於主目錄中的子目錄是同樣的。每一個虛擬目錄都有一個別名,用戶 Web 瀏覽器中能夠經過此別名來訪問虛擬目錄,如 http:// 服務器 IP 地址 / 別名 / 文件名,就能夠訪問虛擬目錄下面的任何文件了。
使用 Alias 選項能夠建立虛擬目錄。在主配置文件中,Apache 默認已經建立了兩個虛擬目錄。這兩條語句分別創建了「/icons/」和「/manual」兩個虛擬目錄,它們對應的物理路徑分別是「/var/www/icons/」和「/var/www/manual」。在主配置文件中,用戶能夠看到以下配置語句:
Alias /icons/ "/var/www/icons/"
Alias /manual "/var/www/manual"
在實際使用過程當中,用戶能夠本身建立虛擬目錄。好比,建立名爲 /user 的虛擬目錄,它所對應的路徑爲上面幾個例子中經常使用的 /var/www/html/rhel5:
Alias /test "/var/www/html/rhel5"
若是須要對其進行權限設置,能夠加入以下語句:
1 2 3 4 5 6 |
|
設置該虛擬目錄和目錄權限後,可使用客戶端瀏覽器進行測試驗證,採用別名對該目錄中的文件進行訪問,瀏覽結果如圖 3 所示。
圖 3. 使用虛擬目錄的測試結果
Apache 服務器須要綁定到 80 端口上來監聽請求,而 root 是惟一有這種權限的用戶,隨着攻擊手段和強度的增長,這樣會使服務器受到至關大的威脅,一但被利用緩衝區溢出漏洞,就能夠控制整個系統。爲了進一步提升系統安全性,Linux 內核引入 chroot 機制,chroot 是內核中的一個系統調用,軟件能夠經過調用函數庫的 chroot 函數,來更改某個進程所能見到的根目錄。
chroot 機制即將某軟件運行限制在指定目錄中,保證該軟件只能對該目錄及其子目錄的文件有所動做,從而保證整個服務器的安全。在這種狀況下,即便出現黑客或者不法用戶經過該軟件破壞或被侵入系統,Linux 系統所受的損壞也僅限於該設定的根目錄,而不會影響到整個系統的其餘部分。
將軟件 chroot 化的一個問題是該軟件運行時須要的全部程序、配置文件和庫文件都必須事先安裝到 chroot 目錄中,一般稱這個目錄爲 chroot「監牢」。若是在「監牢」中運行 httpd,那麼用戶根本看不到 Linux 文件系統中那個真正的目錄,從而保證了 Linux 系統的安全。
在使用該技術的時候,通常狀況下須要事先建立目錄,並將守護進程的可執行文件 httpd 複製到其中。同時,因爲 httpd 須要幾個庫文件,因此須要把 httpd 程序依賴的幾個 lib 文件同時也拷貝到同一個目錄下,所以手工完成這一工做是很是麻煩的。幸運的是,用戶能夠經過使用開源的 jail 軟件包來幫助簡化 chroot「監牢」創建的過程,具體步驟以下所示:Jail 官方網站是:http://www.jmcresearch.com/projects/。
首先將其下載,而後執行以下命令進行源代碼包的編譯和安裝:
1 2 3 |
|
jail 軟件包提供了幾個 Perl 腳本做爲其核心命令,包括 mkjailenv、addjailuser 和 addjailsw,他們位於解壓後的目錄 jail/bin 中。這幾個命令的基本用途以下所示:
採用 jail 建立監牢的步驟以下所示;
(1)首先須要中止目前運行的 httpd 服務,而後創建 chroot 目錄,命令以下所示。該命令將 chroot 目錄創建在路徑 /root/chroot/httpd 下:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
(2)爲「監牢」添加 httpd 程序,命令以下:
1 2 3 4 5 6 7 8 9 10 11 |
|
在上述過程當中,用戶不須要在乎那些警告信息,由於 jail 會調用 ldd 檢查 httpd 用到的庫文件。而幾乎全部基於共享庫的二進制可執行文件都須要上述的幾個庫文件。
(3)而後,將 httpd 的相關文件拷貝到「監牢」的相關目錄中,命令以下所示:
1 2 3 |
|
添加後的目錄結構以下所示:
1 2 3 4 5 6 7 8 9 |
|
(4)從新啓動 httpd,並使用 ps 命令檢查 httpd 進程,發現該進程已經運行在監牢中,以下所示:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
Apache 的一個優點即是其靈活的模塊結構,其設計思想也是圍繞模塊(module)概念而展開的。安全模塊是 Apache Server 中的極其重要的組成部分。這些安全模塊負責提供 Apache server 的訪問控制和認證,受權等一系列相當重要的安全服務。
Apache 下有以下幾類與安全相關的模塊:
爲了可以使用模塊功能,模塊一般以 DSO(Dynamic Shared Object)的方式構建,用戶應該在 httpd.conf 文件中使用 LoadModule 指令,使得可以在使用前得到模塊的功能。以下爲主配置文件中各個模塊的狀況,開啓安全模塊很是簡單,即去掉在各安全模塊所在行前的「#」符號便可,以下所示:
1 2 3 4 5 |
|
只有將上述安全模塊進行開啓後 ,Apache 才能實現相應的訪問控制和通訊加密功能。
在開啓了相應的安全模塊後,還須要對 Apache 的訪問控制策略進行設定。
目前,有兩種常見的認證類型,基本認證和摘要認證:
(1)基本認證(Basic):使用最基本的用戶名和密碼方式進行用戶認證。
(2)摘要認證(Digest):該認證方式比基本認證要安全得多,在認證過程當中額外使用了一個針對客戶端的挑戰(challenge)信息,能夠有效地避免基本認證方式可能遇到的「重放攻擊」。值得注意的是:目前並不是全部的瀏覽器都支持摘要認證方式。
全部的認證配置指令既能夠出如今主配置文件 httpd.conf 中的 Directory 容器中,也能夠出如今單獨的 .htaccess 文件中,這個能夠由用戶靈活地選擇使用。在認證配置過程當中,須要用到以下指令選項:
使用上述的認證指令配置認證以後,須要爲 Apache 服務器的訪問對象,也就是指定的用戶和組進行相應的受權,以便於他們對 Apache 服務器提供的目錄和文件進行訪問。爲用戶和組進行受權須要使用 Require 指令,它主要可使用以下三種方式進行受權:
要實現用戶認證功能,首先要創建保存用戶名和口令的文件。Apache 自帶的 htpasswd 命令提供了創建和更新存儲用戶名、密碼的文本文件的功能。須要注意的是,這個文件必須放在不能被網絡訪問的位置,以免被下載和信息泄漏。建議將口令文件放在 /etc/httpd/ 目錄或者其子目錄下。
下面的例子在 /etc/httpd 目錄下建立一個文件名爲 passwd_auth 的口令文件,並將用戶 rhel5 添加入認證口令文件。使用如下命令創建口令文件(過程當中還會提示輸入該用戶的口令):
1 2 3 4 5 |
|
命令執行的過程當中系統會要求用戶爲 rhel5 用戶輸入密碼。上述命令中的 -c 選項表示不管口令文件是否已經存在,都會從新寫入文件並刪去原有內容。因此在添加第 2 個用戶到口令文件時,就不須要使用 -c 選項了,以下命令所示
1 |
|
配置指令
Apache 實現訪問控制的配置指令包括以下三種:
(1)order 指令:用於指定執行容許訪問控制規則或者拒絕訪問控制規則的順序。order 只能設置爲 Order allow,deny 或 Order deny,allow,分別用來代表用戶先設置容許的訪問地址仍是先設置禁止訪問的地址。Order 選項用於定義缺省的訪問權限與 Allow 和 Deny 語句的處理順序。Allow 和 Deny 語句能夠針對客戶機的域名或 IP 地址進行設置,以決定哪些客戶機可以訪問服務器。Order 語句設置的兩種值的具體含義以下:
(2)allow 指令:指明容許訪問的地址或地址序列。如 allow from all 指令代表容許全部 IP 來的訪問請求。
(3)deny 指令:指明禁止訪問的地址或地址序列。如 deny from all 指令代表禁止全部 IP 來的訪問請求。
應用實例
下面舉幾個簡單的例子對上述 order、allow 和 deny 命令的使用進行示範。
(1)在下面的例子中,admin.org 域中全部主機都容許訪問網站,而其餘非該域中的任何主機訪問都被拒絕,由於 Deny 在前,Allow 在後,Allow 語句覆蓋了 Deny 語句:
1 2 3 |
|
(2)下面例子中,admin.org 域中全部主機,除了 db.admin.org 子域包含的主機被拒絕訪問之外,都容許訪問。而全部不在 admin.org 域中的主機都不容許訪問,由於缺省狀態是拒絕對服務器的訪問(Allow 在前,Deny 在後,Deny 語句覆蓋了 Allow 語句):
1 2 3 |
|
使用主配置文件配置用戶認證及受權
在本例子中,用戶能夠在 Apache 的主配置文件 httpd.conf 中加入如下語句創建對目錄 /var/www/html/rhel5 訪問的用戶認證和受權機制:
1 2 3 4 5 6 7 |
|
在上述例子中,使用了以下指令:
須要注意的是:在 AuthUserFile 選項定義中,還須要使用以下語句事先創建認證用戶 patterson 和 testuser,該選項中的定義才能生效:
1 2 |
|
使用 .htaccess 文件配置用戶認證和受權
在本例子中,爲了完成如上述例子一樣的功能,須要先在主配置文件中加入以下語句:
1 2 3 |
|
上述語句中的 AllowOverride 選項容許在 .htaccess 文件中使用認證和受權指令。、、而後,在 .htaccess 文件中添加以下語句便可:
1 2 3 4 |
|
同理,在 AuthUserFile 選項定義中,還須要使用以下語句事先創建認證用戶 patterson 和 testuser,該選項中的定義才能生效:
#htpasswd -c /etc/httpd/passwd_auth rhel5
#htpasswd /etc/httpd/passwd_auth testuser
在 SSL 通訊中,首先採用非對稱加密交換信息,使得服務器得到瀏覽器端提供的對稱加密的密鑰,而後利用該密鑰進行通訊過程當中信息的加密和解密。爲了保證消息在傳遞過程當中沒有被篡改,能夠加密 Hash 編碼來確保信息的完整性。服務器數字證書主要頒發給 Web 站點或其餘須要安全鑑別的服務器,證實服務器的身份信息,一樣客戶端數字證書用於證實客戶端的身份。
使用公用密鑰的方式能夠保證數據傳輸沒有問題,但若是瀏覽器客戶訪問的站點被假冒,這也是一個嚴重的安全問題。這個問題不屬於加密自己,而是要保證密鑰自己的正確性問題。要保證所得到的其餘站點公用密鑰爲其正確的密鑰,而非假冒站點的密鑰,就必須經過一個認證機制,能對站點的密鑰進行認證。固然即便沒有通過認證,仍然能夠保證信息傳輸安全,只是客戶不能確信訪問的服務器沒有被假冒。若是不是爲了提供電子商務等方面對安全性要求很高的服務,通常不須要如此嚴格的考慮
。
下面給出使用 SSL 進行通訊的過程(參見圖 4):
(1)客戶端向服務器端發起對話,協商傳送加密算法。例如:對稱加密算法有 DES、RC5,密鑰交換算法有 RSA 和 DH,摘要算法有 MD5 和 SHA。
(2)服務器向客戶端發送服務器數字證書。好比:使用 DES-RSA-MD5 這對組合進行通訊。客戶端能夠驗證服務器的身份,決定是否須要創建通訊。
(3)客戶端向服務器傳送本次對話的密鑰。在檢查服務器的數字證書是否正確,經過 CA 機構頒發的證書驗證了服務器證書的真實有效性以後,客戶端生成利用服務器的公鑰加密的本次對話的密鑰發送給服務器。
(4)服務器用本身的私鑰解密獲取本次通訊的密鑰。
(5)雙方的通訊正式開始。
圖 4. SSL 通訊流程示意
在通常狀況下,當客戶端是保密信息的傳遞者時,他不須要數字證書驗證本身身份的真實性,如用戶一般使用的網上銀行交易活動,客戶須要將本身的隱祕信息——帳號和密碼發送給銀行,所以銀行的服務器須要安裝數字證書來代表本身身份的有效性,不然將會使得信息泄露。固然,在某些安全性要求極高的 B2B(Business to Business)應用,服務器端也須要對客戶端的身份進行驗證,這時客戶端也須要安裝數字證書以保證通訊時服務器能夠辨別出客戶端的身份,驗證過程相似於服務器身份的驗證過程。另外,在一些電子商務的應用中,可能還會使用到電子簽名,或者爲了信息交換的更加安全,會增長電子簽名和消息校驗碼(MAC)。而在一般狀況下,瀏覽器都會經過交互的方式來完成上述的通訊過程,下面在 Linux 中對 Apache 採用 SSL 也會做詳細地介紹。
安裝 SSL
雖然 Apache 服務器不支持 SSL,但 Apache 服務器有兩個能夠自由使用的支持 SSL 的相關計劃,一個爲 Apache-SSL,它集成了 Apache 服務器和 SSL,另外一個爲 Apache+mod_ssl,它是經過可動態加載的模塊 mod_ssl 來支持 SSL,其中後一個是由前一個分化出的,並因爲使用模塊,易用性很好,所以使用範圍更爲普遍。還有一些基於 Apache 並集成了 SSL 能力的商業 Web 服務器,然而使用這些商業 Web 服務器主要是北美,這是由於在那裏 SSL 使用的公開密鑰的算法具有專利權,不能用於商業目的,其餘的國家沒必要考慮這個專利問題,而能夠自由使用 SSL。
Apache+mod_ssl 依賴於另一個軟件:OpenSSL,它是一個能夠自由使用的 SSL 實現,首先須要安裝這個軟件。用戶能夠從網站 http://www.openssl.org/source/ 上下載 Linux 下 OpenSSL 的最新穩定版本:openssl-1.0.1c.tar.gz。
下載源代碼安裝包後,使用以下的步驟安裝便可:
(1)用 openssl-1.0.1c.tar.gz 軟件包安裝 OpenSSL 以前,首先需要對該軟件包進行解壓縮和解包。用如下命令完成軟件包的解壓縮和解包:
#tar xvfz openssl-1.0.1c.tar.gz
(2)解壓縮後,進入源碼的目錄 openssl-1.0.1c ,並使用配置腳本進行環境的設置。相應的命令爲:
1 2 3 4 5 |
|
(3)在執行 ./configure 以後,配置腳本會自動生成 Makefile。若是在設置的過程當中沒有任何的錯誤,就能夠開始編譯源碼了。相應的命令及其顯示結果以下:
1 |
|
安裝好 OpenSSL 以後,就能夠安裝使用 Apache+mod_ssl 了。然而爲了安裝徹底正確,須要清除原先安裝的 Apache 服務器的其餘版本,而且還要清除全部的設置文件及其缺省設置文件,以免出現安裝問題。最好也刪除 /usr/local/www 目錄(或改名),以便安裝程序能創建正確的初始文檔目錄。若是是一臺沒有安裝過 Apache 服務器的新系統,就能夠忽略這個步驟,而直接安裝 Apache+mod_ssl 了。
啓動和關閉 SSL
啓動和關閉該服務器的命令以下所示:
此時使用 start 參數爲僅僅啓動普通 Apache 的 httpd 守護進程,而不啓動其 SSL 能力,而 startssl 才能啓動 Apache 的 SSL 能力。若是以前 Apache 的守護進程正在運行,便須要使用 stop 參數先中止服務器運行。
在採用 OpenSSL 進行 Apache 通訊加密前,須要先產生與加密相關的認證憑證(也就是證書),以下步驟所示:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
|
通過上述步驟後,將會產生三個文件 apache.csr, apache.key 和 apache.crt,而後把這三個文件拷貝到 /etc/httpd/conf/ca 目錄下便可。
而後,就能夠啓動 Mozilla、IE 或其餘支持 SSL 的瀏覽器,輸入 URL 爲:https://ssl_server/來查看服務器是否有相應,https 使用的缺省端口爲 443,若是一切正常,服務器將會返回給客戶端證書,由客戶端進行驗證而且判斷,是否接受該證書並進行下一步的通訊過程。
下面以 Linux 下的 Mozilla Firefox 瀏覽器爲例,來簡要說明使用 Apache+SSL 服務器的過程。首先,圖 5 給出了查看和驗證該證書的相關提示;最後,圖 6 則給出了證書驗證成功後,採用 SSL 進行保密傳輸的具體界面示意:
圖 5. 驗證證書示意
圖 6. 證書經過驗證,正常通訊開始
日誌文件是用戶管理和監控 Apache 安全的很是好的第一手資料,它清晰地記錄了客戶端訪問 Apache 服務器資源的每一條記錄,以及在訪問中出現的錯誤信息,能夠這樣說,Apache 能夠記錄 Web 訪問中感興趣的幾乎全部信息。
當運行 Apache 服務器時生成 4 個標準的日誌文件:
其中比較常見的是訪問日誌(access_log)和錯誤日誌(error_log),其中傳輸日誌和 cookie 日誌被 Apache 2.0 以上的版本丟棄,因此本文不討論這兩種日誌。固然,若是使用 SSL 服務的話,還可能存在 ssl_access_log、ssl_error_log 和 ssl_request_log 三種日誌文件。
另外,值得注意的是:上述幾種日誌文件若是長度過大,還可能生成注入 access_log.1,error_log.2 等的額外文件,其格式與含義與上述幾種文件相同,只不過系統自動爲其進行命名而已。
Apache 中提供以下 4 條與日誌相關的配置指令:
在上述幾個文件當中,除了 error_log 和 ssl_error_log 以外,全部日誌文件以由 CustomLog 和 LogFormat 指令指定的格式生成。這些指令在 httpd.conf 文件中出現。使用 LogFormat 指令能夠定義新的日誌文件格式:
1 |
|
假定使用的是 common 日誌格式或者 combined 日誌格式,這兩種格式都在默認的配置文件中定義。表 1 列出了 LogFormat 語句可使用的變量:
表 1. LogFormat 語句的變量
變 量 | 含 義 |
---|---|
%b | 發送字節,不包括 HTTP 標題 |
%f | 文件名 |
%{VARIABLE}e | 環境變量 VARIABLE 的內容 |
%h | 遠程主機 |
%a | 遠程 IP 地址 |
%{HEADER}i | HEADER 內容;發送到服務器的請求的標題行 |
%l | 遠程登陸名(若是提供該值,則從 identd 得到) |
%{NOTE}n | 來自另外一個模塊的 NOTE 通知的內容 |
%{HEADER}o | HEADER 的內容,回覆中的標題行 |
%p | 服務器服務於請求的規範端口 |
%P | 服務於請求的子進程的 ID |
%r | 請求的第一行 |
%s | 狀態。對於內部重定向的請求,該狀態爲初始請求—最後是 %>s |
%t | 時間,格式爲 common 日誌格式中的時間格式 |
%{format}t | 時間,格式由 format 給出。能夠是 strftime(3)格式 |
%T | 服務請求花費的時間,以秒計 |
%u | 來自 auth 的遠程用戶;若是返回的狀態(%s)爲 401 則多是假的 |
%U | 請求的 URL 路徑 |
%v | 服務於該請求的服務器的規範 ServerName |
在每一個變量中,能夠在前面設置一個條件,決定是否顯示該變量。若是不顯示,則顯示 -。這些條件是數值返回值列表的形式。另外,還可使用 CustomLog 指令指定日誌文件的位置和格式。若是沒有指定日誌文件的絕對路徑,則日誌文件的位置假定爲相對於 ServerRoot。下面是 httpd.conf 文件中指定日誌文件的語句:
1 2 3 4 5 6 7 8 9 10 |
|
通常說來,Apache 中的錯誤日誌記錄等級有如表 2 所示的八類:
表 2. 錯誤日誌記錄的等級
緊急性 | 等級 | 解釋 |
---|---|---|
1 | Emerg | 出現緊急情況使得系統不可用 |
2 | Alert | 須要當即引發注意的情況 |
3 | Crit | 危險狀況的警告 |
4 | Error | 除上述 3 種狀況以外的其餘錯誤 |
5 | Warn | 警告信息 |
6 | Notice | 須要引發注意的狀況,不如第 4 和第 5 類重要 |
7 | Info | 須要報告的通常消息 |
8 | Debug | 運行於 debug 模式的程序產生的消息 |
另外,在 Apache 中,將訪問日誌分爲以下 4 類:
在實際的使用過程當中,因爲綜合日誌格式有效地結合了其餘 3 種日誌格式和信息,因此在配製訪問日誌時,能夠有兩種方式:
(1)分別使用 3 個文件進行分別記錄,相應配置示例以下:
1 2 3 4 5 6 |
|
(2)使用一個綜合文件進行記錄,相應配置示例以下:
1 2 3 |
|