Ubuntu LTS और interim release में क्या अंतर है?

Ubuntu LTS बनाम interim releases: संक्षिप्त उत्तर

सर्वर पर Ubuntu LTS और interim release के बीच चयन एक ही संख्या पर निर्भर करता है: वह release कितने समय तक security updates प्राप्त करेगी। एक LTS को पांच वर्षों का मानक security maintenance मिलता है। एक interim release को नौ महीने मिलते हैं, जिसके बाद updates बंद हो जाते हैं, इसलिए आपको upgrade करना होगा या सिस्टम को फिर से बनाना होगा। जिस भी चीज़ पर अन्य लोग निर्भर हैं, उस पर LTS चलाएं। interim release केवल वहां चलाएं जहां सिस्टम को फिर से बनाना ऐसा काम हो जिसे आप बिना किसी से पूछे कर सकें।

LTS का अर्थ है long term support। Canonical हर दो साल में एक LTS जारी करता है, जो सम वर्षों (even years) के अप्रैल में आता है, और बीच के समय में हर छह महीने में एक interim release जारी करता है। 26.04 LTS को 23 April 2026 को ship किया गया था और इसका मानक security maintenance 2031 तक चलता है। 26.10 को 15 October 2026 को आना है, और यह एक interim release है, इसलिए इसकी समय-सीमा 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
  }
]

ये आंकड़े अगस्त 2026 तक Canonical द्वारा प्रकाशित नीति के अनुसार हैं, न कि किसी test box से लिए गए माप। एक LTS में 60 महीनों का मानक security maintenance मिलता है, जिसका अर्थ है कि पांच वर्षों में 1 नियोजित release upgrade करने होते हैं। एक interim release में 9 महीनों का support मिलता है। उसी पांच साल की अवधि के लिए interim track पर बने रहने पर 10 release upgrades की आवश्यकता होती है, क्योंकि आप किसी release को छोड़ नहीं सकते और पांच वर्षों में दस releases आते हैं।

एक Ubuntu Pro subscription LTS के आंकड़ों को बढ़ाकर 120 महीने, यानी दस साल कर देता है, और coverage को main component से पूरे archive तक विस्तृत कर देता है। अगस्त 2026 तक, Pro व्यक्तिगत उपयोग के लिए पांच मशीनों तक मुफ्त है, जो अधिकांश छोटे VPS fleets को कवर करता है। interim release के लिए ऐसा कोई विकल्प उपलब्ध नहीं है। नौ महीने ही पूरी पेशकश है, और कोई भी subscription इसे आगे नहीं बढ़ाता है।

एक वास्तविक सर्वर पर नौ महीने की लागत

उदाहरण के तौर पर 26.10 को लें। यह 15 October 2026 को रिलीज़ होता है और इसकी सुरक्षा देखरेख (security maintenance) July 2027 में समाप्त होती है। यह वही नौ महीने का पैटर्न है जो 25.10 के लिए July 2026 में समाप्त हुआ था। कैलेंडर के अनुसार देखने पर, यह हर तीन तिमाही में एक मेंटेनेंस विंडो जैसा लगता है। कैलेंडर का यह आकलन गलत है, और यह गलत दिशा में महंगा साबित होता है।

एक रिलीज़ अपग्रेड ऑपरेटिंग सिस्टम को उसी स्थान पर बदल देता है। do-release-upgrade apt सोर्सेज को फिर से लिखता है, थर्ड-पार्टी रिपॉजिटरी को डिसेबल करता है, लगभग हर इंस्टॉल किए गए पैकेज का वर्शन बदलता है, आपके द्वारा एडिट की गई कॉन्फ़िगरेशन फाइलों के बारे में पूछता है, और अंत में रीबूट करता है। इसीलिए यह एक नियोजित विंडो है, न कि बैकग्राउंड जॉब।

इसे ssh पर चलाएं और यह टूल आपको अपना कनेक्शन टूटने से बचाता है। यह अपना खुद का screen सेशन शुरू करता है और एक दूसरा 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.

