CentOS 7下Yum安装Tomcat 7：企业级包管理与等保加固实践

1. 为什么在 CentOS 7 上用 Yum 安装 Tomcat 7 已成“考古级操作”，但你仍需掌握它

Apache Tomcat 7 是一个早已停止官方支持的版本（2015 年底结束生命周期），CentOS 7 本身也已于 2024 年 6 月 30 日正式进入 EOL（End of Life）状态。当你在搜索引擎里输入“Tomcat 7 CentOS 7 yum”，刷出来的几乎全是 2016–2019 年间的博客，配图还是 GNOME 3.8 桌面、Terminal 里飘着绿色字体的 # 提示符——这确实像在翻阅服务器运维的旧胶片。但现实是：我上个月刚接手一个金融行业遗留系统迁移项目，三台物理服务器上跑着 2013 年上线的信贷审批中间件，后端硬编码依赖 Servlet 3.0 规范（Tomcat 7 唯一完整支持的版本），Java 6 编译字节码，连 JVM 参数都写死在 /etc/init.d/tomcat 脚本里。客户明确要求：“不能改一行业务代码，不能升 Java 版本，不能换容器”。这时候，任何鼓吹“直接上 Tomcat 10+ + Jakarta EE”的方案都是纸上谈兵。

更关键的是， Yum 安装路径背后藏着 CentOS 7 时代最典型的包管理逻辑分层 ：它不只是一条 yum install tomcat 命令，而是牵扯到系统级服务封装（ systemd 单元文件）、用户隔离（ tomcat 系统用户权限控制）、目录结构标准化（ /usr/libexec/tomcat vs /opt/tomcat 手动解压版）、以及最关键的—— Yum 源仓库中软件包的构建策略差异 。比如，EPEL（Extra Packages for Enterprise Linux）源里的 tomcat7 包，实际是 Red Hat 在 RHEL 7 中为兼容老系统打的“兼容性补丁包”，它把上游 Apache 发布的二进制包重新打包，注入了符合 RHEL/CentOS 安全基线的 systemd 配置、日志轮转规则和 SELinux 策略模块。而如果你跳过 Yum 直接下载 tar.gz 手动部署，后续做安全加固审计时，会发现 ps aux | grep java 显示的进程属主是 root ， /var/log/tomcat 权限是 755 ，SELinux 上下文是 unconfined_u:object_r:default_t:s0 ——这些在等保 2.0 或金融行业监管检查中，全都是高风险项。

所以，这不是教你怎么装一个过时软件，而是带你拆解一个经典 Linux 发行版中“包即策略”的落地范式。你将看到：Yum 如何把 Apache 的开源项目，变成符合企业 IT 治理要求的可审计、可回滚、可批量管理的系统组件。全文所有步骤均基于真实生产环境复现，包括我在某省政务云平台处理 172 台 CentOS 7 虚拟机集群时踩过的坑——比如 yum install tomcat7 后服务起不来，不是配置错了，而是 firewalld 默认放行了 http 但没放 8009 （AJP 端口），导致负载均衡器健康检查失败；再比如 systemctl start tomcat7 报 Permission denied ，根源在于 /usr/share/tomcat7/conf/web.xml 被 SELinux 标记为 admin_home_t 类型，而非 tomcat_etc_t 。这些细节，文档不会写，但运维现场天天见。

2. Yum 源的底层真相：为什么默认仓库没有 tomcat7，而 EPEL 有且仅此一家

CentOS 7 的官方 base 和 updates 仓库里， 根本不存在 tomcat7 这个软件包 。这是很多初学者执行 yum search tomcat 后一脸懵的根源。你搜到的可能是 tomcatjss （Java Security Services 扩展）、 tomcat-native （APR 本地库），甚至 tomcat-el-3.0-api （EL 表达式 API），但就是没有 tomcat7 。这不是遗漏，而是 Red Hat 的明确策略：RHEL/CentOS 的 base 仓库只提供核心操作系统组件（内核、glibc、systemd、bash 等），所有应用级中间件（Tomcat、Nginx、PostgreSQL）均由 EPEL 仓库提供。EPEL 是由 Fedora Project 维护的社区扩展源，其定位非常清晰——“为 RHEL/CentOS 提供高质量、无冲突、不替代 base 仓库的额外软件包”。

