సర్వర్‌కు Ubuntu LTS లేదా interim release ఏది మంచిది?

Ubuntu LTS మరియు interim releases: సంక్షిప్త సమాధానం

సర్వర్‌లో Ubuntu LTS లేదా interim release ఎంచుకోవడం ప్రధానంగా ఒక విషయంపై ఆధారపడి ఉంటుంది: ఆ release ఎంతకాలం security updates పొందుతుంది. LTS కు ఐదు సంవత్సరాల standard security maintenance ఉంటుంది. interim release కు తొమ్మిది నెలలు మాత్రమే ఉంటుంది. ఆ తర్వాత updates నిలిచిపోతాయి. కాబట్టి మీరు upgrade చేయాలి లేదా rebuild చేయాలి. ఇతరులు ఆధారపడే ఏ వ్యవస్థలోనైనా LTS ఉపయోగించండి. ఎవరినీ సంప్రదించకుండానే rebuild చేయగల పరిస్థితుల్లో మాత్రమే interim release ఉపయోగించండి.

LTS అంటే long term support. Canonical ప్రతి రెండు సంవత్సరాలకు ఒక LTS ను, even years లోని April లో విడుదల చేస్తుంది. మధ్యలో ప్రతి ఆరు నెలలకు ఒక interim release ను విడుదల చేస్తుంది. 26.04 LTS 23 April 2026న విడుదలైంది. దాని standard security maintenance 2031 వరకు కొనసాగుతుంది. 26.10 15 October 2026న విడుదల కావాల్సి ఉంది. ఇది interim release కాబట్టి, దాని support period July 2027లో ముగుస్తుంది.

ప్రతి Ubuntu release కు లభించే support వ్యవధి

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

ఇవి August 2026 నాటికి Canonical ప్రచురించిన policy గణాంకాలు. ఇవి test box పై చేసిన కొలతలు కావు. ఒక LTS కు 60 నెలల standard security maintenance లభిస్తుంది. అంటే ఐదు సంవత్సరాల్లో 1 planned release upgrade అవసరం. ఒక interim release కు 9 నెలల support ఉంటుంది. అదే ఐదు సంవత్సరాల పాటు interim track లో కొనసాగితే 10 release upgrades చేయాలి. ఎందుకంటే ఒక release ను దాటివెళ్లలేరు, అలాగే ఐదు సంవత్సరాల్లో పది releases ఉంటాయి.

Ubuntu Pro subscription వల్ల LTS support వ్యవధి 120 నెలలకు, అంటే పది సంవత్సరాలకు పెరుగుతుంది. అలాగే coverage main component నుంచి మొత్తం archive కు విస్తరిస్తుంది. August 2026 నాటికి వ్యక్తిగత వినియోగానికి Ubuntu Pro గరిష్ఠంగా ఐదు machines వరకు ఉచితం. ఇది చాలా చిన్న VPS fleets కు సరిపోతుంది. Interim release కు దీనికి సమానమైన ఎంపిక లేదు. తొమ్మిది నెలల support మాత్రమే లభిస్తుంది. ఏ subscription కూడా ఆ వ్యవధిని పొడిగించదు.

నిజమైన సర్వర్‌పై తొమ్మిది నెలల నిర్వహణ వ్యయం

పరిశీలనకు 26.10 ను ఉదాహరణగా తీసుకోండి. ఇది 15 October 2026న విడుదలవుతుంది. దీని security maintenance July 2027లో ముగుస్తుంది. July 2026లో 25.10కు ముగిసిన అదే తొమ్మిది నెలల నమూనా ఇది. దీన్ని calendar ప్రకారం చూస్తే, ప్రతి మూడు త్రైమాసికాలకు ఒక maintenance window ఉన్నట్లు కనిపిస్తుంది. కానీ ఈ calendar అర్థం తప్పు. ఖర్చు పెరిగే విధంగా అది తప్పు.

