企业官网建设流程全解析

第二次作业发下来那天，我其实挺有底气的——第一次作业已经把文件系统、用户增删、日志这些基本操作从头到尾滚了一遍，觉得自己离RHCSA认证又近了一步。可真正坐到虚拟机前面，把题目逐条跑完，才发现红帽这种纯实操型认证最折磨人的根本不是“不会”，而是“看着全会，一跑就错”。尤其是SELinux那道题，我卡了一个多小时，最后发现只是布尔值少开了一个。

这篇就把我的RHCSA第二次作业完整复盘一遍，题目长什么样、每道题怎么解的、哪些地方差点扣分，全部写出来，给同样在备考红帽认证的读者当一份参考。文章里用的都是RHEL系虚拟机环境，命令可以直接抄，但更建议你先自己想一遍再动手。

1. 作业题目全景：这次训练到底在练什么

先交代一下背景。我是在虚拟机里的RHEL 9上做的这套作业，模拟的是RHCSA考试中占比最重的基础管理部分。老师给的卷子一共五道题，难度从入门到中高循序渐进，做完之后我才理解为什么它叫“第二次作业”——它正好卡在“会用命令”和“理解系统”之间，要求你不光敲得出来，还得知道为什么这么敲。

题面大概是这个样子的：

这五道题其实对应了RHCSA考试里最核心的几个操作域。第一题考察的是用户体系，第二题是权限体系，第三题是SELinux标签与布尔值的理解，第四题是网络配置，第五题则是服务封装。没有一道是让你写脚本或者搞复杂自动化，考的全是“系统管理员日常维护时一定会碰到的操作”。

这也是我后来真正走上工作岗位后体会最深的一点：RHCSA不是考你懂多少理论，而是考你手里有没有干活的本事。这套二次作业模拟得相当准，做完它，等于把RHCSA的骨架摸了一遍。

2. 用户与组管理：一道看似简单但藏雷最多的题目

2.1 题面与我的完整操作

第一题原题大致是：创建用户alice和bob，密码均设置为Rht@lab2025；创建组developers，并将alice的附加组设为developers；设置alice的密码90天后过期，账户在2026年1月1日失效；要求完成后使用id命令确认。

限用系统管理员掌握的命令差不多是这些：groupadd、useradd、usermod、passwd、chage。我当时提交的操作记录是这样的：

groupadd developers useradd alice useradd bob echo 'Rht@lab2025' | passwd --stdin alice echo 'Rht@lab2025' | passwd --stdin bob usermod -aG developers alice chage -M 90 alice chage -E 2026-01-01 alice

这串命令看起来简单，但我写这篇复盘时想特别提醒一句：第一行groupadd developers和第四行echo | passwd --stdin这两步，恰恰是很多新手最容易漏的。组都没建就直接用-aG developers，回头一查getent group developers，报错找半天才发现组不存在；密码不设置，用户创建出来默认锁定状态，用su - alice永远登录不进去。这两个低级错误在练习时犯一次，基本就记住了。

2.2 附加组与主要组的区别：这个坑我替你们踩过了

usermod -aG developers alice里面那个-a是append的缩写，意思是“追加到附加组”，而不是替换。这点一定要刻在脑子里，因为usermod -G developers alice不带-a的话，会把用户原来所有的附加组全部清掉重来。

举个例子：假设alice之前已经在wheel这个组里（wheel组在RHEL里代表可以sudo提权），你为了完成作业跑了一条usermod -G developers alice，那么alice立刻就从wheel组掉出去了，变成只能登录不能提权的普通用户。RHCSA评分系统重启后一检查，发现alice的提权能力没了，扣分都是小事，关键是这种错误在生产环境里会导致同事的权限莫名其妙丢失。

所以我的习惯是：涉及附加组修改，永远先看一眼id alice确认当前组成员，再决定要不要加-a。

2.3 密码策略与账户有效期：容易被忽略的检查点

chage -M 90 alice表示密码最长使用90天，第91天必须改密码；如果只做这道命令行完成就算完，首次放着不管，考试里这道题基本要扣分。因为RHCSA评分经常在重启后进行，你设了有效期但没验证，过期后用户登录会提示Your password has expired，直接被拒在门外。

正确验证方法是：

chage -l alice

输出里会有一行Maximum number of days between password change : 90，和Account expires : Jan 01, 2026，看到这两行跟题面一致，才算完事。另外-E的参数格式是YYYY-MM-DD，别写成2026-1-1，虽然有些版本的chage也能解析，但考试环境里规范写法能少踩不少坑。

我在实际操作中最深的体会是：用户管理题在RHCSA里属于“送分题”，但送分的前提是你把验证步骤也做了。命令敲完不等于题做完，评分系统按最终状态算分，不是按你敲了哪条命令算分的。

