01-Linux 发行版选择

Linux 系统管理的第一步不是背命令，而是选对发行版。发行版一旦进入生产环境，就会影响后续几年的补丁策略、软件仓库、内核版本、硬件认证、商业支持、自动化工具、团队技能和故障处理方式。选错发行版不一定会让系统马上不可用，但会把维护成本慢慢推高：补丁没人敢打，软件包版本对不上，厂商不支持，安全基线无法统一，升级窗口越来越难排。

本文是 Linux 系统管理系列第 1 篇，目标是建立一套可落地的 Linux 发行版选择方法。它不追求“哪个发行版最好”的单一答案，而是帮助你根据服务器用途、生命周期、软件生态、合规要求、团队能力和运维模型做决策。本文核验日期为 2026-06-12，版本信息以 Ubuntu、Debian、Red Hat 官方资料为准；对 Rocky Linux、AlmaLinux、Fedora、Arch 等发行版的描述只作为选型参考，生产使用前仍应核对各自官方生命周期和支持政策。

选型不是偏好问题

很多团队选择发行版时，容易受个人经验影响。有人熟悉 Ubuntu，就倾向所有服务器都装 Ubuntu；有人在金融或制造核心系统里长期使用 RHEL，就认为社区发行版都不够可靠；有人喜欢 Arch 的新版本生态，就希望开发环境也能和生产环境一样灵活。个人经验有价值，但不能替代组织级决策。

生产发行版选择至少要回答六个问题。第一，系统要运行多久，是否需要五年以上稳定维护。第二，系统运行什么业务，是否需要商业软件认证或厂商支持。第三，团队是否熟悉该发行版的包管理、日志、网络、服务和安全工具。第四，安全补丁和内核更新如何进入生产。第五，是否需要合规能力，例如 FIPS、CIS hardening、等保、安全审计或供应商支持声明。第六，未来是否要批量自动化、云迁移、容器化或纳入统一运维平台。

这张图对应的核心思路是：发行版选择应从稳定性、支持周期、软件生态、合规性、团队能力和场景适配六个维度同时判断，而不是只看下载量或个人熟悉程度。

当前主流家族

Linux 发行版大体可以按家族理解。家族关系决定了包格式、包管理工具、配置习惯、默认安全机制和运维资料生态。

Debian 家族包括 Debian、Ubuntu 及大量衍生发行版。Debian 稳定版强调自由软件、社区治理和稳定发布。Ubuntu 基于 Debian 生态，由 Canonical 提供商业支持，LTS 版本是云服务器、开发环境和通用服务器里非常常见的选择。Ubuntu 官方 release cycle 页面显示，LTS 每两年发布一次，标准安全维护通常为 5 年，Ubuntu Pro 可以扩展安全覆盖。以 2026-06-12 查询结果为例，Ubuntu 24.04 LTS 于 2024 年 4 月发布，标准安全维护到 2029 年 5 月；Ubuntu 26.04 LTS 于 2026 年 4 月发布，标准安全维护到 2031 年 5 月。

Red Hat 家族包括 RHEL、CentOS Stream、Rocky Linux、AlmaLinux、Fedora 等。RHEL 面向企业订阅和商业支持，强调稳定生命周期、认证生态和安全合规；CentOS Stream 是 RHEL 的上游连续交付流；Rocky Linux 和 AlmaLinux 主要面向需要 RHEL 兼容体验但不购买 RHEL 订阅的场景；Fedora 是新技术更快进入社区验证的发行版。Red Hat 官方文档当前已提供 RHEL 10 文档入口，生产选型时要结合应用认证、硬件认证和组织订阅策略决定使用 RHEL 9、RHEL 10 或兼容发行版。

SUSE 家族包括 SUSE Linux Enterprise Server 和 openSUSE。SLES 在部分企业、SAP、传统制造和欧洲市场有较强存在感，openSUSE Leap/Tumbleweed 分别面向稳定和滚动更新场景。若企业已有 SUSE 订阅、YaST 管理习惯或 SAP 认证需求，SUSE 家族应进入候选名单。

独立发行版包括 Arch、Gentoo、NixOS 等。它们在学习、开发、可重复构建或高度定制场景有价值，但通常不是传统生产服务器的默认选择。比如 NixOS 的声明式配置适合追求可重现系统状态的团队，但需要团队接受完全不同的配置模型；Arch 适合理解 Linux 机制和桌面/开发环境，但滚动更新不适合作为多数核心业务服务器基线。

