企业官网建设流程全解析

1. RH134到底考什么：这门课在红帽认证体系里的真实定位

先说个常被忽略的事实：RH134的全称是Red Hat System Administration II，但很多人把它当成一门“只听不练”的理论课，实际上它是一条把“会操作”升级为“能自动化”的转换链路。红帽的认证序列里面，RH124解决的是“单机能不能管得住”，RH134解决的是“多台机器能不能管得动”，而RHCE（也就是EX294）才是真正考验自动化能力的关卡。RH134卡在中间，既要把系统管理的细节抠深，又要开始习惯用Ansible去批量做事，这个过渡期让不少人栽了跟头。

我见过一种典型的学习误区：RH124学完之后觉得自己什么都见过，于是跳过RH134直接刷Ansible题，结果在Playbook的变量优先级、handler触发机制、幂等性这些地方反复踩坑。原因很简单，RH134里的Ansible不是单独拎出来的新知识，它必须建立在扎实的系统操作基础上——你要先懂逻辑卷怎么扩、SELinux布尔值怎么放行、防火墙规则怎么持久化，才能理解Ansible模块背后到底帮你做了什么。没有这层底子，写出来的Playbook只能在实验室里碰运气，换个环境就崩。

再说说RH134在考试上的真实权重。这门课的最终目的不是让你变成Ansible专家，而是让你具备RHCE备考的标准前置能力。EX294考试里有相当一部分任务会在RH134的知识域里钻来钻去：配逻辑卷、改SELinux上下文、设防火墙服务、加定时任务，这些系统底子活儿如果不够熟练，答题速度会非常难看。我在练习的时候花了很多时间在纯手工操作上，后来回头看，那些时间一点都没白费。

还有一个容易被低估的点：RH134会花不少篇幅讲系统管理的“为什么”而不是“怎么做”。比如为什么逻辑卷扩展要按pvcreate、vgextend、lvextend这个顺序来，为什么SELinux上下文不对时明明是root也会Permission denied，为什么firewalld的runtime配置和permanent配置必须分开处理。这些机制层面的理解，才是真正拉开差距的地方。

这篇文章是RH134学习系列总结的第十篇，也到了该做“总复盘”的时候。前九篇讲过的内容我不想再重复展开，这篇文章的重点放在三个方向上：一是把常考的模块边界重新梳理一遍，二是把那些最容易在实操和考试里翻车的操作细节集中拎出来，三是给出一套我自己练到后期一直在用的复盘方法，包括查错顺序和时间分配。如果你正在备考RHCE，或者RH134刚学完想做个全面自检，这篇文章应该能帮你少走不少弯路。

2. Ansible实操里最容易翻车的四个操作面：不是不会，是没想到

先说明一个背景：RH134涉及Ansible的内容其实不算深，但覆盖面很广。inventory怎么写、Playbook的YAML语法、变量引用、handler机制、Jinja2模板、角色目录结构，每一块都有对应的练习题。我练了这么多遍之后发现，真正在考试和项目里让人卡住的，往往不是某个模块的参数记不住，而是下面这几个操作面的小细节。

2.1 inventory的组关系和变量分离经常被忽视

写inventory的时候，很多人习惯把变量直接堆在主机后面，比如web1 ansible_host=192.168.1.10 ansible_user=root。这种写法在单机测试的时候很爽，但一上规模就乱。RH134的练习里更常考的是分组结构和变量文件的组织方式。我自己的习惯是：主机清单只放主机名和组关系，变量全部丢到group_vars和host_vars目录里去。这样做的直接好处是调试的时候不用翻一长串条目，而且分组嵌套的语义也更清楚。

group_vars的优先级有个容易弄混的点：如果同名的变量在inventory文件里直接写了，又在group_vars文件里定义了，那inventory文件里的值会覆盖掉group_vars。我一开始以为group_vars更“高级”，结果被坑了一次——inventory里写死的IP地址和group_vars里配的IP地址不一致，Ansible解析之后还是连了inventory里的那个，排查了半天才发现是优先级理解反了。RH134练习题就喜欢在这种地方埋雷，不是考你会不会写变量，而是考你知不知道谁说了算。

2.2 Playbook里的缩进和键值对，错一个空格就是另一道题

