培训课里最常被问到的一句话是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.cfgGRUB2菜单配置文件一般由grub2-mkconfig命令根据/etc/default/grub自动生成不要手工改这个文件。/etc/default/grubgrub2-mkconfig读取的源配置改这里的参数再重新生成grub.cfg才是正确姿势。/proc/cmdline查看当前内核启动参数的最直接途径。修改内核启动参数最有用的命令是grubby。很多教程让你去改grub.conf但在RHEL 8/9上grubby才是红帽官方推荐的工具。比如当前系统是图形界面启动想临时在下次启动时加上文本串行日志输出可以这样操作grubby --update-kernelALL --argsconsolettyS0如果某次实验加的参数导致系统起不来不需要去手动编辑grub.cfg直接删除grubby --update-kernelALL --remove-argsconsolettyS0注意grubby默认改的是当前内核如果系统里有多个内核建议显式指定ALL来保证所有内核配置一致否则下一次重启选到旧内核时问题复现你会误以为配置没生效。2.2 重置root密码与救援模式忘了root密码是运维最常见的“社死”场景。在RHEL 9上如果你能物理接触到服务器或者能通过管理台进入开机菜单重置密码只需要三步。第一步重启系统在GRUB2菜单界面停留时按键盘e键进入编辑模式。第二步找到以linux开头的那一行在末尾追加一个参数rd.break这个参数的意思是在根文件系统切换到真实环境之前打断启动流程进入一个带initramfs的紧急shell。第三步按Ctrlx启动你会掉进一个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-max65535 echo fs.file-max65535 /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.confRHEL默认会把大部分日志写入/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就是Permissive1就是Enforcing。这个切换是临时的重启后失效。永久修改要编辑/etc/selinux/configSELINUXenforcing重要的一点是从Disabled切到Enforcing需要重启系统因为SELinux需要重新标记整个文件系统。这也是很多人改了配置后开机卡住的原因。另外强烈不建议在生产环境使用Disabled模式考试更不能出现。4.2 avc日志排错闭环SELinux排错的核心线索是AVC日志。当一个进程被SELinux拦截审计日志里会记录一条类似这样的信息typeAVC msgaudit(...): avc: denied { name_connect } for pid12345 commnginx dest8080 scontextsystem_u:system_r:httpd_t:s0 tcontextsystem_u:system_r:default_t:s0 tclasstcp_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_connectsetsebool -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-servicehttp # 临时放行http firewall-cmd --permanent --add-servicehttp # 永久放行http firewall-cmd --reload # 重载使永久规则生效注意区分带不带--permanent。不带是立即生效但重启失效带--permanent是写入配置文件但必须reload。最常见的坑是加了永久规则忘了reload以为配置坏了或者不加permanent直接重启规则全丢了。如果你要放行自定义端口而不是标准服务使用port命令firewall-cmd --permanent --add-port8080/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自动化别说你还没碰过playbook7.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 namenginx statepresent这条命令会在所有受管节点上安装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 --infoALL确认。第二遇到“权限不足”不要习惯性只想到chmod和chown。RHEL上尤其是容器场景先ls -Z看SELinux上下文再判断是文件所有权还是安全策略的问题。我在实验里至少两次因为忽略了SELinux标签而浪费半小时。第三做系统实验前开一个快照。启动流程、内核参数、SELinux策略这些操作改坏了可能直接无法开机。现在虚拟化平台都支持快照三秒钟保护一次性价比极高。我个人在实际操作中的体会是RH134后半程学的不是单个命令而是一套排错闭环。启动出问题就从GRUB和内核入手服务起不来就从日志和SELinux入手网络不通就从路由和防火墙入手。把这个闭环练成条件反射考试和实战就都稳了。最后再分享一个小习惯每做完一个实验把用到的命令和报错截图整理成一份自己的速查表按“场景-命令-坑点”三列归档。这个习惯陪我通过了考试也让我在后面的工作中少翻了很多文档。