ارتقای نسخه Fedora در سرور VPS و چرخه عمر 13 ماهه

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

یک سرور Fedora تا زمانی که از آن استفاده می‌کنید، تقریباً هر یک سال یک‌بار نیاز به ارتقای نسخه دارد. Fedora تقریباً هر شش ماه یک نسخه جدید منتشر می‌کند. هر نسخه تا حدود چهار هفته پس از انتشار نسخه دومِ بعد از خود پشتیبانی می‌شود که این بازه زمانی به حدود 13 ماه به‌روزرسانی می‌رسد. پس از آن تاریخ، هیچ‌گونه اصلاحیه امنیتی برای آن نسخه ارائه نمی‌شود. سیستم همچنان به کار خود ادامه می‌دهد، اما مجموعه‌ای از بسته‌ها را اجرا می‌کند که دیگر توسط هیچ‌کس وصله نمی‌شوند.

تاریخ‌ها این موضوع را شفاف‌تر می‌کنند. تا اوت 2026، نسخه‌های پشتیبانی‌شده Fedora 43 و Fedora 44 هستند. Fedora 44 در تاریخ 28 آوریل 2026 منتشر شد و پایان عمر آن برای ژوئن 2027 برنامه‌ریزی شده است. Fedora 42 در آوریل 2025 منتشر شد و در مه 2026، یعنی چهار هفته پس از عرضه Fedora 44، به پایان عمر خود رسید. بنابراین، سروری که با ایمیج Fedora 42 ساخته شده بود، سیزده ماه بعد بدون اینکه خطایی از سوی کاربر رخ داده باشد، از چرخه پشتیبانی خارج شد.

مقایسه Fedora با نسخه‌های LTS بر حسب ماه

LTS به معنای پشتیبانی بلندمدت است: نسخه‌ای که فروشنده به جای چند ماه، برای چندین سال آن را به‌روزرسانی می‌کند. EOL به معنای پایان عمر محصول است، یعنی تاریخی که انتشار وصله‌ها متوقف می‌شود. در اینجا آنچه هر پروژه برای نسخه‌ای که امروز نصب می‌کنید منتشر کرده است، آمده است.

[
  {
    "distro": "Fedora 44",
    "support_window": 13,
    "upgrades_per_decade": 10
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "support_window": 60,
    "upgrades_per_decade": 2
  },
  {
    "distro": "Debian 13 stable",
    "support_window": 36,
    "upgrades_per_decade": 3
  },
  {
    "distro": "AlmaLinux 10",
    "support_window": 120,
    "upgrades_per_decade": 1
  }
]

Fedora برای هر نسخه 13 ماه پشتیبانی ارائه می‌دهد. یک نسخه Ubuntu LTS دارای 60 ماه و یک توزیع بازسازی‌شدهٔ سازمانی مانند AlmaLinux دارای 120 ماه پشتیبانی است. ستون دوم را به عنوان هزینهٔ نگهداری در نظر بگیرید. در طول ده سال، Fedora تقریباً به 10 بار ارتقای کل سیستم‌عامل نیاز دارد، در حالی که این عدد برای Ubuntu LTS برابر با 2 است. عدد 36 ماه برای Debian مربوط به پشتیبانی امنیتی استاندارد آن است و یک تیم LTS مجزا، پشتیبانی اکثر نسخه‌ها را تا حدود پنج سال افزایش می‌دهد.

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

ارتقای نسخه Fedora دقیقاً شامل چه مواردی است

از زمان Fedora 41، ابزار DNF 5 مدیر بسته پیش‌فرض است و dnf آن را اجرا می‌کند. دستور system-upgrade بخشی از خود dnf5 است، بنابراین نیازی به نصب هیچ افزونه‌ای از قبل نیست. کار را از نسخه فعلی و با اعمال کامل وصله‌ها شروع کنید:

sudo dnf upgrade --refresh
sudo reboot

راه‌اندازی مجدد (reboot) اهمیت دارد، زیرا ارتقا بر اساس آنچه نصب شده و در حال اجراست صورت می‌گیرد؛ بنابراین یک به‌روزرسانی ناقص kernel یا glibc، تحلیل مرحله بعدی را دشوار می‌کند. اکنون نسخه جدید را آماده‌سازی (stage) کنید. عدد 44 را با نسخه‌ای که قصد ارتقا به آن را دارید جایگزین کنید:

sudo dnf system-upgrade download --releasever=44

