Ubuntu LTS hay interim cho server: chọn bản nào?

Ubuntu LTS và bản phát hành interim: câu trả lời ngắn

Việc chọn Ubuntu LTS hay bản phát hành interim cho server phụ thuộc vào một con số: bản phát hành đó tiếp tục nhận security update trong bao lâu. LTS được bảo trì bảo mật tiêu chuẩn trong 5 năm. Bản phát hành interim được hỗ trợ trong 9 tháng, sau đó update dừng lại, nên bạn phải upgrade hoặc rebuild. Hãy chạy LTS trên mọi hệ thống mà người khác phụ thuộc vào. Chỉ chạy bản phát hành interim ở nơi bạn có thể rebuild mà không cần xin phép ai.

LTS là viết tắt của long term support. Canonical phát hành một bản LTS mỗi 2 năm, vào tháng 4 của các năm chẵn, và một bản phát hành interim mỗi 6 tháng trong khoảng thời gian giữa các bản LTS. 26.04 LTS được phát hành vào ngày 23 tháng 4 năm 2026 và thời hạn bảo trì bảo mật tiêu chuẩn kéo dài đến năm 2031. 26.10 dự kiến phát hành vào ngày 15 tháng 10 năm 2026. Đây là bản phát hành interim, nên thời hạn hỗ trợ sẽ kết thúc vào tháng 7 năm 2027.

Mỗi bản release Ubuntu được hỗ trợ trong bao lâu

[
  {
    "label": "LTS, standard support",
    "support_months": 60,
    "upgrades_over_5_years": 1
  },
  {
    "label": "LTS with Ubuntu Pro",
    "support_months": 120,
    "upgrades_over_5_years": 0
  },
  {
    "label": "Interim release",
    "support_months": 9,
    "upgrades_over_5_years": 10
  }
]

Đó là các số liệu chính sách do Canonical công bố tính đến tháng 8 năm 2026, không phải kết quả đo trên một máy thử nghiệm. Một bản LTS có 60 tháng được bảo trì bảo mật tiêu chuẩn. Trong năm năm, con số này tương đương với 1 lần nâng cấp release theo kế hoạch. Một bản interim được hỗ trợ trong 9 tháng. Nếu tiếp tục dùng nhánh interim trong cùng khoảng thời gian năm năm đó, bạn phải thực hiện 10 lần nâng cấp release, vì không thể bỏ qua một release và năm năm có mười release.

Gói đăng ký Ubuntu Pro tăng thời gian hỗ trợ LTS lên 120 tháng, tức mười năm, đồng thời mở rộng phạm vi hỗ trợ từ component main sang toàn bộ archive. Tính đến tháng 8 năm 2026, Pro miễn phí cho mục đích cá nhân trên tối đa năm máy, đủ cho hầu hết các hệ thống VPS nhỏ. Không có tùy chọn tương đương cho bản interim. Chín tháng là toàn bộ thời hạn được cung cấp và không có gói đăng ký nào gia hạn thời hạn này.

Chi phí của chín tháng trên một server thực tế

Lấy 26.10 làm ví dụ. Bản này được phát hành vào ngày 15 tháng 10 năm 2026 và thời hạn security maintenance kết thúc vào tháng 7 năm 2027, đúng theo chu kỳ chín tháng đã kết thúc với 25.10 vào tháng 7 năm 2026. Nếu nhìn theo lịch, bạn sẽ tưởng rằng cứ ba quý lại có một maintenance window. Cách nhìn này sai, và sai theo hướng tốn kém hơn.

Release upgrade thay thế operating system ngay trên hệ thống hiện tại. do-release-upgrade viết lại apt sources, vô hiệu hóa các repository bên thứ ba, thay đổi version của gần như mọi package đã cài, dừng lại để hỏi về các config file bạn đã chỉnh sửa, rồi reboot khi kết thúc. Vì vậy, đây là một planned window, không phải background job.

Nếu chạy qua SSH, tool sẽ bảo vệ bạn khi kết nối của chính bạn bị ngắt. Nó tự khởi động một phiên screen và mở thêm một sshd thứ hai, đồng thời báo cho bạn trước:

To make recovery in case of failure easier, an additional sshd will
be started on port '1022'. If anything goes wrong with the running ssh
you can still connect to the additional one.

Hãy để nó làm vậy. Nếu firewall của bạn hoặc firewall mạng riêng do provider cung cấp chặn 1022, fallback đó sẽ không tồn tại. Khi kết nối bị ngắt, hệ thống có thể còn một bộ package được nâng cấp dở dang. Tự chạy bên trong tmux hoặc screen cũng cung cấp mức bảo vệ tương tự trên mọi box.

Các prompt về config file là nguyên nhân biến một lần upgrade kéo dài mười lăm phút thành một giờ:

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?