选型维度

这张图强调发行版选择不是单点判断。下面逐项展开。

生命周期

服务器系统最怕“装的时候很顺，维护时没人负责”。生命周期要看三个层次：发行版生命周期、内核和关键组件生命周期、企业内部维护周期。

Ubuntu LTS 适合需要明确 LTS 节奏、云镜像和社区资料的场景。Debian stable 适合重视社区稳定、少变更和轻量系统的场景。RHEL 适合需要商业支持、软件认证、长期生命周期和合规能力的场景。滚动发行版更适合开发或实验，不适合作为稳定服务器基线，除非团队明确接受频繁变更和回归测试成本。

生命周期选择不能只看“支持年限长”。如果团队没有升级演练、补丁窗口和回滚机制，十年支持也可能只是纸面承诺。选型时应同步决定：补丁多久打一次，大版本何时升级，内核更新如何验证，安全公告谁跟踪，停服窗口如何申请，回滚方式是什么。

软件生态

软件生态包括官方仓库、第三方仓库、商业软件支持、容器镜像和自动化工具适配。Debian/Ubuntu 的 APT 生态丰富，开发者资料多，云平台镜像成熟；RHEL 家族的 RPM/DNF 生态在企业软件、数据库、中间件、安全合规和厂商认证上更强；SUSE 在特定企业应用和 SAP 场景有优势。

如果生产系统依赖 Oracle、SAP、商业备份软件、EDR、安全加固工具、存储多路径软件或硬件厂商代理，不能只看发行版是否“能安装”。要确认供应商是否明确支持对应版本。未认证但勉强运行的系统，一旦出现故障，供应商可能要求先迁移到受支持平台再排查。

团队能力

发行版越稳定，越不能忽视团队熟悉度。Ubuntu/Debian 与 RHEL/Rocky 的包管理、网络配置、日志位置、安全默认值、服务名称、SELinux/AppArmor 策略、仓库管理都有差异。团队如果只熟悉 Debian/Ubuntu，却把核心生产系统全换成 RHEL，需要培训和试点；团队如果长期使用 RHEL，也不要为了“云原生流行”贸然切到 Ubuntu。

团队能力不是拒绝变化的理由，但变化要有路径。可以先在非核心环境建立新发行版基线，形成安装、补丁、备份、监控、安全和故障处理手册，再逐步推广。不要把第一台生产核心系统当作学习环境。

安全和合规

Linux 安全不只依赖发行版，但发行版会决定默认安全工具和支持能力。RHEL 家族常见 SELinux、firewalld、auditd、FIPS、SCAP、OpenSCAP 等企业安全生态；Ubuntu/Debian 常见 AppArmor、UFW、unattended-upgrades、Livepatch/Ubuntu Pro 等机制；不同发行版还会影响 CIS Benchmark、等保加固脚本、漏洞扫描插件和 EDR 支持。

如果环境涉及金融、医疗、政企、工业控制或跨境数据，选型时必须把合规要求前置。不要等系统上线后才发现安全基线只支持某些版本，或者审计工具无法识别当前系统。合规场景优先选择有明确生命周期、官方安全公告、厂商支持和行业验证案例的发行版。

云和虚拟化适配

云平台通常提供 Ubuntu、Debian、RHEL、Rocky、AlmaLinux、SLES 等官方或认证镜像。选择云镜像时，要关注镜像来源、cloud-init 支持、内核和驱动优化、默认用户、SSH 登录策略、磁盘扩容方式、网络命名规则和安全更新策略。

私有虚拟化环境还要关注 VMware Tools/open-vm-tools、QEMU guest agent、Hyper-V Linux Integration Services、云平台元数据服务和备份代理。一个发行版在裸机上稳定，不代表在所有虚拟化平台上都有最佳体验。

容器和平台工程

容器时代并没有让发行版选择消失。宿主机仍然需要内核、cgroups、namespace、iptables/nftables、SELinux/AppArmor、systemd、日志、网络和存储驱动。Kubernetes 节点常见选择包括 Ubuntu、RHEL/Rocky/Alma、Flatcar、Talos、Bottlerocket 等。传统 Linux 系列文章主要覆盖通用服务器，不深入专用不可变操作系统，但选型时要知道：容器节点更关注内核、CRI、补丁节奏和不可变交付，业务服务器更关注包生态和日常维护。