इसे ऐसा करने दें। यदि आपका फायरवॉल या आपके प्रोवाइडर का अलग नेटवर्क फायरवॉल 1022 को ब्लॉक करता है, तो वह फॉलबैक मौजूद नहीं होगा, और कनेक्शन टूटने पर पैकेज सेट आधा-अधूरा अपग्रेड रह जाएगा। tmux या screen के अंदर स्वयं चलाने से आपको किसी भी बॉक्स पर वही सुरक्षा मिलती है।

कॉन्फ़िगरेशन फाइल के प्रॉम्प्ट ही पंद्रह मिनट के अपग्रेड को एक घंटे में बदल देते हैं:

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 ?

अपनी फाइल रखने का मतलब है कि आप उन बदलावों से चूक जाते हैं जो नए डिफ़ॉल्ट में किए गए हैं। मेंटेनर की फाइल लेने का मतलब है कि आपकी हार्डनिंग तब तक चली गई जब तक आप उसे वापस नहीं डाल देते। उस रिलीज़ में क्या बदला है, यह जाने बिना कोई भी उत्तर सुरक्षित नहीं है, इसीलिए रिलीज़ नोट्स पढ़ना मेंटेनेंस विंडो का हिस्सा है, न कि वैकल्पिक होमवर्क।

फिर इसे बॉक्स की संख्या से गुणा करें। इंटरिम ट्रैक पर एक VPS का मतलब पांच वर्षों में दस अपग्रेड विंडो है। पांच VPS बॉक्स का मतलब पचास है, जब तक कि हर बॉक्स डिस्पोजेबल न हो और इमेज से दोबारा न बनाया जाए। LTS ट्रैक पर पांच बॉक्स का मतलब उसी अवधि में पांच अपग्रेड है, और आप चुन सकते हैं कि प्रत्येक अपग्रेड किस महीने होगा।

आप Ubuntu release को क्यों नहीं छोड़ सकते

Upgrade paths निश्चित होते हैं। एक interim release हमेशा अगली release पर upgrade होती है, चाहे वह कोई भी हो। एक LTS सीधे अगली LTS पर upgrade होती है, या यदि आप चाहें तो अगली interim release पर। कोई भी चीज़ एक साथ दो कदम आगे upgrade नहीं होती। 26.10 से 28.04 LTS तक पहुँचने का मतलब है 27.04 और 27.10 से होकर गुजरना, या मशीन को फिर से install करना।

इस mechanism को जानना महत्वपूर्ण है, क्योंकि यह बताता है कि नियम में कोई ढील नहीं दी जाएगी। do-release-upgrade changelogs.ubuntu.com से एक meta-release file लाता है, और फिर एक विशिष्ट transition के लिए बने upgrade tool को download करता है। Canonical एक बार में केवल एक transition को बनाता और test करता है, इसलिए जो jump किसी release को छोड़ती है, उसके लिए न तो कोई tool होता है और न ही कोई testing। upgrader सावधानी के कारण मना नहीं कर रहा है। उसके पास देने के लिए वहां कुछ भी नहीं है।

आपको कौन सी release offer की जाएगी, यह config की एक line से तय होता है:

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

Prompt=lts केवल अगली LTS offer करता है। Prompt=normal अगली release offer करता है, चाहे वह LTS हो या न हो। Prompt=never कुछ भी offer नहीं करता, इसी तरह आप किसी सहकर्मी को अपनी योजना के बिना upgrade शुरू करने से रोकते हैं। ऐसी release पर जो LTS नहीं है, lts बिल्कुल normal की तरह व्यवहार करता है, क्योंकि 26.10 के बाद अगली release दोनों ही setting में 27.04 है। check Checking for a new Ubuntu release print करता है और फिर या तो New release ... available. line या No new release found.।

एक और scheduling नियम लोगों को उलझाता है। LTS से LTS upgrade उस दिन offer नहीं किया जाता जिस दिन नई LTS release होती है। यह पहली point release के साथ खुलता है, और 26.04.1 को 27 August 2026 के लिए निर्धारित किया गया है। एक 24.04 box जिसमें Prompt=lts था और जो 2026 की गर्मियों तक No new release found. का जवाब दे रहा था, वह खराब नहीं था। वह policy का पालन कर रहा था। जब path खुलता है, तो 24.04 से 26.04 LTS upgrade ही वह प्रक्रिया है जिसकी योजना बनानी और तैयारी करनी चाहिए।

जब interim release सही विकल्प हो