YAML语法在RH134里被反复强调，不是没有理由的。我之前犯过一个很低级的错：在Playbook里写become: true的时候，become和冒号之间多敲了一个空格，结果整个Playbook被解析成字符串而不是布尔值，错误信息还很隐蔽，只说“become is not a valid attribute”。这种问题在编辑器里不容易发现，因为你盯着看很难注意到多了一个空格。

有个实用的排查技巧：当你觉得Playbook报错报得莫名其妙的时候，先用ansible-playbook --syntax-check跑一遍。这个命令不会执行任何任务，只做语法解析，很多YAML格式问题都能在这一步暴露出来。如果syntax-check过了但执行还是出问题，那基本可以确定是逻辑层的问题，而不是格式层——这样排查范围一下就缩小了。

2.3 handler的触发机制和幂等性约束要一起理解

handler是RH134里非常爱考的一个点，它解决的痛点是“只在状态真的发生变化时才去执行某个动作”。比如配置文件被修改了就重启服务，没被修改就不重启。这个机制听起来简单，但有两个实操上的坑。

第一个坑：handler默认只在Play的结尾统一执行，不管任务列表里有多少个notify，handler都只会被执行一次。也就是说如果你连续notify了同一个handler三次，它最后只跑一次，而不是跑三次。这个设计本身是合理的，但如果你没意识到这一点，可能会在某些场景下误判服务状态。第二个坑：handler的执行顺序是严格按照定义顺序来的，不是按notify的触发顺序来的。想在重启服务之前先重载配置，就必须在handler定义里把顺序写对，否则会出现服务起来了但配置没生效的情况。

幂等性这块，RH134反复强调“Playbook跑两遍和跑一遍结果应该一致”。练手的时候最直接的验证方法就是同一个Playbook连续执行两次，第二次所有任务都应该显示为ok或者skipped，而不是changed。如果第二次还有changed出现，说明你的任务没写干净，某些命令或者copy模块的用法还带着“每次执行都干一次活”的味道。养成跑两遍的习惯之后，写出来的Playbook质量会明显上一个台阶。

2.4 模板里的Jinja2表达式，坑在管道的空白处理和默认值

使用template模块加Jinja2模板，在RH134里属于必考能力。模板本身不难，但细节里藏着两个常见翻车点。

一个是变量未定义时的表现。模板里如果引用了一个没有定义的变量，Jinja2默认会当成空字符串处理而不是报错，结果就是配置文件里出现一个空值，服务启动的时候才会报“配置缺失”。我后来习惯在所有关键取值的地方用default()过滤器，比如{{ ansible_facts['memtotal_mb'] | default(0) }}，这样至少配置生成出来是完整的，不会藏着半个残缺条目。

另一个是管道输出的空白行问题。用| to_json或者| join(',')这类过滤器时，结果的行尾常常带着多余的换行或缩进，写入配置文件后虽然不影响大功能，但会让人工检查的时候看得心烦。解决方法是需要严谨时用trim过滤器收尾，或者在模板里把表达式前后不要留无意义的空格和换行。这些小地方不直接扣分，但会影响做事的手感，手感一差就容易在关键步骤上分神。

3. SELinux、逻辑卷和防火墙：RH134这三个系统管理模块的细节陷阱

Ansible只是RH134的“前半场”，后半场是实打实的系统管理能力。这里面SELinux、LVM和firewalld又是考试里出现频率最高的三个模块。恰好这三个模块也最擅长用“看似很简单，实际藏着后手”的题目来考人。

3.1 SELinux上下文不对时，root也要吃Permission denied

SELinux是RH134里最让人头疼也最让人受益的模块。很多人刚接触时觉得它就是个多余的安全层，喜欢顺手setenforce 0关掉。但RH134考试不会给你这种偷懒的机会，题目会明确要求你必须开着SELinux，并且在指定的目录里搞出正确的东西来。

最常见的坑是：你在某个自定义目录下面放了配置文件，服务读取的时候一直报权限错误，ls -l看文件所有者也是对的，权限也是666，但就是读不了。这时候十有八九是SELinux上下文不对。常规目录比如/etc、/var/www/html都有自己的默认上下文类型，而你自己mkdir出来的目录上下文往往是default_t，服务进程跑在受限域里根本碰不到这个类型。

正确的做法是用semanage fcontext给自定义目录设置上下文规则，再用restorecon -Rv让规则生效。很多人只记得restorecon，忘了semanage那一步，结果规则没持久化，重启之后上下文又乱掉。RH134这道题的完整逻辑是：semanage定义策略加restorecon应用策略，两个缺一不可。