این دستور کل تراکنش را حل کرده و تمام بسته‌ها را دانلود می‌کند، بدون اینکه تغییری در سیستم در حال اجرا ایجاد شود. انتظار دانلود چند هزار بسته و حجمی بین 1 تا 3 گیگابایت را در یک سرور کوچک داشته باشید. اگر dnf نتواند تراکنش را حل کند، در همین مرحله متوقف شده و بسته‌ای که باعث مسدود شدن شده است را اعلام می‌کند. این حالت مطلوب است، زیرا خطا زمانی رخ می‌دهد که ماشین هنوز بالا است و شما همچنان به shell دسترسی دارید.

سپس آن را اجرا کنید:

sudo dnf offline status
sudo dnf system-upgrade reboot

دستور dnf offline status تأیید می‌کند که یک تراکنش آماده و در انتظار است. دستور dnf system-upgrade reboot ماشین را برای یک تراکنش آفلاین راه‌اندازی مجدد می‌کند: یک بوت حداقلی که در آن تراکنش RPM به تنهایی اجرا می‌شود. دلیل این کار این است که جایگزینی glibc و systemd در زیرمجموعه سرویس‌های در حال اجرا، باعث ایجاد یک سیستم نیمه‌نصب‌شده می‌شود. سرور شما در طول کل تراکنش غیرقابل دسترس است (معمولاً چند دقیقه در یک VPS کوچک)، سپس دوباره به نسخه جدید بوت می‌شود. برای دو بار راه‌اندازی مجدد و بازه‌ای که SSH پاسخگو نیست، برنامه‌ریزی کنید.

وقتی سیستم بالا آمد:

cat /etc/fedora-release
sudo dnf system-upgrade log --number=-1
sudo dnf distro-sync
sudo dnf repoquery --extras

دستور /etc/fedora-release باید خروجی مشابه Fedora release 44 (Forty Four) چاپ کند. زیردستور log لاگ تراکنش را از آن بوت آفلاین چاپ می‌کند که تنها سابقه اتفاقات رخ‌داده در زمانی است که shell نداشتید. دستور distro-sync هر آنچه را که باقی مانده به نسخه‌های جدید ارتقا می‌دهد. دستور repoquery --extras بسته‌های نصب‌شده‌ای را فهرست می‌کند که دیگر در هیچ مخزن (repository) فعالی وجود ندارند؛ این همان جایی است که می‌توانید بقایای مخزنی را پیدا کنید که هرگز برای نسخه جدید منتشر نشده است.

پیش از مرحله دانلود، از دیسک snapshot بگیرید. تراکنش زمانی اجرا می‌شود که شما به صفحه نمایش دسترسی ندارید، بنابراین اگر در طول بوت آفلاین با شکست مواجه شود، SSH بازنمی‌گردد و تنها راه دسترسی شما، کنسولی است که ارائه‌دهنده در اختیارتان می‌گذارد (VNC یا سریال). پیش از شروع، نه بعد از آن، از داشتن کنسول یا snapshot مطمئن شوید.

یک بررسی دیگر که معمولاً نادیده گرفته می‌شود:

sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'

هنگامی که یک بسته فایل پیکربندی پیش‌فرض جدیدی ارائه می‌دهد و شما فایل قدیمی را ویرایش کرده‌اید، RPM فایل شما را بازنویسی نمی‌کند. نسخه بسته‌بندی‌شده را با پسوند .rpmnew در کنار آن ذخیره می‌کند. بنابراین sshd یا nginx شما دقیقاً مانند نسخه قبلی عمل می‌کند، در حالی که تنظیمات پیش‌فرض جدید بدون استفاده روی دیسک باقی می‌مانند. پس از هر ارتقا، این فایل‌ها را مطالعه کنید. نصب rpmconf و اجرای sudo rpmconf -a به شما کمک می‌کند تا آن‌ها را یکی‌یکی بررسی کرده و تفاوت‌ها را مشاهده کنید.

مخازن شخص ثالث عامل اصلی شکست در ارتقا هستند

بسته‌های خودِ Fedora همگی در روز انتشار نسخه جدید به‌روزرسانی می‌شوند. هر چیزی که خارج از Fedora باشد، طبق زمان‌بندی شخص دیگری تغییر می‌کند. اکثر مخازن فروشندگان از $releasever در URL خود استفاده می‌کنند، بنابراین لحظه‌ای که ارتقا را انجام می‌دهید، dnf شروع به درخواست مسیری می‌کند که ممکن است هنوز وجود نداشته باشد.

لیست مخازن فعلی خود را مشاهده کنید:

