Dec
31
[原]解决Tomcat受环境变量影响不能启动https的问题
还是之前提供的x86_64操作系统平台上,运行Tomcat并启动https的问题。就像日志中描述的,在我的测试环境中部署非常顺利,几乎就没有遇到什么障碍。但把操作过程告知用户,结果访问https://ip:8443/时,就报错,最终无法连接。今天特到现场看看故障情况,经排查原来是用户的Oracle环境变量导致的,去掉有问题的变量后,https启动正常。
排查过程:
1、初步测试
在客户端上进行:
使用telnet ip 8443进行测试,连接正常,所以8443端口监听已经打开。
使用浏览器访问http://ip:8443,没有响应,服务器上用netstat查看连接状态,为ESTABLISHED,等待后一直超时。
2、删除证书
怀疑用户配置证书有问题,把/root/.keystore及/usr/java/latest/jre/lib/security/cacerts等证书全部删除,重建。
修改/usr/local/tomcat5.5.27/conf/server.xml中,关于https连接部分的密码修改为新证书的密码,重启Tomcat后,测试,不行。
再次删掉所有证书,重启Tomcat,发现奇怪问题,Tomcat logs日志中显示:
使用netstat确认,8443端口监听居然启动了。这是不正常的。
3、禁用https
修改/usr/local/tomcat5.5.27/conf/server.xml,把启动https监听部分的内容注释掉,再试,8443端口没有再次启动,说明确实是受该配置文件影响的。
4、使用32bit jdk环境
据用户描述,他们原来使用的是x86平台,部署方式相同,没有发现问题。
所以,安装32bit的jdk包,修改/root/.bashrc中的$JAVA_HOME、$JRE_HOME等路径指向,重启Tomcat,测试,https可以正常连接。
5、重装Tomcat和jdk
怀疑Tomcat或jdk经过多次的测试和改动后,有遗留文件,故把所有的文件删掉,重做x86_64环境,结果一样,不行。
6、修改环境变量
至此,我怀疑Tomcat在启动的时候,根本没有使用我创建的证书,而是使用了其他地方的证书。可能是环境变量的问题。
查看/root/.bashrc中的设置,有:
尝试把这些设定用#号注释掉,重新登陆root,再次启动Tomcat,日志中报:
好了,终于发现Tomcat会提示找不到证书,怀疑已经找到解决问题的方法。
再次重配/root/.keystore证书,启动Tomcat,访问https,一切正常。
至此,已经可以判定,访问Tomcat https失败的原因,就是由于设置了一些不合适的环境变量。
再做进一步的测试,并且由于服务器上根本就没有安装Oracle,$ORACLE_HOME和$ORACLE_BASE的路径都不存在,也就是说,主要的问题在于/usr/local/apr/lib的设定。这是用户的应用程序目录,是32bit的库文件,并不适用于x86_64环境,其影响了Tomcat在x86_64环境的正常运行。
排查过程:
1、初步测试
在客户端上进行:
使用telnet ip 8443进行测试,连接正常,所以8443端口监听已经打开。
使用浏览器访问http://ip:8443,没有响应,服务器上用netstat查看连接状态,为ESTABLISHED,等待后一直超时。
2、删除证书
怀疑用户配置证书有问题,把/root/.keystore及/usr/java/latest/jre/lib/security/cacerts等证书全部删除,重建。
修改/usr/local/tomcat5.5.27/conf/server.xml中,关于https连接部分的密码修改为新证书的密码,重启Tomcat后,测试,不行。
再次删掉所有证书,重启Tomcat,发现奇怪问题,Tomcat logs日志中显示:
引用
2008-12-31 10:31:52 org.apache.coyote.http11.Http11AprProtocol start
信息: Starting Coyote HTTP/1.1 on http-8443
信息: Starting Coyote HTTP/1.1 on http-8443
使用netstat确认,8443端口监听居然启动了。这是不正常的。
3、禁用https
修改/usr/local/tomcat5.5.27/conf/server.xml,把启动https监听部分的内容注释掉,再试,8443端口没有再次启动,说明确实是受该配置文件影响的。
4、使用32bit jdk环境
据用户描述,他们原来使用的是x86平台,部署方式相同,没有发现问题。
所以,安装32bit的jdk包,修改/root/.bashrc中的$JAVA_HOME、$JRE_HOME等路径指向,重启Tomcat,测试,https可以正常连接。
5、重装Tomcat和jdk
怀疑Tomcat或jdk经过多次的测试和改动后,有遗留文件,故把所有的文件删掉,重做x86_64环境,结果一样,不行。
6、修改环境变量
至此,我怀疑Tomcat在启动的时候,根本没有使用我创建的证书,而是使用了其他地方的证书。可能是环境变量的问题。
查看/root/.bashrc中的设置,有:
引用
export ORACLE_BASE=/oracle/oracle/product
export ORACLE_HOME=$ORACLE_BASE/10.2.0/db_3
export TNS_ADMIN=$ORACLE_HOME
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/usr/local/apr/lib:$LD_LIBRARY_PATH
export ORACLE_HOME=$ORACLE_BASE/10.2.0/db_3
export TNS_ADMIN=$ORACLE_HOME
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/usr/local/apr/lib:$LD_LIBRARY_PATH
尝试把这些设定用#号注释掉,重新登陆root,再次启动Tomcat,日志中报:
引用
严重: Error starting endpoint
java.io.FileNotFoundException: /root/.keystore (No such file or directory)
java.io.FileNotFoundException: /root/.keystore (No such file or directory)
好了,终于发现Tomcat会提示找不到证书,怀疑已经找到解决问题的方法。
再次重配/root/.keystore证书,启动Tomcat,访问https,一切正常。
至此,已经可以判定,访问Tomcat https失败的原因,就是由于设置了一些不合适的环境变量。
再做进一步的测试,并且由于服务器上根本就没有安装Oracle,$ORACLE_HOME和$ORACLE_BASE的路径都不存在,也就是说,主要的问题在于/usr/local/apr/lib的设定。这是用户的应用程序目录,是32bit的库文件,并不适用于x86_64环境,其影响了Tomcat在x86_64环境的正常运行。