3. 文件权限与ACL：从权限位到访问控制列表的完整操作

3.1 目录权限的设计思路：setgid并不是炫技

第二题的题面是：创建目录/ops，属主root，属组developers，要求组内用户可以在目录中创建文件，且新建文件自动属于developers组，其他用户不可访问。

很多新手第一反应是chmod 770 /ops，这其实只完成了一半。组内用户能创建文件确实做到了，但新文件的所有组是谁取决于创建者当前的primary group，而不是目录的属组。假设bob的primary group是bob，他在/ops下创建一个文件，文件的属组就是bob，其他组员根本读不了。

所以必须给目录加setgid位，也就是权限值中百位的2。完整命令：

mkdir /ops chown root:developers /ops chmod 2770 /ops

2770拆开看：最高位的2是setgid，中间的770是rwxrwx---。之后任何成员在这个目录里新建文件，文件的属组都会被强制设为developers。用ls -ld /ops会看到权限位显示drwxrws---，那个s就是setgid生效的标志。

有同学问过为什么不顺便加sticky bit（粘滞位），考试里确实常出现两者混合的题目。sticky bit的作用是只允许文件属主删除自己的文件，像我后来在生产环境配共享目录，经常用1777或3777。如果题目明确说“组员可以互相删除文件”，就不能加sticky；如果要说“只能删除自己创建的”，就得在2770基础上再加1000。做题前一定把题目这句读清楚。

3.2 普通权限与ACL授权：当chmod不够用的时候

第二题还有一问：创建文件/ops/readme.txt，要求alice对该文件拥有读写权限，而文件原本的属主是root、属组developers。developers组有读权限，但alice需要写，这时候再用chmod去改组权限会造成其他成员权限过大。

正确解法是用ACL：

touch /ops/readme.txt chown root:developers /ops/readme.txt chmod 640 /ops/readme.txt setfacl -m u:alice:rw /ops/readme.txt

setfacl -m u:alice:rw的意思是给用户alice单独附加一条读写规则，命令执行后原权限不受到影响。查看时用getfacl /ops/readme.txt，输出会多一行：

user:alice:rw-

ACL在RHCSA中是个高频考点，因为它在传统Linux权限模型之上加了一层更细粒度的控制，考试特别喜欢考“某个特定用户需要特殊权限”这种场景。

3.3 ACL掩码位：我掉过一次才记住的规则

ACL最大的陷阱在掩码（mask）。当你给某个用户设置了ACL项之后，ACL会生成一个mask值，它决定“命名用户”和“命名组”的最大权限上限。如果之后你手动执行了chmod 600 /ops/readme.txt，你以为只是清掉了其他权限，实际上可能把mask也改掉了，导致alice那条ACL的rw权限直接失效。

我那次就犯了这么个错：配置完ACL后觉得权限不够收紧，顺手敲了chmod o-r，再一查getfacl，alice那行还在，但mask变成了r--，alice的写权限实际不生效了。排查了半天，最后是看文档回忆起来ACL mask和传统权限位的联动规则。

所以这里记一条硬经验：设置ACL之后，如果还需要调整传统权限，优先考虑用setfacl -m m::rx去设置mask，而不是直接chmod，否则很容易留下“配置看着对、实际权限没有”的严重隐患。

4. SELinux专题：配置“正确”却访问失败时该信谁

4.1 问题的表象与真相：页面打不开未必是httpd的错

第三题是整套作业里最典型的SELinux题：把httpd的文档根目录从/var/www/html改到/opt/webroot，然后在/opt/webroot下创建一个index.html，重启httpd服务后访问本机IP，发现浏览器/curl一直403 Forbidden。

我当时第一反应是去看httpd配置有没有写错，systemctl status httpd一看running，ss -tlnp也显示80端口在监听，curl http://127.0.0.1/依然403。折腾了十几分钟才想到用ls -ldZ /opt/webroot看一眼SELinux上下文，结果类型是default_t，而不是Web内容应该有的httpd_sys_content_t。

这个表象和真相之间的落差，正是SELinux题最核心的考点。RHCSA不会直接跟你说“把SELinux关了”，它默认SELinux是Enforcing强制模式，要求你用正确的方式让服务跑起来。

4.2 恢复文件上下文的完整链路

修复过程其实不难，难的是理解为什么要这样做。第一步用restorecon临时恢复目录及其下文件的上下文：

restorecon -Rv /opt/webroot

-R表示递归，-v是显示详细信息，执行后会看到类似restorecon: reset /opt/webroot context的输出。但这个命令有个局限：它恢复的是系统默认策略里已经定义的标签。如果/opt/webroot事先不在SELinux策略中，restorecon也未必会把它恢复成httpd_sys_content_t，所以更稳妥的做法是两步走，先用semanage fcontext定义规则，再restorecon生效：

