Ubuntu LTS o interim release para sa server?

Ubuntu LTS kumpara sa interim releases: ang maikling sagot

Ang pagpili sa pagitan ng Ubuntu LTS at interim release para sa server ay nakabatay sa isang numero: kung gaano katagal tumatanggap ang release na iyon ng security updates. Ang LTS ay may limang taon ng standard security maintenance. Ang interim release ay may siyam na buwan lamang, at pagkatapos ay hihinto ang updates, kaya kailangan mo itong i-upgrade o i-rebuild. Gumamit ng LTS para sa anumang server na inaasahan ng ibang tao. Gumamit lamang ng interim release kung kaya mong mag-rebuild nang hindi na kailangang humingi ng pahintulot kaninuman.

Ang LTS ay nangangahulugang long term support. Naglalabas ang Canonical ng isang LTS kada dalawang taon, tuwing Abril ng mga even year, at isang interim release kada anim na buwan sa pagitan ng mga ito. Inilabas ang 26.04 LTS noong 23 Abril 2026, at magpapatuloy ang standard security maintenance nito hanggang 2031. Inaasahang ilalabas ang 26.10 sa 15 Oktubre 2026. Interim release ito, kaya matatapos ang support cycle nito sa Hulyo 2027.

Gaano katagal sinusuportahan ang bawat Ubuntu release

[
  {
    "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
  }
]

Ito ang mga inilathalang policy figure ng Canonical noong August 2026, hindi mga sukat mula sa isang test box. Ang LTS ay may 60 buwan ng standard security maintenance, na katumbas ng 1 planadong release upgrade sa loob ng limang taon. Ang interim release ay may 9 buwan. Kung mananatili ka sa interim track sa loob ng parehong limang taon, kakailanganin mo ng 10 release upgrade, dahil hindi puwedeng lumaktaw ng release at may sampung release sa loob ng limang taon.

Itinataas ng Ubuntu Pro subscription ang bilang para sa LTS sa 120 buwan, o sampung taon, at pinalalawak ang coverage mula sa main component tungo sa buong archive. Noong August 2026, libre ang Pro para sa personal na paggamit sa hanggang limang machine, na sapat para sa karamihan ng maliliit na VPS fleet. Walang katumbas na option para sa interim release. Siyam na buwan ang buong support offer, at walang subscription na magpapahaba nito.

Magkano ang aabutin sa tunay na server sa loob ng siyam na buwan

Gamitin nating halimbawa ang 26.10. Ire-release ito sa 15 October 2026 at magtatapos ang security maintenance nito sa July 2027. Pareho ito ng siyam na buwang pattern na nagtapos sa 25.10 noong July 2026. Kung titingnan sa calendar, mukhang may isang maintenance window bawat tatlong quarter. Mali ang pagbasa sa calendar, at mas magastos ang resulta ng pagkakamaling ito.

Pinapalitan ng release upgrade ang operating system habang nasa parehong system. Binabago ng do-release-upgrade ang apt sources, dini-disable ang mga third-party repository, binabago ang version ng halos lahat ng naka-install na package, humihinto upang magtanong tungkol sa mga config file na na-edit mo, at nagre-reboot sa dulo. Kaya isa itong planadong window, hindi background job.

Patakbuhin ito gamit ang ssh at poprotektahan ka ng tool laban sa pagkawala ng sarili mong connection. Gumagawa ito ng sariling screen session at nagbubukas ng ikalawang sshd, pagkatapos ay ipinapaalam muna nito sa iyo:

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.

Hayaan ito. Kung bina-block ng firewall mo o ng hiwalay na network firewall ng provider mo ang 1022, hindi available ang fallback na iyon. Kapag naputol ang connection, maiiwan ang package set na kalahating na-upgrade. Kung ikaw mismo ang nagpapatakbo sa loob ng tmux o screen, makukuha mo ang parehong proteksiyon sa anumang box.

Ang mga prompt para sa config file ang dahilan kung bakit nagiging isang oras ang labinlimang minutong upgrade:

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 ?

Kapag pinanatili mo ang file mo, maaaring hindi mo makuha ang anumang binago sa bagong default. Kapag pinili mo ang file ng maintainer, mawawala ang hardening mo hanggang maibalik mo ito. Hindi ligtas ang alinmang sagot kung hindi mo alam kung ano ang binago sa release na iyon. Kaya bahagi ng window ang pagbasa sa release notes; hindi ito optional na homework.

