تفاوت Ubuntu LTS و نسخه interim برای سرور

تفاوت Ubuntu LTS و نسخه‌های interim: پاسخ کوتاه

انتخاب بین یک نسخه Ubuntu LTS و یک نسخه interim برای سرور، به یک عدد بستگی دارد: مدت زمانی که آن نسخه به‌روزرسانی‌های امنیتی دریافت می‌کند. یک نسخه LTS پنج سال پشتیبانی امنیتی استاندارد دریافت می‌کند. یک نسخه interim نه ماه پشتیبانی دارد و پس از آن به‌روزرسانی‌ها متوقف می‌شوند، بنابراین باید سیستم را ارتقا دهید یا دوباره بسازید. روی هر سیستمی که دیگران به آن وابسته‌اند، از LTS استفاده کنید. نسخه interim را تنها در جایی اجرا کنید که بازسازی سیستم بدون نیاز به هماهنگی با دیگران امکان‌پذیر باشد.

عبارت LTS به معنای پشتیبانی بلندمدت (Long Term Support) است. Canonical هر دو سال یک‌بار، در ماه آوریل سال‌های زوج، یک نسخه LTS و در فواصل بین آن‌ها هر شش ماه یک‌بار، یک نسخه interim منتشر می‌کند. نسخه 26.04 LTS در تاریخ 23 آوریل 2026 عرضه شد و پشتیبانی امنیتی استاندارد آن تا سال 2031 ادامه دارد. نسخه 26.10 برای تاریخ 15 اکتبر 2026 برنامه‌ریزی شده است و چون یک نسخه interim است، عمر پشتیبانی آن در ژوئیه 2027 به پایان می‌رسد.

مدت زمان پشتیبانی از هر نسخه Ubuntu

[
  {
    "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
  }
]

این ارقام، سیاست‌های رسمی منتشرشده توسط Canonical تا اوت 2026 هستند و نه نتایج حاصل از آزمایش‌های موردی. یک نسخه LTS دارای 60 ماه پشتیبانی امنیتی استاندارد است که در طول پنج سال، معادل 1 ارتقای برنامه‌ریزی‌شده نسخه خواهد بود. یک نسخه interim دارای 9 ماه پشتیبانی است. ماندن در مسیر نسخه‌های interim برای همان بازه پنج‌ساله، مستلزم 10 ارتقای نسخه است، زیرا نمی‌توانید یک نسخه را نادیده بگیرید و در پنج سال، ده نسخه منتشر می‌شود.

اشتراک Ubuntu Pro رقم مربوط به نسخه‌های LTS را به 120 ماه (ده سال) افزایش می‌دهد و دامنه پوشش را از بخش main به کل آرشیو گسترش می‌دهد. تا اوت 2026، سرویس Pro برای استفاده شخصی تا سقف پنج دستگاه رایگان است که اکثر ناوگان‌های کوچک VPS را پوشش می‌دهد. هیچ معادل مشابهی برای نسخه‌های interim وجود ندارد. نه ماه، کل مدت زمان ارائه است و هیچ اشتراکی آن را تمدید نمی‌کند.

هزینه واقعی نه ماه پشتیبانی روی یک سرور عملیاتی

نسخه 26.10 را به عنوان نمونه در نظر بگیرید. این نسخه در 15 اکتبر 2026 منتشر می‌شود و پشتیبانی امنیتی آن در ژوئیه 2027 به پایان می‌رسد؛ همان الگوی نه ماهه‌ای که برای نسخه 25.10 در ژوئیه 2026 تکرار شد. اگر این بازه را در تقویم نگاه کنید، به نظر می‌رسد که هر سه فصل یک‌بار نیاز به نگهداری دارید. این برداشت از تقویم اشتباه است و این اشتباه در جهت پرهزینه‌تر شدن محاسبات شماست.

ارتقای نسخه، سیستم‌عامل را در محل جایگزین می‌کند. do-release-upgrade منابع apt را بازنویسی می‌کند، مخازن شخص ثالث را غیرفعال می‌سازد، نسخه تقریباً تمام بسته‌های نصب‌شده را تغییر می‌دهد، برای پرسش درباره فایل‌های پیکربندی که ویرایش کرده‌اید متوقف می‌شود و در پایان، سیستم را reboot می‌کند. به همین دلیل است که این کار یک پنجره برنامه‌ریزی‌شده است و نه یک وظیفه پس‌زمینه.

آن را از طریق 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 ?

