Ubuntu LTS vs interim: alin ang para sa server?

Ubuntu LTS kumpara sa interim releases: ang maikling sagot

Ang pagpili sa pagitan ng Ubuntu LTS at interim release para sa isang server ay nakasalalay sa isang numero: kung gaano katagal tumatanggap ng security updates ang release na iyon. Ang LTS ay may limang taon ng standard security maintenance. Ang interim release ay may siyam na buwan lamang, at pagkatapos ay hihinto ang mga update, kaya kailangan mong mag-upgrade o mag-rebuild. Gumamit ng LTS sa anumang server na inaasahan o ginagamit ng ibang tao. Gumamit lamang ng interim release kung kaya mong mag-rebuild nang hindi 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 tatakbo ang standard security maintenance nito hanggang 2031. Nakatakdang ilabas ang 26.10 sa 15 Oktubre 2026, at isa itong interim release, kaya magtatapos 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
  }
]

Ang mga ito ay mga numerong inilathala ng Canonical ayon sa policy nito noong August 2026, at hindi mga sukat mula sa isang test box. Ang isang LTS ay may 60 buwan ng standard security maintenance, na katumbas ng 1 planadong release upgrade sa loob ng limang taon. Ang isang interim release ay may 9 buwan. Kung mananatili ka sa interim track sa loob ng parehong limang taon, mangangailangan ito ng 10 release upgrade, dahil hindi maaaring mag-skip ng release at sampung release ang nasa loob ng limang taon.

Pinapataas ng Ubuntu Pro subscription ang LTS figure 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 opsyon para sa interim release. Siyam na buwan lamang ang buong support period, at walang subscription na makapagpapahaba rito.

Ano ang gastos sa loob ng siyam na buwan sa isang aktuwal na server

Gamitin nating halimbawa ang 26.10. Inilabas ito noong 15 October 2026, at matatapos ang security maintenance nito sa July 2027. Ito rin ang parehong siyam na buwang pattern na nagtapos sa 25.10 noong July 2026. Kung titingnan ayon sa calendar, para itong isang maintenance window kada tatlong quarter. Mali ang ganitong pagbasa, at mas magastos ang resulta ng pagkakamaling ito.

Pinapalitan ng release upgrade ang operating system habang nasa kasalukuyang installation. do-release-upgrade nire-rewrite 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 kailangan itong ilaan sa isang planadong window at hindi patakbuhin bilang background job.

Patakbuhin ito sa ssh at poprotektahan ka ng tool laban sa pagkaputol ng sarili mong connection. Nagsisimula ito ng sarili nitong screen session at nagbubukas ng pangalawang sshd, at ipinapaalam muna ito 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 gagana ang fallback na iyon. Kapag naputol ang connection, maiiwan ang system na may kalahating na-upgrade na set ng package. Kung ikaw mismo ang magpapatakbo sa loob ng tmux o screen, makukuha mo ang parehong proteksyon sa anumang box.

Ang mga prompt para sa config file ang nagpapahaba sa labinlimang minutong upgrade hanggang isang oras:

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 ?

Kung pananatilihin mo ang file mo, maaaring hindi mo makuha ang anumang pagbabagong ginawa sa bagong default. Kung gagamitin mo ang file ng maintainer, mawawala ang hardening mo hanggang maibalik mo ito. Hindi ligtas ang alinman sa dalawang sagot kung hindi mo alam kung ano ang nagbago sa release na iyon. Kaya bahagi ng upgrade window ang pagbasa sa release notes, at hindi ito opsyonal na paghahanda.

Pagkatapos, i-multiply ito ayon sa dami ng box. Ang isang VPS sa interim track ay nangangailangan ng sampung upgrade window sa loob ng limang taon. Limampu iyon para sa limang VPS box, maliban kung disposable ang bawat box at muli itong bina-build mula sa isang image. Ang limang box sa LTS track ay nangangailangan ng limang upgrade sa parehong panahon, at ikaw ang pumipili kung saang buwan gagawin ang bawat isa.

Bakit hindi maaaring lumaktaw sa isang Ubuntu release