Giữ file của bạn nghĩa là bạn bỏ lỡ mọi thay đổi trong default mới. Chọn file của maintainer nghĩa là các thiết lập hardening của bạn sẽ mất cho đến khi bạn thêm lại. Không lựa chọn nào an toàn nếu bạn chưa biết release đó đã thay đổi gì. Vì vậy, đọc release notes là một phần của window, không phải bài tập tùy chọn.

Sau đó hãy nhân con số này với số box. Một VPS chạy interim track sẽ có mười upgrade window trong năm năm. Năm VPS sẽ có năm mươi window, trừ khi mọi box đều có thể bỏ đi và được rebuild từ một image. Năm box chạy LTS track chỉ có năm lần upgrade trong cùng khoảng thời gian, và bạn được chọn tháng thực hiện từng lần.

Vì sao không thể bỏ qua một bản phát hành Ubuntu

Các đường dẫn nâng cấp đã được cố định. Bản phát hành interim sẽ nâng cấp lên bản phát hành kế tiếp, bất kể đó là bản nào. Bản LTS sẽ nâng cấp trực tiếp lên LTS kế tiếp, hoặc lên bản phát hành interim kế tiếp nếu bạn yêu cầu. Không có đường nâng cấp nào đi qua hai bước cùng lúc. Để chuyển từ 26.10 lên 28.04 LTS, bạn phải đi qua 27.04 và 27.10, hoặc cài lại máy.

Cơ chế này đáng để biết, vì nó cho thấy quy tắc này không thể linh động. do-release-upgrade tải file meta-release từ changelogs.ubuntu.com, sau đó tải công cụ nâng cấp được xây dựng cho một lần chuyển đổi cụ thể. Canonical xây dựng và kiểm thử từng lần chuyển đổi, nên việc bỏ qua một bản phát hành sẽ không có công cụ và quy trình kiểm thử tương ứng. Công cụ nâng cấp không từ chối vì thận trọng. Nó không có tùy chọn nào để cung cấp.

Bản phát hành được cung cấp cho bạn lấy từ một dòng cấu hình:

grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Prompt=lts chỉ cung cấp LTS kế tiếp. Prompt=normal cung cấp bản phát hành kế tiếp, bất kể đó là LTS hay không. Prompt=never không cung cấp bản nào. Đây là cách ngăn một đồng nghiệp có thiện ý bắt đầu một lần nâng cấp mà bạn chưa lên kế hoạch. Trên bản phát hành không phải LTS, lts hoạt động chính xác như normal, vì bản phát hành sau 26.10 là 27.04 trong cả hai thiết lập. Lệnh kiểm tra in ra Checking for a new Ubuntu release, sau đó là một dòng New release ... available. hoặc No new release found.

Một quy tắc lập lịch khác cũng thường gây nhầm lẫn. Không phải cứ bản LTS mới phát hành là có thể nâng cấp từ LTS này lên LTS kế tiếp ngay trong ngày đó. Tùy chọn này được mở khi point release đầu tiên phát hành, và 26.04.1 dự kiến phát hành vào ngày 27 August 2026. Point release không phải là phiên bản Ubuntu mới, mà là bản phát hành hiện tại với bốn tháng bản sửa lỗi tích lũy được đưa vào bộ cài mới, và thời gian chờ tồn tại để đường nâng cấp được kiểm thử trong bốn tháng trước khi cung cấp cho người dùng. Một máy 24.04 có Prompt=lts và trả về No new release found. trong suốt mùa hè năm 2026 không bị lỗi. Máy đó chỉ đang tuân theo chính sách. Khi đường nâng cấp được mở, lần nâng cấp từ 24.04 lên 26.04 LTS là quy trình cần lên kế hoạch và diễn tập.

Khi nào nên chọn interim release

Có 4 trường hợp interim release thực sự phù hợp:

• Bạn cần một phiên bản kernel hoặc userspace mà archive LTS không cung cấp trên máy này ngay lúc này.
• Máy là build host, CI runner hoặc máy test được rebuild từ image, nên việc upgrade tạo ra một instance mới thay vì cần một maintenance window.
• Tính năng phần cứng hoặc hypervisor được phát hành sau khi LTS đóng băng, và không có backport.
• Bạn đang kiểm tra nội dung của LTS tiếp theo. 28.04 được xây dựng từ 26.10, 27.04 và 27.10, nên phát hiện một breaking change trên VPS dự phòng sẽ ít tốn kém hơn so với phát hiện nó trên máy chủ quan trọng.

