সার্ভারে Ubuntu LTS নাকি interim release ব্যবহার করবেন

Ubuntu LTS বনাম interim release: সংক্ষিপ্ত উত্তর

কোনো সার্ভারে Ubuntu LTS নাকি interim release ব্যবহার করবেন, তা মূলত একটি সংখ্যার ওপর নির্ভর করে: সেই release কতদিন security update পাবে। একটি LTS পাঁচ বছর standard security maintenance পায়। একটি interim release নয় মাস পায়। এরপর update বন্ধ হয়ে যায়, তাই আপনাকে upgrade করতে হবে অথবা নতুন করে rebuild করতে হবে। যেসব সিস্টেমের ওপর অন্যরা নির্ভর করে, সেগুলোতে LTS ব্যবহার করুন। interim release শুধু এমন জায়গায় ব্যবহার করুন, যেখানে কাউকে জিজ্ঞেস না করেই rebuild করা সম্ভব।

LTS-এর অর্থ long term support। Canonical প্রতি দুই বছরে একবার, জোড়-বছরের April মাসে একটি LTS প্রকাশ করে। মাঝের প্রতি ছয় মাসে একটি 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 কতদিন সমর্থিত থাকে

[
  {
    "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 release-এ 60 মাসের standard security maintenance থাকে। অর্থাৎ পাঁচ বছরে 1টি planned release upgrade করতে হয়। একটি interim release-এ 9 মাসের সমর্থন থাকে। একই পাঁচ বছর interim track-এ থাকলে 10টি release upgrade করতে হয়, কারণ কোনো release বাদ দেওয়া যায় না এবং পাঁচ বছরে মোট দশটি release থাকে।

Ubuntu Pro subscription নিলে LTS-এর সমর্থনকাল 120 মাস, অর্থাৎ দশ বছর হয়। একই সঙ্গে coverage main component থেকে পুরো archive-এ বিস্তৃত হয়। August 2026 পর্যন্ত ব্যক্তিগত ব্যবহারের জন্য সর্বোচ্চ পাঁচটি machine-এ Pro বিনামূল্যে ব্যবহার করা যায়। এটি অধিকাংশ ছোট VPS fleet-এর জন্য যথেষ্ট। interim release-এর জন্য এর কোনো সমতুল্য সুবিধা নেই। সেখানে মোট সমর্থনকাল নয় মাসই, এবং কোনো subscription এই সময়সীমা বাড়ায় না।

একটি বাস্তব সার্ভারে নয় মাসের খরচ

কাজের উদাহরণ হিসেবে 26.10 ধরা যাক। এটি 15 October 2026-এ প্রকাশিত হয় এবং এর security maintenance July 2027-এ শেষ হয়। 25.10-এর ক্ষেত্রেও একই নয় মাসের ধারা ছিল; সেটির maintenance July 2026-এ শেষ হয়েছিল। ক্যালেন্ডার অনুযায়ী দেখলে মনে হয়, প্রতি তিন প্রান্তিকে একটি maintenance window আছে। এই হিসাব ভুল, এবং খরচের দিক থেকে ভুল।

একটি release upgrade চলমান অবস্থায় operating system প্রতিস্থাপন করে। do-release-upgrade apt sources পুনর্লিখে, third party repository নিষ্ক্রিয় করে, প্রায় প্রতিটি install করা package-এর version পরিবর্তন করে, আপনার সম্পাদনা করা config file সম্পর্কে জানতে থামে, এবং শেষে 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 বিচ্ছিন্ন হলে package set আংশিকভাবে upgrade হওয়া অবস্থায় থেকে যেতে পারে। নিজে tmux বা screen-এর ভিতরে চালালে যেকোনো box-এ একই সুরক্ষা পাবেন।

Config file-এর prompt-গুলোর কারণেই পনেরো মিনিটের 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 notes পড়া এই window-এরই অংশ; এটি ঐচ্ছিক অতিরিক্ত কাজ নয়।

এরপর box-এর সংখ্যা দিয়ে হিসাব করুন। একটি VPS interim track-এ রাখলে পাঁচ বছরে দশটি upgrade window লাগে। পাঁচটি VPS box হলে তা পঞ্চাশটি window, যদি না প্রতিটি box বাদ দিয়ে image থেকে নতুন করে তৈরি করা হয়। একই সময়ে পাঁচটি box LTS track-এ রাখলে পাঁচটি upgrade লাগে, এবং প্রতিটির জন্য কোন মাসে upgrade হবে তা আপনি নির্ধারণ করতে পারেন।

Ubuntu release এড়িয়ে আপগ্রেড করা যায় না কেন

আপগ্রেডের পথ নির্দিষ্ট। একটি interim release পরবর্তী release-এ আপগ্রেড হয়, সেটি যে release-ই হোক। একটি LTS সরাসরি পরবর্তী LTS-এ আপগ্রেড হয়, অথবা আপনি অনুরোধ করলে পরবর্তী interim release-এ আপগ্রেড হয়। কোনো release দুই ধাপ একসঙ্গে অতিক্রম করে না। 26.10 থেকে 28.04 LTS-এ যেতে হলে 27.04 এবং 27.10-এর মধ্য দিয়ে যেতে হবে, অথবা মেশিনটি পুনরায় ইনস্টল করতে হবে।

এই প্রক্রিয়াটি জানা দরকার, কারণ এতে বোঝা যায় যে এই নিয়ম বদলাবে না। do-release-upgrade changelogs.ubuntu.com থেকে একটি meta-release file সংগ্রহ করে। এরপর এটি একটি নির্দিষ্ট transition-এর জন্য তৈরি upgrade tool ডাউনলোড করে। Canonical একবারে একটি transition তৈরি ও পরীক্ষা করে। তাই কোনো release এড়িয়ে যাওয়া jump-এর জন্য কোনো tool বা পরীক্ষিত workflow নেই। Upgrader সতর্কতার কারণে আপগ্রেড প্রত্যাখ্যান করছে না। দেওয়ার মতো কোনো upgrade path-ই নেই।

আপনাকে কোন release-এ আপগ্রেডের প্রস্তাব দেওয়া হবে, তা config-এর একটি line থেকে নির্ধারিত হয়:

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

Prompt=lts শুধু পরবর্তী LTS-এর প্রস্তাব দেয়। Prompt=normal পরবর্তী release-এর প্রস্তাব দেয়, সেটি LTS হোক বা না হোক। Prompt=never কোনো প্রস্তাব দেয় না। আপনি পরিকল্পনা না করা কোনো আপগ্রেড যেন কোনো সহকর্মী শুরু না করেন, এভাবে সেটি ঠেকানো যায়। LTS নয় এমন release-এ lts, normal-এর মতোই আচরণ করে, কারণ উভয় setting-এর অধীনেই 26.10-এর পরবর্তী release হলো 27.04। Check কমান্ডটি Checking for a new Ubuntu release মুদ্রণ করে। এরপর হয় New release ... available. line, নয়তো No new release found. মুদ্রণ করে।

আরেকটি scheduling rule অনেককে বিভ্রান্ত করে। নতুন LTS release হওয়ার দিন LTS থেকে LTS আপগ্রেডের প্রস্তাব দেওয়া হয় না। প্রথম point release প্রকাশের পর এই পথ খোলে। 26.04.1-এর নির্ধারিত তারিখ 27 August 2026। 2026 সালের গ্রীষ্মজুড়ে Prompt=lts থাকা একটি 24.04 মেশিনে No new release found. উত্তর পাওয়া গেলে সেটি নষ্ট ছিল না। সেটি policy অনুযায়ী চলছিল। পথটি খোলার পর 24.04 থেকে 26.04 LTS-এ আপগ্রেড চালানোর পরিকল্পনা ও মহড়া করতে হবে।

যখন একটি interim release বেছে নেওয়া সঠিক

চারটি ক্ষেত্রে এটি সত্যিই ভালো সিদ্ধান্ত:

• এই মেশিনে এখনই এমন kernel বা userspace version প্রয়োজন, যা LTS archive-এ নেই।
• মেশিনটি একটি 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 থেকে তৈরি হয়। তাই গুরুত্বপূর্ণ মেশিনে সমস্যা খুঁজে পাওয়ার চেয়ে একটি অতিরিক্ত VPS-এ breaking change খুঁজে পাওয়ার খরচ কম।

Interim release বেছে নেওয়া বেশিরভাগ মানুষের আসলে একটি নতুন distribution নয়, একটি নতুন package প্রয়োজন। এর জন্য কম খরচের দুটি সমাধান আছে। Hardware enablement stack পরবর্তী release-এর kernel 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 version পাওয়া যাবে যা হয়তো কখনো ব্যবহারই করবেন না।
• যেসব box-এ unattended-upgrades আপনার হয়ে security patch প্রয়োগ করছে। এই automation যে security pocket থেকে package সংগ্রহ করে, সেটি যতটা নির্ভরযোগ্য, automation-ও ততটাই নির্ভরযোগ্য।
• এমন fleet, যেটি আপনি হাতে upgrade করেন। কারণ প্রকৃত খরচ হলো একটি maintenance window-এর খরচকে box-এর সংখ্যা দিয়ে গুণ করা।
• এমন কিছু, যা install করার পর এক বছর আর পরীক্ষা করেন না। ভুলে যাওয়া interim release নয় মাস পর unpatched internet-facing server হয়ে যেতে পারে।

শেষের সমস্যাটি নীরবে ঘটে, তাই এটি বিপজ্জনক। কোনো release end of life-এ পৌঁছালে তার package-গুলো old-releases.ubuntu.com-এ সরিয়ে নেওয়া হয়। ফলে sudo apt update archive.ubuntu.com-এর বিরুদ্ধে 404 error দেখিয়ে ব্যর্থ হতে শুরু করে। disk-এ থাকা package list পুরোনো হয়ে যায়। unattended-upgrades তার timer অনুযায়ী চলতে থাকে এবং /var/log/unattended-upgrades/unattended-upgrades.log-এ এই ধরনের line লিখতে থাকে:

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

সম্পূর্ণ patched server এবং চার মাস আগে end of life-এ পৌঁছানো release-যুক্ত server—উভয় ক্ষেত্রেই এই line একই রকম দেখায়। কেউ apt error পড়ে না দেখলে বা end of life date track না করলে, আপনি কোন server দেখছেন তা মেশিনের কোনো তথ্য থেকেই বোঝা যায় না।

পরবর্তী পরিবর্তন যা প্রথমে interim track-এ আসে

March 2026-এ একজন Canonical engineer Ubuntu discourse-এ 26.10-এর জন্য secure boot-এ ব্যবহৃত signed GRUB bootloader থেকে কিছু উপাদান বাদ দেওয়ার প্রস্তাব দেন। এই প্রস্তাবে btrfs, hfsplus, xfs এবং zfs-এর filesystem driver, JPEG ও PNG image parser, Apple partition table, LVM-এ /boot, RAID 1 ছাড়া software RAID এবং LUKS-encrypted /boot বাদ দেওয়া হয়েছে। কারণ হিসেবে বলা হয়েছে, bootloader-এর ভেতরের parser-গুলোতে বারবার security bug দেখা যায়। Storage ও encryption-এর logic initramfs-এ থাকা উচিত। Kernel বাস্তব root filesystem mount করার আগে এই ছোট initial RAM filesystem mount করে। August 2026 পর্যন্ত এটি আলোচনাধীন একটি প্রস্তাব; release করা পরিবর্তন নয়।

বেশিরভাগ VPS instance-এ এতে কোনো পরিবর্তন হবে না। কারণ সেগুলো secure boot ছাড়াই GPT partition table-এর সাধারণ ext4 /boot থেকে boot করে। অনুমান না করে নিজের সিস্টেম পরীক্ষা করুন। আপনার root যদি ZFS হয়, অথবা /boot btrfs-এ বা LUKS-এর ভেতরে থাকে, তাহলে এই ধরনের পরিবর্তনই interim track-এ প্রথমে আপনার সিস্টেমে প্রভাব ফেলতে পারে। এই কারণে আলোচনায় প্রভাবিত ব্যবহারকারীদের জন্য LTS-এ থাকার পরামর্শ দেওয়া হয়েছে। এই পরামর্শেই পুরো যুক্তিটি এক বাক্যে বলা আছে। পরিবর্তন পরীক্ষা করা হয় interim release-এ। দুই বছর ধরে interim release-এ পরীক্ষা করার পর কোন পরিবর্তনে কী ভাঙে তা জানা গেলে সেই পরিবর্তন LTS-এ আসে।

প্রতিটি interim release-এ ছোট পরিসরেও একই ধারা দেখা যায়। Database, language runtime এবং init configuration-এর default version এগিয়ে যায়। ফলে আগে কাজ করা config file আর কাজ নাও করতে পারে। Default version এগিয়ে নেওয়াই interim release-এর উদ্দেশ্য। তাই এই দশটি upgrade-এর প্রতিটির আগে release note পড়া সেই ব্যবহারের খরচের অংশ, যা আপনি গ্রহণ করেছেন।

সার্ভার তৈরি করার সময় track নির্বাচন

ইনস্টলের সময় track নির্বাচন করুন। পরে এটি পরিবর্তন করতে reinstall অথবা ধারাবাহিক upgrade করতে হয়। নতুন সার্ভারে নিচের চারটি command চালালে বর্তমান অবস্থান পরিষ্কার বোঝা যায়:

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

lsb_release -a-এ আপনি যে release ইনস্টল করতে চেয়েছিলেন, সেটির নাম থাকা উচিত। LTS হলে description line-এর শেষে LTS থাকে। Prompt line-এ provider-এর image-এ থাকা track নয়, আপনার নির্বাচিত track-ই দেখানো উচিত। বর্তমান LTS-এ do-release-upgrade -c-এর উত্তর হওয়া উচিত No new release found.। এটি যদি interim release দেখায়, তাহলে Prompt-এ normal সেট করা আছে এবং সেটি ইচ্ছাকৃত কি না, তা নির্ধারণ করা উচিত। pro security-status জানায়, ইনস্টল করা কতগুলো package কোন update stream-এর আওতায় রয়েছে। মেশিনটি কোনো subscription-এর সঙ্গে যুক্ত না থাকলে এটিও স্পষ্টভাবে জানায়।

এরপর end-of-life তারিখটি এমন জায়গায় লিখে রাখুন, যেখানে এটি আবার দেখা যাবে। সার্ভারটির build notes-এর বাকি তথ্যের পাশে তারিখটি রাখুন। এটি নতুন VPS তৈরির প্রথম দশ মিনিটের কাজ-এর অংশ হওয়া উচিত। কারণ কোনো support date শুধু কারও স্মৃতিতে থাকলে সেটিই নজর এড়িয়ে শেষ হয়ে যায়। আপনি যদি ছয় মাস পরপর পরিবর্তনের এই চক্র পুরোপুরি এড়াতে চান, কোনো fleet-কে Linux বা FreeBSD-তে স্থায়ীভাবে নেওয়ার আগে Linux-এর সঙ্গে তুলনা করে FreeBSD release model পড়তে এক ঘণ্টা সময় দেওয়া উপকারী।

FAQ

production server-এ Ubuntu interim release চালানো উচিত কি?

প্রায় সব ক্ষেত্রেই না। কোনো interim release ship হওয়ার 9 মাস পর security update পাওয়া বন্ধ করে। তাই production server-এ এই track ব্যবহার করলে বছরে প্রায় দুবার বাধ্যতামূলক upgrade window তৈরি হয়, এবং এটি চলতেই থাকে। ব্যতিক্রম হিসেবে সেই মেশিনগুলো ধরা যায় যেগুলো আপনি যেকোনোভাবেই image থেকে পুনর্নির্মাণ করেন, যেমন CI runner এবং build host। এসব ক্ষেত্রে upgrade মানে নতুন instance তৈরি করা, maintenance window নয়। যদি প্রকৃত user-রা ওই server-এর ওপর নির্ভর করেন, LTS install করুন এবং সাশ্রয় হওয়া maintenance window অন্য কাজে ব্যবহার করুন।

Ubuntu interim release কতদিন supported থাকে?

9 মাস। 26.10 15 October 2026-এ ship হবে এবং এর security maintenance July 2027-এ শেষ হবে। 25.10-এর ক্ষেত্রেও একইভাবে July 2026-এ support শেষ হয়েছিল। প্রতিটি interim release একই ধারা অনুসরণ করে: April বা October-এ release হয় এবং 9 মাস পরে support শেষ হয়। একটি LTS 5 বছর standard security maintenance পায়। Ubuntu Pro ব্যবহার করলে তা 10 বছর পর্যন্ত বাড়ে। August 2026 অনুযায়ী, personal use-এর জন্য সর্বোচ্চ 5টি মেশিনে এটি বিনামূল্যে।

Upgrade করার সময় Ubuntu release এড়িয়ে যেতে পারি কি?

না। do-release-upgrade এক ধাপ করে এগোয়: একটি interim release পরবর্তী release-এ যায়, আর একটি LTS সরাসরি পরবর্তী LTS-এ যেতে পারে। 26.10 থেকে 28.04 LTS-এ যেতে হলে আগে 27.04 এবং 27.10 হয়ে upgrade চালাতে হবে, অথবা মেশিনটি reinstall করতে হবে। Canonical একবারে একটি transition তৈরি ও পরীক্ষা করে। Upgrader-ও নির্দিষ্ট jump-এর জন্য নির্দিষ্ট tool download করে। তাই দুই ধাপের jump-এর জন্য কোনো tool থাকে না এবং সেই upgrade কখনো offer করা হয় না।

আমার Ubuntu release end of life-এ পৌঁছালে কী হয়?

এর package-গুলো old-releases.ubuntu.com-এ সরিয়ে নেওয়া হয়। ফলে sudo apt update archive.ubuntu.com-এর বিরুদ্ধে 404 error দিয়ে ব্যর্থ হতে শুরু করে, এবং ওই release-এর জন্য আর কোনো নতুন security update প্রকাশিত হয় না। মেশিনে এ বিষয়ে কোনো notification আসে না। Server চলতে থাকে এবং network traffic serve করতে থাকে, কিন্তু এতে পরবর্তীতে প্রকাশিত প্রতিটি vulnerability অমীমাংসিত থাকে। Recovery-এর জন্য সময়ের চাপের মধ্যে release upgrade চালাতে হবে, অথবা মেশিনটি rebuild করতে হবে। তাই symptom দেখার বদলে তারিখটি monitor করুন।

নতুন hardware-এর জন্য LTS kernel কি খুব পুরোনো?

সাধারণত নয়, কারণ একটি LTS 5 বছর ধরে তার original kernel ব্যবহার করে না। Hardware enablement stack, অর্থাৎ HWE, point release-এর সময় পরবর্তী release-গুলোর kernel LTS-এ নিয়ে আসে। Server install-এ linux-generic-hwe-24.04-এর মতো package ব্যবহার করে এতে opt in করা যায়। Kernel-ই বাধা—এমন ধারণা করার আগে uname -r দিয়ে বর্তমানে কোন kernel চলছে তা পরীক্ষা করুন। যদি missing component kernel নয়, userspace version হয়, তাহলে পুরো মেশিনকে interim track-এ নেওয়ার চেয়ে একটি container বা vendor repository ব্যবহার করা অনেক ছোট পরিবর্তন।