Pagkatapos, paramihin ito ayon sa bilang ng mga box. Ang isang VPS sa interim track ay nangangailangan ng sampung upgrade window sa loob ng limang taon. Limang VPS box ay nangangailangan ng limampu, maliban kung disposable ang bawat box at nire-rebuild mula sa image. Limang box sa LTS track ay nangangailangan ng limang upgrade sa parehong panahon, at ikaw ang pumipili kung saang buwan isasagawa ang bawat isa.

Bakit hindi maaaring laktawan ang isang Ubuntu release

Fixed ang mga upgrade path. Ang isang interim release ay nag-a-upgrade sa kasunod na release, anuman iyon. Ang isang LTS ay direktang nag-a-upgrade sa kasunod na LTS, o sa kasunod na interim release kung iyon ang hihilingin mo. Walang nag-a-upgrade nang dalawang hakbang sa isang pagkakataon. Para makapunta mula 26.10 sa 28.04 LTS, kailangang dumaan sa 27.04 at 27.10, o i-reinstall ang machine.

Mahalagang malaman ang mekanismo dahil ipinapakita nitong hindi maaaring baguhin ang panuntunang ito. Kinukuha ng do-release-upgrade ang isang meta-release file mula sa changelogs.ubuntu.com, at pagkatapos ay dina-download ang upgrade tool na ginawa para sa isang partikular na transition. Isang transition lang bawat pagkakataon ang bina-build at tine-test ng Canonical, kaya walang tool o testing para sa pagtalon na lumalaktaw sa isang release. Hindi tumatanggi ang upgrader dahil lamang sa pag-iingat. Wala talaga itong maiaalok para sa ganoong upgrade.

Ang release na iaalok sa iyo ay nakatakda sa isang linya ng config:

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

Ang Prompt=lts ay nag-aalok lamang ng kasunod na LTS. Ang Prompt=normal ay nag-aalok ng kasunod na release, LTS man o hindi. Walang iniaalok ang Prompt=never; ganito mo mapipigilan ang isang mabuting-loob na kasamahan na magsimula ng upgrade na hindi mo pinlano. Sa isang release na hindi LTS, eksaktong katulad ng normal ang kilos ng lts dahil ang kasunod na release ng 26.10 ay 27.04 sa alinmang setting. Ipinapakita ng check ang Checking for a new Ubuntu release at pagkatapos ay alinman sa linyang New release ... available. o No new release found.

May isa pang scheduling rule na madalas nakalilito. Hindi iniaalok ang LTS-to-LTS upgrade sa araw na nire-release ang bagong LTS. Nagiging available ito sa unang point release, at nakatakda ang 26.04.1 sa 27 August 2026. Ang isang 24.04 box na may Prompt=lts at sumagot ng No new release found. hanggang tag-init ng 2026 ay hindi sira. Sinusunod nito ang policy. Kapag naging available na ang path, ang upgrade mula 24.04 patungong 26.04 LTS ang kailangang planuhin at i-rehearse.

Kailan tamang piliin ang interim release

May apat na sitwasyon kung kailan tunay itong kapaki-pakinabang:

• Kailangan mo ngayon sa server na ito ng kernel o userspace version na wala sa LTS archive.
• Ang machine ay build host, CI runner, o test box na nire-rebuild mula sa image. Dahil dito, ang upgrade ay bagong instance sa halip na maintenance window.
• May hardware o hypervisor feature na inilabas matapos mag-freeze ang LTS, at walang backport para rito.
• Sinusuri mo kung ano ang isasama sa susunod na LTS. Binubuo ang 28.04 mula sa 26.10, 27.04, at 27.10. Mas mura ang makakita ng breaking change sa isang spare VPS kaysa sa server na mahalaga.

Karamihan sa pumipili ng interim release ay isang mas bagong package ang kailangan, hindi isang mas bagong distribution. May dalawang mas murang opsyon. Dinadala ng hardware enablement stack ang mga kernel mula sa mas bagong release papunta sa LTS. Sa 24.04, iyon ay sudo apt install linux-generic-hwe-24.04, at sumusulong ito sa bawat point release simula sa ikalawang point release. Para sa iisang application, maaaring gumamit ng container image o sariling repository ng vendor upang isang bahagi lang ang magbago, sa halip na ang buong operating system.

Kapag maling piliin ang interim release