ఒక release upgrade operating systemను అదే సిస్టమ్‌లో భర్తీ చేస్తుంది. do-release-upgrade apt sourcesను తిరిగి రాస్తుంది, third party repositoriesను disable చేస్తుంది, దాదాపు ప్రతి installed package versionను మార్చుతుంది, మీరు మార్చిన config files గురించి అడగడానికి ఆగుతుంది, చివర్లో reboot చేస్తుంది. అందుకే ఇది ముందుగా ప్రణాళిక చేసిన window కావాలి; background job కాదు.

ssh ద్వారా దీన్ని నడిపితే మీ connection తెగిపోకుండా tool రక్షణ కల్పిస్తుంది. ఇది స్వంత screen sessionను ప్రారంభించి, రెండవ sshdను తెరుస్తుంది. ముందుగా దీనిని తెలియజేస్తుంది:

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.

దాన్ని అలాగే ఉంచండి. మీ firewall లేదా provider యొక్క separate network firewall 1022ను block చేస్తే ఈ fallback అందుబాటులో ఉండదు. అప్పుడు connection తెగిపోతే సగం upgrade అయిన package set మిగులుతుంది. మీరే tmux లేదా screen లోపల దీన్ని నడిపితే, ఏ boxపైనా అదే రక్షణ లభిస్తుంది.

Config file prompts వల్ల పదిహేను నిమిషాల 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 ?

మీ fileను ఉంచుకుంటే కొత్త defaultలో మారిన అంశాలు మీకు అందవు. Maintainer fileను స్వీకరిస్తే, మీరు తిరిగి అమలు చేసే వరకు మీ hardening తొలగిపోతుంది. ఆ releaseలో ఏమి మారిందో తెలుసుకోకుండా ఈ రెండు సమాధానాల్లో ఏదీ సురక్షితం కాదు. అందుకే release notes చదవడం ఈ windowలో భాగం; అది ఐచ్ఛికమైన ముందస్తు పని కాదు.

తర్వాత boxes సంఖ్యతో గుణించండి. Interim trackలో ఒక VPS ఉంటే ఐదు సంవత్సరాల్లో 10 upgrade windows వస్తాయి. ప్రతి boxను image నుంచి తిరిగి నిర్మించి పారవేయగలిగితే తప్ప, 5 VPS boxesకు 50 windows వస్తాయి. అదే కాలంలో LTS trackలో 5 boxesకు 5 upgrades మాత్రమే ఉంటాయి. ప్రతి upgrade ఏ నెలలో జరగాలో మీరే ఎంచుకోవచ్చు.

Ubuntu release ను ఎందుకు దాటలేరో

Upgrade paths ముందుగానే నిర్ణయించబడి ఉంటాయి. Interim release తరువాతి release కు upgrade అవుతుంది. LTS release నేరుగా తరువాతి LTS release కు upgrade అవుతుంది, లేదా మీరు కోరితే తరువాతి interim release కు upgrade అవుతుంది. ఏదీ ఒకేసారి రెండు releaseలను దాటదు. 26.10 నుంచి 28.04 LTS కు చేరాలంటే 27.04 మరియు 27.10 మీదుగా వెళ్లాలి, లేదా ఆ machine ను మళ్లీ install చేయాలి.

ఈ విధానం ఎందుకు మారదో అర్థం చేసుకోవడానికి దాని mechanism తెలుసుకోవడం ఉపయోగకరం. do-release-upgrade, changelogs.ubuntu.com నుంచి meta-release file ను fetch చేసి, ఒక నిర్దిష్ట transition కోసం రూపొందించిన upgrade tool ను download చేస్తుంది. Canonical ఒక్కో transition ను విడిగా build చేసి test చేస్తుంది. అందువల్ల ఒక release ను దాటే jump కు tool గానీ testing గానీ ఉండదు. జాగ్రత్త కారణంగా upgrader తిరస్కరించడం లేదు. అందించడానికి అక్కడ ఏమీ లేదు.

మీకు ఏ release చూపించాలో ఒక config line నిర్ణయిస్తుంది:

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

