Fedora VPS服务器为何每13个月就要升级
Fedora每个版本仅获约13个月安全更新,服务器通常每年需升级一次。本文比较Fedora、Ubuntu LTS和AlmaLinux的维护成本,并说明何时值得选择Fedora。
Fedora 版本会获得多长时间的安全更新?
Fedora 服务器大约每年需要升级一次版本,直到该服务器停止使用为止。Fedora 大约每六个月发布一个新版本。每个版本会一直获得支持,直到后两个版本发布约四周后,整个支持周期约为 13 个月。超过该日期后,该版本将不再获得任何安全修复。服务器仍可继续运行,但其中的软件包将不再有人修补。
具体日期如下。截至 2026 年 8 月,受支持的版本是 Fedora 43 和 Fedora 44。Fedora 44 于 2026 年 4 月 28 日发布,计划于 2027 年 6 月结束生命周期。Fedora 42 于 2025 年 4 月发布,并于 2026 年 5 月结束生命周期,也就是 Fedora 44 发布四周后。因此,从 Fedora 42 镜像创建的服务器在 13 个月后便失去支持,期间并没有任何操作失误。
Fedora 与 LTS 的支持周期(以月计)
LTS 表示长期支持,即供应商持续提供多年补丁、而不是仅提供数月补丁的版本。EOL 表示生命周期结束,即停止提供补丁的日期。以下是各项目针对当前可安装版本公布的信息。
The data behind this chart
[
{
"distro": "Fedora 44",
"support_window": 13,
"upgrades_per_decade": 10
},
{
"distro": "Ubuntu 26.04 LTS",
"support_window": 60,
"upgrades_per_decade": 2
},
{
"distro": "Debian 13 stable",
"support_window": 36,
"upgrades_per_decade": 3
},
{
"distro": "AlmaLinux 10",
"support_window": 120,
"upgrades_per_decade": 1
}
]Fedora 每个版本提供 13 个月的支持。Ubuntu LTS 提供 60,而 AlmaLinux 等企业重构版提供 120。第二列可以理解为维护成本。按十年计算,Fedora 大约需要进行 10 次完整操作系统升级,而 Ubuntu LTS 需要 2 次。Debian 的 36 个月是常规安全支持周期,另外还有独立的 LTS 团队将大多数版本的支持时间延长到约五年。
这些是截至 August 2026 核实的官方支持周期,不是实测运行时间。不同版本节奏的原因,请参阅服务器上 Ubuntu LTS 与中间版本的区别。这里需要关注的是每种选择会为您带来多少维护工作。
Fedora 版本升级实际涉及的内容
Fedora 41 起默认使用 DNF 5 作为包管理器,dnf 会调用它。system-upgrade 命令属于 dnf5 本身,因此无需先安装插件。从当前版本开始,并先安装全部更新:
sudo dnf upgrade --refresh
sudo reboot重启很重要,因为升级会根据已安装且正在运行的内容解析依赖。如果内核或 glibc 更新只完成了一半,下一步就更难判断问题所在。现在暂存新版本。将 44 替换为要升级到的版本:
sudo dnf system-upgrade download --releasever=44此命令会解析整个事务并下载所有软件包,但不会修改正在运行的系统。小型服务器通常需要下载几千个软件包,占用 1 到 3 GB 空间。如果 dnf 无法解析事务,它会在这里停止,并指出阻塞事务的软件包。这是较好的情况,因为故障发生时机器仍在运行,您仍有 shell 可用。
然后执行升级:
sudo dnf offline status
sudo dnf system-upgrade rebootdnf offline status 确认事务已暂存并等待执行。dnf system-upgrade reboot 会将机器重启到离线事务环境:系统以最小化启动方式运行 RPM 事务。之所以采用这种方式,是因为在正在运行的服务下替换 glibc 和 systemd,可能导致系统处于半安装状态。整个事务期间服务器都无法访问。小型 VPS 通常需要几分钟,完成后机器会再次重启并进入新版本。请预留 2 次重启的时间,并预计 SSH 在此期间不会响应。
系统恢复后:
cat /etc/fedora-release
sudo dnf system-upgrade log --number=-1
sudo dnf distro-sync
sudo dnf repoquery --extras/etc/fedora-release 应输出类似 Fedora release 44 (Forty Four) 的行。log 子命令会输出本次离线启动期间的事务日志。这是您无法使用 shell 时,记录系统执行内容的唯一日志。distro-sync 会将遗留内容更新到新版本对应的软件包版本。repoquery --extras 会列出已安装但不再属于任何已启用仓库的软件包。您可以在这里找到那些没有为新版本发布软件包的仓库所留下的内容。
在下载步骤之前创建磁盘快照。事务在您无法查看屏幕时运行。如果离线启动期间失败,SSH 不会恢复,您只能通过服务商提供的控制台、VNC 或串口访问系统。请在开始前确认您有可用的控制台或快照,不要等到失败后才确认。
还有一项经常被忽略的检查:
sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'如果软件包提供了新的默认配置文件,而您修改过旧文件,RPM 不会覆盖您的文件。它会将软件包提供的版本写入旁边的 .rpmnew 文件。因此,sshd 或 nginx 会继续按照旧版本的配置运行,而新的默认配置仍未被读取,留在磁盘上。每次升级后都应读取这些文件。安装 rpmconf 并运行 sudo rpmconf -a,即可逐个查看这些文件及其差异。
第三方软件仓库会导致升级失败
Fedora 自带的软件包会在发布当天统一更新。Fedora 之外的软件包则按各自供应商的计划发布。大多数供应商仓库会在 URL 中包含 $releasever,因此升级后,dnf 会立即请求一个可能尚不存在的路径。
列出当前配置的软件仓库:
sudo dnf repo list --enabled
grep -R -e baseurl -e metalink /etc/yum.repos.d/对于每个非 Fedora 官方仓库,在执行升级前,先针对目标版本测试:
sudo dnf --releasever=44 --repo=docker-ce-stable makecache如果供应商已为该版本发布仓库,dnf 会下载元数据并安静退出。如果尚未发布,您会看到类似 https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml 的路径返回 404,之后的 system-upgrade download 也会因同样的原因失败。Fedora 发布后的最初几周内,这是升级无法开始的最常见原因。
您有两种处理方式。等待几周,直到供应商发布对应仓库,通常这是正确的选择。或者禁用该仓库后再升级:
sudo dnf system-upgrade download --releasever=44 --disable-repo=docker-ce-stable禁用仓库不会删除其中的软件包。这些软件包仍会保持已安装状态,但不再由仓库管理;如果它们阻止事务执行,dnf 会明确提示。添加 --allowerasing 后,dnf 可以删除已安装的软件包来解决冲突,因此接受前请先查看删除列表。很多人就是在这里误删了原本想保留的数据库服务器。
错过支持窗口的 Fedora 服务器会发生什么
当天本身不会发生任何事情。下次操作软件包管理器时,问题才会出现。生命周期结束的版本会从镜像网络移入归档,因此 dnf upgrade 在获取元数据时失败,针对该版本的 metalink URL 返回 404:
Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-42&arch=x86_64服务器仍会处理网络流量,这正是问题隐蔽且危险的原因。它不会再接收安全更新。它也无法安装任何内容,因此当 OpenSSH 或 nginx 发布安全公告时,您没有受支持的方式为其打补丁。
仍然可以恢复,但过程缓慢。您可以将软件包仓库指向 Fedora 的归档地址 https://dl.fedoraproject.org/pub/archive/fedora/linux/,然后从那里升级。Fedora 要求每次跨越一个或两个版本,因此落后四个版本的服务器需要连续执行多次升级。每次升级都有失败的可能,而且每次都要在离线启动环境中盲目进行。对于 VPS,使用当前镜像重建服务器并迁移数据通常更快、更安全;这与新 VPS 上的前十分钟是同一项工作。
自动更新会为当前发行版安装补丁,但不会升级发行版。
Fedora 可以按定时器安装更新:
sudo dnf install -y dnf5-plugin-automatic
sudo systemctl enable --now dnf5-automatic.timer设置位于 /etc/dnf/automatic.conf,并会覆盖 /usr/share/dnf5/dnf5-plugins/automatic.conf 中随软件提供的默认值。apply_updates 默认关闭,因此在开箱配置下,定时器只会下载更新,不会安装任何内容。upgrade_type 用于在 default 和 security 之间进行选择。reboot 接受 never、when-changed 或 when-needed。
这样可以让系统在当前发行版内保持最新。它不会将 Fedora 43 升级到 Fedora 44,因为版本升级是独立且需要明确执行的操作,并且会重启系统以执行离线事务。这就是它与 LTS 的实际差距。在 Ubuntu 上,无人值守安全更新 可以让系统在完整的五年支持周期内持续获得更新,同时完全不改变版本;版本升级本身则是计划任务,例如每隔几年执行一次 从 24.04 升级到 26.04。
Fedora 适合作为服务器的情况
当系统的新版本特性是首要需求时,Fedora 是不错的选择。
- 您需要的内核或用户空间版本高于任何 LTS 版本提供的版本:例如使用较新的硬件,或使用距离企业版发布仍有一年的容器和 systemd 技术栈。Fedora 还会在一个版本的生命周期内继续迁移到新的上游内核,因此这不只是安装时的一次性优势。
- 您正在验证即将进入 RHEL(Red Hat Enterprise Linux)的内容。Fedora 为 CentOS Stream 提供基础,而 CentOS Stream 又为 RHEL 提供基础。因此,目前可以在 Fedora 上构建和运行的软件,正在针对未来几年的企业平台进行测试。
- 这台机器的设计用途就是短期运行。两个月后即被销毁的构建运行器或测试机,不会等到生命周期结束日期。此逻辑同样适用于交给编码代理的临时 VM,因为这类机器的重建频率远高于 Fedora 的发布频率。
- 有人负责升级。由指定负责人管理,并已加入日历计划的服务器适合运行 Fedora。对于所有人都已遗忘的服务器,Fedora 并不合适。
稳定基础上的当前软件包:折中方案
大多数希望在服务器上使用 Fedora 的人,需要的是两三个当前版本的软件包,而不是当前版本的整个操作系统。这两者可以分开处理。使用 LTS 版本或企业版重构发行版作为基础,然后只在实际需要的地方引入新软件。容器镜像可以在无需为应用升级主机的情况下,提供当前版本的应用(在 VPS 上运行 Docker)。对于 PostgreSQL 或 nginx 等需要关注的单个软件包,也可以使用厂商软件仓库单独更新该软件包,而不改动基础系统。
这种取舍的利弊都很明确。容器可以在主机的旧内核上提供新的用户空间,因此当你需要更新的是内核时,容器无法解决问题。厂商软件仓库可以在基础系统上提供一个新软件包,但该基础系统经过厂商测试的程度较低。两种方案都会让基础系统继续按照 LTS 的周期获取安全更新,而在 Fedora 上,每年都需要为这个周期安排一次维护窗口。
如果确实选择 Fedora 作为服务器系统,请将升级周期加入日历。新版本发布后,等待几周,让厂商软件仓库完成同步;然后创建快照、执行升级,并确认各项服务已恢复运行。这个流程每年大约耗时 1 小时,而且可行。真正容易出问题的情况,是只有在系统已经出现故障后,才想起原本应该执行升级。
FAQ
Fedora 版本支持多长时间?
大约 13 个月。Fedora 大约每六个月发布一个版本,并支持每个版本,直到其后第二个版本发布约四周后。Fedora 44 于 28 April 2026 发布,计划于 June 2027 结束生命周期。该日期过后,此版本将不再接收安全更新,其软件包也会从镜像站移至 Fedora 的归档站点。
可以跳过一个 Fedora 版本,一次升级两个版本吗?
可以,但有一定限制。dnf system-upgrade download --releasever= 接受领先当前版本一个或两个版本的目标版本,一次跨越两个版本正是每年升级一次的方式。跨越更多版本不属于受支持的路径,而且每多跨越一个版本,软件包重命名或配置格式变更导致事务失败的概率就会增加。如果计算机已经落后多个版本且版本已结束生命周期,通常直接使用当前镜像重建系统,比连续升级更快。
Fedora 服务器达到生命周期结束后会发生什么?
服务器会继续运行,但不再接收补丁。下一次 dnf upgrade 会因版本对应的 metalink URL 返回 404 而失败,因为已结束生命周期的版本会被移至 dl.fedoraproject.org 归档站点。您可以将软件源文件重新指向该归档站点,再分阶段升级;也可以使用受支持的版本重建服务器。在完成其中一种操作前,安全更新无法到达该计算机,也无法安装任何软件包。
Fedora 不适合用作生产服务器吗?
将 Fedora 作为默认选择并不合适,但在有明确理由时可以使用。代价是每年都必须对操作系统进行完整升级,而且需要长期在您可能不希望改动的服务器上执行此操作。如果您需要比 LTS 版本提供的更新内核或用户空间,或者服务器按设计只会短期运行,可以选择 Fedora。如果您希望多年为服务器安装补丁而不更改版本,应选择 LTS 或企业重构版。