还有一个细节：ls -Z是查看上下文最快的命令，写Playbook的时候用community.general.sefs修改上下文也是可以的，但如果你还在用手工操作的阶段，把semanage命令练熟比什么都重要。SELinux的布尔值也是一个考点，比如SELinux开启时Apache能不能访问非标准目录或者能不能做CGI，都是通过布尔值控制的，不是通过直接改配置文件。忘了布尔值这回事，就相当于把安全策略硬生生卡在自己的业务需求上。

3.2 LVM扩容的顺序，错一步就是“灾难级”现场

RH134里的LVM题目，标准解法是pvcreate、vgextend、lvextend、resize2fs（或xfs_growfs）四步走。看着简单是吧？但考题特别喜欢在“文件系统类型”上埋伏笔。

xfs文件系统和ext4在扩容时的处理方式完全不同：xfs只能在线扩大，不能缩小，而且扩容之后必须用xfs_growfs把文件系统扩展到位，这个命令的挂载点参数是你唯一需要关心的事情。ext4则用resize2fs，而且它可以缩小。我见过不少人在xfs卷上习惯性地敲resize2fs，结果直接报错不支持，整个人当场懵了。

还有一个我踩过的坑：lvextend -L +5G和lvextend -L 5G的区别。一个是在现有大小基础上加5G，一个是把逻辑卷调成5G。这个“加号有没有”的问题，考试里真的很爱考，因为它测试的不是你会不会打命令，而是你有没有真正理解命令的语义。我有一次在练习环境里手滑少敲了加号，然后整个逻辑卷缩小到只剩5G，数据还没来得及备份，差点当场把练习环境玩崩。

最后说一个容易被忽略的验收动作。RH134练习题做完之后，永远记得用df -h确认文件系统确实变大了，然后再用pvdisplay、vgdisplay和lvdisplay逐个检查物理卷、卷组和逻辑卷的状态。有时候步骤都执行成功了，但卷组里剩的物理空间不够，逻辑卷根本没有实际扩展，一切看起来正常却什么都没发生。只有做完整链路检查，才能确保万无一失。

3.3 firewalld的runtime和permanent，是一对又爱又恨的组合

firewalld在RH134里的考点，说穿了就是两条：一个是怎么设置规则，另一个是怎么让规则重启之后还在。

firewall-cmd --add-service=http执行完，服务立刻放行了，但这个配置只是runtime状态，重启防火墙或者重启系统之后就会消失。想要持久化，必须加--permanent参数。这里有个执行顺序的坑：如果你直接firewall-cmd --permanent --add-service=http，配置写进去了但当前运行时环境没生效，web服务还是访问不了，容易让人误以为命令没执行成功。

我练题的经验是：先不带permanent把规则加到运行时里，确认业务不受影响，然后再带permanent写一遍让规则持久化。这样两步走的顺序能避免“服务到底起没起”的瞎猜。如果你只想一步到位，也可以执行完带permanent的命令后，用firewall-cmd --reload把永久配置重载到运行时，效果是一样的。

另外注意--add-service和--add-port的区别。考试里经常出现需要放行某个端口而不是服务的情况，比如MySQL的3306或者Redis的6379，这时候就要用--add-port=3306/tcp。有些人在这道题上背命令背顺了，看到端口就下意识用--add-service，结果放行的是服务名而不是端口，复查的时候才发现规则根本没匹配上。这种题目不是考智商，就是考细心。

这个模块里还有一个比较冷门但RH134真会考的：富规则（rich rule）。富规则可以做到更细的控制，比如只允许某个网段访问某个端口，或者对流量做日志记录。虽然平时用的少，但至少在记忆里要有这个概念的影子，知道有这么个东西存在，不然考场上见到题目会根本不知道命令往哪个方向写。

4. 模拟实验的完整复盘链路：从报错到定位，我用的固定排查顺序

RH134到了后期，做题刷实验的目的就不再是“把题做对”，而是“把做错的题变成自己的弹药”。我这里有一套自己反复用的复盘链路，基本思想很简单：每次模拟实验失分之后，遵守固定的排查顺序，不跳步、不瞎试，直到定位到根因。这套方法帮我在后期把模拟实验的正确率稳定拉高了一大截。

4.1 先看事实，再看猜测

