مدة دعم Fedora للخوادم على VPS ومتى ترقي الإصدار

ما مدة حصول إصدار 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 ترقية لنظام التشغيل بالكامل، مقارنةً بـ 2 في Ubuntu LTS. ويمثل رقم Debian، وهو 36 شهراً، مدة دعم الأمان العادية لديه، بينما يمدّد فريق LTS مستقل مدة معظم الإصدارات إلى نحو خمس سنوات.

هذه مدد دعم منشورة، وقد جرى التحقق منها في August 2026، وليست مدة التشغيل المقاسة. يوضّح الفرق بين Ubuntu LTS والإصدارات المرحلية على الخادم سبب اختلاف دورات الإصدار. المهم هنا هو العمل الذي يضيفه كل خيار إلى مسؤولياتك.

ما الذي تتضمنه ترقية إصدار Fedora فعلياً

يُعد DNF 5 مدير الحزم الافتراضي منذ Fedora 41، ويشغّله dnf. الأمر system-upgrade جزء من dnf5 نفسه، لذلك لا تحتاج إلى تثبيت مكوّن إضافي أولاً. ابدأ من الإصدار الحالي بعد تثبيت جميع التحديثات:

sudo dnf upgrade --refresh
sudo reboot

إعادة التشغيل مهمة لأن الترقية تُحلّ وفقاً لما هو مثبّت وقيد التشغيل. لذلك يجعل تحديث غير مكتمل لـkernel أو glibc الخطوة التالية أصعب في التشخيص. جهّز الآن الإصدار الجديد. استبدل 44 بالإصدار الذي تريد الانتقال إليه:

sudo dnf system-upgrade download --releasever=44

يحل هذا الأمر المعاملة كاملة وينزّل كل الحزم، ولا يغيّر شيئاً في النظام قيد التشغيل. توقّع تنزيل بضعة آلاف من الحزم وحجماً يتراوح بين واحد وثلاثة غيغابايت على خادم صغير. إذا تعذّر على 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 الحزم المثبّتة التي لم تعد موجودة في أي مستودع مفعّل. وهنا تجد بقايا مستودع لم ينشر حزم للإصدار الجديد.

أنشئ لقطة للقرص قبل خطوة التنزيل. تُنفَّذ المعاملة بينما لا يمكنك رؤية الشاشة. لذلك، إذا فشلت أثناء الإقلاع دون اتصال، فلن يعود SSH للعمل، وستكون وسيلة الدخول الوحيدة هي وحدة التحكم التي يوفّرها مزود الخدمة، سواء عبر VNC أو serial. تأكد من توفّر وحدة تحكم أو لقطة قبل البدء، وليس بعده.

هناك فحص إضافي يتجاهله بعض المستخدمين:

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 الذي يفوّت المهلة

لا يحدث شيء في اليوم نفسه. يظهر الفشل في المرة التالية التي تستخدم فيها مدير الحزم. تُنقل الإصدارات التي انتهى عمرها إلى الأرشيف بدلاً من شبكة المرايا، لذلك يفشل dnf upgrade أثناء جلب البيانات الوصفية، مع ظهور 404 في عنوان metalink الخاص بإصدارك:

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 جديد.

التحديثات التلقائية تثبّت التصحيحات ضمن الإصدار. ولا تُجري ترقية الإصدار أبداً.

يمكن لـFedora تثبيت تحديثاتها وفق مؤقت:

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 خياراً جيداً عندما تكون الحداثة هي الهدف.

• تحتاج إلى kernel أو userspace أحدث مما توفره أي نسخة LTS: بسبب عتاد حديث، أو حزمة container وsystemd لا يزال أمامها عام قبل إصدار مؤسسي. ينتقل Fedora أيضاً إلى إصدارات kernel الجديدة أثناء دورة الإصدار، لذلك لا تقتصر الفائدة على وقت التثبيت فقط.
• تتحقق مما سيتجه إلى RHEL (Red Hat Enterprise Linux). يزوّد Fedora مشروع CentOS Stream، الذي يزوّد RHEL، لذلك تخضع البرمجيات التي تُبنى وتعمل على Fedora اليوم للاختبار مقابل المنصة المؤسسية بعد عامين تقريباً.
• صُممت الآلة لتكون قصيرة العمر. لا يصل build runner أو جهاز الاختبار الذي يُدمَّر بعد شهرين إلى تاريخ نهاية دعمه. وينطبق المنطق نفسه على الآلات الافتراضية المؤقتة التي تمنحها لوكلاء البرمجة، إذ يُعاد بناء الآلة بوتيرة أعلى بكثير من وتيرة إصدارات Fedora.
• هناك شخص مسؤول عن الترقية. يناسب Fedora خادماً له مسؤول محدد وإدخال في التقويم. لكنه لا يناسب آلة نسيها الجميع.

