編譯apache

㈠ 編譯安裝的apache，httpd.pid在哪

/var/run/httpd/httpd.pid

看下httpd.conf的配置文件下，比如
grep pid /etc/httpd/conf/httpd.conf

find / -name httpd.pid

㈡ 在linux 上裝apache 編譯和安裝都正常，可是在啟動服務apachectl start 的時候報錯： apachectl ：沒有許

編譯安裝httpd，系統並不會自動給apachectl做鏈接，你可以到編譯安裝目錄中去尋找apachectl命令，然後執行/path/apachectl start,或者手動把鏈接做到/usr/local/bin目錄中，然後才可以執行apachectl start

㈢ 求助，編譯apache伺服器出問題

隨著網路技術的普及、應用和Web技術的不斷完善，Web服務已經成為互聯網上重要的服務形式之一。原有的客戶端/伺服器模式正在逐漸被瀏覽器/伺服器模式所取代。本文將重點Apache 伺服器的故障排除的技巧。
一、檢查配置文件的錯誤
Apache伺服器的設置文件位於/etc/httpd/conf/目錄下，傳統上使用三個配置文件httpd.conf,access.conf和srm.conf，來配置Apache伺服器的行為。在新版本的Apache中，所有的設置都被放在了httpd.conf中，因此只需要調整這個文件中的設置。其中99% Apache伺服器錯誤是配置文件有誤。
1 使用apachectl configtest命令
如果配置文件有錯誤，可以使用apachectl configtest命令，apachectl configtest命令可以檢查出所有語法錯誤和邏輯錯誤。
實例1
下面是一個配置文件樣例片斷：
Locatio
erver
tatu
SetHandler server
tatu
Order deny,allow
Deny from all
Allow from
192.168
149
</
Locatio
如果黑體部分的錯誤寫成了「<Location /server-status」少寫了一個 >。
apachectl configtest命令會檢查到這個問題，輸出如下：
apachectl configtest
Syntax error on line
918
of
etc
httpd
conf
httpd.conf:
Locatio
directive missing closing
2 使用服務管理工具
如果配置文件有錯誤，也可以使用GUI工具來查看。下面是實例1在GUI工具「服務配置「中的體現，如圖1 。
圖1 使用GUI工具檢查錯誤
二、 學會使用錯誤日誌 錯誤日誌是最重要的日誌文件，其文件名和位置取決於ErrorLog指令。Apache httpd將在這個文件中存放診斷信息和處理請求中出現的錯誤，由於這里經常包含了出錯細節以及如何解決，如果伺服器啟動或運行中有問題，首先就應該查看這個錯誤日誌。錯誤日誌是你的朋友。任何錯誤都會在錯誤日誌中有所記載，所以你應該首先查看它。如果你的網站空間提供者不允許訪問錯誤日誌，那麼你應該考慮換一個空間提供者。學會閱讀錯誤日誌，可以快速找出問題並快速解決。 1 錯誤日誌格式 Apache 默認的錯誤日誌配置如下： ErrorLog logs/error_log LogLevel warn 配置錯誤日誌相對簡單，只要說明日誌文件的存放路徑和日誌記錄等級即可。格式為： 日期和時間 錯誤等級 錯誤消息 2 日誌記錄等級 下面著重說說日誌記錄等級，包括八個級別。 1 級英文名稱emerg ，出現緊急情況使得該系統不可用，如系統宕機等 2 級alert 英文名稱，需要立即引起注意的情況 3 級 英文名稱crit ，危險情況的警告 4級 英文名稱error ，除了emerg 、alert、crit 的其他錯誤 5級英文名稱 warn。 警告信息 6級英文名稱 notice ，需要引起注意的情況，但不如error、warn 重要 7級英文名稱 info ，值得報告的一般消息 8級英文名稱 debug， 由運行於debug 模式的程序所產生的消息 錯誤日誌文件舉例 錯誤日誌的格式相對靈活，並可以附加文字描述。某些信息會出現在絕大多數記錄中，一個典型的例子是： [Wed Oct 11 14:32:52 2007] [error] [client 127.0.0.1] client denied by server configuration: /export/home/live/ap/htdocs/test 其中，第一項是錯誤發生的日期和時間；第二項是錯誤的嚴重性，LogLevel指令使只有高於指定嚴重性級別的錯誤才會被記錄；第三項是導致錯誤的IP地址；此後是信息本身，在此例中，伺服器拒絕了這個客戶的訪問。伺服器在記錄被訪問文件時，用的是文件系統路徑，而不是Web路徑。錯誤日誌中會包含類似上述例子的多種類型的信息。此外，CGI腳本中任何輸出到stderr的信息會作為調試信息原封不動地記錄到錯誤日誌中。用戶可以增加或刪除錯誤日誌的項。但是對某些特殊請求，在訪問日誌(access log)中也會有相應的記錄，比如上述例子在訪問日誌中也會有相應的記錄，其狀態碼是403，因為訪問日誌也可以定製，所以可以從訪問日誌中得到錯誤事件的更多信息。 了解錯誤代碼和錯誤提示 l 常用的錯誤響應代碼如下： 301 ：告知用戶請求的URL 已經永久的移動到新的URL，用戶可以記住新的URL，以便日後直接使用新的URL 進行訪問。 302 ：告知用戶請求的URL 臨時的移動到新的URL，用戶無需記住新的URL，如果省略錯誤響應代碼，默認就是此值。 303 ：告知用戶頁面已經被替換，用戶應該記住新的URL。 401 ：授權失敗，即密碼錯誤。 403 ：Access denied 存取錯誤，即不可以讀取該文件。 404 ：File not found 找不到文件。 410 ：告知用戶請求的頁面已經不再存在，使用此代碼時不應該使用重定向的URL 參數。 500 ：伺服器內部錯誤，可能是Web伺服器本身存在問題，也可能是編寫的程序出錯。 l 錯誤消息提示說明 「Invalid argument: core_output_filter: writing data to the network」 消息 Apache在可能的平台上使用系統調用sendfile來加速響應的發送。不幸的是，在某些系統上，Apache會在編譯時檢測sendfile的存在，即使它不能正常工作。這經常發生在使用網路或其他非標准文件系統時。這個問題的表現症狀包括上述信息出現在錯誤日誌里及對於非零長度文件請求發送零長度的響應。一般這個問題只發生在靜態文件上，因為動態文件通常用不到sendfile 。要修正這個問題，可用EnableSendfile指令關閉伺服器所有部分對sendfile的使用即可。同時參看EnableMMAP指令，對相似的問題有幫助。 「Premature end of script headers」 消息 大多數導致這個錯誤的CGI腳本問題將會向瀏覽器發送一個"Internal Server Error"錯誤信息。 「Permission denied」 消息 error_log中的"Permission denied"錯誤伴隨一個發送到客戶端的"Forbidden"信息通常表明違反了文件系統的許可權，而不是Apache HTTP的配置文件出了錯誤。檢查並確認用於運行子進程的User和Group有訪問導致問題的文件的足夠許可權。同時檢查一下導致問題的文件所在的目錄及其所有父目錄是否具有執行(搜索)許可權(也就是 chmod +x)。最近發行的 Fedora Core 和其它Linux發行版使用了SELinux進行額外的訪問控制，違反這些限制也會導致"Permission denied"消息。 "POST Method Not Allowed"消息 這說明Apache沒有被正確配置以執行CGI程序，重新閱讀配置Apache看看遺漏了什麼。 "Internal Server Error"消息 查閱Apache錯誤日誌，可以找到CGI程序產生的出錯消息"Premature end of script headers"。對此，需要檢查下列各項，以找出不能產生正確HTTP頭的原因。
1 檢查錯誤日誌！
Apache伺服器在遇到問題時會盡力做到對你有所幫助。在許多情況下，它會通過在錯誤日誌中寫入一條或多條消息來提供一些細節。有時這已經足夠讓你自己診斷和解決問題了(比如文件許可權或類似的問題)。錯誤日誌的默認位置在/usr/local/apache2/logs/error_log ，但是最後還是看看配置文件中的ErrorLog指令以確認錯誤日誌在你伺服器上的確切位置。
2 再一次檢查語法
Apache 配置文件是httpd.conf 長度通常在80-990行，幾乎99%Apache 故障是語法錯誤引起的。可以手工檢查/etc/httpd/conf/httpd.conf，也可以通過瀏覽器輸入：
http://192.168.1.12/server-info?config
獲取當前配置文件，如圖3 。
圖3 當前Apache伺服器配置文件
說明：此時系統會自動添加行號。
3 察看Apache的FAQ!
最新版本的Apache常見問題列表總是可以從Apache主站點得到，
4 察看Apache bug資料庫
大多數報告給Apache項目組的問題都記錄在bug資料庫中。在你添加一個新bug之前，請務必檢查已有的報告(打開的和關閉的)。如果你發現你的問題已經被報告了，請不要添加一個"我也是"那樣的報告。如果原始報告還沒有關閉，我們建議你經常周期性地來看看它。你也可以考慮與最初的提交者接觸，因為有可能會在郵件交流中發現沒有記錄在資料庫中的問題。
5 在某個用戶論壇中提問
Apache擁有一個活躍的、願意共享知識的用戶社區。參與這個社區通常是獲得解答的最快最好的辦法。
Apache用戶郵件列表：
6 提交問題報告到bug資料庫
如果做了以上幾個合適的步驟而沒有得到解答，那麼請務必讓httpd的開發者了解這個問題，到這里（
）提交bug報告。
7 獲取商業支持

