سرور کے لیے 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 چلائیں جس پر دوسرے لوگ انحصار کرتے ہوں۔ interim release صرف وہاں چلائیں جہاں rebuild کرنا کسی سے اجازت لیے بغیر ممکن ہو۔

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 ہے، اس لیے اس کی مدت 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 کی شائع کردہ پالیسی کے اعداد و شمار ہیں، کسی test box سے حاصل کردہ پیمائش نہیں۔ ایک LTS کو standard security maintenance کے 60 ماہ ملتے ہیں، یعنی پانچ سال میں 1 منصوبہ بند release upgrade۔ ایک interim release کو 9 ماہ ملتے ہیں۔ انہی پانچ سالوں کے دوران interim track پر رہنے کے لیے 10 release upgrades درکار ہوتے ہیں، کیونکہ آپ کوئی release skip نہیں کر سکتے اور پانچ سالوں میں دس releases شامل ہوتی ہیں۔

Ubuntu Pro subscription سے LTS کی support مدت 120 ماہ، یعنی دس سال، ہو جاتی ہے۔ اس کے علاوہ coverage main component سے بڑھ کر پورے archive تک پہنچ جاتی ہے۔ August 2026 تک Pro ذاتی استعمال کے لیے زیادہ سے زیادہ پانچ machines پر مفت ہے، جو زیادہ تر چھوٹے VPS fleets کے لیے کافی ہے۔ interim release کے لیے اس کے مساوی کوئی option نہیں ہے۔ پوری پیشکش نو ماہ تک محدود ہے، اور کوئی subscription اس مدت میں اضافہ نہیں کرتی۔

حقیقی سرور پر نو ماہ کی لاگت

26.10 کو عملی مثال کے طور پر لیں۔ یہ 15 October 2026 کو جاری ہوتا ہے اور اس کی security maintenance July 2027 میں ختم ہو جاتی ہے۔ یہی نو ماہ والا pattern 25.10 کے لیے بھی تھا، جو July 2026 میں ختم ہوا۔ Calendar کے حساب سے یہ ہر تین quarters میں ایک maintenance window دکھائی دیتی ہے۔ یہ calendar-based interpretation غلط ہے، اور اس کی لاگت زیادہ پڑتی ہے۔

Release upgrade operating system کو اسی جگہ replace کرتا ہے۔ do-release-upgrade apt sources کو دوبارہ لکھتا ہے، third party repositories کو disable کرتا ہے، تقریباً ہر installed package کا version تبدیل کرتا ہے، آپ کی edit کی ہوئی config files کے بارے میں سوال کرتا ہے، اور آخر میں reboot کرتا ہے۔ اسی لیے یہ ایک planned window ہے، background job نہیں۔

اسے ssh کے ذریعے چلانے پر tool آپ کو اپنی 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 پڑھنا window کا حصہ ہے، اختیاری تیاری نہیں۔

اب یہی حساب متعدد boxes کے لیے کریں۔ Interim track پر ایک VPS پانچ سال میں دس upgrade windows لیتا ہے۔ پانچ VPS boxes کے لیے یہ تعداد پچاس ہو جاتی ہے، الا یہ کہ ہر box disposable ہو اور image سے دوبارہ بنایا جائے۔ اسی مدت میں LTS track پر پانچ boxes کے لیے پانچ upgrades ہوتے ہیں، اور آپ ہر upgrade کا مہینہ خود منتخب کرتے ہیں۔

آپ Ubuntu release کو کیوں چھوڑ نہیں سکتے

Upgrade paths مقرر ہیں۔ ایک interim release اگلی release پر upgrade ہوتی ہے، چاہے وہ کوئی بھی ہو۔ ایک LTS براہِ راست اگلی LTS پر upgrade ہوتی ہے، یا اگر آپ ایسا کہیں تو اگلی interim release پر۔ کوئی بھی release ایک ہی بار میں دو مراحل آگے upgrade نہیں ہوتی۔ 26.10 سے 28.04 LTS تک پہنچنے کے لیے 27.04 اور 27.10 سے گزرنا ہوگا، یا machine کو دوبارہ install کرنا ہوگا۔

