1. 网络配置：把nmcli当成唯一出路

1.1 别再直接改配置文件了，原因都在这里

RH134学到后半程，网络配置的考察方式会和很多人的旧习惯产生冲突。系统里默认跑着NetworkManager服务，所有网卡连接都由它统一接管。这时候如果你还按以前的习惯，直接vi /etc/sysconfig/network-scripts/ifcfg-ens160，改完再重启network服务，大概率会遇到两种情况：要么文件被NetworkManager的缓存覆盖，要么连接状态变得不可控。

我早期实验的时候吃过这个亏。手动改完ifcfg文件，ip addr show看地址没变，以为没生效，于是又执行了一次systemctl restart NetworkManager，结果网络直接断掉，最后只能通过控制台重新配置。原因是NetworkManager在运行期间维护着一套内存里的连接配置，它不监听外部对配置文件的修改，但只要检测到连接状态变化，就可能用自己的缓存把文件覆盖回去。这种"双写"问题在RH134的考试里也很常见，很多考生改了文件后忘了执行nmcli connection reload，重启后配置丢失，白丢分。

最稳的做法就是统一用nmcli操作。它相当于通过正规通道通知NetworkManager做什么，配置写入、连接重建、生效确认是一气呵成的，不存在两套配置打架的问题。RH134课程里明确要求掌握nmcli的常用子命令，考试环境也完全围绕这套体系来出题。所以我的建议是：优先把nmcli用熟，配置文件只需要理解原理，不必作为主要操作手段。

1.2 静态IP配置的完整命令演示

nmcli connection add con-name ens160 type ethernet ifname ens160 \ ipv4.addresses 192.168.1.10/24 \ ipv4.gateway 192.168.1.1 \ ipv4.dns 8.8.8.8 \ ipv4.method manual \ connection.autoconnect yes nmcli connection up ens160

这是一套最常见的静态配置场景。拆开看几个容易出错的点。

con-name是连接的逻辑名称，ifname是实际网卡接口名，两者可以相同也可以不同。初学者经常把这两个搞混，结果创建了连接却没绑到正确的网卡上。ipv4.method必须显式设为manual，否则即使提供了addresses，系统也可能会因为默认的DHCP策略导致地址不生效。connection.autoconnect yes一定不能漏，否则重启后连接不会自动激活，考试里考察的就是重启之后的验证。

配置完成后，用ip addr show ens160确认地址已经加上，用ip route show确认默认路由正常。如果发现网关没生效，先ping一下网关IP，确认二层链路没问题，再检查network配置里网关是否有冲突。

还有一个实操细节：改完网络后不要急着重启。先执行nmcli connection reload，再执行nmcli connection up，确认一切正常后再重启系统。这样能把排查范围控制在网络层，避免每次改动都影响当前会话。如果是在远程连接的机器上操作，这一步尤其重要，配置错了还不至于把自己锁在门外。

2. 系统日志：journald的正确使用方式

2.1 日志持久化，99%的人会踩一次的坑

RH134的日志管理围绕journald展开。默认情况下journald把日志写在内存里，意味着系统正常运行时可以用journalctl查所有历史，但一旦重启，之前的日志记录可能会丢失。很多人第一次踩坑就是"重启一下系统，准备翻日志排查问题，发现什么都没了"。

解决办法是在/etc之前创建/var/log/journal目录并设置好权限。journald在每次启动时会检查这个目录是否存在，存在就自动走持久化路径，不存在就继续用内存临时存储。这个细节在红帽的官方文档里有明确说明，但考试环境不一定帮你预设好，所以提前建好是稳妥做法。

顺手验证一下：执行journalctl --disk-usage可以查看当前日志占用空间。只有做了持久化，这个目录才会持续增长，否则数值会和在临时目录状态下不同。

另外一个常见问题：journald默认按UTC显示时间。如果你把系统时区设置成了Asia/Shanghai，但日志时间还是UTC，排查问题时会产生很大的时间偏差错觉。建议先执行timedatectl status确认时区，必要时timedatectl set-timezone Asia/Shanghai。这算日志系统的使用细节，但实际排查时能省掉很多自我怀疑。