نگه داشتن فایل خودتان به این معنی است که تغییرات پیش‌فرض جدید را از دست می‌دهید. پذیرش فایل نگهدارنده بسته (maintainer) به این معنی است که تنظیمات امنیتی شما تا زمانی که دوباره آن‌ها را اعمال نکنید، از بین می‌رود. هیچ‌کدام از این پاسخ‌ها بدون دانستن تغییرات آن نسخه ایمن نیستند؛ به همین دلیل است که خواندن یادداشت‌های انتشار (release notes) بخشی از زمان پنجره نگهداری است و نه یک تکلیف اختیاری.

سپس این تعداد را در تعداد سرورها ضرب کنید. یک VPS در مسیر interim، ده پنجره ارتقا در پنج سال است. پنج سرور VPS یعنی پنجاه پنجره ارتقا، مگر اینکه هر سرور یکبارمصرف باشد و از روی یک image بازسازی شود. پنج سرور در مسیر LTS یعنی پنج ارتقا در همان دوره زمانی، و شما می‌توانید ماهی که هر کدام در آن ارتقا می‌یابند را انتخاب کنید.

چرا نمی‌توانید یک نسخه از Ubuntu را نادیده بگیرید

مسیرهای ارتقا ثابت هستند. هر نسخه میان‌دوره‌ای (interim) به نسخه بعدی، هر چه که باشد، ارتقا می‌یابد. یک نسخه LTS مستقیماً به نسخه LTS بعدی یا در صورت درخواست شما، به نسخه میان‌دوره‌ای بعدی ارتقا پیدا می‌کند. هیچ چیزی دو مرحله را همزمان ارتقا نمی‌دهد. رسیدن از 26.10 به 28.04 LTS به معنای عبور از 27.04 و 27.10 یا نصب مجدد سیستم‌عامل است.

دانستن این مکانیزم ارزشمند است، زیرا به شما می‌گوید که این قانون تغییرناپذیر است. do-release-upgrade یک فایل meta-release را از changelogs.ubuntu.com دریافت می‌کند و سپس ابزار ارتقایی را دانلود می‌کند که برای یک انتقال خاص ساخته شده است. Canonical هر بار یک انتقال را می‌سازد و تست می‌کند، بنابراین پرشی که یک نسخه را نادیده بگیرد، هیچ ابزار و تست پشتیبانی ندارد. ابزار ارتقا به دلیل احتیاط امتناع نمی‌کند؛ بلکه هیچ بسته‌ای برای ارائه در آن مسیر وجود ندارد.

اینکه چه نسخه‌ای به شما پیشنهاد می‌شود، از یک خط پیکربندی تعیین می‌شود:

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

Prompt=lts فقط نسخه LTS بعدی را پیشنهاد می‌دهد. Prompt=normal نسخه بعدی، چه LTS باشد و چه نباشد، را پیشنهاد می‌دهد. Prompt=never هیچ چیزی پیشنهاد نمی‌دهد؛ این روشی است که مانع از آن می‌شوید که یک همکار خوش‌نیت، ارتقایی را که برنامه‌ریزی نکرده‌اید، شروع کند. در نسخه‌ای که LTS نیست، lts دقیقاً مانند normal عمل می‌کند، زیرا نسخه بعدی پس از 26.10 در هر دو تنظیمات، 27.04 است. این بررسی، Checking for a new Ubuntu release و سپس یک خط New release ... available. یا No new release found. را چاپ می‌کند.

یک قانون زمان‌بندی دیگر نیز وجود دارد که کاربران را غافلگیر می‌کند. ارتقای LTS به LTS در روز انتشار نسخه جدید LTS پیشنهاد نمی‌شود. این قابلیت با اولین نسخه point release فعال می‌شود و 26.04.1 برای 27 اوت 2026 برنامه‌ریزی شده است. یک point release نسخه جدیدی از Ubuntu نیست، بلکه همان نسخه با چهار ماه اصلاحات انباشته‌شده در رسانه‌های نصب جدید است. این انتظار وجود دارد تا مسیر ارتقا پیش از آنکه به کسی پیشنهاد شود، آن چهار ماه تست را پشت سر بگذارد. یک سیستم 24.04 با Prompt=lts که در طول تابستان 2026 پاسخ No new release found. را می‌داد، خراب نبود؛ بلکه داشت از سیاست‌های تعیین‌شده پیروی می‌کرد. هنگامی که مسیر باز شود، ارتقای 24.04 به 26.04 LTS همان فرآیندی است که باید برای آن برنامه‌ریزی و تمرین کنید.

