Linux精華 Tomcat伺服器配置技巧詳解分析

伺服器|技巧|精華|詳解

1、配置系統管理（Admin Web Application）
　　
　　大多數商業化的J2EE伺服器都提供一個功能強大的管理介面，且大都採用易於理解的Web應用介面。Tomcat按照自己的方式，同樣提供一個成熟的管理工具，並且絲毫不遜於那些商業化的競爭者。Tomcat的Admin Web Application最初在4.1版本時出現，當時的功能包括管理context、data source、user和group等。當然也可以管理像初始化參數，user、group、role的多種資料庫管理等。在後續的版本中，這些功能將得到很大的擴充，但現有的功能已經非常實用了。Admin Web Application被定義在自動部署檔案：CATALINA_BASE/webapps/admin.xml 。（譯者註：CATALINA_BASE即tomcat安裝目錄下的server目錄）
　　
　　你必須編輯這個檔案，以確定Context中的docBase參數是絕對路徑。也就是說，CATALINA
　　
　　_BASE/webapps/admin.xml的路徑是絕對路徑。作為另外一種選擇，你也可以刪除這個自動部署檔案，而在server.xml檔案中建立一個Admin Web Application的context，效果是一樣的。你不能管理Admin Web Application這個應用，換而言之，除了刪除CATALINA_BASE/webapps/admin.xml ，你可能什麼都做不了。
　　
　　如果你使用UserDatabaseRealm（預設），你將需要添加一個user以及一個role到CATALINA_BASE/conf/tomcat-users.xml檔案中。你編輯這個檔案，添加一個名叫“admin”的role 到該檔案中，如下：
　　
　　＜role name="admin"/＞
　　
　　你同樣需要有一個使用者，並且這個使用者的角色是“admin”。象存在的使用者那樣，添加一個使用者（改變密碼使其更加安全）：
　　
　　＜user name="admin"
　　password="deep_dark_secret"
　　roles="admin"/＞
　　
　　當你完成這些步驟後，請重新啟動Tomcat，訪問http://localhost:8080/admin，你將看到一個登入介面。Admin Web Application採用基於容器管理的安全機制，並採用了Jakarta Struts架構。一旦你作為“admin”角色的使用者登入管理介面，你將能夠使用這個管理介面配置Tomcat。
　　
　　2、配置應用管理（Manager Web Application）
　　
　　Manager Web Application讓你通過一個比Admin Web Application更為簡單的使用者介面，執行一些簡單的Web應用任務。Manager Web Application被被定義在一個自動部署檔案中：
　　
　　CATALINA_BASE/webapps/manager.xml
　　
　　你必須編輯這個檔案，以確保context的docBase參數是絕對路徑，也就是說CATALINA_HOME/server/webapps/manager的絕對路徑。（譯者註：CATALINA_HOME即tomcat安裝目錄）
　　
　　如果你使用的是UserDatabaseRealm，那麼你需要添加一個角色和一個使用者到CATALINA_BASE/conf/tomcat-users.xml檔案中。接下來，編輯這個檔案，添加一個名為“manager”的角色到該檔案中：
　　
　　＜role name=”manager”＞
　　
　　你同樣需要有一個角色為“manager”的使用者。像已經存在的使用者那樣，添加一個新使用者（改變密碼使其更加安全）：
　　
　　＜user name="manager"
　　password="deep_dark_secret"
　　roles="manager"/＞
　　
　　然後重新啟動Tomcat，訪問http://localhost/manager/list，將看到一個很樸素的文本型管理介面，或者訪問http://localhost/manager/html/list，將看到一個HMTL的管理介面。不管是哪種方式都說明你的Manager Web Application現在已經啟動了。
　　
　　Manager application讓你可以在沒有系統管理特權的基礎上，安裝新的Web應用，以用於測試。如果我們有一個新的web應用位於/home/user/hello下在，並且想把它安裝到/hello下，為了測試這個應用，我們可以這麼做，在第一個檔案框中輸入“/hello”（作為訪問時的path），在第二個文字框中輸入“file:/home/user/hello”（作為Config URL）。
　　
　　Manager application還允許你停止、重新啟動、移除以及重新部署一個web應用。停止一個應用使其無法被訪問，當有使用者嘗試訪問這個被停止的應用時，將看到一個503的錯誤??“503 - This application is not currently available”。
　　
　　移除一個web應用，只是指從Tomcat的運行拷貝中刪除了該應用，如果你重新啟動Tomcat，被刪除的應用將再次出現（也就是說，移除並不是指從硬碟上刪除）。
　　
　　3、部署一個web應用
　　
　　有兩個辦法可以在系統中部署web服務。
　　
　　1. 拷貝你的WAR檔案或者你的web應用檔案夾（包括該web的所有內容）到$CATALINA_BASE/webapps目錄下。
　　
　　2. 為你的web服務建立一個只包括context內容的XML片斷檔案，並把該檔案放到$CATALINA_BASE/webapps目錄下。這個web應用本身可以儲存在硬碟上的任何地方。
　　
　　如果你有一個WAR檔案，你若想部署它，則只需要把該檔案簡單的拷貝到CATALINA_BASE/webapps目錄下即可，檔案必須以“.war”作為副檔名。一旦Tomcat監聽到這個檔案，它將（預設的）解開該檔案包作為一個子目錄，並以WAR檔案的檔案名稱作為子目錄的名字。
　　
　　接下來，Tomcat將在記憶體中建立一個context，就好象你在server.xml檔案裡建立一樣。當然，其他必需的內容，將從server.xml中的DefaultContext獲得。
　　
　　部署web應用的另一種方式是寫一個Context XML片斷檔案，然後把該檔案拷貝到CATALINA_BASE/webapps目錄下。一個Context片斷並非一個完整的XML檔案，而只是一個context元素，以及對該應用的相應描述。
　　
　　這種片斷檔案就像是從server.xml中切取出來的context元素一樣，所以這種片斷被命名為“context片斷”。
　　
　　舉個例子，如果我們想部署一個名叫MyWebApp.war的應用，該應用使用realm作為存取控制方式，我們可以使用下面這個片斷：
　　
　　＜!--
　　Context fragment for deploying MyWebApp.war
　　--＞
　　＜Context path="/demo"
　　docBase="webapps/MyWebApp.war"
　　debug="0" privileged="true"＞
　　＜Realm className=
　　"org.apache.catalina.realm.UserDatabaseRealm"
　　resourceName="UserDatabase"/＞
　　＜/Context＞
　　
　　把該片斷命名為“MyWebApp.xml”，然後拷貝到CATALINA_BASE/webapps目錄下。
　　
　　這種context片斷提供了一種便利的方法來部署web應用，你不需要編輯server.xml，除非你想改變預設的部署特性，安裝一個新的web應用時不需要重啟動Tomcat。
　　
　　4、配置虛擬機器主機（Virtual Hosts）
　　
　　關於server.xml中“Host”這個元素，只有在你設定虛擬機器主機的才需要修改。虛擬機器主機是一種在一個web伺服器上服務多個網域名稱的機制，對每個網域名稱而言，都好象獨享了整個主機。實際上，大多數的小型商務網站都是採用虛擬機器主機實現的，這主要是因為虛擬機器主機能直接連接到Internet並提供相應的頻寬，以保障合理的訪問響應速度，另外虛擬機器主機還能提供一個穩定的固定IP。
　　
　　基於名字的虛擬機器主機可以被建立在任何web伺服器上，建立的方法就是通過在網域名稱伺服器（DNS）上建立IP地址的別名，並且告訴web伺服器把去往不同網域名稱的請求分發到相應的網頁目錄。因為這篇文章主要是講Tomcat，我們不準備介紹在各種作業系統上設定DNS的方法，如果你在這方面需要協助，請參考《DNS and Bind》一書，作者是Paul Albitz and Cricket Liu (O'Reilly)。為了示範方便，我將使用一個靜態主機檔案，因為這是測試別名最簡單的方法。
　　
　　在Tomcat中使用虛擬機器主機，你需要設定DNS或主機資料。為了測試，為本地IP設定一個IP別名就足夠了，接下來，你需要在server.xml中添加幾行內容，如下：
　　
　　＜Server port="8005"
　　shutdown="SHUTDOWN" debug="0"＞
　　＜Service name="Tomcat-Standalone"＞
　　＜Connector className=
　　"org.apache.coyote.tomcat4.CoyoteConnector"
　　port="8080"
　　minProcessors="5" maxProcessors="75"
　　enableLookups="true"
　　redirectPort="8443"/＞
　　＜Connector className=
　　"org.apache.coyote.tomcat4.CoyoteConnector"
　　port="8443" minProcessors="5"
　　maxProcessors="75"
　　acceptCount="10" debug="0"
　　scheme="https" secure="true"/＞
　　＜Factory className="org.apache.coyote.
　　tomcat4.CoyoteServerSocketFactory"
　　clientAuth="false" protocol="TLS" /＞
　　＜/Connector＞
　　＜Engine name="Standalone"
　　defaultHost="localhost" debug="0"＞
　　＜!-- This Host is the default Host --＞
　　＜Host name="localhost"
　　debug="0" appBase="webapps"
　　unpackWARs="true" autoDeploy="true"＞
　　＜Context path="" docBase="ROOT" debug="0"/＞
　　＜Context path="/orders"
　　docBase="/home/ian/orders" debug="0"
　　reloadable="true" crossContext="true"＞
　　＜/Context＞
　　＜/Host＞
　　
　　＜!-- This Host is the first
　　"Virtual Host": http://www.example.com/ --＞
　　＜Host name="www.example.com"
　　appBase="/home/example/webapp"＞
　　＜Context path="" docBase="."/＞
　　＜/Host＞
　　
　　＜/Engine＞
　　＜/Service＞
　　＜/Server＞
　　
　　Tomcat的server.xml檔案，在初始狀態下，只包括一個虛擬機器主機，但是它容易被擴充到支援多個虛擬機器主機。在前面的例子中展示的是一個簡單的server.xml版本，其中粗體部分就是用於添加一個虛擬機器主機。每一個Host元素必須包括一個或多個context元素，所包含的context元素中必須有一個是預設的context，這個預設的context的顯示路徑應該為空白（例如，path=””）。
　　
　　5、配置基礎驗證（Basic Authentication）
　　
　　容器管理驗證方法控制著當使用者訪問受保護的web應用資源時，如何進行使用者的身份鑒別。當一個web應用使用了Basic Authentication（BASIC參數在web.xml檔案中auto-method元素中設定），而有使用者訪問受保護的web應用時，Tomcat將通過HTTP Basic Authentication方式，彈出一個對話方塊，要求使用者輸入使用者名稱和密碼。在這種驗證方法中，所有密碼將被以64位的編碼方式在網路上傳輸。
　　
　　注意：使用Basic Authentication通過被認為是不安全的，因為它沒有強健的加密方法，除非在用戶端和伺服器端都使用HTTPS或者其他密碼加密碼方式（比如，在一個虛擬私人網路中）。若沒有額外的加密方法，網路系統管理員將能夠截獲（或濫用）使用者的密碼。
　　
　　但是，如果你是剛開始使用Tomcat，或者你想在你的web應用中測試一下基於容器的安全管理，Basic Authentication還是非常易於設定和使用的。只需要添加＜security-constraint＞和＜login-config＞兩個元素到你的web應用的web.xml檔案中，並且在CATALINA_BASE/conf/tomcat-users.xml檔案中添加適當的＜role＞和＜user＞即可，然後重新啟動Tomcat。
　　
　　下面例子中的web.xml摘自一個俱樂部會員網站系統，該系統中只有member目錄被保護起來，並使用Basic Authentication進行身分識別驗證。請注意，這種方式將有效代替Apache web伺服器中的.htaccess檔案。
　　
　　＜!--
　　Define the
　　Members-only area,
　　by defining
　　a "Security Constraint"
　　on this Application, and
　　mapping it to the
　　subdirectory (URL) that we want
　　to restrict.
　　--＞
　　＜security-constraint＞
　　＜web-resource-collection＞
　　＜web-resource-name＞
　　Entire Application
　　＜/web-resource-name＞
　　＜url-pattern＞/members/*＜/url-pattern＞
　　＜/web-resource-collection＞
　　＜auth-constraint＞
　　＜role-name＞member＜/role-name＞
　　＜/auth-constraint＞
　　＜/security-constraint＞
　　＜!-- Define the Login
　　Configuration for
　　this Application --＞
　　＜login-config＞
　　＜auth-method＞BASIC＜/auth-method＞
　　＜realm-name＞My Club
　　Members-only Area＜/realm-name＞
　　＜/login-config＞

6、配置單點登入（Single Sign-On）
　　
　　一旦你設定了realm和驗證的方法，你就需要進行實際的使用者登入處理。一般說來，對使用者而言登入系統是一件很麻煩的事情，你必須盡量減少使用者登入驗證的次數。作為預設的情況，當使用者第一次請求受保護的資源時，每一個web應用都會要求使用者登入。
　　
　　如果你運行了多個web應用，並且每個應用都需要進行單獨的使用者驗證，那這看起來就有點像你在與你的使用者搏鬥。使用者們不知道怎樣才能把多個分離的應用整合成一個單獨的系統，所有他們也就不知道他們需要訪問多少個不同的應用，只是很迷惑，為什麼總要不停的登入。
　　
　　Tomcat 4的“single sign-on”特性允許使用者在訪問同一虛擬機器主機下所有web應用時，只需登入一次。為了使用這個功能，你只需要在Host上添加一個SingleSignOn Valve元素即可，如下所示：
　　
　　＜Valve className=
　　"org.apache.catalina.
　　authenticator.SingleSignOn"
　　debug="0"/＞
　　
　　在Tomcat初始安裝後，server.xml的注釋裡麵包括SingleSignOn Valve配置的例子，你只需要去掉注釋，即可使用。那麼，任何使用者只要登入過一個應用，則對於同一虛擬機器主機下的所有應用同樣有效。使用single sign-on valve有一些重要的限制：
　　
　　1＞ value必須被配置和嵌套在相同的Host元素裡，並且所有需要進行單點驗證的web應用（必須通過context元素定義）都位於該Host下。
　　
　　2＞ 包括共用使用者資訊的realm必須被設定在同一級Host中或者嵌套之外。
　　
　　3＞ 不能被context中的realm覆蓋。
　　
　　4＞ 使用單點登入的web應用最好使用一個Tomcat的內建的驗證方式（被定義在web.xml中的＜auth-method＞中），這比自訂的驗證方式強，Tomcat內建的的驗證方式包括basic、digest、form和client-cert。
　　
　　5＞ 如果你使用單點登入，還希望整合一個第三方的web應用到你的網站中來，並且這個新的web應用使用它自己的驗證方式，而不使用容器管理安全，那你基本上就沒招了。你的使用者每次登入原來所有應用時需要登入一次，並且在請求新的第三方應用時還得再登入一次。
　　
　　當然，如果你擁有這個第三方web應用的源碼，而你又是一個程式員，你可以修改它，但那恐怕也不容易做。
　　
　　6＞ 單點登入需要使用cookies。
　　
　　7、配置使用者定製目錄（Customized User Directores）
　　
　　一些網站允許個別使用者在伺服器上發布網頁。例如，一所大學的學院可能想給每一位學生一個公用地區，或者是一個ISP希望給一些web空間給他的客戶，但這又不是虛擬機器主機。在這種情況下，一個典型的方法就是在使用者名稱前面加一個特殊字元（~），作為每位使用者的網站，比如：
　　
　　http://www.cs.myuniversity.edu/~username
　　http://members.mybigisp.com/~username
　　
　　Tomcat提供兩種方法在主機上映射這些個人網站，主要使用一對特殊的Listener元素。Listener的className屬性應該是org.apache.catalina.startup.UserConfig，userClass屬性應該是幾個映射類之一。
　　
　　如果你的系統是Unix，它將有一個標準的/etc/passwd檔案，該檔案中的帳號能夠被運行中的Tomcat很容易的讀取，該檔案指定了使用者的主目錄，使用PasswdUserDatabase 映射類。
　　
　　＜Listener className=
　　"org.apache.catalina.startup.UserConfig"
　　directoryName="public_html"
　　userClass="org.apache.catalina.
　　startup.PasswdUserDatabase"/＞
　　
　　web檔案需要放置在像/home/users/ian/public_html或者/users/jbrittain/public_html一樣的目錄下面。當然你也可以改變public_html 到其他任何子目錄下。
　　
　　實際上，這個使用者目錄根本不一定需要位於使用者主目錄下裡面。如果你沒有一個密碼檔案，但你又想把一個使用者名稱對應到公用的像/home一樣目錄的子目錄裡面，則可以使用HomesUserDatabase類。
　　
　　＜Listener className=
　　"org.apache.catalina.startup.UserConfig"
　　directoryName="public_html"
　　homeBase="/home"
　　userClass="org.apache.catalina.
　　startup.HomesUserDatabase"/＞
　　
　　這樣一來，web檔案就可以位於像/home/ian/public_html或者/home/jasonb/public_html一樣的目錄下。這種形式對Windows而言更加有利，你可以使用一個像c:\home這樣的目錄。
　　
　　這些Listener元素，如果出現，則必須在Host元素裡面，而不能在context元素裡面，因為它們都用應用於Host本身。
　　
　　8、在Tomcat中使用CGI指令碼
　　
　　Tomcat主要是作為Servlet/JSP容器，但它也有許多傳統web伺服器的效能。支援通用閘道介面（Common Gateway Interface，即CGI）就是其中之一，CGI提供一組方法在響應瀏覽器請求時運行一些擴充程式。
　　
　　CGI之所以被稱為通用，是因為它能在大多數程式或指令碼中被調用，包括：Perl，Python，awk，Unix shell scripting等，甚至包括Java。
　　
　　當然，你大概不會把一個Java應用程式當作CGI來運行，畢竟這樣太過原始。一般而言，開發Servlet總要比CGI具有更好的效率，因為當使用者點擊一個連結或一個按鈕時，你不需要從作業系統層開始進行處理。
　　
　　Tomcat包括一個可選的CGI Servlet，允許你運行遺留下來的CGI指令碼。
　　
　　為了使Tomcat能夠運行CGI，你必須做如下幾件事：
　　
　　1. 把servlets-cgi.renametojar （在CATALINA_HOME/server/lib/目錄下）改名為servlets-cgi.jar。處理CGI的servlet應該位於Tomcat的CLASSPATH下。
　　
　　2. 在Tomcat的CATALINA_BASE/conf/web.xml 檔案中，把關於＜servlet-name＞ CGI的那段的注釋去掉（預設情況下，該段位於第241行）。
　　
　　3. 同樣，在Tomcat的CATALINA_BASE/conf/web.xml檔案中，把關於對CGI進行映射的那段的注釋去掉（預設情況下，該段位於第299行）。注意，這段內容指定了HTML連結到CGI指令碼的訪問方式。
　　
　　4. 你可以把CGI指令碼放置在WEB-INF/cgi 目錄下（注意，WEB-INF是一個安全的地方，你可以把一些不想被使用者看見或基於安全考慮不想暴露的檔案放在此處），或者你也可以把CGI指令碼放置在context下的其他目錄下，並為CGI Servlet調整cgiPathPrefix初始化參數。這就指定的CGI Servlet的實際位置，且不能與上一步指定的URL重名。
　　
　　5. 重新啟動Tomcat，你的CGI就可以運行了。
　　
　　在Tomcat中，CGI程式預設放置在WEB-INF/cgi目錄下，正如前面所提示的那樣，WEB-INF目錄受保護的，通過用戶端的瀏覽器無法窺探到其中內容，所以對於放置含有密碼或其他敏感資訊的CGI指令碼而言，這是一個非常好的地方。
　　
　　為了相容其他伺服器，儘管你也可以把CGI指令碼儲存在傳統的/cgi-bin目錄，但要知道，在這些目錄中的檔案有可能被網上好奇的衝浪者看到。另外，在Unix中，請確定運行Tomcat的使用者有執行CGI指令碼的許可權。
　　
　　9、改變Tomcat中的JSP編譯器（JSP Compiler）
　　
　　在Tomcat 4.1（或更高版本，大概），JSP的編譯由包含在Tomcat裡面的Ant程式控制器直接執行。這聽起來有一點點奇怪，但這正是Ant有意為之的一部分，有一個API文檔指導開發人員在沒有啟動一個新的JVM的情況下，使用Ant。
　　
　　這是使用Ant進行Java開發的一大優勢。另外，這也意味著你現在能夠在Ant中使用任何javac支援的編譯方式，這裡有一個關於Apache Ant使用手冊的javac page列表。
　　
　　使用起來是容易的，因為你只需要在＜init-param＞ 元素中定義一個名字叫“compiler”，並且在value中有一個支援編譯的編譯器名字，樣本如下：
　　
　　＜servlet＞
　　＜servlet-name＞jsp＜/servlet-name＞
　　＜servlet-class＞
　　org.apache.jasper.servlet.JspServlet
　　＜/servlet-class＞
　　＜init-param＞
　　＜param-name＞logVerbosityLevel
　　＜/param-name＞
　　＜param-value＞WARNING＜/param-value＞
　　＜/init-param＞
　　＜init-param＞
　　＜param-name＞compiler＜/param-name＞
　　＜param-value＞jikes＜/param-value＞
　　＜/init-param＞
　　＜load-on-startup＞3＜/load-on-startup＞
　　＜/servlet＞
　　
　　當然，給出的編譯器必須已經安裝在你的系統中，並且CLASSPATH可能需要設定，那處決於你選擇的是何種編譯器。
　　
　　10、限制特定主機訪問（Restricting Access to Specific Hosts）
　　
　　有時，你可能想限制對Tomcat web應用的訪問，比如，你希望只有你指定的主機或IP地址可以訪問你的應用。這樣一來，就只有那些指定的的用戶端可以訪問服務的內容了。為了實現這種效果，Tomcat提供了兩個參數供你配置：RemoteHostValve 和RemoteAddrValve。
　　
　　通過配置這兩個參數，可以讓你過濾來自請求的主機或IP地址，並允許或拒絕哪些主機/IP。與之類似的，在Apache的httpd檔案裡有對每個目錄的允許/拒絕指定。例如你可以把Admin Web application設定成只允許本地訪問，設定如下：
　　
　　＜Context path=
　　"/path/to/secret_files" ...＞
　　＜Valve className="org.apache.
　　catalina.valves.RemoteAddrValve"
　　allow="127.0.0.1" deny=""/＞
　　＜/Context＞
　　
　　如果沒有給出允許主機的指定，那麼與拒絕主機匹配的主機就會被拒絕，除此之外的都是允許的。與之類似，如果沒有給出拒絕主機的指定，那麼與允許主機匹配的主機就會被允許，除此之外的都是拒絕的。