场景选择

通用云服务器

Web 服务、API 服务、轻量数据库、监控代理、自动化工具和开发测试环境，通常可以优先考虑 Ubuntu LTS 或 Debian stable。Ubuntu LTS 的优势是云镜像成熟、社区资料丰富、第三方工具适配广；Debian stable 的优势是轻量、稳定、社区治理清晰。若团队已经使用 RHEL 家族，也可以选 Rocky/Alma/RHEL 统一基线。

企业核心系统

ERP、MES、数据库、中间件、商业备份、安全代理和关键业务系统，优先考虑 RHEL、SLES 或经过企业验证的 RHEL 兼容发行版。核心问题不是“免费还是付费”，而是是否能获得供应商支持、补丁承诺、安全公告和故障升级路径。对核心系统来说，商业订阅费用往往低于长期无人负责的隐性风险。

数据库和中间件

数据库服务器不应只看发行版，还要看数据库厂商认证。PostgreSQL、MySQL、MariaDB、Redis、Kafka、Elasticsearch、Oracle、DB2、SAP HANA 等产品对 OS 版本、内核参数、文件系统和依赖包有不同要求。若使用商业数据库，先查官方支持矩阵；若使用开源数据库，也应选择社区资料和仓库支持良好的发行版。

开发工作站

开发工作站可以比生产环境更灵活，但仍建议和生产基线保持可解释关系。后端服务跑在 Ubuntu LTS，开发机使用 Ubuntu Desktop 或 WSL Ubuntu 通常更容易复现；生产跑 RHEL/Rocky，开发容器和 CI 镜像最好也覆盖 RPM 生态。Arch、Fedora、NixOS 可以作为个人开发环境，但团队交付物仍应通过容器或 CI 保证一致。

边缘和工业现场

边缘节点和工业现场服务器需要关注断网运行、只读根文件系统、远程升级、硬件驱动、串口/网口/采集卡兼容、低资源占用和安全加固。Ubuntu Core、Debian minimal、RHEL for Edge、SUSE Edge 等都有对应方向。传统服务器发行版也能用于边缘，但要补上自动恢复、离线仓库、镜像回滚和现场维护流程。

决策框架

发行版选择可以用一张表完成初筛：

真正落地时，建议采用“三层基线”。

第一层是生产标准基线。它用于核心业务服务器、数据库、中间件和长期运行系统。要求生命周期清楚、补丁路径清楚、监控备份标准清楚。可以是一到两个发行版，例如 RHEL/Rocky 与 Ubuntu LTS。

第二层是平台基线。它用于 Kubernetes 节点、虚拟化宿主机、云镜像、CI Runner、边缘节点等。平台基线不一定和业务服务器相同，但必须有自动化安装、补丁和回滚方案。

第三层是实验基线。它用于开发、测试、POC、学习和新技术验证。实验基线可以更灵活，但不能直接进入生产。只有通过安全、运维、监控、备份和故障演练后，才能提升为生产或平台基线。

标准化基线如何设计

发行版一旦选定，就要转换成可执行的标准化基线。很多团队只在文档中写“生产使用 Ubuntu LTS”或“数据库使用 RHEL”，但没有定义镜像、仓库、补丁、账号、网络、安全、日志、监控和备份标准。这样的选型仍然落不到运维能力上。

标准化基线至少包含六类内容。第一是镜像基线，明确使用哪一个官方 ISO、云镜像或内部镜像，镜像如何校验、谁负责更新、旧镜像何时下架。第二是初始化基线，明确主机名、时区、NTP、DNS、SSH、sudo、普通账号、服务账号、防火墙、安全审计和基础包。第三是软件仓库基线，明确使用官方源、内部镜像源、第三方源还是离线仓库，以及仓库变更如何审批。第四是安全基线，明确 SELinux/AppArmor、防火墙、密码策略、SSH 策略、审计日志、漏洞扫描和安全补丁窗口。第五是运维基线，明确日志、监控、备份、告警、容量阈值和故障处理方式。第六是升级基线，明确小版本补丁、大版本升级、内核更新和回滚策略。

基线设计不要追求“一份配置适用于所有场景”。更好的方式是按服务器类型分层。例如：

这样做的好处是：发行版选择不再停留在“装哪个系统”，而是变成“这个系统进入哪条运维流水线”。后续 Ansible、Packer、Terraform、cloud-init、Kickstart、Preseed、Autoinstall 都可以围绕基线展开。

