सर्व्हरसाठी Ubuntu LTS की interim release?

Ubuntu LTS विरुद्ध interim releases: थोडक्यात उत्तर

सर्व्हरसाठी Ubuntu LTS आणि interim release यांपैकी निवड करताना एकच बाब महत्त्वाची असते: त्या release ला security updates किती काळ मिळत राहतात. LTS ला standard security maintenance पाच वर्षे मिळते. interim release ला नऊ महिने updates मिळतात. त्यानंतर updates थांबतात, त्यामुळे तुम्हाला upgrade किंवा rebuild करावे लागते. इतर लोक ज्या सेवांवर अवलंबून आहेत, अशा सर्व ठिकाणी LTS चालवा. rebuild करण्यासाठी कोणाची परवानगी घेण्याची गरज नसलेल्या ठिकाणीच interim release चालवा.

LTS म्हणजे long term support. Canonical सम वर्षांच्या एप्रिलमध्ये दर दोन वर्षांनी एक LTS आणि त्यांमधील प्रत्येक सहा महिन्यांनी एक interim release प्रकाशित करते. 26.04 LTS 23 April 2026 रोजी release झाले आणि त्याची standard security maintenance 2031 पर्यंत सुरू राहते. 26.10 हे 15 October 2026 रोजी अपेक्षित आहे. ते interim release आहे, त्यामुळे त्याचे updates 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 महिन्यांचे standard security maintenance मिळते. याचा अर्थ पाच वर्षांत 1 नियोजित release upgrade करावे लागतात. Interim release ला 9 महिन्यांचे support मिळते. त्याच पाच वर्षांत interim track वर राहिल्यास 10 release upgrades करावे लागतात, कारण एखादा release वगळता येत नाही आणि पाच वर्षांत दहा release येतात.

Ubuntu Pro subscription मुळे LTS चे support 120 महिने, म्हणजे दहा वर्षे, होते. तसेच coverage main component पासून संपूर्ण archive पर्यंत वाढते. ऑगस्ट 2026 पर्यंत वैयक्तिक वापरासाठी Ubuntu Pro जास्तीत जास्त पाच मशीनवर विनामूल्य आहे. यात बहुतेक लहान VPS fleets समाविष्ट होतात. Interim release साठी यासारखी कोणतीही सुविधा नाही. नऊ महिने एवढेच पूर्ण support आहे; कोणतेही subscription ते वाढवत नाही.

प्रत्यक्ष सर्व्हरवर नऊ महिन्यांचा प्रत्यक्ष खर्च

कार्य केलेले उदाहरण म्हणून 26.10 घ्या. ते 15 October 2026 रोजी release होते आणि त्याची security maintenance July 2027 मध्ये संपते. July 2026 मध्ये 25.10 साठी संपलेल्या त्याच नऊ महिन्यांच्या पद्धतीचा हा पुढचा टप्पा आहे. Calendar नुसार पाहिल्यास, दर तीन quarters मध्ये एक maintenance window असल्यासारखे दिसते. Calendar वर आधारित हे आकलन चुकीचे आहे आणि त्याचा खर्च अधिक असतो.

Release upgrade मुळे operating system त्याच ठिकाणी replace होते. do-release-upgrade apt sources पुन्हा लिहिते, third party repositories disable करते, install केलेल्या जवळपास प्रत्येक package ची version बदलते, तुम्ही edit केलेल्या 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 चा स्वतंत्र network firewall 1022 block करत असल्यास हा fallback उपलब्ध नसतो. अशा वेळी connection तुटल्यास अर्धवट upgraded 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 चाच भाग आहे; तो optional homework नाही.

यानंतर boxes ची संख्या विचारात घ्या. Interim track वरील एक VPS म्हणजे पाच वर्षांत दहा upgrade windows. पाच VPS boxes म्हणजे पन्नास, जोपर्यंत प्रत्येक box disposable नसतो आणि image वरून पुन्हा build केला जात नाही. त्याच कालावधीत LTS track वरील पाच boxes साठी पाच upgrades असतात आणि प्रत्येक upgrade कोणत्या महिन्यात करायचा हे तुम्ही ठरवता.