那么问题来了：为什么 EPEL 里有 tomcat7 ，却没有 tomcat8 或 tomcat9 ？答案藏在 EPEL 的包维护哲学里。EPEL 不追求“最新版”，而是追求“稳定兼容版”。Tomcat 7 是最后一个原生支持 Servlet 3.0 / JSP 2.2 / EL 2.2 的版本，而 RHEL 7 的 JDK 7（ java-1.7.0-openjdk ）正是为这一套规范深度适配的。当 EPEL 维护者打包 tomcat7 时，他们做的不是简单搬运 Apache 官网的二进制包，而是进行了一整套企业级改造：

• 服务化封装 ：生成 /usr/lib/systemd/system/tomcat7.service 文件，定义了标准的 Type=forking 启动类型、 PIDFile=/var/run/tomcat7/tomcat7.pid 、 Environment=JAVA_HOME=/usr/lib/jvm/java-1.7.0 ，并设置了 RestartSec=10 自动重启间隔；
• 用户与权限隔离 ：创建专用系统用户 tomcat （UID 91），组 tomcat （GID 91），所有运行时文件（日志、临时文件、工作目录）强制归属该用户，杜绝 root 运行风险；
• 目录结构标准化 ：配置文件统一放在 /etc/tomcat7/ （符号链接到 /usr/share/tomcat7/conf/ ），Web 应用部署目录为 /var/lib/tomcat7/webapps/ ，日志输出到 /var/log/tomcat7/ ，完全遵循 Linux Filesystem Hierarchy Standard（FHS）；
• SELinux 策略嵌入 ：在 RPM 包中预编译了 tomcat7_selinux.pp 策略模块，确保 tomcat7_t 域能合法读取 tomcat_etc_t 类型的配置文件、写入 tomcat_log_t 类型的日志、绑定 http_port_t 端口（8080）和 ajp_port_t 端口（8009）。

提示：你可以用 rpm -ql tomcat7 查看 EPEL 包安装的所有文件路径，用 rpm -qi tomcat7 查看包的详细信息（维护者、构建时间、描述）。你会发现它的 Build Date 是 2018 年 10 月， Vendor 是 "Fedora Project"，这印证了它是社区长期维护的稳定分支，而非上游快照。

而如果你试图在 CentOS 7 上安装 Tomcat 8+，会立刻掉进兼容性陷阱。Tomcat 8 要求 Servlet 3.1，这需要 JDK 8+；但 RHEL 7/CentOS 7 的 base 仓库默认只提供 JDK 7（ java-1.7.0-openjdk ），JDK 8 是作为 java-1.8.0-openjdk 单独包存在，且未被 tomcat7 的依赖关系声明所引用。强行 yum install tomcat8 会导致依赖冲突，因为 tomcat8 包的 Requires: java >= 1.8.0 无法被 base 仓库满足。这就是为什么 EPEL 只打包 Tomcat 7——它和系统默认 JDK 形成了完美的“最小可行兼容对”。

3. 从零配置 EPEL 源到启动成功：每一步背后的决策逻辑与实操验证

在 CentOS 7 Minimal 安装环境下（这是生产服务器最常见形态），EPEL 源默认是禁用的。你需要手动启用它，但绝不是简单执行 yum install epel-release 就完事。这里有一套必须遵循的顺序和验证点，否则后续安装必然失败。

3.1 启用 EPEL 源的三步法：为什么不能跳过 GPG 密钥校验

第一步，安装 EPEL 仓库元数据包：

yum install -y epel-release

这条命令看似简单，实则触发了 Yum 的完整信任链校验。 epel-release 包本身是一个 RPM，它包含 /etc/yum.repos.d/epel.repo 和 /etc/yum.repos.d/epel-testing.repo 两个配置文件，以及最重要的 /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7 密钥文件。当你执行 yum install 时，Yum 会先用这个密钥验证 epel-release 包的数字签名，确保它来自可信的 Fedora Project 维护者，而非被中间人篡改的恶意包。如果网络环境受限（如内网离线环境），这一步会卡住，报错 GPG key retrieval failed 。

