★ FEATURED ARTICLE 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_host192.168.1.10 ansible_userroot。这种写法在单机测试的时候很爽但一上规模就乱。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的结尾统一执行不管任务列表里有多少个notifyhandler都只会被执行一次。也就是说如果你连续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 deniedSELinux是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-servicehttp执行完服务立刻放行了但这个配置只是runtime状态重启防火墙或者重启系统之后就会消失。想要持久化必须加--permanent参数。这里有个执行顺序的坑如果你直接firewall-cmd --permanent --add-servicehttp配置写进去了但当前运行时环境没生效web服务还是访问不了容易让人误以为命令没执行成功。我练题的经验是先不带permanent把规则加到运行时里确认业务不受影响然后再带permanent写一遍让规则持久化。这样两步走的顺序能避免“服务到底起没起”的瞎猜。如果你只想一步到位也可以执行完带permanent的命令后用firewall-cmd --reload把永久配置重载到运行时效果是一样的。另外注意--add-service和--add-port的区别。考试里经常出现需要放行某个端口而不是服务的情况比如MySQL的3306或者Redis的6379这时候就要用--add-port3306/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_logsshd的日志在/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这一段的人最值钱的其实不是证书而是那份“拿到一台陌生机器也能稳扎稳打把它管好”的从容感。这份从容感值得每个人去争取一下。
阅读完成 · 觉得有帮助？