یہ mechanism سمجھنا مفید ہے، کیونکہ اس سے واضح ہوتا ہے کہ یہ قاعدہ تبدیل نہیں ہوگا۔ do-release-upgrade، changelogs.ubuntu.com سے meta-release file حاصل کرتا ہے، پھر ایک ایسی upgrade tool download کرتا ہے جو ایک مخصوص transition کے لیے بنائی گئی ہو۔ Canonical ایک وقت میں ایک ہی transition بناتا اور test کرتا ہے، اس لیے ایسی چھلانگ کے لیے جو ایک release چھوڑ دے، نہ کوئی tool موجود ہوتا ہے اور نہ testing۔ Upgrader احتیاط کی وجہ سے انکار نہیں کرتا۔ اس کے پاس پیش کرنے کے لیے کچھ موجود ہی نہیں ہوتا۔

آپ کو کون سی release پیش کی جائے گی، یہ configuration کی ایک سطر سے متعین ہوتا ہے:

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

Prompt=lts صرف اگلی LTS پیش کرتا ہے۔ Prompt=normal اگلی release پیش کرتا ہے، خواہ وہ LTS ہو یا نہ ہو۔ Prompt=never کچھ بھی پیش نہیں کرتا۔ اس طرح آپ کسی نیک نیت ساتھی کو ایسی upgrade شروع کرنے سے روک سکتے ہیں جس کی آپ نے منصوبہ بندی نہیں کی۔ ایسی release پر جو LTS نہ ہو، lts بالکل normal کی طرح کام کرتا ہے، کیونکہ 26.10 کے بعد اگلی release دونوں settings میں 27.04 ہی ہے۔ یہ check Checking for a new Ubuntu release دکھاتا ہے، اور اس کے بعد یا تو New release ... available. سطر یا No new release found.

ایک اور scheduling rule بھی لوگوں کو مشکل میں ڈالتا ہے۔ LTS سے LTS upgrade نئی LTS کے جاری ہونے والے دن پیش نہیں کی جاتی۔ یہ پہلی 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 وہ run ہے جس کی منصوبہ بندی اور rehearsal کرنی چاہیے۔

جب interim release کا انتخاب درست ہو

یہ چار صورتیں ہیں جن میں یہ واقعی بہتر ثابت ہوتی ہے:

• آپ کو اسی machine پر، ابھی، ایسا kernel یا userspace version درکار ہے جو LTS archive میں موجود نہیں۔
• یہ machine 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 تلاش کرنے کی لاگت اس machine پر تلاش کرنے سے کم ہوتی ہے جو اہم ہے۔

زیادہ تر لوگ 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 کا انتخاب غلط ہو

• وہ تمام سسٹمز جن کے users ادائیگی کرتے ہوں یا جن کے لیے on-call rotation موجود ہو۔ آپ package versions کے بدلے سال میں دو مرتبہ لازمی upgrade قبول کریں گے، حالانکہ ممکن ہے آپ کو ان versions کی کبھی ضرورت ہی نہ پڑے۔
• وہ تمام سسٹمز جہاں unattended-upgrades آپ کی security patching خود کر رہا ہو۔ یہ automation صرف اتنی ہی قابلِ اعتماد ہوتی ہے جتنا security pocket وہ استعمال کرتی ہے۔
• وہ fleet جسے آپ دستی طور پر upgrade کرتے ہوں، کیونکہ اصل لاگت ایک maintenance window کو systems کی تعداد سے ضرب دینے سے بنتی ہے۔
• کوئی بھی ایسا سسٹم جسے install کرنے کے بعد آپ ایک سال تک نہ دیکھیں۔ جس interim release کو آپ بھول گئے ہوں، وہ 9 ماہ بعد unpatched internet-facing server بن جاتا ہے۔

آخری خرابی خاموشی سے پیدا ہوتی ہے، اور یہی اسے خطرناک بناتی ہے۔ جب کسی release کی end of life ہو جاتی ہے تو اس کے packages old-releases.ubuntu.com میں منتقل ہو جاتے ہیں۔ اس لیے sudo apt update، archive.ubuntu.com کے خلاف 404 errors کے ساتھ fail ہونا شروع ہو جاتا ہے۔ 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

یہ line مکمل طور پر patched server اور ایسے server، دونوں پر یکساں نظر آتی ہے جس کی release 4 ماہ پہلے ختم ہو چکی ہو۔ جب تک کوئی apt errors نہ پڑھے یا end of life date کو track نہ کرے، machine پر موجود کوئی چیز یہ نہیں بتاتی کہ آپ ان دونوں میں سے کس server کو دیکھ رہے ہیں۔

