我其实挺少看到有人认认真真坐下来把 RH134 前半程梳理成体系的。大部分备考的朋友要么抱着题海猛刷，要么把课程从头到尾点一遍，结果考完没几天就忘了。RH134 这门课，红帽给出的全称是 Red Hat System Administration II，对应的是 RHCSA 认证的完整考试范围。很多人的误区是觉得它就是 RH124 的续集，多学几个命令而已。真正走过一遍之后你会发现，RH134 的重点根本不在“认识新命令”，而在“把系统运维自动化”。
这一篇我先集中拆解前半程的核心模块：命令行效率、周期任务、时间同步、性能调优、SSH 免密。这几个主题在教材里分在不同章节，但实际是一条线——都是为了让一台 Linux 服务器在无人值守的情况下稳定干活。下面我会按自己的学习顺序，把每个模块的设计思路、关键命令、实际操作和踩坑经验全部整理出来。正在备考 RHCSA 或者刚开始接触企业 Linux 运维的朋友，这篇文章应该能帮你省掉不少自己绕弯的时间。
1. 先聊聊 RH134 前半程的课程设计与学习思路
RH134 前半部分学下来，我的整体感受是：它不像 RH124 那样什么都讲一遍，而是围绕“自动化运维”这个目标重新组织内容。红帽官方把 RH134 定位为 RHCSA 的第二门课程，考纲覆盖的内容其实和 RH124 有大量重叠，但是深度和角度完全不一样。RH124 教你“这个命令能做什么”，RH134 教你“如何让一系列命令在正确的时间、以正确的优先级、在正确的环境下自动执行”。
举个例子，RH124 里你会学到cron是 Linux 的计划任务工具，然后练习一下怎么写crontab。RH134 里你不仅要会用，还要知道 cron 任务执行时为什么不加载用户的登录环境变量、为什么脚本里的命令要写绝对路径、日志要在哪里排查、权限不够时任务为什么直接不跑。这些细节看上去不起眼，却是实际运维中最容易翻车的地方。
我建议把前半程拆成下面三个层次来学习：
- 第一层是提升操作效率。核心是 PATH 环境变量、自定义命令、bash 历史技巧。目的很简单：让你在命令行里少敲重复命令。这一层掌握得越牢，后面所有模块的实操速度都会快一截。
- 第二层是让系统自动干活。核心是 cron、at、systemd timer 这类计划任务工具。目的不是背格式，而是理解“系统调度机制”的完整链路，包括服务、日志、环境、权限。
- 第三层是让系统稳定运转。核心是时间同步（chrony）、进程优先级（nice/renice）、SSH 免密认证。这些内容单独看起来不复杂，但组合在一起，就是一台服务器“自我管理”的基础设施。
这三个层次并不是完全独立的。比如 SSH 免密配置好之后，cron 任务里就能放心调用ssh user@host 'command'去远程执行脚本；时间不同步时，日志错乱会直接影响你排查 cron 任务是否准时执行。这也是为什么我把这几个模块放在同一篇总结里，它们在生产环境里本来就是互相咬合的一整套东西。
2. 命令行效率：PATH、shell 历史与自定义命令
RH134 前半程第一个让我觉得“终于有人讲明白”的模块，是关于命令行效率的部分。它不会单独列一张命令大全让你背，而是教你从机制层面去理解：shell 是怎么找到命令的、什么情况下会找不到命令、怎么把自己写的脚本变成系统级命令。
2.1 PATH 环境变量决定了“为什么敲命令找不到”
当你在终端输入一个命令，shell 并不会全盘扫描整个文件系统去找它，而是按 PATH 环境变量中记录的目录顺序，一个一个目录查找。找到第一个同名可执行文件就停止。如果全部找完都没有，就会报command not found。
echo $PATH默认输出大概长这样：
/root/.local/bin:/root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/binRH134 里反复出现的一个场景是：你自己写了一个脚本放在/root/scripts/下面，给了执行权限，但是敲名字执行时提示找不到命令。原因就在 PATH 里没有包含这个目录。解决办法有两个方向：
- 把脚本放进 PATH 已有的目录，比如
/usr/local/bin/，这是最推荐的方式； - 把脚本所在目录加进 PATH，比如在
~/.bashrc里追加一行。
echo 'export PATH="$PATH:/root/scripts"' >> ~/.bashrc source ~/.bashrc我自己的经验是，考试环境里尽量使用第一种方式，也就是把脚本放入/usr/local/bin/。原因很简单：RHCSA 考试对“命令可用范围”是有要求的，你通过修改登录环境变量的方式添加 PATH，只能在当前用户当前 shell 里生效，如果题目明确要求“所有用户都能执行”，那就必须把脚本放到公共目录，而不是去改某个用户的 bashrc。
2.2 自定义命令脚本的编写规范
RH134 里自定义命令不只是写一个 shell 脚本那么简单，它讲究一套完整的规范，目的是让脚本在自动化场景里可复用、可排错。我按自己的实操习惯整理了几个必需点。
脚本头部必须有#!/bin/bash声明解释器，然后设置set -o nounset和set -o errexit。它们的作用分别是：遇到未定义变量时报错退出，遇到命令执行失败时立即退出。这样脚本不会带着错误状态继续往下跑，这在 cron 任务里尤其重要，因为脚本出错了你要能通过退出状态码第一时间发现。
#!/bin/bash set -o nounset set -o errexit LOG_FILE=/var/log/myapp/backup.log echo "$(date '+%Y-%m-%d %H:%M:%S') backup started" >> "$LOG_FILE"脚本写好之后，需要赋予执行权限：
chmod +x /usr/local/bin/my-backup一个容易被忽略的细节是脚本命名。尽量不要和系统已有命令重名，比如test、kill、read，否则会因为 PATH 查找顺序导致奇怪的行为。我一般习惯用带连字符的名字，比如my-backup、sys-info，既能识别是自己写的，又避免和系统工具冲突。
2.3 bash 历史技巧在考试中的价值
RH134 前几章会花一点时间讲 bash 历史，很多人觉得这部分是凑数，实际作用很大。在考试里你敲命令的速度直接决定了能不能做完所有题目。下面这几个快捷键和语法，我建议练到手感自然。
!!：执行上一条命令；!$：引用上一条命令的最后一个参数；!string：执行最近一条以 string 开头的历史命令；Ctrl + r：反向搜索历史命令；Ctrl + w：删除光标前一个单词。
举个例子，你刚刚创建了一个用户，紧接着想给它设置密码，传统方式是再敲一遍完整命令，但用历史引用更快：
useradd testuser passwd !$!$会展开成上一条命令的最后一个参数testuser，实际执行的就是passwd testuser。这类技巧在考试的时间压力下非常实用，日常运维中也能少敲很多重复内容。
3. 计划任务：cron 是最常用答案，但也是最容易出问题的部分
计划任务这个模块，几乎是 RH134 考试必考的内容，也是生产环境里用得最多的自动化手段。很多刚入行的朋友只会写个crontab -e，然后往里填五段式时间表达式，却不知道任务没执行时应该从哪里排查。这一节我把时间格式、用户级和系统级 cron 的区别、环境变量问题、日志排查全部串起来讲一遍。
3.1 cron 的时间表达式到底该怎么读
cron 的时间格式是五个字段，依次是：分钟、小时、日期、月份、星期。用*表示任意值，用逗号表示枚举，用连字符表示范围，用/表示步进。后面跟的是要执行的命令。
下面这张表是记忆重点：
| 字段 | 取值范围 | 含义 |
|---|---|---|
| 分钟 | 0-59 | 每小时的第几分钟 |
| 小时 | 0-23 | 每天的第几个小时 |
| 日期 | 1-31 | 每月的第几天 |
| 月份 | 1-12 | 每年的第几个月 |
| 星期 | 0-7 | 每周的第几天，0 和 7 都表示周日 |
几个常见写法：
# 每天 02:30 执行 30 2 * * * /usr/local/bin/my-backup # 每 10 分钟执行一次 */10 * * * * /usr/local/bin/check_disk.sh # 每周一到周五的 08:00 执行 0 8 * * 1-5 /usr/local/bin/report.sh有一个非常容易踩的坑：日期字段和星期字段是“或”的关系。比如0 0 1 * 1在不少人的理解里是“每月第一天且是周一时执行”，但实际语义是“每月 1 号执行，并且也在每周一执行”。如果你真的想表达“每月 1 号且正好是周一”，cron 做不到，只能组合条件在脚本里判断。这个知识点在考试里出现过，理解不到位很容易选错。
3.2 用户级 crontab 与系统 /etc/crontab 的区别
RH134 里会把 crontab 分两种：用户级和系统级。用户级通过crontab -e编辑，属于当前用户的计划任务；系统级文件是/etc/crontab，它多了一个“执行用户”字段，格式是六段式。
# /etc/crontab 示例 30 2 * * * root /usr/local/bin/my-backup日常维护中，我绝大多数情况使用用户级 crontab，因为不需要直接修改系统文件，也不涉及额外的权限管理。考试中你也要留意题目要求的是“为某用户创建计划任务”，这时的正确操作是crontab -u username -e，而不是去编辑/etc/crontab。
用户级 cron 任务默认会向该用户发送邮件输出，如果没有配置邮件系统，这些邮件会堆积在本地的/var/spool/mail/目录下。所以我一般会在每条任务后面加上重定向：
30 2 * * * /usr/local/bin/my-backup > /var/log/my-backup.log 2>&1这样既能记录输出，又不会把本地邮箱撑爆，排查问题也方便。
3.3 cron 环境变量是隐藏杀手
这是我认为整个 cron 模块里最值得单独拎出来讲的知识点。cron 在用户登录时不存在，它由crond守护进程启动，默认不会加载用户登录 shell 的环境变量，比如/etc/profile或~/.bash_profile。它只使用一个极其精简的环境，PATH 通常是/usr/bin:/bin。
所以你在交互 shell 里能正常执行的命令，放进 cron 里很可能因为 PATH 里没有/usr/local/bin而失败。解决办法有两个：
- 脚本里所有外部命令都写绝对路径，比如
/usr/bin/find、/usr/sbin/tcpdump； - 在 crontab 文件顶部显式设置 PATH。
PATH=/usr/local/bin:/usr/bin:/bin 30 2 * * * /usr/local/bin/my-backup我自己更推荐“命令全用绝对路径 + 脚本内部定义变量”的做法，因为在多个 Linux 发行版之间迁移 crontab 时，这种写法最不容易出问题。另外，%在 crontab 里有特殊含义，它表示换行，如果你要执行命令并把日期传给脚本，比如：
0 2 * * * /usr/local/bin/backup.sh $(date +\%F)这里必须写成\%F，不转义的话 cron 会把%后面的内容当作标准输入传给命令。
3.4 at 命令处理一次性任务
周期性任务用 cron，临时任务用at。比如你现在想预定 15 分钟后运行一个脚本，用at比临时写一行 crontab 干净得多。
at now + 5 minutes /usr/local/bin/quick_check.sh输入完成后按Ctrl + D提交。查看队列用atq，删除任务用atrm 任务号。值得留意的是at服务由atd守护进程支撑，如果执行at时提示无法打开作业文件或找不到队列，先检查systemctl status atd。
4. 系统时间同步：时区设置与 chrony 排查
时间问题在考试里看起来分值不大，但实际生产中非常重要。日志记录、证书校验、Kerberos 认证、数据库事务、分布式集群的一致性，几乎全都依赖系统时间的正确性。很多人复习 RH134 时直接跳过时间模块，觉得无非是date -s改一下，这个想法在单机环境里没错，放到真实网络环境里就会吃大亏。
4.1 timedatectl：现代 RHEL 的时间管理入口
RHEL 8/9 系列里，时间管理统一走timedatectl，取代了老旧的date、hwclock、tzselect那一套手动配置方式。
timedatectl status这条命令能看到本地时间、UTC 时间、RTC 时间以及是否启用了 NTP 同步。查看当前时区：
timedatectl list-timezones设置时区：
timedatectl set-timezone Asia/Shanghai启用 NTP 自动同步：
timedatectl set-ntp yes不要再像以前那样去创建/etc/localtime的软链接，除非你是在非常老的系统上操作。红帽考试现在要求的是timedatectl的用法，这个命令本身工程化程度高，直接改文件的方式很容易在系统更新时被覆盖。
4.2 chrony 的配置与验证
RHEL 8/9 默认的时间同步服务是 chronyd，对应的配置在/etc/chrony.conf。配置文件里常见的是pool或server指令，用来指定上游时间服务器。
pool 2.rhel.pool.ntp.org iburst配置完成后，重启 chronyd 并验证：
systemctl restart chronyd chronyc sources -v输出里可以看到同步源状态，^*表示当前已同步，^-表示候选但未选择，^?表示无法连接。继续查看同步精度和偏差：
chronyc tracking这一行里重点关注Leap status、Stratum和System time偏移值。如果Stratum是 15 或 16，通常意味着该机器没有正常同步到上游时间服务器。
还有一点，chrony 默认监听的 UDP 123 端口需要能被外部访问，如果配置了 firewalld，要记得放行：
firewall-cmd --permanent --add-service=ntp firewall-cmd --reload4.3 时间管理实操中的几个典型问题
我遇到过的最典型的状况是：系统明明开了set-ntp yes，但chronyc sources显示所有源都是^?。排查思路是先看上游时间服务器是否可达，用普通 UDP 连接测试不方便，可以直接在 chrony 配置里换一个更近的池地址，或者在客户端机器上抓包确认 UDP 123 是否有响应。另一个常见问题是刚部署完虚拟机，时区还是默认的 UTC，导致日志时间和本地时间差 8 个小时。修改时区之后要记得同步到硬件时钟：
timedatectl set-local-rtc 0 hwclock --systohc很多人在这一步漏掉hwclock的同步，重启之后时间又变回去了。考试里虽然不一定要求你操作硬件时钟，但理解“系统时间”和“硬件时钟”的区别是基本要求。
5. 性能调优：nice/renice 与 systemd 参数
性能调优这个模块，乍一听很高大上，RH134 前半程涉及的内容其实非常务实，核心就是进程优先级和如何把一个进程放到受限的环境中运行。
5.1 nice 值到底是什么
Linux 的进程调度器会根据进程的优先级来决定 CPU 时间片的分配。这个优先级在用户态用一个叫 nice value 的值来表达，范围是 -20 到 19。数值越小，优先级越高，越容易被调度器选中执行；数值越大，优先级越低，越“谦让”其他进程。
用生活化的类比来说，CPU 就像一个只有一个窗口的食堂打饭口，进程是排队的人。nice 值越低的人越优先插队，nice 值越高的人越靠后站着。这个“礼貌值”的名字（nice）本身就说明了一切：你对别的进程越礼貌，你的 nice 值越高。
查看进程的 nice 值：
ps -o pid,ni,comm -p <PID>启动一个进程并设置 nice 值：
nice -n -5 /usr/local/bin/performance-test注意：普通用户只能调高自己的进程 nice 值（让进程更谦让），不能调低（让进程更优先）。只有 root 用户能把 nice 值降到负数。
5.2 renice 调整运行中的进程
进程已经跑起来了，发现它占用了太多 CPU，或者需要提速，可以用 renice 调整。
renice -n 10 -p 12345这个操作把 PID 12345 的 nice 值设置为 10，让它的调度优先级变低。如果是把一个 CPU 密集型任务降权，在真实服务器上效果立竿见影，原本卡顿的其他服务会明显恢复响应。
需要强调的一点是：nice/renice 调整的是“调度优先级”，不是“CPU 配额”。也就是说，系统负载不高时，一个 nice 值高的进程照样可能跑满 CPU；只有在多个进程争抢 CPU 时，nice 值才真正发挥作用。很多人在性能调优时把这个概念搞混，以为设置了 nice 值就等于限制了 CPU 使用率，实际不是一回事。如果要做硬性限制，需要配合cgroups或者systemd的CPUQuota等机制。
5.3 systemd-run 与 systemd 服务级别的优先级控制
RH134 里比较新的考纲内容是把进程放到 systemd 管理的 scope 下运行。systemd-run这个命令允许你临时启动一个程序，并给它设置多种资源控制参数，包括 CPUWeight、MemoryMax、Nice 等。
systemd-run --unit=test-task --nice=-5 /usr/local/bin/performance-test这条命令把performance-test放到一个名为test-task的 systemd scope 中运行，并指定 nice 值为 -5。查看运行情况：
systemctl status test-task systemctl show test-task -p Nice如果这个过程需要长期作为服务运行，更标准的做法是编写 systemd unit 文件，在[Service]段里写：
[Service] ExecStart=/usr/local/bin/performance-test Nice=-5这样服务启动时就会自动以指定优先级运行，非常适合数据库、计算任务这类需要稳定调度顺序的场景。学习这个模块时，我建议把nice、renice、systemd-run三个命令放在一起练，这样你能同时理解“用户态直接调进程”和“通过 systemd 管理进程”两条路径，考试题目无论从哪个角度出都不会慌。
5.4 性能调优的验证方法
调优完之后，怎么证明生效了？我的习惯是开两个终端窗口，一个窗口用 top 实时观察进程状态，另一个窗口执行测试任务。
top在 top 输出里，NI 列就是进程的 nice 值。如果任务开始跑，NI 列的数字应该和预期一致。执行密集计算后，观察 CPU 时间在各进程之间的分配比例，也能明显感受到优先级差异带来的调度效果。验证 systemd-run 创建的 scope 时，用systemctl status test-task看进程的 CGroup 归属和资源限制。
6. SSH 免密配置：从生成密钥到故障排查完整梳理
SSH 免密是 Linux 运维里出镜率极高的需求。RH134 专门安排了这个模块，因为它是后续自动化脚本、Ansible 批量操作、集群互信的基础。没有免密，你的 cron 远程任务根本没法稳定地无人值守执行。
6.1 密钥生成与分发标准流程
免密登录的原理其实很简单：客户端生成一对密钥，公钥放到服务器的某个用户家目录下的authorized_keys文件里；后续 SSH 登录时，服务器用公钥验证客户端的私钥签名，验证通过就放行，不再询问密码。
在客户端生成密钥：
ssh-keygen -t rsa -b 4096默认会在~/.ssh/id_rsa生成私钥，~/.ssh/id_rsa.pub生成公钥。如果不希望每次登录都输入保护密码，一路回车即可。
分发公钥到目标服务器：
ssh-copy-id -i ~/.ssh/id_rsa.pub user@server这一步会要求输入目标用户的密码，输入正确后公钥就被追加到远程主机的~/.ssh/authorized_keys。免密配置完成后，测试：
ssh user@server 'hostname; uptime'这条命令如果直接返回主机名和运行时间，不提示输密码，说明免密配置成功。
6.2 权限和 SELinux 上下文
SSH 免密失败，十有八九是权限问题。OpenSSH 对关键文件和目录的权限要求非常严格，任何“过度宽松”都会导致密钥验证被拒绝。标准要求如下：
| 路径 | 要求权限 |
|---|---|
客户端~/.ssh/ | 700 |
客户端~/.ssh/id_rsa | 600 |
服务端~/.ssh/ | 700 |
服务端~/.ssh/authorized_keys | 600 |
调整权限的命令：
chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys如果是 RHEL 系统，还要考虑 SELinux 上下文。正常情况下，~/.ssh这个路径的 SELinux 类型是ssh_home_t。你手动创建或拷贝文件时，上下文可能不对，这会导致 sshd 拒绝读取 authorized_keys。修复方式：
restorecon -R -v ~/.ssh执行后再用ls -Z ~/.ssh/authorized_keys确认上下文已经恢复成unconfined_u:object_r:ssh_home_t:s0这类合法标签。
6.3 排查 SSH 免密的思路
免密登录失败时，不要只盯着 authorized_keys 反复看。我一般按下面的顺序排查：
- 先用有密码连接测试连通性：
ssh user@server能登录吗？如果密码都过不了，先解决基本网络和用户认证问题； - 用调试模式观察过程：
ssh -vvv user@server，日志会清楚显示证书认证是否被接受； - 看服务器端日志：
tail -f /var/log/secure，重点看Authentication refused或no matching key type这类关键字； - 检查服务器端
sshd_config是否显式禁用了密钥认证。RHEL 8+ 默认PubkeyAuthentication yes，但部分安全加固模板会改成 no，需要确认。
如果看到Permission denied (publickey,password)，基本可以确定是权限或者密钥内容问题。重新执行ssh-copy-id是速度最快的修复方案，因为它会自动处理权限和路径问题。
7. 实战演练：把前半程知识串成一个完整实验
上面讲了这么多模块，如果只是分别练习，记忆是不够牢固的。我强烈建议搭一个两节点的实验环境，把文章里提到的所有内容一次串起来。下面是我自己演练时完整跑过一遍的流程，可以直接照着做。
7.1 实验环境与目标
准备两台虚拟机或容器：一台作为server，一台作为client。系统用 RHEL 9 或者 Rocky Linux 9 都行，差别不大。目标如下：
- 在 server 上新增一个自定义命令
/usr/local/bin/node-info，输出主机名、IP、时间和内存使用情况； - 给 server 配置 cron 计划任务，每 5 分钟执行一次
node-info并追加写入日志文件； - 将 server 的时区设置为
Asia/Shanghai，并启用 chronyd 同步； - 启动一个 CPU 密集测试进程，通过 nice/renice 调整优先级；
- 配置 client 到 server 的 SSH 免密登录，并远程执行
node-info验证自动化链路完整。
7.2 逐步操作记录
第一步，编写自定义命令脚本：
cat > /usr/local/bin/node-info << 'EOF' #!/bin/bash echo "Hostname: $(hostname)" echo "IP: $(hostname -I)" echo "Time: $(date '+%Y-%m-%d %H:%M:%S')" echo "Memory: $(free -h | awk '/^Mem:/ {print $3 "/" $2}')" echo "---" EOF chmod +x /usr/local/bin/node-info直接执行验证：
node-info如果提示找不到命令，先确认/usr/local/bin是否在 PATH 中，或者用完整路径/usr/local/bin/node-info执行。
第二步，创建 cron 计划任务：
crontab -e添加以下内容：
PATH=/usr/local/bin:/usr/bin:/bin */5 * * * * /usr/local/bin/node-info >> /var/log/node-info.log 2>&1保存退出后验证：
crontab -l等待几分钟后查看日志文件：
cat /var/log/node-info.log如果日志为空，先执行systemctl status crond确认 crond 正常运行。
第三步，设置时区和时间同步：
timedatectl set-timezone Asia/Shanghai timedatectl set-ntp yes systemctl restart chronyd chronyc sources -v输出里出现^*后，再执行chronyc tracking，看 Leap status 是否为 Normal。
第四步，进程性能调优。在 server 上启动一个计算任务：
systemd-run --unit=demo-task --nice=-10 sh -c 'while true; do echo "running"; sleep 2; done'查看状态：
systemctl status demo-task systemctl show demo-task -p Nice能看到Nice=-10说明配置生效。不需要这个任务时，停止它：
systemctl stop demo-task第五步，SSH 免密。在 client 上生成密钥并复制到 server：
ssh-keygen -t rsa -b 4096 -N '' ssh-copy-id -i ~/.ssh/id_rsa.pub root@server测试免密登录并远程执行自定义命令：
ssh root@server '/usr/local/bin/node-info'返回 server 的完整系统信息后，再配合 cron 任务想想看：如果这个命令被写进别的 server 的 crontab 里，是不是就能实现多台机器定时远程收集状态？这就是 RH134 前半程所有模块联动起来后真实能做的事。
8. 常见问题与避坑速查表
最后把这几个模块里我实际踩过、以及在辅导别人时看到的高频问题统一整理成一个速查表。每一条都是真实场景里发生过的，不是从手册里抄来的。
| 问题 | 典型现象 | 排查思路 | 处理方案 |
|---|---|---|---|
| cron 任务未执行 | 时间到了没有产生任何日志 | 检查 crond 是否运行；查看/var/log/cron；确认 crontab 语法正确 | systemctl status crond；查看日志中的实际执行记录；脚本内命令改用绝对路径 |
cron 中命令包含%报错 | 日志显示参数被截断 | %被 cron 当成了换行符 | 写成\% |
| 时区修改后重启失效 | 重启后 time 又变回 UTC | 系统硬件时钟没有同步 | hwclock --systohc |
| chrony 无法同步 | chronyc sources全是^? | 上游服务器不可达；防火墙拦截 UDP 123；配置的 pool 地址错误 | 更换 pool；放行firewall-cmd --add-service=ntp；检查网络连通性 |
| 设置 nice 后感觉无变化 | 高负载时目标进程还是占用大量 CPU | nice 只在资源争抢时影响调度，不限制 CPU 配额 | 明确调整目标；如果需要硬性限制，配合 systemd CPUQuota |
| ssh 免密失败 | 登录时仍提示输入密码 | 权限不正确；SELinux 上下文错误；sshd_config 中禁用了密钥认证 | 检查~/.ssh权限为 700、authorized_keys为 600；执行restorecon -R -v ~/.ssh；查看/var/log/secure |
| 自定义命令找不到 | 输入脚本名提示 command not found | 脚本目录不在 PATH 中；脚本没有执行权限 | 移入/usr/local/bin后chmod +x；或把目录加入用户的.bashrc |
这之中我最想再强调一次的是 cron 环境变量问题。现实中很多任务“不执行”的真相，并不是 cron 没运行，而是脚本里用的命令在 cron 的精简 PATH 里找不到，导致执行时报错但用户没收到邮件也没看日志。养成在 crontab 顶部声明 PATH、在脚本里用绝对路径的习惯之后，这类问题能减少八成。
RH134 前半程的这些内容，单独挑任何一块出来都不难。但组合在一起，它就构成了一套自动化运维的基础能力：你自己定义一个可执行的命令，让系统按计划去跑它，保证系统时间正确，调整进程优先级避免资源争抢，再用 SSH 免密把远程操作串起来。这种能力不是背几条命令就能建立的，需要多动手搭环境、多故意制造故障去排查。我自己学这部分的最大体会是：红帽考试看重“结果正确”，但生产环境更看重“结果可重复、可排查”。沿着这个思路去练习，RH134 学完的效果会远比一张证书本身值钱。
