Fedora trên VPS: vòng đời 13 tháng và chi phí nâng cấp

Fedora được cập nhật bảo mật trong bao lâu?

Một server Fedora cần nâng cấp phiên bản khoảng mỗi năm một lần, trong suốt thời gian máy còn được sử dụng. Fedora phát hành phiên bản mới khoảng 6 tháng một lần. Mỗi phiên bản được hỗ trợ đến khoảng 4 tuần sau khi phiên bản mới hơn 2 phiên bản được phát hành. Như vậy, phiên bản đó nhận được bản cập nhật trong khoảng 13 tháng. Sau thời điểm này, phiên bản không còn nhận bất kỳ bản sửa lỗi bảo mật nào. Máy vẫn tiếp tục chạy, nhưng không còn ai vá các package trên đó.

Các mốc thời gian giúp thấy rõ điều này. Tính đến tháng 8 năm 2026, các phiên bản được hỗ trợ là Fedora 43 và Fedora 44. Fedora 44 được phát hành vào ngày 28 tháng 4 năm 2026 và dự kiến hết vòng đời vào tháng 6 năm 2027. Fedora 42 được phát hành vào tháng 4 năm 2025 và hết vòng đời vào tháng 5 năm 2026, 4 tuần sau khi Fedora 44 được phát hành. Vì vậy, một server được dựng từ image Fedora 42 đã hết thời hạn hỗ trợ sau 13 tháng, dù không ai làm sai điều gì.

Fedora so với bản LTS, tính theo tháng

LTS là viết tắt của long term support: một bản phát hành được nhà cung cấp tiếp tục phát hành bản vá trong nhiều năm thay vì vài tháng. EOL là viết tắt của end of life, tức thời điểm ngừng phát hành bản vá. Dưới đây là thông tin mỗi dự án công bố cho bản phát hành mà bạn sẽ cài đặt hiện nay.

