在写RHEL9.7这份作业的时候我其实没想过会在虚拟机上折腾这么久。作为系统管理课程里比较完整的综合实验它要求的不只是把服务装起来而是要把一套从系统初始化、软件部署到安全策略完整的链路走通。我把整个完成过程整理成了这篇记录既是一份作业复盘也希望能给正在做同类RHEL9.7综合实验的同学一些可以直接抄作业的思路。这篇内容主要讲清楚三件事这套实验项目的整体架构是怎么拆解的、每一步核心服务部署的实操过程、以及我在排错阶段踩过的坑和解决方法。无论你是刚开始接触RHEL9.7的新手还是已经有一定Linux基础、想看看别人怎么设计实验环境的都可以在这篇记录里找到对应的参考价值。1. 作业需求与整体设计思路1.1 实验题面到底想考什么RHEL9.7作为Red Hat Enterprise Linux的最新小版本它的实验作业考察点其实非常明确验证一个人是否具备在企业级Linux环境下独立完成服务部署、网络配置和系统安全管理的能力。题面虽然只要“浅浅完成一下”但如果只是在虚拟机里把系统装上、再用yum装个HTTP服务那显然达不到这门课的深度要求。我拿到作业之后先做了需求拆解。题面虽然没有给出特别细的拓扑图但从课程大纲和评分标准可以反推出来实验至少需要覆盖以下模块系统安装后的初始化配置包括主机名、网络、时区、SELinux和防火墙策略软件仓库的合理配置能够正常使用dnf安装和更新软件包一个完整的Web服务链路数据库、后端处理、前端页面三层都要打通服务之间能够正常通信同时安全策略不能挡掉业务流量关键服务在重启后依然能够自动拉起符合企业运维的基本要求把这些模块整合在一起其实就是一个小型的企业Web架构前端一台RHEL9.7服务器跑Apache HTTPD后端用MariaDB存储数据PHP作为中间处理层。这个架构虽然不算复杂但麻雀虽小五脏俱全非常适合用来做课程作业也非常适合检验一个运维工程师的基本功。1.2 为什么选RHEL9.7作为实验平台最近几年Linux发行版更新迭代很快Ubuntu、Debian、openEuler各有拥趸但RHEL系列在企业生产环境中的地位依然非常稳固。RHEL9.7作为Red Hat 9系列的最新更新版本除了继承了RHEL9原本就有的dnf软件包管理、SELinux安全增强、firewalld动态防火墙这些特性外还更新了部分内核补丁和软件包版本在稳定性方面保持了Red Hat一贯的保守策略。选择RHEL9.7做实验核心原因有三个。一是与生产环境的契合度。很多企业的线上服务器用的就是RHEL或者它的衍生品比如Rocky Linux、AlmaLinux在RHEL9.7上把实验跑通意味着你学到的命令、配置文件写法、SELinux策略调整方式到了公司之后还有很高的复用价值。二是安全机制的完整性。与Ubuntu这类发行版相比RHEL9.7默认开启SELinux强制模式这对初学者来说可能会觉得有些别扭但恰恰是这种“别扭”逼着你把安全上下文、布尔值这些概念吃透。一个在RHEL9.7上能正常跑起来的Web服务一定是真正理解了系统安全机制之后的结果。三是RHEL9.7本身的特性更新。比如它默认使用OSRelease而不是老旧的redhat-release系统角色的编排能力也比之前版本更强虽然实验用不到那么复杂的功能但这些变化说明这个版本不是简单的补丁升级而是有实质性的演进。1.3 实验拓扑与模块划分整个实验环境我设计成一个精简的“单机多服务”结构其实就是在同一台RHEL9.7虚拟机上承载全部角色。虽然是单机但逻辑分层必须清晰否则后面排查问题会很痛苦。划分下来的层次结构是最下面是系统层负责操作系统本身的稳定运行包括内核参数、文件系统、SELinux状态往上是网络层配置静态IP并设置好firewalld规则再往上是数据层运行MariaDB并提供数据库服务最上层是应用展示层Apache加PHP负责处理HTTP请求动态读取数据库内容并生成页面。这样划分的最大好处是一旦业务访问出现问题我可以按照“应用层 - 网络层 - 系统层”的顺序逐层排查而不会像无头苍蝇一样乱试。实际调试过程中大多数问题确实都出在层与层的交界处比如防火墙没放行数据库端口、SELinux上下文不对、PHP和数据库通信被策略阻断这些都是典型的分层问题。2. 系统初始化与基础环境准备2.1 虚拟机创建与安装源配置系统初始化从创建虚拟机开始。我使用的虚拟化平台是VMware Workstation分配给实验机的资源配置为4核CPU、8GB内存、80GB硬盘。这个配置面对课程作业来说非常充足也预留了后续做快照和扩展实验的余地。安装RHEL9.7的时候有两点需要注意。第一是安装源的选择由于没有Red Hat订阅账号我选择了ISO镜像本地安装的方式在安装引导界面指定了镜像文件位置这样系统会从本地ISO完成整个安装过程不依赖网络。第二是软件包选择我选择了“带GUI的服务器”这个预设方案虽然平时操作完全用命令行但保留GUI可以在万一面板配置出错时作为兜底而且图形化的浏览器调试也方便。安装完成进入系统后第一件事不是急着配服务而是先做系统基线配置。我喜欢用命令行而非图形工具来完成这些操作因为命令行写下来的每一条命令都可以形成文档方便复用和复盘。以下是初始化网络配置的核心步骤# 查看当前网络接口名称 nmcli device status # 修改网卡配置为静态IP nmcli connection modify ens160 ipv4.addresses 192.168.10.10/24 nmcli connection modify ens160 ipv4.gateway 192.168.10.1 nmcli connection modify ens160 ipv4.dns 192.168.10.1 nmcli connection modify ens160 ipv4.method manual # 生效配置 nmcli connection up ens160 # 设置主机名和时区 hostnamectl set-hostname web-server timedatectl set-timezone Asia/Shanghai注意RHEL9.7中NetworkManager仍然是网络管理的核心修改网络配置务必通过nmcli操作直接编辑/etc/sysconfig/network-scripts/ifcfg-eth0目录下的脚本方式在这个版本已经过时系统默认也不会读取传统网络脚本。时区设置被很多人忽略但这个细节其实挺重要。如果你在日志里看时间戳发现和实际时间差了8个小时排查线上问题时很容易产生误导。我在实验环境中第一时间就把时区设成了Asia/Shanghai并且与NTP时间源做了同步保证后续所有服务日志时间的一致性。2.2 软件仓库与系统更新RHEL9.7安装完成后默认的软件仓库指向Red Hat官方订阅源没有订阅的情况下dnf是无法使用的。为了解决这个问题同时又不影响对企业级系统的理解我选择将仓库源替换为Rocky Linux 9的镜像源。Rocky Linux作为RHEL的1:1兼容替代品其软件包与RHEL9.7保持高度兼容非常适合学习场景。配置仓库源的操作要点# 在 /etc/yum.repos.d/ 目录下新建仓库文件 vim /etc/yum.repos.d/rocky.repo # 仓库文件核心内容 [baseos] nameRocky Linux $releasever - BaseOS baseurlhttps://mirrors.aliyun.com/rockylinux/9/BaseOS/x86_64/os/ gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9 [appstream] nameRocky Linux $releasever - AppStream baseurlhttps://mirrors.aliyun.com/rockylinux/9/AppStream/x86_64/os/ gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-9 # 清理缓存并生成新的仓库信息 dnf clean all dnf makecache替换完成以后dnf install就能正常工作了。这一步做完记得运行一次完整的系统更新把内核和核心软件包升级到当前仓库的最新版本可以避免后续安装服务时遇到依赖版本过旧的问题。整个更新过程大约需要几分钟视网络情况而定更新完成后建议重启一次系统让新内核生效。2.3 防火墙与SELinux的前置策略RHEL9.7默认的防火墙是firewalld默认安全策略是只放行SSH服务其他端口全部拒绝。SELinux则处于Enforcing强制模式对所有进程执行严格的安全策略限制。前置策略我先做了两个约定。第一在实验环境里放行HTTP服务端口80和443并保留SSH端口第二SELinux暂时保持在Enforcing状态不允许为了图省事直接关闭它。这样设计的好处是所有服务的部署和验证过程都是在真实的安全约束下完成的后面不会因为环境过于宽松而在生产服务器上踩坑。防火墙的配置操作# 启动防火墙并设置开机自启 systemctl enable --now firewalld # 放行HTTP和HTTPS服务 firewall-cmd --permanent --add-servicehttp firewall-cmd --permanent --add-servicehttps # 重载防火墙配置 firewall-cmd --reload # 查看当前配置 firewall-cmd --list-allSELinux这边虽然暂时不需要马上修改策略但需要确认它处于Enforcing状态并且记下当前系统的布尔值设置方便后续部署Web服务时对照调整。验证命令是getenforce如果输出为Enforcing就说明安全机制已经生效。3. 核心服务部署与链路打通3.1 数据库层MariaDB的安装与配置Web架构中最底层的数据存储我选择了MariaDB而不是MySQL。原因很直接RHEL9.7的AppStream仓库默认提供的就是MariaDB一条dnf命令就能安装而且Red Hat官方也推荐在RHEL系统上使用MariaDB作为MySQL的替代品兼容性方面没有任何顾虑。安装与初始化# 安装MariaDB服务器和客户端 dnf install -y mariadb-server mariadb # 启动服务并设置开机自启 systemctl enable --now mariadb # 执行安全初始化脚本设置root密码并清理匿名账户 mysql_secure_installationmysql_secure_installation脚本是MariaDB安装后必须执行的一步。它会一步一步引导你设置root密码、删除匿名用户、禁止root远程登录、删除测试数据库。我第一次做实验的时候偷懒跳过了这步结果后面做数据库安全加固时还得回头补多花了不少时间。按提示做完至少能提前规避掉大部分低级别安全风险。随后创建业务数据库和专用账号这是为了让业务系统不直接使用root账户连接数据库符合最小权限原则CREATE DATABASE webdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER webuserlocalhost IDENTIFIED BY WebPass2025; GRANT ALL PRIVILEGES ON webdb.* TO webuserlocalhost; FLUSH PRIVILEGES; EXIT;这里考虑过数据库账号的host设置。如果Web服务和数据库在同一台机器上使用localhost是安全且高效的选择。如果后续要拆成两台机器部署就需要把host部分改成应用服务器的IP同时还要考虑数据库监听地址。我在实验里有一版是让MariaDB监听在0.0.0.0上后面发现这样做会带来额外的防火墙配置工作而且安全隐患也不小。最终权衡之后还是回归到了单机localhost部署整体链路更简洁。3.2 Web服务层Apache HTTPD的部署与虚拟主机Web服务选择Apache HTTPD同样是基于RHEL9.7仓库原生支持的原因。虽然Nginx在性能方面表现优秀但RHEL9.7的AppStream仓库同时包含httpd和nginx课程教学大纲中明确以Apache为主要实验对象我就顺着这个方向做。安装和基本配置dnf install -y httpd systemctl enable --now httpd # 确认服务状态 systemctl status httpdhttpd安装完成后默认有一个测试页面直接访问服务器IP可以看到。但我要做的是一个能展示数据库内容的动态页面所以需要修改默认的网站目录配置并创建一个虚拟主机。虚拟主机配置我直接写在/etc/httpd/conf.d/webapp.conf中Apache默认加载这个目录下所有.conf文件无需修改主配置VirtualHost *:80 ServerName www.lab.local DocumentRoot /var/www/html/webapp DirectoryIndex index.php index.html Directory /var/www/html/webapp Options -Indexes AllowOverride All Require all granted /Directory ErrorLog logs/webapp-error.log CustomLog logs/webapp-access.log combined /VirtualHost配置里的Options -Indexes值得单独说一下。如果不禁止目录索引当访问的目录没有索引文件时Apache会把目录的文件列表直接展示出来这在生产环境里是严重的信息泄露隐患。关闭目录索引是Web服务器加固的基本动作后面检查时也要重点确认。修改完配置后检查语法再重启服务# 验证配置语法是否正确 apachectl configtest # 重新加载配置 systemctl reload httpd如果看到Syntax OK的输出就可以进入到下一步了。这里如果你只是想跑通基础作业不写配置文件也行直接用系统默认的/var/www/html目录就好但虚拟主机的写法是生产环境中非常常用的技能建议理解并掌握。3.3 应用逻辑层PHP与数据库连接PHP作为连接Apache和MariaDB的桥梁需要安装PHP解释器以及连接MariaDB所需的扩展模块。RHEL9.7仓库自带的PHP版本是8.0系列对现代Web应用的支持基本够用。安装命令dnf install -y php php-mysqlnd php-fpm php-json php-gd这里php-mysqlnd扩展包名容易记错。我一开始安装时只装了php和php-fpm结果PHP脚本里调用mysqli_connect函数直接报错Fatal error: Uncaught Error: Call to undefined function mysqli_connect()排查了半天才发现就是少了php-mysqlnd这个扩展。php-mysqlnd是PHP连接MySQL/MariaDB数据库的驱动模块必须装没得商量。为了验证整条链路我写了两个测试脚本。第一个是探针脚本info.php用来确认PHP解析和扩展加载情况?php phpinfo(); ?把文件放到/var/www/html/webapp目录下浏览器访问http://192.168.10.10/webapp/info.php如果能看到PHP信息页并显示mysqli模块说明PHP解析正常且扩展已加载。第二个脚本是数据库连接测试这个验证的是PHP到数据库这一层有没有问题?php $conn new mysqli(localhost, webuser, WebPass2025, webdb); if ($conn-connect_error) { die(数据库连接失败: . $conn-connect_error); } echo 数据库连接成功; $conn-close(); ?这一步出现了“数据库连接失败”是一个很好的排查契机。我实际执行时也踩到了坑因为PHP默认以httpd用户运行而SELinux策略可能限制它连接数据库的网络套接字。后面我会专门讲SELinux的解决过程这里先记住模块安装完整、PHP配置正确、防火墙放行这三个检查点基本能覆盖90%的失败场景。3.4 页面展示与数据初始化数据库、Web服务、PHP三层都通之后我在webdb库中创建了一张访客记录表用于页面访问时实时展示数据USE webdb; CREATE TABLE visitor ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50) NOT NULL, visit_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); INSERT INTO visitor (name) VALUES (test-user-01), (test-user-02);对应的index.php页面负责从数据库读取访客列表并生成HTML表格?php $conn new mysqli(localhost, webuser, WebPass2025, webdb); if ($conn-connect_error) { die(数据库连接失败: . $conn-connect_error); } $result $conn-query(SELECT id, name, visit_time FROM visitor ORDER BY id DESC); ? !DOCTYPE html html head meta charsetUTF-8 titleRHEL9.7 Web实验页面/title /head body h1RHEL9.7 Web架构实验/h1 p当前时间: ?php echo date(Y-m-d H:i:s); ?/p table border1 cellpadding8 trthID/thth访客名称/thth访问时间/th/tr ?php while ($row $result-fetch_assoc()): ? tr td?php echo $row[id]; ?/td td?php echo $row[name]; ?/td td?php echo $row[visit_time]; ?/td /tr ?php endwhile; ? /table /body /html ?php $conn-close(); ?这个页面本身没有多复杂但它把整个RHEL9.7实验的三层架构串起来了。浏览器请求到达ApachePHP解析脚本执行数据库查询MariaDB返回数据PHP渲染成HTML回给浏览器。任何一个环节断开页面都无法正常显示这也是这个实验作业最大的价值所在。4. 安全策略适配与加固细节4.1 SELinux导致的服务异常及解决整个实验过程中让我印象最深的是SELinux引发的异常。安装完所有服务、放行防火墙之后我用浏览器访问HTTP页面发现Apache能正常启动PHP也能被解析但页面在查询数据库时一直报错。一开始我以为是数据库账号密码配置错误检查了一遍没发现问题最后看了SELinux的审计日志才找到根源。SELinux在这个场景里的核心文件是httpd_unified这个布尔值。RHEL9.7默认关闭它时Apache只能处理静态网页一旦涉及动态脚本访问网络资源或写文件受限目录就会被强制拦截。查看与解决步骤# 查看当前SELinux布尔值状态 getsebool -a | grep httpd # 查看审计日志中与httpd相关的拒绝记录 ausearch -m AVC -ts recent | grep httpd # 允许Apache执行网络连接动态页面访问数据库 setsebool -P httpd_can_network_connect_db on # 允许Apache执行CGI/PHP脚本 setsebool -P httpd_unified on-P参数让设置永久生效这样系统重启后配置仍然保留。这里要特别提醒SELinux布尔值的修改应当遵循最小权限原则只需要打开实验涉及的功能开关不要把所有相关的布尔值一律设为on否则就失去了SELinux存在的意义。有同学可能会问为什么不直接在/etc/selinux/config里把SELinux设为disabled或者permissive多省事。我的体会是如果做实验时关闭了SELinux虽然服务能跑通但你根本没有经历SELinux环境下的问题排查过程等到了生产环境或者相关认证考试时会非常被动。RHEL系列最核心的安全竞争力就是SELinux这个机制不搞懂RHEL实验的价值就打了一半折扣。4.2 firewalld防火墙的精细化调整前面提到我最初规划数据库除了本地访问外还预留了远程管理的可能性所以安装了数据库之后想要从外部连接MariaDB必须放行3306端口。虽然最后实验回归到了单机localhost架构但防火墙规则的配置思路还是值得记录一下。端口放行的常规做法# 追加3306端口到防火墙放行列表 firewall-cmd --permanent --add-port3306/tcp # 重载防火墙 firewall-cmd --reload但如果你真正这样操作了需要知道它的安全含义。3306端口暴露到外部意味着任何能连通你IP地址的人都可以尝试连接数据库如果你的数据库账号密码强度不够很容易被爆破。所以我在实验里最终使用了更严格的做法只允许特定来源IP访问3306端口直接把数据库服务限制在一个小范围内# 仅允许192.168.10.0/24网段访问3306端口 firewall-cmd --permanent --add-rich-rulerule familyipv4 source address192.168.10.0/24 port port3306 protocoltcp accept # 移除之前添加的宽泛放行规则 firewall-cmd --permanent --remove-port3306/tcp firewall-cmd --reload注意在RHEL9.7中rich-rule的顺序很重要firewalld是按照规则出现的顺序逐条匹配的。如果前面有一条拒绝所有或放行所有的规则后面的规则可能不会生效。写规则之前可以用firewall-cmd --list-all先查看下当前规则列表。4.3 系统账户与文件权限收紧服务跑通之后还有一道必修课是身份与权限安全。RHEL9.7默认的SSH服务允许root直接登录这个配置在实验环境也许图方便但作为系统管理作业来说必须改掉。SSH加固的核心操作vim /etc/ssh/sshd_config # 修改以下两行 PermitRootLogin no PasswordAuthentication yes # 修改后重启SSH服务 systemctl restart sshdPermitRootLogin设置为no是常规操作它禁止远程使用root登录强制管理员通过普通用户登录后使用sudo提权执行管理命令。这样一旦远程登录凭据泄露攻击者拿到的只是一个没有管理员权限的普通用户想进一步操作还需要破解sudo密码攻击难度成倍提升。文件权限方面网站目录/var/www/html/webapp及其上级目录需要确保Apache用户有读取和执行权限同时不允许其他用户写入。实际操作中还需要检查一下httpd用户对配置文件的读取权限还有数据库备份目录的权限设置这些都是容易被忽略的细节。执行下来系统相比裸装环境已经有了明显加固同时也保留了一条链路完整的业务服务。5. 实验过程中踩过的坑与排查思路5.1 PHP页面502 Bad Gateway在实验的某个中间版本中我尝试过使用PHP-FPM方式处理PHP请求。那时配置好Apache和PHP-FPM后访问页面一直提示502 Bad Gateway查了一圈Apache错误日志发现问题出在PHP-FPM的监听配置上。RHEL9.7中PHP-FPM默认配置监听的是特定套接字地址而Apache的PHP处理器模块需要知晓这个地址。两个服务如果socket路径对不上请求就会在反代环节断掉。解决方法是统一两边的socket配置修改/etc/php-fpm.d/www.conf中的listen参数确保它与Apache中SetHandler指令指定的socket路径一致。最后我放弃了PHP-FPM方案直接使用mod_php模块方式。在RHEL9.7仓库中Apache以模块方式加载PHP足够应对课程实验场景而且配置更简单直接也少了一个故障点。5.2 数据库连接权限制约导致的访问受限数据库连接出现Access denied也是一个经典问题。我当时创建了webuser用户并授权了webdb库的所有权限但使用密码登录后依然被拒绝提示主机不允许连接。原因是我在创建用户时写的是webuserlocalhost而PHP脚本连接时使用的host是127.0.0.1。在MySQL/MariaDB的用户管理逻辑中localhost和127.0.0.1是两个不同的主机匹配项需要分别授权。解决方案是创建用户时同时覆盖两个来源或者统一连接字符串中的主机名。我调整了连接方式后问题解决。这个小坑在单机部署中经常出现建议实战时统一使用localhost作为连接主机名同时确保数据库用户包含对应的授权记录。5.3 httpd访问日志与错误日志的利用排查问题时日志是最重要的线索来源。RHEL9.7中Apache的日志在/var/log/httpd/目录下访问日志和错误日志分开存放。错误日志记录启动失败、配置语法错误、SELinux拦截、PHP报错等关键信息访问日志则记录每次HTTP请求的状态码和响应时间。我遇到过一个奇怪现象页面能打开但样式全部缺失查了访问日志以后才发现CSS文件的请求返回了403状态码。这通常与SELinux上下文或文件权限有关。用restorecon重新恢复目录的SELinux上下文标签就能解决# 为网站目录恢复SELinux上下文 restorecon -Rv /var/www/html/webapp这个方法在调整网站目录位置后尤其重要因为新建目录默认的SELinux类型可能不是httpd_sys_content_tApache有权读取但SELinux会拦截。restorecon把上下文恢复到系统默认规则要求的类型问题立刻消失。5.4 常见问题速查表现象可能原因排查方法解决方案网页无法访问firewalld未放行80端口firewall-cmd --list-allfirewall-cmd --permanent --add-servicehttpPHP代码被显示为纯文本PHP模块未正确加载php -v 确认版本查看httpd -M输出安装php并重启httpdmysqli函数未定义php-mysqlnd未安装php -m 查看模块列表dnf install php-mysqlnd页面无法连接数据库SELinux拦截或数据库用户权限问题ausearch -m AVC查看审计日志setsebool -P httpd_can_network_connect_db on访问目录出现文件列表httpd配置未关闭目录索引检查Directory配置中的Options配置中增加 -Indexes重启后服务未自动运行服务未设置开机自启systemctl is-enabled httpdsystemctl enable --now httpd网页样式文件403新目录SELinux上下文不正确ls -Z 查看文件上下文restorecon -Rv目录路径这张表是我在完成整份作业之后整理的基本上能让后面做同类实验的人少走一大半弯路。每条记录都是实际操作中遇到并解决过的对照排查效率远高于盲试。6. 作业完成后的一点总结与思考这份RHEL9.7作业做完我最深的感受是“浅浅完成”这四个字其实是最难做到的。表面看起来只是把服务装好、把页面跑通但实际上为了达到这个结果你需要理解防火墙规则的生效顺序、SELinux的安全上下文模型、数据库用户授权的机制还要掌握通过日志反推故障原因的能力。这些知识点单独拎出来都不算难但放在一个综合实验里同时生效的时候才是真正考验系统工程思维的时刻。有一个小细节想特别提一下就是整个实验过程中最好养成快照的习惯。每次完成一个阶段性的稳定状态比如系统初始化完成、Web服务部署成功、数据库链路打通都做一个快照。这样做有两大好处一是后面实验改崩了可以快速回退不用从头再来二是不同方案之间可以来回切换对比比如PHP模块方式和PHP-FPM方式的差异有了快照就能随时切换回去研究。我在做这份作业的过程中至少建了六个快照每个都记录了当时的关键状态这让排错效率提升了很多。RHEL9.7这份实验下一步还可以继续扩展的方向也不少比如用Podman把MariaDB容器化部署、通过系统角色批量管理多台服务器的配置、配置Nginx反向代理替代直接暴露Apache等。每一个方向都能延伸出足够深的内容但基础打好了这些路走起来都不会太难。希望这篇记录能帮你少踩一些坑顺利完成自己的实验任务。