第二步，强制刷新仓库缓存并验证密钥：

yum clean all
yum makecache

yum clean all 清除所有本地缓存（metadata、packages、db），避免旧缓存干扰； yum makecache 则重新下载 EPEL 仓库的 repomd.xml （元数据索引）和 primary.xml.gz （软件包列表），并用 RPM-GPG-KEY-EPEL-7 校验其完整性。此时，你应该看到类似输出：

Metadata Cache Created.
...
Importing GPG key 0x352C64E5:
 Userid     : "Fedora EPEL (7) <epel@fedoraproject.org>"
 Fingerprint: 91e9 7d7c 4a5a 25a9 b488 6a06 1b06 1b06 352c 64e5
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7

如果没看到 Importing GPG key 行，说明密钥未正确导入，后续 yum install tomcat7 会因包签名验证失败而中止。

第三步，确认 EPEL 源已启用且可访问：

yum repolist enabled | grep epel

正常输出应为：

epel/x86_64                    Extra Packages for Enterprise Linux 7 - x86_64    13,652

注意 13,652 这个数字——它代表当前 EPEL 7 仓库中可用的软件包总数。如果显示 0 或报错 Cannot retrieve metalink... ，说明网络不通或镜像源不可用。此时需检查 /etc/yum.repos.d/epel.repo ，将 baseurl 改为国内镜像（如阿里云）：

[epel]
name=Extra Packages for Enterprise Linux 7 - $basearch
# 注释掉默认的 mirrorlist
# mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch
# 启用阿里云镜像
baseurl=https://mirrors.aliyun.com/epel/7/$basearch
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7

注意：切勿在生产环境使用 gpgcheck=0 关闭签名验证！这等于放弃软件供应链安全的第一道防线。我曾见过某公司因关闭 GPG 校验，被植入了带挖矿木马的 nginx 包，导致整个集群 CPU 100%。

3.2 安装 Tomcat 7 及其依赖：为什么必须显式安装 java-1.7.0-openjdk

执行安装命令：

yum install -y tomcat7 tomcat7-webapps tomcat7-admin-webapps java-1.7.0-openjdk

这里必须显式指定 java-1.7.0-openjdk ，原因有二：

1. 依赖解析的不确定性 ：虽然 tomcat7 包的 .spec 文件中声明了 Requires: java >= 1.7.0 ，但 Yum 的依赖解析器在面对多个 JDK 版本共存时（如系统里同时有 java-1.7.0-openjdk 和 java-1.8.0-openjdk ），可能随机选择一个满足条件的版本。而 Tomcat 7 与 JDK 8 存在类加载器兼容性问题——JDK 8 的 java.util.Optional 类在 Tomcat 7 的 catalina.jar 中被反射调用，但 Tomcat 7 的类加载器未将其加入 common.loader ，导致 NoClassDefFoundError 。显式安装 JDK 7，锁定了运行时环境。

2. JAVA_HOME 的自动配置 ： java-1.7.0-openjdk 包安装后，会在 /usr/lib/jvm/ 下创建标准路径 /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.261.x86_64/ ，并更新 /etc/alternatives/java 符号链接。 tomcat7 的 systemd 服务文件 /usr/lib/systemd/system/tomcat7.service 中的 Environment=JAVA_HOME=/usr/lib/jvm/java-1.7.0 正是依赖于此。如果不装 JDK 7， JAVA_HOME 指向空目录，服务启动必败。

安装完成后，验证核心文件是否存在：

# 检查 Tomcat 主目录结构
ls -l /usr/share/tomcat7/
# 应有 bin/, conf/, lib/, logs/, temp/, webapps/, work/ 等标准目录

# 检查 systemd 服务文件
systemctl cat tomcat7.service | grep -E "(ExecStart|Environment|PIDFile)"
# 输出应显示 ExecStart=/usr/libexec/tomcat7/tomcat7 start 等关键行

# 检查 JAVA_HOME 是否正确指向 JDK 7
source /usr/libexec/tomcat7/tomcat7-functions
echo $JAVA_HOME
# 应输出 /usr/lib/jvm/java-1.7.0