وہ تبدیلی جسے پہلے interim track میں شامل کیا جاتا ہے

March 2026 میں Canonical کے ایک انجینئر نے 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 ایک چھوٹا ابتدائی RAM filesystem ہے جسے kernel اصل root filesystem سے پہلے mount کرتا ہے۔ August 2026 تک یہ زیرِ بحث تجویز ہے، جاری کی گئی تبدیلی نہیں۔

زیادہ تر VPS instances میں اس سے کچھ نہیں بدلے گا، کیونکہ وہ secure boot کے بغیر GPT partition table پر موجود سادہ ext4 /boot سے boot ہوتے ہیں۔ مفروضہ قائم کرنے کے بجائے اپنے سسٹم کی جانچ کریں۔ اگر آپ کا root ZFS ہے، یا /boot btrfs پر موجود ہے یا LUKS کے اندر ہے، تو یہ بالکل اسی قسم کی تبدیلی ہے جو interim track میں آپ تک پہلے پہنچ سکتی ہے۔ متاثرہ صارفین کے لیے thread میں بھی یہی مشورہ دیا گیا ہے کہ LTS پر رہیں۔ یہی مشورہ ایک جملے میں پوری دلیل بیان کرتا ہے۔ interim releases وہ جگہ ہیں جہاں تبدیلیاں آزمائی جاتی ہیں۔ LTS وہ جگہ ہے جہاں یہ تبدیلیاں interim releases کے دو سال میں ان کے پیدا کردہ مسائل سامنے آنے کے بعد پہنچتی ہیں۔

یہی pattern ہر interim release میں چھوٹی سطح پر بھی نظر آتا ہے۔ database، language runtime اور init configuration کے default versions آگے بڑھتے ہیں، اس لیے جو config files پہلے کام کرتی تھیں وہ کام کرنا بند کر سکتی ہیں۔ defaults کو آگے بڑھانا interim release کا بنیادی مقصد ہے۔ اس لیے ان دس upgrades میں سے ہر ایک سے پہلے release notes پڑھنا اس قیمت کا حصہ ہے جسے آپ نے قبول کیا تھا۔

سرور تیار کرتے وقت track کا انتخاب

track کا انتخاب installation کے وقت کریں، کیونکہ بعد میں اسے تبدیل کرنے کے لیے 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 میں اسی release کا نام ہونا چاہیے جسے آپ نے install کرنے کا ارادہ کیا تھا، اور LTS پر description line کا اختتام LTS پر ہونا چاہیے۔ Prompt line میں آپ کا منتخب کردہ track دکھائی دینا چاہیے، نہ کہ وہ track جو provider کی image میں اتفاقاً شامل تھا۔ موجودہ LTS پر do-release-upgrade -c کا جواب No new release found. ہونا چاہیے۔ اگر اس کے بجائے یہ interim release پیش کرے تو Prompt کو normal پر set کیا گیا ہے، اور کسی کو فیصلہ کرنا چاہیے کہ یہ جان بوجھ کر کیا گیا تھا یا نہیں۔ pro security-status بتاتا ہے کہ installed packages میں سے کتنے کس update stream کے تحت آتے ہیں، اور اگر machine کسی subscription سے منسلک نہ ہو تو یہ بات واضح طور پر بتاتا ہے۔

اس کے بعد end of life date ایسی جگہ لکھیں جہاں آپ اسے دوبارہ دیکھ سکیں، یعنی اس server کے build notes میں باقی معلومات کے ساتھ۔ یہ کام نئے VPS کے پہلے دس منٹ کے دیگر کاموں کے ساتھ شامل ہونا چاہیے، کیونکہ جو support date صرف کسی کی یادداشت میں ہو، وہی عموماً خاموشی سے expire ہو جاتی ہے۔ اگر آپ مکمل طور پر چھ ماہ بعد ہونے والی تبدیلیوں سے بچنا چاہتے ہیں تو کسی fleet کو Linux یا FreeBSD میں سے کسی ایک کے لیے commit کرنے سے پہلے Linux کے مقابلے میں FreeBSD کا release model پڑھنے کے لیے ایک گھنٹہ نکالنا مفید ہوگا۔

FAQ

کیا production server پر Ubuntu interim release چلانی چاہیے؟