一上来就猜“是不是防火墙问题”“是不是SELinux问题”，是最容易浪费时间的行为。我给自己定的规矩是：先把环境里所有和任务目标相关的状态量抓一遍再下结论。

什么叫“抓状态量”？举个例子：给某个服务配置开机自启的题目没得分，我第一轮检查固定跑这些命令：

systemctl status <服务名> --no-pager -l systemctl is-enabled <服务名> ss -tlnp | grep <端口> getenforce firewall-cmd --list-all

这一套跑下来，服务有没有起来、要不要开机启动、端口监听在哪儿、SELinux开没开、防火墙当前放行了什么，全部一目了然。很多问题其实在这一步就已经曝光了，比如服务根本没有启动成功，那后面再看文件权限、再看配置格式都是白费功夫。

四层检查的逻辑是：服务层最贴近现象，先看它；网络层看端口监听和防火墙，很多“服务正常但外部连不上”的问题出在这一层；然后才是SELinux上下文和文件系统权限。这个顺序不能乱，因为前面层级的现象会直接影响你后面判断的方向。

4.2 看日志的姿势要对：journalctl和错误文件一个都不能少

服务起不来，最直接的做法是看日志。RH134实验环境里最常见的服务无非httpd、sshd、firewalld、crond这几样，它们的日志位置和查看方式各不相同。

httpd的错误日志默认在/var/log/httpd/error_log，sshd的日志在/var/log/secure里会有记录，firewalld则更适合用journalctl -u firewalld来查。我见过很多人在httpd报错的时候翻secure日志，翻了半天一无所获，白白浪费时间。

journalctl有个好用的参数组合：-u指定单元，-n只看最近的行数，--no-pager防止日志太多刷屏。一次性写全：

journalctl -u httpd -n 50 --no-pager

这样能快速看到故障前后最近的日志。看日志不是为了找到某种“标准答案”，而是为了缩小范围。比如日志反复出现“Permission denied”，那基本可以确定是文件和上下文的问题，跟配置语法没关系，这时候再回头跑状态检查那一套。

4.3 做了改动之后，验证和缓存是两件大事

排查到根因并且改了配置之后，很多人直接就把这一题翻过去了，结果下次模拟题换个场景又踩同样的坑。我强烈建议每次改动之后做两件事。

第一件事是按题目要求做功能验证。题目让你开放防火墙的http服务，验证方式就是用curl -I去访问一下本地的80端口，看到HTTP/1.1 200 OK才算真的完成。题目让你把httpd设成开机自启，验证方式就是systemctl is-enabled httpd看到enabled才算数。验证这个动作不能省，它不仅仅是心理安慰，是真的能从结果上暴露遗漏。

第二件事是排查环境是否被之前的操作污染。我有一段时间做LVM题目总是不稳定，后来发现练习环境里的卷组被我上一次实验留下了很多不干净的物理卷和逻辑卷，导致新任务执行的时候空间判断完全错乱。从那以后，我每次做新题之前都会先检查一遍实验环境的初始状态，必要时直接重建一个干净的虚拟机快照环境。反复使用一个被污染的练习环境去复盘错误，得出的结论很容易是错的。

4.4 固定一个复盘表格，错一次记一次

到后期的模拟训练，我开始用表格记录每一轮的错题信息。表格的列包括：题目模块、报错现象、根因分类、排查用时、修复命令、复现概率。这个表格不需要很复杂，但它会让你的复盘变得系统化。

比如我会在表格里记录，“httpd访问403，根因是SELinux上下文类型错误，排查用时8分钟，修复命令semanage fcontext -a -t httpd_sys_content_t加restorecon”。写了几轮之后就会发现，自己反复犯的错误其实集中在两三个根因类别里，比如SELinux上下文、键值对优先级、防火墙持久化。明确了弱点之后，再去集中练习就能做到精准提高，而不是天天把整套实验从头再跑一遍。

5. 训练方法、时间分配和考场操作习惯：练到后期我坚持的三件事

RH134的内容量不算巨大，但涉及的技术面和细节足够让人眼花缭乱。从“学过一遍”到“考场稳定输出”，中间差的不是智商，而是训练方法和操作习惯。这篇总结的最后，我把后期备考期间坚持的三件事拿出来说说，每一件都是针对实际提高稳定性来的。

5.1 每天固定跑一遍“基本操作链”，形成肌肉记忆

