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

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

انتخاب بین یک نسخه Ubuntu LTS و یک نسخه interim برای سرور، تنها به یک عدد بستگی دارد: مدت زمانی که آن نسخه به‌روزرسانی‌های امنیتی دریافت می‌کند. یک نسخه LTS پنج سال پشتیبانی امنیتی استاندارد دریافت می‌کند. یک نسخه interim تنها 9 ماه پشتیبانی دارد و پس از آن به‌روزرسانی‌ها متوقف می‌شوند، بنابراین باید سیستم را ارتقا دهید یا دوباره نصب کنید. روی هر سیستمی که دیگران به آن وابسته‌اند، از 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 ?

نگه داشتن فایل خودتان به این معنی است که تغییرات پیش‌فرض جدید را از دست می‌دهید. پذیرش فایل نگهدارنده بسته به این معنی است که تنظیمات امنیتی شما تا زمانی که دوباره آن‌ها را اعمال نکنید، از بین می‌روند. هیچ‌کدام از این پاسخ‌ها بدون دانستن تغییرات آن نسخه ایمن نیستند؛ به همین دلیل است که خواندن یادداشت‌های انتشار (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 برنامه‌ریزی شده است. یک سیستم 24.04 با Prompt=lts که در طول تابستان 2026 پاسخ No new release found. را می‌داد، خراب نبود. این سیستم از سیاست پیروی می‌کرد. هنگامی که مسیر باز شود، ارتقا از 24.04 به 26.04 LTS همان فرآیندی است که باید برای آن برنامه‌ریزی و تمرین کنید.

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

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

• شما به نسخه‌ای از kernel یا userspace نیاز دارید که در آرشیو LTS موجود نیست و باید همین حالا روی این سیستم نصب شود.
• دستگاه مورد نظر یک build host، یک CI runner یا یک سیستم تست است که آن را از روی یک image بازسازی می‌کنید؛ بنابراین ارتقا به معنای ایجاد یک instance جدید است، نه یک بازه زمانی برای نگهداری (maintenance window).
• قابلیتی در سخت‌افزار یا 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 که فراموشش کرده‌اید، نه ماه بعد به یک سرور وصله‌نشده تبدیل می‌شود که رو به اینترنت است.

این شکست آخر بی‌سروصدا رخ می‌دهد و همین موضوع آن را خطرناک می‌کند. وقتی یک انتشار به پایان عمر (end of life) خود می‌رسد، بسته‌های آن به 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 را نخواند یا تاریخ پایان عمر انتشار را پیگیری نکند، هیچ چیزی روی دستگاه به شما نمی‌گوید که با کدام وضعیت روبرو هستید.

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

در مارس 2026، یکی از مهندسان Canonical در انجمن Ubuntu پیشنهاد داد که بوت‌لودر GRUB امضاشده که برای secure boot در نسخه 26.10 عرضه می‌شود، محدودتر شود. این پیشنهاد درایورهای فایل‌سیستم برای btrfs، hfsplus، xfs و zfs، پارسرهای تصاویر JPEG و PNG، جداول پارتیشن Apple، /boot روی LVM، نرم‌افزار RAID به جز RAID 1، و /boot رمزنگاری‌شده با LUKS را حذف می‌کند. دلیل اعلام‌شده این است که پارسرها در داخل بوت‌لودر منبع تکرارشونده باگ‌های امنیتی هستند و منطق ذخیره‌سازی و رمزنگاری باید در 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 برای آن وجود دارد، و این یعنی خواندن یادداشت‌های انتشار پیش از هر یک از آن ده ارتقا، بخشی از بهایی است که پذیرفته‌اید بپردازید.

انتخاب مسیر (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 باید با مسیری که انتخاب کرده‌اید مطابقت داشته باشد، نه با آنچه که ایمیج ارائه‌دهنده به‌صورت پیش‌فرض ارائه داده است. دستور 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ها و hostهای build، که در آن‌ها ارتقا به معنای ایجاد یک 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 است.