2.2 查日志，先记住这几种组合套路

我平时排查问题时，journalctl基本只用三种组合，覆盖绝大多数场景。

第一种，按服务看。journalctl -u sshd -n 50，只看sshd服务最近50行日志。适合确认服务启动、重启、登录失败等事件。

第二种，按时间过滤。journalctl --since "3 hours ago"，或者journalctl --since "2025-01-01 00:00:00" --until "2025-01-01 12:00:00"。适合配合故障发生时间去定位当时的日志。

第三种，按优先级过滤。journalctl -p err，只看err及以上级别。优先级可以用数字表示：0是emerg，1是alert，2是crit，3是err。

优先级过滤经常配合服务筛选，比如journalctl -p err -u sshd，一条命令定位SSH服务最近的错误记录。还有一点值得说：默认的short格式在日志条目很长时很难读，换成journalctl -o short-iso可以获得完整时间戳，日志对齐其他监控系统时更省事。

再提一个关于启动周期的常用参数。journalctl -b表示当前这次启动的所有日志，journalctl -b -1表示上一次启动的。如果做了持久化，这些历史记录会一直在，排查"上次开机为什么失败"这个问题时，-b -1是非常好用的切入点。

3. 本地存储：LVM从新盘到挂载，五步走

3.1 PV、VG、LV三个概念，用仓库理解最舒服

LVM对初学者最大的门槛是抽象层次太多。PV、VG、LV这三个词，单看英文缩写很容易记混。我习惯用仓库的比喻来理解：PV相当于一块块独立的砖头，VG是装满砖头的仓库，LV是从仓库里取砖头砌成的房间。仓库可以随时加砖头，房间的大小也可以根据需要在仓库里调整。

对应到命令上：pvcreate把物理磁盘初始化为物理卷，vgcreate把多个PV组成一个卷组，lvcreate在VG里划出逻辑卷。上层文件系统不再直接依赖物理磁盘的大小和数量，扩容时只要往VG里加新PV，或者用VG空闲空间给LV扩容就行。

从工程实践角度看，数据库、文件服务器这类对扩容有刚需的场景，LVM几乎是标准方案。RH134对LVM的要求不高，能完成从创建到挂载的全流程，并且会做在线扩容就够了。

3.2 一张新盘完整操作记录

假设系统里新加了一块/dev/sdb，目标是建一个500MB的逻辑卷，格式化成xfs，挂载到/data。

第一步，创建PV：

pvcreate /dev/sdb

第二步，创建VG：

vgcreate vg_data /dev/sdb

第三步，创建LV：

lvcreate -n lv_data -L 500M vg_data

第四步，格式化。这里要先确认LV的设备路径。一般在/dev/vg_data/lv_data下，执行lvs列出所有逻辑卷，再用vgdisplay确认大小，不要凭记忆输路径。

mkfs.xfs /dev/vg_data/lv_data

第五步，挂载并配置开机自动挂载。先mkdir /data，然后mount /dev/vg_data/lv_data /data。写到/etc/fstab时建议用UUID而不是设备路径，因为在多盘或多路径环境里，设备名可能会漂移，UUID是唯一稳定的标识。

用blkid查询UUID后，在/etc/fstab里加一行：

UUID=xxxx-xxxx /data xfs defaults 0 0

写完fstab后一定要执行mount -a验证一次。这个命令会按fstab内容重新挂载所有条目，如果有语法错误或UUID错误，它会当场报错，不至于等到重启才发现问题。这个习惯能有效避免那种"fstab写错导致系统进入救援模式"的惨剧。

3.3 扩容与缩减：记住"xfs只能扩不能缩"

扩容逻辑卷是RH134的重点。顺序是：先扩展LV，再扩展文件系统。

lvextend -L +200M /dev/vg_data/lv_data xfs_growfs /data

扩展顺序很重要，先lv后文件系统。xfs用xfs_growfs命令，它直接用挂载点作为参数，不需要写设备路径。这一点和ext4的resize2fs不一样，我见过不少人把两个命令的用法搞混，导致"设备忙"或者命令不识别。

