您正在查看: Tomcat 分类下的文章

apache tomcat 5.5 servlet/jsp 容器 - 如何把tomcat注册为视窗的服务

apache Tomcat 5.5 servlet/JSP 容器

如何把Tomcat注册为视窗的服务

NOTICE

本说明适用于procrun 1.0,现已淘汰。

Tomcat5应用程序

Tomcat5 是一个可以在视窗NT下注册为服务的程序。

Tomcat5w监视程序

Tomcat5w 是一个可用来监视和修改 Tomcat 设置的程序,它有方便使用的界面

指令选项:

//ES// 修改设置 这是却省是的选项。 运行命令的名称将以servicenameW.exe出现
//MS// 监视程序运行状况 代表程序运行的小图标会出现在视窗有下角

指令行选项

指令行选项的格式为: //XX//ServiceName

现有指令行的选项:

//TS// 把服务按控制台模式运行 不过没有提供其他选项,这是缺省运行模式。其中ServiceName时是可运行文件的名字去 掉exe后缀,这里是Tomcat5
//RS// 运行为系统的服务 由系统ServiceManager来执行
//SS// 停止服务
//US// 更新属性
//IS// 把Tomcat安装为系统的服务
//DS// 删除Tomcat服务 如果Tomcat服务正在运行,这个指令首先终止Tomcat

指令行允许的属性

每个属性都以--开始。以++的属性会给附加在已有的属性里。 如果有系统环境变量的名称与指令的属性相同,有PR_前缀的优先。 例如:

set PR_CLASSPATH=xx.jar

与下面的指令项属性效果一样:

--Classpath=xx.jar

属性名称 默认值 描述
--Description 描述Tomcat服务,最多1024个字符
--DisplayName 名称 服务显示的名称
--Install procrun.exe //RS//ServiceName 安装服务
--Startup manual 启动服务的状态,可以是 automanual
--DependsOn 罗列Tomcat服务必须依赖的其他系统服务。如果有多个服务,用#;符号来分开
--Environment 罗列需要提供给该服务的环境变量。格式为: key=value. 用 #; 符号来区分
--User 用来运行该指令的用户名。只是用在 StartMode 下的 javaexe,这样可以使Tomcat服务以没有 LogonAsService 特权的用户的名义来运行。
--Password --User 所列用户的密码
JAVA_HOME JAVA_HOME 可以定义一个不同于系统的JAVA_HOME环境变量,指定使用不同的Java
--Jvm auto 允许的值为autojvm.dll的完整路径。 路径中可以有环境变量出现。
--JvmOptions -Xrs Java虚拟机器的选项。都用-D or -X开始, 将会被传递给JVM。 选项间用 # or ;字符隔开。
--Classpath 设置Java的classpath环境变量
--JvmMs 指定开始时所用的内存,单位是MB
--JvmMx 最大内存,单位用MB
--JvmSs Thread stack size in KB
--StartImage 可运行文件
--StartPath 程序运行时的工作目录
--StartClass 程序开始时执行的类
--StartParams 需要传递个程序的变量数值,变量用#;字符分隔
--StartMethod main 如果开始执行类中的方法名称,可以不是 main()
--StartMode 可运行文件 exe 可以是jvm javaexe
--StopImage 收到终止信号后运行的文件名
--StopPath 收到终止信号后运行文件的工作目录
--StopClass 收到终止信号后运行的Java类
--StopParams 需要传递个终止信号后运行文件的变量数值。变量用#; 字符分开
--StopMethod main 收到终止信号后运行的Java类中的开始方法,可以不是main()
--StopMode 运行文件 可以是jvm javaexe;中的一个
--StopTimeout 没有限制 定义 procrun 需要等待多少秒让程序安全退出。
--LogPath 工作目录 定义日志所在目录
--LogPrefix jakarta_service 定义日志文件名称
--LogLevel info 定义日志写入的底限,可以是 error, info, warndebug
--StdOutput 把标准输出导入到文件的文件名
--StdError 把错误输出stderr导入到文件的文件名

安装服务

最方便安全的办法是用 Tomcat 提供的service.bat脚本文件。

安装名为'Tomcat5'的服务
C:\> service.bat install

如果你使用 tomcat5.exe,你需要用//IS//选项

安装名为'Tomcat5'的服务
C:\> tomcat5 //IS//Tomcat5 --DisplayName="apache Tomcat 5" \
C:\> --Install="C:\Program Files\Tomcat\bin\tomcat5.exe" --Jvm=auto \
C:\> --StartMode=jvm --StopMode=jvm \
C:\> --StartClass=org.apache.catalina.startup.Bootstrap --StartParams=start \
C:\> --StopClass=org.apache.catalina.startup.Bootstrap --StopParams=stop

更新服务

更新服务的变量,用 //US// 选项

更新服务'Tomcat5
C:\> tomcat5 //US//Tomcat5 --Description="Apache Tomcat Server - http://tomcat.apache.org/ " \
C:\> --Startup=auto --Classpath=%JAVA_HOME%\lib\tools.jar;%CATALINA_HOME%\bin\bootstrap.jar

删除服务

如果你要删除服务,用 //DS// 变量。
如果该服务正在运行,它先会被终止运行,然后删除。

删除名为'Tomcat5'的服务
C:\> tomcat5 //DS//Tomcat5

纠错

如果需要让服务在控制台运行,用 //TS// 选项。 该服务可用 CTRL+CCTRL+BREAK终止。

如果你把 tomcat5.exe 重新命名为 testservice.exe, 那么你只要运行 testservice.exe,
控制模式是缺省的模式。

用控制台模式运行 'Tomcat5'
C:\> tomcat5 //TS//Tomcat5 [更多变量]
或简单运行:
C:\> tomcat5

