企业官网建设流程全解析

很多人第一次被问到 CentOS 和 RedHat 的关系，都是在比较尴尬的场合：要么是面试官随口一问，要么是项目交接时发现对面的老哥把两者混着用，要么是自己面对一台写着 Red Hat Enterprise Linux 的机器，照着 CentOS 的教程敲命令，敲完 yum 直接报没有权限。更麻烦的是，CentOS 7 在 2024 年 6 月走到生命周期终点之后，CentOS Linux 8 早就提前收摊，CentOS Stream 变成了另一条路线，很多人的知识体系还停留在"CentOS 就是免费的 RedHat"这一句话上。这篇东西不讲历史课本，我从实际运维和迁移的角度，把两者的血缘、版本对应、包管理差异、日常命令的分叉点，以及一堆反复出现的坑，一次性摊开讲清楚。不管你是刚在 VMware 里装上 CentOS 7 的新手，还是正在给公司做 RHEL 订阅合规和系统迁移的老手，都能从里面找到能直接抄走的东西。

1. 搞清血缘：谁是上游，谁是下游

先把最容易搞混的一句话摆正：Red Hat Enterprise Linux（下文简称 RHEL）是商业发行版，传统意义上的 CentOS Linux 是它的下游复刻版，而 2021 年之后的 CentOS Stream 反过来变成了 RHEL 的上游。这三者的顺序在不同年代是反的，这是所有混乱的源头。

1.1 RHEL 的源码是怎么出来的

Red Hat 的开发链路大致是 Fedora → RHEL。Fedora 是节奏快、尝鲜性质的社区版本，每半年一个版本；RHEL 从 Fedora 里挑出一个时间点做分支，然后进入长达十年的维护。RHEL 本身是商业产品，但它的绝大多数组件是 GPL 等开源协议覆盖的，协议要求它必须把对应源码放出来。Red Hat 走的是 SRPM（源码 RPM）这条路，把这些源码包放在客户门户里，供持有订阅的用户获取。

这里有个实操层面的关键点：SRPM 不等于二进制 RPM。SRPM 是"配方加原料"，包含 spec 文件、补丁、原始 tarball；二进制 RPM 是"做好的菜"。CentOS 当年干的事情，就是把 SRPM 拿回来，去掉 Red Hat 的商标和品牌资源，改掉 release 包，然后重新编译一遍，产出自己的二进制包。所以早期 CentOS 和对应版本的 RHEL 在二进制层面是高度一致的，用户态的程序几乎可以互换。

1.2 传统 CentOS 的重建模式：好处和代价

重建模式带来的好处非常直观，也就是 CentOS 当年能火起来的原因：包管理方式一模一样，命令一模一样，配置文件路径一模一样，RHEL 的文档和书可以直接拿来用。你在 RHEL 7 上学的 systemctl、firewalld、nmcli，在 CentOS 7 上原样可用。

代价也很明显。第一是时间差，RHEL 出补丁，CentOS 要等人家把源码放出来、再走一遍重建流程，紧急安全补丁通常慢几天到几周；第二是没有官方支持，出问题只能靠社区和自己；第三是品牌资源被剥离后，一些依赖 Red Hat 认证的组件（比如某些认证插件、订阅相关的工具链）天生就没有。理解了这一点，你就能明白为什么很多企业明知道 CentOS 免费，还是咬牙买订阅——买的是响应时间和责任主体，不是那几个 RPM。

1.3 角色反转：CentOS Linux 和 CentOS Stream 是两码事

2020 年底的那次路线调整，是很多人知识断层的分界线。简单说：

• CentOS Linux：老模式，RHEL 的下游复刻，有明确的版本号（7、8），有明确的生命周期。7 撑到了 2024 年 6 月，8 提前在 2021 年底结束。
• CentOS Stream：新模式，RHEL 的上游滚动开发分支。它比 RHEL 早一步拿到变更，相当于 RHEL 下一个次版本的预演场。Stream 9、Stream 10 都是滚动更新的，没有传统意义上的"小版本号"。

这个反转带来的实际影响是：Stream 上的包可能比对应的 RHEL 版本新，也可能在某些细节上不一致，因为它是"正在开发中"的状态，而不是"已经冻结验收完"的状态。拿它当生产环境的铁板一块来用，需要你自己做验证，不能指望有一份"和 RHEL 完全二进制对齐"的保证。

2. 版本号、生命周期与订阅那点事