3.3 启动服务前的三项强制检查：SELinux、防火墙、端口占用

Tomcat 7 默认监听 8080（HTTP）和 8009（AJP）端口。在 CentOS 7 上，这三个检查项任何一个失败，都会导致 systemctl start tomcat7 看似成功（返回 Active: active (running) ），但 curl http://localhost:8080 却超时。

第一项：SELinux 上下文检查

# 查看 Tomcat 主目录的 SELinux 类型
ls -Z /usr/share/tomcat7/
# 正常应为 system_u:object_r:tomcat_exec_t:s0
# 如果是 unconfined_u:object_r:default_t:s0，说明上下文损坏，需修复
sudo semanage fcontext -a -t tomcat_exec_t "/usr/share/tomcat7(/.*)?"
sudo restorecon -Rv /usr/share/tomcat7/

# 查看配置文件目录
ls -Z /etc/tomcat7/
# 应为 system_u:object_r:tomcat_etc_t:s0

SELinux 是 CentOS 7 的默认强制访问控制模块，它比传统 Unix 权限更细粒度。 tomcat_exec_t 类型允许进程以 tomcat_t 域运行，而 tomcat_etc_t 类型允许该域读取配置。如果上下文错误，Tomcat 进程会被 SELinux 拒绝读取 server.xml ，静默失败。

第二项：firewalld 端口放行

# 检查 8080 端口是否在 public zone 中放行
sudo firewall-cmd --zone=public --list-ports | grep 8080
# 若无输出，添加放行
sudo firewall-cmd --zone=public --add-port=8080/tcp --permanent
sudo firewall-cmd --reload

# 同样检查 AJP 端口（负载均衡必需）
sudo firewall-cmd --zone=public --add-port=8009/tcp --permanent
sudo firewall-cmd --reload

CentOS 7 默认启用 firewalld ，其规则比旧版 iptables 更严格。 --permanent 参数确保重启后规则依然生效， --reload 是热加载，避免重启服务中断。

第三项：端口占用排查

# 检查 8080 是否被其他进程占用
sudo ss -tuln | grep ':8080'
# 若有输出，如 *:8080 LISTEN 1234/nginx，则需停用冲突服务
sudo systemctl stop nginx
sudo systemctl disable nginx

常见冲突源是 nginx （被误装为反向代理）或 httpd （Apache HTTP Server）。Tomcat 7 的 server.xml 默认配置 <Connector port="8080" .../> ，若端口被占，启动日志 /var/log/tomcat7/catalina.out 会报 Address already in use ，但 systemctl status 仍显示 active，极具迷惑性。

完成这三项检查后，启动服务：

sudo systemctl start tomcat7
sudo systemctl enable tomcat7  # 设置开机自启
sudo systemctl status tomcat7  # 验证状态

成功状态应显示 Active: active (running) ，且 curl http://localhost:8080 返回 Tomcat 7 的欢迎页 HTML。

4. 生产环境不可绕过的五项加固配置：从默认漏洞到等保合规

Yum 安装的 tomcat7 包提供了开箱即用的基础功能，但其默认配置在生产环境中存在严重安全隐患，必须立即加固。以下是我在金融、政务类项目中强制执行的五项配置，全部基于等保 2.0 三级要求和 OWASP Top 10 标准。

4.1 删除默认管理界面：为什么 manager 和 host-manager 是最大攻击入口

Tomcat 7 的 tomcat7-admin-webapps 包安装后，会在 /var/lib/tomcat7/webapps/ 下部署 manager 和 host-manager 两个 Web 应用。它们的默认登录凭证存储在 /etc/tomcat7/tomcat-users.xml 中，初始内容为：

<tomcat-users>
  <role rolename="manager-gui"/>
  <role rolename="manager-script"/>
  <role rolename="manager-jmx"/>
  <role rolename="manager-status"/>
  <user username="tomcat" password="s3cret" roles="manager-gui,manager-status"/>
</tomcat-users>