sudo dnf repo list --enabled
grep -R -e baseurl -e metalink /etc/yum.repos.d/

برای هر مخزنی که متعلق به Fedora نیست، پیش از هر اقدامی، آن را با نسخه مقصد تست کنید:

sudo dnf --releasever=44 --repo=docker-ce-stable makecache

اگر فروشنده نسخه مربوطه را منتشر کرده باشد، dnf متادیتا را دانلود کرده و بدون خطا خارج می‌شود. در غیر این صورت، با خطای 404 برای مسیری مانند https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml مواجه می‌شوید و همین شکست باعث توقف system-upgrade download در مراحل بعدی خواهد شد. در هفته‌های نخست پس از انتشار نسخه جدید Fedora، این رایج‌ترین دلیل برای شروع نشدن فرآیند ارتقا است.

شما دو راه دارید. چند هفته صبر کنید تا فروشنده نسخه جدید را منتشر کند، که معمولاً تصمیم درست همین است. یا اینکه بدون آن مخزن ارتقا را انجام دهید:

sudo dnf system-upgrade download --releasever=44 --disable-repo=docker-ce-stable

غیرفعال کردن یک مخزن، بسته‌های آن را حذف نمی‌کند. آن‌ها نصب‌شده و بدون مدیریت باقی می‌مانند و اگر مانع تراکنش شوند، dnf این موضوع را اعلام می‌کند. افزودن --allowerasing به dnf اجازه می‌دهد برای رفع تداخل، بسته‌های نصب‌شده را حذف کند؛ بنابراین پیش از تأیید، لیست حذف را به‌دقت بخوانید. همان لیستی که ممکن است باعث حذف ناخواسته یک سرور دیتابیس شود که قصد حفظ آن را داشته‌اید.

اگر سرور Fedora از بازه زمانی پشتیبانی عبور کند چه اتفاقی می‌افتد

در همان روز اتفاق خاصی رخ نمی‌دهد. مشکل زمانی بروز می‌کند که برای بار بعدی با مدیر بسته (package manager) کار کنید. نسخه‌هایی که به پایان عمر (End of life) خود رسیده‌اند از شبکه mirror به بخش آرشیو منتقل می‌شوند؛ بنابراین dnf upgrade هنگام دریافت متادیتا با خطا مواجه شده و برای URL متالینک نسخه شما، خطای 404 برمی‌گرداند:

Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-42&arch=x86_64

ماشین همچنان به سرویس‌دهی ترافیک ادامه می‌دهد و همین موضوع باعث می‌شود این وضعیت بی‌سروصدا و خطرناک باشد. سرور دیگر هیچ به‌روزرسانی امنیتی دریافت نمی‌کند. همچنین امکان نصب هیچ بسته‌ای وجود ندارد؛ بنابراین در روزی که یک هشدار امنیتی برای OpenSSH یا nginx منتشر شود، هیچ روش پشتیبانی‌شده‌ای برای وصله کردن آن نخواهید داشت.

خروج از این وضعیت ممکن است اما زمان‌بر خواهد بود. می‌توانید مخازن را به آرشیو Fedora در https://dl.fedoraproject.org/pub/archive/fedora/linux/ تغییر مسیر دهید و از آنجا ارتقا را انجام دهید. Fedora انتظار دارد که ارتقا هر بار یک یا دو نسخه انجام شود؛ بنابراین سروری که چهار نسخه عقب است، به چندین مرحله ارتقای متوالی نیاز دارد که هر کدام احتمال شکست دارند و هر مرحله نیز در حالت بوت آفلاین و بدون نظارت انجام می‌شود. در یک VPS، بازسازی سرور روی یک ایمیج جدید و انتقال داده‌ها معمولاً کوتاه‌تر و ایمن‌تر است و همان کاری است که در ده دقیقه اول روی یک VPS جدید انجام می‌دهید.

به‌روزرسانی‌های خودکار یک نسخه را وصله می‌کنند. آن‌ها هرگز آن را ارتقا نمی‌دهند.

فدورا می‌تواند به‌روزرسانی‌های خود را طبق یک زمان‌بندی نصب کند:

sudo dnf install -y dnf5-plugin-automatic
sudo systemctl enable --now dnf5-automatic.timer

تنظیمات در /etc/dnf/automatic.conf قرار دارند که مقادیر پیش‌فرض ارائه‌شده در /usr/share/dnf5/dnf5-plugins/automatic.conf را بازنویسی می‌کند. apply_updates به‌صورت پیش‌فرض غیرفعال است، بنابراین در حالت اولیه، این زمان‌بند فقط به‌روزرسانی‌ها را دانلود می‌کند و هیچ‌چیزی را نصب نمی‌کند. upgrade_type بین default و security یکی را انتخاب می‌کند. reboot مقادیر never، when-changed یا when-needed را می‌پذیرد.