Ubuntu release वगळता येत का नाही

Upgrade path निश्चित असतात. Interim release पुढील release वर upgrade होते. LTS थेट पुढील LTS वर upgrade होते किंवा तुम्ही तसे सांगितल्यास पुढील interim release वर upgrade होते. कोणतेही upgrade एकावेळी दोन releases पुढे जात नाही. 26.10 वरून 28.04 LTS वर जाण्यासाठी 27.04 आणि 27.10 या releases मधून जावे लागते किंवा मशीन पुन्हा install करावी लागते.

ही यंत्रणा समजून घेणे महत्त्वाचे आहे, कारण त्यामुळे हा नियम बदलणार नाही हे स्पष्ट होते. do-release-upgrade changelogs.ubuntu.com वरून meta-release file आणते आणि त्यानंतर एका विशिष्ट transition साठी तयार केलेले upgrade tool download करते. Canonical प्रत्येक transition स्वतंत्रपणे build आणि test करते. त्यामुळे एखादा release वगळणाऱ्या jump साठी कोणतेही tool किंवा testing उपलब्ध नसते. Upgrader सावधगिरी म्हणून नकार देत नाही. त्याच्याकडे देण्यासाठी आवश्यक साधनच उपलब्ध नसते.

तुम्हाला कोणता release उपलब्ध करून द्यायचा हे config मधील एका ओळीवरून ठरते:

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 प्रमाणेच कार्य करते, कारण दोन्ही settings मध्ये 26.10 नंतरचा पुढील release 27.04 असतो. तपासणी Checking for a new Ubuntu release मुद्रित करते आणि त्यानंतर एकतर New release ... available. ओळ किंवा No new release found. मुद्रित करते.

आणखी एक scheduling नियम अनेकांना अडचणीत आणतो. नवीन LTS release झाल्याच दिवशी LTS ते LTS upgrade उपलब्ध होत नाही. ते पहिल्या point release नंतर खुले होते आणि 26.04.1 हे 27 August 2026 रोजी scheduled आहे. 2026 च्या उन्हाळ्यात Prompt=lts असलेल्या 24.04 मशीनने No new release found. असे उत्तर दिले, तर त्यात बिघाड नव्हता. ती policy नुसार कार्य करत होती. हा path खुला झाल्यावर 24.04 ते 26.04 LTS upgrade हेच नियोजित करून सराव करण्याचे काम आहे.

मध्यंतरातील आवृत्ती निवडणे योग्य ठरण्याची परिस्थिती

खालील चार परिस्थितींमध्ये हा पर्याय खरोखर उपयुक्त ठरतो:

• या मशीनवर, आत्ताच, LTS archive मध्ये उपलब्ध नसलेली kernel किंवा userspace आवृत्ती आवश्यक आहे.
• ही मशीन build host, CI runner किंवा test box आहे आणि ती image मधून पुन्हा तयार केली जाते. त्यामुळे upgrade म्हणजे maintenance window ऐवजी नवीन instance तयार करणे असते.
• LTS स्थिर झाल्यानंतर एखादे hardware किंवा hypervisor feature उपलब्ध झाले आहे आणि त्यासाठी backport उपलब्ध नाही.
• पुढील LTS मध्ये काय समाविष्ट असेल हे तपासायचे आहे. 28.04 ही 26.10, 27.04 आणि 27.10 मधून तयार केली जाते. त्यामुळे महत्त्वाच्या मशीनवर breaking change शोधण्यापेक्षा spare VPS वर तो शोधणे कमी खर्चिक ठरते.

मध्यंतरातील आवृत्ती निवडणाऱ्या बहुतेक लोकांना नवीन distribution नव्हे, तर एकच नवीन package हवे असते. त्यासाठी दोन कमी खर्चिक पर्याय आहेत. 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 ऐवजी फक्त आवश्यक घटक अद्ययावत होतो.

Interim release निवडणे चुकीचे कधी ठरते