这个配置等同于在服务器上敞开一扇门：用户名 tomcat 、密码 s3cret （明文硬编码）、且拥有 manager-gui （图形界面）权限，任何能访问 8080 端口的人都可上传 WAR 包、执行任意脚本、甚至获取服务器 shell。2023 年某银行中间件被黑事件，根源就是运维人员未删除此默认配置，黑客通过扫描 http://ip:8080/manager/html 入侵。

加固操作 ：

# 1. 彻底删除管理应用目录
sudo rm -rf /var/lib/tomcat7/webapps/manager/
sudo rm -rf /var/lib/tomcat7/webapps/host-manager/

# 2. 清空 tomcat-users.xml，仅保留注释
sudo cp /dev/null /etc/tomcat7/tomcat-users.xml
echo "<!-- Empty tomcat-users.xml for security -->" | sudo tee -a /etc/tomcat7/tomcat-users.xml

# 3. 重启服务使配置生效
sudo systemctl restart tomcat7

提示：如果业务确实需要远程管理（如 CI/CD 自动部署），应采用 SSH 隧道 + 本地访问方式，而非开放 manager 界面。例如 ssh -L 8081:localhost:8080 user@server ，然后浏览器访问 http://localhost:8081/manager/html 。

4.2 限制 HTTP 头信息泄露：如何让 Server 头不暴露 Tomcat 版本

默认情况下，Tomcat 7 的 HTTP 响应头包含 Server: Apache-Coyote/1.1 ，这直接暴露了容器类型和版本，为攻击者提供精准打击依据。OWASP ASVS 3.2.1 要求“禁止在响应头中泄露服务器技术栈信息”。

加固操作 ： 编辑 /etc/tomcat7/server.xml ，找到 <Connector> 标签，在其属性中添加 server=" " （空格）：

<Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443"
           server=" " />

重启服务后， curl -I http://localhost:8080 的响应头中 Server 字段将变为 Server: （空值），彻底隐藏技术指纹。

4.3 配置安全的 Session Cookie：防止会话劫持的三个关键参数

Tomcat 7 的默认 session Cookie 缺少安全标识，易被中间人窃取。等保 2.0 要求“会话 Cookie 必须设置 HttpOnly 和 Secure 属性”。

加固操作 ： 编辑 /etc/tomcat7/web.xml ，找到 <session-config> 部分，添加以下子元素：

<session-config>
  <session-timeout>30</session-timeout>
  <cookie-config>
    <http-only>true</http-only>
    <secure>true</secure>
  </cookie-config>
  <tracking-mode>COOKIE</tracking-mode>
</session-config>

• http-only=true ：禁止 JavaScript 访问 Cookie，防御 XSS 攻击窃取 session ID；
• secure=true ：强制 Cookie 仅通过 HTTPS 传输，防止明文 HTTP 下泄露；
• session-timeout=30 ：将默认 60 分钟会话超时缩短为 30 分钟，降低会话固定风险。

注意： secure=true 要求你的 Tomcat 必须配置 HTTPS（SSL Connector）。若暂未配置，此项可暂缓，但 http-only=true 必须开启。

4.4 日志格式强化：记录客户端真实 IP 而非代理 IP

在 Nginx/Traefik 等反向代理后部署 Tomcat 时， %h （remote host）日志变量记录的是代理服务器 IP（如 127.0.0.1 ），而非真实用户 IP，导致安全审计失效。等保要求“日志必须记录发起请求的真实源地址”。

加固操作 ： 编辑 /etc/tomcat7/server.xml ，找到 <Valve> 日志阀（通常在 <Host> 标签下），修改其 pattern 属性：

<Valve className="org.apache.catalina.valves.AccessLogValve" 
       directory="logs" 
       prefix="localhost_access_log." 
       suffix=".txt"
       pattern="%{X-Forwarded-For}i %l %u %t &quot;%r&quot; %s %b &quot;%{Referer}i&quot; &quot;%{User-Agent}i&quot;" 
       resolveHosts="false"/>

关键点是 %{X-Forwarded-For}i ，它读取 HTTP 请求头中的 X-Forwarded-For 字段（由前端代理设置）。同时，确保你的 Nginx 配置中有：

location / {
    proxy_pass http://tomcat_backend;
    proxy_set_header X-Forwarded-For $remote_addr;
}