我觉得RH134最有价值的基本操作链是：创建逻辑卷并挂载、调整SELinux上下文、放行防火墙端口、编写一个触发服务重启的Playbook并执行两次验证幂等。每天花20分钟把这套组合从头到尾跑一遍，不是浪费时间，而是在给考试的手感保温。

这套操作链跑熟之后，有几个直接的好处。第一，命令的拼写和顺序不再需要临时想，手指自己就知道下一步该敲什么，这在考场上是巨大的优势。第二，每个步骤的正常输出是什么样都印在脑子里了，一旦出现异常输出，当场就能判断出来是哪个环节出了问题，不需要从头排查。第三，做这些操作的时候会顺手巩固一些不起眼的细节，比如xfs和ext4的调整命令不同、防火墙的runtime和permanent要分开处理，这些细节就是考试里的送分题。

有人可能会觉得每天重复同样的事情很无聊，但实际操作下来你会发现，越是觉得无聊的时候，越容易在某个不起眼的地方发现之前没注意到的细节。有一次我就是在重复LVM挂载操作时，突然意识到/etc/fstab里写挂载项时如果用了逻辑卷路径，重启后的设备顺序问题就完全不影响了，这个理解让我后续做相关题目的时候又快又准。

5.2 二十分钟原则：解不出来先标记，回头再处理

模拟考试或者实际考试中最怕的一件事是：卡在一道题上死磕，把后面所有题的时间全部耗光。我给自己定了一个“二十分钟原则”——一道题如果花了二十分钟还没有清晰的解决思路，就先把当前状态记录下来，然后跳过它去做后面的题。

这背后的逻辑其实很简单：分值是平均分布的，一道题卡死，损失的不仅是这题的分数，还有后面本来能拿到的分数。而且很多时候，后面题目里会出现类似的知识点或命令，做着做着大脑反而会回忆起前面那道题的解法。等整份卷子做完一遍，再回头处理前面标记的问题，心态和视野都会不一样。

记录状态的时候怎么记呢？我一般会在草稿纸上写下：题目编号、当前改动的文件、执行过的命令和报错信息。这样回头来重新处理，不需要把整个环境重新检查一遍，直接看草稿就能接上思路。

5.3 善用man、--help和tab补全，不要觉得自己“都记住了”

考场上最容易出现的迷之自信就是“这个命令我背得出来”。但RH134的知识面和命令量足够庞大，总有一些参数是你平时用不到、考试里突然冒出来的。这时候man和--help就是救命稻草。

我训练自己的一个习惯是：不管命令熟不熟，新遇到一个不太常用的参数时，先man一下确认它的确切含义再动手。这不丢面子，反而能避免很多因为“自以为懂”而搞出来的乌龙。比如我就曾经一度以为lvresize和lvextend完全等价，后来man了一下才发现，两者在缩小时的参数处理上有很多差异，而RH134偏偏会在这些细节上出题。

tab补全也是要练的，不只是为了省时间，更是为了防错。你敲systemctl再敲tab，系统会把所有可用的子命令列出来，这比你硬背list-units还是list-unit-files要稳得多。看到候选列表的时候，反而能帮你确认自己是不是记错了参数名。考场上能少错一个是一个，稳字当头。

5.4 个人体会：稳定输出的前提是稳定的心态和习惯

练到后期我最大的感受是：RH134不是一个拼天赋的考试，而是一个拼稳定性的考试。谁能在规定时间内把熟悉的操作一个个稳定复现出来，谁就能拿到分。而稳定性靠的是每天的重复练习、固定的复盘流程、以及一套不慌不乱的考场操作习惯。

另外一个让我很受益的习惯是，每做完一道题，不管感觉多顺利，都会花十几秒从头快速核对一遍关键状态量。比如配完逻辑卷就用df -h看一眼，开完防火墙端口就用firewall-cmd --list-all确认一下。这几秒钟的核对，能挡住不少“以为自己做对了、实际还差一点”的情况。RH134的坑从来都不会是那种惊天动地的错误，反而是这种不起眼的小细节，一个接一个地扣走你的分数。

这篇总结是系列的第十篇，也算一个阶段性的休止符。不管你是刚开始备考，还是已经刷了好几遍模拟实验，希望你都能从这套复盘思路和操作习惯里找到一点对自己有用的东西。能走完RH134这一段的人，最值钱的其实不是证书，而是那份“拿到一台陌生机器也能稳扎稳打把它管好”的从容感。这份从容感，值得每个人去争取一下。