چه زمانی استفاده از نسخه interim انتخاب درستی است

چهار موردی که در آن‌ها این انتخاب واقعاً برتری دارد:

• شما به نسخه‌ای از kernel یا userspace نیاز دارید که در مخزن LTS موجود نیست و باید همین حالا روی این سیستم در دسترس باشد.
• دستگاه مورد نظر یک build host، یک CI runner یا یک سیستم تست است که آن را از روی یک image بازسازی می‌کنید؛ بنابراین ارتقا به معنای ایجاد یک instance جدید است، نه صرف زمان برای نگهداری.
• قابلیت‌های سخت‌افزاری یا hypervisor پس از freeze شدن نسخه LTS معرفی شده‌اند و هیچ backport برای آن‌ها وجود ندارد.
• شما در حال بررسی محتوای نسخه LTS بعدی هستید. نسخه 28.04 از ترکیب 26.10، 27.04 و 27.10 ساخته می‌شود و شناسایی یک breaking change روی یک VPS یدکی، هزینه بسیار کمتری نسبت به مواجهه با آن روی سرور اصلی دارد.

بیشتر کسانی که به سراغ نسخه interim می‌روند، فقط یک بسته نرم‌افزاری جدیدتر می‌خواهند، نه یک توزیع جدیدتر. دو راهکار ارزان‌تر برای این کار وجود دارد. Hardware enablement stack، کرنل‌های نسخه‌های جدیدتر را به LTS می‌آورد: در 24.04 این مورد sudo apt install linux-generic-hwe-24.04 است و با هر point release، از دومین نسخه به بعد، به‌روزرسانی می‌شود. برای یک برنامه واحد، استفاده از یک container image یا مخزن اختصاصی خودِ سازنده، تنها یک بخش را تغییر می‌دهد و نیازی به تغییر کل سیستم‌عامل نیست.

چه زمانی نسخه interim انتخاب اشتباهی است

• هر سرویسی که کاربر پرداختی دارد یا دارای چرخه on-call است. شما در ازای دریافت نسخه‌هایی از بسته‌ها که ممکن است هرگز از آن‌ها استفاده نکنید، عملاً پذیرفته‌اید که دو بار در سال ارتقای اجباری انجام دهید.
• هر سروری که در آن unattended-upgrades وظیفه اعمال وصله‌های امنیتی را بر عهده دارد. این اتوماسیون تنها به اندازه مخزن امنیتی که از آن تغذیه می‌کند، کارآمد است.
• مجموعه‌ای از سرورها که به‌صورت دستی ارتقا می‌دهید؛ زیرا هزینه واقعی، زمان صرف‌شده برای یک سرور ضرب‌در تعداد کل سرورهاست.
• هر چیزی که نصب می‌کنید و تا یک سال به آن سر نمی‌زنید. یک نسخه interim که فراموشش کرده‌اید، نه ماه بعد به یک سرور وصله‌نشده تبدیل می‌شود که در معرض اینترنت قرار دارد.

این شکست آخر بی‌سروصدا رخ می‌دهد و همین موضوع آن را خطرناک می‌کند. وقتی عمر یک نسخه به پایان می‌رسد، بسته‌های آن به old-releases.ubuntu.com منتقل می‌شوند، بنابراین sudo apt update در برقراری ارتباط با archive.ubuntu.com دچار خطای 404 می‌شود. لیست بسته‌های موجود روی دیسک قدیمی می‌شود. unattended-upgrades طبق زمان‌بندی خود به اجرا ادامه می‌دهد و خطوطی مانند این را در /var/log/unattended-upgrades/unattended-upgrades.log می‌نویسد:

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

این خط در یک سرور کاملاً وصله‌شده و سروری که عمر نسخه‌اش چهار ماه پیش به پایان رسیده، دقیقاً یکسان خوانده می‌شود. مگر اینکه کسی خطاهای apt را بخواند یا تاریخ پایان عمر (end of life) را پیگیری کند، هیچ چیزی در سیستم به شما نمی‌گوید که با کدام وضعیت روبرو هستید.

نوع تغییری که ابتدا در مسیر interim اعمال می‌شود