चार स्थितियाँ जहाँ यह वास्तव में बेहतर है:

• आपको किसी ऐसे kernel या userspace version की आवश्यकता है जो LTS archive में उपलब्ध नहीं है, और वह आपको इसी सर्वर पर अभी चाहिए।
• यह मशीन एक build host, CI runner या test box है जिसे आप image से फिर से बनाते हैं, इसलिए upgrade का अर्थ maintenance window के बजाय एक नई instance तैयार करना है।
• कोई hardware या hypervisor feature LTS के freeze होने के बाद आया है, और उसका कोई backport उपलब्ध नहीं है।
• आप यह जाँच रहे हैं कि अगले LTS में क्या शामिल होगा। 28.04 को 26.10, 27.04 और 27.10 से मिलाकर बनाया जाता है, और किसी spare VPS पर breaking change ढूँढना उस सर्वर की तुलना में सस्ता है जो आपके लिए महत्वपूर्ण है।

ज्यादातर लोग जो interim release चुनते हैं, उन्हें केवल एक नया package चाहिए होता है, न कि पूरी distribution। इसके दो सस्ते विकल्प मौजूद हैं। Hardware enablement stack बाद के releases से kernels को LTS में लाता है: 24.04 पर यह sudo apt install linux-generic-hwe-24.04 है, और यह प्रत्येक point release के साथ आगे बढ़ता है, जिसकी शुरुआत दूसरे point release से होती है। किसी एक application के लिए, container image या vendor का अपना repository पूरे operating system को बदलने के बजाय केवल उस एक हिस्से को update कर देता है।

जब interim release का चुनाव गलत होता है

• कोई भी ऐसी सेवा जिसमें भुगतान करने वाले उपयोगकर्ता हों या on-call rotation हो। आप वर्ष में दो बार अनिवार्य upgrade स्वीकार कर रहे होंगे, जबकि इसके बदले में आपको ऐसे package versions मिल सकते हैं जिनकी आपको कभी आवश्यकता ही न हो।
• कोई भी ऐसा सर्वर जहाँ unattended-upgrades आपके लिए security patching का काम कर रहा हो। वह automation केवल उसी security pocket तक प्रभावी है जहाँ से वह updates प्राप्त करता है।
• सर्वरों का ऐसा समूह जिसे आप मैन्युअल रूप से upgrade करते हैं, क्योंकि वास्तविक लागत एक maintenance window को सर्वरों की कुल संख्या से गुणा करने पर आती है।
• कोई भी ऐसी चीज़ जिसे आप install करने के बाद एक साल तक नहीं देखते। एक interim release जिसे आप भूल गए हैं, वह नौ महीने बाद internet पर खुला एक unpatched सर्वर बन जाता है।

वह अंतिम विफलता शांत होती है, जो इसे खतरनाक बनाती है। जब कोई release अपने जीवनकाल (end of life) के अंत तक पहुँचती है, तो उसके packages old-releases.ubuntu.com पर चले जाते हैं, इसलिए sudo apt update, archive.ubuntu.com के विरुद्ध 404 errors के साथ विफल होने लगता है। डिस्क पर मौजूद package lists पुरानी हो जाती हैं। unattended-upgrades अपने timer पर चलता रहता है और /var/log/unattended-upgrades/unattended-upgrades.log में इस तरह की पंक्तियाँ लिखता रहता है:

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

यह पंक्ति एक पूरी तरह से patched सर्वर और एक ऐसे सर्वर पर समान दिखाई देती है जिसकी release चार महीने पहले ही समाप्त हो चुकी है। जब तक कोई apt errors को नहीं पढ़ता या end of life की तारीख को ट्रैक नहीं करता, तब तक मशीन पर ऐसी कोई चीज़ नहीं है जो आपको यह बता सके कि आप किस स्थिति को देख रहे हैं।

वह बदलाव जो सबसे पहले interim track पर आता है