而缩减就麻烦了。xfs文件系统不支持在线缩容。如果实际工作中遇到需要缩小逻辑卷的场景，常见绕法是把数据备份出来、重新创建更小文件系统、再把数据拷回去。ext4可以用resize2fs先缩小文件系统再lvreduce缩小LV，但xfs只能扩不能缩，这是RH134里最容易被坑的点之一，考试中也偶尔会出逻辑题考察这个知识点。

另外再提一个PE（Physical Extent）相关的细节。创建VG时可以指定PE大小，默认是4MB。PE大小实际上决定了LV空间分配的最小粒度。比如LV要分配500MB，如果PE是4MB，实际占用是500/4=125个PE，整数完全OK。但如果你把PE设成8MB，而VG剩余空间只有124个PE，分配时就会产生一点偏差。考试不要求掌握这个计算，理解概念即可。

4. 容器管理：podman从零到跑通

4.1 podman和docker的三个本质区别

RH134在较新版本里加入了容器内容，核心工具是podman。很多人从docker切到podman时，会发现命令几乎一样，能无缝上手。但有几个本质区别需要理解。

第一，podman是daemonless架构。没有常驻后台守护进程，容器由podman直接作为子进程运行。这意味着没有Docker服务需要管理，也没有因守护进程崩溃导致所有容器挂掉的风险。

第二，rootless是默认模式。普通用户不需要额外配置就能运行容器。但这也带出权限边界问题：如果想把容器端口映射到宿主机的80端口，普通用户因为权限限制通常会失败；映射到8080这类高位端口则没有问题。

第三，podman和SELinux结合得更紧密。容器挂载宿主机目录时，需要处理SELinux标签，否则会遇到权限拒绝问题。这一点在Red Hat系Linux上尤其明显。

RH134阶段只需要掌握：搜索镜像、拉取镜像、运行容器、映射端口、挂载卷、查看日志、停止删除容器这些操作。

4.2 用nginx跑通一个完整示例

直接以nginx为例。拉取并启动一个容器，把宿主机的8080端口映射到容器内的80端口，同时挂载一个本地目录作为站点目录：

podman pull docker.io/library/nginx:latest podman run -d --name web -p 8080:80 -v /webdata:/usr/share/nginx/html:Z docker.io/library/nginx:latest

这里有一个必须讲清楚的点：-v参数后面的:Z会把宿主机挂载目录的SELinux标签调整为container_file_t，让容器内的进程可以读取这个目录。如果不加:Z，在SELinux启用的系统上，nginx容器会无法读取挂载目录里的文件，浏览器访问时返回403。很多人宿主机测试一切正常，换到SELinux环境就翻车，多数就是这里漏了。

验证运行状态用podman ps，查看日志用podman logs -f web。进入容器调试用podman exec -it web /bin/bash。清理容器时先podman stop web，再podman rm web。如果确定不要了，也可以直接podman rm -f web一步到位。

容器在重启后默认不会自动恢复。实际生产环境里需要让容器随开机启动，较新版本的podman已经支持quadlet语法，在/etc/containers/systemd/目录下写容器单元定义，由systemd统一管理。考试阶段不一定会到这个深度，先把podman自身的命令操作练熟更实际。

5. 定时任务：cron与systemd timer怎么选

5.1 crontab五分钟搞定，环境变量是最大的坑

RH134要求掌握cron定时任务。crontab -e为当前用户编辑定时任务，格式是五个时间字段加命令：

分钟 小时 日期 月份 星期 命令

例如每天凌晨2点30分执行备份脚本：

30 2 * * * /usr/local/bin/backup.sh

其中最容易被忽视的是环境变量问题。cron执行命令时不会自动加载用户shell的环境变量，PATH基本只有/sbin:/bin:/usr/sbin:/usr/bin。如果你在脚本里调用了/usr/local/bin下的程序，脚本可能因为找不到命令而失败。解决办法很简单：脚本开头显式export PATH，或者在crontab里直接写命令的绝对路径。

另一个经验是：cron里执行命令和交互式shell执行结果不一样，因为会话环境不完整。例如脚本依赖HOME变量来定位配置文件，用crontab执行时可能会找不到。调试时建议先把输出重定向到日志文件：

30 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