㈣ 編譯安裝apache 需要什麼環境

編譯Apache的要求如下：
磁碟空間
必須保證有50MB以上的自由臨時磁碟空間。Apache安裝完畢後會占據10MB左右的空間，實際的磁碟空間需求會因編譯設置和是否安裝第三方模塊而有所不同。
ANSI-C編譯器及編譯環境
必須裝有ANSI-C編譯器，推薦使用自由軟體基金會(FSF)的GCC。如果沒有GCC，那麼要確保使用的編譯器符合ANSI標准，而且PATH中必須包含指向基本編譯工具比如make的路徑。
確保准確的時間
由於HTTP協議的元素都會用到時間，有必要了解一下你的系統所使用的時間同步機制。在基於網路時間協議(NTP)的系統中，一般是用ntpdate或xntpd來同步時間。有關NTP軟體的資料請參見NTP主頁。
Perl 5 [可選]
有些用Perl寫的支持腳本，如apxs或dbmmanage ，需要Perl5解釋器(5.003或以上的版本就足夠了)。如果系統中存在多個Perl解釋器，比如有系統提供的Perl 4，還有你自己安裝的Perl 5，推薦你使用 --with-perl 選項來確保configure腳本使用正確的版本。如果configure沒有沒找到Perl 5也沒關系，這並不影響Apache httpd的編譯和安裝，只是相關的支持腳本不能使用而已。
apr/apr-util >= 1.2
apr和apr-util包含在Apache httpd的發行源代碼中，並且在絕大多數情況下使用都不會出現問題。當然，如果apr或apr-util的1.0或1.1版本已經安裝在你的系統中了，則必須將你的apr/apr-util升級到1.2版本，或者將httpd單獨分開編譯。要使用發行源代碼中自帶的apr/apr-util源代碼進行安裝，你必須手動完成：
# 編譯和安裝 apr 1.2
cd srclib/apr
./configure --prefix=/usr/local/apr-httpd/
make
make install