मार्च 2026 में एक Canonical इंजीनियर ने Ubuntu discourse पर 26.10 में secure boot के लिए ship होने वाले signed GRUB bootloader को हटाने का प्रस्ताव रखा। यह प्रस्ताव btrfs, hfsplus, xfs और zfs के लिए filesystem drivers, JPEG और PNG image parsers, Apple partition tables, /boot on LVM, RAID 1 के अलावा अन्य software RAID, और LUKS encrypted /boot को हटा देता है। इसका कारण यह बताया गया है कि bootloader के भीतर मौजूद parsers सुरक्षा खामियों का एक निरंतर स्रोत हैं, और storage तथा encryption logic को initramfs में होना चाहिए, जो कि वह छोटा initial RAM filesystem है जिसे kernel वास्तविक root से पहले mount करता है। अगस्त 2026 तक यह चर्चा के अधीन एक प्रस्ताव है, न कि कोई लागू किया गया बदलाव।

अधिकांश VPS instances के लिए इससे कोई बदलाव नहीं होगा, क्योंकि वे GPT partition table पर एक साधारण ext4 /boot से secure boot के बिना boot होते हैं। अनुमान लगाने के बजाय अपना सिस्टम चेक करें। यदि आपका root ZFS है, या /boot btrfs पर या LUKS के भीतर स्थित है, तो यह बिल्कुल उसी श्रेणी का बदलाव है जो interim track पर आपको सबसे पहले मिलता है, और प्रभावित उपयोगकर्ताओं के लिए thread की अपनी सलाह यह है कि वे LTS पर बने रहें। वह सलाह ही एक वाक्य में पूरी बहस है। Interim releases वह जगह हैं जहाँ बदलावों को आजमाया जाता है। LTS वह जगह है जहाँ वे दो साल के interim releases द्वारा यह पता लगाने के बाद पहुँचते हैं कि वे क्या तोड़ते हैं।

यही पैटर्न हर interim release में छोटे तरीकों से दिखाई देता है। Database, language runtime और init configuration के default versions आगे बढ़ते हैं, इसलिए जो config files काम करती थीं, वे काम करना बंद कर सकती हैं। Defaults को आगे बढ़ाना वह काम है जिसके लिए interim release मौजूद है, जिसका अर्थ है कि उन दस upgrades में से प्रत्येक से पहले release notes को पढ़ना उस कीमत का हिस्सा है जिसे चुकाने के लिए आप सहमत हुए हैं।

बॉक्स बनाते समय ट्रैक का चुनाव

इंस्टॉल करते समय ही ट्रैक चुनें, क्योंकि बाद में इसे बदलने का मतलब है रीइंस्टॉल करना या अपग्रेड की एक लंबी प्रक्रिया। एक नए सर्वर पर, चार कमांड आपको आपकी स्थिति बता देते हैं:

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

lsb_release -a में उस रिलीज का नाम होना चाहिए जिसे आप इंस्टॉल करना चाहते थे, और एक LTS पर विवरण पंक्ति LTS के साथ समाप्त होती है। Prompt पंक्ति आपके द्वारा चुने गए ट्रैक से मेल खानी चाहिए, न कि उस इमेज से जो प्रोवाइडर ने गलती से शिप कर दी हो। एक वर्तमान LTS पर do-release-upgrade -c का उत्तर No new release found. होना चाहिए। यदि यह आपको इसके बजाय कोई अंतरिम (interim) रिलीज ऑफर करता है, तो Prompt को normal पर सेट किया गया है और किसी को यह तय करना चाहिए कि क्या यह जानबूझकर किया गया था। pro security-status रिपोर्ट करता है कि कितने इंस्टॉल किए गए पैकेज किस अपडेट स्ट्रीम के अंतर्गत आते हैं, और स्पष्ट रूप से बताता है कि मशीन किसी सब्सक्रिप्शन से जुड़ी नहीं है।

फिर एंड-ऑफ-लाइफ (end of life) तिथि को वहां लिखें जहाँ आप इसे दोबारा देख सकें, उस सर्वर के बाकी बिल्ड नोट्स के साथ। यह नए VPS पर पहले दस मिनट के अन्य कार्यों के साथ आता है, क्योंकि जो सपोर्ट तिथि केवल किसी की याददाश्त में रहती है, वही बिना किसी के ध्यान में आए समाप्त हो जाती है। यदि आप छह महीने के बदलाव (churn) से पूरी तरह बचना चाहते हैं, तो FreeBSD रिलीज मॉडल बनाम Linux पर एक घंटे का अध्ययन करना उचित है, इससे पहले कि आप किसी फ्लीट को किसी एक के लिए प्रतिबद्ध करें।