[
  {
    "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 hỗ trợ mỗi bản phát hành trong 13 tháng. Ubuntu LTS hỗ trợ trong 60, còn một bản rebuild dành cho doanh nghiệp như AlmaLinux hỗ trợ trong 120. Hãy xem cột thứ hai là khối lượng công việc phải trả. Trong mười năm, Fedora yêu cầu khoảng 10 lần nâng cấp toàn bộ hệ điều hành, so với 2 lần trên Ubuntu LTS. Con số 36 tháng của Debian là thời gian hỗ trợ bảo mật tiêu chuẩn; một nhóm LTS riêng sẽ kéo dài thời gian hỗ trợ hầu hết bản phát hành lên khoảng năm năm.

Đây là các khoảng thời gian hỗ trợ được công bố và đã được kiểm tra vào tháng 8 năm 2026, không phải uptime đo được. Lý do các chu kỳ này khác nhau được trình bày trong sự khác biệt giữa Ubuntu LTS và các bản phát hành interim trên server. Điều quan trọng ở đây là khối lượng công việc mà mỗi lựa chọn tạo ra cho bạn.

Nâng cấp phiên bản Fedora thực sự gồm những gì

DNF 5 là package manager mặc định kể từ Fedora 41, và dnf chạy package manager này. Lệnh system-upgrade là một phần của chính dnf5, nên bạn không cần cài plugin trước. Bắt đầu từ release hiện tại, đã cài đầy đủ các bản cập nhật:

sudo dnf upgrade --refresh
sudo reboot

Việc reboot rất quan trọng vì quá trình nâng cấp dựa trên những gì đã được cài và đang chạy. Vì vậy, kernel hoặc glibc mới chỉ được áp dụng một phần sẽ khiến bước tiếp theo khó phân tích hơn. Bây giờ hãy chuẩn bị release mới. Thay 44 bằng release bạn muốn nâng cấp lên:

sudo dnf system-upgrade download --releasever=44

Lệnh này giải quyết toàn bộ transaction và tải xuống mọi package, nhưng không thay đổi gì trên hệ thống đang chạy. Với một server nhỏ, hãy dự kiến vài nghìn package và từ một đến ba gigabyte dữ liệu. Nếu dnf không thể giải quyết transaction, nó sẽ dừng tại đây và nêu tên package gây lỗi. Đây là trường hợp tốt, vì lỗi xảy ra khi máy vẫn đang hoạt động và bạn vẫn còn shell.

Sau đó chạy lệnh:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status xác nhận transaction đã được chuẩn bị và đang chờ. dnf system-upgrade reboot restart máy vào một offline transaction: một lần boot tối giản, trong đó RPM transaction tự chạy. Cơ chế này cần thiết vì thay thế glibc và systemd bên dưới các service đang chạy có thể khiến hệ thống được cài đặt dở dang. Server sẽ không thể truy cập trong toàn bộ transaction, thường là vài phút trên một VPS nhỏ, rồi reboot lần nữa vào release mới. Hãy chuẩn bị cho 2 lần reboot và khoảng thời gian SSH không phản hồi.

Khi máy hoạt động trở lại:

cat /etc/fedora-release
sudo dnf system-upgrade log --number=-1
sudo dnf distro-sync
sudo dnf repoquery --extras

/etc/fedora-release sẽ in ra một dòng tương tự Fedora release 44 (Forty Four). Subcommand log in transaction log của offline boot. Đây là bản ghi duy nhất về những gì đã xảy ra trong lúc bạn không có shell. distro-sync cập nhật mọi thứ còn sót lại lên các version của release mới. repoquery --extras liệt kê những package đã cài nhưng không còn nằm trong bất kỳ repository nào đang enable. Đây là nơi bạn tìm các package còn sót lại từ repository chưa từng phát hành package cho release mới.

Hãy snapshot disk trước bước download. Transaction chạy trong lúc bạn không thể xem màn hình. Nếu nó fail trong offline boot, SSH sẽ không kết nối lại và cách duy nhất để truy cập là dùng console do provider cung cấp, VNC hoặc serial. Hãy xác nhận bạn có console hoặc snapshot trước khi bắt đầu, không phải sau đó.

Có thêm một bước kiểm tra mà nhiều người bỏ qua:

sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'

Khi một package phát hành file cấu hình mặc định mới và bạn đã chỉnh sửa file cũ, RPM sẽ không ghi đè lên file của bạn. Nó ghi version đi kèm package bên cạnh file đó dưới tên .rpmnew. Vì vậy sshd hoặc nginx của bạn vẫn hoạt động đúng như trên release cũ, trong khi các giá trị mặc định mới nằm trên disk nhưng chưa được đọc. Hãy đọc các file này sau mỗi lần nâng cấp. Cài rpmconf rồi chạy sudo rpmconf -a để xem lần lượt từng file và phần khác biệt.

Các repository bên thứ ba là nguyên nhân làm hỏng quá trình nâng cấp

Các package của Fedora được cập nhật đồng bộ vào ngày phát hành. Những package bên ngoài Fedora được cập nhật theo lịch của nhà cung cấp. Hầu hết repository của nhà cung cấp đều đặt $releasever trong URL, vì vậy ngay khi bạn nâng cấp, dnf sẽ truy vấn một đường dẫn có thể chưa tồn tại.

Liệt kê các repository hiện có:

sudo dnf repo list --enabled
grep -R -e baseurl -e metalink /etc/yum.repos.d/

Với mỗi repository không thuộc Fedora, hãy kiểm tra repository đó với bản release đích trước khi thực hiện nâng cấp:

sudo dnf --releasever=44 --repo=docker-ce-stable makecache

Nếu nhà cung cấp đã phát hành repository cho release đó, dnf sẽ tải metadata rồi thoát mà không báo lỗi. Nếu chưa, bạn sẽ nhận lỗi 404 cho một đường dẫn như https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml, và chính lỗi này sẽ khiến bước system-upgrade download sau đó thất bại. Trong vài tuần đầu sau khi Fedora phát hành một release mới, đây là nguyên nhân phổ biến nhất khiến quá trình nâng cấp không bắt đầu được.

Bạn có hai lựa chọn. Chờ vài tuần để nhà cung cấp phát hành repository, đây thường là lựa chọn đúng. Hoặc nâng cấp mà không dùng repository đó:

sudo dnf system-upgrade download --releasever=44 --disable-repo=docker-ce-stable

Vô hiệu hóa một repository không xóa các package của repository đó. Các package vẫn được cài đặt nhưng không còn được quản lý, và nếu chúng chặn transaction, dnf sẽ báo rõ. Thêm --allowerasing cho phép dnf gỡ các package đã cài để giải quyết xung đột, vì vậy hãy đọc danh sách package bị gỡ trước khi chấp nhận. Đây là danh sách khiến nhiều người vô tình mất database server mà họ định giữ lại.

Một máy chủ Fedora bỏ lỡ thời hạn này sẽ gặp chuyện gì

Vào đúng ngày đó thường không có gì xảy ra. Lỗi xuất hiện vào lần tiếp theo bạn dùng package manager. Các bản phát hành đã hết vòng đời được chuyển khỏi mirror network vào kho lưu trữ, nên dnf upgrade bị lỗi khi tải metadata, với mã 404 trên URL metalink của bản phát hành bạn đang dùng:

Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-42&arch=x86_64

Máy vẫn tiếp tục phục vụ network traffic, nên lỗi này vừa âm thầm vừa nguy hiểm. Máy không còn nhận security update. Máy cũng không thể cài thêm gì, vì vậy khi có advisory cho OpenSSH hoặc nginx, bạn không có cách được hỗ trợ để vá hệ thống.

Vẫn có thể xử lý, nhưng sẽ mất thời gian. Bạn có thể trỏ lại repository đến archive của Fedora tại https://dl.fedoraproject.org/pub/archive/fedora/linux/ rồi nâng cấp từ đó. Fedora yêu cầu mỗi lần nâng cấp chỉ đi qua một hoặc hai bản phát hành, nên một máy đã chậm 4 bản phát hành sẽ phải nâng cấp qua nhiều bước liên tiếp. Mỗi bước đều có khả năng thất bại riêng và đều phải thực hiện mà không có hỗ trợ trong một lần boot offline. Trên VPS, dựng lại máy bằng image hiện tại rồi chuyển dữ liệu sang thường là cách ngắn hơn và an toàn hơn. Đây cũng chính là công việc được mô tả trong 10 phút đầu tiên trên một VPS mới.

Cập nhật tự động vá một bản phát hành. Chúng không bao giờ nâng cấp bản phát hành đó.

Fedora có thể cài đặt các bản cập nhật theo timer:

sudo dnf install -y dnf5-plugin-automatic
sudo systemctl enable --now dnf5-automatic.timer

Các thiết lập nằm trong /etc/dnf/automatic.conf. File này ghi đè các giá trị mặc định do phần mềm cung cấp trong /usr/share/dnf5/dnf5-plugins/automatic.conf. apply_updates mặc định bị tắt, nên ở trạng thái ban đầu, timer chỉ tải bản cập nhật xuống và không cài đặt gì. upgrade_type chọn giữa default và security. reboot chấp nhận never, when-changed hoặc when-needed.

Cách này giúp hệ thống luôn được cập nhật trong cùng một bản phát hành. Nó không bao giờ chuyển Fedora 43 lên Fedora 44, vì nâng cấp phiên bản là một thao tác riêng và có chủ đích, trong đó hệ thống reboot để thực hiện transaction ở chế độ offline. Đây là khác biệt thực tế so với một bản phát hành LTS. Trên Ubuntu, các bản nâng cấp bảo mật không cần giám sát có thể duy trì máy trong toàn bộ khoảng thời gian năm năm mà không thay đổi phiên bản, còn việc đổi phiên bản là một công việc được lập kế hoạch, chẳng hạn như nâng cấp từ 24.04 lên 26.04, thực hiện vài năm một lần.

Khi Fedora là lựa chọn phù hợp để chạy server

Fedora phù hợp khi tính mới là yếu tố chính.

• Bạn cần kernel hoặc userspace mới hơn mọi bản LTS đang phát hành: phần cứng mới, hoặc stack container và systemd vẫn còn cách vài năm mới xuất hiện trong một bản enterprise. Fedora cũng chuyển sang các kernel upstream mới trong suốt vòng đời một bản phát hành, nên lợi ích này không chỉ có một lần tại thời điểm cài đặt.
• Bạn đang xác thực những gì sẽ được đưa vào RHEL (Red Hat Enterprise Linux). Fedora cung cấp nền tảng cho CentOS Stream, còn CentOS Stream cung cấp nền tảng cho RHEL. Vì vậy, phần mềm build và chạy được trên Fedora hôm nay đang được kiểm thử với nền tảng enterprise của vài năm tới.
• Máy được thiết kế để tồn tại trong thời gian ngắn. Một build runner hoặc test box bị hủy sau hai tháng sẽ không bao giờ chạm đến ngày hết vòng đời. Logic này cũng áp dụng cho các VM tạm thời cấp cho coding agent, trong đó máy được rebuild thường xuyên hơn lịch phát hành của Fedora.
• Có người chịu trách nhiệm nâng cấp. Fedora phù hợp với server có owner cụ thể và lịch nâng cấp rõ ràng. Fedora không phù hợp với máy mà mọi người đều đã quên.

Lựa chọn trung gian: package hiện tại trên nền tảng ổn định

Phần lớn người muốn dùng Fedora trên server chỉ cần hai hoặc ba package mới, không cần một hệ điều hành mới. Hai việc này có thể tách rời. Dùng LTS hoặc một bản rebuild dành cho doanh nghiệp làm nền tảng, sau đó chỉ đưa phần mềm mới vào nơi thực sự cần. Container image cung cấp phiên bản mới của ứng dụng trên một host mà bạn không cần nâng cấp chỉ vì ứng dụng đó (chạy Docker trên VPS). Repository của vendor cho package duy nhất bạn quan tâm, chẳng hạn PostgreSQL hoặc nginx, sẽ cập nhật riêng package đó mà không ảnh hưởng đến nền tảng.

Sự đánh đổi này rõ ràng theo cả hai chiều. Container cung cấp userspace mới trên kernel cũ của host, nên không giúp ích nếu kernel mới là thứ bạn cần. Repository của vendor cung cấp một package mới trên nền tảng mà vendor đã kiểm thử ít hơn. Cả hai cách vẫn để việc cập nhật bảo mật của hệ thống nền tảng theo lịch LTS, và chính lịch đó khiến bạn phải dành một maintenance window mỗi năm khi dùng Fedora.

Nếu vẫn chọn Fedora cho server, hãy đưa chu kỳ này vào lịch. Khi một bản release được phát hành, hãy chờ vài tuần để các repository của vendor cập nhật, tạo snapshot, nâng cấp, rồi xác minh các service đã khởi động lại. Quy trình này chỉ mất khoảng một giờ mỗi năm và hoạt động hiệu quả. Trường hợp gây lỗi là khi bạn chỉ nhớ đến việc nâng cấp sau khi một thứ gì đó đã hỏng.

FAQ

Fedora được hỗ trợ trong bao lâu?

Khoảng 13 tháng. Fedora phát hành một phiên bản mới khoảng sáu tháng một lần và hỗ trợ mỗi phiên bản cho đến khoảng bốn tuần sau khi phiên bản mới hơn hai phiên bản được phát hành. Fedora 44 được phát hành vào ngày 28 tháng 4 năm 2026 và dự kiến hết vòng đời vào tháng 6 năm 2027. Sau thời điểm đó, phiên bản này sẽ không còn nhận bản cập nhật bảo mật, còn các package sẽ được chuyển khỏi mirror vào kho lưu trữ của Fedora.

Tôi có thể bỏ qua một phiên bản Fedora và nâng cấp hai phiên bản cùng lúc không?

Có, trong một số giới hạn. dnf system-upgrade download --releasever= chấp nhận phiên bản đích cao hơn một hoặc hai phiên bản, và nâng cấp hai phiên bản mỗi lần chính là cách hoạt động của lịch nâng cấp mỗi năm một lần. Nâng cấp xa hơn không phải là đường dẫn được hỗ trợ. Mỗi phiên bản bỏ qua làm tăng khả năng transaction bị dừng do package được đổi tên hoặc format cấu hình thay đổi. Nếu một máy đã chậm hơn vài phiên bản và quá thời hạn hỗ trợ, dựng lại máy bằng image hiện tại thường nhanh hơn thực hiện một chuỗi lần nâng cấp.

Điều gì xảy ra nếu server Fedora của tôi hết vòng đời?

Server vẫn chạy nhưng không còn được patch. Lần dnf upgrade tiếp theo sẽ fail với lỗi 404 trên URL metalink của phiên bản đó, vì các phiên bản hết vòng đời được chuyển vào kho lưu trữ tại dl.fedoraproject.org. Bạn có thể trỏ lại các file repository vào kho lưu trữ đó rồi nâng cấp theo từng bước, hoặc dựng lại server bằng một phiên bản còn được hỗ trợ. Cho đến khi thực hiện một trong hai cách này, không có bản cập nhật bảo mật nào đến được máy và không package nào cài đặt được.

Fedora có phải là lựa chọn tồi cho production server không?

Đây là lựa chọn mặc định không tốt, nhưng vẫn hợp lý nếu có lý do cụ thể. Chi phí là phải nâng cấp toàn bộ operating system mỗi năm, liên tục, trên một máy mà bạn có thể không muốn thay đổi. Chọn Fedora khi bạn cần kernel hoặc userspace mới hơn phiên bản mà một LTS cung cấp, hoặc khi server vốn được thiết kế để chỉ sử dụng trong thời gian ngắn. Chọn một LTS hoặc bản rebuild dành cho doanh nghiệp khi bạn muốn patch server trong nhiều năm mà không phải thay đổi version.