در مارس 2026، یکی از مهندسان Canonical در انجمن Ubuntu پیشنهاد داد که bootloader امضاشده GRUB که برای secure boot در نسخه 26.10 عرضه می‌شود، محدودتر شود. این پیشنهاد درایورهای فایل‌سیستم برای btrfs، hfsplus، xfs و zfs، تجزیه‌کننده‌های تصاویر JPEG و PNG، جداول پارتیشن Apple، /boot روی LVM، نرم‌افزار RAID به جز RAID 1، و /boot رمزنگاری‌شده با LUKS را حذف می‌کند. دلیل ذکر شده این است که تجزیه‌کننده‌ها در داخل bootloader منبع مکرر باگ‌های امنیتی هستند و منطق ذخیره‌سازی و رمزنگاری باید در initramfs قرار گیرد؛ همان فایل‌سیستم کوچک RAM که هسته پیش از mount کردن root اصلی، آن را بارگذاری می‌کند. تا اوت 2026، این موضوع صرفاً یک پیشنهاد در حال بحث است و هنوز به عنوان یک تغییر نهایی عرضه نشده است.

برای اکثر نمونه‌های VPS، این تغییر هیچ تأثیری نخواهد داشت، زیرا آن‌ها بدون secure boot و از روی یک /boot ساده با فرمت ext4 روی جدول پارتیشن GPT بوت می‌شوند. به جای فرض کردن، وضعیت سیستم خود را بررسی کنید. اگر root شما ZFS است، یا /boot روی btrfs یا داخل LUKS قرار دارد، این دقیقاً همان کلاسی از تغییرات است که ابتدا در مسیر interim با آن مواجه می‌شوید. توصیه خودِ این بحث به کاربران تحت تأثیر، ماندن روی نسخه LTS است. این توصیه، کل استدلال را در یک جمله خلاصه می‌کند. نسخه‌های interim جایی هستند که تغییرات در آن‌ها آزمایش می‌شوند. نسخه LTS جایی است که تغییرات پس از دو سال بررسی در نسخه‌های interim و شناسایی خرابی‌های احتمالی، به آن می‌رسند.

همین الگو به روش‌های کوچک‌تر در هر نسخه interim دیده می‌شود. نسخه‌های پیش‌فرض پایگاه داده، runtime زبان‌ها و پیکربندی init به‌روزرسانی می‌شوند، بنابراین فایل‌های پیکربندی که قبلاً کار می‌کردند ممکن است از کار بیفتند. پیش بردن تنظیمات پیش‌فرض، وظیفه‌ای است که نسخه‌های interim برای آن وجود دارند؛ این یعنی مطالعه یادداشت‌های انتشار (release notes) پیش از هر یک از آن ده ارتقا، بخشی از هزینه‌ای است که پذیرفته‌اید بپردازید.

انتخاب مسیر (track) هنگام ساخت سرور

مسیر (track) را در زمان نصب انتخاب کنید، زیرا تغییر آن پس از نصب مستلزم نصب مجدد یا زنجیره‌ای از ارتقاها است. روی یک سرور جدید، چهار دستور وضعیت فعلی شما را مشخص می‌کنند:

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 باید با مسیری که انتخاب کرده‌اید مطابقت داشته باشد، نه با آنچه که به صورت پیش‌فرض در image ارائه‌دهنده وجود داشته است. دستور do-release-upgrade -c در یک نسخه LTS فعلی باید No new release found. را پاسخ دهد. اگر به جای آن یک نسخه interim پیشنهاد شد، Prompt روی normal تنظیم شده است و باید مشخص شود که آیا این تصمیم آگاهانه بوده است یا خیر. دستور pro security-status گزارش می‌دهد که چه تعداد از بسته‌های نصب‌شده تحت پوشش کدام جریان به‌روزرسانی هستند و به‌صراحت اعلام می‌کند که دستگاه به هیچ اشتراکی متصل نیست.

سپس تاریخ پایان پشتیبانی (end of life) را در جایی یادداشت کنید که دوباره آن را ببینید؛ این کار را در کنار سایر یادداشت‌های ساخت آن سرور انجام دهید. این مورد باید در کنار سایر کارهای مربوط به ده دقیقه اول روی یک VPS جدید قرار گیرد، زیرا تاریخی که فقط در حافظه افراد باقی بماند، همان تاریخی است که بدون اطلاع منقضی می‌شود. اگر تغییرات شش‌ماهه همان چیزی است که می‌خواهید کاملاً از آن دوری کنید، مقایسه مدل انتشار FreeBSD با لینوکس ارزش یک ساعت مطالعه را پیش از متعهد کردن یک ناوگان سرور به هر یک از این دو سیستم‌عامل دارد.

FAQ

آیا باید از نسخه‌های interim اوبونتو روی سرور عملیاتی (production) استفاده کنم؟

