如果你正在备考 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 决定的。考试中如果要绕过这个坑常用的办法是配合默认 ACLsetfacl -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] DescriptionMy Test Service Afternetwork.target [Service] Typeoneshot ExecStart/usr/local/bin/mytest.sh [Install] WantedBymulti-user.target这里必须强调两点。第一写完单元文件后要执行systemctl daemon-reload否则 systemd 不会加载新配置。第二Typeoneshot表示这条服务是一条性任务执行完脚本后就退出如果你用的是默认的Typesimplesystemd 会认为服务进程需要一直驻留但你的脚本执行完就退出了服务状态会显示失败。这两种类型不搞清楚自定义服务这道题可以做很久都找不到问题在哪。我记得第一次练习时写了个脚本脚本内容就一条echoUnit 文件写完启动后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] nameLocal DVD Repo baseurlfile:///mnt/cdrom/AppStream enabled1 gpgcheck0配完以后第一件事就是验证dnf repolist dnf install -y vsftpd如果dnf repolist显示该 ID 的源可用说明仓库配置成功。这里我见过不少新手犯的错误是在 baseurl 里写错路径比如写成file://mnt/cdrom少了斜杠或者挂载点不对。排查时可以使用dnf repolist --verbose查看具体的源 URL再用ls确认挂载目录下确实存在 repodata 目录。另一个容易出问题的地方是 gpgcheck。在自建本地源或内网源场景中通常设置为 0 跳过签名验证但如果是官方源且网络环境可用保持 gpgcheck1 并配置正确的 GPG key 更规范。考试中为了稳定大多采用本地 DVD 镜像源记住关键点路径正确、权限可读、enabled1。三条都对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.1DNS 192.168.1.1nmcli 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 rhtuser192.168.1.200-N 表示空密码短语这样后续登录不需要输入口令。ssh-copy-id逻辑上等价于把本机的公钥追加到目标机器对应用户的~/.ssh/authorized_keys中如果你不想用这个命令也可以手动cat ~/.ssh/id_rsa.pub | ssh userhost mkdir -p ~/.ssh cat ~/.ssh/authorized_keys效果一样。我曾经在作业里漏掉一个关键点目标用户的家目录或.ssh目录权限不对时即使公钥复制过去了SSH 也会拒绝使用密钥登录并回退到密码验证。RHEL 的 sshd 默认要求.ssh目录权限为 700authorized_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和getfaclsystemd 服务启动后 inactive (dead)Type 类型错误脚本执行完就退出但服务被声明为常驻systemctl status 服务名cron 任务不执行crond 服务没启动或 /etc/cron.d 下漏写用户名systemctl status crond和tail /var/log/crondnf repolist 不显示新源baseurl 路径错误、repo 文件权限不对或 enabled0dnf repolist --verboseSSH 免密登录无效家目录或 .ssh 权限过宽authorized_keys 内容不正确ssh -vvv 目标用户主机静态 IP 配置不生效没有 connection up或配置写入错误连接nmcli connection show服务日志里看到 permission deniedSELinux 上下文错误或目录属主不对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 的很多坑都不是“不会命令”造成的而是“看一眼觉得没问题”造成的。做第二次作业时与其一门心思加快速度不如每次做完都用上面的三连检查法走一遍。刚开始会很慢但练过十几次之后你会发现自己看问题的角度变了不再是机械执行命令而是主动判断配置是否符合预期。后面真正考试时这种下意识检查的习惯会比多背几十条命令更让你安心。把环境故意弄坏再修好这个过程虽然折腾但往往是最长本事的部分。