搞清楚血缘之后，第二个高频问题是："我这台 CentOS 7 相当于 RHEL 几？还能用多久？"版本号对应关系比较好办，生命周期和授权才是真正会让人踩坑的地方。

2.1 版本号为什么能一一对上

传统 CentOS 的版本号是直接跟着 RHEL 走的：CentOS 7.9 对应 RHEL 7.9，CentOS 8.5 对应 RHEL 8.5。这不是巧合，是重建模式的必然结果——源码版本号一致，产物版本号自然一致。所以你在 CentOS 7.6 上查到的内核版本、glibc 版本、systemd 版本，基本可以拿去对照 RHEL 7.6 的文档。

一个能快速自查的小方法，在任意一台机器上执行下面这几条，就能拿到判断依据：

cat /etc/redhat-release # CentOS 上会显示 CentOS Linux release 7.9.2009 (Core) cat /etc/os-release # 更通用的方式，能看出 ID 是 centos 还是 rhel uname -r # 内核版本，注意 CentOS 的内核字符串里没有 RHEL 的构建后缀 rpm -q centos-release # CentOS 上拿到的是 centos-release，RHEL 上是 redhat-release

最后一条特别有用。很多脚本判断发行版就是靠rpm -q --whatprovides /etc/redhat-release，CentOS 和 RHEL 返回的包名不一样，写脚本做兼容时要留意。

2.2 生命周期对照表

下面这张表是我自己在做迁移规划时常用的对照，注意 CentOS Linux 8 那一行是个例外，它没有走完 RHEL 8 的完整周期。

RHEL 的十年周期通常拆成"完整支持"和"维护支持"两个阶段，后半段基本只收安全补丁和严重问题修复，不再加新功能和新硬件支持。做硬件升级规划时，这个分界线比 EOL 日期更值得关注——你可能还在周期内，但新买的网卡和阵列卡已经不在支持列表里了。

2.3 授权和订阅：能装上不等于能合规用

CentOS 不讲授权，装多少台都行。RHEL 讲。RHEL 的订阅机制是通过subscription-manager注册到 Red Hat 的 CDN，注册之后才会给你仓库的访问凭证（放在/etc/pki/entitlement/下面）。没注册的 RHEL，yum repolist会告诉你仓库是空的或者全部 disabled，这时候很多人会以为是网络问题，其实是没订阅。

判断当前机器状态最快的三条命令：

subscription-manager status # 看整体订阅状态 subscription-manager repos # 看有哪些可用仓库、哪些启用 yum repolist all # 看仓库实际生效情况

反过来说，CentOS 的仓库地址是公共镜像站，走的是mirror或者vault，不需要任何凭证。这就是为什么同一份yum install教程，在 CentOS 上一把过，在 RHEL 上可能第一步就卡住。写自动化脚本或者做镜像时，这一步必须分开处理。

3. 仓库与包管理：差异最集中的地带

RHEL 和 CentOS 的差异，百分之八十都体现在仓库和包这一层。命令语法几乎一样（yum/dnf 是同一套），但仓库从哪来、包里装了什么，差别不小。

3.1 仓库地址与订阅机制的分叉

CentOS 7 及以前，/etc/yum.repos.d/下是CentOS-Base.repo，指向公共镜像。CentOS 8 和 Stream 时代换成了 dnf，文件结构类似但内容指向不同域名。RHEL 上则是redhat.repo，这个文件是被subscription-manager动态生成的，你手动改它会被覆盖，想加仓库要用subscription-manager repos --enable=xxx或者干脆自己新写一个.repo文件。

老版本的情况更复杂一点。RHEL 6.5 那个年代，早期用的是 RHN Classic 那套体系，后来切到 subscription-manager。现在再想把一台 RHEL 6.5 跑起来装包，最省事的做法是挂 ISO 做本地仓库，别指望连官方源了：

mount -o loop /path/to/rhel-server-6.5-x86_64-dvd.iso /mnt cat > /etc/yum.repos.d/local.repo <<'EOF' [local] name=local-iso baseurl=file:///mnt enabled=1 gpgcheck=0 EOF yum clean all && yum makecache

同样的套路对 CentOS 7.9 也成立，尤其是内网离线环境，把 ISO 挂上去做本地源，比一个个 rpm 手动装靠谱得多。

3.2 包名和版本字符串的差别

前面提到的centos-release和redhat-release只是最表层的一处。再往下看：