这样，Tomcat 日志中每行开头就是真实用户 IP。

4.5 JVM 启动参数加固：防止堆溢出与内存泄漏的黄金组合

Tomcat 7 的默认 JVM 参数极简，未设置堆内存上限，易被恶意请求耗尽内存（如超大 XML 解析引发 XXE）。等保要求“应用服务必须配置合理的 JVM 内存参数”。

加固操作 ： 编辑 /usr/libexec/tomcat7/tomcat7.conf （Yum 包的全局配置文件），在末尾添加：

# JVM 内存参数（根据服务器内存调整）
JAVA_OPTS="-Xms512m -Xmx1024m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m"
# 安全参数：禁用 JMX 远程管理（默认开启，高危）
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote=false"
# GC 日志（便于性能分析）
JAVA_OPTS="$JAVA_OPTS -Xloggc:/var/log/tomcat7/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps"

• -Xms512m -Xmx1024m ：初始堆 512MB，最大堆 1024MB，避免动态扩容抖动；
• -XX:MetaspaceSize=256m ：JDK 7 的永久代（PermGen）已移除，Metaspace 是其替代，设上限防内存泄漏；
• -Dcom.sun.management.jmxremote=false ：关闭 JMX 远程管理端口（默认 1099），该端口若暴露，可被利用执行任意代码。

重启服务后，验证参数是否生效：

ps aux | grep tomcat7 | grep -o "Xmx[0-9a-zA-Z]*"
# 应输出 Xmx1024m

5. 故障排查实战：从 systemctl status 看不懂的报错到根因定位

在 CentOS 7 上部署 Tomcat 7，最常见的“假成功”现象是 systemctl status tomcat7 显示 active (running) ，但 curl http://localhost:8080 超时。这种问题往往不是配置错误，而是深层系统机制冲突。以下是我在 172 台服务器集群中总结的四类高频故障及完整排查链路。

5.1 现象： systemctl status 显示 active，但 netstat -tuln | grep 8080 无监听

排查链路 ：

1. 确认进程是否真在运行 ：

   ps aux | grep tomcat7
   # 若无输出，说明进程已崩溃退出，但 systemd 未及时更新状态
   

2. 检查 systemd 服务日志 ：

   journalctl -u tomcat7 -n 50 --no-pager
   # 重点关注 "Failed to start" 或 "exited with code" 行
   

3. 查看 Tomcat 自身日志 ：

   tail -50 /var/log/tomcat7/catalina.out
   # 最常见错误：`SEVERE: Failed to initialize end point associated with ProtocolHandler ["http-bio-8080"]`
   # 根因：端口被占或 SELinux 拒绝绑定
   

4. 验证 SELinux 拒绝日志 ：

   sudo ausearch -m avc -ts recent | grep tomcat
   # 若输出类似 `avc: denied { name_bind } for ... scontext=system_u:system_r:tomcat_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket`，证明 SELinux 阻止了端口绑定
   # 修复：sudo setsebool -P tomcat_can_network_connect on
   

5.2 现象： curl http://localhost:8080 返回 404，但 ls /var/lib/tomcat7/webapps/ 有 ROOT 目录

排查链路 ：

1. 检查 ROOT 应用是否被正确部署 ：

   ls -l /var/lib/tomcat7/webapps/ROOT/
   # 应有 index.jsp、WEB-INF/ 等标准文件。若为空，说明部署失败
   

2. 查看部署日志 ：

   tail -20 /var/log/tomcat7/catalina.out | grep "Deploying"
   # 若有 `Deploying web application directory [/var/lib/tomcat7/webapps/ROOT]` 但无后续 `Deployment of web application` 成功日志，说明部署过程异常中断
   

3. 检查磁盘空间与 inodes ：

   df -h /var
   df -i /var
   # Tomcat 部署时需在 `/var/lib/tomcat7/work/` 创建临时文件，若 `/var` 分区满（100%）或 inodes 耗尽，部署会静默失败
   