# 編譯和安裝 apr-util 1.2
cd ../apr-util
./configure --prefix=/usr/local/apr-util-httpd/ --with-apr=/usr/local/apr-httpd/
make
make install

# 配置 httpd
cd ../../
./configure --with-apr=/usr/local/apr-httpd/ --with-apr-util=/usr/local/apr-util-httpd/

㈤ 如何編譯配置Apache中的Configure

./Configure文件是一個經常被遺忘的Apache工具。本文介紹如何用./Configure進行編譯配置，避免每次編譯Apache時進行重復的操作。文章比較了常規方法與使用./Configure這兩者各自的優缺點以及如何手工編輯配製文件進行編譯配置。 一、優缺點比較 我們知道，配製Apache編譯選項使用的是configure。但除此之外，我們還可以使用Configure。注意兩者的差別：常用的那個配製工具是小寫c開頭的「configure」，這里要討論的「Configure」以大寫的C開頭。 解開Apache源代碼之後，configure腳本位於頂級目錄下面。一般我們按照如下步驟使用它： tar -zvxf apache_1.3.14.tar.gz cd apache_1.3.14 ./configure --prefix=/usr/local/apache make make install Configure是位於src子目錄下的腳本。它的參數不是通過命令行指定，而是在一個名為Configuration的配置文件中指定。Apache提供一個默認的配置模板文件Configuration.tmpl，其中包含了通用的默認配置值。 用Configure進行默認安裝的過程如下： tar -zvxf apache_1.3.14.tar.gz cd apache_1.3.14/src cp -f Configuration.tmpl Configuration vi Configuration ... 如必要，修改默認配置值 ./Configure make make install 缺點 用Configure進行配製有幾個明顯的缺點，至少對初學者來說是這樣的。 首先，這種配製方法並不廣為人知。只要是對開放源代碼軟體有所了解的人，解開源代碼並進入它的目錄之後，或許會對它的configure腳本感到熟悉，但往往不會進入src子目錄去尋找其他什麼東西。 即使知道可以用Configure進行編譯配製，Configuration文件本身也可能成為小小的障礙。這是因為，雖然Configuration文件內部包含的說明相當完善，每一行都有豐富的註解說明其作用，但這個文件實在過於龐大，包含了許多大多數人永遠不想要加以定製的選項。 最後，雖然有關這兩種配製方法差別的資料略顯缺乏，但總地看來初學者最好使用configure，而Configure只適合於經驗豐富的用戶使用。雖然這並不能算是一個真正的缺點，但它無疑使許多用戶駐足而不敢嘗試。 優點 使用Configure進行編譯配製最大的優點在於，它方便了我們將特定的配置信息保存下來以後再用，無需記住冗長的configure命令行選項。 例如，本人上次編譯Apache時使用的configure命令如下： ./configure --prefix=/usr/local/apache --enable-mole=most --enable-shared=max --enable-mole=auth_dbm --enable-mole=auth_mysql 這還應該算是一次比較簡單的編譯。問題在於，即使是輸入上面這行命令，我也要查看各種參數的語法並努力記住各個模塊的名字。對於大多數人來說這並不是一個很重要的問題，但由於我經常要重新構造Apache，這個問題就顯得比較突出了。 configure也有它的好處，它實際上會在src目錄下生成一個配製文件，我們可以保存這個文件供以後參考。這個文件就是src/Configuration.apaci。 如果我們為測試目的構造Apache，完成後又要在正式運行的系統上以完全相同的方式構造Apache，configure的這個功能將是非常有用的。此時，我們只需要復制一份Configuration.apaci文件，將它拷貝到正式運行的伺服器上，然後用這個文件編譯Apache伺服器即可。 應當說明的是，雖然默認情況下配製選項由Configuration文件提供，但我們可以用-file參數指定另外的文件： ./Configure -file Configuration.saved_prefs 二、手工編輯配製文件 以前，指定編譯選項的唯一方法是手工編輯Configuration文件。當然，那時候我們還要步行上學，跋山涉水。這一切現在都已經過去。 不管怎樣，如果你准備直接使用Configuration文件，你就得仔細地了解一下它到底由什麼內容構成。Configuration文件中的大多數選項都是無需定製的，不過了解一下它們的用處是有好處的。 Configuration文件的前面是關於本文件的一個簡短說明。下面摘錄了這部分內容並給出其譯文： # There are 5 types of lines here: 這里共有5種類型的代碼行： # &single;#&single; comments, distinguished by having a &single;#&single; as the first non-blank character 「#」注釋，以第一個非空字元為「#」區別 # # Makefile options, such as CC=gcc, etc... Make文件選項，例如 CC=gcc，等等... # # Rules, distinguished by having "Rule" at the front. These are used to # control Configure&single;s behavior as far as how to create Makefile. 規則，以前面的「Rule」區別，用於控制Configure的行為以至 如何創建Make文件 # # Mole selection lines, distinguished by having &single;AddMole&single; at the front. # These list the configured moles, in priority order (highest priority # last). They&single;re down at the bottom. 模塊選擇行，以前面的「AddMole」區別。這些行以優先順序為序列出 了已經配製的模塊（高優先順序的在後面）。模塊選擇在文件最後進行。 # # Optional mole selection lines, distinguished by having `%Mole&single; # at the front. These specify a mole that is to be compiled in (but # not enabled). The AddMole directive can be used to enable such a # mole. By default no such moles are defined. 可選模塊選擇行，以前面的「%Mole」區別。這些行指定了必須 編譯的模塊（但不啟用）。AddMole指令可以啟用這種模塊。默 認不定義這種模塊。 大多數用戶只需修改模塊選擇行，其他內容只適合於深入了解其含義的用戶進行修改。在文件的最後我們可以發現許多如下形式的行： AddMole moles/standard/mod_cgi.o 它表示本次編譯Apache應啟用指定的模塊（這里是mod_cgi模塊）。我們可以用注釋掉相應行的方法來刪除特定的模塊；反之，如果取消已注釋行的注釋將啟用該模塊。 我們可以通過SharedMole指令（而不是AddMole）將模塊編譯成DSO（共享對象，shared object）： SharedMole moles/standard/mod_vhost_alias.so 注意在編譯DSO時必須啟用mod_so模塊。 用configure生成Configuration.apaci文件，然後檢查其改動之處是一種很好的學習方法。 一旦在Configuration文件中完成了所有必須的改動，只需運行./Configure即可開始編譯過程。 三、使用哪種方法好？ 顯然，使用configure和使用Configure都有著各自強硬的支持者，但可以相信每一種觀點都有其派別和歷史的原因。 我們建議兩種方法都用。用configure生成Configuration文件，閱讀這些文件了解其作用，然後保存其中的部分文件供以後在Configure命令中使用。 如果你打算只進行默認安裝，而且從來沒有想到過要改變任何一個選項，那麼使用哪一種方法進行配製就無關緊要了