风险矩阵

发行版选型应显式记录风险。下面是一张实用矩阵：

风险矩阵不是形式文档。每一次新增发行版、升级主版本、引入第三方仓库、变更内核或改动安全策略，都应该重新评估风险。尤其是数据库、虚拟化宿主机、Kubernetes 节点和工业现场服务器，不应直接沿用普通 Web 服务器的发行版策略。

生命周期治理

发行版生命周期治理需要落到日历和责任人。以 Ubuntu LTS 为例，官方资料显示 24.04 LTS 的标准安全维护到 2029 年 5 月，26.04 LTS 的标准安全维护到 2031 年 5 月。这个日期不应只出现在发行说明里，而应该进入 CMDB、资产台账、补丁计划和年度预算。

建议为每个发行版基线维护以下字段：

如果使用 Debian stable，要关注 stable、oldstable 和 LTS 团队维护节奏；如果使用 RHEL，要关注 Red Hat 生命周期、订阅、EUS/ELS 等支持政策；如果使用兼容发行版，要关注社区维护承诺和与 RHEL 的兼容边界。生命周期治理的目标不是追逐最新，而是避免临近停服才被迫迁移。

样例决策

下面给出几个常见决策样例，帮助把选型原则落到实际场景。

场景一：一家中型制造企业建设内部 Web 系统、监控平台和自动化脚本平台。团队熟悉 Ubuntu，系统大多运行在 VMware 和公有云。此时可以选择 Ubuntu LTS 作为通用服务器基线，配合内部镜像、Ansible 初始化、定期补丁和统一监控。数据库如果使用开源 PostgreSQL，也可以继续使用 Ubuntu LTS；如果引入商业数据库，则按数据库厂商认证重新评估。

场景二：集团 ERP、核心数据库、商业备份和安全代理都要求 RHEL 支持。此时不应为了节省订阅费用直接替换为任意兼容发行版。可以把 RHEL 作为核心系统基线，把 Rocky/Alma 用于非核心测试或通用工具服务器，但必须把支持边界写清楚。

场景三：研发团队希望使用最新编译器、容器运行时和开发工具。生产仍是 RHEL/Rocky 或 Ubuntu LTS。此时可以允许 Fedora、Ubuntu interim 或 Arch 出现在个人开发环境，但 CI 镜像和生产构建环境必须覆盖生产基线。否则“开发可用、生产不可用”的问题会频繁出现。

场景四：边缘工厂节点需要长期离线运行，只有偶尔远程维护窗口。此时发行版选择应优先考虑镜像回滚、离线仓库、自动恢复和远程诊断，而不是桌面体验或最新软件。可以选企业边缘方案，也可以用精简 Debian/Ubuntu/RHEL 基线，但必须补齐现场恢复和离线升级流程。

选型评审会议怎么开

发行版选择最好通过一次轻量评审完成，而不是由单个人拍板。参会角色包括基础设施负责人、安全负责人、应用负责人、数据库或中间件负责人、运维自动化负责人和业务系统代表。会议不需要讨论每个发行版的历史，而要逐项确认决策依据。

推荐议程如下：

1. 明确本次选型覆盖范围：生产、测试、开发、云、虚拟化、容器、边缘是否都在范围内。
2. 列出关键应用和供应商支持要求。
3. 列出现有团队能力和历史运行经验。
4. 对比候选发行版生命周期和补丁策略。
5. 确认安全基线和合规要求。
6. 确认镜像、仓库、自动化和回滚方案。
7. 形成结论：生产标准基线、平台基线、实验基线和例外流程。

评审输出应是一份短文档，包含选择结论、适用范围、禁止事项、例外申请方式、下一次复核日期。不要只留下会议纪要，否则半年后没人知道为什么当初这样选。

选型后的落地验收

发行版选型真正完成的标志，不是文档写完，而是第一批标准服务器能够按同一流程交付、运维和恢复。建议把落地验收拆成五类。

第一类是安装验收。使用标准 ISO、云镜像或内部镜像创建一台全新服务器，确认分区、网络、主机名、时区、NTP、SSH、初始用户、软件仓库和基础包都符合基线。安装流程必须可重复，不能依赖某个管理员临场记忆。