• Anumang system na may mga user na nagbabayad o may on-call rotation. Tinatanggap mo ang mandatory upgrade dalawang beses bawat taon kapalit ng package version na maaaring hindi mo naman kailanman gamitin.
• Anumang server kung saan ang unattended-upgrades ang nagsasagawa ng security patching para sa iyo. Ang automation na iyon ay kasinghusay lamang ng security repository na pinanggagalingan nito.
• Isang fleet na mano-mano mong ina-upgrade, dahil ang tunay na gastos ay isang maintenance window na minumultiply sa bilang ng mga server.
• Anumang ini-install mo at pagkatapos ay hindi mo tinitingnan sa loob ng isang taon. Ang interim release na nakalimutan mo ay magiging unpatched na internet-facing server makalipas ang siyam na buwan.

Tahimik ang huling failure na ito, kaya mapanganib. Kapag umabot sa end of life ang isang release, inililipat ang mga package nito sa old-releases.ubuntu.com. Dahil dito, nagsisimulang mabigo ang sudo apt update laban sa archive.ubuntu.com at nagbabalik ng 404 errors. Nagiging stale ang mga package list na naka-save sa disk. Patuloy na tumatakbo ang unattended-upgrades ayon sa timer nito at patuloy na nagsusulat ng mga linyang ganito sa /var/log/unattended-upgrades/unattended-upgrades.log:

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

Pareho ang mababasang linyang iyon sa isang fully patched na server at sa isang server na apat na buwan nang end of life ang release. Maliban kung may magbasa sa apt errors o sumusubaybay sa end of life date, walang ipinapakita ang machine kung alin sa dalawang sitwasyon ang kinakaharap mo.

Ang uri ng pagbabagong unang napupunta sa interim track

Noong March 2026, isang Canonical engineer ang nagmungkahi sa Ubuntu Discourse na alisin sa signed GRUB bootloader na ipinapadala para sa secure boot sa 26.10 ang mga sumusunod: filesystem drivers para sa btrfs, hfsplus, xfs, at zfs; JPEG at PNG image parsers; Apple partition tables; /boot sa LVM; software RAID maliban sa RAID 1; at isang LUKS-encrypted na /boot. Ang nakasaad na dahilan ay paulit-ulit na pinagmumulan ng security bug ang mga parser sa loob ng bootloader. Ang storage at encryption logic ay dapat nasa initramfs, ang maliit na initial RAM filesystem na mina-mount ng kernel bago ang aktuwal na root. Noong August 2026, panukala pa lamang ito na tinatalakay, at hindi pa isang pagbabagong inilabas.

Para sa karamihan ng VPS instance, wala itong mababago dahil nagbo-boot ang mga ito nang walang secure boot mula sa plain ext4 /boot sa isang GPT partition table. Suriin ang iyong setup sa halip na magpalagay. Kung ZFS ang iyong root, o nasa btrfs o nasa loob ng LUKS ang /boot, ito mismo ang uri ng pagbabagong unang mararanasan sa interim track. Ang sariling payo ng thread sa mga apektadong user ay manatili sa isang LTS. Iyon na ang buong argumento sa isang pangungusap. Sa interim releases sinusubukan ang mga pagbabago. Sa LTS dumarating ang mga ito matapos matukoy ng dalawang taon ng interim releases kung ano ang maaari nilang sirain.

Lumilitaw din ang parehong pattern sa mas maliliit na paraan sa bawat interim release. Umaabante ang default versions ng database, language runtime, at init configuration, kaya maaaring tumigil sa paggana ang mga config file na dati ay gumagana. Bahagi ng layunin ng interim release ang i-update ang mga default. Dahil dito, kasama sa kapalit na tinanggap mo ang pagbasa sa release notes bago ang bawat isa sa sampung upgrade na iyon.

Pagpili ng track kapag bina-build ang server

Piliin ang track sa oras ng installation, dahil ang pagpapalit nito pagkatapos ay nangangailangan ng reinstall o sunod-sunod na upgrades. Sa bagong server, apat na command ang magsasabi kung nasaan ka:

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

Dapat tukuyin ng lsb_release -a ang release na dapat mong i-install, at sa isang LTS, nagtatapos sa LTS ang description line. Dapat tumugma ang line na Prompt sa pinili mong track, hindi sa track na kasama sa image ng provider. Sa kasalukuyang LTS, dapat ang sagot ng do-release-upgrade -c ay No new release found.. Kung interim release ang iniaalok nito, nakatakda ang Prompt sa normal, at dapat magpasya ang isang tao kung sinadya iyon. Iniuulat ng pro security-status kung ilang installed package ang saklaw ng bawat update stream, at malinaw nitong sinasabi kapag hindi naka-attach ang machine sa isang subscription.

