RHCSA培训班的最后两周老师布置了结课实验在一台全新安装的RHEL系统上不依赖任何课程笔记独立完成从用户权限配置、存储扩容、服务部署到远程验收的全流程交付。当时机房里的气氛一下紧张起来了因为这不只是一次结课作业更是对RHCSA考试场景的全真模拟。我前前后后把这个实验完整做了两遍第一遍能做到“会”第二遍才勉强做到“快”。这篇博文就把我当时的实验设计思路、模块拆解、完整操作过程和踩坑记录都整理出来正在备考RHCSA或者学完Linux基础想找一套综合练手方案的朋友可以直接照着这个思路搭。1. 结课实验整体设计与思路拆解1.1 为什么结课实验要按“交付系统”来设计RHCSA考试本身就全程在命令行环境里进行不考理论题考的就是你面对一台陌生服务器时能不能在限定时间内完成指定配置。如果平时学习和联系的方式是照着讲义一节一节敲命令你记住的是“单点操作”一旦遇到把用户、存储、服务、防火墙、SELinux全部搅在一起的综合场景就很容易卡壳。结课实验的价值正在于此把过去一学期学的内容像拼图一样拼起来最后交付一套“能开机、能访问、能验收”的完整系统。我设计的实验需求描述其实很简单从零搭建一台业务服务器要求满足三块核心内容——用户按角色分权、存储可动态扩展、业务服务能通过远程客户端稳定访问同时所有配置重启后依然有效。这个设计有一个关键的思考题目里的每一个小项都对应着RHCSA考试中的高频考核点。但把它们合在一起后考察的不再是单独命令而是组件之间的配合。比如服务起不来原因可能不是服务配置文件写错了而是SELinux上下文没改、防火墙没放行、目录权限不对甚至是因为时间没同步导致证书校验失败。这种综合性正是真实运维环境的日常也是考试里最容易扣分的地方。1.2 实验环境的拓扑与硬件规划做实验之前我先把虚拟机环境搭好。拓扑保持简单但足够模拟真实场景两台RHEL 9虚拟机一台当业务服务器一台当管理客户端所有验证都从客户端反向发起避免“自己配完自己验证”造成死角。主机名角色IP地址核心用途srv-01业务服务器192.168.10.10/24用户管理、LVM存储、Nginx服务、SELinux、计划任务cli-01管理客户端192.168.10.20/24SSH远程登录、NFS挂载验证、HTTP访问验证存储规划我有意识地分成了两部分。系统盘用固定分区方式/boot分区1G、/分区20G、swap分区按4G分配。另外再单独挂一块30G的空白磁盘专门用来做LVM实验避免在生产配置里又扩根目录又扩数据目录混在一起增加排错难度。软件包选型上我选择了最小化安装加随后按需补充的路线这样做更贴近RHCSA考试习惯因为考试环境给的就是一个很精简的系统。1.3 考核点覆盖与分值权重在动手之前我画了一张考核点覆盖表作为实验进度的“地图”。因为我太清楚自己的薄弱项在哪SELinux和防火墙经常联动出问题所以我给这两个模块额外多留了时间。知识模块实验覆盖内容我预估的考试权重远程管理SSH密钥登录、禁止root直接登录15%用户与权限用户组创建、附属组、sudo授权、ACL20%存储管理LVM创建、扩容、fstab持久挂载20%服务管理systemd自定义服务、自启动15%网络与安全静态IP、firewalld放行、SELinux上下文与布尔值15%自动化与日志crontab定时任务、journalctl日志定位15%这个表格的核心用途不是背下来而是用来控制实验节奏。我会在每个模块完成后检查一次发现哪个模块耗时超过预期立刻调整后续安排。实际做的时候用户权限和存储模块是最容易拿分也最容易马虎的而SELinux则是最容易让人“卡住半小时找不到原因”的地方。2. 五个核心实验模块拆解2.1 用户与权限管理最容易被扣分的部分用户权限这个模块看起来简单但恰恰是整场实验里错误率最高的。老师设置的需求是创建三个业务用户分别属于不同的管理组让他们能共享访问一个目录并且其中一个人需要获得特定的sudo权限。操作上我会分成四步走。第一步用groupadd创建两个组一个叫ops一个叫dev第二步用useradd创建用户并指定附属组。这里有个非常容易踩的坑-g是指定主组-G是追加附属组两者完全不同。如果用户需要同时属于多个组必须用-G。groupadd ops groupadd dev useradd -G ops alice useradd -G dev bob useradd -G ops,dev carol第三步是设置密码策略和sudo规则。用chage可以设置密码最长使用天数比如要求30天后强制改密。sudo授权我用/etc/sudoers.d/目录下的独立文件来做而不是直接改/etc/sudoers主文件这样更干净也不容易写崩。visudo -f /etc/sudoers.d/ops-admin # 在文件里写入 # %ops ALL(ALL) NOPASSWD: ALL第四步是目录共享。我创建一个/srv/share目录设置好用户组归属并且给目录加上setgid位让新建文件自动继承目录的组归属。后面发现如果只设置属组权限而不管umask用户新建文件默认权限会很乱所以直接加ACL更省心setfacl -m g:ops:rwx /srv/share setfacl -m g:dev:r-x /srv/share这里我最想提醒一句用户目录的默认权限也很重要。如果用户主目录权限是755同台机器上的其他普通用户就能进你的家目录翻文件这在考试场景里属于“权限配置不当”。检查时一定留意ls -ld /home/用户名的输出。2.2 存储管理LVM动态扩容必考流程存储管理是RHCSA考试里最“套路化”也最好拿分的一块前提是流程熟练。我的实验需求是把一块新磁盘做成LVM逻辑卷挂载到/mnt/app目录然后模拟业务增长把逻辑卷从5G扩展到8G。第一步先看盘符。lsblk能看到系统里新增的30G磁盘假设是/dev/sdb。接下来把整块磁盘初始化为物理卷pvcreate /dev/sdb vgcreate vgdata /dev/sdb lvcreate -L 5G -n lvapp vgdata创建逻辑卷后格式化并挂载这些都不难。难的是把“扩容”这件事做到干净利落。RHCSA 9的默认文件系统是xfs而xfs文件系统有一个特性只能扩容不能缩容。所以一旦按缩容方向操作基本就是从头再来。扩容的标准流程是先用lvextend扩展逻辑卷再用xfs_growfs扩展文件系统。注意xfs扩展文件系统要写挂载点而不是写设备路径lvextend -L 8G /dev/vgdata/lvapp xfs_growfs /mnt/app持久化挂载也必须做对。我见过太多人在/etc/fstab里直接写/dev/vgdata/lvapp这个写法在重启后大概率出问题。正确做法是用blkid查到UUID然后以UUID形式写入fstab。同时要加上挂载参数比如defaults最后用mount -a先验证一遍确认无误后再重启验证。2.3 systemd与SELinux服务启停背后的两个坑结课实验里的服务部署模块我选择部署一个简单的Web服务来模拟业务进程。部署Web服务本身很常规安装Nginx、启动、设开机自启、放行防火墙端口。但这个模块真正的难点不在Nginx本身而在SELinux和systemd之间的联动。我先写一个模拟业务进程的脚本比如/usr/local/bin/app.sh脚本里记录每次启动时间到日志文件。然后创建一个systemd服务单元/etc/systemd/system/app.service[Unit] DescriptionDemo Application Service Afternetwork.target [Service] Typesimple ExecStart/usr/local/bin/app.sh Restarton-failure [Install] WantedBymulti-user.target这里有两个细节要讲清楚。Typesimple表示ExecStart启动的进程就是服务主进程systemd会认为服务一直运行。如果脚本是个一次性命令跑完就退出systemd会立刻判定服务失败并尝试重启。另外unit文件创建后必须执行systemctl daemon-reload否则systemd加载的还是旧配置。服务能启动了紧接着SELinux就会出来“执法”。默认情况下自定义脚本放在/usr/local/bin/下相关上下文可能是usr_t如果这个脚本要监听网络端口SELinux的布尔值就可能拦截。我的解决办法是setsebool -P httpd_can_network_connect 1 getsebool -a | grep httpd_can_network_connect如果是文件访问被拒先看ls -Z确认文件的SELinux上下文再用restorecon恢复上下文。很多人容易忘记仁这一步手动拷贝文件或创建新目录后上下文不对但没有主动执行restorecon导致服务明明配置正确却怎么都起不来。2.4 网络配置与防火墙联动网络模块我要求自己不再依赖图形界面全部用nmcli完成。给服务器配置固定的静态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配置完网络后检查ip addr和路由表确认本机没问题再从cli-01上用ping和ssh反向验证。这一步会暴露一个很常见的问题服务器本地能访问客户端访问不了就是防火墙没放行。firewalld的操作逻辑要熟练用--permanent参数让规则持久化然后必须--reload让配置生效。容易犯的错是只加了临时规则没加永久规则重启之后放行失效。firewall-cmd --permanent --add-servicehttp firewall-cmd --permanent --add-port8080/tcp firewall-cmd --reload firewall-cmd --list-all如果端口比较多建议用服务名而不是裸端口。比如--add-servicehttp比--add-port80/tcp更语义化而且当端口变化时比如配置了8080端口的Web服务服务名规则可能不匹配反而裸端口更准确。2.5 计划任务与系统日志计划任务模块看起来简单但有一个“边界情况”经常让人翻车cron和at任务默认不会把输出写到标准输出也没有错误反馈。如果不主动配置日志测试时感觉任务“好像执行了”实际可能根本没跑。我在实验里添加了两个计划任务需求每天凌晨2点自动清理/tmp下的临时文件每分钟往日志文件里追加一条当前时间记录用于验证crontab确实生效。用crontab -e编辑当前用户的任务然后通过查看日志文件确认执行效果。系统日志这一块重点是会用journalctl定位问题。拿到一台陌生机器第一步就是查服务状态和日志systemctl status sshd journalctl -u app.service -n 50 journalctl -u app.service --since today如果想再深入一点可以配置rsyslog把特定服务的日志单独写到独立文件。比如在/etc/rsyslog.d/app.conf里写一行规则把所有local0.*级别的日志重定向到/var/log/app.log然后重启rsyslog服务。这在考试里不算超纲但对理解Linux日志体系帮助很大。3. 完整实操过程与关键命令实录3.1 系统初始化从裸机到可用系统拿到新虚拟机后我第一步不是急着配服务而是先把系统基础状态摸一遍。顺序很重要先确认主机名和网络再同步时间然后更新软件包最后建立自己的管理账号。hostnamectl set-hostname srv-01 nmcli connection modify ens160 ipv4.addresses 192.168.10.10/24 ipv4.gateway 192.168.10.1 ipv4.method manual systemctl restart NetworkManager timedatectl set-timezone Asia/Shanghai systemctl enable --now chronyd chronyc sources -v dnf update -y这一步的真实目的是把底层环境变成可预期状态。比如时间不同步会导致日志时间线混乱后面排查问题时非常痛苦系统软件包不更新有些服务装的时候可能依赖不满足。还有一个容易被忽视的点建议在初始化时就创建好自己的管理用户并加入wheel组这样后面所有操作都用普通用户身份去执行需要提权时再用sudo这个习惯和RHCSA考试里“禁止root直接登录”的要求是一致的。3.2 核心配置的全流程操作记录我按照用户权限、存储、服务、网络、计划任务五个模块依次执行。以用户配置为例完整流程是先创建组和用户再准备共享目录再设置sudo规则和密码策略最后用客户端验证是否能用密钥登录。SSH密钥登录是我在实验中优先完成的一项因为后续所有远程验证都依赖它。在cli-01上生成密钥对然后把公钥分发到服务器ssh-keygen -t ed25519 ssh-copy-id alicesrv-01服务端还需要加固修改/etc/ssh/sshd_config把PermitRootLogin改为no然后systemctl restart sshd。这里我必须强调改配置文件之前一定要备份原始文件并且用sshd -t先做语法检查再重启服务否则一个文件写错SSH服务直接起不来你就只能在虚拟机的控制台界面上可怜巴巴地修复。LVM模块的全流程我在第二节已经写过命令这里补充一个非常重要的细节做完扩容后要养成“解除挂载再查文件系统”的验证习惯。在考试里你可能没有机会重启机器验证fstab用mount -a配合reboot前检查是替代方案。具体到操作顺序我会先在逻辑卷挂载状态下运行df -hT查看容量然后扩容再df -hT查看容量变化。这个验证动作必须在当场完成不能等到最后再统一验证。3.3 写一个一键验证脚本做完所有配置后我写了一个简单的验证脚本用来快速判断环境是否处于健康状态。这个动作不是为了炫技而是在考试现场给自己留“退路”如果时间不够逐项检查脚本能帮你迅速定位哪一块出了问题。#!/bin/bash echo 服务状态检查 systemctl is-active sshd echo sshd: OK || echo sshd: 异常 systemctl is-active nginx echo nginx: OK || echo nginx: 异常 echo 用户检查 for user in alice bob carol; do id $user /dev/null echo $user: OK || echo $user: 缺失 done echo 存储挂载检查 mountpoint -q /mnt/app echo /mnt/app: 已挂载 || echo /mnt/app: 未挂载 df -hT /mnt/app | tail -1 echo 防火墙检查 firewall-cmd --list-all echo 网络连通性检查 ping -c 2 -W 1 192.168.10.20 /dev/null echo 到cli-01: 通 || echo 到cli-01: 不通脚本本身不复杂但逻辑上覆盖了服务、用户、存储、网络四个核心维度。我在执行后马上发现了一个问题Nginx服务状态显示正常但从客户端访问却超时原因是防火墙里只放行了80端口而我的Nginx监听在8080端口。这就是验证脚本帮你发现问题的典型场景。4. 常见问题与排查技巧实录4.1 五个高频报错的排查思路在实验过程中我整理了一份“高频报错对照表”这些问题在RHCSA考试里出现频率也相当高。与其背单个命令不如把“报错-原因-排错序列”整理成肌肉记忆。报错现象根本原因排查位置与修复方式Permission denied (publickey)SSH密钥文件权限错误或SELinux上下文异常检查~/.ssh目录权限700、authorized_keys权限600执行restorecon -Rv ~/.sshJob for app.service failedunit文件中ExecStart路径写错或脚本没有执行权限先systemctl cat app.service查看实际配置再chmod x脚本daemon-reloadxfs扩容命令报“is not a mounted XFS filesystem”写成了设备路径而不是挂载点对xfs文件系统xfs_growfs后面接挂载点不要接/dev/路径服务能从本机访问客户端无法访问防火墙或SELinux放行不到位按顺序查firewall-cmd --list-all、ss -tlnp、getenforce与ls -Z重启后挂载消失fstab未配置或格式错误用blkid查UUID以UUID形式写入/etc/fstab执行mount -a验证这套排查思路里最核心的一条是修改配置后一定要从客户端反向验证。本机环回地址访问成功不代表外部主机能访问本机启动服务成功也不代表重启之后还能起来。每次改完配置都问自己三个问题现在通吗重启后通吗别人能访问吗这三个问题能堵住大部分考试扣分点。4.2 考试节奏与习惯养成做结课实验最大的收获不是会了某个命令而是养成了按节奏推进的习惯。RHCSA考试时间紧张每道题平均下来只有几分钟所以平时练习时就要建立“分块验收”的节奏感。我的节奏是每完成一个小任务立即做一次验证并且用echo $?确认命令执行成功。比如完成用户创建后马上id alice echo success完成挂载后马上df -hT确认容量。这个即时反馈的小习惯能避免最后一刻才发现一堆错误却不知道从哪查起。另一个值得养成的习惯是改任何系统关键文件之前先备份。比如修改/etc/ssh/sshd_config前先cp一份改fstab前同样备份。这个习惯在考试现场能救命。很多考生因为改错了/etc/sudoers导致所有sudo命令失效如果没有备份只能进紧急模式修复时间成本极高。4.3 最容易忽略的细节清单实验过程中我总结了一些容易忽略的细节单独列出来供参考密码策略不是创建用户就结束useradd之后必须用passwd设置密码课程要求启用密码老化就用chage配置。fstab要写UUID而不是设备名特别是虚拟机环境下设备名顺序可能变化UUID才稳定。systemd unit文件修改后必须daemon-reload否则一切改动看起来都没生效。SELinux上下文不是一路“chmod”就能解决的文件权限对但SELinux类型不对服务照样读不了文件。cron任务的输出要重定向到日志文件否则出错你看不到任何反馈。时间同步要放在最前面做日志时间错乱会严重干扰排错。这些细节单独看都很小但在综合实验里它们常常同时出现导致“按下葫芦浮起瓢”。我把它们写在这是希望准备考试或做实验的你在交付前专门花五分钟核对一遍。5. 从结课实验里带走的东西做完这个实验后我有一种很强烈的感觉RHCSA考的不是“你会多少条命令”而是“你在一台未知机器上面对复杂需求时的组织能力”。命令只是最小单元把命令组织成可交付、可验证、重启不失效的系统才是核心。如果你想把这个实验再往上扩展一步可以在现有环境基础上继续加需求给服务配置负载均衡、设计自动备份策略、用容器方式打包业务应用或者把整套验证脚本固化成一个巡检工具。这些方向都是RHCSA知识的自然延伸也是日常运维工作的真实内容。最后分享一个小技巧在整个实验过程中我用script命令记录了完整会话script -a session.log可以把终端输入输出全部保存成文件。做完实验后翻一遍这段日志你会比自己想象中更容易发现重复犯的错。这个习惯我一直保留到现在每次处理完一个复杂故障回看日志复盘都会有意想不到的收获。