4. RHEL安装与自动化部署验收
在RHEL生产平台交付中，安装环节的验收往往决定了后续系统能否稳定运行。很多交付事故并非源于应用配置错误，而是安装阶段遗留了分区不合理、引导参数缺失、自动化脚本未生效等问题。本节围绕Kickstart、PXE、Image Builder三条自动化部署路径，以及安装日志、分区与LVM、首次启动三个验收维度，说明如何把“装完了”变成“验收通过”。
一、三条自动化部署路径的定位与验收重点
Kickstart是RHEL最基础的无人值守安装机制，通过一个ks.cfg文件描述语言、时区、分区、软件包、网络、用户和首次启动脚本。验收时要确认的不是“有没有这个文件”，而是“这个文件是否被真正读取并生效”。典型检查点是/root/anaconda-ks.cfg，它是安装器根据本次实际安装过程生成的回写文件，可与原始ks.cfg比对，确认分区、软件包组、时区等是否与预期一致。
PXE部署则把Kickstart放到网络启动链路上：客户端通过DHCP获取IP和next-server、filename，经TFTP下载pxelinux.0与内核/initrd，再通过HTTP或NFS拉取安装源和ks.cfg。验收PXE时，重点在DHCP的next-server与filename是否指向正确TFTP根、TFTP服务是否可读、ks.cfg的URL是否可达，以及客户端BIOS/UEFI启动模式与引导文件是否匹配。
Image Builder（composer-cli）面向镜像化交付，适合批量生成qcow2、ISO、AMI等制品。它的验收重点与Kickstart不同：不是看单机安装日志，而是看蓝图（blueprint）中的软件包、内核参数、分区方案是否被正确固化进镜像，以及镜像启动后是否具备预期的首次启动行为。
二、安装日志检查：从日志定位安装偏差
RHEL安装完成后，安装器会把过程日志保留在/var/log/anaconda/目录下。验收时建议按以下顺序查看：
ls -l /var/log/anaconda/
grep -iE "error|warning|fail" /var/log/anaconda/anaconda.log
grep -iE "error|warning" /var/log/anaconda/storage.log
grep -iE "error|warning" /var/log/anaconda/packaging.log其中storage.log记录分区与LVM的创建过程，是判断分区方案是否按ks.cfg执行的关键；packaging.log记录软件包安装情况，若出现“package not found”或“group not found”，说明仓库或包组名称有误；anaconda.log则记录安装器整体流程。若日志中出现“ignoring kickstart command”或“unknown kickstart command”，说明ks.cfg语法或版本不匹配，必须修正后重装，不能带病交付。
三、分区与LVM验收：看结构，也看参数
分区验收不能只看“有没有分区”，而要看分区结构、容量、挂载点和LVM参数是否符合交付标准。常用命令如下：
lsblk -f
pvs
vgs
lvs -a -o +lv_size,seg_type
cat /etc/fstab
findmnt --verify验收要点包括：/boot是否为独立分区且文件系统为xfs；根分区是否位于LVM逻辑卷上；卷组中PE Size是否为预期值（如4M）；/etc/fstab是否使用UUID而非设备名，避免设备顺序变化导致启动失败；swap容量是否满足交付基线。若使用LVM，还应确认lvdisplay中LV Path与预期一致，例如/dev/vg_root/lv_root。对于生产环境，建议至少保留一个可扩展的卷组空间，便于后续扩容。
findmnt --verify可以检查fstab中所有挂载项是否可解析、是否存在重复挂载点，是交付前快速自检的有效手段。四、首次启动验证：确认系统“活”得符合预期
首次启动验证的目标是确认系统在无人干预下能正常进入多用户状态，且%post脚本、订阅注册、网络配置等已生效。建议按以下顺序检查：
systemctl --failed
systemctl get-default
sestatus
firewall-cmd --state
subscription-manager status
ip -br a
cat /etc/resolv.conf若systemctl --failed有输出，需逐个排查；若SELinux为disabled而基线要求enforcing，说明安装时未正确配置；若订阅状态为Unknown，说明注册未完成，会影响后续yum源使用。对于PXE和Image Builder部署的机器，还应检查/root/anaconda-ks.cfg是否存在，以及%post脚本是否在/var/log/ks-post.log中留下成功记录。
五、交付前检查清单
| 检查项 | 命令/文件 | 通过标准 |
|---|---|---|
| Kickstart生效 | /root/anaconda-ks.cfg | 分区、包组、时区与预期一致 |
| PXE引导 | DHCP/TFTP/HTTP日志 | 客户端成功获取ks并完成安装 |
| Image Builder | composer-cli compose info | 镜像状态FINISHED，启动行为符合蓝图 |
| 安装日志 | /var/log/anaconda/ | 无ERROR，无ignoring kickstart command |
| 分区与LVM | lsblk / pvs / vgs / lvs | 结构、容量、PE Size、挂载点符合基线 |
| 首次启动 | systemctl --failed | 无失败单元，SELinux/防火墙/订阅正常 |
把上述检查固化为交付前的标准动作，可以显著降低“装完即上线”带来的返工风险。自动化部署的价值不仅在于快，更在于可验证、可复现；验收环节正是把这种可验证性落到实处的关键一步。