این کار شما را در محدودهٔ یک نسخه به‌روز نگه می‌دارد. این فرآیند هرگز Fedora 43 را به Fedora 44 منتقل نمی‌کند، زیرا ارتقای نسخه یک عملیات جداگانه و آگاهانه است که با راه‌اندازی مجدد سیستم در یک تراکنش آفلاین انجام می‌شود. این تفاوت عملی در مقایسه با توزیع‌های LTS است. در اوبونتو، به‌روزرسانی‌های امنیتی خودکار یک سیستم را در تمام بازهٔ پنج‌ساله بدون هیچ تغییر نسخه‌ای هدایت می‌کنند و خودِ تغییر نسخه، یک کار برنامه‌ریزی‌شده مانند ارتقای 24.04 به 26.04 است که هر چند سال یک‌بار انجام می‌شود.

چه زمانی Fedora گزینه مناسبی برای سرور است

Fedora زمانی انتخاب مناسبی است که به‌روز بودن اولویت اصلی باشد.

• شما به kernel یا userspace جدیدتری نسبت به آنچه در نسخه‌های LTS ارائه می‌شود نیاز دارید: سخت‌افزار جدید، یا پشته‌ای از container و systemd که هنوز تا رسیدن به نسخه enterprise یک سال فاصله دارد. Fedora همچنین در طول چرخه حیات یک نسخه، به kernelهای جدیدتر upstream مهاجرت می‌کند؛ بنابراین این فقط یک مزیت لحظه‌ای در زمان نصب نیست.
• شما در حال اعتبارسنجی چیزی هستید که قرار است به RHEL (Red Hat Enterprise Linux) راه یابد. Fedora تغذیه‌کننده CentOS Stream است و آن نیز به نوبه خود RHEL را تغذیه می‌کند؛ بنابراین نرم‌افزاری که امروز روی Fedora ساخته و اجرا می‌شود، در حال تست شدن برای پلتفرم enterprise چند سال آینده است.
• ماشین مورد نظر طبق طراحی، عمر کوتاهی دارد. یک build runner یا یک محیط تست که قرار است پس از 2 ماه حذف شود، هرگز با تاریخ پایان پشتیبانی (EOL) مواجه نخواهد شد. همین منطق در مورد ماشین‌های مجازی یک‌بارمصرف که به عامل‌های برنامه‌نویسی می‌دهید نیز صدق می‌کند، جایی که ماشین بسیار زودتر از انتشار نسخه‌های جدید Fedora بازسازی می‌شود.
• شخصی مسئولیت ارتقا را بر عهده دارد. Fedora برای سروری که مالک مشخص و برنامه زمانی برای نگهداری دارد، مناسب است. این سیستم‌عامل برای ماشینی که همه آن را فراموش کرده‌اند، گزینه ضعیفی است.

مسیر میانه: بسته‌های به‌روز روی یک پایه پایدار

بیشتر کسانی که Fedora را برای سرور می‌خواهند، به دو یا سه بسته به‌روز نیاز دارند، نه یک سیستم‌عامل کاملاً جدید. این دو موضوع از هم جدا هستند. از یک توزیع LTS یا یک نسخه بازسازی‌شده سازمانی (enterprise rebuild) به عنوان پایه استفاده کنید و سپس نرم‌افزارهای جدید را فقط در جایی که واقعاً نیاز دارید، فراخوانی کنید. یک image کانتینر، نسخه جدید برنامه را روی میزبانی در اختیار شما قرار می‌دهد که برای آن هرگز نیازی به ارتقای کل سیستم ندارید (اجرای Docker روی یک VPS). یک مخزن (repository) رسمی از سمت سازنده برای همان یک بسته‌ای که برایتان مهم است، مثلاً PostgreSQL یا nginx، فقط همان مورد را ارتقا می‌دهد و پایه سیستم را دست‌نخورده باقی می‌گذارد.

این معامله در هر دو جهت منصفانه است. کانتینر یک فضای کاربری (userspace) جدید روی هسته قدیمی میزبان به شما می‌دهد، بنابراین اگر نیاز اصلی شما به هسته جدید باشد، کمکی نمی‌کند. مخزن سازنده نیز یک بسته جدید روی پایه‌ای به شما می‌دهد که سازنده آن را کمتر تست کرده است. هر دو روش، به‌روزرسانی‌های امنیتی سیستم پایه را روی چرخه LTS نگه می‌دارند؛ همان چرخه‌ای که در Fedora باعث می‌شود هر سال یک بازه زمانی برای نگهداری (maintenance window) صرف کنید.