看到报错内容再做针对性修改。这个习惯能省很多排查时间。

5.2 anacron解决"关机错过执行"的问题

普通cron适合那些长期开机的服务器。如果设备经常在凌晨关机，cron任务可能会错过执行窗口。此时可以用anacron，它不会精确到分钟，但会确保错过执行的作业在下次开机时补跑。RH134会提到这个工具，考试里也可能会给一个"系统关机后补执行任务"的场景。

另一个替代方案是systemd timer。它在灵活性和可管理性上优于cron，可以配置精确执行时间、随机延迟、依赖关系等。优点是与系统日志统一，可以查看每一步执行状态；缺点是语法较复杂，需要同时维护service和timer两个unit文件，对不熟悉systemd的人来说上手成本高。

实战建议：考试阶段先掌握crontab，因为它是RHCSA/RH134的标准考点。真正到了生产环境，如果需要精确时间点和严格依赖管理，优先考虑systemd timer——它更符合现代Linux系统管理的思路。

6. 避坑指南：这些错误我当年都犯过

6.1 重启验证是底线的底线

RH134考试里，验证环节的权重很高。配置完一个服务后，系统重启不代表服务一定可用。比如网络连接设了静态IP但忘了autoconnect，重启后IP就丢了；fstab写错了，重启直接进救援模式。

所以我的习惯是：每个配置做完之后，至少做一次重启验证。别嫌麻烦，这是最有效的防翻车手段。在实际考试环境里，配置完系统重启后全部失效的案例太多了。

如果你在虚拟机上练习，做重要操作前先拍快照。这样即使把网络改废了、把系统搞进救援模式，也能快速回滚，不耽误练习进度。虚拟机的快照功能就是这个场景最核心的价值。

6.2 SELinux是那个"隐形杀手"

很多人在RH134上莫名其妙丢分，问题都出在SELinux。比如httpd的默认网页目录换了内容，但SELinux策略不允许httpd读取某些目录，网页就是403。或者练习时临时把SELinux设成了permissive，配置完忘了恢复enforcing，最后操作结果和enforcing模式下完全不同。

学习阶段建议不要图省事直接setenforce 0，而是学会用semanage和restorecon调整上下文。容器挂载卷加:Z是最轻量方案；Web服务自定义目录时，需要保证目录的SELinux类型是httpd_sys_content_t。遇到SELinux相关的访问异常时，用ausearch -m avc -ts recent看一眼审计日志，能直接告诉你哪一步被拒绝了。

只要理解SELinux的"类型强制"逻辑，这类问题大多是几分钟的事；直接无视SELinux，你就会在各种不起眼的地方反复栽跟头。

6.3 日志时间和时区，细节决定排查效率

前面提过journald默认用UTC显示日志。如果你把系统时区设置成了Asia/Shanghai，但日志仍是UTC时间，排查问题时会产生很大的时间偏差。尤其涉及跨时区系统时，更应先确认timedatectl的时间显示是否和预期一致。

另一个相关点：RH134考试环境里，时区设置重启后有时不保留，确认一下系统配置是否正确。修改时区时，理想方式是通过timedatectl set-timezone完成，而不是自己去改/etc/localtime的软链接，否则可能出现软链接指向错误或配置不完整的问题。

6.4 密码、权限、账户：别乱动特殊文件

我见过有人为了方便，把/etc/passwd、/etc/shadow的权限改成777，或者手工改UID和GID，结果系统无法启动或用户无法登录。这类问题属于低级错误，但实际工作中偶尔也能看到。

基础原则是：能用命令完成的操作，不要手动改配置文件。改用户属性用usermod，改密码策略用chage，改权限用chown/chmod，并且要理解setuid、setgid、sticky位的作用。只有理解这些机制，遇到异常时才能从原理上排查。

还有一个实用的完整性检查方法：rpm -V可以验证软件包文件是否被修改。如果系统莫名其妙出问题，跑一下rpm -V package-name，看看哪些文件发生了变更，能帮你快速定位是不是有人改错了文件。

把这些常见错误提前排掉，实验和考试的成功率会提升很多。这些教训都是真金白银换来的，每一句都值得多看两遍。