Prompt=lts తరువాతి LTS ను మాత్రమే అందిస్తుంది. Prompt=normal, LTS అయినా కాకపోయినా, తరువాతి release ను అందిస్తుంది. Prompt=never ఏదీ అందించదు. మీరు ప్రణాళిక చేయని upgrade ను మంచి ఉద్దేశంతో ఉన్న సహోద్యోగి ప్రారంభించకుండా ఆపడానికి ఇది ఉపయోగపడుతుంది. LTS కాని release లో lts, normal లాగే ఖచ్చితంగా పనిచేస్తుంది. కారణం, 26.10 తరువాతి release రెండు settings లోనూ 27.04 కావడమే. ఈ check Checking for a new Ubuntu release ను print చేస్తుంది. తరువాత New release ... available. line లేదా No new release found. ను చూపిస్తుంది.

మరొక scheduling నియమం కూడా చాలామందిని తప్పుదారి పట్టిస్తుంది. కొత్త LTS విడుదలైన రోజునే LTS నుంచి LTS upgrade అందుబాటులోకి రాదు. అది మొదటి point release తో ప్రారంభమవుతుంది. 26.04.1 27 August 2026న schedule చేయబడింది. 2026 వేసవిలో Prompt=lts కలిగిన 24.04 box, No new release found. కు సమాధానం ఇచ్చిందని అది విఫలమైందని అర్థం కాదు. అది policy ప్రకారం పనిచేస్తోంది. Path అందుబాటులోకి వచ్చినప్పుడు, 24.04 నుంచి 26.04 LTS upgrade ను plan చేసి rehearse చేయాల్సిన run అవుతుంది.

ఇంటరిమ్ release సరైన ఎంపిక అయ్యే సందర్భాలు

ఇది నిజంగా ప్రయోజనకరంగా ఉండే నాలుగు సందర్భాలు:

• ఈ సర్వర్‌లో ఇప్పుడే అవసరమైన kernel లేదా userspace version LTS archive లో అందుబాటులో ఉండదు.
• ఆ machine build host, CI runner లేదా test box అయి ఉండి, దాన్ని image నుంచి తిరిగి నిర్మిస్తే upgrade అనేది maintenance window కాకుండా కొత్త instance అవుతుంది.
• LTS freeze అయిన తర్వాత hardware లేదా hypervisor feature అందుబాటులోకి వచ్చింది, దానికి backport లేదు.
• తదుపరి LTS లో ఏమి ఉంటుందో మీరు పరీక్షిస్తున్నారు. 28.04 అనేది 26.10, 27.04 మరియు 27.10 ఆధారంగా రూపొందుతుంది. spare VPS లో breaking change ను గుర్తించడం, ముఖ్యమైన server లో గుర్తించడం కంటే తక్కువ ఖర్చుతో పూర్తవుతుంది.

కొత్త distribution కాకుండా ఒక కొత్త package మాత్రమే కావాలనుకునే వారు చాలామంది interim release వైపు వెళ్తారు. దీనికి తక్కువ ఖర్చుతో రెండు ప్రత్యామ్నాయాలు ఉన్నాయి. hardware enablement stack తరువాతి releases నుంచి kernels ను LTS లోకి తీసుకువస్తుంది: 24.04లో అది sudo apt install linux-generic-hwe-24.04. రెండో point release నుంచి ప్రారంభమై, ప్రతి point release వద్ద అది ముందుకు update అవుతుంది. ఒకే application కోసం container image లేదా vendor యొక్క స్వంత repository ఉపయోగిస్తే, మొత్తం operating system ను మార్చకుండా ఒక భాగాన్ని మాత్రమే update చేయవచ్చు.

interim release ఎంచుకోకూడని సందర్భాలు

