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是emerg1是alert2是crit3是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。第一步创建PVpvcreate /dev/sdb第二步创建VGvgcreate vg_data /dev/sdb第三步创建LVlvcreate -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里加一行UUIDxxxx-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里最容易被坑的点之一考试中也偶尔会出逻辑题考察这个知识点。另外再提一个PEPhysical Extent相关的细节。创建VG时可以指定PE大小默认是4MB。PE大小实际上决定了LV空间分配的最小粒度。比如LV要分配500MB如果PE是4MB实际占用是500/4125个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 21看到报错内容再做针对性修改。这个习惯能省很多排查时间。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看看哪些文件发生了变更能帮你快速定位是不是有人改错了文件。把这些常见错误提前排掉实验和考试的成功率会提升很多。这些教训都是真金白银换来的每一句都值得多看两遍。