• 内核版本字符串：CentOS 的内核不会带 RHEL 的构建后缀，某些依赖内核字符串做判断的第三方驱动安装脚本会因此报错。
• 品牌相关包：logos、indexhtml、release notes 这类包在两边的名字和内容都不一样。
• /etc/issue、/etc/motd：很多合规检查脚本会读这里，两边内容天然不同。

真正需要注意的是内核 ABI。传统 CentOS 和 RHEL 在同一个小版本上，内核 ABI 是一致的，所以第三方内核模块（比如某些存储驱动、安全模块）编译一次两边都能用。但跨小版本就不保证了，这也是为什么生产环境升级内核前一定要先看变更说明。

3.3 商业组件的有无

RHEL 订阅里包含一些 CentOS 没有的东西，实际会用到的主要有这几类：

所以如果你在做等保、金融行业合规这类工作，选型时把这一块算进去，不然临到检查才发现少东西，返工成本很高。

4. 日常运维命令：哪些完全一样，哪些会翻车

命令层面我的经验是这样：系统管理的基础操作九成以上相通，翻车集中在"仓库、订阅、网络配置格式、SELinux 策略"这四个点上。下面按常用场景拆开说。

4.1 网卡与 IP 配置：从 ifcfg 到 keyfile

CentOS 7 和 RHEL 7 都用 NetworkManager 管网络，配置文件在/etc/sysconfig/network-scripts/ifcfg-xxx。CentOS 7.6 那种老机器上查看网卡，最常用的还是这几条：

ip addr show # 首选，net-tools 不装也能用 nmcli device status # 看设备状态和连接名 lspci | grep -i ethernet # 看物理网卡型号

注意 minimal 安装的 CentOS 默认不带net-tools，ifconfig和netstat直接是 command not found，要么装包要么改用ip和ss。这个坑几乎每个新手都踩过。

到了 RHEL 9 / CentOS Stream 9 以后，NetworkManager 的配置格式换成了 keyfile，路径变成/etc/NetworkManager/system-connections/，老式的 ifcfg 虽然还能读，但新写建议直接用 nmcli：

nmcli con mod "ens160" ipv4.addresses 192.168.1.50/24 nmcli con mod "ens160" ipv4.gateway 192.168.1.1 nmcli con mod "ens160" ipv4.dns "223.5.5.5 114.114.114.114" nmcli con mod "ens160" ipv4.method manual nmcli con up "ens160"

CentOS Stream 10 固定 IP 也是这套。写错网关或者掩码，症状就是能 ping 通同网段但出不了门，别急着怀疑系统，先把ip route看一眼。

查看某个进程占了哪些端口和连接，用ss -tunap或者lsof -i -P -n都比老netstat快，ss在两边系统里都是标配。

4.2 防火墙放行：firewalld 是共同语言

RHEL 7 和 CentOS 7 开始，默认都是 firewalld，命令完全一致：

firewall-cmd --add-port=8080/tcp --permanent firewall-cmd --reload firewall-cmd --list-all

对应的配置文件在/etc/firewalld/zones/public.xml，如果做批量部署，直接推这个文件比逐台敲命令高效。要注意的是--permanent不加的话，重启就丢，这个错我见过太多次。

还有一个高频现象：服务本机curl 127.0.0.1通，外部连不上。拿 redis 举例，你redis-cli登录进去发现一切正常，但另一台机器连不上，八成是bind 127.0.0.1只监听了本地，或者protected-mode yes挡着，再或者防火墙没放 6379。这三步依次排查，基本能定位。

4.3 日志与服务管理

RHEL 7 和 CentOS 7 之后都是 systemd，日志走 journald：

journalctl -u nginx -n 100 --no-pager # 看某个服务的近期日志 journalctl --since "1 hour ago" -p err # 看一小时内错误级别日志 tail -f /var/log/messages # 传统文本日志，两边都在 tail -f /var/log/secure # 登录、sudo、ssh 相关 dmesg -T | tail -50 # 内核环缓冲，带时间戳

RHEL 6.5 那种老系统没有 systemd，日志就是纯文本，服务管理用service xxx start和chkconfig，重启用shutdown -r now。到了 systemd 时代，重启统一是systemctl reboot或者shutdown -r now，两条命令在 RHEL 和 CentOS 上都一样。做维护窗口时尽量用shutdown -r +5 "维护重启"这种带通知的方式，比reboot体面得多。