apache tomcat 5.5 servlet/jsp 容器 - 如何设置ssl

apache Tomcat 5.5 servlet/JSP 容器

如何设置SSL

速成

文档说明:本文件适用于用JSSE设置Tomcat的SSL。 如果使用 APR, Tomcat是通过 OpenSSL来实现SSL,设置会不同。

在下面的描述中使用变量名$CATALINA_HOME来代指Tomcat5所安装的目录地址, 这是一个基础目录(base directory),其他的相关路径由它而派生。不过,如果你已经把Tomcat 设置成多个体实例(multiple instances),并且设立了一个$CATALINA_BASE目录, 那么你就应使用$CATALINA_BASE而不是$CATALINA_HOME作为参照。

你需要按照下列简单步骤在Tomcat 5上安装和配置SSL支持。更多信息,请阅读这个帮助的其余部分。

  • 如果你在使用1.3 JVM,从http://java.sun.com/products/jsse/ 下载JSSE 1.0.3 (或其后的版本), 然后,或者把它作为系统上installed extension,或者把它设置为一个环境变量 JSSE_HOME,让它指向你所安装JSSE的目录。


  • 通过执行下面的命令产生一个认可的keystore。
    %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA

    Unix

    %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA
    并指定一个密码值为"changeit"。


  • 把$CATALINA_HOME/conf/server.xml中的 "SSL HTTP/1.1 Connector" 去掉注释,并根据需要修改。

  • SSL简介

    SSL, 或者Secure Socket Layer,是一种允许web浏览器和web服务器通过一个安全的连接进行 交流的技术。这意味着将被发送的数据在一端被翻译成密码,传送出去,然后在另一端解开密码, 再进行处理。这是一个双向的过程,也就是浏览器和服务器都需要在发送数据之前对它们进行加密。

    SSL协定的另一个重要方面是认证(Authentication)。这就是说,在你开始试图通过一个安全连接 与一个web服务器交流的时候,这个服务器会要求你的浏览器出示一组证件,通过“鉴定”的方式来证明这 就是你所声明的网站。在某些情况下,服务器还会要求你的web浏览器的认证书,证明你就是你所说的那 个人。这就是所知的“客户认证”,尽管实际情况中,更多地用在商务-对-商务(B2B)交易,而不是对个人 用户。大多数有SSL功能的web服务器不要求客户认证(Client Authentication)。

    SSL 和 Tomcat

    必须要注意,配置Tomcat来利用secure sockets仅仅在它作为一个独立的web服务器时才有必要。 当Tomcat主要作为在另外一个web服务器,如apache 或Microsoft IIS, 后面的servlet/JSP容器 运行时,通常有必要把主要的web服务器配置来处理与用户的SSL连接。通常,这个服务器会对所有的 SSL-相关的功能进行交涉,然后再把对Tomcat容器的请求解密后传递过去。同样,Tomcat会返回 明码的回应,这个回应将被加密后才被送到用户浏览器。在这样的环境下,Tomcat知道与主要web服务器 和客户的交流是通过一个安全连接才发生的(因为你的程序需要询问这些情况),但是它本身并没有参与 加密和解密。

    认证书:Certificate

    为了能实施SSL,一个web服务器对每个接受安全连接的外部接口(IP 地址)必须要有相应的认 证书(Certificate)。关于这个设计的理论是一个服务器必须提供某种合理的保证以证明这个服务器的 主人就是你所认为的那个人,特别是在接收任何敏感信息之前要这样做。关于Certificates的更广泛 的解释超过了这个文档资料的范围,就把一个认证书当作一个英特网地址的“数码驾驶执照”。这个认证书 要陈述与这个网站相关联的公司,以及这个网站的所有者或系统管理员的一些基本联系信息。

    这个"驾驶执照"由所有人以密码方式签字,其他人非常难伪造。对于进行电子商务 (e-commerce)的网站,或其他身份认证至关重要的任何商业交易,认证书要向大家所熟知的认证权威 (Certificate Authority (CA))如VeriSign或Thawte来购买。这样的认证书可用电子 技术证明属实——实际上,认证权威单位会担保它发出的认证书的真实性,如果你信任发出认证书的 认证权威单位的话,你就可以相信这个认证书是有效的。

    在许多情况下,认证并不是真正使人担忧的事。系统管理员或许只想要保证被服务器传送和接收的 数据是秘密的,不会被连接线上的偷窃者盗窃到。庆幸的是,Java提供相对简单的被称 为keytool的命令行工具,可以简单地产生“自己签名”的认证书。自己签名的认证书 只是用户产生的认证书,没有正式在大家所熟知的认证权威那里注册过,因此不能确保它的真实性。 认证也许很重要,也许不重要,完全决定于你的需要。

    使用SSL需要考虑的地方

    用户第一次试图到你的网站访问被安全保卫的页面时,他(她)通常会被要求提供关于认证的 详细信息(如公司名称和联系姓名),并询问他(她)是否愿意接受这个认证的合法性,并继续进行交易。 一些浏览器会提供一个选项来永久地接受所给的认证的合法性,这样一来用户就不用在每次访问你的网站 时麻烦地去填写认证信息。有的浏览器没有这一选项。一旦用户认可后,这个认证至少在整个浏览器 会话期间被认为是合法的。

    虽然SSL协议的设计尽量做到既安全又高效,但是加密和解密是复杂耗时的计算过程。通常没有必要让整个 网站都通过SSL来传输,开发人员可以选择部分网页用SSL,部分网页不用SSL。对于一个相对繁忙的网站 来说,可以选择保护那些比较敏感的信息,如登陆、个人信息、购物车、付账、信用卡等。那些网页只要 把网页地址里http:改为https:,浏览器就会自动把信息按照指定的 协议传输出去。

    最后,使用根据网名决定的虚拟主机来进行安全连接可能会出现问题。这是SSL协定本身的设计局限。 SSL handshake,就是客户浏览器接受服务器认证,在HTTP请求访问之前必须产生。因此,包含虚拟 主机名字的请求信息在认证之前不能被确定,所以不可能给单个IP地址分配多个认证书。如果在单个IP 地址上的所有的虚拟主机需要对照同一个认证书来认证的话,再添加多个虚拟主机不应该干扰服务器上 正常的SSL操作。不过要当心,大多数的客户浏览器会按认证书上列出的domain names(主要是官方的, CA-签署的认证书)对照比较服务器的domain name。如果领域名(domain names)不相配,这些浏览器 会向客户端用户显示警告。总的来说,只有address-based虚拟主机通常和SSL一起在生产环境中 被使用。

    设置
    检查你是否需要下载 JSSE

    Java 1.4或更新的版本已经包括了JSSE。如果你使用 1.4或更新版本,你不需要另外下载JSSE。 你可以跳过本节

    从下面的网站下载Java Secure Socket Extensions (JSSE) 版本 1.0.3或更新版。 http://java.sun.com/products/jsse/.

    在扩展这个软件包后,有两种方法让Tomcat可以使用它(选择其中之一):

    • 通过把所有这三个JAR文件(jcert.jar , jnet.jar , 和 jsse.jar)复制到$JAVA_HOME/jre/lib/ext 目录中去,让JSSE成为 安装好的扩充目录。
    • 产生一个新的环境变量JSSE_HOME,让它包含绝对路径,指向你拆装(unpacked) JSSE二进制分布的目录。
    产生 Keystore

    Tomcat 现在只支持 JKS或PKCS12 格式的keystores. JKS格式是 Java 的标准 KeyStore格式,它可以用 Java 的 keytool 来产生。这个工具在 Java 的 bin 目录里。 PKCS12 格式时互联网的标准,可以用 OpenSSL 和微软的 Key-Manager来修改。

    To import an existing certificate into a JKS keystore, please read the documentation (in your JDK documentation package) about keytool. Note that openssl often adds a readable comments before the key, keytooldoes not support that, so remove the openssl comments if they exist before importing the key using keytool.

    使用OpenSSL把一个现存的被你自己CA签署的认证书输入到PKCS12 keystore里面,你会执行象这样的一个命令:

    openssl pkcs12 -export -in mycert.crt -inkey mykey.key \
    -out mycert.p12 -name tomcat -CAfile myCA.crt \
    -caname root -chain
    
    更深层的情况,请查阅OpenSSL documententation。

    要从头开始产生一个新的keystore,包含一个自签的认证书,从一个终端命令行执行下面的命令:

    视窗

    %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA

    Unix

    %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA

    ( 应该把RSA运算法则作为主要安全运算法则,这保证了与其它服务器和组件的兼容性。)

    这个命令会在用户的home directory产生一个叫做" .keystore " 的新文件。要指定一个不同的位置(location)或文件名,在上面所示的keytool 命令里添加-keystore参数,后面紧跟着你的keystore文件的全部路径名。你还需要把 这个新的位置在server.xml配置文件中反映出来,这在后面将有描述。例如:

    视窗

    %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA \ 
    -keystore \path\to\my\keystore

    Unix

    %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA \ 
    -keystore \path\to\my\keystore

    在执行这个命令后,你首先被要求出示keystore密码。Tomcat使用的默认密码是 " changeit "(全都是小写字母),如果你愿意,你可以指定你自己的 密码。你还需要在server.xml配置文件里指定自己的密码,这在以后会有描述。

    下一步,你会被要求出示关于这个认证书的一般性信息,如公司,联系人名称,等等。这些信息会 显示给那些试图访问你程序里安全网页的用户,以确保这里提供的信息与他们期望的相对应。

    最后,你会被要求出示密钥(key)密码,也就是这个认证书所特有的密码(与其它的 储存在同一个keystore文件里的认证书不同)。你必须在这里使用与keystore 密码相同的密码。(目前,keytool会提示你按ENTER键会自动帮你做这些)。

    如果一切顺利,你现在就拥有了一个可以被你的服务器使用的有认证书的keystore文件。

    注意: 你的 private key 的密码和 keystore 的密码应该相同。 如果不同的话你会得到一下错误信息: java.io.IOException: Cannot recover key 这是一个已知的错误,详细请看: Bugzilla issue 38217

    Edit the Tomcat Configuration File

    最后的步骤是把你的secure socket配置在$CATALINA_HOME/conf/server.xml文件里, $CATALINA_HOME代表你在其中安装Tomcat 5 的目录。一个例子是SSL连接器 的<Connector>元素被包括在和Tomcat一起安装的缺省server.xml文件里。 它看起来象是这样:

    <-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 -->
    <!--
    <Connector 
      port="8443" minProcessors="5" maxProcessors="75"
      enableLookups="true" disableUploadTimeout="true"
      acceptCount="100" debug="0" scheme="https" secure="true";
      clientAuth="false" sslProtocol="TLS"/>
    -->
    

    你会注意到Connector元素本身,其默认形式是被注释掉的(commented out),所以你需要把它周围 的注释标志删除掉。然后,你可以根据需要客户化(自己设置)特定的属性。关于各种选项的详细信息, 请查阅Server Configuration Reference 。下面的讨论 仅仅涵盖设置SSL通信(communication)时大家最感兴趣的那些属性。

    这个port属性(默认值是8443)是 TCP/IP端口数码,Tomcat在其上监听安全连接。 你可以把它更改成任何你愿意要的数值(如默认的https通信,数目是443)。不过,在许 多操作系统中,要想在比1024小的端口数码上运行Tomcat,需要特殊的设置(它超出了这个文档资料 的范围)。

    如果你在这里更改端口数值,你还必须更改在non-SSL连接器上的redirectPort 这个属性特定的值。这允许Tomcat自动地redirect那些试图访问有安全限制页面的用户,指明根据 Servlet 2.4 Specification要求,SSL是必需的。

    有一些额外的选项被用来配置SSL协定。依赖于你早先怎样配置你的keystore,你也许需要添加或更改下列属性值:

    属性 描述
    clientAuth 如果你想要Tomcat要求所有的SSL客户在使用这个socket时出示用户认证书,把这个值设定为 true 。如果你想要Tomcat要求出示用户认证书,但是如果没有认证书也可以, 就把这个值设定为want 。
    keystoreFile 如果你产生的keystore文件不在Tomcat期望的默认地方(一个叫做.keystore 的文件在Tomcat运行的主目录),就添加这个属性。你可以指定一个绝对路径名称, 或者一个由$CATALINA_BASE环境变量而派生的相对路径名称。
    keystorePass 如果你使用一个不同的keystore(以及认证书)密码,而不是Tomcat期望的密码 (就是changeit),添加这个元素。
    keystoreType 如果使用一个PKCS12 keystore的话,就添加这个element。 有效的值是JKS 和 PKCS12 。
    sslProtocol 要在这个socket上被使用的加密/解密协定。如果你在使用Sun的JVM,我们不提倡更改 这个值。据报道,TLS协定的IBM's 1.4.1 实现与一些通用的浏览器不兼容。 如果是这样,就使用value SSL 。
    ciphers 这个socket允许使用的由逗号分隔开的加密密码列单。默认的情况下,任何可用的密码都允许被使用。
    algorithm 可用的X509算法。默认是Sun的实现( SunX509 )。 对于IBM JVMs,你应该使用值 IbmX509。对于其他卖主,查阅JVM文档资料来 找正确的值。
    truststoreFile 用来验证用户认证书的TrustStore文件。
    truststorePass 访问TrustStore的密码。默认值就是keystorePass的值。
    truststoreType 如果你在使用与KeyStore不同格式的TrustStore,添加这个元素。 合法的值是JKS和PKCS12。
    keyAlias 如果 keystore 里面有多个 key,你可以为用这个选项为加入的 key 起一个名字。 如果没有指定名字,使用时 keystore 内的第一个 key 将会被使用。

    在完成这些配置更改后,你必须象通常那样重新启动Tomcat,然后你就可以工作了。 你应该可以通过SSL访问Tomcat支持的任何web应用程序。例如,试一下下面的指令:

    https://localhost:8443

    你应该看到通常的Tomcat splash页面(除非你修改过ROOT web应用程序)。如果不行的话, 下面的章节包含一些排除故障的提示。

    安装和获取认证权威颁发的认证书

    要从认证权威(如verisign.com, thawte.com 或 trustcenter.de)获得并安装认证书, 你应该先阅读前面章节,然后再按照下面的指示进行:

    产生一个认证签名请求 (CSR)

    为了从你选择的认证权威那里获得认证书,你必须产生一个所谓的认证签名请求(Certificate Signing Request (CSR))。这个认证签名请求被认证权威用来产生鉴定你的网站是“安全的”的认证书。 按照下列步骤产生一个CSR:

    • 产生一个局部认证书(如前面章节描述那样):
      keytool -genkey -alias tomcat -keyalg RSA \ 
      -keystore &lt;your_keystore_filename&gt;
      注意:在某些情况下, 要产生一个工作认证书,你必须在“"first- and lastname" field 键入你的网站的域名 (例如www.jaxmao.org)。
    • 然后用下列指令产生CSR :
      keytool -certreq -keyalg RSA -alias tomcat 
      -file certreq.csr \ 
      -keystore &lt;your_keystore_filename&gt;

    执行这个命令之后你会得到一个文件叫 certreq.csr。然后你可以到发送到认证权威, 然后你就可以得到你的认证书。具体步骤可以参考他们的网站的帮助文件。

    导入认证书

    现在你有了认证书,你可以把它输入到你局部的keystore里。首先你必须输入一个叫做证书链 Chain Certificate 或 Root Certificate 到你的 keystore 里去。在这之后,你可以开始 输入你的认证书。

    • 从你获得认证书的认证权威那里下载一个Chain Certificate 。
      For Verisign.com commercial certificates go to: http://www.verisign.com/support/install/intermediate.html
      For Verisign.com trial certificates go to: http://www.verisign.com/support/verisign-intermediate-ca/Trial_Secure_Server_Root/index.html For Trustcenter.de go to: http://www.trustcenter.de/certservices/cacerts/en/en.htm#server
      对于Thawte.com , 去http://www.thawte.com/certs/trustmap.html下载
    • 把Chain Certificate 输入到你的keystore里边
      keytool -import -alias root -keystore &lt;your_keystore_filename&gt; \ 
      -trustcacerts -file &lt;filename_of_the_chain_certificate&gt;
    • 最后输入你的新的认证书
      keytool -import -alias tomcat -keystore &lt;your_keystore_filename&gt; \ 
      -trustcacerts -file &lt;your_certificate_filename&gt;
    Troubleshooting

    这里是一些你在设置SSL通信时也许会遇到的常见问题,以及如何解决它们。

    • 我在我的日志文件中得到"java.security.NoSuchAlgorithmException"错误。

      JVM找不到JSSE JAR 文件。按照所有的指导说明 下载并安装JSSE。

    • 当Tomcat启动时,我得到一个象 "java.io.FileNotFoundException: {some-directory}/{some-file} not found"的异常。

      一个可能的解释是Tomcat不能在它要找的地方找到 keystore文件。在默认的情况下, Tomcat预计 keystore文件在Tomcat运行的用户主目录里被命名为.keystore。 如果 keystore存放在别的什么地方,你需要向Tomcat配置文件里的 &lt;Factory&gt;元素添加一个 keystoreFile属性。

    • 当Tomcat启动时,我得到一个象"java.io.FileNotFoundException: Keystore was tampered with, or password was incorrect"的异常。

      如果没有其他人 试图 修改你的 keystore 文件,最可能的情况是 Tomcat 用了错误的密码。你可以尝试重新产生 keystore 文件,或修改 Tomcat 设置文件里 <Connector> 元素的 keystorePass 属性,还请记住密码是分大小写的。

    如果你仍然有问题,一个好的地方你可找到帮助是 TOMCAT-USER 邮件列表。你可以 用下面的地址订阅。

    http://tomcat.apache.org/lists.html.

    Miscellaneous Tips and Bits

    你可以用下面的办法获取用户 SSL session 的 ID:

    String sslID = (String)request.getAttribute("javax.servlet.request.ssl_session");



    你可从下面的网址获得更多这方面的信息:
    Bugzilla.

    apache tomcat 5.5 servlet/jsp 容器 - project status

    apache Tomcat 5.5 servlet/JSP 容器

    Project Status

    前言

    本文的意图是为各位介绍Tomcat开发的现状,而没有提供有关某个臭虫是否已经被改正或 Tomcat是否支持某个功能。

    This page is updated roughly once per every couple of Tomcat minor releases, so for day-to-day status you should check the tomcat-user and tomcat-dev mailing lists. You can always inquire there as to the availability or status of a specific feature or component.

    Current Status Summary

    Tomcat 5.0.27 在2004 年6月17日发表。 那时起 TOMCAT_5_0 在 CVS 里面开始分枝, Tomcat 5.5正是开始开发。 Tomcat 5.5 已经发表了几个稳定版。Tomcat 5.5是现在所有工作的 重点。Tomcat 5.0只是处于维护状态,它的修正版会发表的越来越少。

    Tomcat 5.5 有几个主要目标。可以从下面的连接看到。 MARC. The status of some of these items is detailed below. Once 5.5 releases are available, please refer to the Changelog accompanying each release for detailed changes, enhancements, and fixes.

    Tomcat 4.1.x is no longer actively developed. It is maintained to address only showstopper, security, and servlet Specification compliance issues. Maintenance for Tomcat 4.1.x will likely cease once a stable release or two of Tomcat 5.5 are out. Users of Tomcat 4.1.x are strongly encouraged to upgrade to the latest stable Tomcat 5.0 release.

    Tomcat 4.0.x is relatively old, and not actively maintained or supported. It is strongly recommended that users of these releases upgrade to the latest stable Tomcat 5.0 release or at least the latest stable Tomcat 4.1 release.

    Tomcat 3.3.x is in roughly the same maintenance mode as Tomcat 4.1.x.

    Tomcat 3.2 and earlier are in roughly the same support state as Tomcat 4.0.x. Users should upgrade to Tomcat 3.3.x or the latest stable Tomcat 5.0.x.

    How to read the report

    The columns in this report contain the following information:

    • Priority - A sense of how important it is to address this issue in the short term.
    • Action Item - Concise description of the action item to be completed. Where relevant, Java package names of the primary classes involved are listed in [square brackets]
    • Volunteers - Login of those developers who have volunteered to assist in the design, implementation, testing, and documentation of this action item's changes to Tomcat.
    Developers can nominate themselves to work on particular action items by asking a Committer to add their name address to those items. The developers working on each item should discuss and agree upon the approach to be used for implementing the item's changes to the project source code and documentation, prior to completing those changes. Such discussions should take place on the tomcat-dev mailing list so that everyone can stay apprised of what is going on, or chime in if they want to contribute ideas and suggestions.

    TODO List
    PriorityAction ItemVolunteers
    High Refactor ClassLoaders for Tomcat 5.5 to allow container plugins. costin
    Medium Enhance Cluster functionality for Tomcat 5.5. fhanik
    Medium Continue fixing bugs and updating docs. everyone
    Open bugs

    The list of the bugs which are in an unresolved state for Tomcat 5 can be seen here. Aspiring volunteers and others are strongly encouraged to attempt to comment and help resolve these issues.

    apache tomcat 5.5 servlet/jsp 容器 - tomcat的系统安全管理

    apache Tomcat 5.5 servlet/JSP 容器

    Tomcat的系统安全管理

    背景知识

    Java的SecurityManager允许浏览器在它可执行的范围内运行,这样可以 防止不可靠的程序读写用户在局部文件系统里的文件,或者未经授权进行网络连接,等等。同样, SecurityManager可用来防止不可靠的程序在你的浏览器上运行,在运行Tomcat时,使用 SecurityManager可以保护你的服务器不受到类似于木马的servlets, JSPs, JSP beans 和标签库(tag libraries)的影响,或者发生错误。

    试想某个被允许在你的网站上发表JSPs的人不慎包括了以下的语句在他们的JSP里:

    &lt;%System.exit(1);%&gt;

    每次Tomcat运行该JSP都会导致Tomcat中断。使用Java SecurityManager 如同多了一层防护, 可以让服务器更加安全可靠。

    警告——虽然Tomcat 5 的程序通过了安全检查,最重要的程序包都已被 保护,新的安全机制也已实施,但在允许用户发表网络程序,JSPs, servlets, beans, 或 标签库(tag libraries)之前,你还是有必要确保 SecurityManager 的各项配置符合你的要求。 当然,有SecurityManager绝对比没有它要安全的多。

    许可 Permissions

    Java的Permission类是用来定义Tomcat载入的类所拥有的权限。Java本身包括了一些 Permission类,你也可以在你的网络应用中加入你自己的Permission类。 这两种技术在Tomcat 5里都被应用。

    标准许可

    这里将简单总结标准系统中适用于Tomcat的SecurityManager 和 Permission 类。 更多信息请参看 http://java.sun.com/security/。

    • java.util.PropertyPermission - 控制读/写Java虚拟器的属性,如java.home 。
    • java.lang.RuntimePermission - 控制使用一些系统/运行时(System/Runtime)的功能,如exit() 和 exec()。它也控制包(package)的访问/定义。
    • java.io.FilePermission - 控制对文件和目录的读/写/执行操作。
    • java.net.SocketPermission - 控制使用网路sockets连接。
    • java.net.NetPermission - 控制使用multicast网路连接。
    • java.lang.reflect.ReflectPermission - 控制使用reflection来对类进行检视。
    • java.security.SecurityPermission - 控制对安全方法的访问。
    • java.security.AllPermission - 给予所有访问权限,就如你运行一个没有SecurityManager的Tomcat 。
    Tomcat 中可修改的许可

    Tomcat利用一个叫做org.apache.naming.JndiPermission 许可类。它用来控制以JNDI命名的文件资源的可读权限。该许可的名称是以JNDI来表达, 没有命令。在给予许可时,"*"的结尾可以用来以wild card方式映射JNDI命名 的文件资源。例如,你可以在你的政策(policy)文件加入以下一行:

    <table width="100%"><tr><td   height="1"></td><td  height="1"></td><td   height="1"></td></tr><tr><td  height="1"><pre>permission org.apache.naming.JndiPermission "jndi://localhost/examples/*";</pre></td></tr><tr><td   height="1"></td><td  height="1"></td><td   height="1"></td></tr></table>
    

    一个象这样的许可(Permission)会在部署网络程序时被自动产生,允许它读取它自己的静态资源, 但不允许它使用文件访问权来读取其它文件(除非你明确地给出访问那些文件的许可).

    并且, Tomcat 总是自动产生以下文件许可:

    permission java.io.FilePermission "** your application context**", "read";

    这里**your application context**代表那个拥有你的应用程序的文件夹(或者是WAR文件)。

    改变 Tomcat 中的 SecurityManager

    政策文件的格式

    由Java SecurityManager实现的安全政策被配置存放在 $CATALINA_HOME/conf/catalina.policy 文件里。这个文件完全替代了 JDK系统目录里的java.policy文件。这个catalina.policy 文件可以手动修改, 或者使用Java 1.2 及其后版本的 policytool 程序修改。

    catalina.policy 文件中的条文使用了标准的java.policy 文件格式,如下:

    // Example policy file entry 
    

    grant [signedBy &lt;signer&gt;,] [codeBase &lt;code source&gt;] {
    permission &lt;class&gt; [&lt;name&gt; [, &lt;action list&gt;]];
    };

    其中signedBycodeBase是选择项。 注释行是以"//"开始,直到该行结束。codeBase是URL的格式,文件的URL中可用如 ${java.home}和${catalina.home}等属性(这些属性会被扩展到由环境变量 JAVA_HOME 和 CATALINA_HOME为他们定义的目录路径)。

    缺省政策文件

    缺省$CATALINA_HOME/conf/catalina.policy 文件看起来象这样:

    // ============================================================================
    // catalina.corepolicy - Security Policy Permissions for Tomcat 5
    //
    // This file contains a default set of security policies to be enforced (by the
    // JVM) when Catalina is executed with the "-security" option.  In addition
    // to the permissions granted here, the following additional permissions are
    // granted to the codebase specific to each web application:
    //
    // * Read access to the document root directory
    //
    // $Id: security-manager-howto.xml 301460 2003-01-15 03:40:45Z glenn $
    // ============================================================================
    

    // ========== SYSTEM CODE PERMISSIONS =========================================
    // ========== 系统源码许可控制 ===============

    // These permissions apply to javac
    // 下面的许可适用于javac
    grant codeBase "file:${java.home}/lib/-" {
    permission java.security.AllPermission;
    };

    // These permissions apply to all shared system extensions
    // 下面的许可适用于java的扩展
    grant codeBase "file:${java.home}/jre/lib/ext/-" {
    permission java.security.AllPermission;
    };

    // These permissions apply to javac when ${java.home] points at $JAVA_HOME/jre
    // 下面的许可适用于当${java.home] 是 $JAVA_HOME/jre时的 javac
    grant codeBase "file:${java.home}/../lib/-" {
    permission java.security.AllPermission;
    };

    // These permissions apply to all shared system extensions when
    // 下面的许可适用于java的扩展
    // ${java.home} points at $JAVA_HOME/jre
    grant codeBase "file:${java.home}/lib/ext/-" {
    permission java.security.AllPermission;
    };

    // ========== CATALINA CODE PERMISSIONS =======================================
    // ========== CATALINA的源码许可控制 =============

    // These permissions apply to the launcher code
    // 以下许可适用于启动Tomcat的程序
    grant codeBase "file:${catalina.home}/bin/commons-launcher.jar" {
    permission java.security.AllPermission;
    };

    // These permissions apply to the server startup code
    // 以下许可适用于启动服务器的程序
    grant codeBase "file:${catalina.home}/bin/bootstrap.jar" {
    permission java.security.AllPermission;
    };

    // These permissions apply to the servlet API classes
    // and those that are shared across all class loaders
    // located in the "common" directory
    // 以下许可适用于 Servlet 的 API 和 common目录里的程序
    grant codeBase "file:${catalina.home}/common/-" {
    permission java.security.AllPermission;
    };

    // These permissions apply to the container's core code, plus any additional
    // libraries installed in the "server" directory
    // 下面的许可适用于Tomcat的核心和 server 目录里的程序
    grant codeBase "file:${catalina.home}/server/-" {
    permission java.security.AllPermission;
    };

    // ========== WEB APPLICATION PERMISSIONS =====================================
    // ========== WEB 应用的许可 ===========

    // These permissions are granted by default to all web applications
    // In addition, a web application will be given a read FilePermission
    // and JndiPermission for all files and directories in its document root.
    // 缺省情况下,所有WEB 应用拥有下面这些许可,另外还有 它们本身文件夹里的 “read” FilePermission
    // 和JndiPermission。

    grant {
    // Required for JNDI lookup of named JDBC DataSource's and
    // javamail named MimePart DataSource used to send mail
    permission java.util.PropertyPermission "java.home", "read";
    permission java.util.PropertyPermission "java.naming.", "read";
    permission java.util.PropertyPermission "javax.sql.
    ", "read";

    // OS Specific properties to allow read access
    permission java.util.PropertyPermission "os.name", "read";
    permission java.util.PropertyPermission "os.version", "read";
    permission java.util.PropertyPermission "os.arch", "read";
    permission java.util.PropertyPermission "file.separator", "read";
    permission java.util.PropertyPermission "path.separator", "read";
    permission java.util.PropertyPermission "line.separator", "read";

    // JVM properties to allow read access
    permission java.util.PropertyPermission "java.version", "read";
    permission java.util.PropertyPermission "java.vendor", "read";
    permission java.util.PropertyPermission "java.vendor.url", "read";
    permission java.util.PropertyPermission "java.class.version", "read";
    permission java.util.PropertyPermission "java.specification.version", "read";
    permission java.util.PropertyPermission "java.specification.vendor", "read";
    permission java.util.PropertyPermission "java.specification.name", "read";

    permission java.util.PropertyPermission "java.vm.specification.version", "read";
    permission java.util.PropertyPermission "java.vm.specification.vendor", "read";
    permission java.util.PropertyPermission "java.vm.specification.name", "read";
    permission java.util.PropertyPermission "java.vm.version", "read";
    permission java.util.PropertyPermission "java.vm.vendor", "read";
    permission java.util.PropertyPermission "java.vm.name", "read";
    

    // Required for getting BeanInfo
    permission java.lang.RuntimePermission "accessClassInPackage.sun.beans.*";

    // Required for OpenJMX
    permission java.lang.RuntimePermission "getAttribute";

    // Allow read of JAXP compliant XML parser debug
    permission java.util.PropertyPermission "jaxp.debug", "read";
    

    };

    // 你还可以给某个特定的WEB应用赋予其它许可。
    // You can assign additional permissions to particular web applications by
    // adding additional "grant" entries here, based on the code base for that
    // application, /WEB-INF/classes/, or /WEB-INF/lib/ jar files.
    //
    // Different permissions can be granted to JSP pages, classes loaded from
    // the /WEB-INF/classes/ directory, all jar files in the /WEB-INF/lib/
    // directory, or even to individual jar files in the /WEB-INF/lib/ directory.
    //
    // For instance, assume that the standard "examples" application
    // included a JDBC driver that needed to establish a network connection to the
    // corresponding database and used the scrape taglib to get the weather from
    // the NOAA web server. You might create a "grant" entries like this:
    //
    // The permissions granted to the context root directory apply to JSP pages.
    // grant codeBase "file:${catalina.home}/webapps/examples/-" {
    //permission java.net.SocketPermission "dbhost.mycompany.com:5432", "connect";
    //permission java.net.SocketPermission ".noaa.gov:80", "connect";
    // };
    //
    // The permissions granted to the context WEB-INF/classes directory
    // grant codeBase "file:${catalina.home}/webapps/examples/WEB-INF/classes/-" {
    // };
    //
    // The permission granted to your JDBC driver
    // grant codeBase "jar:file:${catalina.home}/webapps/examples/WEB-INF/lib/driver.jar!/-" {
    //permission java.net.SocketPermission "dbhost.mycompany.com:5432", "connect";
    // };
    // The permission granted to the scrape taglib
    // grant codeBase "jar:file:${catalina.home}/webapps/examples/WEB-INF/lib/scrape.jar!/-" {
    //permission java.net.SocketPermission "
    .noaa.gov:80", "connect";
    // };

    启动附带SecurityManager的Tomcat

    在你配置好与SecurityManager一起使用的catalina.policy文件之后, 你可以使用"-security"选项来启动Tomcat。

    $CATALINA_HOME/bin/catalina.sh start -security (Unix) 
    %CATALINA_HOME%\bin\catalina start -security (Windows)
    Configuring Package Protection in Tomcat

    从Tomcat 5开始,现在可以配置Tomcat内部包的许可。更多信息请参阅 http://java.sun.com/security/seccodeguide.html

    警告:删除缺省的包保护,可能打开一个安全漏洞。

    缺省的属性文件

    缺省的$CATALINA_HOME/conf/catalina.properties 文件看起来象这样:

    #
    # List of comma-separated packages that start with or equal this string
    # will cause a security exception to be thrown when
    # passed to checkPackageAccess unless the
    # corresponding RuntimePermission ("accessClassInPackage."+package) has
    # been granted.
    package.access=sun.,org.apache.catalina.,org.apache.coyote.,org.apache.tomcat.,
    org.apache.jasper.
    #
    # List of comma-separated packages that start with or equal this string
    # will cause a security exception to be thrown when
    # passed to checkPackageDefinition unless the
    # corresponding RuntimePermission ("defineClassInPackage."+package) has
    # been granted.
    #
    # by default, no packages are restricted for definition, and none of
    # the class loaders supplied with the JDK call checkPackageDefinition.
    #
    package.definition=sun.,java.,org.apache.catalina.,org.apache.coyote.,
    org.apache.tomcat.,org.apache.jasper.

    当你完成配置SecurityManager所需的catalina.properties 文件,记住要重新启动Tomcat。

    故障排除

    如果你的网络应用程序试图执行没有许可而被阻止的操作,SecurityManager探查出这样的违规后, 就会抛出一个AccessControLException 或 SecurityException。 要查出究竟缺少哪个许可往往非常困难,一个方法是打印执行过程中的所有关于安全决定的排错信息。 这可以在启动Tomcat之前通过设置系统属性来实现。最简单的办法是修改CATALINA_OPTS 环境变量。在启动Tomcat之前,执行下面这个命令:

    export CATALINA_OPTS=-Djava.security.debug=all (Unix) 
    set CATALINA_OPTS=-Djava.security.debug=all (Windows)

    (在启动Tomcat之前)。

    警告——这会产生很多megabytes的输出。不过,通过 查找"FAILED"这个词可以帮助你搜索问题所在,并确定哪个许可是要找的问题。 请参看Java安全文档资料,那里有你可指定的更多选项。

    apache tomcat 5.5 servlet/jsp 容器 - 安装 tomcat

    apache Tomcat 5.5 servlet/JSP 容器

    安装 Tomcat

    介绍

    这篇文档介绍了几种在不同的操作平台上运行Tomcat的安装方法。请注意,这里没包含一些高级 的设置问题:完整发布版 (ZIP 文件 or tarball)里有一个叫做RUNNING.txt的文件来讨论这些 问题。如果下面的信息不能回答你的某些问题的话,我们建议你再参考一下RUNNING.txt文件。

    Windows下使用安装版安装

    用Window安装版可以很简单地在Windows上安装Tomcat。 它的接口和功能与此其它安装程序相似,只需要几个有关的项目就行了。

    • 安装为系统服务:不管选什么样的设置,Tomcat都将被安装 成Windows NT/2K/XP 的系统服务。在组件那一页上,选中"auto" (“自动”) 运行,这样启动Windows时,Tomcat 就会自动启动。 从最佳安全性考虑,这种服务应该作为单独的用户来运行,它的操作权限也应被限制 (参看Windows服务管理工具以及帮助文档)。
    • Java路径:安装程式利用登记名册(registry)的信息,或者 JAVA_HOME 环境变量(variable)来决定J2SE 5 JRE的基础(base)路径(path)。
    • 任务栏图标: 当 Tomcat 作为服务运行时, 任务栏图标将不会出现。 如果你在安装的最后步骤选择运行 Tomcat,任务栏图标会同时出现一次。
    • 关于怎样把Tomcat作为Windows NT service进行管理的信息,请参考 Windows Service HOW-TO 。

    安装程式会产生一个快捷方式允许启动和配置Tomcat。必须注意Tomcat管理web应用程序只有在 Tomcat运行时才能被使用。

    如果使用J2SE 1.4 JRE,应该下载其相应的软件包并把它扩展在安装Tomcat所放置的文件夹里。

    Unix daemon

    应用commons-daemon项目里的jsvc工具可以很好地运行Tomcat。 Tomcat二进制(binaries) 里有jsvc的source tarballs, 需要被编译。 建立(building) jsvc需要用C ANSI编译器(如 GCC), GNU, Autoconf, and a JDK。

    在运行脚本(script)之前, JAVA_HOME的环境变量要被设定在JDK的基础路径 (base path)里,或者在调用(calling) ./configure脚本时, 用--with-java 参数(parameter)来设定JDK的路径, 比如./configure --with-java=/usr/java。

    应用下面的指令(command)可以产生一个编译过的jsvc二进制(文件),这个文件放在 $CATALINA_HOME/bin文件夹。 这里假设使用了GNU TAR, 同时 $CATALINA_HOME环境变量(environment variable)被设定在Tomcat安装的基础 路径上。 $CATALINA_HOME/bin

    请注意,你要用GNU make(g make),而不是用FreeBSD系统(system)本身的BSD make.

     cd $CATALINA_HOME/bin
     tar xvfz jsvc.tar.gz
     cd jsvc-src
     autoconf
     ./configure
     make
     cp jsvc ..
     cd ..
    

    然后Tomcat就可以用下面的命令很好地运行:

     cd $CATALINA_HOME
     ./bin/jsvc -Djava.endorsed.dirs=./common/endorsed -cp ./bin/bootstrap.jar \
      -outfile ./logs/catalina.out -errfile ./logs/catalina.err \
      org.apache.catalina.startup.Bootstrap
    

    javc还有其他的有用的参数,就象-user(用户),在daemon初始化(initialization) 完成以后,使它转换到另一个用户。这样,既使没有特使权的用户来运行Tomcat,也可以使用特定 的端口(privileged port)。 jsvc --help 会提供全面的jsvc使用信息。 特别是-debug 选项在jsvc运行时对排错很有用。

    文件$CATALINA_HOME/bin/jsvc/native/tomcat.sh 可被用作样板(template),在 开机时从/etc/init.d 自动启动Tomcat。 这个文件目前被设置来运行 Tomcat 4.1x, 所以需要修订一下,把类名(classname) BootstrapService 改成Bootstrap。 $CATALINA_HOME/bin/jsvc/native/tomcat.sh

    Commons-Daemon的JAR文件一定要在运行时的 classpath里面。如果你因为 Commons-Daemon 得到一个 ClassNotFoundException 或 NoClassDefFoundError, 请把 Commons-Daemon 的 JAR 用 -cp 选项加入到 classpath 里面,然后再启动 jsvc.