• पैसे देणारे वापरकर्ते किंवा on-call rotation असलेली कोणतीही प्रणाली. तुम्ही वर्षातून दोनदा करणे अनिवार्य असलेले upgrade स्वीकारत असता, पण कदाचित कधीही न वापरणाऱ्या package versions साठी.
• तुमच्यासाठी unattended-upgrades security patching करत असलेली कोणतीही प्रणाली. ही automation ज्या security repository मधून packages घेते, त्या repository इतकीच सुरक्षित असते.
• हाताने upgrade करणारा fleet. कारण प्रत्यक्ष खर्च एक maintenance window आणि त्याचा box च्या संख्येने होणारा गुणाकार असतो.
• install केल्यानंतर वर्षभर न पाहिलेली कोणतीही प्रणाली. तुम्ही विसरलेले interim release नऊ महिन्यांनी unpatched 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 मध्ये अशा ओळी लिहित राहते:

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

Fully patched server वर आणि चार महिन्यांपूर्वी ज्याचा release कालबाह्य झाला आहे अशा server वर ही ओळ सारखीच दिसते. कोणी apt errors वाचले नाहीत किंवा end of life date चा मागोवा घेतला नाही, तर तुम्ही कोणत्या server कडे पाहत आहात हे मशीनवरील कोणतीही गोष्ट सांगत नाही.

पहिल्यांदा interim track मध्ये येणाऱ्या बदलांचा प्रकार

March 2026 मध्ये Canonical च्या एका engineer ने Ubuntu discourse वर 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 हे वारंवार security bugs चे स्रोत ठरतात. तसेच storage आणि encryption logic ही initramfs मध्ये असणे योग्य आहे. initramfs ही kernel ने वास्तविक root filesystem 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 मध्ये सर्वप्रथम तुमच्यापर्यंत पोहोचू शकतो. या परिस्थितीतील users साठी त्या thread मध्ये दिलेला सल्ला म्हणजे LTS वर राहणे. हा सल्ला संपूर्ण मुद्दा एका वाक्यात स्पष्ट करतो. बदलांची चाचणी interim releases मध्ये केली जाते. दोन वर्षांच्या interim releases मध्ये कोणत्या गोष्टी बिघडतात हे समोर आल्यानंतर ते बदल LTS मध्ये येतात.

हीच पद्धत प्रत्येक interim release मध्ये लहान स्वरूपातही दिसते. Database, language runtime आणि init configuration यांच्या default versions पुढे सरकतात. त्यामुळे पूर्वी चालणाऱ्या config files काम करणे थांबवू शकतात. Default versions पुढे नेणे हे interim release चे उद्दिष्टच आहे. म्हणून या दहा upgrades पैकी प्रत्येकापूर्वी release notes वाचणे ही तुम्ही स्वीकारलेल्या किंमतीचा भाग आहे.

बॉक्स तयार करताना track निवडा

Install करतानाच track निवडा. नंतर तो बदलण्यासाठी reinstall किंवा 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 मध्ये provider च्या image मध्ये आलेला track नव्हे, तर तुम्ही निवडलेला track दिसला पाहिजे. सध्याच्या LTS वर do-release-upgrade -c चा निकाल No new release found. असा असला पाहिजे. त्याऐवजी interim release उपलब्ध असल्यास, Prompt हे normal वर set आहे. हा पर्याय जाणीवपूर्वक निवडला होता का, हे कोणीतरी ठरवले पाहिजे. pro security-status installed packages पैकी किती packages कोणत्या update stream अंतर्गत येतात हे दाखवते. Machine subscription शी जोडलेली नसल्यास ते स्पष्टपणे सांगते.

त्यानंतर end of life date पुन्हा दिसेल अशा ठिकाणी लिहून ठेवा. त्या server च्या उर्वरित build notes शेजारी ती नोंद ठेवा. हे नवीन VPS वरील पहिल्या दहा मिनिटांमधील इतर कामांसोबतच करा. कारण एखाद्याच्या स्मरणातच असलेली support date कोणाच्याही लक्षात न येता expire होते. सहा महिन्यांनी होणारा बदल पूर्णपणे टाळायचा असल्यास, एखाद्या fleet ला यापैकी कोणत्याही पर्यायाशी बांधील करण्यापूर्वी Linux च्या तुलनेत FreeBSD चे release model यावर एक तास वाचणे उपयुक्त ठरेल.

