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

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

Việc chọn Ubuntu LTS hay bản phát hành interim cho server phụ thuộc vào một thông tin: 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 chỉ được hỗ trợ trong 9 tháng, sau đó các bản cập nhật dừng lại, nên bạn phải upgrade hoặc rebuild. Hãy dùng LTS cho mọi hệ thống mà người khác phụ thuộc vào. Chỉ dùng bản phát hành interim khi bạn có thể rebuild mà không cần hỏi ý kiến 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 vào 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ợ kết thúc vào tháng 7 năm 2027.

Mỗi bản phát hành 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 từ 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 5 năm, thời gian này tương đương với 1 lần nâng cấp bản phát hành theo kế hoạch. Một bản phát hành interim có 9 tháng hỗ trợ. Nếu dùng kênh interim trong cùng 5 năm đó, bạn phải thực hiện 10 lần nâng cấp bản phát hành, vì không thể bỏ qua một bản phát hành và 5 năm có 10 bản phát hành.

Gói đăng ký Ubuntu Pro nâng thời hạn hỗ trợ LTS lên 120 tháng, tức 10 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 được miễn phí cho mục đích cá nhân trên tối đa 5 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 phát hành interim. 9 tháng là toàn bộ thời hạn được cung cấp và không gói đăng ký nào có thể kéo dài thời hạn này.

Chi phí trong 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 bảo trì bảo mật kết thúc vào tháng 7 năm 2027. Đây cũng là chu kỳ chín tháng đã kết thúc với 25.10 vào tháng 7 năm 2026. Nếu chỉ nhìn theo lịch, bạn sẽ nghĩ cứ mỗi ba quý mới có một lần bảo trì. Cách hiểu theo lịch này sai, và sai theo hướng tốn kém hơn.

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

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

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 để nguyên như vậy. Nếu firewall của bạn hoặc firewall mạng riêng của nhà cung cấp chặn cổng 1022, cơ chế dự phòng này sẽ không hoạt động. Khi kết nối bị ngắt, hệ thống có thể còn một bộ package nâng cấp dở dang. Tự chạy bên trong tmux hoặc screen cũng cung cấp cùng một lớp bảo vệ trên mọi máy.

Các prompt về file cấu hình là nguyên nhân biến một lần nâng cấp 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 có nghĩa là bạn bỏ lỡ mọi thay đổi trong default mới. Chọn file của maintainer có nghĩa là các thiết lập hardening của bạn biến mất cho đến khi bạn khôi phục chúng. Không câu trả lời nào an toàn nếu bạn chưa biết những gì đã thay đổi trong bản phát hành đó. Vì vậy, đọc release notes là một phần của maintenance window, không phải việc có thể bỏ qua.

Sau đó hãy nhân lên theo số lượng máy. Một VPS dùng interim track sẽ có mười maintenance window trong năm năm. Năm VPS sẽ là năm mươi, trừ khi mọi máy đều có thể bỏ đi và được rebuild từ một image. Năm máy dùng LTS track sẽ có năm lần nâng cấp 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 có thể 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ó cách nào nâng cấp liền 2 bướ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 để tìm hiểu vì nó cho thấy quy tắc này không thể thay đổi. 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 chuyển đổi cụ thể. Canonical xây dựng và kiểm thử từng chuyển đổi một, nên việc bỏ qua một bản phát hành sẽ không có công cụ và 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ó lựa chọn nào để cung cấp.

Bản phát hành được đề xuất cho bạn xuất phát 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ỉ đề xuất LTS kế tiếp. Prompt=normal đề xuất bản phát hành kế tiếp, dù là LTS hay không. Prompt=never không đề xuất bản nào. Đây là cách ngăn một đồng nghiệp có ý tốt 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 rồi in 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. Việc nâng cấp từ LTS lên LTS không được đề xuất ngay trong ngày LTS mới được phát hành. Tùy chọn này mở sau khi point release đầu tiên được phát hành; 26.04.1 dự kiến phát hành vào ngày 27 August 2026. Một máy chạy 24.04 có Prompt=lts và trả về No new release found. trong mùa hè năm 2026 không bị lỗi. Máy chỉ đang tuân theo chính sách. Khi đường dẫn mở, quy trình nâng cấp từ 24.04 lên 26.04 LTS là lần chạy bạn 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 có trên máy này ngay lúc đó.
• Máy là build host, CI runner hoặc máy test được rebuild từ image, nên 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 xuất hiện sau khi LTS được freeze và không có backport.
• Bạn muốn 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. Phát hiện breaking change trên một VPS dự phòng sẽ ít tốn kém hơn phát hiện nó trên máy chủ quan trọng.

Hầu hết 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 cách í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. Stack này được cập nhật ở mỗi point release, bắt đầu từ point release thứ 2. Với một application riêng lẻ, container image hoặc repository do vendor cung cấp 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 bản phát hành trung gian

