📚 课程目录第2章 RHEL系统管理基础回顾

2. RHEL系统管理基础回顾

自动化运维平台并不是凭空运行的独立系统，它最终要落到一台台 RHEL 主机上，通过调用主机既有的系统能力来完成部署、配置、监控与修复。因此，在进入 Ansible、SaltStack、Foreman、Katello 或自研控制端之前，必须先把 RHEL 侧“平台依赖的系统能力”梳理清楚。本节不追求把每个子系统讲成完整教程，而是从平台集成的视角，回答三个问题：平台会调用哪些系统能力、这些能力通过什么接口暴露、调用失败时如何判断与恢复。

一、平台依赖的系统能力全景

从自动化平台的角度看，RHEL 主机对外提供的能力可以归纳为六类：服务与启动管理、网络配置、存储与文件系统、用户与权限、SELinux 强制访问控制、firewalld 防火墙。它们并不是彼此孤立的，而是存在明确的依赖顺序：网络决定主机可达性，存储决定数据落点，用户权限决定谁能操作，SELinux 与 firewalld 决定访问是否被放行，systemd 则负责把这些能力组织成可管理的服务单元。

下图给出平台视角下的系统能力依赖关系。图中左侧是自动化平台的控制面，右侧是 RHEL 主机上的六类系统能力，箭头表示平台调用方向与能力之间的依赖方向。

二、systemd：服务与启动的统一入口

systemd 是 RHEL 7 以后所有服务的统一管理入口，也是自动化平台最常调用的系统能力。平台通常通过 systemctl 或 D-Bus 接口完成服务启停、开机自启、状态查询和单元重载。理解 systemd 的关键在于“单元（unit）”和“依赖关系”：一个服务单元可以通过 After=、Requires=、Wants= 声明启动顺序和依赖强度。

例如，一个自研采集服务需要网络就绪后再启动，可以这样声明：

[Unit]
Description=Custom Metrics Collector
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/local/bin/metrics-collector --config /etc/metrics/collector.conf
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

平台在推送该单元后，通常执行 systemctl daemon-reload 让 systemd 重新读取单元文件，再执行 systemctl enable --now metrics-collector 完成开机自启与立即启动。判断是否成功，不能只看命令返回码，还要看 systemctl is-active 与 systemctl is-enabled 两个状态，以及 journalctl -u metrics-collector -n 50 中的实际日志。

三、网络：连接、地址与路由

RHEL 8/9 默认使用 NetworkManager 管理网络，平台可以通过 nmcli 或 nmstate 声明式接口配置连接。一个常见的平台操作是：为某台主机创建静态地址连接并激活。示例命令如下：

nmcli connection add type ethernet con-name ens192-static ifname ens192 \
  ipv4.method manual ipv4.addresses 192.168.10.20/24 \
  ipv4.gateway 192.168.10.1 ipv4.dns 192.168.10.53
nmcli connection up ens192-static
nmcli -g IP4.ADDRESS,IP4.GATEWAY,IP4.DNS device show ens192

平台需要关注的不只是地址是否配上，还包括路由表、DNS 解析和连接是否持久化。判断依据通常是 ip -br addr、ip route、resolvectl status 三组输出是否与期望一致。若平台通过 SSH 管理主机，网络配置错误会直接导致失联，因此变更前应保留带外管理或控制台通道。

四、存储：LVM 与文件系统

平台部署应用时经常需要创建数据目录、扩容逻辑卷或挂载新磁盘。RHEL 上标准的存储栈是“物理卷 PV → 卷组 VG → 逻辑卷 LV → 文件系统 → 挂载点”。示例操作如下：

pvcreate /dev/sdb
vgcreate vg_data /dev/sdb
lvcreate -n lv_app -L 20G vg_data
mkfs.xfs /dev/vg_data/lv_app
mkdir -p /data/app
echo '/dev/vg_data/lv_app /data/app xfs defaults 0 0' >> /etc/fstab
mount -a
df -hT /data/app

平台集成时要注意两点：一是 /etc/fstab 写入后必须用 mount -a 验证，避免重启后因挂载失败进入紧急模式；二是扩容逻辑卷后，XFS 需要用 xfs_growfs 扩展文件系统，而 ext4 使用 resize2fs，两者不能混用。

五、用户权限、SELinux 与 firewalld

用户与权限决定“谁能做什么”。平台通常需要创建专用服务账号、设置家目录权限、配置 sudo 规则。示例：

useradd -r -s /sbin/nologin appsvc
usermod -aG appgrp appsvc
echo 'appsvc ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart metrics-collector' \
  > /etc/sudoers.d/appsvc
chmod 440 /etc/sudoers.d/appsvc

SELinux 是 RHEL 的重要安全特性，平台常见的失败场景是“服务启动失败但权限看起来正常”，此时应检查 getenforce、ls -Z 和 ausearch -m avc -ts recent。修复方式优先使用 semanage fcontext 与 restorecon 修正上下文，或用 setsebool -P 持久化布尔值，而不是直接关闭 SELinux。

firewalld 决定外部访问是否放行。平台开放服务端口时，推荐按 service 而非裸端口管理：

firewall-cmd --permanent --add-service=https
firewall-cmd --permanent --add-port=9100/tcp
firewall-cmd --reload
firewall-cmd --list-all

六、平台集成检查清单

把上述能力落到平台工程中，可以形成一份最小检查清单，用于主机纳管前的基线确认：

能力域	关键检查项	判断命令示例
systemd	目标服务 active/enabled	`systemctl is-active/is-enabled`
网络	地址、网关、DNS、路由	`nmcli device show`
存储	LV 容量、挂载点、fstab	`df -hT`、`findmnt`
用户权限	服务账号、组、sudo 规则	`id`、`sudo -l -U`
SELinux	模式、上下文、AVC 拒绝	`getenforce`、`ausearch`
firewalld	zone、service、port	`firewall-cmd --list-all`

平台自动化失败时，建议按“网络可达 → 服务状态 → 权限与 SELinux → 防火墙”的顺序排查。这个顺序与系统能力的依赖方向一致，能最快定位到被阻断的环节。

梳理清楚这六类系统能力及其接口，后续无论是编写 Ansible Role、设计平台 API，还是做故障自愈，都能明确“平台该调用什么、期望什么状态、失败时看哪里”。这是 RHEL 自动化运维平台工程最底层、也最不可跳过的一步。