المسار الأوسط: الحزم الحالية على قاعدة مستقرة

يريد معظم من يختارون Fedora على خادم حزمتين أو ثلاثاً حديثة، لا نظام تشغيل حديثاً بالكامل. ويمكن الفصل بين الأمرين. استخدم إصدار LTS أو إعادة بناء موجهة للمؤسسات كأساس، ثم اجلب البرامج الجديدة حيث تحتاج إليها فعلياً. تمنحك صورة حاوية إصداراً جديداً من التطبيق على مضيف لا تحتاج إلى ترقيته من أجل هذا التطبيق (تشغيل Docker على VPS). أما مستودع المورّد للحزمة الوحيدة التي تهمك، مثل PostgreSQL أو nginx، فيحدّث ذلك المكوّن وحده ويُبقي النظام الأساسي كما هو.

المقايضة واضحة في الاتجاهين. تمنحك الحاوية مساحة مستخدم جديدة على نواة المضيف القديمة، لذلك لن تفيدك عندما تكون النواة هي المكوّن الذي تحتاج إلى تحديثه. ويمنحك مستودع المورّد حزمة جديدة واحدة على قاعدة اختبرها المورّد بدرجة أقل. في الحالتين، تبقى تحديثات أمان النظام الأساسي وفق دورة LTS، وهذه الدورة هي التي تفرض عليك نافذة صيانة كل عام عند استخدام Fedora.

إذا اخترت Fedora لخادم، فضع دورة الترقية في التقويم. عند صدور إصدار، انتظر بضعة أسابيع حتى تلحق به مستودعات المورّدين، ثم أنشئ snapshot، ونفّذ الترقية، وتحقق بعد ذلك من عودة الخدمات إلى العمل. تستغرق هذه العملية نحو ساعة واحدة سنوياً، وهي فعالة. أما الأسلوب الذي يفشل فهو تذكّر الترقية فقط بعد أن يتعطل شيء ما.

FAQ

ما مدة دعم إصدار Fedora؟

حوالي 13 شهراً. تصدر Fedora إصداراً جديداً تقريباً كل ستة أشهر، وتدعم كل إصدار حتى نحو أربعة أسابيع بعد إصدار النسخة التي تليه بإصدارين. صدر Fedora 44 في 28 April 2026، ومن المقرر انتهاء دعمه في June 2027. بعد حلول ذلك التاريخ، يتوقف الإصدار عن تلقي التحديثات الأمنية، وتُنقل حزمُه من المرايا إلى أرشيف Fedora.

هل يمكنني تخطي إصدار من Fedora والترقية بإصدارين دفعة واحدة؟

نعم، ضمن حدود معينة. يقبل dnf system-upgrade download --releasever= إصداراً مستهدفاً يسبق الإصدار الحالي بإصدار واحد أو إصدارين، والقفز بإصدارين دفعة واحدة هو بالضبط ما يلزم للترقية مرة واحدة سنوياً. لا يُعد الانتقال إلى إصدار أبعد مساراً مدعوماً، وكل إصدار إضافي يزيد احتمال أن يؤدي تغيير اسم حزمة أو تنسيق ملف إعداد إلى إيقاف المعاملة. إذا كان الجهاز متأخراً عن عدة إصدارات وانتهى عمرها، فعادةً تكون إعادة بنائه باستخدام image حالية أسرع من تنفيذ سلسلة من الترقيات.

ماذا يحدث إذا بلغ خادم Fedora نهاية عمره؟

يستمر في العمل، لكنه يتوقف عن تلقي التصحيحات. يفشل dnf upgrade التالي مع الخطأ 404 في عنوان metalink الخاص بإصدارك، لأن الإصدارات التي انتهى عمرها تُنقل إلى الأرشيف في dl.fedoraproject.org. يمكنك إعادة توجيه ملفات المستودعات إلى ذلك الأرشيف ثم الترقية على مراحل، أو إعادة بناء الخادم باستخدام إصدار مدعوم. إلى أن تنفذ أحد الخيارين، لن يصل أي تحديث أمني إلى الجهاز، ولن تُثبَّت أي حزمة.

هل تُعد Fedora خياراً سيئاً لخادم إنتاج؟

هي خيار افتراضي سيئ، لكنها خيار معقول عند وجود سبب واضح. تتمثل التكلفة في ترقية نظام التشغيل بالكامل كل عام، إلى أجل غير محدد، على جهاز قد تفضّل عدم تغييره. اختر Fedora عندما تحتاج إلى kernel أو userspace أحدث مما يوفره إصدار LTS، أو عندما يكون الخادم قصير العمر بحكم تصميمه. اختر إصدار LTS أو إعادة بناء مؤسسية عندما تريد تصحيح خادم لسنوات من دون تغيير إصداره.