• చెల్లింపు వినియోగదారులు ఉన్న లేదా on-call rotation అమలులో ఉన్న ఏ వ్యవస్థకైనా. మీరు ఎప్పుడూ ఉపయోగించకపోవచ్చే package versions కోసం సంవత్సరానికి రెండుసార్లు తప్పనిసరి upgrade ను స్వీకరించాల్సి వస్తుంది.
• unattended-upgrades మీ security patching ను నిర్వహిస్తున్న ఏ server అయినా. ఆ automation, అది updates పొందే security pocket ఎంత మంచిదో అంతవరకే విశ్వసనీయంగా ఉంటుంది.
• మీరు చేతితో upgrade చేసే fleet. ఎందుకంటే వాస్తవ ఖర్చు ఒక upgrade window ను serverల సంఖ్యతో గుణించినంత ఉంటుంది.
• మీరు install చేసి ఒక సంవత్సరం పాటు పరిశీలించని ఏదైనా వ్యవస్థ. మీరు మర్చిపోయిన interim release, తొమ్మిది నెలల తర్వాత patch చేయని internet-facing serverగా మారుతుంది.

చివరి సమస్య నిశ్శబ్దంగా జరుగుతుంది. అందుకే అది ప్రమాదకరం. ఒక release end of life కు చేరుకున్నప్పుడు దాని packages old-releases.ubuntu.com కు తరలించబడతాయి. అందువల్ల sudo apt update archive.ubuntu.com కు చేసిన అభ్యర్థనలపై 404 errors తో విఫలమవడం ప్రారంభిస్తుంది. Diskలోని package lists పాతబడిపోతాయి. unattended-upgrades తన timer ప్రకారం నడుస్తూనే ఉంటుంది. /var/log/unattended-upgrades/unattended-upgrades.log లో ఇలాంటి lines ను రాస్తూనే ఉంటుంది:

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

పూర్తిగా patched అయిన serverలోనూ, నాలుగు నెలల క్రితమే release ముగిసిన serverలోనూ ఆ line ఒకే విధంగా కనిపిస్తుంది. ఎవరైనా apt errors చదవకపోతే లేదా end of life తేదీని track చేయకపోతే, మీరు ఏ serverను పరిశీలిస్తున్నారో machineలోని ఏ సూచన కూడా తెలియజేయదు.

మధ్యంతర విడుదలల్లో ముందుగా వచ్చే మార్పుల రకం

March 2026లో Ubuntu Discourseలో Canonical ఇంజినీర్ 26.10లో secure boot కోసం అందించే signed GRUB bootloader నుంచి కొన్ని భాగాలను తొలగించాలని ప్రతిపాదించారు. ఈ ప్రతిపాదనలో btrfs, hfsplus, xfs మరియు zfs కోసం filesystem drivers, JPEG మరియు PNG image parsers, Apple partition tables, LVMపై ఉన్న /boot, RAID 1 మినహా software RAID, అలాగే LUKS encrypted /boot తొలగించబడతాయి. Bootloaderలోని parsers భద్రతా లోపాలకు పదేపదే కారణమవుతుండటం, storage మరియు encryption logicను initramfsలో ఉంచడం సరైనదని పేర్కొన్న కారణం. initramfs అనేది kernel నిజమైన rootను mount చేయడానికి ముందు mount చేసే చిన్న initial RAM filesystem. August 2026 నాటికి ఇది చర్చలో ఉన్న ప్రతిపాదన మాత్రమే; విడుదలైన మార్పు కాదు.

చాలా VPS instancesపై దీనివల్ల ఎలాంటి మార్పూ ఉండదు. అవి సాధారణంగా secure boot లేకుండా, GPT partition tableలోని plain ext4 /boot నుంచి boot అవుతాయి. ఊహించకుండా మీ వ్యవస్థను తనిఖీ చేయండి. మీ root ZFS అయితే, లేదా /boot btrfsపై లేదా LUKSలో ఉంటే, ఇలాంటి మార్పు interim trackలో ముందుగా మీ వ్యవస్థను ప్రభావితం చేసే అవకాశం ఉంది. ప్రభావిత వినియోగదారులు LTSలోనే ఉండాలని ఆ threadలో ఇచ్చిన సలహా. ఈ సలహా మొత్తం వాదనను ఒక వాక్యంలో చెబుతుంది. Interim releasesలో మార్పులను ముందుగా పరీక్షిస్తారు. రెండు సంవత్సరాల interim releases వాటివల్ల ఏవి విరిగిపోతాయో గుర్తించిన తర్వాత ఆ మార్పులు LTSలోకి వస్తాయి.