4.4 用户、口令与远程端口

单用户模式重置 root 口令这套操作，两边完全一样：开机在 GRUB 菜单按e，在 kernel 行尾加rd.break（CentOS 7 / RHEL 7 及以后）或者single（更老的系统），然后mount -o remount,rw /sysroot、chroot /sysroot、passwd root，最后一定要执行touch /.autorelabel，否则 SELinux 上下文不对，重启后可能进不了系统。这个touch是新手最容易漏的一步。

改 SSH 远程端口这件事，光改/etc/ssh/sshd_config里的Port是不够的。SELinux 开着的话，还得给新端口打标签：

semanage port -a -t ssh_port_t -p tcp 2222 firewall-cmd --add-port=2222/tcp --permanent && firewall-cmd --reload

顺序上建议先把新端口开好、验证能连上，再关旧端口，不然你就得去机房了。这套流程在 RHEL 和 CentOS 上没有区别。

5. 磁盘、离线装包、容器：实操重灾区

这一块是我被问得最多的，也是 CentOS 和 RHEL 差异体现得最不明显、但坑最多的地方。因为命令一样，反而容易让人忽略环境差异。

5.1 磁盘扩容和 LV 空间挪移

虚拟机磁盘扩容的标准链路是这样：先在虚拟化平台把磁盘调大，进系统后扩分区、扩 PV、扩 LV、扩文件系统。

lsblk # 确认新容量已经识别 growpart /dev/sda 3 # 扩展分区（CentOS 7 需装 cloud-utils-growpart） pvresize /dev/sda3 lvextend -l +100%FREE /dev/mapper/centos-root xfs_growfs / # XFS 用这个；ext4 用 resize2fs

centos-root这个名字是 CentOS 默认的 VG 名（RHEL 默认也叫这个，所以两边通用）。如果你的盘是 ext4，最后一步换成resize2fs /dev/mapper/centos-root。搞混了会报错，但不会损坏数据，重跑一次就行。

"把 /home 的空间挪给根分区"是个经典需求，尤其是根分区快满、/home 却空着一大半的机器。步骤是：先确认 /home 没有正在使用的进程，umount /home，然后lvreduce -L -50G /dev/mapper/centos-home（如果要缩文件系统，加-r让它一起处理，但 XFS不支持缩小，只有 ext4 可以）。XFS 的情况下只能备份数据、删掉 LV、重建、再恢复。这一点非常关键，很多人上来就lvreduce结果把 XFS 搞崩了。

顺手说个排查磁盘占用的组合拳：找大文件用find / -xdev -type f -size +10M -exec ls -lh {} \; 2>/dev/null | sort -k5 -h | tail -20，比du一层层翻快得多。挂载新盘时记得改/etc/fstab并且先mount -a验证一遍，写错 UUID 就等着下次开机进应急模式吧。

5.2 离线装包：gcc、nodejs、maven 的通用套路

内网环境装东西，有个万能思路：能挂 ISO 就别手动 rpm。因为离线装 gcc 这类编译器，依赖链能拉出几十个包，手动装到崩溃。

# 挂载 ISO 做本地源（RHEL 和 CentOS 通用） mount -o loop /path/to/dvd.iso /mnt cat > /etc/yum.repos.d/local.repo <<'EOF' [local] name=local baseurl=file:///mnt enabled=1 gpgcheck=0 EOF yum clean all && yum makecache yum install -y gcc gcc-c++ make

如果实在没有完整 ISO，只有零散 rpm，那就在一台能联网的同版本机器上用yumdownloader把依赖一起拉下来，再传到内网：

yumdownloader --resolve --destdir=/tmp/pkgs gcc # 内网机器上 yum localinstall -y /tmp/pkgs/*.rpm

Node.js 的离线安装更简单，直接下官方二进制压缩包解压即可，不走系统包管理器，也就没有依赖问题：

tar -xf node-v20.x-linux-x64.tar.xz -C /usr/local/ ln -s /usr/local/node-v20.x-linux-x64/bin/node /usr/bin/node ln -s /usr/local/node-v20.x-linux-x64/bin/npm /usr/bin/npm

Maven 的离线要分两层：Maven 本身解压即用，麻烦的是依赖。做法是在有网机器上mvn dependency:go-offline把依赖拉全，然后把整个本地仓库目录（默认~/.maven_repo）打包带走，在离线机器的settings.xml里把localRepository指向这个目录。经验是go-offline经常抓不全，尤其是插件依赖，所以最好的办法是先在联网环境完整跑一次mvn package，把仓库打满，再整体搬过去。