㈥ 怎樣區別APACHE動態和靜態編譯

關於apache的動態與靜態編譯的理解，引用某人的比喻如下：
好比有兩個人a和m，a代表apache,m代表mole，要想讓a使用m的東西，一個方法是把m的東西都放到a那裡去，a使用的時候就是現成的了，就是所謂的靜態編譯
還有一個方法，就是告訴a，m的住址，當a要使用m的東西的時候,a去找m,然後使用，不過，這種方法要注意的一個問題就是：m必須要有實際的住址，否則a會找不到m而產生錯誤的，這種方法也就是apache 的動態(DSO)編譯了。
下面說說在apache1.3和apache2.0動態與靜態編譯編譯的區別
首先是apache1.3.29+php4.3.4+mysql4.0.13的靜態編譯
apache第一次編譯,並不要安裝，因為php的編譯需要apache至少已經編譯過一次
tar zvxf apache_1.3.27.tar.gz
cd apache_1.3.27
./configure --prefix=/usr/local/apache
編譯php
tar zvxf php4.3.4.tar.gz
cd php4.3.4
./configure --prefix=/usr/local/php --with-mysql=/usr/local/mysql --with-apache=../apache_1.3.27
make
make install
第二次編譯安裝apache:
cd ../apache_1.3.29
./configure --prefi=/usr/local/apache --activate-mole=src/moles/php4/libphp4.a
make
make install
cp ../php4.3.4/php.ini.dist /usr/local/php/lib/php.ini

