培训课里最常被问到的一句话是：RH134到底要掌握到什么程度？我自己的答案是：能徒手修好一台开机卡住的系统、能不多不少地给服务放通SELinux权限、能十分钟起一个容器并且让它以服务方式开机自启，就算过关。这篇是《RH134总结》的第四篇，也是整个系列里内容密度最大的一篇，把后半程的启动排错、内核参数、日志审计、SELinux、网络聚合、Podman容器和Ansible基础全部收进来，一次性讲透。
如果你是从第一篇一路跟过来的，前面应该已经把用户权限、硬盘存储、LVM、systemd服务管理这些硬骨头啃得差不多了。没有跟过前文也没关系，这篇里的每一块知识都是相对独立的，你完全可以当作一份RH134后半程的复习手册来用。准备一个干净的RHEL 9虚拟机，跟着命令敲一遍，比看十遍教程都管用。
1. 第四篇覆盖什么：先给后半程画个地图
1.1 前三篇做了什么
先说清楚这个系列走到了哪一步。RH134是Red Hat System Administration II，官方定位是给已经了解基础的运维人员进阶。前三篇我拆的是常规运维动作：用户和权限、文件系统与LVM管理、systemd服务单元和计划任务。这些内容的特点是“日常用得多、考得细”，属于必须形成肌肉记忆的部分。
但RH134真正的分水岭在系统后半程。前面那些知识，熟练了只是“会用Linux”，后面这些内容，掌握了才是“能维护一台正在出问题的Linux”。两者在面试和考试里的差距非常大。
1.2 第四篇的几个硬骨头
第四篇选的模块都有一个共同特征：默认情况下你是看不到效果的，需要你主动去配置、主动去排错。
- 启动流程和故障恢复：大部分教材把这部分放在最后，但恰恰是生产环境最救命的能力。
- 日志与时间同步：不会看日志，后面SELinux和网络排错等于没眼睛。
- SELinux：红帽认证和真实生产环境的“分水岭”，关掉SELinux容易，但要放通权限并且不开全局开关，需要一套方法论。
- 网络聚合和防火墙：涉及nmcli、firewalld的联动，很容易踩顺序坑。
- Podman容器：RH134后半程的明星内容，考试必考，但题型和普通Docker习惯有不少差异。
- Ansible入门：RHCE考试的核心工具，RH134阶段先建立自动化思维。
这六大块今天一次讲完。每块我都按“原理、实操、避坑”的顺序来，尽量让你看完就能上手。
2. 启动流程与故障恢复：从“进不了系统”到“一分钟自救”
2.1 GRUB2启动与内核参数
很多学Linux的人对启动流程是模糊的：开机键按下去，屏幕一亮，就进了登录界面。但生产环境服务器出现开机卡死、进入emergency mode、甚至grub>提示符时，不懂启动流程的人只能重装系统。
RHEL 9用的引导器是GRUB2，完整的启动链路大致是：
BIOS/UEFI自检 -> 从磁盘读取GRUB2引导程序 -> GRUB2加载vmlinuz内核文件和initramfs镜像 -> 内核初始化硬件 -> systemd作为第一个进程接管系统
这条链路上最常出问题的环节是GRUB2配置和内核参数。考试和实操中你最好记住这几个文件的位置：
- /boot/grub2/grub.cfg：GRUB2菜单配置文件，一般由grub2-mkconfig命令根据/etc/default/grub自动生成，不要手工改这个文件。
- /etc/default/grub：grub2-mkconfig读取的源配置，改这里的参数再重新生成grub.cfg才是正确姿势。
- /proc/cmdline：查看当前内核启动参数的最直接途径。
修改内核启动参数最有用的命令是grubby。很多教程让你去改grub.conf，但在RHEL 8/9上grubby才是红帽官方推荐的工具。
比如当前系统是图形界面启动，想临时在下次启动时加上文本串行日志输出，可以这样操作：
grubby --update-kernel=ALL --args="console=ttyS0"如果某次实验加的参数导致系统起不来，不需要去手动编辑grub.cfg，直接删除：
grubby --update-kernel=ALL --remove-args="console=ttyS0"注意：grubby默认改的是当前内核，如果系统里有多个内核，建议显式指定ALL来保证所有内核配置一致，否则下一次重启选到旧内核时问题复现，你会误以为配置没生效。
2.2 重置root密码与救援模式
忘了root密码是运维最常见的“社死”场景。在RHEL 9上，如果你能物理接触到服务器或者能通过管理台进入开机菜单，重置密码只需要三步。
第一步，重启系统，在GRUB2菜单界面停留时按键盘e键，进入编辑模式。第二步，找到以linux开头的那一行，在末尾追加一个参数：
rd.break这个参数的意思是：在根文件系统切换到真实环境之前，打断启动流程，进入一个带initramfs的紧急shell。第三步，按Ctrl+x启动，你会掉进一个shell提示符，但此时根目录还是只读的临时状态，需要手动重新挂载：
mount -o remount,rw /sysroot chroot /sysroot passwd root这里有两个极其重要的细节。第一，修改完密码后不要直接执行reboot，而是输入exit退出chroot，再输入exit退出初始shell，让系统继续完成SELinux重标记和后续启动流程。第二，如果你在chroot里做了其他文件改动，建议创建一个.autorelabel标记文件，让系统启动时自动修复文件安全上下文：
touch /.autorelabel否则很容易出现密码改完、系统重启后SELinux阻止登录，又是一轮新的排查。
如果系统连GRUB菜单都进不去了，也不要急着重装，用安装光盘或U盘启动，在Troubleshooting菜单里选Rescue a Red Hat Enterprise Linux system，进入救援模式后把原系统挂载到/mnt/sysimage，同样chroot进去修复即可。
2.3 内核参数与tuned调优
内核参数分两大类：启动时通过GRUB传入的kernel参数，以及运行时可修改的sysctl参数。RH134阶段不需要背几十个内核参数，但你必须知道在哪里查、怎么改、改完要不要重启。
运行时查看和修改sysctl参数的命令是sysctl。比如加大文件句柄限制：
sysctl -w fs.file-max=65535 echo 'fs.file-max=65535' >> /etc/sysctl.conf sysctl -p第一行立即生效，第二行写入配置文件，第三行重新加载全部配置。注意，sysctl -w是运行时生效，重启后丢失，只有写进/etc/sysctl.conf或/etc/sysctl.d/xx.conf才是永久生效。
tuned是红帽自带的系统调优工具，它通过不同的profile来适配不同场景。刚装完系统时很多人发现虚拟机跑得不够快，第一反应是调内核参数，其实先看一眼tuned更合理：
tuned-adm active tuned-adm recommend在我的虚拟机实验环境里，虚拟化平台上recommend的profile通常是virtual-guest，它已经针对KVM做了优化。如果是物理服务器做文件服务器，可以切换成throughput-performance，最大化吞吐量：
tuned-adm profile throughput-performance切换之后可以立刻对比一下大文件复制速度，实测在机械硬盘环境下吞吐量有可见提升。不要把tuned想得很复杂，它就是红帽帮你包好的一系列内核参数组合，你只需要选对场景。
3. 日志与时间同步：让系统“开口说话”
3.1 journald和rsyslog两套通道
很多新手分不清systemd-journald和rsyslog的关系，这里用一句话总结：journald是systemd大家庭的日志收集器，负责收集二进制日志；rsyslog是传统文本日志的守门员，把日志写入/var/log/下的文本文件。两者在RHEL默认同时运行，互相配合但不互相替代。
journald收集的日志是二进制的，存储在内存环形缓冲区里，重启就没了。如果你想把日志持久化到磁盘，需要手动创建目录：
mkdir -p /var/log/journal systemd-tmpfiles --create --prefix /var/log/journal第一条命令创建持久化目录，第二条命令让systemd按tmpfiles.d规范重新生成该目录的属性和权限。做完之后重启systemd-journald或重启系统，日志就能持久保留了。
rsyslog这边则比较简单，核心配置文件是/etc/rsyslog.conf，RHEL默认会把大部分日志写入/var/log/messages，认证相关日志写入/var/log/secure。排错时这两个文件优先级最高。
3.2 journalctl高级用法
journalctl是查看journald日志的客户端工具，它的优势是过滤条件非常灵活。刚开始接触时你可能会觉得一堆选项记不住，我建议先记住这五个最常用的：
journalctl -b # 查看本次启动以来的日志 journalctl -p err # 只看错误级别及以上的日志 journalctl -u sshd # 只看sshd服务相关日志 journalctl --since "1 hour ago" # 只看最近一小时 journalctl -f # 实时跟踪，类似tail -f实际排错中这五个条件经常组合使用。比如排查sshd服务为什么没起来：
journalctl -u sshd --since today -p err一次拿到今天所有sshd的错误日志，比在/var/log/secure里翻半天效率高得多。
避坑提醒：journalctl默认显示的时间是UTC或者系统时区，如果你在中国时区（CST），建议在命令里加上--utc看看是否时区问题，或者直接确认系统时区是否配置正确。我踩过一次时间显示“差8小时”的坑，最后发现是chrony服务没起来，系统时间一直停在UTC。
3.3 chrony时间同步
RH134的时间同步模块讲的是chrony，不是老的ntpd。chrony的优势是对频繁断网、网络抖动的环境适应性更好，而且同步速度更快。
配置文件是/etc/chrony.conf，关键配置是NTP服务器地址。生产环境通常用公司内部的NTP服务器，实验环境可以直接用公网池：
pool 2.centos.pool.ntp.org iburst配置完重启服务并检查同步状态：
systemctl restart chronyd chronyc sources -v输出里的^*说明当前已经同步，^?说明还在寻找可用源。如果一直处于^?状态，多半是网络不通，先ping一下NTP服务器地址。
时间同步在RH134里看似简单，但考试喜欢把它和日志时间关联起来考。日志时间对不上、证书验证失败、Kerberos认证失败，根子经常都是时间漂移。
4. SELinux排错：从永久关闭到精准放行
4.1 模式理解
SELinux是RH134里劝退率最高的一块，因为它的概念抽象、报错信息晦涩。但如果你能记住一个核心模型，整块知识点就通了。
SELinux有三大模式：Enforcing（强制）、Permissive（宽容）、Disabled（关闭）。 强制模式下违规操作会被直接拒绝；宽容模式下违规操作会被记录下来但不会拒绝；关闭模式就是完全关闭检查。
查看和临时切换模式的命令：
getenforce setenforce 0这里的0就是Permissive，1就是Enforcing。这个切换是临时的，重启后失效。永久修改要编辑/etc/selinux/config：
SELINUX=enforcing重要的一点是：从Disabled切到Enforcing需要重启系统，因为SELinux需要重新标记整个文件系统。这也是很多人改了配置后开机卡住的原因。另外强烈不建议在生产环境使用Disabled模式，考试更不能出现。
4.2 avc日志排错闭环
SELinux排错的核心线索是AVC日志。当一个进程被SELinux拦截，审计日志里会记录一条类似这样的信息：
type=AVC msg=audit(...): avc: denied { name_connect } for pid=12345 comm="nginx" dest=8080 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:default_t:s0 tclass=tcp_socket这条日志翻译成人话是：nginx进程（域httpd_t）想连接8080端口，但SELinux认为这个域没有权限连接类型为default_t的端口资源。
拿到这类日志后的完整排查闭环是：
第一步，用ausearch从审计日志里查出最近的相关事件：
ausearch -m AVC -ts recent第二步，如果你装了setroubleshoot工具，可以直接看它对问题的解读：
sealert -a /var/log/audit/audit.log第三步，根据提示做精准放行。这里最忌讳的操作是把SELinux直接setenforce 0，你应该做的是告诉SELinux：这个域访问这个资源是被允许的。
正确的处理方式通常涉及端口类型、文件标签和布尔值，下面两小节分别讲。
4.3 文件标签与端口放行
SELinux给文件系统里的每个文件都打了一个安全上下文标签，用ls -Z可以查看：
ls -Z /var/www/html/index.html输出中的httpd_sys_content_t就是文件标签。如果你把网站目录从/var/www/html换到了自定义路径/app/web，需要手动让SELinux知道这个目录应该是什么类型：
semanage fcontext -a -t httpd_sys_content_t "/app/web(/.*)?" restorecon -Rv /app/web第一句是给目录添加默认标签规则，第二句是让已存在的文件立刻应用新规则。很多新手只做了chown和chmod，忘了restorecon，结果nginx一直报403。
端口放行是另一类常见需求。比如nginx监听8080端口，默认情况下httpd_t域只能访问80、443等预设端口。需要显式添加：
semanage port -a -t http_port_t -p tcp 8080添加完后用semanage port -l | grep http确认规则生效。如果只想临时验证一下“问题到底是不是SELinux”，再考虑setenforce 0。
4.4 布尔值
布尔值是SELinux里最实用的开关，它允许你在不重新打标签的情况下调整部分策略。查看某一类服务的布尔值：
semanage boolean -l | grep httpd比如你想让httpd服务能够向外访问网络（代理、调用API等场景），开启httpd_can_network_connect：
setsebool -P httpd_can_network_connect on-P参数表示永久生效，不带-P的话重启后就会恢复。考试时如果题目没说“永久”，一般也不扣分，但生产环境建议一律加-P。
个人心得：SELinux排错最快的思路是“三分法”。先确认进程域有没有问题（布尔值），再确认端口类型有没有问题（semanage port），最后确认文件标签有没有问题（semanage fcontext）。按这个顺序查AVC日志，基本能在五分钟内定位问题。
5. 网络管理：bond链路聚合与防火墙联动
5.1 team和bond怎么选
RHEL同时支持bond和team两种链路聚合方案。bond是传统内核模块，team是由teamd进程管理的用户态方案。RHEL 9里红帽逐渐把重心放到bond上，但考试时两种都可能出现。
这里优先掌握bond，因为它更通用。目标是给一个服务器配置两个网卡聚合，增加带宽和冗余。用nmcli操作：
nmcli con add type bond ifname bond0 mode active-backup nmcli con add type ethernet ifname ens3 master bond0 nmcli con add type ethernet ifname ens4 master bond0 nmcli con up bond0第一行创建bond连接，模式是active-backup（主备模式，同一时刻只有一块网卡工作）。后面两行是把两块物理网卡加入bond的从属连接。这个顺序不能反，必须先有bond设备，才能加从属网卡。
验证聚合状态：
cat /proc/net/bonding/bond0主要看MII Status和Slave Interface段。如果显示up，说明聚合成功。
模式选择上，active-backup适合对可用性要求高的环境，round-robin适合需要榨干带宽的场景。考试一般考active-backup，因为它最能体现“冗余”这个核心诉求。
5.2 firewalld规则
防火墙是网络管理的另一块。RHEL默认是firewalld，它对外提供firewall-cmd命令。核心概念是zone（区域）和service（服务）。
日常操作最常用的命令也就这几个：
firewall-cmd --state # 查看运行状态 firewall-cmd --get-default-zone # 当前默认区域 firewall-cmd --add-service=http # 临时放行http firewall-cmd --permanent --add-service=http # 永久放行http firewall-cmd --reload # 重载使永久规则生效注意区分带不带--permanent。不带是立即生效但重启失效，带--permanent是写入配置文件但必须reload。最常见的坑是：加了永久规则忘了reload，以为配置坏了；或者不加permanent直接重启，规则全丢了。
如果你要放行自定义端口而不是标准服务，使用port命令：
firewall-cmd --permanent --add-port=8080/tcp5.3 网络排查命令串联
RH134的网络排错题，最烦人的是“只能ping通网关但不能ssh”。我建议按这个顺序排查：
第一步，确认IP配置是否正确：
ip addr show第二步，检查路由是否正确：
ip route show第三步，检查监听端口：
ss -tlnp | grep 22第四步，检查防火墙：
firewall-cmd --list-all第五步，检查SELinux是否拦截。一般到这里都能定位问题。跨VLAN不通优先查路由，端口通但连接被重置优先查防火墙，连接超时优先查SELinux。
6. Podman容器：从拉镜像到生成systemd服务
6.1 核心差异与安装
RH134的容器部分用的是Podman，不是Docker。两者命令格式非常相似，但底层实现有本质差异。Docker需要后台守护进程才能运行，Podman则是无守护进程架构，每个容器直接由Podman进程管理。
这意味着什么？意味着普通用户不需要sudo也能运行容器，意味着系统重启后容器不会被某个daemon自动拉起来（需要额外配置），也意味着Podman的安全隔离方式比Docker多了一层保障。
安装很简单：
dnf install -y container-tools这个包组会同时安装podman、skopeo、buildah等全套容器工具。安装好后先验证：
podman info6.2 运行与生命周期管理
Podman的命令和Docker几乎可以无缝迁移。跑一个nginx容器并做端口映射：
podman run -d --name web -p 8080:80 nginx查看容器状态：
podman ps -a podman logs web podman exec -it web bash停止和删除容器：
podman stop web podman rm web关键点是理解-p 8080:80的含义：宿主机8080端口映射到容器内80端口。考试时经常会把宿主机端口和容器端口写反，一定要严格按“宿主机:容器”的顺序记。
另一个容易忽略的是容器镜像。Podman默认从Docker Hub拉取镜像，可以用podman search先确认镜像名：
podman search nginx如果镜像拉不下来或特别慢，检查一下是不是网络或镜像源的问题。生产环境一般会配置企业内部的registry源。
6.3 systemd集成：让容器开机自启
这是Podman实操里最有价值的内容，也是考试里容易失分的点。前面说了Podman没有守护进程，所以容器不会自动开机启动，需要手动生成systemd服务。
生成服务单元的标准做法是：
podman generate systemd --new --name web这条命令会输出一个完整的systemd service单元文件。--new参数很关键，它表示这个服务每次启动时都会创建一个新容器，停止时删除旧容器。重定向到服务文件：
podman generate systemd --new --name web > /etc/systemd/system/web-container.service systemctl daemon-reload systemctl enable --now web-container.service这里有个坑：普通用户生成的容器，如果用root身份去生成systemd服务，可能导致容器路径和权限有问题。最好保持同一个用户身份。如果用的是普通用户，需要让systemd以用户服务的方式启动：
systemctl --user enable --now web-container.service loginctl enable-linger $USER第二条命令非常重要，它允许用户在未登录的情况下，用户级systemd服务仍然运行。不加这条，你退出终端后容器服务就会被杀掉。
6.4 常见坑
Podman使用中我踩过最典型的坑有三个。
第一个是卷挂载权限。容器内进程写文件时可能没有权限，因为宿主机目录的属主和容器内用户不一致。用-v挂载目录时，先确认容器内的用户UID，然后调整宿主机目录属主。
第二个是端口占用。宿主机8080端口被别的进程占着时，podman run -p 8080:80会直接失败。
第三个是SELinux影响容器目录访问。如果宿主机开启了SELinux，容器挂载的目录需要添加container_file_t标签：
semanage fcontext -a -t container_file_t "/data(/.*)?" restorecon -Rv /data这个问题在考试里很容易被忽略，因为Docker环境下默认不这么严格，但RHEL 9的Podman环境是强制检查的。
7. Ansible自动化：别说你还没碰过playbook
7.1 三个最小概念
RH134课程最后通常会用几个小时带入门Ansible，为RHCE考试的EX294打底。虽然课时不多，但它是整个RH134课程里“从单机管理到批量运维”思维转变的分水岭。
Ansible有三个最小概念必须理解：
控制节点：安装Ansible的那台机器，所有命令和playbook在这里执行。 受管节点：被控制节点远程管理的机器。 模块：Ansible执行具体操作的最小单元，相当于Linux命令的封装。
安装Ansible只需要在控制节点上执行：
dnf install -y ansible-core看版本确认安装成功：
ansible --version7.2 配置与常用模块
Ansible的配置文件是ansible.cfg，资产清单（inventory）默认是/etc/ansible/hosts。核心配置大多放在ansible.cfg中：
[defaults] inventory = /etc/ansible/hosts remote_user = root测试被管节点连通性：
ansible all -m ping -o如果返回pong，说明控制节点能通过SSH连接受管节点。
常用模块需要形成一个速记表。我按照日常运维频率排个序：
- package模块：安装软件包，支持yum和dnf后端
- service模块：管理系统服务
- copy模块：拷贝文件到远程机器
- lineinfile模块：确保某行配置存在
- user模块：创建用户
- firewalld模块：管理防火墙规则
- shell/command模块：执行任意命令
第一次用Ansible时，可以跑一条最简单的ad-hoc命令感受一下：
ansible all -m package -a "name=nginx state=present"这条命令会在所有受管节点上安装nginx，并且自动抹平不同节点环境的差异。这就是批量运维的威力。
7.3 幂等性的思维转变
我刚接触Ansible时犯过一个很典型的错误：写playbook时想着“如果这个包没有装就装”，用shell模块去判断、去写条件。后来才明白Ansible模块天生就是幂等的。
幂等的意思是：不管执行一次还是执行一百次，系统最终状态都一样。你不需要自己写“如果存在就跳过”，package模块本身就会判断包是否已安装，copy模块本身就会比对文件内容是否一致。
写playbook的正确姿势是描述“最终状态”，而不是写“操作步骤”。比如：
--- - name: ensure nginx installed and running hosts: all tasks: - name: install nginx package: name: nginx state: present - name: start nginx service service: name: nginx state: started enabled: true这段配置无论运行多少遍，结果都是nginx已安装、已启动、已设为开机自启。这种思维方式从RH134阶段就要开始建立，到RHCE考试时你会感谢现在的自己。
8. 考试与实战复盘：易错点和做题顺序
8.1 高频考点
前面内容覆盖了RH134后半程的主要模块，这里把考试和面试里出现频率最高的考点汇总一下。
启动类和内核类是必考题。重置忘记的root密码、grubby调整内核参数、系统进入emergency mode后的修复，这三板斧只要练熟，基本稳拿分。注意重置root密码的操作步骤顺序一定不能反向，我见过有人在chroot后直接reboot，结果SELinux重标记没完成，重启后反而进不了系统。
SELinux类题目惯用的出题思路是：给你一个跑不起来服务的场景，AVC日志里有denied字样，要你能用ausearch或sealert定位问题，然后通过布尔值、fcontext、semanage port三个工具中的一个解决问题。我建议你练习时不带网络环境做一遍，因为考试环境经常不联网，setroubleshoot的提示信息不一定能完整显示。
容器类题目基本是：拉镜像、起容器、挂载目录、生成systemd服务、开机自启。最容易扣分的是忘了enable-linger或忘了生成systemd服务时加--new参数。这两步我至少见三个人在模拟考中翻车。
网络类题目集中在bond聚合和firewalld规则。做bond时容易把nmcli命令顺序写反，先加网卡后建bond设备是必错操作。防火墙则集中在“永久规则到底要不要reload”——这个细节很多人栽跟头。
8.2 做题顺序
考RH134对应的实操考试时，我的建议是拿到题先整体浏览一遍，把题目按“稳、中、难”分类。
稳的题先做：用户创建、文件权限、计划任务、仓库配置，这些拿分最容易。 中的题第二做：SELinux排错、Podman容器、网络聚合。这些题只要思路清晰，步骤熟练，也能比较稳地拿下。 难的题最后做：系统启动修复、内核参数调整、复杂排错。这类题耗时较长，如果时间不够，可以先把简单动作做完，拿到基础分。
尤其是启动修复题，做完后一定要重启验证。如果验证失败，后面还有机会调整；如果把启动修复放在最后且没有验证时间，一旦操作出错，整场考试都可能被打乱。
8.3 最后的踩坑提醒
写这一篇时我特意翻了一下自己实验环境的命令历史，挑出几个最常踩的坑再提醒一次。
第一，所有涉及“永久生效”的操作，写完配置后务必用对应命令验证。比如setsebool -P之后用getsebool确认，firewall-cmd --permanent之后用firewall-cmd --list-all确认，grubby改完内核参数后用grubby --info=ALL确认。
第二，遇到“权限不足”不要习惯性只想到chmod和chown。RHEL上尤其是容器场景，先ls -Z看SELinux上下文，再判断是文件所有权还是安全策略的问题。我在实验里至少两次因为忽略了SELinux标签而浪费半小时。
第三，做系统实验前开一个快照。启动流程、内核参数、SELinux策略这些操作改坏了可能直接无法开机。现在虚拟化平台都支持快照，三秒钟保护一次，性价比极高。
我个人在实际操作中的体会是：RH134后半程学的不是单个命令，而是一套排错闭环。启动出问题就从GRUB和内核入手，服务起不来就从日志和SELinux入手，网络不通就从路由和防火墙入手。把这个闭环练成条件反射，考试和实战就都稳了。最后再分享一个小习惯：每做完一个实验，把用到的命令和报错截图整理成一份自己的速查表，按“场景-命令-坑点”三列归档。这个习惯陪我通过了考试，也让我在后面的工作中少翻了很多文档。