ప్రతి interim releaseలో ఇదే విధానం చిన్న స్థాయిలోనూ కనిపిస్తుంది. Database, language runtime మరియు init configurationకు సంబంధించిన default versions ముందుకు మారుతాయి. అందువల్ల పనిచేసిన config files ఇక పనిచేయకపోవచ్చు. Default versionsను ముందుకు మార్చడం interim release ఉద్దేశించిన పనిలో భాగం. కాబట్టి ఆ పది upgradesలో ప్రతి దానికి ముందు release notes చదవడం మీరు అంగీకరించిన నిర్వహణ భారంలో భాగం.

సర్వర్‌ను నిర్మించేటప్పుడు track ఎంచుకోవడం

ఇన్‌స్టాల్ చేసే సమయంలోనే track ఎంచుకోండి. తర్వాత దాన్ని మార్చాలంటే మళ్లీ install చేయాలి లేదా వరుసగా upgrades చేయాలి. కొత్త serverలో మీరు ఏ స్థితిలో ఉన్నారో నాలుగు commands చెబుతాయి:

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

lsb_release -a మీరు install చేయాలని ఉద్దేశించిన release పేరును చూపాలి. LTSలో description line చివర LTS తో ముగుస్తుంది. Prompt line మీరు ఎంచుకున్న track కు సరిపోవాలి; provider imageలో ముందుగా వచ్చిన track ఏదైనా దానితో సరిపోవాల్సిన అవసరం లేదు. ప్రస్తుత LTSలో do-release-upgrade -c కు సమాధానం No new release found. గా ఉండాలి. బదులుగా అది interim releaseను చూపిస్తే, Prompt విలువ normal గా ఉంది. అది ఉద్దేశపూర్వకమా కాదా అని ఎవరో నిర్ణయించాలి. ఇన్‌స్టాల్ చేసిన packagesలో ఎన్ని packages ఏ update stream పరిధిలో ఉన్నాయో pro security-status చూపిస్తుంది. అలాగే machine subscriptionకు జత కాలేదని కూడా స్పష్టంగా చెబుతుంది.

తర్వాత end of life dateను మళ్లీ కనిపించే చోట రాయండి. ఆ serverకు సంబంధించిన మిగతా build notes పక్కన దాన్ని నమోదు చేయండి. ఇది కొత్త VPSలో మొదటి పది నిమిషాల్లో చేయాల్సిన పనులుతో పాటు ఉండాలి. ఎందుకంటే ఎవరి జ్ఞాపకంలో మాత్రమే ఉన్న support date ఎవరూ గమనించకుండానే ముగిసిపోతుంది. ఆరు నెలలకొకసారి జరిగే మార్పుల నుంచి పూర్తిగా తప్పించుకోవాలనుకుంటే, fleetను ఏదో ఒకదానికి కట్టుబరచే ముందు Linuxతో పోల్చిన FreeBSD release model గురించి ఒక గంట చదవడం ఉపయోగకరం.

FAQ

Ubuntu interim release ను production server పై నడపాలా?

దాదాపు ప్రతి సందర్భంలోనూ వద్దు. interim release విడుదలైన తొమ్మిది నెలల తర్వాత security updates అందుకోవడం ఆపేస్తుంది. అందువల్ల production వ్యవస్థను ఆ track పై ఉంచితే, ఏడాదికి సుమారు రెండుసార్లు తప్పనిసరిగా upgrade చేయాల్సి వస్తుంది. దీనికి నిజమైన మినహాయింపులు image నుంచి ఎలాగైనా మళ్లీ నిర్మించే యంత్రాలు. ఉదాహరణకు CI runners మరియు build hosts లో upgrade అంటే నిర్వహణ window కాదు, కొత్త instance సృష్టించడం. నిజమైన users ఆ server పై ఆధారపడితే LTS ను install చేసి, మిగిలిన నిర్వహణ సమయాన్ని ఇతర పనులకు ఉపయోగించండి.