FAQ

उत्पादन सर्व्हरवर Ubuntu interim release चालवावी का?

जवळजवळ प्रत्येक बाबतीत, नाही. Interim release ला ती release झाल्यानंतर नऊ महिन्यांनी security updates मिळणे थांबते. त्यामुळे production साठी हा track वापरल्यास वर्षातून साधारण दोनदा upgrade window अनिवार्य होते. हे चक्र कायम सुरू राहते. अपवाद म्हणून अशी मशीन येतात ज्या तुम्ही image मधून नियमितपणे पुन्हा तयार करत असता, जसे CI runners आणि build hosts. अशा ठिकाणी upgrade म्हणजे देखभालीची window नसून नवीन instance असतो. या सर्व्हरवर प्रत्यक्ष वापरकर्ते अवलंबून असतील, तर LTS install करा आणि वाचलेल्या maintenance windows इतर कामांसाठी वापरा.

Ubuntu interim release ला किती काळ support मिळतो?

नऊ महिने. 26.10 ही release 15 October 2026 रोजी उपलब्ध होते आणि तिची security maintenance July 2027 मध्ये संपते. 25.10 साठीही याच पद्धतीने July 2026 मध्ये support संपला. प्रत्येक interim release चे हेच वेळापत्रक असते: April किंवा October मध्ये release होते आणि नऊ महिन्यांनी support संपतो. LTS ला standard security maintenance पाच वर्षे मिळते. Ubuntu Pro वापरल्यास हा कालावधी दहा वर्षांपर्यंत वाढतो. August 2026 पर्यंत personal use साठी ते जास्तीत जास्त पाच मशीनवर विनामूल्य आहे.

Upgrade करताना Ubuntu releases वगळता येतात का?

नाही. do-release-upgrade मध्ये एका वेळी एकच release पुढे जाता येते: interim release पुढील release वर जाते आणि LTS थेट पुढील LTS वर जाऊ शकते. 26.10 वरून 28.04 LTS वर जाण्यासाठी आधी 27.04 आणि 27.10 मार्गे upgrade करावे लागते किंवा मशीन पुन्हा install करावी लागते. Canonical प्रत्येक transition स्वतंत्रपणे तयार करून तपासते. Upgrader त्या विशिष्ट jump साठीचे tool download करतो. त्यामुळे दोन release ओलांडणाऱ्या jump साठी tool उपलब्ध नसते आणि असा upgrade पर्याय दिला जात नाही.

माझ्या Ubuntu release चा end of life झाल्यावर काय होते?

तिचे packages old-releases.ubuntu.com वर हलवले जातात. त्यामुळे sudo apt update archive.ubuntu.com विरुद्ध 404 errors देऊ लागते आणि त्या release साठी कोणतेही नवीन security updates प्रकाशित होत नाहीत. मशीनवर याची कोणतीही सूचना दिसत नाही. सर्व्हर सुरू राहतो आणि network traffic serve करत राहतो; मात्र त्यातील नव्याने प्रकाशित झालेली प्रत्येक vulnerability उघडी राहते. Recovery साठी वेळेच्या दबावाखाली release upgrade करावा लागतो किंवा मशीन पुन्हा तयार करावी लागते. त्यामुळे symptoms दिसेपर्यंत थांबण्याऐवजी date तपासत राहा.

नवीन hardware साठी LTS kernel खूप जुना असतो का?

सहसा नाही. LTS मूळ kernel पाच वर्षे तसाच ठेवत नाही. Hardware enablement stack, म्हणजे HWE, point releases दरम्यान नंतरच्या releases मधील kernels LTS मध्ये आणतो. Server install मध्ये linux-generic-hwe-24.04 सारखे package वापरून HWE स्वीकारता येते. Kernel अडथळा आहे असे गृहीत धरण्यापूर्वी uname -r वापरून सध्या कोणता kernel चालू आहे ते तपासा. जर आवश्यक घटक kernel ऐवजी userspace version मध्ये नसेल, तर संपूर्ण मशीन interim track वर हलवण्यापेक्षा container किंवा vendor repository वापरणे हा खूप लहान बदल असतो.