Nakatakda ang mga upgrade path. Ang isang interim release ay nag-a-upgrade sa kasunod na release, anuman ito. 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 beses. 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 nito na hindi maaaring lampasan ang panuntunan. Ang do-release-upgrade ay kumukuha ng meta-release file mula sa changelogs.ubuntu.com, pagkatapos ay nagda-download ng upgrade tool na ginawa para sa isang partikular na transition. Gumagawa at nagte-test ang Canonical ng isang transition sa bawat pagkakataon, kaya walang tool at testing para sa jump na lumalaktaw sa isang release. Hindi tumatanggi ang upgrader dahil lamang sa pag-iingat. Wala itong maiaalok.

Ang release na iniaalok sa iyo ay nakabatay sa isang linya ng configuration:

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, kaya mapipigilan mong magsimula ang isang mabuting-loob na kasamahan 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 panuntunan sa scheduling na kadalasang nakalilito. Hindi iniaalok ang LTS-to-LTS upgrade sa araw na inilabas ang bagong LTS. Nagbubukas ito sa unang point release, at nakatakda ang 26.04.1 sa 27 August 2026. Ang point release ay hindi bagong bersyon ng Ubuntu kundi parehong release na may apat na buwang naipong fixes na isinama sa bagong install media, at may ganitong paghihintay upang makuha ng upgrade path ang apat na buwang testing bago ito ialok kaninuman. Ang 24.04 box na may Prompt=lts na sumagot ng No new release found. hanggang tag-init ng 2026 ay hindi may sira. Sinusunod nito ang policy. Kapag nagbukas ang path, ang 24.04 hanggang 26.04 LTS upgrade ang dapat planuhin at i-rehearse.

Kapag mas angkop ang interim release

Apat na sitwasyon kung kailan ito talagang mas 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, kaya ang upgrade ay bagong instance at hindi 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, at mas mababa ang gastos ng pagtuklas ng breaking change sa isang ekstrang VPS kaysa sa pagtuklas nito sa mahalagang server.

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

Kapag maling piliin ang interim release

• Anumang may mga paying user o may on-call rotation. Tatanggap ka ng mandatory upgrade dalawang beses bawat taon kapalit ng mga package version na maaaring hindi mo kailanman gamitin.
• Anumang box kung saan ang unattended-upgrades ang gumagawa ng security patching para sa iyo. Ang automation na iyon ay nakadepende sa security pocket kung saan ito kumukuha ng mga update.
• Isang fleet na mano-mano mong ina-upgrade, dahil ang aktuwal na gastos ay isang maintenance window na minumultiply sa bilang ng mga box.
• Anumang ini-install mo at pagkatapos ay hindi mo sinusuri 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 iyon, kaya mapanganib ito. Kapag umabot na sa end of life ang isang release, inililipat ang mga package nito sa old-releases.ubuntu.com, kaya sudo apt update ay nagsisimulang mag-fail laban sa archive.ubuntu.com dahil sa 404 errors. Nagiging stale ang mga package list na nasa disk. Patuloy na tumatakbo ang unattended-upgrades ayon sa timer nito at patuloy na nagsusulat ng mga linyang tulad nito sa /var/log/unattended-upgrades/unattended-upgrades.log:

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

Magkapareho ang ipinapakitang line na 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 ng apt errors o sumusubaybay sa end of life date, walang ipinapakita ang machine para malaman mo kung alin sa dalawa ang tinitingnan mo.

Ang uri ng pagbabagong unang dumarating sa interim track

Noong March 2026, isang Canonical engineer ang nagmungkahi sa Ubuntu discourse na alisin sa signed GRUB bootloader na inilalabas para sa secure boot sa 26.10 ang mga sumusunod: mga filesystem driver para sa btrfs, hfsplus, xfs, at zfs; mga JPEG at PNG image parser; 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. Dapat nasa initramfs ang storage at encryption logic—ito ang maliit na initial RAM filesystem na mina-mount ng kernel bago ang aktuwal na root filesystem. Noong August 2026, panukala pa lamang ito na tinatalakay, hindi pa isang pagbabagong inilabas.

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