Phần lớn người chọn interim release chỉ cần một package mới hơn, không cần một distribution mới hơn. Có 2 lựa chọn ít tốn kém hơn. Hardware enablement stack đưa kernel từ các release mới hơn vào LTS: trên 24.04, đó là sudo apt install linux-generic-hwe-24.04, và stack này được cập nhật ở mỗi point release, bắt đầu từ point release thứ 2. Với một ứng dụng riêng lẻ, container image hoặc repository của vendor sẽ cập nhật một thành phần thay vì toàn bộ operating system.

Khi không nên chọn interim release

• Bất kỳ hệ thống nào có người dùng trả phí hoặc có lịch trực on-call. Bạn sẽ phải chấp nhận nâng cấp bắt buộc 2 lần mỗi năm để đổi lấy các phiên bản package mà có thể bạn không bao giờ dùng.
• Bất kỳ máy nào mà unattended-upgrades đang tự động cài bản vá bảo mật cho bạn. Cơ chế tự động đó chỉ tốt bằng security pocket mà nó lấy package.
• Một fleet được nâng cấp thủ công, vì chi phí thực tế là một maintenance window nhân với số lượng máy.
• Bất kỳ hệ thống nào bạn cài xong rồi không kiểm tra trong 1 năm. Một interim release bị bạn bỏ quên sẽ trở thành server public Internet chưa được vá sau 9 tháng.

Lỗi cuối cùng này diễn ra âm thầm, nên rất nguy hiểm. Khi một release hết vòng đời, các package của nó được chuyển sang old-releases.ubuntu.com, vì vậy sudo apt update bắt đầu lỗi khi truy cập archive.ubuntu.com và trả về lỗi 404. Các package list lưu trên đĩa trở nên cũ. unattended-upgrades vẫn chạy theo timer và tiếp tục ghi những dòng như sau vào /var/log/unattended-upgrades/unattended-upgrades.log:

No packages found that can be upgraded unattended and no pending auto-removals

Dòng đó giống hệt nhau trên một server đã được cập nhật đầy đủ và trên một server có release đã hết vòng đời từ 4 tháng trước. Nếu không có ai đọc lỗi của apt hoặc theo dõi ngày hết vòng đời, không có dấu hiệu nào trên máy cho bạn biết mình đang xem trường hợp nào.

Loại thay đổi xuất hiện trước trên bản phát hành interim

Vào tháng 3 năm 2026, một kỹ sư Canonical đề xuất trên Ubuntu Discourse loại bỏ GRUB bootloader đã ký dùng cho secure boot trong 26.10. Đề xuất này loại bỏ các filesystem driver cho btrfs, hfsplus, xfs và zfs, các trình phân tích ảnh JPEG và PNG, partition table của Apple, /boot trên LVM, software RAID ngoài RAID 1 và một /boot được mã hóa bằng LUKS. Lý do được nêu là các parser bên trong bootloader thường xuyên gây ra lỗi bảo mật, còn logic xử lý storage và encryption nên nằm trong initramfs, filesystem RAM ban đầu nhỏ mà kernel mount trước root thực. Tính đến tháng 8 năm 2026, đây vẫn là đề xuất đang được thảo luận, chưa phải thay đổi đã được phát hành.

Với hầu hết VPS, thay đổi này không ảnh hưởng gì vì chúng boot mà không dùng secure boot, từ một /boot ext4 đơn giản trên GPT partition table. Hãy kiểm tra hệ thống của bạn thay vì mặc định như vậy. Nếu root của bạn là ZFS, hoặc /boot nằm trên btrfs hay bên trong LUKS, đây chính xác là loại thay đổi sẽ ảnh hưởng đến bạn trước trên interim track. Chính thread đó cũng khuyên người dùng bị ảnh hưởng nên dùng LTS. Một câu này tóm tắt toàn bộ lý do: interim release là nơi các thay đổi được thử nghiệm. LTS là nơi các thay đổi xuất hiện sau khi hai năm interim release đã cho thấy chúng làm hỏng những gì.

Mẫu hình tương tự cũng xuất hiện ở quy mô nhỏ hơn trong mỗi interim release. Phiên bản mặc định của database, language runtime và init configuration được nâng lên, nên các config file từng hoạt động có thể ngừng hoạt động. Nâng các phiên bản mặc định là nhiệm vụ của interim release. Vì vậy, đọc release notes trước mỗi trong 10 lần nâng cấp đó là chi phí bạn đã chấp nhận.

Chọn track khi build máy chủ

Chọn track ngay lúc cài đặt, vì thay đổi sau đó sẽ cần cài lại hoặc thực hiện một chuỗi lần nâng cấp. Trên server mới, 4 lệnh cho biết hiện trạng của máy:

lsb_release -a
grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c
pro security-status