Pagkatapos, isulat ang end-of-life date sa lugar na muli mong makikita, kasama ng iba pang build notes para sa server na iyon. Bahagi ito ng iba pang gawain sa unang sampung minuto sa bagong VPS, dahil ang support date na nasa alaala lamang ng isang tao ang pinakalamang na mag-expire nang hindi napapansin. Kung ang anim na buwang churn ang nais mong lubusang iwasan, sulit basahin nang isang oras ang release model ng FreeBSD kumpara sa Linux bago ka mag-commit ng fleet sa alinman sa mga ito.

FAQ

Dapat ba akong gumamit ng Ubuntu interim release sa production server?

Sa halos lahat ng sitwasyon, hindi. Ang interim release ay humihinto sa pagtanggap ng security updates siyam na buwan matapos itong i-release. Ibig sabihin, kung production ang gamit dito, kailangan mong mag-upgrade humigit-kumulang dalawang beses bawat taon, nang tuloy-tuloy. Ang makatwirang exception ay mga machine na regular namang nire-rebuild mula sa image, gaya ng CI runners at build hosts. Sa mga ito, ang upgrade ay bagong instance at hindi maintenance window. Kung may tunay na users na umaasa sa server, i-install ang LTS at gamitin ang mga natipid na maintenance window sa ibang gawain.

Gaano katagal suportado ang Ubuntu interim release?

Siyam na buwan. Ire-release ang 26.10 sa 15 October 2026 at magtatapos ang security maintenance nito sa July 2027. Pareho ito ng naging iskedyul ng 25.10, na nagtapos noong July 2026. Ganito ang bawat interim release: nire-release sa April o October, at nagtatapos makalipas ang siyam na buwan. Ang LTS ay may limang taon ng standard security maintenance. Umaabot ito sa sampung taon kapag may Ubuntu Pro. Noong August 2026, libre ito para sa personal na paggamit sa hanggang limang machine.

Maaari ko bang laktawan ang Ubuntu releases habang nag-u-upgrade?

Hindi. do-release-upgrade ay ginagawa nang paisa-isang hakbang: ang interim release ay ina-upgrade sa kasunod na release, at ang LTS ay maaaring direktang i-upgrade sa kasunod na LTS. Para umabot mula 26.10 sa 28.04 LTS, kailangan munang isagawa ang upgrade sa 27.04 at 27.10, o kaya ay i-reinstall ang machine. Isang transition lang bawat pagkakataon ang bina-build at tine-test ng Canonical. Nagda-download din ang upgrader ng tool na partikular sa jump na iyon. Kaya walang tool para sa two-step jump at hindi ito kailanman iniaalok.

Ano ang mangyayari kapag nag-end of life ang Ubuntu release ko?

Ililipat ang mga package nito sa old-releases.ubuntu.com. Dahil dito, magsisimulang mag-fail ang sudo apt update laban sa archive.ubuntu.com at maglalabas ito ng 404 errors. Wala nang bagong security updates na ipo-publish para sa release na iyon. Walang awtomatikong mag-aanunsyo nito sa machine. Patuloy na tatakbo ang server at patuloy itong magse-serve ng traffic, habang nananatiling bukas ang bawat bagong vulnerability na matutuklasan dito. Ang recovery ay release upgrade na kailangang isagawa sa ilalim ng time pressure, o rebuild. Kaya subaybayan ang petsa at huwag hintaying lumitaw ang mga sintomas.

Masyado bang luma ang LTS kernel para sa bagong hardware?

Karaniwan, hindi. Hindi nananatili ang orihinal na kernel ng LTS sa loob ng limang taon. Dinadala ng hardware enablement stack, o HWE, ang mga kernel mula sa mas bagong releases papunta sa LTS sa mga point release. Maaaring mag-opt in ang server install gamit ang package gaya ng linux-generic-hwe-24.04. Suriin muna kung ano ang ginagamit mong kernel sa pamamagitan ng uname -r bago ipagpalagay na kernel ang problema. Kung userspace version ang kulang at hindi kernel, mas maliit na pagbabago ang paggamit ng container o vendor repository kaysa ilipat ang buong machine sa interim track.