如果你正在备考 RHCSA，做作业做到第二次，说明你已经熬过了安装系统和熟悉命令行的阶段。RHCSA 这门认证最难的一点在于，题目不是选择题，而是给你一个真实的系统环境，让你在规定时间内完成一系列配置任务。第二次作业的练习范围通常就覆盖了 RHCSA 考试的核心操作域：用户和权限体系、systemd 服务管理、计划任务、软件源配置、网络与 SSH、日志定位。这些内容看起来都是零零散散的小命令，但每一块都能延伸出考试中真正会扣分的细节。这篇文章我把做第二次作业时应该注意的考点拆开讲一遍，包括命令背后的原理、操作步骤、验证方法，以及我实际练习时踩过的坑。不管你是刚学完基础还是准备冲刺考试，这套思路都值得你照着在虚拟机上过一遍。
1. 第二次作业到底在练什么
先把格局打开。RHCSA 全称是 Red Hat Certified System Administrator，它考的不是你会背多少命令，而是你能否在一个只给你初始状态的红帽系统上，像一个真正的系统管理员那样完成日常运维任务。考试环境是无外网、无现成文档的，你唯一的依据就是自己的知识储备。所以第二次作业的作用，就是把 RHCSA 大纲中那些高频考察点拆成一个个具体的配置场景，反复练到形成肌肉记忆。
1.1 你拿到的是一份“填空题清单”
大多数培训机构和自学习惯的思路，都会把第二次作业设计成类似这样的任务清单：
- 按要求创建用户，指定 UID、主组、附加组、家目录路径和登录 Shell。
- 为一个用户设置密码，同时配置密码过期策略，要求该用户下次登录时必须修改密码。
- 创建共享目录，让指定组内成员可以读写，并且新创建的文件自动继承组的属组关系。
- 为某个用户或组设置 ACL 权限。
- 创建一个自定义 systemd 服务，并设置为开机自启。
- 配置 cron 计划任务，比如每天固定时间执行某个脚本。
- 配置 at 一次性任务，确认任务在指定时间执行。
- 添加或配置 dnf 软件源，安装指定软件包。
- 修改系统主机名，用 nmcli 配置静态网络地址。
- 为特定用户配置免密 SSH 登录。
- 用 journalctl 查看某个服务的运行日志，定位错误。
这份清单基本上就是 RHCSA 考试大纲的缩影。你可以在自己的虚拟机里把这些任务从头到尾过一遍，然后思考一个问题：这些任务如果换个机器、换个用户名、换个时间要求，操作流程还是一样的吗？如果答案是不确定，那说明你还没有真正理解底层逻辑，只是记住了键盘上的操作顺序。
1.2 为什么这些操作是 RHCSA 的核心骨架
回答这个问题的关键在于理解红帽的命题思路。RHCSA 考察的是一个系统管理员最基础的生存能力：你能管理账户和权限，因为这是多用户系统最底层的安全边界；你能管理系统服务，因为服务器上跑的软件本质上是受 systemd 管理的进程；你能配置计划任务，因为自动化是运维的基础；你能搞定软件源和网络，因为这两项直接决定一台服务器能否持续可用。把这几个模块串起来，就是一台 Linux 服务器从安装到投入使用的最小闭环。
我见过不少备考者，做题时只盯着“命令怎么敲”却不关心“为什么这么敲”，一旦题目换一个角度就蒙了。比如同一道题，改一下要求“给这个服务设置开机启动”和“设置这个服务在系统启动后自动启动”，前者你会用 systemctl enable，后者你可能就不知道还是 enable，只是描述不同而已。说到底，变的是语言包装，不变的是服务管理的核心概念。第二次作业的价值就在于此：它逼着你把概念和操作一一对应起来。
2. 用户与权限：最容易被细节坑掉的环节
用户和权限这一章，是 RHCSA 考试中题量最多、分值最重的部分之一。这部分的坑特别多，因为命令本身简单，但各种参数组合起来，稍不留神就会做错。做作业时我建议大家不要只求“把用户建出来”，要反复问自己：这个用户的主组是什么？家目录在哪里？Shell 是什么？UID 是多少？所有问题都要在验证阶段用命令确认。
2.1 创建用户的隐藏细节：UID范围、家目录、umask
先看一个典型的创建用户命令：
useradd -u 2800 -g rhtgroup -G wheel -d /home/rhtuser -s /bin/bash rhtuser passwd rhtuser这个命令做了几件事：指定 UID 为 2800，主组为 rhtgroup，附加组为 wheel，家目录为 /home/rhtuser，登录 Shell 为 /bin/bash。每个参数都有对应考点。
有个非常常见的混淆点必须说清楚：-g指定的是主组，-G指定的是附加组。很多新手把两个参数当成一回事，结果题目要求“把某用户添加到某组”，他用-g一改，直接把主组换了，后面共享目录权限怎么查都不对。我当时的教训是：题目里的“添加到一个组”几乎都指的是附加组，除非它明确说“主要组”或者“初始组”。
另一个容易出问题的点是用户家目录的权限。useradd默认创建的家目录权限是 700，也就是只有用户自己能访问。如果考试题目要求其他组内成员可以访问这个用户的家目录，比如“允许 rhtgroup 组内的成员可以读取该目录”，光创建用户是不够的，还要手动调整：
chmod 750 /home/rhtuser chgrp rhtgroup /home/rhtuser不调整的话，组内其他成员连家目录都进不去。很多作业场景里，这道题的前置条件是让两个用户共享一个家目录区域的文档，结果因为这一步没做，权限验证直接失败。
还有一个小细节：如果你用useradd创建用户后不设置密码，这个用户是无法登录的。而且如果你在考试中用了useradd以后马上执行各种配置，回头发现用户登录不上去，第一时间检查的就是密码是否设置成功，可以用passwd -S rhtuser查看密码状态。
2.2 组共享目录：setgid与ACL怎么配合
组共享目录是 RHCSA 的一大高频考点，题目通常这样描述：创建一个目录 /shared/team，让 teamgroup 组成员可以在里面创建和删除文件，并且新生成的文件自动属于 teamgroup，而不是创建者自己的主组。
这个题目的标准操作分两步。第一步，把目录组改成 teamgroup，并设置 setgid 特权位。第二步，给目录开放组读写执行权限。
chgrp teamgroup /shared/team chmod 2770 /shared/team其中数字 2 在权限位最前面，代表 setgid 位。setgid 作用于目录的含义很优雅：在这个目录下新建的任何文件和子目录，其属组自动继承目录的属组，而不是创建者自己的主组。这是实现共享目录的天然工具。
但这里有一个坑是我做作业时反复踩过的：setgid 只解决“属组继承”的问题，不能解决“创建者 umask 导致文件权限不足”的问题。举个例子，如果系统 umask 是 022，那么新建文件的默认权限通常是 644，虽然文件属于 teamgroup，但组内其他人没有写权限。这时候光靠 chmod 2770 解决不了，因为新文件的权限是由 umask 决定的。考试中如果要绕过这个坑，常用的办法是配合默认 ACL：
setfacl -m d:g:teamgroup:rwx /shared/teamd:开头的 ACL 是默认 ACL，它的意思是：在这个目录下新建的任何文件和子目录，都会自动给 teamgroup 组设置 rwx 权限，不受创建者 umask 的负面影响。加上这条命令，才能真正保证组内成员在合作场景中都能读写彼此创建的文件。
在学习时，我建议你把ls -ld和getfacl /shared/team都跑一遍，观察 setgid 位显示为小写 s 还是大写 S。s 表示这个目录本身具有执行权限，S 表示 setgid 位存在但目录没有执行权限，后者意味着这个配置有问题。这种细节就是考试判卷时最容易扣分的地方。
2.3 特权位与密码策略：一道题里藏了三层要求
RHCSA 的题目经常喜欢把多个考察点揉在一起，不会单独说“请设置 setgid”，而是说“请让该目录可以被团队协作使用并自动继承组权限”。同理，密码策略也可能藏在用户创建任务里。
设置密码过期策略时，常用命令是chage。例如要求用户 rhtuser 的密码有效期为 90 天，密码过期前 7 天提醒，并且下次登录必须修改密码：
chage -M 90 -W 7 -d 0 rhtuser-M是最大有效天数，-W是过期前提醒天数，-d 0强制该用户下次登录时立刻改密码。这里最容易忽略的是-d 0，因为很多题目不会直白地写“强制下次修改密码”，而是写“要求该用户登录后必须更改密码”。这两句话意思完全相同，但如果你没有理解-d 0的含义，这道题就只能靠碰运气了。
chage的作用虽然简单，但要记清楚是给现有用户设置属性，而不是创建用户。如果你先用useradd创建用户，再用chage修改策略，这两步操作顺序无所谓，但如果你试图用useradd的参数一步搞定密码过期，很多版本的红帽系统并不支持直接用useradd指定密码过期时间，还是得回到chage。这个组合考点非常典型，建议做题时把id、passwd -S、chage -l三条验证命令都执行一遍。
Sudo 权限也是用户管理中的常客。如果题目要求某用户可以以 root 身份执行任意命令，一般做法是：
usermod -aG wheel rhtuserRHEL 系统默认在 sudoers 中配置了%wheel组具有全部权限。注意修改 sudoers 时永远不要直接编辑/etc/sudoers，而是用visudo命令，这样能在保存前检查语法。直接用编辑器改坏了文件，会导致所有用户都无法使用 sudo，负载低的实验环境还好，生产环境这就是事故。
3. systemd、计划任务与软件源管理
完成用户相关的基础操作后，第二次作业通常会进入服务管理阶段。这部分内容同样在 RHCSA 中占据大量分值，而且非常贴近生产环境。你平时维护服务器时对服务做的事，考试中几乎都会遇到。
3.1 服务管理：不是会systemctl start就行
很多新手提到 systemd，第一反应就是systemctl start 服务名。但 RHCSA 不会只让你启动服务，它更可能考的是“设置某服务开机自启并立即启动”或“屏蔽”某个服务。
最正规的写法是：
systemctl enable --now httpd这一条命令等价于systemctl enable httpd加systemctl start httpd，省时间且不容易忘记其中一步。同理，如果你想禁用某个服务且停止它，用systemctl disable --now。
关于服务管理的进阶考点，是创建自定义 systemd 服务。作业里常见的场景是：写一个脚本，要求系统启动时自动运行，且服务器重启后仍然有效。操作方法是先写脚本到/usr/local/bin/并加执行权限，然后创建服务单元文件/etc/systemd/system/mytest.service：
[Unit] Description=My Test Service After=network.target [Service] Type=oneshot ExecStart=/usr/local/bin/mytest.sh [Install] WantedBy=multi-user.target这里必须强调两点。第一，写完单元文件后要执行systemctl daemon-reload，否则 systemd 不会加载新配置。第二，Type=oneshot表示这条服务是一条性任务，执行完脚本后就退出；如果你用的是默认的Type=simple，systemd 会认为服务进程需要一直驻留，但你的脚本执行完就退出了，服务状态会显示失败。这两种类型不搞清楚，自定义服务这道题可以做很久都找不到问题在哪。
我记得第一次练习时写了个脚本，脚本内容就一条echo，Unit 文件写完启动后systemctl status一直报 inactive (dead)。我当时以为脚本没执行，排查了半天才发现是循环在 Type 类型上。换成oneshot以后，脚本执行状态清晰，这就是典型的概念不清导致操作反复。
3.2 cron与at：两种计划任务的使用边界
计划任务是运维自动化的基础，RHCSA 考试中对 cron 的考查方式是多种多样的，可能直接在/etc/cron.d/下放一个任务文件，也可能要求用户通过crontab -e编辑自己的任务。两者格式上最大的区别是：/etc/cron.d/下文件中的任务行需要多加一个“用户名”字段，而crontab -e里的行不需要。
举个例子，要求每天 14:30 执行/usr/local/bin/backup.sh。如果用 root 的crontab -e，写入：
30 14 * * * /usr/local/bin/backup.sh如果在/etc/cron.d/backup这个文件中写，必须是：
30 14 * * * root /usr/local/bin/backup.sh这个区别是很多人的扣分点。我见过不少人直接在/etc/cron.d/下写 crontab 格式，把用户名漏了，结果 cron 服务完全不会执行这个任务，用grep查看相关日志时也没有任何记录。
at一次性任务的考点相对简单，但一定要确保 atd 服务在运行：
systemctl status atd echo "sh /usr/local/bin/test.sh" | at now + 5 minutes学的时候最好复习一下atq查看任务队列，用atrm删除任务。大多数课程不会把 at 展开讲太多，但考试时可能有一道题就是单纯考查 at 是否理解。
验证计划任务是否执行，我的建议是别只看ls的结果，因为有可能是文件刚好被别的流程创建了。更可靠的方法是查看 cron 的执行日志。RHEL 系统将 cron 任务执行信息记录在/var/log/cron中，执行tail -f /var/log/cron后等待任务触发，能看到具体的执行记录。这样验证要比事后推测准确得多。
3.3 dnf软件源：配好源只是第一步
配置软件源是 RHCSA 中一个基础但重要的考点。考试可能要求你“添加一个软件源，并确认可用”，也可能更进一步“从这个源安装软件包并验证版本”。标准做法是在/etc/yum.repos.d/下添加一个 repo 文件，比如local.repo：
[dvd_repo] name=Local DVD Repo baseurl=file:///mnt/cdrom/AppStream enabled=1 gpgcheck=0配完以后第一件事就是验证：
dnf repolist dnf install -y vsftpd如果dnf repolist显示该 ID 的源可用，说明仓库配置成功。这里我见过不少新手犯的错误是：在 baseurl 里写错路径，比如写成file://mnt/cdrom少了斜杠，或者挂载点不对。排查时可以使用dnf repolist --verbose查看具体的源 URL，再用ls确认挂载目录下确实存在 repodata 目录。
另一个容易出问题的地方是 gpgcheck。在自建本地源或内网源场景中，通常设置为 0 跳过签名验证；但如果是官方源且网络环境可用，保持 gpgcheck=1 并配置正确的 GPG key 更规范。考试中为了稳定，大多采用本地 DVD 镜像源，记住关键点：路径正确、权限可读、enabled=1。三条都对，dnf repolist才能正常显示。
当安装某个包后提示依赖缺失，dnf install会自动处理依赖。但如果你用的是rpm -ivh，则必须手动把所有依赖的 rpm 包一并安装，否则会报错。这个差异也是考试中经常暗藏考察点的地方：如果要安装的软件路径在本地，用dnf install /path/package.rpm比rpm -Uvh更省心，因为 dnf 会走一遍依赖分析。
4. 网络、SSH与日志基础
网络配置和远程管理是 RHCSA 另一块重要内容。对系统管理员来说，不会配网络意味着服务器无法接入现有基础设施。把日志查看和 SSH 配置放在这一部分来复习，也是因为日常最常接触的远程运维场景恰好包含这几项。
4.1 主机名与IP配置：先分清持久化配置
RHEL 8 之后，网络的持久化配置已经全面迁移到 NetworkManager。作业中最常见的题目是：给系统设置一个固定主机名，并配置静态 IP 地址。主机名的配置比较简单：
hostnamectl set-hostname node1.example.com修改后执行hostnamectl查看结果。这里不推荐直接编辑/etc/hostname，因为虽然内容一样，但hostnamectl会同时更新 systemd 的相关状态，避免某些服务从 stale 状态读到旧主机名。
IP 地址的配置方式，很多旧教程还在教vim /etc/sysconfig/network-scripts/ifcfg-ens160，在 RHEL 9 上这个方式虽然仍能生效，但更标准的建议是使用 nmcli。假设网卡名为 ens160，配置静态 IP 192.168.1.100/24，网关 192.168.1.1，DNS 192.168.1.1：
nmcli connection modify ens160 ipv4.method manual ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.dns 192.168.1.1 nmcli connection up ens160注意网卡名要根据自己的虚拟机环境来定，不要照抄 ens160，可以用nmcli device status查看实际名字。配置完成后验证命令是ip addr show ens160和ip route，而不是ifconfig。虽然 ifconfig 也能看 IP，但 RHEL 默认最小化安装后可能没有 net-tools，用ip命令更稳妥。
这里的核心逻辑是理解“配置文件驱动”和“运行时配置”的差异。nmcli connection modify修改的是持久化配置，必须connection up或重启网络才能生效；如果你用ip addr add临时添加 IP，重启就会丢失。考试中要求配置静态地址，一定是在连接配置文件里做持久化修改，而不是用ip命令。
4.2 SSH免密登录与sshd排障
SSH 配置在 RHCSA 中主要考察两点：修改默认配置使特定用户能够登录，以及配置免密登录。做免密登录时的标准流程是：
ssh-keygen -t rsa -b 4096 -N "" ssh-copy-id rhtuser@192.168.1.200-N ""表示空密码短语，这样后续登录不需要输入口令。ssh-copy-id逻辑上等价于把本机的公钥追加到目标机器对应用户的~/.ssh/authorized_keys中，如果你不想用这个命令，也可以手动cat ~/.ssh/id_rsa.pub | ssh user@host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"，效果一样。
我曾经在作业里漏掉一个关键点：目标用户的家目录或.ssh目录权限不对时，即使公钥复制过去了，SSH 也会拒绝使用密钥登录并回退到密码验证。RHEL 的 sshd 默认要求.ssh目录权限为 700，authorized_keys文件权限为 600。权限过宽会触发 sshd 的安全限制，导致免密配置失败。这个坑排查起来很难受，因为服务端日志会提示权限问题，但初学者往往不会去看/var/log/secure。
如果你在作业中遇到“SSH 登录慢”或“密码对但登录失败”的情况，先检查一下 sshd 服务状态和监听端口：
systemctl status sshd ss -tlnp | grep :22新增的考试趋势中，还可能出现“禁用 root 远程登录”或“仅允许某用户从特定地址登录”的配置，操作对象是/etc/ssh/sshd_config。修改后必须重启 sshd 服务，而且建议保持当前 SSH 会话不退出，另外开一个新窗口测试新配置是否正常，再决定是否关闭当前连接，防止把自己锁在机器外面。
4.3 journalctl：把日志当成第一现场
日志能力不是一个单独的考题，但它深入渗透到每一道题中。无论你是排查计划任务没执行、服务启动失败、还是 SSH 连接被拒绝，最终都要回到日志中找答案。journalctl 是 RHEL 上最常用的日志查看工具。
最常用的几个排查命令：
journalctl -xe journalctl -u httpd.service journalctl -u httpd.service --since "10 minutes ago" journalctl -p err -p warning -b-x是显示附加说明，-e是跳转到日志末尾。在服务启动失败时，journalctl -u会直接告诉你失败原因，比如“Failed to start”或“Permission denied”，比用肉眼干猜系统状态有效得多。RHEL 7 时代经常看的/var/log/messages仍然存在，但 systemd 的统一日志已经覆盖了大部分应用输出场景。
做作业时容易忽略的一点是日志的持久化。journald 默认把日志保存在内存/run/log/journal中，重启后历史日志就会丢失。如果想保证日志持久保存到磁盘，需要创建/var/log/journal目录并重启 journald。考试不一定直接考这个，但在你当天反复重启虚拟机做实验时，持久化日志能帮你保留足够多的历史信息。
5. 常见实验踩坑与排查记录
做 RHCSA 相关作业时，报错不可怕，怕的是没有排查思路。我整理了一份自己在练习过程中真正遇到过的典型问题对照表，如果你在操作时遇到类似现象，可以直接照着排查方向走一遍。
5.1 高频问题对照速查表
| 现象 | 可能原因 | 排查命令 |
|---|---|---|
| 用户创建成功但无法登录 | 密码未设置，或 /etc/shadow 中密码字段为 ! | passwd -S 用户名 |
| 目录共享后组内成员无法写入 | setgid 未设置，或 umask 导致新文件权限不足 | ls -ld /shared/team和getfacl |
| systemd 服务启动后 inactive (dead) | Type 类型错误，脚本执行完就退出但服务被声明为常驻 | systemctl status 服务名 |
| cron 任务不执行 | crond 服务没启动，或 /etc/cron.d 下漏写用户名 | systemctl status crond和tail /var/log/cron |
| dnf repolist 不显示新源 | baseurl 路径错误、repo 文件权限不对或 enabled=0 | dnf repolist --verbose |
| SSH 免密登录无效 | 家目录或 .ssh 权限过宽，authorized_keys 内容不正确 | ssh -vvv 目标用户@主机 |
| 静态 IP 配置不生效 | 没有 connection up，或配置写入错误连接 | nmcli connection show |
| 服务日志里看到 permission denied | SELinux 上下文错误，或目录属主不对 | journalctl -u 服务名、ls -ld |
这张表没有把所有可能都列进来，但绝大多数第二次作业里出现的问题，都能在这些方向上找到共性。遇到问题先不要急着重启虚拟机，很多时候你只需要用systemctl status、journalctl、ls -ld、id四个命令交叉验证，就能定位出真正的原因。
5.2 做作业时应该养成的检查习惯
我每次做完一个配置任务，都会按固定顺序做三件事：看状态、看权限、看日志。
看状态指的是服务有没有 running、用户属组有没有变化、网络连接是否 up，对应命令就是systemctl status、id、nmcli connection show。看权限是专门对付文件权限类题目的，养成ls -ld、getfacl的习惯，比做完判断题后凭感觉说“感觉没问题”可靠得多。看日志则是在前两步都没发现异常时，进一步深入排查的必经之路。
用这个思路检查，证明我是真在练习中吃过亏。以前我做完一个共享目录配置题，检查时只看了目录权限是 2770，觉得没问题，结果组内用户创建文件后，其他组员根本打不开。最后仔细看才发现文件属组不是共享组，而是创建者的私有组，因为新文件生成时完全忽略了我设的 setgid。用ls -ld一看，目录的 s 是小写 s，说明有 setgid，问题就出在验证时没有去实际创建文件。
所以我的建议是：作业收尾阶段，不要只静态检查配置，一定要用普通用户身份实际测试一次。比如权限问题，就用组内用户登录后touch一个文件，再用另一个用户读取和修改；服务问题，就用systemctl restart后看状态和日志；网络问题，就从另一台机器 ping 一下目标地址。能跑通真实使用流程，才算真正完成了作业。
我个人在实际操作中的体会是，RHCSA 的很多坑都不是“不会命令”造成的，而是“看一眼觉得没问题”造成的。做第二次作业时，与其一门心思加快速度，不如每次做完都用上面的三连检查法走一遍。刚开始会很慢，但练过十几次之后，你会发现自己看问题的角度变了，不再是机械执行命令，而是主动判断配置是否符合预期。后面真正考试时，这种下意识检查的习惯，会比多背几十条命令更让你安心。把环境故意弄坏再修好，这个过程虽然折腾，但往往是最长本事的部分。