第二类是安全验收。检查 root 登录策略、sudo 规则、SSH 密钥、密码策略、防火墙、SELinux/AppArmor、审计日志、漏洞扫描、补丁状态和安全更新源。安全验收要关注默认值，因为发行版默认配置常常会随着版本变化而变化。

第三类是运维验收。确认监控代理、日志采集、备份代理、时间同步、磁盘容量、系统服务、告警规则和故障诊断命令可用。一个发行版如果只有安装流程，没有监控和备份基线，不能进入生产。

第四类是应用验收。选择一个代表性应用部署到该发行版上，验证依赖包、服务管理、日志路径、端口、防火墙、用户权限、目录权限、启动顺序和升级过程。应用验收能发现很多文档阶段看不到的问题，例如包名不同、库版本不同、SELinux 策略阻断、systemd unit 依赖不完整。

第五类是恢复验收。模拟服务器损坏、误删配置、补丁失败、磁盘满、网络配置错误等场景，确认备份和回滚路径能工作。发行版基线必须支持故障恢复，否则长期稳定只是理论。

例外管理

再严格的发行版标准，也会遇到例外。某个商业软件只支持特定 OS，某个硬件驱动只在旧内核上稳定，某个边缘设备只能运行厂商定制系统，某个研发团队需要新工具链。这些情况不应简单禁止，也不能无记录放行。

例外管理至少记录五项内容：为什么需要例外，例外影响哪些系统，风险是什么，补救措施是什么，何时复核或退出。比如某应用必须运行在 Ubuntu 22.04，而企业标准基线已经切到 24.04，可以允许它保留在旧版本，但必须记录维护结束时间、补丁来源、升级计划和业务责任人。

例外不应永久存在。每个例外都应该有复核日期。复核时要判断原原因是否仍然成立，供应商是否已经支持新版本，业务是否仍然需要该系统，是否可以迁移到标准基线。没有复核机制的例外会逐渐变成新的标准外系统群。

与后续系统管理工作的关系

发行版选择会直接影响本系列后续所有章节。系统安装与初始化要根据发行版决定安装器、分区、网络、仓库和初始化工具。用户与权限管理要根据 sudo/wheel、PAM、NSS、SELinux/AppArmor、默认 UID/GID 策略调整。文件系统管理要考虑 ext4、XFS、Btrfs、LVM、快照和扩容方式。软件包管理会完全受 APT、DNF/YUM、Zypper 或其他包管理器影响。

进程管理和服务管理也与发行版有关。现代主流服务器发行版都使用 systemd，但 unit 文件位置、默认服务、日志策略、网络依赖和安全沙箱配置可能不同。网络配置更是差异明显：Ubuntu Server 常见 Netplan 与 systemd-networkd/NetworkManager 组合，RHEL 家族强调 NetworkManager、nmcli、nmstate 和 firewalld，Debian 可根据安装环境采用不同网络管理方式。

因此，选型文档不应孤立存放。它应该成为安装手册、权限基线、包管理规范、服务管理规范、网络配置规范和补丁策略的上游依据。后续每一篇文章都会在这个基础上展开。

最小可行标准

如果组织还没有成熟的 Linux 标准，可以先定义一个最小可行标准。它不需要覆盖所有场景，但必须能防止最常见的混乱：

这个最小标准可以在一两周内建立，后续再逐步扩展到合规、安全加固、自动化、镜像流水线和生命周期治理。

复核周期和指标

发行版标准不能长期不变。建议每半年做一次轻量复核，每年做一次完整复核。轻量复核关注当前版本是否仍在维护期、是否有关键漏洞长期未修复、内部镜像是否过旧、例外系统是否失控。完整复核则要重新评估业务系统、云平台、容器平台、安全合规、供应商支持和团队能力是否发生变化。

可以用以下指标判断发行版治理是否有效：

这些指标不需要一开始就很复杂，但必须能暴露趋势。如果例外数量持续上升，说明标准过严或执行失控；如果补丁及时率低，说明测试和回滚机制不足；如果自动化交付率低，说明选型还没有真正转化为运维能力。

当这些指标能够被持续采集和复盘时，发行版选择才算从一次性决策变成了可治理的基础设施能力，也能支撑后续审计。

所有结论都应归档到基础设施标准库，便于新项目复用和持续改进，减少重复决策成本和维护风险持续积累。

迁移和替换