修改/usr/local/apache/conf/httpd.conf
查找<IfMole mod_mime.c>
在此范圍添加
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
注意：apache和php的源碼包在同一個目錄，--with-apache=../apache_1.3.27是指向源碼解壓的目錄
ok!靜態編譯完成。
再看DSO動態編譯方法：
首先編譯安裝apache
tar zvxf apache_1.3.29
cd apache_1.3.29
./configure --prefix=/usr/local/apache --enable-mole=so --enable-mole=rewrite --enable-shared=max
make
make install
so模塊用來提供DSO支持的apachehe核心模塊，rewrite是地址重寫的模塊，如果不需要可以不編譯enable－shared＝max是指除了so以外的所有標准模塊都編譯成DSO模塊。

然後編譯php
tar zvxf php4.3.4.tar.gz
cd php4.3.2
./configure --prefix=/usr/local/php --with-mysql=/usr/local/mysql --with-apxs=/usr/local/apache/bin/apxs
make
make install
然後修改httpd.conf，方法同靜態編譯的方法
OK，DSO動態編譯就完成了！

接下來我們講apache2.0.46+php4.3.2的動態編譯方法
一樣先編譯安裝apache
tar zvxf httpd-2.0.46.tar.gz
cd httpd-2.0.46
./configure --prefix=/usr/local/apache2 --enable-so --enable-mods-shared=most
make
make install

大家注意了--enable-so相當與1.3.27的--enable-mole=so，而--enable-mods-shared=most又等同與以前的--enable-shared=max
然後還是編譯PHP
tar zvxf php4.3.2.tar.gz
./configure --prefix=/usr/local/php --with-mysql=/usr/local/mysql --with-apxs2=/usr/local/apache2/bin/apxs
make
make install
注意這里是apxs2！！
修改httpd.conf與1.3.27也有所不同，大家尋找Add Type application/x-tar .tgz 在下面添加
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
另外要顯示中文的話，請修改:
AddDefaultCharset gb2312

㈦ Apache可移植運行庫apr在windows下怎麼編譯

如果是開發者則使用此選項，--with-included-apr利於連接apache的代碼或者是調試apache，其消除了由於版本或者編譯中跟APR或者APR-util代碼產生的不匹配； 如果從子版本編譯apache，要先運行buildconf（需要Python，GNU autoconf和libtool）