安全设置运行 Java 服务的 Linux1
时间：2007-08-16 来源：心跳男人
安全设置运行 Java 服务的 Linux 为 Tomcat 构建一个安全的笼子
企业 Java 专家 Dennis Sosnoski 从 Java 服务器技术如何适合 Linux 来开始阐述他的观点，然后给出在 Linux 上安全地设置 Tomcat Java servlet 引擎的一点建议。
Linux 平台和 Java 平台有着久远的但有经常经历曲折的关系。构建高性能虚拟机的同时又要跟上日益增长的核心 Java API 集合，这样做所带来的复杂性在很大程度上使开发 Java 平台的开放源码“净室”实现的早期行动困难重重。Java 技术的特许实现最终可用于 Linux，但这些实现并不是开放源码。因此，大多数 Linux 分发版没有包含该特许实现。
尽管有这些困难，Java 平台还是提供了许多好处，从而导致在 Linux 上越来越多地使用该特许实现，尤其是对于服务器应用程序。在本文中，我回顾了 Java 平台给服务器应用程序带来的优点，然后研究了在 Linux 上简单且安全地部署 Java 服务所涉及的问题。作为一个实际示例，我将讨论设置 Apache Software Foundation 的广泛使用的 Tomcat Java servlet 引擎的详细信息以用于独立操作。
为什么使用 Java 平台？
有许多原因可以解释为什么 Java 平台成为基于服务器的商业应用程序的广为接受的选择。我将主要讨论我认为对于该环境至关重要的三个原因：跨平台兼容性、受管运行时环境和易于开发。
Java 应用程序提供了跨多种操作系统和硬件平台的二进制兼容性。对于非 GUI 服务器应用程序尤其是这样，在此类应用程序中，通常在实际目标系统中需要执行非常少的测试。开发人员可以在任何他们喜欢的平台上进行编码和调试，同时仍可以将这些应用程序部署到他们也许不能直接控制的环境中。
Java 虚拟机（Java Virtual Machine，JVM）环境的运行时特性以几种方式来加强程序安全性。最显著的方面之一是严格的类型检查、数组边界检查和自动垃圾收集的组合彻底防止了最具破坏性形式的服务器代码攻击：缓冲区溢出、重复释放的错误和游离的指针。Java 语言早期用于 applet，经过不断发展，该语言还有一个完善的系统，用于对那些已确信存在安全性风险的设施进行细颗粒度的访问控制。这些方法可供独立应用程序选择使用，但它们已构建在许多 Java 服务的框架中。
这些运行时程序安全特性还提供了用 Java 语言开发的便利性。要对便利性这类问题作任何精确测量是困难的，但大多数具有诸如 C 和 C++ 之类语言背景而转向 Java 编程的开发人员都承认在转变之后他们的生产力提高了。其中部分是因为在编译时和运行时严格执行类型确定，以及自动内存管理的简单性。另一个因素是为 Java 平台开发的标准 API 扩展的集合。这些 API 对于新的开发人员可能是一个重大挑战，但是一旦学会了，API 会为各种企业需求提供优秀的跨平台支持。
当然，对于某些应用程序而言，Java 平台可能是一个糟糕的选择。尽管 JVM 体系结构在持续改进，但 Java 应用程序通常会比使用相同算法的 C 或 C++ 应用程序运行得稍微慢一点。根据我的经验和测试，我估计这个速度差异对于在特许 JVM 上运行的大多数服务器应用程序来说大约是在 20％ 到 50％ 的范围内，然而这很大程度上取决于代码的质量。与独立程序相比，在这些 JVM 上运行的 Java 应用程序还忍受着比较慢的启动，但是这对于长时间运行的服务器应用程序通常并不是一个重大问题。在大多数情况中，降低的性能和较慢的启动只是为获得 Java 平台的增强的安全性和更快速的开发优点所付出的微小代价。
开放源码替代选择
除了标准特许 JVM（免费使用，但是源码受到限制；可用于 Sun、IBM、BEA 和 Blackdown 组织的 Linux）之外，对于 Linux 还有其它几个替代选择。这些选择包括“净室”开放源码 JVM 实现，其中使用最广泛的可能是 Kaffe（在许多 Linux 分发版中都包含它）。Kaffe 是一个非常有意义的项目，它已经完成了一些令人惊讶的工作，但它只能提供与当前特许 JVM 有限的兼容性。因此，它通常不可用于本文所关注的企业类型的服务器应用程序。
用于 Java 程序的本机代码编译器的开放源码工作也有几个替代选择。这里最重要的项目是 GNU 编译器集（GNU Compiler Collection）的 GCJ。使用诸如 CGJ 之类的本机代码编译器会将独立于平台的 Java 字节码在其执行之前转换成特定于平台的代码（这与在 JVM 中执行成对比，在 JVM 中执行通常在运行时将字节码转换成特定于平台的代码）。
本机代码编译显示出它极有可能成为一种避免在 JVM 中运行的 Java 应用程序启动较慢的方法。但是，使用这种方法的编译器通常都不能与当代特许 JVM 的稳定状态性能相匹配。如果 Java 应用程序使用 Java 平台的动态特性（如使用反射来访问字段或装入在运行时选择的类），这种情况尤其突出。根据所使用的实现和编译选项，本机代码编译也许还会削弱 Java 平台的许多运行时安全特性。最后，由于许可证问题，许多 Java API 不能与已编译的本机代码一起使用。由于这些限制，本机代码编译目前还不是 Java 平台服务器应用程序的一个好选择。
C# 怎么样？
与 Java 运行时环境有许多共同点的一个替代方法是 Microsoft 的 C# 语言和相关的公共语言运行时（Common Language Runtime，CLR）。C# 是 Java 语言的关系紧密的衍生物，CLR 可能允许 C# 在许多平台上使用。CLR 还提供了 JVM 的许多运行时安全特性（尽管有严重削弱安全保证的逃离出口）。Microsoft .Net 实现还支持预编译成本机代码的选项以获得更快速启动，这与 GCJ 对 Java 字节码所做的工作相同。当然，Linux 用户并不能直接使用这项功能，因为 .Net 只适用于 Windows 系统。
Mono Project 正致力于为多种 Linux 产品构建“净室”开放源码 C# 和等价于 CLR 的产品。现在，该项目中的 C# 编译器已开发完成，而且还完成了大部分的 CLR，Microsoft 已发布将它用于标准化。但是，无论从性能还是功能角度来看，在它成为合理的 Java 平台替代选择之前还有许多工作要做。CLR 只包含了与 Java 核心类库等价的基本内容。在可以将它看作是企业软件开发的合理选项之前，还需要用许多附加的 API 来补充它。
Mono Project 正在致力于开发 CLR 以外的 .Net 其它部分的移植，如果这些移植成功了 — 并且如果 Microsoft 不对 .Net 的这些部分强加它的专利权 — 那么它们会有助于满足 C# 成为 Linux 上服务器软件开发的可靠平台的需要。但要使那些假设成为现实，还需要做很多工作，同时，Java 程序的本机代码编译器和开放源码 JVM 向那些确实想要避免使用特许 JVM 并可以忍受有限功能性的用户提供了比较稳定的替代选择。
Apache Tomcat
最普遍存在的 Java 平台服务器应用程序之一是 Apache Tomcat。Tomcat 是基于最初由 Sun 捐赠的源代码的开放源码项目。它是一个 HTTP 服务器，是 Sun 通过 Java Community Process 开发的、对广泛使用的 servlet 和 JavaServer Page（JSP）技术的正式参考实现。我将在本文中使用 Tomcat 作为样本 Java 应用程序，将其部署成 Linux 上的一个服务。如果您想要尝试自己运行 Tomcat，那么您将需要在系统上安装 Java 开发工具箱（Java Development Kit，JDK），而不是安装更小的 Java 运行时环境（Java Runtime Environment，JRE）。
servlet 和 JSP 技术用于构造 HTTP 服务器应用程序。虽然 servlet 技术中添加了许多特性（包括访问安全性、会话管理和线程控制），但它本身只是粗略地等价于为快速直接的 Java 语言调用而定制的 CGI 接口。JSP 技术提供了一种处理动态生成的 HTML 页面的简便方法，这些 HTML 页面被直接编译成 servlet 以用于快速运行时操作。
在这两种技术之外，Tomcat 还提供了其它许多特性。凭它本身的性能，它实际上是全功能 Web 服务器，但它通常在 Linux 系统上与 Apache Web 服务器前端共同使用。Apache 向 Tomcat 提供了许多高级性能以适合静态内容。对于静态内容所占比例比较高且使用率很高的 Web 应用程序，Apache 前端非常有用。但对于许多简单的 Web 应用程序，就没必要使用它了，当更易于配置和管理时，单独运行 Tomcat 就可提供足够的性能（至少对于以前没有使用过 Apache 的开发人员来说是这样）。
端口难题
单独运行 Tomcat 的一个大问题是它不能访问标准 HTTP 端口 80，除非是作为 root 用户运行。作为 root 用户运行服务器应用程序的想法通常并不是上流公司所讨论的问题，因此我将完全放弃这个想法！使用除 80 以外的端口是一个更好的选择（例如，Tomcat 缺省端口 8080）。这通常适用于测试，但当用户正在访问服务时，它会导致杂乱的 URL，因为需要在请求中清楚地说明端口号。使用非标准端口还意味着如果需要外部访问，就需要重新配置所有的防火墙。
xinetd 解决方案
幸好，Linux 支持一些利用 Tomcat（或任何其它用户方式应用程序）处理端口 80 请求的简便方式。一种常用方式是通过 xinetd。xinetd 是带有广泛访问控制和日志记录支持的因特网服务守护程序，它还拥有方便的重定向特性。重定向让您将系统配置成接受一个端口上的进入请求，然后将请求传递到另一个端口或者甚至另一个 IP 地址进行处理。
如果您想要在系统上设置 Tomcat 以处理端口 80 请求，就需要添加 xinetd 配置文件来实现这一目的。假设按常规在缺省路径上安装了 xinetd，那么您可以通过对 /etc/xinetd.d 目录添加一个文件（以 root 用户身份）来执行这一操作。清单 1 提供了用于 Tomcat 的一个样本配置文件。
清单 1. xinetd 重定向配置
# Redirects any requests on port 80
# to port 8080 (where Tomcat is listening)
service tomcat
{
socket_type = stream
protocol = tcp
user = root
wait = no
port = 80
redirect = localhost 8080
disable = no
}
在添加了配置文件之后，需要重新启动 xinetd 来真正激活重定向。在大多数 Linux 安装上，通过以 root 用户身份执行以下命令来重新启动 xinetd：
/sbin/service xinetd restart
只要将配置文件放在 /etc/xinetd.d 目录中，当重新启动系统时，重定向就会自动启动。如果没有将 Tomcat 设置成自动启动，那么在启动 Tomcat 之前，会拒绝进入请求。
iptables 解决方案
xinetd 是处理请求重定向的一种好方法，但它运行了一个进程以在端口之间实际转发数据，这确实增加了一些开销。最新的 Linux 内核版本通过使用 iptables 来支持一种更好的设置重定向的方法。iptables 与 xinetd 的区别之处在于它是一个真正的内核组件。因此，它可以避免 xinetd 方法增加的开销。使用 iptables 的唯一缺点是它可能比 xinetd 更难以配置，而且它只可用于相当新的内核版本。
您需要运行支持 iptables 的 2.4.x 或更新的内核，以便使用我在这里描述的技术。配置和设置 iptables 是一个确信由几篇文章来单独描述的主题，所以我不打算在这里尝试讨论该主题。如果对 iptables 的入门需要帮助，请阅读 Linux 分发版的手册。要快速检查 iptables 是否在您的系统上运行，尝试以 root 用户身份执行：
/sbin/service iptables status
如果它正在运行，您将会在控制台上看到表和链的清单。
iptables 使用几个遵循包处理规则的不同的表和链。为了将进入 HTTP 请求从端口 80 重定向到系统中的另一个端口，您将要使用 nat 表（表示网络地址转换，Network Address Translation）和 PREROUTING 链。清单 2 提供了要执行的实际命令（以 root 用户身份），以便于添加一条处理这一请求的规则。这条规则的作用是将进入包的目标端口 80 修改成目标端口 8080，因此只有在您没有阻止从外部使用端口 8080 时，这条规则才会正确工作。一旦执行了该命令，您就应该能够立即处理进入请求。
清单 2. iptables 重定向规则
/sbin/iptables -t nat \
-A PREROUTING -j REDIRECT -p tcp \
--destination-port 80:80 --to-ports 8080
在您重新启动系统之前，它将一直有效。如果您想使该重定向永久有效，需要执行以下命令：
/sbin/service iptables save
以便于保存当前 iptables 配置。
自动启动 Tomcat
当运行诸如 Tomcat 之类的 Java 服务时的另一个问题是当系统启动时，如何自动启动该应用程序，以及当系统关机时如何自动停止它（换句话说，将它当作守护程序运行）。经验丰富的 Linux 用户已经知道怎样做，但如果您还是个 Linux 新手，以下就是一些基础知识。
如果您就在您的个人系统上运行它并且想要使用与直接运行 Tomcat 一样的对 Tomcat 的文件和目录的访问权，那么您可以用您自己的用户名来设置它。但是，通常，一个比较好的想法是：为将要作为守护程序运行的任何程序设置一个单独的用户。要针对 Tomcat 执行这一操作，以 root 用户身份执行：
/usr/sbin/useradd tomcat
这将创建一个名为 tomcat 的用户帐户并创建一个用于 Tomcat 安装的主目录 /home/tomcat。所创建的主目录的所有者是 tomcat 用户，而且通常只允许该用户访问（当然还有 root 用户）。如果想要从其它帐户访问 Tomcat 安装，可以将许可权更改成包括组访问权，并将 tomcat 组添加到这些其它帐户。
总之，要将 Tomcat 当作守护程序运行，需要将服务配置文件添加到 /etc/init.d 目录中，而您可能要将该文件命名为“tomcat”。清单 3 提供了该文件的样本。这假设了 Tomcat 安装在 /home/tomcat 下，并且该位置中有两个 shell 脚本文件，用于处理启动和停止服务器（tcstart.sh 和 tcstop.sh）。在执行实际的 Tomcat 启动或停止脚本之前，需要使用这些文件来设置 Tomcat 所需的环境变量（包括 JAVA_HOME 和 JDK_HOME）。
清单 3. Tomcat 服务定义
#!/bin/bash
#
# tomcat Starts Tomcat Java server.
#
#
# chkconfig: 345 88 12
# description: Tomcat is the server for Java servlet applications.
### BEGIN INIT INFO
# Provides: $tomcat
### END INIT INFO
# Source function library.
. /etc/init.d/functions
[ -f /home/tomcat/tcstart.sh ] || exit 0
[ -f /home/tomcat/tcstop.sh ] || exit 0
RETVAL=0
umask 077
start() {
echo -n $"Starting Tomcat Java server: "
daemon su -c /home/tomcat/tcstart.sh tomcat
echo
return $RETVAL
}
stop() {
echo -n $"Shutting down Tomcat Java server: "
daemon su -c /home/tomcat/tcstop.sh tomcat
echo
return $RETVAL
}
restart() {
stop
start
}
case "$1" in
start)
start
;;
stop)
stop
;;
restart|reload)
restart
;;
*)
echo $"Usage: $0 {start|stop|restart}"
exit 1
esac
exit $?
以下是一个样本 tcstart.sh，可以修改它来适合您的安装。
清单 4. 样本 tcstart.sh
#!/bin/bash
export JDK_HOME=/usr/java/jdk
export JAVA_HOME=/usr/java/jdk
#run the startup script from Tomcat installation
/home/tomcat/server/bin/startup.sh
chroot：最大的安全性监狱
对于真正的偏执狂，还可能进一步讨论保护 Java 语言服务。当该服务提供对本地文件系统的某种形式的访问权时，这尤其有用。JVM 运行时安全性特性并不能阻止已经有权访问文件系统的应用程序访问除了用户专用的文件之外的文件。在 Tomcat 的情况中，文件访问是它作为 HTTP 服务器使用时所固有的。它通常将为每个 Web 应用程序提供服务的文件限制为该应用程序目录中的那些文件，但 servlet 应用程序可以避开这些限制。当 Tomcat 与诸如 Apache 之类的前端 Web 服务器共同运行时，也会发生这种情况。
通过使用 chroot，您可以阻止 Tomcat（和所有在 Tomcat 下运行的 Web 应用程序）访问为该服务器留出的空间以外的任何东西。chroot 并不以任何方式特定于 Java 应用程序，但它是为 JVM 提供的安全性添加最终包装器的简便方法。我将在这里为那些不熟悉 chroot 概念的人介绍设置它的要点。
chroot 所做的类似于用于执行 Java 代码的 JVM 沙箱，但它适用于文件系统本身。chroot 执行一条命令并将您指定的位置设置成有效根目录。所执行的命令（可以是执行其它命令（包括应用程序）的 shell 脚本）只能访问所指定的有效根目录下的文件系统的一部分。文件系统的其余部分对于该命令来说完全不存在。
要对诸如 Tomcat 之类的应用程序使用 chroot，需要将一些基本系统应用程序和库（包括实际的 Java JDK 安装）复制到新的虚拟根目录下。这可能会占用许多空间 — 也许从一百兆字节到一千兆字节或更多 — 这取决于您想尽多少努力来将这些应用程序和库减少到最小。设置它的最简单方法也最浪费空间：只要将整个 /bin、/lib、/usr/bin 和 /usr/lib 目录树以及 Java 安装复制到新的根目录下，使 root 用户成为对所有文件的拥有者和唯一授权的写入者。如果想要让磁盘使用率保持到最小，可以有选择地只复制 chroot 中需要的命令（包括基本命令，如 ls、rm、echo 和 cat 等，以及实际的 Java 安装）以及那些命令使用的库（通过使用 ldd 可以找到那些库）。
接下来，您将需要创建一些附加的目录作为常规系统的缩减版本。这包括 /dev，以及设备 /dev/null 和 /dev/zero；/etc 以及 /etc/passwd 和 /etc/group 文件的已编辑版本（只保留 root 和 tomcat 项），也许还有主机。如果正在多处理器系统上运行，您还需要在新的根目录下挂装 /proc 系统，因为 JVM 使用该系统来协调各个处理器。
最后，为了在设置了 chroot 后仍作为用户 tomcat 运行，也许需要构建一个可以在虚拟根目录下运行的 su 命令版本（许多分发版的一般版本不允许这样做）。要这样做，可以从 GNU 项目获取 sh-utils 源码并根据该源码直接构建 su，然后将它复制到新的根目录的 /bin 目录中。
完成了所有这些设置后，可以尝试以 root 用户身份执行（假设新的根目录位于 /home/tomcat）：
/usr/sbin/chroot /home/tomcat /bin/su tomcat
如果设置正确，这应该让您在新的根目录下作为 tomcat 运行，而且您可以尝试使用您的脚本来启动和停止 Tomcat。在证实了所有东西都工作之后，最后一步就是将清单 3 中的 Tomcat 服务定义更改成使用 chroot 来代替 su，将 su 命令移到 tcstart.sh 脚本和 tcstop.sh 脚本。还需要确保只能由 root 用户修改这些脚本。
希望这篇概述的解释很清楚，这个过程并不适合胆小的人！如果您选择走使用 chroot 这条路线，但以前没有使用过 chroot，那么您一定要参考网上的 chroot 参考资料之一，以获取详细信息。但是这确实会给您的 Java 服务器代码可能最好的隔离，而且在某些情况下，带来的内心的宁静值得这样做。
结束语
Linux 和 Java 技术都正在赢得商业系统的市场份额。尽管开放源码 Linux 和特许 Java 技术之间存在着原理上的差异，但这两者在一起确实配合得很好。Linux 对于 Java 应用程序，尤其是对于服务器类型的应用程序是一个极好的部署环境，而 Java 技术是作为企业软件开发的先进方法而建立且得到了认可。
通过正确的预防措施，在 Linux 上运行的 Java 服务器应用程序可以提供非常高的安全性程度 — 甚至高于本机应用程序 — 因为 Java 技术消除了服务器应用程序中许多弱点的常见来源。Java 技术的跨平台性质所带来的是包括企业开发人员和 Linux 立即就绪的应用程序的巨大资源集合。Java 服务器应用程序开始在日益增长的 Linux 的服务器市场份额中扮演重要角色，而且这种趋势在将来只会帮助这两种技术。
我要感谢 Miles Sabin 向我指出了 /proc 文件系统，来解决在多处理器系统上 chroot Java 的问题
你可能还对以下内容感兴趣：java环境变量的设置，java环境设置，java设置，java classpath设置，手机java设置，三星手机java设置，java 设置焦点，java path设置，java路径设置，java上网设置，java设置背景，三星java设置，java 设置快捷键，java 设置button，java参数设置，java 权限设置，java home 如何设置，java如何设置，java 设置字体颜色，java编程环境设置。
企业 Java 专家 Dennis Sosnoski 从 Java 服务器技术如何适合 Linux 来开始阐述他的观点，然后给出在 Linux 上安全地设置 Tomcat Java servlet 引擎的一点建议。
Linux 平台和 Java 平台有着久远的但有经常经历曲折的关系。构建高性能虚拟机的同时又要跟上日益增长的核心 Java API 集合，这样做所带来的复杂性在很大程度上使开发 Java 平台的开放源码“净室”实现的早期行动困难重重。Java 技术的特许实现最终可用于 Linux，但这些实现并不是开放源码。因此，大多数 Linux 分发版没有包含该特许实现。
尽管有这些困难，Java 平台还是提供了许多好处，从而导致在 Linux 上越来越多地使用该特许实现，尤其是对于服务器应用程序。在本文中，我回顾了 Java 平台给服务器应用程序带来的优点，然后研究了在 Linux 上简单且安全地部署 Java 服务所涉及的问题。作为一个实际示例，我将讨论设置 Apache Software Foundation 的广泛使用的 Tomcat Java servlet 引擎的详细信息以用于独立操作。
为什么使用 Java 平台？
有许多原因可以解释为什么 Java 平台成为基于服务器的商业应用程序的广为接受的选择。我将主要讨论我认为对于该环境至关重要的三个原因：跨平台兼容性、受管运行时环境和易于开发。
Java 应用程序提供了跨多种操作系统和硬件平台的二进制兼容性。对于非 GUI 服务器应用程序尤其是这样，在此类应用程序中，通常在实际目标系统中需要执行非常少的测试。开发人员可以在任何他们喜欢的平台上进行编码和调试，同时仍可以将这些应用程序部署到他们也许不能直接控制的环境中。
Java 虚拟机（Java Virtual Machine，JVM）环境的运行时特性以几种方式来加强程序安全性。最显著的方面之一是严格的类型检查、数组边界检查和自动垃圾收集的组合彻底防止了最具破坏性形式的服务器代码攻击：缓冲区溢出、重复释放的错误和游离的指针。Java 语言早期用于 applet，经过不断发展，该语言还有一个完善的系统，用于对那些已确信存在安全性风险的设施进行细颗粒度的访问控制。这些方法可供独立应用程序选择使用，但它们已构建在许多 Java 服务的框架中。
这些运行时程序安全特性还提供了用 Java 语言开发的便利性。要对便利性这类问题作任何精确测量是困难的，但大多数具有诸如 C 和 C++ 之类语言背景而转向 Java 编程的开发人员都承认在转变之后他们的生产力提高了。其中部分是因为在编译时和运行时严格执行类型确定，以及自动内存管理的简单性。另一个因素是为 Java 平台开发的标准 API 扩展的集合。这些 API 对于新的开发人员可能是一个重大挑战，但是一旦学会了，API 会为各种企业需求提供优秀的跨平台支持。
当然，对于某些应用程序而言，Java 平台可能是一个糟糕的选择。尽管 JVM 体系结构在持续改进，但 Java 应用程序通常会比使用相同算法的 C 或 C++ 应用程序运行得稍微慢一点。根据我的经验和测试，我估计这个速度差异对于在特许 JVM 上运行的大多数服务器应用程序来说大约是在 20％ 到 50％ 的范围内，然而这很大程度上取决于代码的质量。与独立程序相比，在这些 JVM 上运行的 Java 应用程序还忍受着比较慢的启动，但是这对于长时间运行的服务器应用程序通常并不是一个重大问题。在大多数情况中，降低的性能和较慢的启动只是为获得 Java 平台的增强的安全性和更快速的开发优点所付出的微小代价。
开放源码替代选择
除了标准特许 JVM（免费使用，但是源码受到限制；可用于 Sun、IBM、BEA 和 Blackdown 组织的 Linux）之外，对于 Linux 还有其它几个替代选择。这些选择包括“净室”开放源码 JVM 实现，其中使用最广泛的可能是 Kaffe（在许多 Linux 分发版中都包含它）。Kaffe 是一个非常有意义的项目，它已经完成了一些令人惊讶的工作，但它只能提供与当前特许 JVM 有限的兼容性。因此，它通常不可用于本文所关注的企业类型的服务器应用程序。
用于 Java 程序的本机代码编译器的开放源码工作也有几个替代选择。这里最重要的项目是 GNU 编译器集（GNU Compiler Collection）的 GCJ。使用诸如 CGJ 之类的本机代码编译器会将独立于平台的 Java 字节码在其执行之前转换成特定于平台的代码（这与在 JVM 中执行成对比，在 JVM 中执行通常在运行时将字节码转换成特定于平台的代码）。
本机代码编译显示出它极有可能成为一种避免在 JVM 中运行的 Java 应用程序启动较慢的方法。但是，使用这种方法的编译器通常都不能与当代特许 JVM 的稳定状态性能相匹配。如果 Java 应用程序使用 Java 平台的动态特性（如使用反射来访问字段或装入在运行时选择的类），这种情况尤其突出。根据所使用的实现和编译选项，本机代码编译也许还会削弱 Java 平台的许多运行时安全特性。最后，由于许可证问题，许多 Java API 不能与已编译的本机代码一起使用。由于这些限制，本机代码编译目前还不是 Java 平台服务器应用程序的一个好选择。
C# 怎么样？
与 Java 运行时环境有许多共同点的一个替代方法是 Microsoft 的 C# 语言和相关的公共语言运行时（Common Language Runtime，CLR）。C# 是 Java 语言的关系紧密的衍生物，CLR 可能允许 C# 在许多平台上使用。CLR 还提供了 JVM 的许多运行时安全特性（尽管有严重削弱安全保证的逃离出口）。Microsoft .Net 实现还支持预编译成本机代码的选项以获得更快速启动，这与 GCJ 对 Java 字节码所做的工作相同。当然，Linux 用户并不能直接使用这项功能，因为 .Net 只适用于 Windows 系统。
Mono Project 正致力于为多种 Linux 产品构建“净室”开放源码 C# 和等价于 CLR 的产品。现在，该项目中的 C# 编译器已开发完成，而且还完成了大部分的 CLR，Microsoft 已发布将它用于标准化。但是，无论从性能还是功能角度来看，在它成为合理的 Java 平台替代选择之前还有许多工作要做。CLR 只包含了与 Java 核心类库等价的基本内容。在可以将它看作是企业软件开发的合理选项之前，还需要用许多附加的 API 来补充它。
Mono Project 正在致力于开发 CLR 以外的 .Net 其它部分的移植，如果这些移植成功了 — 并且如果 Microsoft 不对 .Net 的这些部分强加它的专利权 — 那么它们会有助于满足 C# 成为 Linux 上服务器软件开发的可靠平台的需要。但要使那些假设成为现实，还需要做很多工作，同时，Java 程序的本机代码编译器和开放源码 JVM 向那些确实想要避免使用特许 JVM 并可以忍受有限功能性的用户提供了比较稳定的替代选择。
Apache Tomcat
最普遍存在的 Java 平台服务器应用程序之一是 Apache Tomcat。Tomcat 是基于最初由 Sun 捐赠的源代码的开放源码项目。它是一个 HTTP 服务器，是 Sun 通过 Java Community Process 开发的、对广泛使用的 servlet 和 JavaServer Page（JSP）技术的正式参考实现。我将在本文中使用 Tomcat 作为样本 Java 应用程序，将其部署成 Linux 上的一个服务。如果您想要尝试自己运行 Tomcat，那么您将需要在系统上安装 Java 开发工具箱（Java Development Kit，JDK），而不是安装更小的 Java 运行时环境（Java Runtime Environment，JRE）。
servlet 和 JSP 技术用于构造 HTTP 服务器应用程序。虽然 servlet 技术中添加了许多特性（包括访问安全性、会话管理和线程控制），但它本身只是粗略地等价于为快速直接的 Java 语言调用而定制的 CGI 接口。JSP 技术提供了一种处理动态生成的 HTML 页面的简便方法，这些 HTML 页面被直接编译成 servlet 以用于快速运行时操作。
在这两种技术之外，Tomcat 还提供了其它许多特性。凭它本身的性能，它实际上是全功能 Web 服务器，但它通常在 Linux 系统上与 Apache Web 服务器前端共同使用。Apache 向 Tomcat 提供了许多高级性能以适合静态内容。对于静态内容所占比例比较高且使用率很高的 Web 应用程序，Apache 前端非常有用。但对于许多简单的 Web 应用程序，就没必要使用它了，当更易于配置和管理时，单独运行 Tomcat 就可提供足够的性能（至少对于以前没有使用过 Apache 的开发人员来说是这样）。
端口难题
单独运行 Tomcat 的一个大问题是它不能访问标准 HTTP 端口 80，除非是作为 root 用户运行。作为 root 用户运行服务器应用程序的想法通常并不是上流公司所讨论的问题，因此我将完全放弃这个想法！使用除 80 以外的端口是一个更好的选择（例如，Tomcat 缺省端口 8080）。这通常适用于测试，但当用户正在访问服务时，它会导致杂乱的 URL，因为需要在请求中清楚地说明端口号。使用非标准端口还意味着如果需要外部访问，就需要重新配置所有的防火墙。
xinetd 解决方案
幸好，Linux 支持一些利用 Tomcat（或任何其它用户方式应用程序）处理端口 80 请求的简便方式。一种常用方式是通过 xinetd。xinetd 是带有广泛访问控制和日志记录支持的因特网服务守护程序，它还拥有方便的重定向特性。重定向让您将系统配置成接受一个端口上的进入请求，然后将请求传递到另一个端口或者甚至另一个 IP 地址进行处理。
如果您想要在系统上设置 Tomcat 以处理端口 80 请求，就需要添加 xinetd 配置文件来实现这一目的。假设按常规在缺省路径上安装了 xinetd，那么您可以通过对 /etc/xinetd.d 目录添加一个文件（以 root 用户身份）来执行这一操作。清单 1 提供了用于 Tomcat 的一个样本配置文件。
清单 1. xinetd 重定向配置
# Redirects any requests on port 80
# to port 8080 (where Tomcat is listening)
service tomcat
{
socket_type = stream
protocol = tcp
user = root
wait = no
port = 80
redirect = localhost 8080
disable = no
}
在添加了配置文件之后，需要重新启动 xinetd 来真正激活重定向。在大多数 Linux 安装上，通过以 root 用户身份执行以下命令来重新启动 xinetd：
/sbin/service xinetd restart
只要将配置文件放在 /etc/xinetd.d 目录中，当重新启动系统时，重定向就会自动启动。如果没有将 Tomcat 设置成自动启动，那么在启动 Tomcat 之前，会拒绝进入请求。
iptables 解决方案
xinetd 是处理请求重定向的一种好方法，但它运行了一个进程以在端口之间实际转发数据，这确实增加了一些开销。最新的 Linux 内核版本通过使用 iptables 来支持一种更好的设置重定向的方法。iptables 与 xinetd 的区别之处在于它是一个真正的内核组件。因此，它可以避免 xinetd 方法增加的开销。使用 iptables 的唯一缺点是它可能比 xinetd 更难以配置，而且它只可用于相当新的内核版本。
您需要运行支持 iptables 的 2.4.x 或更新的内核，以便使用我在这里描述的技术。配置和设置 iptables 是一个确信由几篇文章来单独描述的主题，所以我不打算在这里尝试讨论该主题。如果对 iptables 的入门需要帮助，请阅读 Linux 分发版的手册。要快速检查 iptables 是否在您的系统上运行，尝试以 root 用户身份执行：
/sbin/service iptables status
如果它正在运行，您将会在控制台上看到表和链的清单。
iptables 使用几个遵循包处理规则的不同的表和链。为了将进入 HTTP 请求从端口 80 重定向到系统中的另一个端口，您将要使用 nat 表（表示网络地址转换，Network Address Translation）和 PREROUTING 链。清单 2 提供了要执行的实际命令（以 root 用户身份），以便于添加一条处理这一请求的规则。这条规则的作用是将进入包的目标端口 80 修改成目标端口 8080，因此只有在您没有阻止从外部使用端口 8080 时，这条规则才会正确工作。一旦执行了该命令，您就应该能够立即处理进入请求。
清单 2. iptables 重定向规则
/sbin/iptables -t nat \
-A PREROUTING -j REDIRECT -p tcp \
--destination-port 80:80 --to-ports 8080
在您重新启动系统之前，它将一直有效。如果您想使该重定向永久有效，需要执行以下命令：
/sbin/service iptables save
以便于保存当前 iptables 配置。
自动启动 Tomcat
当运行诸如 Tomcat 之类的 Java 服务时的另一个问题是当系统启动时，如何自动启动该应用程序，以及当系统关机时如何自动停止它（换句话说，将它当作守护程序运行）。经验丰富的 Linux 用户已经知道怎样做，但如果您还是个 Linux 新手，以下就是一些基础知识。
如果您就在您的个人系统上运行它并且想要使用与直接运行 Tomcat 一样的对 Tomcat 的文件和目录的访问权，那么您可以用您自己的用户名来设置它。但是，通常，一个比较好的想法是：为将要作为守护程序运行的任何程序设置一个单独的用户。要针对 Tomcat 执行这一操作，以 root 用户身份执行：
/usr/sbin/useradd tomcat
这将创建一个名为 tomcat 的用户帐户并创建一个用于 Tomcat 安装的主目录 /home/tomcat。所创建的主目录的所有者是 tomcat 用户，而且通常只允许该用户访问（当然还有 root 用户）。如果想要从其它帐户访问 Tomcat 安装，可以将许可权更改成包括组访问权，并将 tomcat 组添加到这些其它帐户。
总之，要将 Tomcat 当作守护程序运行，需要将服务配置文件添加到 /etc/init.d 目录中，而您可能要将该文件命名为“tomcat”。清单 3 提供了该文件的样本。这假设了 Tomcat 安装在 /home/tomcat 下，并且该位置中有两个 shell 脚本文件，用于处理启动和停止服务器（tcstart.sh 和 tcstop.sh）。在执行实际的 Tomcat 启动或停止脚本之前，需要使用这些文件来设置 Tomcat 所需的环境变量（包括 JAVA_HOME 和 JDK_HOME）。
清单 3. Tomcat 服务定义
#!/bin/bash
#
# tomcat Starts Tomcat Java server.
#
#
# chkconfig: 345 88 12
# description: Tomcat is the server for Java servlet applications.
### BEGIN INIT INFO
# Provides: $tomcat
### END INIT INFO
# Source function library.
. /etc/init.d/functions
[ -f /home/tomcat/tcstart.sh ] || exit 0
[ -f /home/tomcat/tcstop.sh ] || exit 0
RETVAL=0
umask 077
start() {
echo -n $"Starting Tomcat Java server: "
daemon su -c /home/tomcat/tcstart.sh tomcat
echo
return $RETVAL
}
stop() {
echo -n $"Shutting down Tomcat Java server: "
daemon su -c /home/tomcat/tcstop.sh tomcat
echo
return $RETVAL
}
restart() {
stop
start
}
case "$1" in
start)
start
;;
stop)
stop
;;
restart|reload)
restart
;;
*)
echo $"Usage: $0 {start|stop|restart}"
exit 1
esac
exit $?
以下是一个样本 tcstart.sh，可以修改它来适合您的安装。
清单 4. 样本 tcstart.sh
#!/bin/bash
export JDK_HOME=/usr/java/jdk
export JAVA_HOME=/usr/java/jdk
#run the startup script from Tomcat installation
/home/tomcat/server/bin/startup.sh
chroot：最大的安全性监狱
对于真正的偏执狂，还可能进一步讨论保护 Java 语言服务。当该服务提供对本地文件系统的某种形式的访问权时，这尤其有用。JVM 运行时安全性特性并不能阻止已经有权访问文件系统的应用程序访问除了用户专用的文件之外的文件。在 Tomcat 的情况中，文件访问是它作为 HTTP 服务器使用时所固有的。它通常将为每个 Web 应用程序提供服务的文件限制为该应用程序目录中的那些文件，但 servlet 应用程序可以避开这些限制。当 Tomcat 与诸如 Apache 之类的前端 Web 服务器共同运行时，也会发生这种情况。
通过使用 chroot，您可以阻止 Tomcat（和所有在 Tomcat 下运行的 Web 应用程序）访问为该服务器留出的空间以外的任何东西。chroot 并不以任何方式特定于 Java 应用程序，但它是为 JVM 提供的安全性添加最终包装器的简便方法。我将在这里为那些不熟悉 chroot 概念的人介绍设置它的要点。
chroot 所做的类似于用于执行 Java 代码的 JVM 沙箱，但它适用于文件系统本身。chroot 执行一条命令并将您指定的位置设置成有效根目录。所执行的命令（可以是执行其它命令（包括应用程序）的 shell 脚本）只能访问所指定的有效根目录下的文件系统的一部分。文件系统的其余部分对于该命令来说完全不存在。
要对诸如 Tomcat 之类的应用程序使用 chroot，需要将一些基本系统应用程序和库（包括实际的 Java JDK 安装）复制到新的虚拟根目录下。这可能会占用许多空间 — 也许从一百兆字节到一千兆字节或更多 — 这取决于您想尽多少努力来将这些应用程序和库减少到最小。设置它的最简单方法也最浪费空间：只要将整个 /bin、/lib、/usr/bin 和 /usr/lib 目录树以及 Java 安装复制到新的根目录下，使 root 用户成为对所有文件的拥有者和唯一授权的写入者。如果想要让磁盘使用率保持到最小，可以有选择地只复制 chroot 中需要的命令（包括基本命令，如 ls、rm、echo 和 cat 等，以及实际的 Java 安装）以及那些命令使用的库（通过使用 ldd 可以找到那些库）。
接下来，您将需要创建一些附加的目录作为常规系统的缩减版本。这包括 /dev，以及设备 /dev/null 和 /dev/zero；/etc 以及 /etc/passwd 和 /etc/group 文件的已编辑版本（只保留 root 和 tomcat 项），也许还有主机。如果正在多处理器系统上运行，您还需要在新的根目录下挂装 /proc 系统，因为 JVM 使用该系统来协调各个处理器。
最后，为了在设置了 chroot 后仍作为用户 tomcat 运行，也许需要构建一个可以在虚拟根目录下运行的 su 命令版本（许多分发版的一般版本不允许这样做）。要这样做，可以从 GNU 项目获取 sh-utils 源码并根据该源码直接构建 su，然后将它复制到新的根目录的 /bin 目录中。
完成了所有这些设置后，可以尝试以 root 用户身份执行（假设新的根目录位于 /home/tomcat）：
/usr/sbin/chroot /home/tomcat /bin/su tomcat
如果设置正确，这应该让您在新的根目录下作为 tomcat 运行，而且您可以尝试使用您的脚本来启动和停止 Tomcat。在证实了所有东西都工作之后，最后一步就是将清单 3 中的 Tomcat 服务定义更改成使用 chroot 来代替 su，将 su 命令移到 tcstart.sh 脚本和 tcstop.sh 脚本。还需要确保只能由 root 用户修改这些脚本。
希望这篇概述的解释很清楚，这个过程并不适合胆小的人！如果您选择走使用 chroot 这条路线，但以前没有使用过 chroot，那么您一定要参考网上的 chroot 参考资料之一，以获取详细信息。但是这确实会给您的 Java 服务器代码可能最好的隔离，而且在某些情况下，带来的内心的宁静值得这样做。
结束语
Linux 和 Java 技术都正在赢得商业系统的市场份额。尽管开放源码 Linux 和特许 Java 技术之间存在着原理上的差异，但这两者在一起确实配合得很好。Linux 对于 Java 应用程序，尤其是对于服务器类型的应用程序是一个极好的部署环境，而 Java 技术是作为企业软件开发的先进方法而建立且得到了认可。
通过正确的预防措施，在 Linux 上运行的 Java 服务器应用程序可以提供非常高的安全性程度 — 甚至高于本机应用程序 — 因为 Java 技术消除了服务器应用程序中许多弱点的常见来源。Java 技术的跨平台性质所带来的是包括企业开发人员和 Linux 立即就绪的应用程序的巨大资源集合。Java 服务器应用程序开始在日益增长的 Linux 的服务器市场份额中扮演重要角色，而且这种趋势在将来只会帮助这两种技术。
我要感谢 Miles Sabin 向我指出了 /proc 文件系统，来解决在多处理器系统上 chroot Java 的问题
你可能还对以下内容感兴趣：java环境变量的设置，java环境设置，java设置，java classpath设置，手机java设置，三星手机java设置，java 设置焦点，java path设置，java路径设置，java上网设置，java设置背景，三星java设置，java 设置快捷键，java 设置button，java参数设置，java 权限设置，java home 如何设置，java如何设置，java 设置字体颜色，java编程环境设置。
相关阅读 更多 +