semanage fcontext -a -t httpd_sys_content_t "/opt/webroot(/.*)?" restorecon -Rv /opt/webroot

这里的(/.*)?是正则写法，匹配目录本身以及下面所有文件和子目录。重要的是semanage fcontext -a写的是持久化规则，重启后依然有效；而直接用chcon改标签只对当次有效，考试评分往往重启检查，因此强烈建议用semanage。

重新验证：ls -ldZ /opt/webroot，类型显示为httpd_sys_content_t之后，再用curl http://127.0.0.1/就正常返回页面内容了。

4.3 端口号改动时的SELinux配合：又一个必考分支

作业里藏着个变种题目：如果httpd监听的不是80端口而是8080，那么做完上下文修复还不够，SELinux默认只放行标准端口。启动服务时会直接失败，journalctl日志里会给出类似SELinux is preventing httpd from binding to port 8080的提示。

解法是给SELinux加一条端口类型规则：

semanage port -a -t http_port_t -p tcp 8080

然后重启httpd，再用ss -tlnp | grep 8080确认端口已经监听。执行semanage需要安装policycoreutils-python-utils，RHEL 9上默认可能没带，先用dnf install -y policycoreutils-python-utils装一下。很多人在这一小步上栽跟头，因为命令工具都没找到。

4.4 布尔值开关：SELinux的另一半世界

最后一道小问是：配置httpd服务允许访问网络，这就需要SELinux布尔值放行。布尔值可以理解为SELinux的“功能开关”，默认很多服务的外部通信能力是被禁止的。查看当前状态：

getsebool httpd_can_network_connect

通常返回HTTPD_Can_Network_Connect --> off，使用setsebool -P httpd_can_network_connect 1永久打开。那个-P参数代表持久化，不加的话重启后配置丢失。这一类布尔值在RHCSA考试里考得不少，httpd相关的还有httpd_can_user_zones、httpd_enable_homedirs等，每个都对应一个具体场景，备考时按场景记比死背名字高效得多。

我只想说一句，SELinux考察的是你面对运行“意外失败”时的排查思路。不要一上来就setenforce 0，那是考试里的大忌讳，正确做法是看日志、找类型、改标签、验证。

5. 静态网络配置：nmtui之后的验收细节

5.1 用nmcli完成静态IP配置

第四题的题面：把网卡enp0s3的IP地址改为192.168.56.20/24，网关192.168.56.1，DNS为192.168.56.1，同时把主机名改成rhcsa-lab.example.com。

RHEL 9里网络配置的主流工具是nmcli，考试操作基本都是围绕着NetworkManager来的。我的操作如下：

nmcli con mod enp0s3 ipv4.addresses 192.168.56.20/24 nmcli con mod enp0s3 ipv4.gateway 192.168.56.1 nmcli con mod enp0s3 ipv4.dns 192.168.56.1 nmcli con mod enp0s3 ipv4.method manual nmcli con up enp0s3

前几条命令修改配置，ipv4.method manual决定这块网卡不使用DHCP而是使用静态地址，最后一条con up让修改立即生效。

这里最容易忽略的是ipv4.method那一步。如果你只设置了地址不把方法改为manual，NetworkManager会继续按DHCP方式处理，重启网络甚至重启系统后，静态IP会被DHCP分配的地址顶掉。这个坑在我身上发生过一次，原因就是漏了最后一行，实在是太容易翻车了。

5.2 配置文件里到底发生了什么

用nmcli做完修改，本质上是改写/etc/NetworkManager/system-connections/enp0s3.nmconnection这个文件。手工改配置文件当然也可以，但考试时用nmcli更不容易出错，因为它会自动处理格式。

如果用cat查看配置文件，关键段落长这样：

[ipv4] address1=192.168.56.20/24,192.168.56.1 dns=192.168.56.1; method=manual

注意address1那一行，网关跟在掩码后面用逗号隔开。理解配置文件的结构很重要，因为假如考试环境中NetworkManager被禁用而改用/etc/sysconfig/network-scripts/传统脚本，你也需要有能力直接编辑那些文件来达到同样效果。不过RHEL 9已经彻底移除传统网络脚本，考试时放心用nmcli就好。

5.3 重启后的验收到底验什么

网络配置题的验收不能只看ip addr。我的标准流程是三步：先ping 192.168.56.1测网关连通；再cat /etc/resolv.conf确认DNS生效；最后用hostnamectl status查看完整主机名。DNS那个字段有个坑，nmcli con mod设置的DNS会被NetworkManager写入resolv.conf，但如果你手动改过resolv.conf，重启后有可能被覆盖回去，所以尽量统一用nmcli管理。

另外主机名修改：

hostnamectl set-hostname rhcsa-lab.example.com

执行后立刻用hostname验证。完整的FQDN时间通常需要重新登录终端才能正确显示在提示符里，如果出现这种现象不要慌，属正常。