发行版选择不是一次性决定。CentOS Linux 停止维护、应用认证变化、云平台镜像策略调整、企业合规要求升级，都可能触发迁移。迁移时不要只做系统重装，而要评估应用依赖、包名差异、服务名称、配置路径、SELinux/AppArmor 策略、日志路径、网络配置、定时任务、内核参数和备份恢复。

从 CentOS Linux 迁移到 Rocky/Alma/RHEL，通常包生态相近，但仍要测试仓库、第三方 RPM、内核模块、商业代理和 SELinux 策略。从 Ubuntu 20.04/22.04 升级到 24.04/26.04，要关注 Python、OpenSSL、systemd、Netplan、内核和第三方 PPA。Debian major upgrade 要仔细阅读 release notes，并在快照或备份可恢复的条件下进行。

迁移前至少做四件事：冻结当前配置清单，准备完整备份和回滚方案，建立同规格测试环境，运行应用和监控验收。不要把发行版升级和应用大版本升级、数据库迁移、网络改造放在同一个窗口，除非已经完成充分演练。

实操建议

1. 建立候选清单

不要让候选清单超过三类。比如：

生产核心系统：RHEL / Rocky Linux
通用云服务器：Ubuntu LTS / Debian stable
开发与试验：Ubuntu LTS / Fedora / Debian testing

候选过多会让自动化、镜像、补丁和安全基线复杂化。少量标准发行版能显著降低运维成本。

2. 做小规模试点

选三类典型工作负载：Web/API 服务、数据库或中间件、运维代理组合。分别验证安装、补丁、日志、监控、备份、安全扫描、权限管理、网络配置和恢复流程。试点不是“能启动服务”就结束，而是要验证完整生命周期。

3. 固化标准镜像

标准镜像应包含基础包、时区、NTP、SSH、账号策略、sudo、日志、监控代理、防火墙、自动更新策略、审计、备份代理和基线检查脚本。镜像必须有版本号和变更记录。不要让每台服务器都靠人工安装形成“手工差异”。

4. 建立升级节奏

每个发行版基线都要有生命周期表。至少记录当前版本、标准维护结束时间、扩展维护结束时间、计划升级窗口、业务负责人和技术负责人。发行版接近维护结束时，不应临时救火，而应提前一年进入迁移评估。

常见误区

第一，只看“免费”。免费发行版本身没有问题，但生产成本不只包括订阅费用，还包括补丁、故障、合规、培训、迁移和供应商支持成本。

第二，只看“最新”。新内核和新工具链对开发有吸引力，但核心生产系统更重视变更可控。需要新功能时，可以用特定平台基线或容器镜像解决，不一定要把所有服务器都滚动更新。

第三，把兼容发行版等同于商业支持。Rocky/Alma 等 RHEL 兼容发行版适合很多场景，但它们不是 RHEL 订阅。若商业软件明确要求 RHEL 支持，应按厂商条款执行。

第四，不区分服务器和桌面。桌面体验好不代表服务器基线合适。服务器发行版要看远程管理、安全补丁、自动化、日志、监控和长期维护。

第五，忽视组织能力。发行版最终由团队维护。没有人熟悉、没有手册、没有自动化、没有回滚，再好的发行版也会变成风险。

选型清单

最终决策前，至少完成以下检查：

总结

Linux 发行版选择的核心不是“谁更好”，而是谁更适合你的业务、团队和生命周期。通用服务器可以优先考虑 Ubuntu LTS 或 Debian stable；企业核心系统更适合 RHEL、SLES 或经过验证的 RHEL 兼容发行版；开发和实验环境可以更灵活；边缘和容器节点要按平台特性单独评估。

本系列后续文章会以常见企业服务器为背景，继续讲系统安装与初始化、用户权限、文件系统、软件包、进程、服务和网络配置。无论选择哪个发行版，都应把“可维护、可审计、可升级、可恢复”作为第一原则。

参考资料

• Ubuntu Release Cycle，检索日期 2026-06-12，https://ubuntu.com/about/release-cycle
• Ubuntu Server installation documentation，检索日期 2026-06-12，https://ubuntu.com/server/docs/how-to/installation/
• Debian stable release information，检索日期 2026-06-12，https://www.debian.org/releases/stable/
• Red Hat Enterprise Linux 10 Documentation，检索日期 2026-06-12，https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10
• Red Hat Enterprise Linux networking documentation，检索日期 2026-06-12，https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/configuring_and_managing_networking/index