lsb_release -a phải hiển thị đúng release bạn định cài; với bản LTS, dòng mô tả phải kết thúc bằng LTS. Dòng Prompt phải khớp với track bạn đã chọn, không phải track đi kèm image mà provider cung cấp. do-release-upgrade -c trên LTS hiện tại phải trả về No new release found.. Nếu lệnh này đề xuất một interim release thay vì vậy, Prompt đang được đặt thành normal và cần xác định xem đó có phải là chủ ý hay không. pro security-status cho biết có bao nhiêu package đã cài đang được bao phủ bởi từng update stream, đồng thời nêu rõ khi máy chưa được gắn với subscription.

Sau đó, ghi ngày end of life ở nơi bạn có thể xem lại, cạnh các ghi chú build khác của server đó. Việc này thuộc nhóm công việc mười phút đầu tiên trên một VPS mới, vì ngày hỗ trợ chỉ nằm trong trí nhớ của ai đó sẽ là ngày hết hạn mà không ai nhận ra. Nếu mục tiêu của bạn là loại bỏ hoàn toàn chu kỳ nâng cấp 6 tháng, mô hình phát hành của FreeBSD so với Linux đáng để dành 1 giờ đọc trước khi quyết định triển khai cả fleet trên một trong hai nền tảng.

FAQ

Tôi có nên chạy bản Ubuntu interim trên server production không?

Trong hầu hết trường hợp là không. Bản interim ngừng nhận security update sau 9 tháng kể từ khi được phát hành. Vì vậy, chạy production trên nhánh này đồng nghĩa với việc phải nâng cấp bắt buộc khoảng 2 lần mỗi năm, vô thời hạn. Ngoại lệ hợp lý là những máy vốn được dựng lại từ image, chẳng hạn CI runner và build host. Với các máy này, nâng cấp nghĩa là tạo một instance mới thay vì mở một đợt nâng cấp. Nếu có người dùng thực sự phụ thuộc vào máy chủ, hãy cài bản LTS và dùng thời gian không phải nâng cấp cho việc khác.

Bản Ubuntu interim được hỗ trợ trong bao lâu?

9 tháng. 26.10 được phát hành vào ngày 15 tháng 10 năm 2026 và thời hạn security maintenance kết thúc vào tháng 7 năm 2027, giống như 25.10 đã kết thúc vào tháng 7 năm 2026. Mọi bản interim đều theo chu kỳ này: phát hành vào tháng 4 hoặc tháng 10, rồi kết thúc 9 tháng sau. Bản LTS có 5 năm standard security maintenance, kéo dài thành 10 năm với Ubuntu Pro. Tính đến tháng 8 năm 2026, Ubuntu Pro miễn phí cho mục đích cá nhân trên tối đa 5 máy.

Tôi có thể bỏ qua các bản Ubuntu khi nâng cấp không?

Không. do-release-upgrade chuyển từng bước một: bản interim nâng cấp lên bản kế tiếp, còn bản LTS có thể nâng cấp trực tiếp lên bản LTS kế tiếp. Để chuyển từ 26.10 lên 28.04 LTS, bạn phải chạy nâng cấp lần lượt qua 27.04 và 27.10, hoặc cài lại máy. Canonical xây dựng và kiểm thử từng bước chuyển đổi, còn trình nâng cấp tải tool dành riêng cho bước chuyển đó. Vì vậy, bước nhảy 2 phiên bản không có tool tương ứng và sẽ không bao giờ được cung cấp.

Điều gì xảy ra khi bản Ubuntu của tôi hết thời hạn hỗ trợ?

Các package của bản đó được chuyển sang old-releases.ubuntu.com. Vì vậy, sudo apt update bắt đầu fail khi truy cập archive.ubuntu.com và trả về lỗi 404. Bản phát hành đó cũng không còn nhận security update mới. Máy không có thông báo nào cho bạn biết việc này. Server vẫn chạy và tiếp tục phục vụ traffic, trong khi mọi lỗ hổng mới được công bố trên hệ thống vẫn còn bỏ ngỏ. Cách khôi phục là chạy release upgrade trong điều kiện bị giới hạn thời gian, hoặc dựng lại máy. Vì vậy, hãy theo dõi ngày hết hạn thay vì chờ dấu hiệu lỗi xuất hiện.

Kernel LTS có quá cũ đối với phần cứng mới không?

Thông thường là không, vì LTS không giữ nguyên kernel ban đầu trong 5 năm. Hardware enablement stack, gọi là HWE, đưa kernel từ các bản phát hành mới hơn vào LTS thông qua các point release. Server install có thể bật HWE bằng package như linux-generic-hwe-24.04. Hãy kiểm tra kernel đang chạy bằng uname -r trước khi kết luận kernel là nguyên nhân gây lỗi. Nếu phần còn thiếu là phiên bản userspace thay vì kernel, dùng container hoặc vendor repository thường là thay đổi nhỏ hơn nhiều so với việc chuyển toàn bộ máy sang nhánh interim.