• 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 đến.
• Bất kỳ máy nào để unattended-upgrades tự động cài bản vá bảo mật. Cơ chế tự động đó chỉ an toàn ở mức kho package bảo mật mà nó sử dụng.
• 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ỳ thứ gì bạn cài xong rồi không kiểm tra trong 1 năm. Một bản phát hành trung gian bị bạn quên mất 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 bản phát hành 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 máy trở nên cũ. unattended-upgrades vẫn chạy theo timer và tiếp tục ghi các 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 này giống nhau trên một server đã được cài đầy đủ bản vá và một server có bản phát hành đã 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 biết bạn đang xem trường hợp nào.

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

Vào tháng 3 năm 2026, một kỹ sư Canonical đã đề xuất trên Ubuntu Discourse việc loại bỏ GRUB bootloader đã ký được cung cấp 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 bộ 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 bộ phân tích bên trong bootloader thường xuyên là nguồn gây ra lỗi bảo mật, còn logic lưu trữ và mã hóa 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 phần lớn 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 thông thường trên GPT partition table. Hãy kiểm tra hệ thống của bạn thay vì giả định. 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 mà bạn sẽ gặp trước trên nhánh interim. Chính thread đó cũng khuyên những người dùng bị ảnh hưởng nên dùng LTS. Lời khuyên này tóm tắt toàn bộ vấn đề trong một câu. 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ô 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à cấu hình init được nâng lên, nên các file cấu hình từng hoạt động có thể ngừng hoạt động. Nâng phiên bản mặc định là nhiệm vụ của interim release, vì vậy đọc release note trước mỗi lần trong số mười lần nâng cấp đó là chi phí bạn đã chấp nhận.

Chọn track khi cài đặt máy chủ

Hãy chọn track ngay khi cài đặt, vì thay đổi sau đó đồng nghĩa với việc cài lại hoặc thực hiện một chuỗi lần nâng cấp. Trên máy chủ mới, 4 lệnh cho biết hệ thống đang ở trạng thái nào:

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 bản phát hành bạn định cài đặt; trên 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 mà image của nhà cung cấp tình cờ có sẵn. Trên bản LTS hiện tại, do-release-upgrade -c phải trả về No new release found.. Nếu lệnh này cung cấp một bản phát hành interim thay vì bản LTS, Prompt đượ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 thuộc từng update stream, đồng thời nói rõ khi máy chưa được gắn với subscription.

Sau đó, hãy 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 máy chủ đó. Nội dung này thuộc cùng nhóm công việc với 10 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 đó thì thường sẽ hết hạn mà không ai nhận ra. Nếu bạn muốn loại bỏ hoàn toàn chu kỳ thay đổi 6 tháng, mô hình phát hành của FreeBSD so với Linux là nội dung đáng dành 1 giờ để đọc trước khi quyết định triển khai fleet theo một trong hai mô hình.

FAQ

Tôi có nên chạy một bản Ubuntu interim trên máy chủ production không?

Trong hầu hết trường hợp là không. Một 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 bắt buộc phải nâng cấp khoảng 2 lần mỗi năm, mãi mãi. 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 có nghĩa là tạo instance mới thay vì chờ một maintenance window. Nếu có user thực sự phụ thuộc vào máy chủ, hãy cài bản LTS và dùng các maintenance window tiết kiệm được cho việc khác.

Một bản Ubuntu interim được hỗ trợ trong bao lâu?

9 tháng. 26.10 được phát hành vào 15 October 2026 và thời hạn security maintenance kết thúc vào July 2027, giống như 25.10 đã kết thúc vào July 2026. Mọi bản interim đều theo chu kỳ này: phát hành vào April hoặc October, 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 August 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 nâng cấp từng bước một: bản interim chuyển lên bản kế tiếp, còn bản LTS có thể chuyển 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 thực hiện 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 riêng. Trình nâng cấp cũng tải về một tool dành riêng cho lần chuyển đổi đó, nên 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 vòng đời?

Các package của bả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ới lỗi 404, và hoàn toàn không còn security update mới nào được phát hành cho bản đó. Máy không có thông báo nào về việc này. Server vẫn tiếp tục chạy và phục vụ traffic, trong khi mọi lỗ hổng mới được công bố trên đó vẫn để ngỏ. Cách khôi phục là chạy release upgrade dưới áp lực 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ờ triệu chứng xuất hiện.

Kernel LTS có quá cũ đối với phần cứng mới khô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 tắt là HWE, đưa kernel từ các bản phát hành sau vào LTS thông qua các point release. Server install có thể opt in 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 sẽ là thay đổi nhỏ hơn nhiều so với việc chuyển toàn bộ máy sang nhánh interim.