4. 验证 Tomcat 用户权限 ：

   sudo -u tomcat ls -l /var/lib/tomcat7/webapps/ROOT/
   # 若报 `Permission denied`，说明 `/var/lib/tomcat7/webapps/` 目录权限错误（应为 tomcat:tomcat，755）
   sudo chown -R tomcat:tomcat /var/lib/tomcat7/webapps/
   

5.3 现象： curl http://localhost:8080 返回 500， catalina.out 报 java.lang.OutOfMemoryError: PermGen space

排查链路 ：

1. 确认 JDK 版本 ：

   java -version
   # 必须是 1.7.0_XXX，若为 1.8.0，则 `PermGen` 错误是必然的（JDK 8 用 Metaspace 替代）
   

2. 检查 JVM 参数是否生效 ：

   ps aux | grep tomcat7 | grep -o "XX:PermSize=[0-9a-zA-Z]*"
   # 若无输出，说明 `tomcat7.conf` 中的 `JAVA_OPTS` 未被读取
   # 验证：`sudo -u tomcat /usr/libexec/tomcat7/tomcat7-functions` 应输出 JAVA_OPTS 值
   

3. 添加 PermGen 参数 （JDK 7 专属）： 编辑 /usr/libexec/tomcat7/tomcat7.conf ，追加：

   JAVA_OPTS="$JAVA_OPTS -XX:PermSize=256m -XX:MaxPermSize=512m"
   

   注意：此参数在 JDK 8+ 中无效，会报 Unrecognized VM option 。

5.4 现象： systemctl start tomcat7 报 Job for tomcat7.service failed ， journalctl 显示 Failed to parse PID file

排查链路 ：

1. 检查 PID 文件路径 ：

   systemctl cat tomcat7.service | grep PIDFile
   # 默认为 `/var/run/tomcat7/tomcat7.pid`
   ls -l /var/run/tomcat7/
   # 若目录不存在，或 `tomcat7.pid` 为空，说明启动脚本未正确写入 PID
   

2. 验证 /var/run 是否为 tmpfs ：

   mount | grep /var/run
   # 应为 `tmpfs on /var/run type tmpfs (rw,nosuid,nodev,mode=0755)`
   # 若不是，`/var/run` 可能是普通磁盘分区，`systemd-tmpfiles` 未创建目录
   

3. 手动创建并授权 ：

   sudo mkdir -p /var/run/tomcat7
   sudo chown tomcat:tomcat /var/run/tomcat7
   sudo chmod 0755 /var/run/tomcat7
   # 确保 systemd-tmpfiles 服务启用
   sudo systemctl enable systemd-tmpfiles-setup.service
   

这套排查链路的核心思想是： 永远不要相信 systemctl status 的表面状态，必须逐层向下验证进程、端口、日志、权限、内核机制 。每个环节都有其独立的故障域，只有按顺序排除，才能快速定位根因。我在某次省级政务云升级中，就靠这套方法在 12 分钟内定位到是 systemd-tmpfiles 服务被意外禁用，导致所有 Java 服务 PID 目录缺失，避免了数小时的业务中断。

6. 从 CentOS 7 Tomcat 7 到现代运维：一个被遗忘却至关重要的技能树

写到这里，你可能觉得“都 EOL 了还学这个有啥用”？但我想分享一个真实的场景：去年底，某大型央企启动“老旧系统云迁移三年计划”，首批 47 套系统中，有 31 套运行在 CentOS 7 + Tomcat 7 + JDK 7 栈上。他们的迁移策略不是“重写”，而是“封装”——用 Docker 将整个运行环境打包为镜像，再迁移到 Kubernetes。而 docker build 的 Dockerfile 第一行，就是 FROM centos:7 ，第二行 RUN yum install -y tomcat7 java-1.7.0-openjdk 。这时，你对 Yum 源、EPEL、RPM 依赖、systemd 服务封装的理解，直接决定了镜像能否构建成功、能否通过安全扫描、能否在 K8s 中稳定运行。

更深层的价值在于， Tomcat 7 的 Yum 安装模式，是理解现代 Linux 发行版包管理哲学的“活化石” 。它展示了 Red Hat 如何将上游开源项目（Apache Tomcat）转化为符合企业治理要求的“产品化组件”：通过 RPM 的 pre-install/post-install 脚本实现