كم تدوم تحديثات 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 نفسه، لذلك لا تحتاج إلى تثبيت plugin أولاً. إذا كنت قادماً من خادم Debian أو Ubuntu، فمعظم الأوامر التي تكتبها يومياً لها مقابل مباشر من apt إلى dnf، وتُعد ترقية الإصدار أدناه من المهام القليلة التي لا تملك مقابلاً حقيقياً. ابدأ من الإصدار الحالي بعد تثبيت جميع التحديثات:

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

أنشئ 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 الذي يفوّت نافذة التحديث؟

لا يحدث شيء في اليوم نفسه. يظهر الفشل في المرة التالية التي تستخدم فيها مدير الحزم. تُنقل الإصدارات المنتهية الصلاحية من شبكة المرايا إلى الأرشيف، لذلك يفشل 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 إلى kernels جديدة خلال دورة الإصدار، لذلك لا تقتصر هذه الفائدة على وقت التثبيت الأول.
• تتحقق من التقنيات التي تتجه إلى RHEL (Red Hat Enterprise Linux). تزوّد Fedora مشروع CentOS Stream، الذي يزوّد RHEL بدوره، لذلك يجري اختبار البرمجيات التي تُبنى وتعمل على Fedora اليوم مقابل منصة المؤسسات بعد عامين تقريباً.
• صُممت الآلة لتكون قصيرة العمر. لا يصل build runner أو جهاز الاختبار الذي يُدمَّر بعد شهرين إلى تاريخ نهاية دعمه. وينطبق المنطق نفسه على الآلات الافتراضية المؤقتة التي تمنحها لوكلاء البرمجة، حيث يُعاد بناء الآلة بوتيرة أعلى بكثير من وتيرة إصدارات Fedora.
• يتولى شخص محدد مسؤولية الترقية. تناسب Fedora خادماً له مالك محدد وموعد مسجل في التقويم. لكنها لا تناسب الخادماً الذي نسيه الجميع.

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

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

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

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

FAQ

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

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

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

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

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

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

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

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