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

مدت زمان دریافت به‌روزرسانی‌های امنیتی برای نسخه‌های 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 ماه پشتیبانی ارائه می‌دهد. ستون دوم را به عنوان هزینه زمانی در نظر بگیرید. در طول 10 سال، Fedora تقریباً به 10 بار ارتقای کل سیستم‌عامل نیاز دارد، در حالی که این عدد برای Ubuntu LTS برابر با 2 است. عدد 36 ماه برای Debian مربوط به پشتیبانی امنیتی استاندارد آن است و یک تیم مجزای LTS، پشتیبانی اکثر نسخه‌ها را تا حدود 5 سال افزایش می‌دهد.

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

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

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

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 جدید انجام می‌دهید.

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

Fedora می‌تواند به‌روزرسانی‌های خود را بر اساس یک زمان‌بندی (timer) نصب کند:

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 است. در Ubuntu، به‌روزرسانی‌های امنیتی خودکار یک سیستم را در تمام بازهٔ پنج‌ساله بدون تغییر نسخه هدایت می‌کنند و خودِ تغییر نسخه، یک کار برنامه‌ریزی‌شده مانند ارتقای 24.04 به 26.04 است که هر چند سال یک‌بار انجام می‌شود.

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

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

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

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

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

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

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