اگر Fedora را برای سرور انتخاب کردید، چرخه آن را در تقویم خود علامت بزنید. وقتی نسخه جدیدی منتشر (ship) می‌شود، چند هفته صبر کنید تا مخازن سازندگان با آن هماهنگ شوند، سپس snapshot بگیرید، ارتقا دهید و در نهایت بررسی کنید که سرویس‌ها دوباره بالا آمده‌اند. این روال حدود یک ساعت در سال زمان می‌برد و به‌خوبی کار می‌کند. نسخه‌ای که در آن شکست می‌خورید، همان نسخه‌ای است که ارتقای آن را تنها زمانی به یاد می‌آورید که چیزی از قبل خراب شده باشد.

FAQ

مدت زمان پشتیبانی از هر نسخه Fedora چقدر است؟

حدود 13 ماه. Fedora تقریباً هر شش ماه یک نسخه جدید منتشر می‌کند و از هر نسخه تا حدود چهار هفته پس از انتشار نسخه دومِ بعد از آن، پشتیبانی می‌کند. نسخه Fedora 44 در تاریخ 28 April 2026 منتشر شد و پایان عمر آن برای June 2027 برنامه‌ریزی شده است. پس از گذشت این تاریخ، انتشار به‌روزرسانی‌های امنیتی برای آن نسخه متوقف شده و بسته‌های آن از روی سرورهای mirror به آرشیو Fedora منتقل می‌شوند.

آیا می‌توانم یک نسخه از Fedora را نادیده بگیرم و مستقیماً دو نسخه ارتقا دهم؟

بله، با رعایت محدودیت‌ها. ابزار dnf system-upgrade download --releasever= از ارتقا به یک یا دو نسخه جلوتر پشتیبانی می‌کند و جهش دو نسخه‌ای دقیقاً همان روشی است که برای چرخه ارتقای سالانه استفاده می‌شود. ارتقای بیش از دو نسخه، مسیر پشتیبانی‌شده‌ای نیست و با هر نسخه اضافه، احتمال بروز مشکل در تراکنش به دلیل تغییر نام بسته‌ها یا تغییر فرمت فایل‌های پیکربندی افزایش می‌یابد. اگر سیستم از چندین نسخه عقب‌تر است و از پایان عمر آن گذشته، نصب مجدد با استفاده از یک ایمیج جدید معمولاً سریع‌تر از انجام زنجیره‌ای از ارتقاها است.

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

سرور به کار خود ادامه می‌دهد اما دیگر وصله (patch) نمی‌شود. دستور dnf upgrade بعدی به دلیل دریافت خطای 404 از URL متالینک مربوط به نسخه شما با شکست مواجه می‌شود، زیرا نسخه‌های پایان‌یافته به آرشیو در dl.fedoraproject.org منتقل شده‌اند. شما می‌توانید فایل‌های مخزن (repository) را به آن آرشیو تغییر مسیر دهید و به‌صورت مرحله‌به‌مرحله ارتقا دهید، یا سرور را با یک نسخه پشتیبانی‌شده بازسازی کنید. تا زمانی که یکی از این دو کار را انجام ندهید، هیچ به‌روزرسانی امنیتی به ماشین نمی‌رسد و هیچ بسته‌ای نصب نخواهد شد.

آیا Fedora انتخاب بدی برای یک سرور عملیاتی (production) است؟

این انتخاب به عنوان یک گزینه پیش‌فرض مناسب نیست، اما با داشتن دلیل موجه، انتخابی منطقی است. هزینه آن، انجام یک ارتقای کامل سیستم‌عامل در هر سال و به‌طور مداوم روی ماشینی است که شاید ترجیح دهید به آن دست نزنید. زمانی Fedora را انتخاب کنید که به کرنل یا فضای کاربری (userspace) جدیدتر از آنچه در نسخه‌های LTS ارائه می‌شود نیاز دارید، یا زمانی که سرور طبق طراحی، عمر کوتاهی دارد. اگر می‌خواهید سروری را برای سال‌ها بدون تغییر نسخه اصلی وصله کنید، یک توزیع LTS یا نسخه‌های بازسازی‌شده سازمانی (enterprise rebuild) را انتخاب کنید.