玩轉 Tomcat 配置必備的 10 個小技巧!

做者:Jason Brittain & Ian F. Darwin
出處:http://www.orielly.com/ 
譯者:陳光 html

如今開發Java Web應用,創建和部署Web內容是一件很簡單的工做。使用Jakarta Tomcat做爲Servlet和JSP容器的人已經遍佈全世界。Tomcat具備免費、跨平臺等諸多特性,而且更新得很快,如今很是的流行。 java

你所須要作的就是:按照你的需求配置Tomcat,只要你正確配置,Tomcat通常都能適合你的要求。下面是一系列關於Tomcat的配置技巧,但願對你有所幫助。程序員

1、配置系統管理(Admin Web Application)

==================================web

大多數商業化的J2EE服務器都提供一個功能強大的管理界面,且大都採用易於理解的Web應用界面。Tomcat按照本身的方式,一樣提供一個成熟的管理工具,而且絲絕不遜於那些商業化的競爭對手。Tomcat的Admin Web Application最初在4.1版本時出現,當時的功能包括管理context、data source、user和group等。固然也能夠管理像初始化參數,user、group、role的多種數據庫管理等。在後續的版本中,這些功能將獲得很大的擴展,但現有的功能已經很是實用了。Admin Web Application被定義在自動部署文件:shell

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 ,你可能什麼都作不了。apache

若是你使用UserDatabaseRealm(默認),你將須要添加一個user以及一個role到CATALINA_BASE/conf/tomcat-users.xml文件中。你編輯這個文件,添加一個名叫「admin」的role 到該文件中,以下:segmentfault

<role name="admin"/>

一樣須要有一個用戶,而且這個用戶的角色是「admin」。象存在的用戶那樣,添加一個用戶(改變密碼使其更加安全):瀏覽器

<ser name="admin"password="deep_dark_secret"roles="admin"/>

你完成這些步驟後,請從新啓動Tomcat,訪問http://localhost:8080/admin,你將看到一個登陸界面。Admin Web Application採用基於容器管理的安全機制,並採用了Jakarta Struts框架。一旦你做爲「admin」角色的用戶登陸管理界面,你將可以使用這個管理界面配置Tomcat。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...,將看到一個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" rivileged="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仍是很是易於設置和使用的。只須要添加 和 兩個元素到你的web應用的web.xml文件中,而且在CATALINA_BASE/conf/tomcat-users.xml文件中添加適當的 和 便可,而後從新啓動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有一些重要的限制:

  • value必須被配置和嵌套在相同的Host元素裏,而且全部須要進行單點驗證的web應用(必須經過context元素定義)都位於該Host下。
  • 包括共享用戶信息的realm必須被設置在同一級Host中或者嵌套以外。
  • 不能被context中的realm覆蓋。
  • 使用單點登陸的web應用最好使用一個Tomcat的內置的驗證方式(被定義在web.xml中的 中),這比自定義的驗證方式強,Tomcat內置的的驗證方式包括basic、digest、form和client-cert。
  • 若是你使用單點登陸,還但願集成一個第三方的web應用到你的網站中來,而且這個新的web應用使用它本身的驗證方式,而不使用容器管理安全,那你基本上就沒招了。你的用戶每次登陸原來全部應用時須要登陸一次,而且在請求新的第三方應用時還得再登陸一次。
  • 固然,若是你擁有這個第三方web應用的源碼,而你又是一個程序員,你能夠修改它,但那恐怕也不容易作。
  • 單點登陸須要使用cookies。

7、配置用戶定製目錄(Customized User Directores)

======================================

一些站點容許個別用戶在服務器上發佈網頁。例如,一所大學的學院可能想給每一位學生一個公共區域,或者是一個ISP但願給一些web空間給他的客戶,但這又不是虛擬主機。在這種狀況下,一個典型的方法就是在用戶名前面加一個特殊字符(~),做爲每位用戶的網站,好比:

http://www.cs.myuniversity.ed...
http://members.mybigisp.com/~...

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,你必須作以下幾件事:

  • 把servlets-cgi.renametojar (在CATALINA_HOME/server/lib/目錄下)更名爲servlets-cgi.jar。處理CGI的servlet應該位於Tomcat的CLASSPATH下。
  • 在Tomcat的CATALINA_BASE/conf/web.xml 文件中,把關於 CGI的那段的註釋去掉(默認狀況下,該段位於第241行)。
  • 一樣,在Tomcat的CATALINA_BASE/conf/web.xml文件中,把關於對CGI進行映射的那段的註釋去掉(默認狀況下,該段位於第299行)。注意,這段內容指定了HTML連接到CGI腳本的訪問方式。
  • 你能夠把CGI腳本放置在WEB-INF/cgi 目錄下(注意,WEB-INF是一個安全的地方,你能夠把一些不想被用戶看見或基於安全考慮不想暴露的文件放在此處),或者你也能夠把CGI腳本放置在context下的其餘目錄下,併爲CGI Servlet調整cgiPathPrefix初始化參數。這就指定的CGI Servlet的實際位置,且不能與上一步指定的URL重名。
  • 從新啓動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列表。

使用起來是容易的,由於你只須要在 元素中定義一個名字叫「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"...>  
<ValveclassName="org.apache.  
catalina.valves.RemoteAddrValve"  
allow="127.0.0.1"deny=""/>  
</Context>

若是沒有給出容許主機的指定,那麼與拒絕主機匹配的主機就會被拒絕,除此以外的都是容許的。與之相似,若是沒有給出拒絕主機的指定,那麼與容許主機匹配的主機就會被容許,除此以外的都是拒絕的。

若有錯誤或其它問題,歡迎小夥伴留言評論、指正。若有幫助,歡迎點贊+轉發分享。

歡迎你們關注民工哥的公衆號:民工哥技術之路
image.png

相關文章
相關標籤/搜索