介绍
实际的系统管理任务很少只涉及单一命令。服务可能因为单元（unit）未激活、服务用户无法读取内容、SELinux 标签不完整或防火墙未开放所需端口而导致失败。
在本实验中，你将修复一个预设的 Web 服务主机。该服务应以 labex 用户身份运行，从 /srv/rhcsa-review/site 提供内容，监听 127.0.0.1:18082，设置为开机自启，拥有正确的 SELinux 标签，并通过 firewalld 开放 18082/tcp 端口。
重现并诊断服务故障
在此步骤中，你将重现服务故障并在进行更改前检查相关证据。首先使用 systemctl 和 journalctl，然后将日志信息与文件权限进行对比。
环境初始化已在 public 区域中永久保留 SSH 和使用 3002/tcp 的 LabEx 浏览器终端访问规则。更改应用程序的防火墙策略时，请保留这些管理访问规则。
进入项目目录。
cd /home/labex/project
检查预设的服务。该服务已存在，但尚未运行。
systemctl status rhcsa-review-web.service --no-pager || true
尝试启动它。由于服务以 labex 用户身份运行，但该用户无法访问内容目录，因此启动会失败。
sudo systemctl start rhcsa-review-web.service || echo "service start failed as expected"
sleep 1
查看 systemd 是否将该单元标记为失败。
systemctl is-failed rhcsa-review-web.service || true
读取最近的服务日志条目。日志应会指出服务账户无法使用配置的工作目录或内容路径。
sudo journalctl -u rhcsa-review-web.service -n 20 --no-pager
检查内容路径的权限。
sudo stat -c '%a %U:%G %n' /srv/rhcsa-review /srv/rhcsa-review/site /srv/rhcsa-review/site/index.html
修复内容权限
在此步骤中，你将使服务账户能够读取内容，同时避免将其设置为全局可读。该服务以用户 labex 和组 labex 身份运行。
将目录树的组设置为 labex。服务以 labex 组身份运行，因此通过组所有权，你可以在不更改文件所有者的情况下授予访问权限。
sudo chown root:labex /srv/rhcsa-review /srv/rhcsa-review/site /srv/rhcsa-review/site/index.html
允许该组遍历目录并读取内容文件。目录需要执行位（execute bit）才能遍历，HTML 文件需要读取位（read bit）以便服务能够提供内容。
sudo chmod 750 /srv/rhcsa-review /srv/rhcsa-review/site
sudo chmod 640 /srv/rhcsa-review/site/index.html
检查修复后的权限。
sudo stat -c '%a %U:%G %n' /srv/rhcsa-review /srv/rhcsa-review/site /srv/rhcsa-review/site/index.html
清除失败状态并再次启动服务。reset-failed 会移除旧的失败标记，使权限修复后的 systemctl 状态更易于查看。
sudo systemctl reset-failed rhcsa-review-web.service
sudo systemctl start rhcsa-review-web.service
sleep 1
确认服务已激活并正在提供内容。
systemctl is-active rhcsa-review-web.service
curl -s http://127.0.0.1:18082/
使服务持久化
在此步骤中，你将启用修复后的服务，使其在开机时自动启动。仅在当前会话有效而无法在下次开机时自动运行的服务，不能算作完全修复。
启用该单元。启动（start）修复的是当前引导过程；启用（enable）则记录了修复后的服务应在正常的引导目标（boot target）中自动启动。
sudo systemctl enable rhcsa-review-web.service
检查启用状态。
systemctl is-enabled rhcsa-review-web.service
重启服务以确认单元在权限修复后仍能正常启动。干净的重启比仅仅检查当前正在运行的进程更有说服力。
sudo systemctl restart rhcsa-review-web.service
sleep 1
再次测试服务。
systemctl is-active rhcsa-review-web.service
curl -s http://127.0.0.1:18082/
添加 SELinux 上下文与端口标签
在此步骤中，你将使 SELinux 策略元数据与服务设计相匹配。即使简单的演示服务能够读取内容，RHCSA 风格的 Web 服务修复也应包含持久化的文件上下文和端口标签。
为服务内容添加持久化的 HTTP 内容上下文规则。fcontext 规则是持久化的策略元数据；它告诉 SELinux 在重新标记（relabeling）后该路径应接收什么标签。
sudo semanage fcontext -a -t httpd_sys_content_t '/srv/rhcsa-review/site(/.*)?'
将规则应用于现有文件。restorecon 会读取持久化规则并将正确的标签应用于已存在的文件。
sudo restorecon -Rv /srv/rhcsa-review/site
检查自定义规则和生成的标签。
sudo semanage fcontext -l | grep '/srv/rhcsa-review/site'
ls -Zd /srv/rhcsa-review/site /srv/rhcsa-review/site/index.html
将服务端口添加到 HTTP 端口类型中。端口标签让 SELinux 策略能够理解 TCP 18082 是用于 HTTP 风格的服务流量。
sudo semanage port -a -t http_port_t -p tcp 18082
检查 HTTP 端口标签。
sudo semanage port -l | grep '^http_port_t'
开放防火墙并进行端到端验证
在此步骤中，你将通过 firewalld 开放服务端口并进行最终审计。服务应处于激活、已启用、已标记状态，并被主机防火墙允许。
启动并启用 firewalld。
sudo systemctl enable --now firewalld
永久添加服务端口并重新加载防火墙。永久规则在 firewalld 重新加载后依然有效，而重新加载操作会将规则应用到当前活动的防火墙中。
sudo firewall-cmd --permanent --add-port=18082/tcp
sudo firewall-cmd --reload
检查活动端口列表。
sudo firewall-cmd --list-ports
运行最终的服务检查。这些命令确认服务已设置为开机自启、当前处于激活状态，并返回预期的本地 Web 响应。
systemctl is-enabled rhcsa-review-web.service
systemctl is-active rhcsa-review-web.service
curl -s http://127.0.0.1:18082/
最后一次审计内容权限。此最终权限检查可防止常见的局部修复问题：即服务虽然能运行，但访问模型比预期的更宽泛或更狭窄。
sudo stat -c '%a %U:%G %n' /srv/rhcsa-review /srv/rhcsa-review/site /srv/rhcsa-review/site/index.html
总结
你通过诊断失败的 systemd 单元、修复服务用户权限、启用服务、添加 SELinux 文件和端口标签、开放 firewalld 以及验证最终 Web 响应，成功修复了一个存在多项故障的服务主机。
