简介针对RHCSA与RHCE认证备考的RH134、RH294环境使用说明面向Linux系统管理员和红帽认证考生用于快速掌握两套官方模拟培训平台的部署与操作。资料共1个PDF文档压缩包约398KB内容紧凑已有289人学习下载适合考前集中参考。文档详解RH134环境的约30GB硬盘、至少6GB虚拟机内存等硬件要求列出foundation、workstation、servera/serverb、bastion的主机分工以及root、student等账号的默认密码并说明rht-vmctl与virt-manager的典型用法。对RH294环境则介绍约60GB硬盘、至少8GB内存的更高需求说明servera至serverd四台被控节点、快照初始化、RHCSA、RHCE的用途以及通过kiosk账户登录、exam-setup初始化和exam-grade评分的模拟考试流程。按此说明可顺利搭建两套实验环境熟悉各主机角色、快照恢复与评分机制尤其是RH294自带的模拟考试与评分系统可帮助学员自查学习效果针对薄弱环节反复练习显著提升备考效率。1. RH134-RH294环境说明-v1一套实验环境要解决的两门课问题第一次搭 RH134-RH294 的人往往把时间花在装系统和配置网络上而不是花在学习本身。RH134-RH294环境说明-v1 这类文档的价值就在这里它不教系统管理和 Ansible 的内容而是把「跑通这些内容所需要的实验环境」当作一份施工图来写——什么拓扑、什么版本、多大资源、装到什么程度打快照、哪些参数必须在安装阶段定死。它适合两类人一类是准备系统学习 RH134系统管理进阶和 RH294Ansible 自动化的学员另一类是想在公司内部搭建一套可反复重置的 Linux 运维实验床的工程师。读完这份说明你应该能在一天内得到一套能跑完两门课绝大多数实验的环境。这篇笔记就按「拓扑选型 → 基础环境 → 自动化叠加 → 高频排查」的顺序把方案和踩过的坑一次性讲透。2. 环境拓扑与版本选型为什么不能只开一台虚拟机2.1 两门课合在一起时的最小拓扑RH134 的实验对象是一台 RHEL 系统本身涉及逻辑卷调整、SELinux 排错、计划任务、内核参数这些会直接影响系统稳定性的操作RH294 的实验对象则是「控制节点 受管节点」的自动化关系。把两门课的实验环境合并最少需要三台虚拟机一台作为 Ansible 控制节点两台作为受管节点。控制节点也是 RHEL这样在 RH134 阶段它是普通实验机进入 RH294 阶段后安装 ansible-core 并承担控制职责。常见做法是再加一台可选网关机用来模拟跨网络、通过网关管理远端主机的场景考试和练习里遇到 proxy 角色时不会临时抓瞎。拓扑不需要很复杂但必须保证「受管节点之间、受管节点与控制节点之间」的网络是同一个实验网段。实际搭建中我习惯用一个 NAT 网络承载全部虚拟机网关地址固定DNS 不依赖宿主机所有主机名解析写入各节点的 /etc/hosts。这个决定越早做后面 Ansible 的 inventory 写起来越省心——清单里写主机名而不是 IP重装虚拟机后拓扑仍然可用。节点角色建议配置control控制节点 / RH134 练习机2 vCPU4 GB 内存60 GB 磁盘node1受管节点2 vCPU3 GB 内存40 GB 磁盘node2受管节点2 vCPU3 GB 内存40 GB 磁盘proxy可选模拟网关 / 跳板机1 vCPU2 GB 内存20 GB 磁盘2.2 版本选型RHEL 9.x 与兼容发行版的取舍版本选型直接影响实验行为和命令输出。当前 RH134 和 RH294 的实验与评测普遍基于 RHEL 9.x 系列我建议直接使用 RHEL 9.x 的安装镜像而不是选择旧版本或兼容发行版。原因有三第一课程里讲的 SELinux 布尔值、systemd 服务管理、Ansible 集合与执行环境的用法在 9.x 上行为最贴近讲义第二RH294 涉及自动化内容导航器和执行环境镜像这些组件对系统的依赖在 9.x 上得到完整支持第三旧版本上某些命令输出和包名差异会浪费不必要的排查时间。兼容发行版能不能用能但要做好心理准备。比如某些发行版默认的 sudo 配置、防火墙规则、网络命名方式与 RHEL 不同Ansible 的 setup 模块返回的 facts 里操作系统字段也不一样。你在课程练习里照抄命令时可能因为ansible_distribution的差异导致的角色变量不生效这类问题属于「环境对不上」而非「题目做错」。如果你只能使用兼容发行版务必至少保证 systemd、NetworkManager、SELinux 这三个组件存在且默认开启否则后续关于服务的实验会非常别扭。2.3 资源分配内存、CPU、磁盘的底线参数资源给多少直接决定实验顺不顺。以一台 16 GB 内存、8 核的宿主机为例我通常按上面的表格分配control 和 node1/node2 各占 34 GBproxy 给 2 GB剩余留给宿主机和磁盘缓存。内存的坑比 CPU 更隐蔽——受管节点内存太小会导致 Ansible 并发执行任务时 OOM表现为 SSH 连接被断开、任务卡在waiting状态。CPU 方面每台虚拟机至少 2 vCPUAnsible 模块执行本身要求不高但 RH294 里执行环境EE构建和镜像拉取是 CPU 密集型操作。磁盘是大多数人忽略的翻车点。RH294 使用自动化内容导航器时需要从仓库拉取执行环境镜像一套镜像加依赖经常超过 5 GBRH134 里做逻辑卷扩容也需要预留空间。我建议 control 节点磁盘不低于 60 GB。另外所有虚拟机使用静态 IP并记录一张 IP-MAC 对照表。这样即使快照回滚导致网络连接重新激活也可以快速判断是哪台虚拟机在抢占地址。注意内存不足时虚拟机的图形界面可能比命令行先崩溃很多人的第一反应是「系统卡死」实际是 qemu 进程被宿主机 OOM Killer 处理掉了。开虚拟机前先确认宿主机剩余内存。3. 从零搭建 RH134 实验环境安装参数与网络规划3.1 安装阶段必须定死的三个选项包组、分区与用户安装 RHEL 9.x 时图形界面手动安装最直观但如果你需要重复创建多台虚拟机我建议写一份最小 Kickstart 备着用起来比每次点下一步快得多。下面这份片段针对实验场景做了裁剪重点是包组选择、分区策略和 SELinux 状态。# 最小Kickstart片段实验环境用 lang en_US.UTF-8 keyboard us timezone UTC selinux --enforcing services --enabledsshd,NetworkManager # 磁盘与分区LVM自动分区显式指定swap为4096MB zerombr clearpart --all --initlabel autopart --typelvm --swap4096 # 包组带图形界面保证GNOME终端可用 %packages gnome standard vim %end # 创建普通用户并加入wheel组课程实验常以此用户执行sudo user --namestudent --groupswheel --passwordstudent123这份片段里最重要的不是%packages而是autopart --typelvm --swap4096。RH134 的逻辑卷实验需要在已有卷组上操作LVM 自动分区省去后续手动扩展/的麻烦swap 明确给 4 GB避免内存压力大时陷入卡死。user --groupswheel这一步往往被忽略——课程里大量操作要求用普通用户配合 sudo 完成如果你安装时只建了 root后面还得手动补一个带提权能力的用户。selinux --enforcing必须保留RH134 有专门的 SELinux 排错实验关闭状态下做过的实验没有任何参考价值。3.2 同一实验网里的主机名与解析用 /etc/hosts 而不是 DNS实验网络中的主机名解析我推荐直接改各节点的/etc/hosts而不是搭一个真正的 DNS 服务器。原因有两点一是实验网络的节点数量少静态解析足够二是 RH294 的 inventory 和 playbook 里大量引用control.example.com、node1.example.com这样的主机名使用 hosts 文件可以保证在控制节点上ansible all -m ping之前名称解析一定是通的。# 在每一台虚拟机的 /etc/hosts 中追加以下内容 cat /etc/hosts EOF 192.0.2.10 control.example.com control 192.0.2.11 node1.example.com node1 192.0.2.12 node2.example.com node2 EOF # 设置主机名在各自节点上执行 hostnamectl set-hostname control.example.com hostnamectl set-hostname node1.example.com hostnamectl set-hostname node2.example.com注意 IP 段我使用了文档保留地址192.0.2.0/24作为示例你在真实环境里应替换为自己宿主机 NAT 网络实际分配的网段。配置完成后逐台验证ping node1与ssh node1都能使用短主机名。另外不要忽略 NetworkManager 的默认行为RHEL 9.x 中连接名称与设备名分离使用nmcli connection modify修改 IP 后必须nmcli connection up重新激活否则系统里看起来配置生效了实际网卡还在用旧地址。3.3 打好基础快照后续所有实验的后悔药安装完成、注册订阅、网络与主机名配置就绪后第一件事是给每台虚拟机打一个干净快照。这个快照的时机选择很讲究必须在安装完成但尚未进行任何课程实验之前。这样一来RH134 里把系统搞到无法启动、RH294 里把某个节点改坏都能在几分钟内回到可用状态。没有快照保护的实验环境练习到一半系统损坏重建至少两个小时起步。# 在宿主机上对名为 control 的虚拟机创建快照 # 以常用虚拟化管理工具为例不同工具命令略有差异 snapshot-create control --name base-clean --disk-only打快照之前还需要清理虚拟机内部的第一启动唯一标识否则之后基于此虚拟机克隆出的新节点会出现主机名、机器 ID 重复的玄学问题。# 克隆前清理SSH主机密钥与machine-id在源虚拟机上执行 rm -f /etc/ssh/ssh_host_* rm -f /etc/machine-id systemd-machine-id-setup # 清理NetworkManager生成的连接文件首次启动时会重新创建 rm -f /etc/NetworkManager/system-connections/*.nmconnection清理完成后关机再打快照。强调一点快照不是备份不要用它代替文件级备份。课程实验中如果只是某个配置文件被改坏优先用原始文件或dnf reinstall解决快照留给真正需要重置系统的场景。4. 在 RH134 基础上叠加 RH294Ansible 控制节点与受管节点配置4.1 配置 ansible 用户、免密 SSH 与 NOPASSWD sudoRH294 的实验环境有一个不成文的约定Ansible 通过专用用户连接受管节点而不是直接使用 root。这个设计是为了模拟生产环境的安全模型——自动化账号拥有提权能力但不直接以 root 身份登录。我习惯在控制节点和每台受管节点上都创建同名用户ansible并把它加入 wheel 组。# 在所有节点control、node1、node2上执行 useradd -G wheel ansible echo ansible123 | passwd --stdin ansible # 在控制节点上切换到ansible用户并生成密钥 su - ansible ssh-keygen -t ed25519 -N -f ~/.ssh/id_ed25519 # 从控制节点向所有受管节点分发公钥 for host in node1 node2; do ssh-copy-id ansible$host done # 验证免密登录 ssh node1 whoami sudo whoami这里有一个经常踩的坑RH294 要求 ansible 用户在受管节点执行 sudo 时不需要输入密码而默认的 sudo 规则会要求密码。你需要用visudo确认 wheel 组被配置为 NOPASSWD# 执行 visudo确认或添加这一行 %wheel ALL(ALL) NOPASSWD: ALL如果你的课程练习里明确要求保留 sudo 密码以模拟真实环境可以跳过这一步但我建议至少在本地实验阶段启用 NOPASSWD否则 Ansible 在批量执行时需要交互输入密码自动化流程会频繁中断。4.2 控制节点配置ansible.cfg、inventory 与执行环境控制节点上装的软件不止 ansible-core还包括自动化内容导航器ansible-navigator。导航器是 RH294 课程里主要的实验工具它通过下拉执行环境镜像的方式提供 Ansible 运行时。这意味着控制节点必须能访问镜像仓库且磁盘空间要预留充足。在课程实验里我建议安装发行版仓库自带的 ansible-core 和内容导航器即可不需要手动安装额外的集合——执行环境镜像里已经内置了大部分实验需要的集合。# 控制节点用户的 ~/.ansible.cfg [defaults] inventory /home/ansible/lab/inventory remote_user ansible host_key_checking False stdout_callback yaml [privilege_escalation] become True become_user root become_method sudoinventory 文件写在/home/ansible/lab/inventory内容可以采用最简形式[control] control.example.com [managed] node1.example.com node2.example.com [all:vars] ansible_useransible这里两个参数值得说明host_key_checking False是为了避免实验环境中虚拟机重建频繁导致 SSH 主机密钥变化而中断执行stdout_callback yaml则让 playbook 输出更易读排查问题时能直接看到每个任务的变更状态。如果你更习惯用默认的 stdout也可以不设这一项。[all:vars]里的ansible_user确保控制节点用正确用户连接所有受管节点。4.3 最小验证三条命令确认环境真正可用环境配好之后先用一组最小命令验证而不是直接跑课程的第一个 playbook。验证的目的有三个确认网络连通与密钥认证正常、确认 sudo 提权规则生效、确认模块执行没有因目标系统的差异而报错。# 1. 检查所有受管节点的连通性与认证 ansible managed -i /home/ansible/lab/inventory -m ping # 2. 验证提权在受管节点上查看当前身份 ansible managed -i /home/ansible/lab/inventory -m command -a whoami -b # 3. 查看受管节点的操作系统信息确认版本符合预期 ansible managed -i /home/ansible/lab/inventory -m setup -a filteransible_distribution_major_version三条命令的输出没有报错后再写一个最小 playbook 测试 yum 模块的写操作# /home/ansible/lab/verify_env.yml --- - name: 验证环境的最小Playbook hosts: managed become: yes tasks: - name: 安装一个小型工具包 ansible.builtin.yum: name: lsof state: presentansible-navigator run -m stdout /home/ansible/lab/verify_env.yml注意最后一个命令使用了-m stdout让导航器在当前终端直接输出结果避免进入交互模式。如果这一步能顺利执行且返回changed说明控制节点的执行环境、受管节点的连接与提权链路全部打通。之后任何课程的 playbook 异常都可以先从这条链路上找原因。5. 环境搭建与使用排查清单四类高频问题与现场解法5.1 虚拟机重启后 SSH 连不上现象宿主机重启或虚拟机重启后无论使用 IP 还是主机名都无法 SSH 连接但虚拟机的图形界面能登录。在图形界面里查看网卡发现 IP 变成了 DHCP 分到的地址。原因安装时虽然配置了静态 IP但 NetworkManager 的某个连接配置被覆盖或删除导致回退到默认的 DHCP 状态。这个现象在使用快照回滚之后尤其常见——快照保存的网络连接状态与当前虚拟化平台的网络环境不匹配。解决在虚拟机的图形界面或通过虚拟化平台的控制台登录重新为网卡配置静态 IP。具体做法是使用nmcli修改连接而不是直接编辑配置文件nmcli connection modify ens160 ipv4.method manual \ ipv4.addresses 192.0.2.11/24 \ ipv4.gateway 192.0.2.1 nmcli connection up ens160修改后立即测试二层连通性。另外建议在/etc/sysconfig/network-scripts已经不用的环境下不要再手工写 ifcfg 文件RHEL 9.x 中以 NetworkManager 的 keyfile 为准。5.2 yum makecache 一直失败或软件包安装报错现象执行dnf install时卡在Updating Subscription Management repositories或报错Cannot prepare internal mirrorlist部分实验需要的内核模块或开发工具装不上。原因RHEL 9.x 的软件源默认走订阅服务安装时没有完成订阅注册或订阅已过期如果实验网络与外部隔离这类问题更加明显。解决先确认订阅状态再决定走在线仓库还是本地仓库。对于实验环境更稳妥的做法是直接挂载安装 ISO 搭建本地仓库这样不依赖外网且仓库内容与安装介质版本完全一致# 挂载安装镜像假设ISO位于/opt/rhel.iso mount -o loop /opt/rhel.iso /mnt/repo # 创建本地仓库文件 cat /etc/yum.repos.d/local.repo EOF [local-baseos] nameLocal BaseOS baseurlfile:///mnt/repo/BaseOS gpgcheck0 enabled1 EOF dnf clean all dnf makecache本地仓库解决的是「装不上基础包」的问题。如果目标是模拟课程的完整环境在线订阅仍然是最贴近考试环境的做法本地仓库适合离线练习和快速恢复。5.3 Ansible 受管节点提权失败sudo 规则与日志定位现象执行 playbook 时任务报错错误信息类似Missing sudo password或sudo: a password is required即使 ansible 用户已经加入 wheel 组。原因RH294 环境要求受管节点的 wheel 组具备无密码提权能力但安装系统时 sudo 规则默认为需要密码另外如果通过 root 直接运行 ansible 命令连接用户是 rootsudo 行为与 ansible 用户不一致也会造成「在控制节点能执行、在受管节点失败」的错觉。解决登录受管节点查看 sudo 配置确认包含 NOPASSWD 行visudo -c # 检查语法 grep wheel /etc/sudoers.d/*排错时最有用的信息在系统日志里。受管节点上执行journalctl -u sshd -n 50可以查看 SSH 认证日志grep sudo /var/log/secure可以看到 sudo 被拒绝的具体原因。几乎所有提权问题都能在这两个日志里找到答案不需要反复猜测。5.4 快照回滚后主机名错乱或出现重复节点现象从同一个快照克隆出的 node1 和 node2 主机名相同或者回滚后主机名变成了localhost.localdomain导致 inventory 里的主机名无法匹配。原因安装完成后没有清理 machine-id 和 SSH 主机密钥克隆或回滚时多个节点携带完全相同的标识此外如果快照是在网络配置完成之前打的回滚后主机名设置丢失。解决将清理操作固化为快照前的一步标准动作。若问题已经发生逐台登录节点重新设置主机名并清理机器 IDhostnamectl set-hostname node1.example.com rm -f /etc/machine-id systemd-machine-id-setup reboot同时删除/etc/ssh/ssh_host_*重新生成否则控制节点的 known_hosts 里旧密钥会持续报警。记住一个原则主机名、机器 ID、SSH 密钥这两类标识必须做到「每台虚拟机唯一」这是实验环境不打架的底线。6. 把这份环境说明养成可复用底稿三个值得坚持的记录习惯环境搭好只是开始真正有价值的是「下次重搭时不再踩一遍坑」。我的习惯是把环境说明当一份活文档维护而 v1 只是起点。具体做法有三个。第一每次改动环境比如换软件源、关闭防火墙、调整 swap都在文档的参数变更表里加一行记录日期、变更内容、影响范围。不要依赖记忆两周后再搭一套环境时你会发现当时的「临时改动」已经想不起来原因了。第二把上面那三条验证命令ping、whoami、setup 过滤放在文档最前面任何新环境到手先跑这三条能 10 分钟定位八成问题。第三把参数配置表和踩坑记录分开维护参数表供快速搭建使用踩坑记录只记现象、原因、解决不写无关背景。有一次我把控制节点重装后忘了重新给 ansible 用户配 NOPASSWD sudo当时只跑了 ping 验证觉得环境没问题。结果课程第一个需要提权的 playbook 就报错排查了半小时才在/var/log/secure里发现 sudo 被拒绝——如果当时按文档里的自检清单完整跑一遍这个问题一分钟就能暴露。从那以后我再也不省略验证步骤也坚持把每次环境变更的瞬间记下来。环境文档不是给别人看的交付物而是给你自己铺的一条回头路。希望帮到你。本文还有配套的精品资源点击获取