FAQ

क्या मुझे प्रोडक्शन सर्वर पर Ubuntu interim release चलानी चाहिए?

लगभग हर मामले में, नहीं। एक interim release के जारी होने के नौ महीने बाद उसे security updates मिलना बंद हो जाते हैं, इसलिए उस ट्रैक पर प्रोडक्शन का मतलब है कि आपको साल में लगभग दो बार अनिवार्य रूप से अपग्रेड करना होगा। इसके एकमात्र अपवाद वे मशीनें हैं जिन्हें आप वैसे भी इमेज से फिर से बनाते हैं, जैसे कि CI runners और build hosts, जहाँ अपग्रेड का मतलब एक नया इंस्टेंस बनाना है, न कि कोई मेंटेनेंस विंडो। यदि वास्तविक उपयोगकर्ता उस सर्वर पर निर्भर हैं, तो LTS इंस्टॉल करें और अपग्रेड में लगने वाले समय को किसी अन्य काम में लगाएँ।

Ubuntu interim release कितने समय तक सपोर्ट की जाती है?

नौ महीने। 26.10 को 15 अक्टूबर 2026 को जारी किया गया था और इसका security maintenance जुलाई 2027 में समाप्त हो जाता है, ठीक उसी तरह जैसे 25.10 जुलाई 2026 में समाप्त हुआ था। हर interim release इसी पैटर्न का पालन करती है: अप्रैल या अक्टूबर में जारी होती है और नौ महीने बाद समाप्त हो जाती है। एक LTS को पाँच साल का मानक security maintenance मिलता है, जिसे Ubuntu Pro के साथ दस साल तक बढ़ाया जा सकता है, जो अगस्त 2026 तक पाँच मशीनों तक व्यक्तिगत उपयोग के लिए मुफ्त है।

क्या अपग्रेड करते समय मैं Ubuntu releases को छोड़ सकता हूँ?

नहीं। do-release-upgrade एक बार में एक ही कदम आगे बढ़ता है: एक interim release अगली release पर जाती है, और एक LTS सीधे अगली LTS पर जा सकती है। 26.10 से 28.04 LTS तक पहुँचने का मतलब है कि पहले 27.04 और 27.10 के माध्यम से अपग्रेड करना, या मशीन को फिर से इंस्टॉल करना। Canonical एक बार में एक ही ट्रांजिशन का निर्माण और परीक्षण करता है और अपग्रेडर उस विशिष्ट जंप के लिए एक टूल डाउनलोड करता है, इसलिए दो-चरणीय जंप के लिए कोई टूल उपलब्ध नहीं है और यह कभी भी ऑफर नहीं किया जाता है।

जब मेरी Ubuntu release का end of life आ जाता है तो क्या होता है?

इसके पैकेज old-releases.ubuntu.com पर चले जाते हैं, इसलिए sudo apt update, archive.ubuntu.com के साथ 404 त्रुटियों के कारण विफल होने लगता है, और उस release के लिए कोई नया security update जारी नहीं किया जाता है। मशीन पर कोई भी चीज़ इसकी घोषणा नहीं करती है। सर्वर चलता रहता है और traffic सर्व करता रहता है, जबकि इसमें मौजूद हर नई भेद्यता (vulnerability) खुली रहती है। रिकवरी का मतलब है दबाव में release upgrade करना, या फिर से निर्माण करना, इसलिए लक्षणों के बजाय तारीख पर नज़र रखें।

क्या LTS kernel नए हार्डवेयर के लिए बहुत पुराना है?

आमतौर पर नहीं, क्योंकि एक LTS अपने मूल kernel को पाँच साल तक नहीं रखती है। Hardware enablement stack, HWE, बाद की releases के kernels को point releases के माध्यम से LTS में लाता है, और एक सर्वर इंस्टाल linux-generic-hwe-24.04 जैसे पैकेज के साथ इसे चुन सकता है। यह मानने से पहले कि kernel ही बाधा है, uname -r के साथ जाँचें कि आप क्या चला रहे हैं। यदि कमी kernel के बजाय userspace version की है, तो पूरी मशीन को interim ट्रैक पर ले जाने की तुलना में container या vendor repository का उपयोग करना बहुत छोटा बदलाव है।