Ubuntu interim release కు ఎంతకాలం support ఉంటుంది?

తొమ్మిది నెలలు. 26.10 15 October 2026న విడుదలవుతుంది. దాని security maintenance July 2027లో ముగుస్తుంది. July 2026లో ముగిసిన 25.10కు కూడా ఇదే విధానం ఉంది. ప్రతి interim release ఇదే చక్రాన్ని అనుసరిస్తుంది: April లేదా Octoberలో విడుదలై, తొమ్మిది నెలల తర్వాత support ముగుస్తుంది. LTS కు ఐదు సంవత్సరాల standard security maintenance ఉంటుంది. Ubuntu Proతో ఇది పది సంవత్సరాలకు పొడిగించవచ్చు. August 2026 నాటికి వ్యక్తిగత వినియోగానికి గరిష్ఠంగా ఐదు machines వరకు ఇది ఉచితం.

Upgrade చేసేటప్పుడు Ubuntu releases ను దాటవచ్చా?

లేదు. do-release-upgrade ఒకేసారి ఒక release మాత్రమే ముందుకు తీసుకెళ్తుంది. interim release తదుపరి releaseకు వెళ్తుంది. LTS మాత్రం తదుపరి LTSకు నేరుగా upgrade కావచ్చు. 26.10 నుంచి 28.04 LTSకు వెళ్లాలంటే ముందుగా 27.04, తరువాత 27.10 ద్వారా upgrade చేయాలి. లేకపోతే machineను మళ్లీ install చేయాలి. Canonical ప్రతి transitionను ఒక్కొక్కటిగా build చేసి test చేస్తుంది. Upgrader కూడా ఆ నిర్దిష్ట మార్పు కోసం toolను download చేస్తుంది. అందువల్ల రెండు releases దాటే jumpకు tool ఉండదు, అది ఎప్పుడూ అందించబడదు.

నా Ubuntu release end of life చేరుకున్నప్పుడు ఏమి జరుగుతుంది?

దాని packages old-releases.ubuntu.comకు తరలించబడతాయి. అందువల్ల sudo apt update archive.ubuntu.comకు పంపే అభ్యర్థనల్లో 404 errors రావడం ప్రారంభమవుతుంది. ఆ releaseకు కొత్త security updates ఏవీ ప్రచురించబడవు. Machineపై దీనిని తెలియజేసే ప్రత్యేక ప్రకటన ఉండదు. Server నడుస్తూనే ఉంటుంది, network trafficను అందిస్తూనే ఉంటుంది. కానీ అందులో కనుగొనబడే ప్రతి కొత్త vulnerability పరిష్కారం లేకుండా మిగులుతుంది. Recovery కోసం తక్కువ సమయంలో release upgrade చేయాలి లేదా machineను మళ్లీ నిర్మించాలి. అందువల్ల symptoms కనిపించే వరకు వేచి ఉండకుండా తేదీని పర్యవేక్షించండి.

కొత్త hardwareకు LTS kernel చాలా పాతదా?

సాధారణంగా కాదు. LTS తన ప్రారంభ kernelనే ఐదు సంవత్సరాలు ఉపయోగించదు. Hardware Enablement stack, HWE, తరువాతి releasesలోని kernelsను point releases ద్వారా LTSలోకి తీసుకువస్తుంది. Server installలో linux-generic-hwe-24.04 వంటి package ద్వారా దీనికి opt in చేయవచ్చు. Kernel సమస్య అని ఊహించేముందు uname -rతో ప్రస్తుతం నడుస్తున్న kernelను పరిశీలించండి. అవసరమైనది kernel version కాక userspace version అయితే, మొత్తం machineను interim trackకు మార్చడం కంటే container లేదా vendor repository ఉపయోగించడం చాలా చిన్న మార్పు.