تقریباً ہر صورت میں نہیں۔ Interim release کو release ہونے کے 9 ماہ بعد security updates ملنا بند ہو جاتے ہیں۔ اس track پر production چلانے کا مطلب ہے کہ تقریباً ہر 6 ماہ بعد لازمی upgrade window رکھنی ہوگی، اور یہ سلسلہ مسلسل جاری رہے گا۔ مستثنیٰ صورتیں عموماً وہ machines ہیں جنہیں ویسے بھی image سے rebuild کیا جاتا ہے، جیسے CI runners اور build hosts۔ ان کے لیے upgrade کسی window کے بجائے نیا instance بنانے کے مترادف ہوتا ہے۔ اگر حقیقی users اس server پر depend کرتے ہیں تو LTS install کریں اور بچنے والی upgrade windows کسی دوسرے کام کے لیے استعمال کریں۔

Ubuntu interim release کو کتنے عرصے تک support کیا جاتا ہے؟

9 ماہ تک۔ 26.10، 15 October 2026 کو release ہوگی اور اس کی security maintenance July 2027 میں ختم ہو جائے گی۔ یہی schedule 25.10 کے لیے بھی تھا، جس کی maintenance July 2026 میں ختم ہوئی۔ ہر interim release اسی pattern کی پیروی کرتی ہے: April یا October میں release ہوتی ہے اور 9 ماہ بعد support ختم ہو جاتا ہے۔ LTS کو standard security maintenance کے 5 سال ملتے ہیں۔ Ubuntu Pro کے ساتھ یہ مدت 10 سال تک بڑھ جاتی ہے۔ August 2026 تک Ubuntu Pro ذاتی استعمال کے لیے زیادہ سے زیادہ 5 machines پر مفت ہے۔

کیا upgrade کرتے وقت Ubuntu releases چھوڑ سکتے ہیں؟

نہیں۔ do-release-upgrade میں ایک وقت میں صرف ایک release آگے بڑھائی جاتی ہے۔ Interim release اگلی release پر upgrade ہوتی ہے، جبکہ LTS اگلی LTS پر براہِ راست upgrade ہو سکتی ہے۔ 26.10 سے 28.04 LTS تک پہنچنے کے لیے پہلے 27.04 اور 27.10 کے ذریعے upgrade چلانا ہوگا، یا machine کو دوبارہ install کرنا ہوگا۔ Canonical ہر transition کو الگ بناتا اور test کرتا ہے۔ Upgrader اسی مخصوص jump کے لیے tool download کرتا ہے۔ اس لیے two-step jump کے لیے کوئی tool موجود نہیں ہوتا اور وہ کبھی offer نہیں کیا جاتا۔

Ubuntu release کے end of life تک پہنچنے پر کیا ہوتا ہے؟

اس کے packages old-releases.ubuntu.com پر منتقل ہو جاتے ہیں۔ اس کے بعد sudo apt update، archive.ubuntu.com کے خلاف 404 errors کے ساتھ fail ہونا شروع ہو جاتا ہے، اور اس release کے لیے کوئی نئی security updates شائع نہیں کی جاتیں۔ Machine پر کوئی notification اس صورتِ حال کا اعلان نہیں کرتی۔ Server چلتا رہتا ہے اور network traffic serve کرتا رہتا ہے، جبکہ اس میں دریافت ہونے والی ہر نئی vulnerability غیر محفوظ رہتی ہے۔ Recovery کے لیے وقت کے دباؤ میں release upgrade چلانا یا machine کو rebuild کرنا پڑتا ہے۔ اس لیے symptoms کے بجائے date monitor کریں۔

کیا نئی hardware کے لیے LTS kernel بہت پرانا ہوتا ہے؟

عام طور پر نہیں، کیونکہ LTS پانچ سال تک اپنا original kernel برقرار نہیں رکھتا۔ Hardware Enablement stack، یعنی HWE، بعد کی releases کے kernels کو point releases کے ذریعے LTS میں لاتا ہے۔ Server installation میں `linux-generic-hwe-24.04 جیسے package کے ذریعے HWE opt in کیا جا سکتا ہے۔ یہ فرض کرنے سے پہلے کہ رکاوٹ kernel ہے، uname -r` سے معلوم کریں کہ آپ کون سا kernel چلا رہے ہیں۔ اگر missing component kernel کے بجائے userspace version ہے تو پورے machine کو interim track پر منتقل کرنے کے مقابلے میں container یا vendor repository استعمال کرنا کہیں چھوٹی تبدیلی ہے۔