CentOS 上还有一个高频疑问：系统自带的 python 和 rpm 的关系。记住一条就够——别动系统自带的 python。CentOS 7 的 yum 是 python2 写的，CentOS 8 以后 yum/dnf 依赖python3系统包，你手工升级或替换/usr/bin/python，yum 立刻罢工。要装新版本就用虚拟环境或者独立目录，别碰系统解释器。

5.3 Docker 与 Web 应用部署

RHEL 7.5 那批机器部署 Docker，和 CentOS 7 完全一样：装yum-utils，加仓库，yum install docker-ce，然后systemctl enable --now docker。镜像源慢的话改/etc/docker/daemon.json：

{ "registry-mirrors": ["https://your-mirror.example.com"], "log-driver": "json-file", "log-opts": { "max-size": "50m", "max-file": "3" } }

顺手把日志限制加上，不然跑几个月的容器能把磁盘吃满。跑一个 Web 应用的最小闭环：

docker run -d --name web -p 8080:80 --restart=always nginx

--restart=always别忘了，不然宿主重启后容器不会自己起来，这是部署后最常见的"上线第二天打不开"的原因。

Nginx 如果用二进制包部署，步骤是解压、./configure、make、make install，然后自己写 systemd unit。这里有个 SELinux 的坑：Nginx 反向代理后端时，会被 SELinux 拦住，需要setsebool -P httpd_can_network_connect 1。用 yum 装的 Nginx 也一样会遇到，跟发行版无关。

5.4 Samba、面板工具这类周边

Samba 配置在 RHEL 和 CentOS 上完全一致，/etc/samba/smb.conf写共享段，smbpasswd -a user加账号，然后放行 137/138/139/445。唯一的差别还是 SELinux，共享目录必须先打上下文：

semanage fcontext -a -t samba_share_t "/data/share(/.*)?" restorecon -Rv /data/share

宝塔这类面板在 CentOS 上装得多一些，因为社区教程多、脚本适配久。但要注意，面板会自动改防火墙、改系统服务、装一堆自编译组件，跟你后面自己配的 Nginx、MySQL 很容易打架。我的建议是：面板只用在测试机和小型内部服务上，正式环境还是老老实实手工装，出了问题你能说清楚是哪一层。

6. 几个反复出现的故障链路

下面这几个问题，我在不同公司、不同团队里见过至少五次以上，几乎是 CentOS/RHEL 使用者的共同记忆。关键在于排查思路，而不是背答案。

6.1 卡在 starting dracut initqueue hook

开机卡在这一行，症状是等很久最后掉进 dracut 应急 shell，或者直接超时。根因基本集中在"内核找不到根设备"这一类。

排查按这个顺序走：

1. 看 fstab。在 dracut shell 里执行cat /etc/fstab，比对里面的 UUID 和blkid的输出。最常见的场景是虚拟机克隆之后磁盘 UUID 变了，fstab 还指着老 UUID。
2. 看根设备是否被识别。ls /dev/mapper/、cat /proc/cmdline，确认root=指向的设备存在。
3. 看是不是内核和模块不匹配。升级内核后 initramfs 没重建，或者虚拟化平台换了磁盘控制器类型（比如从 IDE 换成 SCSI），驱动没进 initramfs。

修复方式通常是进救援模式，把 fstab 改对，或者用dracut -f重建 initramfs。想看得更清楚，可以在启动参数里临时加rd.debug和rd.shell，它会告诉你到底卡在等哪个设备。这个技巧比反复重启有效得多。

6.2 虚拟机 NAT 模式上不了网、ping 不通网关

VMware 里装 CentOS 7，NAT 模式是最常用的，也是最容易没网的。按这个顺序查：

• 宿主机服务是否在跑：Windows 上打开服务列表，确认 VMware NAT Service 和 DHCP Service 是启动状态，这两个服务被安全软件干掉的情况非常常见。
• 虚拟机网络编辑器：看 NAT 网段（比如 192.168.x.0/24）和虚拟机里配的 IP 是否同网段，网关是不是.2结尾那个地址。
• 虚拟机内部：ip addr看有没有拿到地址，ip route看默认路由在不在。CentOS minimal 装完经常ONBOOT=no，网卡压根没起来，改/etc/sysconfig/network-scripts/ifcfg-ens33里的ONBOOT=yes然后systemctl restart network。
• 检查 ICMP 是否被禁：sysctl net.ipv4.icmp_echo_ignore_all，返回 1 的话 ping 不通但网络其实是好的，别被误导。