در تقریباً تمام موارد، خیر. یک نسخه interim نه ماه پس از انتشار، دیگر به‌روزرسانی‌های امنیتی دریافت نمی‌کند؛ بنابراین استفاده از آن در محیط عملیاتی به معنای داشتن یک بازه زمانی اجباری برای ارتقا در هر سال است که تا ابد ادامه خواهد داشت. تنها استثناهای منطقی، ماشین‌هایی هستند که به‌هرحال از روی یک image بازسازی می‌شوند، مانند CI runnerها و build hostها؛ جایی که ارتقا به معنای ایجاد یک instance جدید است، نه یک بازه زمانی نگهداری. اگر کاربران واقعی به آن سرور وابسته هستند، نسخه LTS را نصب کنید و زمان ذخیره‌شده را صرف کارهای دیگر کنید.

پشتیبانی نسخه‌های interim اوبونتو چقدر است؟

نه ماه. نسخه 26.10 در تاریخ 15 اکتبر 2026 منتشر می‌شود و پشتیبانی امنیتی آن در ژوئیه 2027 به پایان می‌رسد؛ این همان الگویی است که نسخه 25.10 را در ژوئیه 2026 به پایان رساند. هر نسخه interim از همین روال پیروی می‌کند: انتشار در آوریل یا اکتبر و پایان نه ماه بعد. یک نسخه LTS پنج سال پشتیبانی امنیتی استاندارد دریافت می‌کند که با Ubuntu Pro تا ده سال قابل تمدید است؛ سرویسی که از اوت 2026 برای استفاده شخصی تا سقف پنج ماشین رایگان است.

آیا می‌توانم هنگام ارتقا، نسخه‌های اوبونتو را نادیده بگیرم؟

خیر. do-release-upgrade ارتقا را گام‌به‌گام انجام می‌دهد: یک نسخه interim به نسخه بعدی می‌رود و یک نسخه LTS می‌تواند مستقیماً به LTS بعدی ارتقا یابد. رسیدن از 26.10 به 28.04 LTS به معنای اجرای ارتقا از طریق 27.04 و 27.10 است، یا اینکه باید ماشین را دوباره نصب کنید. Canonical هر انتقال را به‌صورت تک‌مرحله‌ای می‌سازد و تست می‌کند و ابزار ارتقا، ابزاری مخصوص همان جهش خاص را دانلود می‌کند؛ بنابراین برای جهش‌های دو مرحله‌ای ابزاری وجود ندارد و چنین امکانی هرگز ارائه نمی‌شود.

وقتی نسخه اوبونتو به پایان عمر خود می‌رسد چه اتفاقی می‌افتد؟

پکیج‌های آن به old-releases.ubuntu.com منتقل می‌شوند، بنابراین sudo apt update هنگام اتصال به archive.ubuntu.com با خطاهای 404 مواجه می‌شود و دیگر هیچ به‌روزرسانی امنیتی جدیدی برای آن نسخه منتشر نخواهد شد. هیچ هشداری در سیستم این موضوع را اعلام نمی‌کند. سرور به کار خود ادامه می‌دهد و ترافیک را پردازش می‌کند، در حالی که تمام آسیب‌پذیری‌های جدید منتشرشده در آن باز می‌مانند. بازیابی سیستم در این حالت نیازمند اجرای ارتقای نسخه تحت فشار زمانی یا بازسازی کامل است، پس به‌جای مشاهده علائم خرابی، تاریخ پایان پشتیبانی را زیر نظر داشته باشید.

آیا هسته (kernel) نسخه LTS برای سخت‌افزارهای جدید بیش از حد قدیمی است؟

معمولاً خیر، زیرا یک نسخه LTS هسته اولیه خود را برای پنج سال حفظ نمی‌کند. پشته فعال‌سازی سخت‌افزار یا HWE، هسته‌های نسخه‌های جدیدتر را در point releaseها به LTS می‌آورد و یک نصب سرور می‌تواند با پکیجی مانند linux-generic-hwe-24.04 آن را فعال کند. پیش از آنکه فرض کنید هسته مانع کار است، با uname -r بررسی کنید که چه نسخه‌ای در حال اجراست. اگر بخش گمشده، نسخه‌ای از فضای کاربری (userspace) است و نه هسته، استفاده از یک container یا مخزن (repository) سازنده، تغییر بسیار کوچک‌تری نسبت به انتقال کل ماشین به مسیر نسخه‌های interim است.