我建议在做网络题之间先确认自己是通过什么方式连接的。如果是用SSH连到远程虚拟机上操作，改IP前要确保新地址和你当前连接方式兼容，否则命令刚执行完立刻断连，到时候只能去物理控制台救回来。自己练习时倒无所谓，考试环境里断连意味着白白浪费时间。

6. 复盘与备考：那些我踩过却在考试中救命的坑

6.1 一次完整的事故排查：SELinux加端口问题的现场还原

第五题除了安装httpd并设置开机自启之外，还附加了一个定时任务。但真正让我印象深刻的是在一次加练中把SELinux、防火墙、服务配置三样混在一起出错的情形。把完整链路写出来，以后遇到类似问题可以直接照方抓药。

事故现场是这样的：我按要求把httpd改成了监听8080，并且使用semanage port -a放行了端口，重启了服务。结果curl http://127.0.0.1:8080/提示连接失败，ss -tlnp里看不到8080监听。

我当时没有急着改配置，而是按照下面顺序一步步排查：

1. 先看服务状态：systemctl status httpd，发现服务activating后又自动退出，日志里出现端口绑定失败；
2. 用journalctl -xe查看详细日志，发现提示Permission denied而不是普通端口占用；
3. 意识到又是SELinux拦截，执行sesearch --allow | grep httpd_port_t想确认放行状态，但这条命令输出庞杂，实际效率不高；
4. 转向最直接的检查：semanage port -l | grep http_port_t，发现只有80、81、443、488等默认端口，我加的那条8080不见了；
5. 回头查原因，原来是之前setsebool -P httpd_can_network_connect 1时误执行了semanage port -d -t http_port_t -p tcp 8080，把允许端口删掉了；
6. 重新执行semanage port -a -t http_port_t -p tcp 8080，重启httpd，curl立即通。

这一类事故最大的教训是：遇到“配置明明改了却没效果”，先去查系统日志，日志里基本会直接告诉你是什么阻止了操作。SELinux不是玄学，它每条拦截都有明确的审计记录，只是需要你知道去哪里找。

6.2 从失分题到得分题：我给自己的检查清单

做完这套作业之后，我做了一版“最终验证清单”，每道题做完挨个过一遍。别小看这个动作，RHCSA是机考自动判分的，评分系统重启后检查最终状态，你中间怎么操作不重要，只看结果对不对。

我的清单大概长这样：

这套检查清单后来成为了我每次模拟练习的标配，考试中间做一题验一题，比全部做完再回头统一验证稳妥得多。

关于定时任务那道题也顺带说一句：crontab -e编辑当前用户的定时任务表，比如每周三14:30执行备份命令：

30 14 * * 3 tar -cjf /backup/logs-$(date +\%Y\%m\%d).tar.bz2 /var/log/messages 2>/dev/null

我提醒两点：一是date命令里的%在cron环境中需要转义成\%，否则执行会报错；二是目标目录必须存在且写权限可用。另外要确认crond服务已启动并设为开机自启，systemctl enable --now crond，不然任务永远不会触发，这道题的坑基本全在这些细节里了。

6.3 RHCSA认证备考中最值钱的习惯

说句掏心窝的话，做这套二次作业的过程比结果重要得多。RHCSA认证考试和很多IT认证不一样，它没有选择题，全是实际操作，评分系统就盯着你系统里最终的状态。这意味着你平时练习养成的每一个习惯，都会直接变成考场上的表现。

我自己总结下来，备考期间最值钱的习惯有三个：

第一个是“命令即探索”的思维。考试的时候涉及的命令工具就那些，遇到不确定的服务尝试启动，别怕报错，报错本身就是信息。比如systemctl status会问你是不是需要systemctl daemon-reload，跟着提示做就行了。

第二个是“重启验证”的执念。RHCSA评分系统会在考试后重启虚拟机再检查，如果你的配置依赖某个手动启动的进程，重启后没自动起来，这道题就是零分。所以每次练习完，我习惯主动reboot一次，再回来跑一遍检查清单。这个习惯看起来笨，实际非常管用。

第三个是“题目条件逐词读”的谨慎。很多失分是因为理解偏差，比如“附加组”和“主要组”差一个字，操作就完全不同；“只能删除自己创建的文件”对应sticky bit，“允许组内互相删除”就是普通2770。把题目当成合同一样逐词核对，比多刷十道题还有用。

备考RHCSA没有什么捷径，但也不需要什么天赋。环境准备好，题目一套一套过，坑一个一个填，等到把类似第二次作业这样的模拟卷做到几乎没有失误的时候，离通过考试就不远了。我后来进入真实环境管理Linux服务器，用得最多的还是这些基础操作，这也是我建议每个想考红帽认证的人都认真对待这套作业的原因。