Ubuntu LTS बनाम interim release: सर्वर के लिए क्या चुनें?

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

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

LTS का अर्थ है long term support। Canonical हर दो साल में, सम वर्षों के अप्रैल में एक LTS प्रकाशित करता है, और बीच में हर छह महीने में एक interim release। 26.04 LTS को 23 April 2026 को जारी किया गया था और इसका मानक सुरक्षा रखरखाव 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 version में 60 महीनों का standard security maintenance मिलता है, जिसका अर्थ है कि पांच वर्षों में 1 planned release upgrades की आवश्यकता होती है। एक 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 को release होता है और इसका security maintenance July 2027 में समाप्त होता है, वही नौ महीने का पैटर्न जो 25.10 के लिए July 2026 में समाप्त हुआ था। कैलेंडर के अनुसार देखने पर, यह हर तीन तिमाही में एक maintenance window जैसा लगता है। कैलेंडर का यह आकलन गलत है, और यह गलत दिशा में महंगा साबित होता है।

एक release upgrade ऑपरेटिंग सिस्टम को उसी स्थान पर बदल देता है। do-release-upgrade apt sources को फिर से लिखता है, third party repositories को disable करता है, लगभग हर installed package का version बदलता है, आपके द्वारा edit की गई config files के बारे में पूछने के लिए रुकता है, और अंत में reboot करता है। इसीलिए यह एक planned window है, न कि background job।

इसे ssh पर चलाएं और यह टूल आपको आपके connection के टूटने से बचाता है। यह अपना खुद का 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 का अलग network firewall 1022 को block करता है, तो वह fallback मौजूद नहीं होगा, और connection टूटने पर package set आधा-अधूरा upgrade होकर रह जाएगा। 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 पढ़ना optional homework के बजाय window का हिस्सा है।

फिर इसे boxes की संख्या से गुणा करें। interim track पर एक VPS का मतलब पांच वर्षों में दस upgrade windows है। पांच VPS boxes का मतलब पचास है, जब तक कि हर box disposable न हो और उसे image से rebuild न किया जाए। LTS track पर पांच boxes का मतलब उसी अवधि में पांच upgrades है, और आप चुन सकते हैं कि प्रत्येक upgrade किस महीने होगा।

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

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

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

आपको कौन सी release ऑफर की जाएगी, यह कॉन्फ़िगरेशन की एक लाइन से तय होता है:

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

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

एक और शेड्यूलिंग नियम लोगों को उलझाता है। LTS से LTS अपग्रेड उस दिन ऑफर नहीं किया जाता जिस दिन नई LTS रिलीज़ होती है। यह पहली पॉइंट release के साथ खुलता है, और 26.04.1 को 27 अगस्त 2026 के लिए निर्धारित किया गया है। पॉइंट release Ubuntu का नया वर्ज़न नहीं है, बल्कि वही release है जिसमें चार महीनों के संचित सुधारों को नए इंस्टाल मीडिया में शामिल किया गया है। यह प्रतीक्षा इसलिए होती है ताकि अपग्रेड पाथ को किसी को भी ऑफर करने से पहले उन चार महीनों की टेस्टिंग मिल सके। 24.04 वाला बॉक्स जिसमें Prompt=lts सेट था और जो 2026 की गर्मियों तक No new release found. का जवाब दे रहा था, वह खराब नहीं था। वह नीति का पालन कर रहा था। जब पाथ खुलता है, तो 24.04 से 26.04 LTS अपग्रेड ही वह प्रक्रिया है जिसकी योजना बनानी और रिहर्सल करनी चाहिए।

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

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

• आपको किसी ऐसे kernel या userspace version की आवश्यकता है जो LTS archive में उपलब्ध नहीं है, और वह आपको इसी सर्वर पर अभी चाहिए।
• यह मशीन एक build host, CI runner या test box है जिसे आप image से फिर से बनाते हैं, इसलिए upgrade का अर्थ maintenance window के बजाय एक fresh 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 हो। आप वर्ष में दो बार अनिवार्य अपग्रेड स्वीकार कर रहे होंगे, जबकि इसके बदले में आपको ऐसे package versions मिल सकते हैं जिनकी आपको कभी आवश्यकता ही न हो।
• कोई भी ऐसा सर्वर जहाँ unattended-upgrades आपके लिए security patching का काम कर रहा हो। वह automation केवल उसी security pocket तक प्रभावी है जहाँ से वह updates खींचता है।
• ऐसा सर्वर समूह जिसे आप मैन्युअल रूप से अपग्रेड करते हैं, क्योंकि वास्तविक लागत एक maintenance window को सर्वरों की कुल संख्या से गुणा करने पर आती है।
• कोई भी ऐसी चीज़ जिसे आप इंस्टॉल करने के बाद एक साल तक नहीं देखते। एक interim release जिसे आप भूल गए हैं, वह नौ महीने बाद internet-facing एक unpatched सर्वर बन जाता है।

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

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

यह पंक्ति एक पूरी तरह से पैच किए गए सर्वर और एक ऐसे सर्वर पर समान दिखती है जिसकी 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 होते हैं। अनुमान लगाने के बजाय अपना setup जांचें। यदि आपका 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 रिपोर्ट करता है कि कितने इंस्टॉल किए गए पैकेज किस अपडेट स्ट्रीम के अंतर्गत आते हैं, और स्पष्ट रूप से बताता है कि मशीन किसी सब्सक्रिप्शन से जुड़ी नहीं है।

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

FAQ

क्या मुझे production सर्वर पर Ubuntu interim release का उपयोग करना चाहिए?

लगभग हर स्थिति में, नहीं। एक interim release के release होने के नौ महीने बाद उसे security updates मिलना बंद हो जाते हैं। इसलिए, production में इस track का मतलब है कि आपको हमेशा के लिए साल में लगभग दो बार अनिवार्य upgrade window से गुजरना होगा। इसके वास्तविक अपवाद वे मशीनें हैं जिन्हें आप वैसे भी image से फिर से बनाते हैं, जैसे कि CI runners और build hosts, जहाँ upgrade का मतलब एक नया instance बनाना है, न कि कोई window। यदि वास्तविक उपयोगकर्ता उस सर्वर पर निर्भर हैं, तो LTS install करें और बचा हुआ समय किसी अन्य कार्य में लगाएँ।

Ubuntu interim release को कितने समय तक support मिलता है?

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

क्या upgrade करते समय मैं Ubuntu releases को skip कर सकता हूँ?

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

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

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

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

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