如果同网段能通、网关 ping 不通，先确认网关地址有没有写错。虚拟化环境下网关通常不是.1，这个反直觉的点坑过很多人。

6.3 从 CentOS 7.9 迁移到新系统时最容易忽略的事

老系统迁新系统，技术上的坑反而好解决，真正麻烦的是这三件事：

• 第三方仓库。CentOS 7 时代大家习惯装 EPEL、remi、nginx 官方源这些。迁到 RHEL 或 Stream 之后，这些仓库的地址、GPG key、包名可能有变化，得逐个重新确认。老版本（比如 RHEL 5、6 那批）的资源现在基本都在归档站点里，能找到，但不会再更新。
• 自编译组件。凡是当年make install装的东西（自编译的 Nginx、Python、OpenSSL），新系统上全部要重新评估，因为系统库版本变了，老的二进制大概率跑不起来。
• SELinux 策略和防火墙规则的沉淀。跑了几年的机器上，往往有一堆当年为了"先让它跑起来"而临时加的放行规则，没人记得为什么加。迁移时正是清理的好机会，但前提是你得先把它们捞出来看一遍，firewall-cmd --list-all和semanage fcontext -l是起点。

6.4 SSH 大版本升级的保守做法

CentOS 7.9 上升级 OpenSSH 到很新的版本，这个需求在合规检查里很常见，因为 CentOS 7 自带的 OpenSSH 版本太老。我的做法永远是"另起一个端口，不碰原来的"：

# 编译前先备份配置 cp -a /etc/ssh /etc/ssh.bak.$(date +%F) ./configure --prefix=/usr/local/openssh --sysconfdir=/etc/ssh --with-pam ... make && make install # 新 sshd 先跑在 2222 端口 /usr/local/openssh/sbin/sshd -p 2222 -f /etc/ssh/sshd_config.new

验证 2222 能正常登录（并且要用新账号体系验证一遍 PAM 认证），确认无误再考虑换默认端口。整个过程最重要的一条纪律：不要在 SSH 会话里直接重启 sshd，一旦配置有问题，你就失去了唯一的入口。所有验证都通过新端口做，确认好了再动老服务。

7. 选型：什么时候选 RHEL，什么时候走 Stream

聊完技术细节，回到最实际的问题：新项目到底该选哪个。我的判断标准比较简单，按"谁来兜底"来分。

如果你所在的组织有合规要求、需要有人对操作系统层面的安全事件负责、需要硬件厂商的联合认证，那就买 RHEL 订阅。别只算软件的钱，订阅买的是响应链路和责任人，出事故时能有人陪你一起查，这个价值在很多场景下比授权费高得多。

如果只是内部测试环境、学习环境、边缘小服务，CentOS Stream 完全够用，而且它比老 CentOS 更贴近 RHEL 的演进方向。但要接受一个事实：它没有固定小版本，滚动更新意味着你得自己做验证，不能像以前那样"装完 7.9 就锁死三年不动"。如果团队没有这个验证能力，那不如考虑那些承诺长期支持的社区发行版。

还有一个折中路线是"用 RHEL 的二进制但不买订阅"的各种下游重建版本，各有各的维护节奏和社区背景，选之前看清楚它的生命周期承诺和更新节奏，别只看"和 RHEL 兼容"这句宣传语。

我自己踩过最深的坑，是早年在一个项目里把 CentOS 和 RHEL 当成完全等价来写自动化脚本，结果脚本里判断发行版的逻辑在 RHEL 上直接失效，因为centos-release包不存在。后来养成了一个习惯：任何判断发行版的代码，一律只读/etc/os-release里的ID和VERSION_ID字段，不去猜包名、不去猜文件路径。这个习惯到现在为止，在 RHEL、CentOS、Stream 以及各种衍生版本上都没翻过车。另一个习惯是，给任何一台新机器做完基础配置之后，立刻把uname -a、rpm -qa | sort、ip addr、firewall-cmd --list-all四条命令的输出存档一份，等哪天机器出问题或者要做迁移时，这份档案能帮你省掉大量追溯时间。