㈠ linux中Web伺服器的配置
你可以通過以下三種方法安裝Apache伺服器。
1．如果你安裝的Linux版本中帶用Apache的話，就在選擇所要安裝的服務
器的時候，將httpd這個服務選上，Linux安裝程序將自動完成Apache的安裝工
作，並做好基本的配置。
2．使用可執行文件軟體包，這比較適合那些對編譯工作不是太熟悉的初級
用戶，因為它相對比較簡單。
下載軟體包apache_1.2.4.e.tar.gz
tar xvzf apache_1.2.4.e.tar.gz
這就完成了安裝工作，簡單吧！
如果你使用的是RedHat Linux的話，你也可以下載apache_1.2.4.rpm軟體
安裝包，然後使用rpm -ivh apache_1.2.4.rpm命令安裝。
3．如果你想把Apache伺服器充分利用起來的話，就一定要自己編譯
Apache定製其功能。
下載包含Apache源代碼的軟體包apache_1.2.4.tar.gz； 然後用tar命令將它解
開； 將當前目錄改變為Apache源代碼發行版的src目錄； 將配置樣本文件
（Configuration.tmpl）復制為Configuration文件；
編輯Configuration文件中的配置選項：
Makefile配置選項：一些編譯選項：
. "CC="一行指定用什麼編譯軟體編譯，一般為"CC=gcc"；
. 如果需要將額外的標志（參數）指定給C編譯軟體，可以使用：
EXTRA_CFLAGS=
EXTRA_LFLAGS=
. 如果系統需要特殊的庫和包含文件，可以在這里指定它們：
EXTRA_LIBS=
EXTRA_INCLUDES=
. 如果你要改變代碼優化設置的話，你須將下面一句去掉注釋，然
後改成你所需要的值：
#OPTIM=-O2
Rule配置選項：用來決定需要什麼功能，一般情況下無需改變。
模塊配置：模塊是Apache的組成部分，它為Apache內核增加新功能。通過使用
模塊配置，可以自定義在Apache伺服器中需要什麼功能，這個部分也是Apache
靈活性的表現。模塊配置行如下所示：
AddMole moles/standard/mod_env.o
如果你需要Apache伺服器具備什麼功能，就將那個模塊用AddMole語句加到配
置文件Configuration中去。
下表列出了Apache的模塊功能：
模塊名 功能 預設
mod_access 提供基於主機的訪問控制命令 y
mod_actions 能夠運行基於MIME類型的CGI腳本或HTTP請求方法 y
mod_alias 能執行URL重定向服務 y
mod_asis 使文檔能在沒有HTTP頭標的情況下被發送到客戶端 y
mod_auth 支持使用存儲在文本文件中的用戶名、口令實現認證 y
mod_auth_dbm 支持使用DBM文件存儲基本HTTP認證 n
mod_auth_mysql 支持使用MySQL資料庫實現基本HTTP認證 n
mod_auth_anon 允許以匿名方式訪問需要認證的區域 y
mod_auth_external支持使用第三方認證 n
mod_autoindex 當缺少索引文件時，自動生成動態目錄列表 y
mod_cern_meta 提供對元信息的支持 n
mod_cgi 支持CGI y
mod_dir 能夠重定向任何對不包括尾部斜杠字元命令的請求 y
mod_env 使你能夠將環境變數傳遞給CGI或SSI腳本 n
mod_expires 讓你確定Apache在伺服器響應請求時如何處理Expires y
mod_headers 能夠操作HTTP應答頭標 y
mod_imap 提供圖形映射支持 n
mod_include 使支持SSI n
mod_info 對伺服器配置提供了全面的描述 y
mod_log_agent 允許在單獨的日誌文件中存儲用戶代理的信息 n
mod_log_config 支持記錄日誌 y
mod_log_referer 提供了將請求中的Referer頭標寫入日誌的功能 n
mod_mime 用來向客戶端提供有關文檔的元信息 y
mod_negotiation 提供了對內容協商的支持 y
mod_setenvif 使你能夠創建定製環境變數 y
mod_speling 使你能夠處理含有拼寫錯誤或大小寫錯誤的URL請求 n
mod_status 允許管理員通過WEB管理Apache y
mod_unique_id 為每個請求提供在非常特殊的條件下保證是唯一的標識 n
在src目錄下執行：". /configure"；
編譯Apache：執行命令"make"；
根據機器性能的不同，經歷一段5-30分鍾的編譯，就大功告成了。
將編譯好的可執行文件httpd復制到/etc/httpd/bin目錄下；
將Apache發行版的配置文件：access.conf、httpd.conf、mime.types、
srm.conf文件復制到/etc/httpd/conf目錄下。到此為止，安裝完成。
㈡ 伺服器的配置
WebLogic Server Scripting Tool(WLST)是一種命令行腳本工具，BEA公司計劃在WebLogic Server 9.0版本中包含它。現在，該工具及所有的服務包（service packs）都可以從BEA公司的dev2dev站點下載得到，並在WebLogic Server 7.0和8.0下運行。
背景知識
人們一直希望WebLogic Server支持一個腳本解決方案，以允許開發人員和系統管理員可靠地、互動式地對WebLogic Server配置執行簡單和復雜的更改。當前，WebLogic Server 支持三個命令行工具：weblogic.Admin、weblogic.Deployer和WLConfig Ant 任務工具。
這三個工具都需要一個運行的Weblogic Server實例。其中Weblogic.Admin和WLConfig用來修改配置和查詢MBean，weblogic.Deployer則嚴格用於部署應用程序。還有一些工具WebLogic Server不支持，但是用戶很熟悉，例如WLShell、Config2Admin和MBeanExplorer等。
許多用例如果使用一個簡單的腳本工具將會非常容易處理。例如，開發人員和管理員可能需要編寫腳本來配置伺服器，並且想要通過循環和其他流程式控制制結構來為伺服器增加配置元素。類似這樣的用例使人們迫切希望有一種可以讀取用戶腳本並且在WebLogic Server上運行的腳本語言解釋器。
WLST試圖解決一些當前WebLogic Server開發人員和管理員者所面臨的難題。這包括捕捉那些可重復的配置和部署工作，其中配置工作主要是將環境（應用程序和依賴性）准備為大環境的一部分）；在生命周期的某一級別或各個級別之間（例如開發和分段級別之間）的用戶間共享復雜的配置更改；以及跨一個拓撲結構的多個節點或者在一些其他范圍，迭代地應用相同的更改。向WebLogic Server增加對用戶定義腳本編程的支持，可以極大地增強可用性，從而提高用戶滿意度。使用WLST，用戶可以定製WebLogic Server，以滿足自己的需要，簡化日常任務，擴展其他功能。通過提供腳本來處理，重復的任務和復雜的過程現在可以被簡化。腳本語言擴展了Java語言，提高了開發速度。
簡介
WLST是WebLogic Server的一個命令行腳本介面。WLST腳本環境基於Java腳本解釋器（Jython）。WLST使您能夠利用所提供的WebLogic Server腳本功能，以及解釋型語言的共同特性。這些特性包括局部變數、條件變數和流程式控制制語句。WebLogic Server開發人員和管理員可以根據Jython語法，擴展WebLogic Server腳本語言來適應自己的需要。
Jython是高級、動態、面向對象語言Python的一個與Java平台無縫集成的實現。Jython是100%純Java的，由於它清晰簡單的語法，使得Jython非常容易學習。Jython的一個主要優點是您可以通過Jython解釋器調用任何Java對象。這就意味著用戶可以重用自己編寫的任何Java代碼或者Java工具。本文我們對Jython不做太多深究。關於Jython的更多信息，請訪問www.jython.org。
WLST 介紹
WLST有兩種版本，離線版和聯機版。離線版用來在用戶沒有連接到任何一個WebLogic Server實例的情況下，通過與域文件和配置模板交互來配置域。該功能類似於WebLogic Server 9.0中反對的配置向導（Configuration Wizard）靜寂模式腳本編程。聯機版用來在用戶連接到一個運行的WebLogic Server實例的情況下，更改配置工件或者監視運行時數據。現在兩個版本作為兩個獨立的JAR包提供下載。在WebLogic Server 9.0發布的時候，這兩個版本將會整合成為一個工具。
操作模式
WLST提供三種操作模式：交互模式、腳本模式和嵌入模式。在交互模式下，用戶在命令提示符下鍵入命令並查看響應。這種模式對於學習腳本工具及其功能是有用的。另外，對於原型設計命令語法以在編譯較大的腳本之前驗證選項，也是有用的。清單1中展示了一個互動式會話的例子。在腳本模式下，用戶可以把許多腳本命令寫在一個文件中，工具將該文件作為程序執行。清單2展示了一個可以在WLST上作為程序執行的簡單腳本。在嵌入模式下，用戶把WLST解釋器嵌入Java應用程序中（參見清單3）。
特性
WebLogic Server實現了JMX 1.0，並且所有子系統（JMS、JDBC、Security等）都被作為相應的MBean並包含屬性，可以按這些屬性來配置、監視和管理子系統。所有的MBean被組織為層次結構，DomainMBean是所有Configuration MBean的父節點，DomainRuntimeMBean是所有Runtime MBean的父節點。用戶可以通過調用不同的WLST命令定位任何MBean。為了簡單，定位大致相當於任何操作系統中的文件表示方法。
定位
按照操作系統的說法，WLST有三個驅動：config、runtime和custom。config驅動管理所有的Configuration MBean（DomainMBean是它們的父節點）。runtime驅動管理所有的Runtime MBean（DomainRuntimeMBean是它們的父節點）。custom驅動管理所有的Custom Mbean（非WebLogic的，而是用戶在WebLogic Server上注冊的）。MBean的類型或者實例就像目錄，用戶可以「cd」或者定位到這些MBean，以查看屬性名和值或操作（即文件）。清單4中的例子展示了一個用戶定位到不同的驅動和MBean然後列出其屬性和值。
配置
通過「configToScript」命令，用戶可以很方便地把資源從一個域移動到另一個域。這個命令以config.xml作參數，並將之轉換為相應的WSLT腳本，該腳本被應用於另一個域，以創建一個類似的配置。這個命令也可以創建一個包含名稱-值對的屬性文件。這些名稱-值對可以被修改，以創建具有不同域名、伺服器名等的配置。清單5演示了一個簡單的例子，其中config.xml被轉換為WSLT腳本。用戶也可以創建新的配置信息，以及檢索和更改存儲在域config.xml文件中或者是使用Template Builder創建的域模板JAR中的現有配置值。清單6展示了一個簡單的例子，用戶讀取一個現有的medrec模板，以創建一個medrec域。
當前託管對象（cmo）
每當用戶定位到一個MBean實例，他就具有通過cmo變數對這個MBean對象的訪問權。這個變數保存MBean的代理對象，所以用戶可以調用該MBean介面支持的所有方法或操作。清單7展示了一個可以使用這個變數的例子。
從WLST調用Java程序
如果您用Java編寫了命令行工具，並且想要在WLST中重用，這是完全可以做到的。例如，我編寫了一個簡單的Java程序，用來查詢MBeanServer並檢索注冊在這台伺服器上的所有MBean，然後列印它們的對象名稱。好處是我不必拋開這些有用的代碼或者用Jython重新進行編寫，只要從WLST中調用這個程序就行了。清單8顯示了這個用Java編寫的程序，以及用戶如何從WLST中調用該程序。
從Ant中調用WLST
許多用戶使用Ant自動完成Weblogic域的配置，如果您願意把您的WLST配置腳本嵌入Ant編譯文件（build file），那麼您也可以這樣做。清單9展示了編譯文件的一個片斷，它調用WLST來運行腳本。
擴展WLST命令
WLST定義了一些常用的命令，但這並不限制用戶去定義自定義的命令或者模塊，然後把它們導入WLST以滿足他們的需要。清單10定義了兩個自定義的命令：「creatServer」和「deleteServer」。它們創建和刪除具有指定名稱的伺服器。這些命令將會對於WLST會話是活躍的。用戶也可以編寫一些定義幾個有用功能並能導入WLST中的模塊。清單11展示的例子中，用戶定義了一個安全類，這個類包括創建用戶、更改密碼等實用功能。
WLST模塊
用戶常常想將WLST與其他Jython模塊一起使用。這只要把WLST模塊寫入一個文件，並把這個文件導入到您的Jython模塊中就可以了。清單12展示了如何編寫WLST模塊並在Jython模塊中使用。有關更多信息，請訪問http://dev2dev.bea.com/codelibrary/code/posample.jsp。
WLST 工作方式
讓我們完成一個簡單的用例，其中展示了使用WLST的端到端場景。假設一個管理員打算為開發人員配置一個域。本質上，他會從頭開始創建一個域（一個admin 伺服器），啟動伺服器，配置託管伺服器，並群集和部署應用程序。他也會通過一個簡單的腳本監視這些伺服器的狀況。步驟如下：
根據模板創建一個簡單的域（一個admin伺服器），並啟動伺服器（見清單13）。
配置兩個託管伺服器和一個群集。在連接到正在運行的admin伺服器之後，添加這兩個託管伺服器到這個集群，並啟動該群集。另外，部署一個簡單的應用程序到該群集（見清單14）。
使用一個簡單的監視腳本，監視伺服器的狀態（見清單15）。
前瞻
WLST可以在BEA公司的dev2dev站點上下載。這個工具可以與WebLogic Server 7.0和8.1（以及所有的服務包）一起工作。BEA公司的Management新聞組提供對這個工具的支持。這個工具可以在明年發布的WebLogic Server 9.0中正式得到並受到支持。BEA公司也打算在WebLogic Server 7.1和8.1兩個版本中直接支持WLST。
一些您所期待的WLST的新特性：
通過JSR 88 API進行的部署，包括通過WLST進行的部署計劃的編輯。
通過WLST對所有診斷框架（WebLogic Server 9.0中新引入的）工件的訪問。
離線版WLST（現在可以單獨下載）與現有聯機版WLST的合並。
對新的 (WebLogic Server 9.0) 管理API的訪問。
支持WebLogic Server 9.0中所有的新節點管理器特性。
結束語
在這篇文章中，我介紹了一個新工具——WLST，它使開發人員和系統管理員能更方便地管理WebLogic Server（聯機或者離線都可以），並能對WebLogic Server執行配置更改。WLST有三種使用模式：交互模式、腳本模式和嵌入模式。它提供了一個簡單的方法訪問WebLogic Server中的MBean，並且提供了一些方便的命令用於監視WebLogic Server實例的生命周期。WLST是用Jython（Jython是流行的Python語言的純Java實現）語言編寫的。
參考資料
Online WLST Tool: http://dev2dev.bea.com/codelibrary/code/wlst.jsp
Offline WLST Tool: http://dev2dev.bea.com/codelibrary/code/wlst_offline.jsp
Jython's Main Web Site: www.jython.org
PO Sample: http://dev2dev.bea.com/codelibrary/code/posample.jsp
㈢ 如何編譯配置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命令中使用。 如果你打算只進行默認安裝，而且從來沒有想到過要改變任何一個選項，那麼使用哪一種方法進行配製就無關緊要了
㈣ 什麼樣配置的電腦可以當伺服器
1、首先自然是操作系統的安裝了，伺服器的操作系統又分為了windows操作系統和linux操作系統，首先我們來你看下windows伺服器操作系統，比較常用的就是windows server 2003了，當然還有2008和2012，當然沒有2003常用罷了。
2、接著來看下linux操作系統，相比於windows伺服器操作系統，linux操作系統更加安全，一來是會使用linux系統的用戶並不多，二來是因為用戶許可權，一般登陸linux操作系統的用戶都是普通用戶，很多操作許可權都受限制，因此更加安全。常用的linux操作系統有redhat，centos,ubuntu等。
3、想要成為伺服器，聯網是必須的，平時我們使用的一般都是虛擬撥號上網，每次重啟貓的時候IP地址都會變，這樣不利於用戶的訪問，因此我們必須申請一個靜態IP地址，這也是我們架設伺服器的重要條件，靜態IP可以像寬頻供應商提供，應該不是什麼難的事情。
4、如果你的網站都是靜態網頁的話，完成以上步驟就可以了，但是如果你的網站有用到動態網頁的話，我們就需要安裝web伺服器了，windows伺服器操作系統下安裝的web伺服器一般為IIS伺服器，而linux操作系統下安裝的web伺服器一般為apache伺服器，這兩種是比較常用的web伺服器。目前nginx伺服器也是異軍突起，大有和前兩者一較高下之勢。
5、動態網頁的製作離不開後台程序的支持，我們平時比較常用的後台程序有jsp，asp，php，想要編譯這些後台程序文件，我們就需要在web伺服器中載入對應的組件一邊支持這種格式的文件，不同的web伺服器設置的方法也不同，如果有需要的話可以上網搜索相關教程。
6、動態網頁一般都會跟資料庫交互數據，因此資料庫也是必須要安裝的，資料庫的種類也是很多的，常用的有mysql，mssql,oracle,access等等，資料庫的選擇一般都跟後台程序和web伺服器都有關系，不同的web伺服器和後台程序，資料庫也不相同。
7、有了這些軟體，不管是動態網站或者靜態網站都可以支持了。作為伺服器，讓用戶進行操作也是必須的，用戶操作可以分為FTP操作和遠程操作伺服器兩種，首先我們介紹下FTP操作。相信很多站長管理自己的站點都是使用的FTP，作為服務端，我們需要安裝的是類似ServU一類FTP伺服器端軟體，為用戶架設FTP賬號。
8、還有一種管理方式就是直接遠程操作伺服器了，想要遠程操作伺服器，首先必須為伺服器建立一個用戶名和密碼，其次就是開啟遠程桌面，只有滿足這兩點，才能遠程操作伺服器。開啟遠程桌面的方法很簡單，只需要右擊我的電腦，點擊屬性，找到遠程，勾選遠程桌面即可。
以上的操作均完成後，一個計算機就變身成為了伺服器，作為伺服器，24小時開機是必須的，一旦你的電腦關機之後，這里的站點自然就不能夠被訪問了，至於你的電腦能夠掛幾個網站，這要看看它的負載能力了，伺服器的負載能力跟計算機的硬體配置有關系。
㈤ 在Linux中，如何配置WWW伺服器
Apache伺服器的設置文件位於/usr/local/apache/conf/目錄下，傳統上使用三個配置文件httpd.conf,access.conf和srm.conf，來配置Apache伺服器的行為。
httpd.conf提供了最基本的伺服器配置，是對守護程序httpd如何運行的技術描述；srm.conf是伺服器的資源映射文件，告訴伺服器各種文件的MIME類型，以及如何支持這些文件；access.conf用於配置伺服器的訪問許可權，控制不同用戶和計算機的訪問限制；這三個配置文件控制著伺服器的各個方面的特性，因此為了正常運行伺服器便需要設置好這三個文件。
除了這三個設置文件之外，Apache還使用mime.types文件用於標識不同文件對應的MIME類型， magic文件設置不同MIME類型文件的一些特殊標識，使得Apache 伺服器從文檔後綴不能判斷出文件的MIME 類型時，能通過文件內容中的這些特殊標記來判斷文檔的MIME類型。
bash-2.02$ ls -l /usr/local/apache/conf
total 100
-rw-r--r-- 1 root wheel 348 Apr 16 16:01 access.conf
-rw-r--r-- 1 root wheel 348 Feb 13 13:33 access.conf.default
-rw-r--r-- 1 root wheel 30331 May 26 08:55 httpd.conf
-rw-r--r-- 1 root wheel 29953 Feb 13 13:33 httpd.conf.default
-rw-r--r-- 1 root wheel 12441 Apr 19 15:42 magic
-rw-r--r-- 1 root wheel 12441 Feb 13 13:33 magic.default
-rw-r--r-- 1 root wheel 7334 Feb 13 13:33 mime.types
-rw-r--r-- 1 root wheel 383 May 13 17:01 srm.conf
-rw-r--r-- 1 root wheel 357 Feb 13 13:33 srm.conf.default
事實上當前版本的Apache將原來httpd.conf、srm.conf與access.conf中的所有配置參數均放在了一個配置文件httpd.conf中，只是為了與以前的版本兼容的原因（使用這三個設置文件的方式來源於NCSA-httpd），才使用三個配置文件。而提供的access.conf和srm.conf文件中沒有具體的設置。
由於在新版本的Apache中，所有的設置都被放在了httpd.conf中，因此只需要調整這個文件中的設置。以下使用預設提供的httpd.conf為例，解釋Apache伺服器的各個設置選項。然而不必因為它提供設置的參數太多而煩惱，基本上這些參數都很明確，也可以不加改動運行Apache伺服器。但如果需要調整Apache伺服器的性能，以及增加對某種特性的支持，就需要了解這些設置參數的含義。
關於Apache伺服器的性能，在Internet上存在很大的爭議，基本上使用Apache的使用者幾乎都不懷疑它的優秀性能，Apache也支撐了很多著名的高負載的網站，但是在商業機構的評測中，Apache往往得分不高。很多人指出，在這些評測中，商業Web伺服器及其操作系統往往由其專業公司的工程師進行過性能調整，而Free 的操作系統和Web伺服器往往就使用其預設配置或僅僅作很小的更改。需要指出的是，除了操作系統的性能調整之外，Apache 伺服器本身的預設配置絕不是最優化和最高效的，而是要適應幾乎所有種類操作系統、所有種類硬體下的設置，多平台的軟體不可能為特定平台和特定硬體提供最優化的預設配置。因此要使用Apache的時候，性能調整是必不可少的。
在商業評測中忽略了的另一個事實是，評測時往往對不同種類的功能進行比較，例如使用Apache的標准CGI 的性能與ISAPI，NSAPI等伺服器端API比較，事實上Apache伺服器與此可以比較的功能為modperl ，FastCGI，與ASP類似的功能為PHP等等，只不過由於Apache的開放模式，這些功能是由獨立的開發組，作為獨立的模塊來實現的。但是在評測中，測試人員沒有加入相應的模塊評測其性能。
HTTP守護進程的運行參數
httpd.conf中首先定義了一些httpd守護進程運行時需要的參數，來決定其運行方式和運行環境。
ServerType standalone
ServerType定義伺服器的啟動方式，預設值為獨立方式standalone，httpd
伺服器將由其本身啟動，並駐留在主機中監視連接請求。在Linux下將在啟動文件 /etc/rc.d/rc.local/init.d/apache中自動啟動Web伺服器，這種方式是推薦設置。
啟動Apache伺服器的另一種方式是inet方式，使用超級伺服器inetd監視連接請求並啟動伺服器。當需要使用inetd啟動方式時，便需要更改為這個設置，並屏蔽/etc/rc.d/rc.local/init.d/apache文件，以及更改/etc/inetd.conf並重起inetd，那麼Apache就能從inetd中啟動了。
兩種方式的區別是獨立方式是由伺服器自身管理自己的啟動進程，這樣在啟動時能立即啟動伺服器的多個副本，每個副本都駐留在內存中，一有連接請求不需要生成子進程就可以立即進行處理，對於客戶瀏覽器的請求反應更快，性能較高。而 inetd方式要由inetd發現有連接請求後才去啟動http伺服器，由於inetd 要監聽太多的埠，因此反應較慢、效率較低，但節約了沒有連接請求時Web伺服器佔用的資源。因此inetd方式只用於偶爾被訪問並且不要求訪問速度的伺服器上。事實上inetd方式不適合http的突發和多連接的特性，因為一個頁面可能包含多個圖象，而每個圖象都會引起一個連接請求，即使雖然訪問人數造成教少，但瞬間的連接請求並不少，這就受到inetd性能的限制，甚至會影響由inetd啟動的其他伺服器程序。
ServerRoot "/usr/local"
ServerRoot用於指定守護進程httpd的運行目錄，httpd在啟動之後將自動將進程的當前目錄改變為這個目錄，因此如果設置文件中指定的文件或目錄是相對路徑，那麼真實路徑就位於這個ServerRoot定義的路徑之下。
由於httpd會經常進行並發的文件操作，就需要使用加鎖的方式來保證文件操作不沖突，由於NFS文件系統在文件加鎖方面能力有限，因此這個目錄應該是本地磁碟文件系統，而不應該使用NFS文件系統。
#LockFile /var/run/httpd.lock
LockFile參數指定了httpd守護進程的加鎖文件，一般不需要設置這個參數， Apache伺服器將自動在ServerRoot下面的路徑中進行操作。但如果ServerRoot為NFS文件系統，便需要使用這個參數指定本地文件系統中的路徑。
PidFile /var/run/httpd.pid
PidFile指定的文件將記錄httpd守護進程的進程號，由於httpd能自動復制其自身，因此系統中有多個httpd進程，但只有一個進程為最初啟動的進程，它為其他進程的父進程，對這個進程發送信號將影響所有的httpd進程。PidFILE定義的文件中就記錄httpd父進程的進程號。
ScoreBoardFile /var/run/httpd.scoreboard
httpd使用ScoreBoardFile來維護進程的內部數據，因此通常不需要改變這個參數，除非管理員想在一台計算機上運行幾個Apache伺服器，這時每個Apache伺服器都需要獨立的設置文件htt pd.conf，並使用不同的ScoreBoardFile。
#ResourceConfig conf/srm.conf
#AccessConfig conf/access.conf
這兩個參數ResourceConfig和AccessConfig，就用於和使用 srm.conf 和 access.conf 設置文件的老版本Apache兼容。如果沒有兼容的需要，可以將對應的設置文件指定為/dev/null，這將表示不存在其他設置文件，而僅使用httpd.conf 一個文件來保存所有的設置選項。
Timeout 300
Timeout定義客戶程序和伺服器連接的超時間隔，超過這個時間間隔（秒）後伺服器將斷開與客戶機的連接。
KeepAlive On
在HTTP 1.0中，一次連接只能作傳輸一次HTTP請求，而KeepAlive參數用於支持HTTP 1.1版本的一次連接、多次傳輸功能，這樣就可以在一次連接中傳遞多個HTTP請求。雖然只有較新的瀏覽器才支持這個功能，但還是打開使用這個選項。
MaxKeepAliveRequests 100
MaxKeepAliveRequests為一次連接可以進行的HTTP請求的最大請求次數。將其值設為0將支持在一次連接內進行無限次的傳輸請求。事實上沒有客戶程序在一次連接中請求太多的頁面，通常達不到這個上限就完成連接了。
KeepAliveTimeout 15
KeepAliveTimeout測試一次連接中的多次請求傳輸之間的時間，如果伺服器已經完成了一次請求，但一直沒有接收到客戶程序的下一次請求，在間隔超過了這個參數設置的值之後，伺服器就斷開連接。
MinSpareServers 5MaxSpareServers 10
在使用子進程處理HTTP請求的Web伺服器上，由於要首先生成子進程才能處理客戶的請求，因此反應時間就有一點延遲。但是，Apache伺服器使用了一個特殊技術來擺脫這個問題，這就是預先生成多個空餘的子進程駐留在系統中，一旦有請求出現，就立即使用這些空餘的子進程進行處理，這樣就不存在生成子進程造成的延遲了。在運行中隨著客戶請求的增多，啟動的子進程會隨之增多，但這些伺服器副本在處理完一次HTTP請求之後並不立即退出，而是停留在計算機中等待下次請求。但是空餘的子進程副本不能光增加不減少，太多的空餘子進程沒有處理任務，也佔用伺服器的處理能力，因此也要限制空餘副本的數量，使其保持一個合適的數量，使得既能及時回應客戶請求，又能減少不必要的進程數量。
因此就可以使用參數MinSpareServers來設置最少的空餘子進程數量， 以及使用參數MaxSpareServers 來限制最多的空閑子進程數量，多餘的伺服器進程副本就會退出。根據伺服器的實際情況來進行設置，如果伺服器性能較高，並且也被頻繁訪問，就應該增大這兩個參數的設置。對於高負載的專業網站，這兩個值應該大致相同，並且等同於系統支持的最多伺服器副本數量，也減少不必要的副本退出。
StartServers 5
StartServers參數就是用來設置httpd啟動時啟動的子進程副本數量，這個參數與上面定義的MinSpareServers和MaxSpareServers參數相關，都是用於啟動空閑子進程以提高伺服器的反應速度的。這個參數應該設置為前兩個值之間的一個數值，小於MinSpareServers和大於MaxS pareServers都沒有意義。
MaxClients 150
在另一方面，伺服器的能力畢竟是有限的，不可能同時處理無限多的連接請求，因此參數Maxclient s就用於規定伺服器支持的最多並發訪問的客戶數，如果這個值設置得過大，系統在繁忙時不得不在過多的進程之間進行切換來為太多的客戶進行服務，這樣對每個客戶的反應就會減慢，並降低了整體的效率。如果這個值設置的較小，那麼系統繁忙時就會拒絕一些客戶的連接請求。當伺服器性能較高時，就可以適當增加這個值的設置。對於專業網站，應該使用提高伺服器效率的策略，因此這個參數不能超過硬體本身的限制，如果頻繁出現拒絕訪問現象，就說明需要升級伺服器硬體了。對於非專業網站，不太在意對客戶瀏覽器的反應速度，或者認為反應速度較慢也比拒絕連接好，就也可以略微超過硬體條件來設置這個參數。
這個參數限制了MinSpareServers和MaxSpareServers的設置，它們不應該大於這個參數的設置。
MaxRequestsPerChild 30
使用子進程的方式提供服務的Web服務，常用的方式是一個子進程為一次連接服務，這樣造成的問題就是每次連接都需要生成、退出子進程的系統操作，使得這些額外的處理過程占據了計算機的大量處理能力。因此最好的方式是一個子進程可以為多次連接請求服務，這樣就不需要這些生成、退出進程的系統消耗，Apache就採用了這樣的方式，一次連接結束後，子進程並不退出，而是停留在系統中等待下一次服務請求，這樣就極大的提高了性能。
但由於在處理過程中子進程要不斷的申請和釋放內存，次數多了就會造成一些內存垃圾，就會影響系統的穩定性，並且影響系統資源的有效利用。因此在一個副本處理過一定次數的請求之後，就可以讓這個子進程副本退出，再從原始的httpd進程中重新復制一個干凈的副本，這樣就能提高系統的穩定性。這樣，每個子進程處理服務請求次數由MaxRe questPerChild定義。 預設的設置值為30，這個值對於具備高穩定性特點的Linux系統來講是過於保守的設置，可以設置為1000甚至更高，設置為0支持每個副本進行無限次的服務處理。
#Listen 3000
#Listen 12.34.56.78:80
#BindAddress *
Listen參數可以指定伺服器除了監視標準的80埠之外，還監視其他埠的HTTP請求。由於FreeBSD系統可以同時擁有多個IP地址，因此也可以指定伺服器只聽取對某個BindAddress< /B>的IP地址的HTTP請求。如果沒有配置這一項，則伺服器會回應對所有IP的請求。
即使使用了BindAddress參數，使得伺服器只回應對一個IP地址的請求，但是通過使用擴展的Listen參數，仍然可以讓HTTP守護進程回應對其他IP地址的請求。此時Listen參數的用法與上面的第二個例子相同。這種比較復雜的用法主要用於設置虛擬主機。此後可以用VirtualHost參數定義對不同IP的虛擬主機，然而這種用法是較早的HTTP 1.0標准中設置虛擬主機的方法，每針對一個虛擬主機就需要一個IP地址，實際上用處並不大。在HTTP 1.1中，增加了對單IP地址多域名的虛擬主機的支持，使得虛擬主機的設置具備更大的意義。
LoadMole mime_magic_mole libexec/apache/mod_mime_magic.so
LoadMole info_mole libexec/apache/mod_info.so
LoadMole speling_mole libexec/apache/mod_speling.so
LoadMole proxy_mole libexec/apache/libproxy.so
LoadMole rewrite_mole libexec/apache/mod_rewrite.so
LoadMole anon_auth_mole libexec/apache/mod_auth_anon.so
LoadMole db_auth_mole libexec/apache/mod_auth_db.so
LoadMole digest_mole libexec/apache/mod_digest.so
LoadMole cern_meta_mole libexec/apache/mod_cern_meta.so
LoadMole expires_mole libexec/apache/mod_expires.so
LoadMole headers_mole libexec/apache/mod_headers.so
LoadMole usertrack_mole libexec/apache/mod_usertrack.so
LoadMole unique_id_mole libexec/apache/mod_unique_id.so
ClearMoleList
AddMole mod_env.c
AddMole mod_log_config.c
AddMole mod_mime_magic.c
AddMole mod_mime.c
AddMole mod_negotiation.c
AddMole mod_status.c
AddMole mod_info.c
AddMole mod_include.c
AddMole mod_autoindex.c
AddMole mod_dir.c
AddMole mod_cgi.c
AddMole mod_asis.c
AddMole mod_imap.c
AddMole mod_actions.c
AddMole mod_speling.c
AddMole mod_userdir.c
AddMole mod_proxy.c
AddMole mod_alias.c
AddMole mod_rewrite.c
AddMole mod_access.c
AddMole mod_auth.c
AddMole mod_auth_anon.c
AddMole mod_auth_db.c
AddMole mod_digest.c
AddMole mod_cern_meta.c
AddMole mod_expires.c
AddMole mod_headers.c
AddMole mod_usertrack.c
AddMole mod_unique_id.c
AddMole mod_so.c
AddMole mod_setenvif.c
Apache伺服器的一個重要特性就是其模塊化的結構，這不但表現為其能在編譯時能通過新的模塊加入新的功能，還表現為其模塊可以動態載入入http服務程序中，而不必載入不需要的模塊。使用Apache的動態載入模塊只需要設置好Load Mole和AddMole參數就可以了，這種特性就是Apache的 DSO（Dynamic Shared Object）特性，然而要想充分使用DSO特性仍然不是一個簡單的事情，不適當的改動這里的設置就可能造成伺服器不能正常啟動。因此如果不是要增加或減少伺服器提供的功能，就不要改動這里的設置。
上面這些列表就顯示了Linux下的預設Apache伺服器支持的模塊，事實上很多模塊是沒有必要的，不必要模塊不會被載入內存。模塊可以靜態連接到pache 伺服器內部，也可以這樣動態載入，將Apache的特性都編譯成動態可載入模塊是該Port的做法，而不是Apache的預設做法，這樣就以犧牲很小的性能的同時，帶來極大的靈活性。
因而動態可載入的能力還是對性能有輕微的影響，因此可以重新編譯Apache，將自己所需要的功能編譯進Apache 伺服器內部，可以讓系統顯得更為干凈，效率也有輕微的提高。通常僅僅為了這一個目的就重新編譯Apache是沒有必要的，如果需要增加其他特性而重新編譯Apache，不妨在增加其他模塊的同時將所有的模塊都靜態連接入Apache 伺服器。有的使用者更喜歡動態載入模塊，那麼也不妨全部都使用動態載入模塊。
這些模塊都被放置到/usr/local/apache/libexec/目錄下， 每個模塊對應Apache伺服器的一個特性。詳細解釋每個模塊的功能需要相當多的篇幅，其中比較重要的特性將在後面相應的地方中進行解釋，而具體每個模塊的功能及用法就需要查看Apache的文檔。
#ExtendedStatus On
Apache伺服器可以通過特殊的HTTP請求，來報告自身的運行狀態，打開這個ExtendedStatus 參數可以讓伺服器報告更全面的運行狀態信息。
㈥ 如何對lighttpd進行交叉編譯安裝並配置lighttpdweb伺服器
1. 編譯、安裝
1.1. 先到lighttpd官網下載對應版本的軟體包：
http://www.lighttpd.net/
我下載的是 lighttpd-1.4.30.tar.gz
1.2. 將壓縮包解壓到任意目錄（我的是 /root/Desktop/common）得到文件夾 lighttpd-1.4.30
1.3. 在文件夾 lighttpd-1.4.30 中創建shell腳本，命名為：configure-arm.sh
1.4. 在shell腳本 configure-arm.sh 中輸入如下代碼：
#! /bin/sh
CC=arm-linux-gcc
AR=arm-linux-ar LD=arm-linux-ld RANLIB=arm-linux-ranlib
STRIP=arm-linux-strip ./configure --prefix=/opt/web/lighttpd-1.4.30-arm
--host=arm-linux --build=i686-pc-linux --disable-FEATURE --enable-shared
--disable-static --disable-lfs --disable-ipv6 --without-PACKAGE
--without-valgrind --without-openssl --without-kerberos5 --without-pcre
--without-zlib --without-bzip2 --without-lua
1.5. 打開控制台，cd進入 lighttpd-1.4.30 目錄
1.6. 給 configure-arm.sh 文件添加可執行屬性，執行命令：
chmod +x configure-arm.sh
1.7. 配置lighttpd，執行命令：
./configure-arm.sh
1.8. 編譯lighttpd，執行命令：
make
1.9. 安裝lighttpd，執行命令：
make install
㈦ android 編譯伺服器大概需要什麼配置 5
工欲善其事，必先利其器」，要想提高團隊整體的開發效率，盡可能的提前完成開發任務，必須要配備一套配置給力的開發設備。源碼編譯伺服器硬體配置的高低，直接影響著系統固件升級和ROM版本發布的速度和效率。
由於目前Google發布的最新版本的Android系統源碼體積越來越大，因此，越是定製高版本的系統，對編譯伺服器的硬體配置要求就越高，這里根據調研，給出目前Android
6.0及以下版本源碼定製開發的基本配置，供大家參考。
首先進行一波企業級android源碼編譯伺服器的推薦，這類推薦網上絕無僅有，這還是我進行了很久的調研，詢問很多朋友【其中包括不乏6年以上系統開發的大牛，也有之前公司的主管等】，也查了很多資料才挑選出來，提出需求後讓上級審批，目前上一級已經認可比審批，等待領導簽字。給力。
詳細
㈧ ubuntu10.10 伺服器版要求什麼硬體配置
差別不是特別大。。。但是一般的電腦裝不了，沒驅動的。建議你還是考慮用專業的伺服器配置吧。
你可以看看國產品牌正睿的這款單路四核伺服器，它採用英特爾最新的nahalem平台架構，標配一顆至強®X3430四核處理器(2.4GHz/8M緩存)，英特爾3420伺服器晶元組主板，2G DDR3 1333MHz高性能內存，SATA2 320G硬碟，雙千兆網卡，性能可以說是非常的不錯。
產品型號：I145738S-E
產品類型：單路四核塔式伺服器
處 理 器：Xeon X3430
內 存：2G DDR3
硬 盤：SATA2 320G
機 構：塔式
價 格：￥3999
銀牌服務
重慶五年免費上門服務，全國三年免費上門服務，關鍵部件三年以上免費質保。
給你推薦的是國產品牌正睿的伺服器產品，他們的產品性價比很高，做工很專業，兼容性，質量之類的都有保障，售後也很完善，3年免費質保，3年免費上門服務，在業界口碑很不錯。
㈨ 編譯伺服器對電腦的硬體有何要求
沒什麼要求,電腦配置越高編譯速度越快
㈩ 開發團隊有14個人是做android開發的，想為他們配置 一台linux編譯伺服器，該怎麼配
配置maven，svn，配置maven庫，代碼用svn同步
好處么~大約就是依賴包版本統一啊，版本控制方便神馬的