Lumilitaw din ang parehong pattern sa mas maliliit na paraan sa bawat interim release. Umaabante ang mga default na bersyon ng database, language runtime, at init configuration, kaya maaaring hindi na gumana ang mga config file na dati ay maayos. Bahagi ng layunin ng isang interim release ang paabantehin ang mga default. Dahil dito, bahagi ng halagang tinanggap mong bayaran ang pagbasa sa release notes bago ang bawat isa sa sampung upgrade na iyon.

Pagpili ng track kapag binubuo ang server

Piliin ang track sa oras ng installation, dahil ang pagpapalit nito pagkatapos ay nangangailangan ng reinstall o sunod-sunod na upgrade. 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 pangalanan ng lsb_release -a ang release na nilayon mong i-install, at sa isang LTS, nagtatapos ang linya ng description sa LTS. Dapat tumugma ang linya ng Prompt sa pinili mong track, hindi sa track na kasama sa image ng provider. Sa kasalukuyang LTS, dapat magbalik ang do-release-upgrade -c ng 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. Kasama ito sa iba pang gawain sa unang sampung minuto sa bagong VPS, dahil ang support date na nasa alaala lamang ng isang tao ang siyang madaling mag-expire nang hindi napapansin. Kung ang anim-na-buwang pagpapalit ng release ang bagay na lubos mong gustong iwasan, sulit basahin nang isang oras ang release model ng FreeBSD kumpara sa Linux bago ka magpasya kung alin ang gagamitin sa fleet.

FAQ

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

Sa halos lahat ng kaso, hindi. Humihinto ang interim release sa pagtanggap ng security updates pagkalipas ng siyam na buwan mula sa release nito. Kaya ang production server sa track na iyon ay nangangailangan ng upgrade window humigit-kumulang dalawang beses bawat taon, habang-buhay. Ang makatwirang exception ay mga machine na nire-rebuild din naman mula sa image, gaya ng CI runners at build hosts. Sa mga ito, ang upgrade ay bagong instance sa halip na maintenance window. Kung may mga totoong user na umaasa sa server, i-install ang LTS at gamitin ang mga natipid na window sa ibang gawain.

Gaano katagal sinusuportahan ang Ubuntu interim release?

Siyam na buwan. Ang 26.10 ay ire-release sa 15 October 2026 at magtatapos ang security maintenance nito sa July 2027. Ganito rin ang nangyari sa 25.10 na nagtapos noong July 2026. Pareho ang sinusunod na iskedyul ng bawat interim release: nire-release sa April o October, at nagtatapos pagkalipas ng siyam na buwan. Ang LTS ay may limang taon ng standard security maintenance. Maaari itong umabot sa sampung taon gamit ang Ubuntu Pro, na noong August 2026 ay libre para sa personal na paggamit sa hanggang limang machine.

Maaari ba akong lumaktaw ng Ubuntu release kapag nag-a-upgrade?

Hindi. Ang do-release-upgrade ay nag-a-upgrade nang isang hakbang bawat pagkakataon: ang interim release ay pumupunta sa kasunod na release, at ang LTS ay maaaring direktang pumunta sa kasunod na LTS. Para makalipat mula 26.10 papunta sa 28.04 LTS, kailangang isagawa muna ang upgrade sa 27.04 at 27.10, o i-reinstall ang machine. Binubuo at tine-test ng Canonical ang bawat transition nang paisa-isa. Nagda-download din ang upgrader ng tool para sa partikular na jump na iyon. Kaya walang tool para sa two-step jump at hindi ito kailanman iniaalok.

Ano ang mangyayari kapag umabot sa end of life ang Ubuntu release ko?

Inililipat ang mga package nito sa old-releases.ubuntu.com. Dahil dito, nagsisimulang mag-fail ang sudo apt update laban sa archive.ubuntu.com at nagbabalik ito ng 404 errors. Wala nang bagong security updates na inilalabas para sa release na iyon. Walang ipinapakitang anunsyo ang machine tungkol dito. Patuloy na tumatakbo ang server at patuloy na nagseserve ng traffic habang nananatiling bukas ang bawat bagong vulnerability na natutuklasan dito. Ang recovery ay release upgrade na kailangang patakbuhin habang gipit sa oras, o rebuild. Kaya subaybayan ang petsa at huwag hintayin ang mga sintomas.

Masyado na bang luma ang LTS kernel para sa bagong hardware?

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