ما الذي ينتهي في مايو-يونيو 2027
صدر Ubuntu 22.04 LTS في أبريل 2022. وتنتهي صيانته الأمنية القياسية في مايو 2027 بحسب صفحة ubuntu.com/about/release-cycle، بينما يذكر endoflife.date تاريخ 1 يونيو 2027 للمحطة نفسها. اكتبوا «مايو-يونيو 2027» في خططكم، واستهدفوا بداية النافذة لا آخر يوم فيها.
بعد هذا التاريخ، لا يصلكم إصلاح الثغرة التي تصدره Canonical، إلا باشتراك Ubuntu Pro الذي يمدّد الصيانة الأمنية حتى عام 2032 (الشهر الدقيق يختلف بين المصدرين: أبريل عند endoflife.date ومايو عند ubuntu.com، ولذلك نذكر السنة وحدها). وكلفة الترحيل الحقيقية ليست الترخيص بل الوقت: نافذة تدخل، ونسخة تجريبية مستنسخة، وتحقق من كل موقع على حدة.
وفي مجموعة من الخوادم يُقرأ الموعد في ثلاثة أعمدة: كم خادمًا ما زال على 22.04، وأيها يحمل cPanel، وأيها مجرد VPS للتطبيقات. ولكل عمود إجراؤه. وجدول نهايات الدعم الكامل لعام 2027 موجود في جدول نهايات الدعم 2027، وهنا نتناول هذا السطر وحده.
ما يتيحه لكم هذا الدليل
- تحديد الموعد بدقة — مايو 2027 عند Canonical و1 يونيو 2027 عند
endoflife.date: يُخطَّط قبل بداية النافذة. - القرار عميلًا بعد عميل — ترقية في المكان أو ELevate أو خادم جديد، بمعايير قابلة للقياس لا بالعادة.
- معرفة ما تفرضه cPanel — إهمال في الإصدار 132 وسحب في الإصدار 136، ولماذا لا يُشغَّل
do-release-upgradeيدويًا على خادم cPanel. - شبكة أمان حقيقية — صورة للخادم سبقت استعادتها مرة، لا وعد بنسخة احتياطية.
- توقّع ما ينكسر — المستودعات الخارجية المعطّلة وPHP وnginx وSSH والحزم المحذوفة أثناء الترقية.
- الاحتفاظ بطريق عودة — نقطة اللاعودة مسمّاة واستعادة مخططة قبل الضغط على Enter.
cPanel & WHM: النظام 22.04 مُهمَل في 132 ومسحوب في 136
تُدرج صفحة «deprecation plan» في وثائق cPanel نظام Ubuntu 22.04 LTS ضمن الميزات المهمَلة ثم المسحوبة: إهمال في الإصدار 132 وسحب في الإصدار 136، مع التوجيه «Use ELevate to upgrade to Ubuntu 24.04 LTS». ولا تذكر الصفحة تاريخ صدور لهذين الإصدارين ولا نذكر نحن أي تاريخ: تابعوا جدول إصدارات cPanel بدل تاريخ مقروء في موقع طرف ثالث. كما لا تقول الصفحة إن كانت الترقية في المكان خارج ELevate مدعومة.
أما من جهة ELevate فالتوجيه واضح: تغلّف الأداة do-release-upgrade لأن تشغيل أداة التوزيعة مباشرة على تثبيت cPanel يجعله غير صالح للاستعمال. وعلى خادم cPanel تشير وثائق cPanel إلى ELevate، والطريق الآخر خادم جديد بنظام 24.04 تُنقل إليه الحسابات. أما VPS للتطبيقات بلا لوحة تحكم فيتبع الإجراء القياسي لـ Ubuntu.
ترقية في المكان أم خادم جديد: معيار القرار
تحافظ الترقية في المكان على عنوان IP والحسابات والإعدادات. وتفشل حيث ابتعد الخادم عن التثبيت القياسي. أما الخادم الجديد فيكلّف نقل الحسابات، لكنه يترك الجهاز القديم سليمًا حتى تبديل DNS: وهو السيناريو الوحيد الذي يعني فيه التراجع ببساطة عدم التبديل.
احسموا بأربعة أسئلة. هل تغطي نسختكم الاحتياطية النظام كله؟ نسخ حسابات cPanel لا تحمي إلا البيانات التي تديرها cPanel، لا البرامج ولا إعدادات النظام: فبعد فشل خطير يجب إعادة تثبيت نظام التشغيل ثم cPanel ثم استعادة الحسابات. كم من الانقطاع يقبل العميل؟ قد تتجاوز ELevate 30 دقيقة وتعيد تشغيل الخادم عدة مرات. كم من التخصيصات تعيش خارج الحزم (مستودعات خارجية، PHP مبني يدويًا، سكربتات)؟ كل واحد مجهول أثناء الترقية. وأخيرًا، هل الخادم موصوف بالشيفرة، بـ Ansible أو غيره؟ إن كان كذلك فإعادة بنائه أسرع من إصلاحه.
قاعدة عملية: خادم تاريخي كثير التخصيص أو لم تُستعَد نسخته الاحتياطية قط، فاختاروا خادمًا جديدًا. وخادم قياسي وصورة استُعيدت بنجاح ونافذة مقبولة، فاختاروا الترقية في المكان.
أي طريق لأي خادم
مرّر الجدول أفقيًا
| حالة الخادم | الطريق الموصى به | السبب |
|---|---|---|
| VPS للتطبيقات على 22.04 بلا لوحة تحكم وبمستودعات خارجية قليلة | ترقية في المكان بـ `do-release-upgrade` | إجراء Ubuntu القياسي، والتراجع باستعادة الصورة |
| VPS للتطبيقات موصوف بالشيفرة (Ansible وCompose) | خادم جديد بنظام 24.04 | إعادة البناء أقل كلفة من الإصلاح، ويبقى القديم سليمًا حتى التبديل |
| خادم cPanel قياسي وصورة نظام قابلة للاستعادة | ترقية في المكان بـ ELevate | ترقية في المكان عبر ELevate، الأداة التي تشير إليها وثائق cPanel، مع كشف العوائق قبل البدء |
| خادم cPanel كثير التخصيص أو نسخة احتياطية لم تُستعَد قط | خادم جديد ونقل الحسابات | نسخ الحسابات لا تغطي النظام، والنقل يُبقي المصدر سليمًا |
| مواقع بإصدار PHP أقدم من 8.1 على خادم cPanel | خادم جديد، أو ترحيل المواقع أولًا | تتوقف ELevate إذا استعمل مستخدم إصدار PHP قديمًا جدًا |
| خادم في بيئة من نوع الحاويات | خادم جديد | ترفض ELevate العمل داخل بيئة من نوع الحاويات |
متطلبات بالأرقام قبل إطلاق أي شيء
بالنسبة إلى VPS قياسي، تطلب وثائق Ubuntu نظامًا محدَّثًا بالكامل ومساحة لعدة غيغابايت من التنزيل وشخصًا حاضرًا: فالترقية تفاعلية وقد تستغرق ساعات. جهّزوا وحدة تحكم خارج النطاق (وحدة الويب أو VNC لدى المزوّد) تحسبًا لعدم عودة SSH.
وبالنسبة إلى خادم cPanel، تنشر ELevate حدود المساحة الحرة: 5 غيغابايت على / و120 ميغابايت على /boot و750 ميغابايت على /tmp لنظام Ubuntu و1.5 غيغابايت على /usr/local/cpanel و5 غيغابايت على /var/lib. وتشترط وصول root تفاعليًا وترخيص cPanel صالحًا وآخر إصدار فرعي من نسخة cPanel المتوقعة لنظامكم (تطلب وثائق ELevate الإصدار 134 عند الانطلاق من Ubuntu 22: أعيدوا قراءة هذا الشرط يوم التنفيذ) وJetBackup بالإصدار 5 أو أحدث إن استعملتموه. ويجب ألا يعمل upcp ولا نسخة cPanel احتياطية عند البدء. وجهّزوا عدة طرق للوصول إلى الخادم: SSH ووحدة تحكم المزوّد، وIPMI إن أمكن.
إجراء VPS للتطبيقات بلا لوحة تحكم
جرد الحالة
دوّنوا إصدار النظام بالأمر
lsb_release -aومصادر APT الخارجية بالأمرls /etc/apt/sources.list.d/، ثم إصدارات ما يخدم مواقعكم:php -vوnginx -vوmysql --version. تصبح هذه القائمة خطة الاختبار.النسخ الاحتياطي ثم الاستعادة مرة واحدة
التقطوا صورة للـ VPS لدى المزوّد واستعيدوها على جهاز تجريبي: نسخة احتياطية لم تُستعَد قط مجرد فرضية. وأضيفوا إليها نسخة خارج الخادم من قواعد البيانات والأحجام و
/etc. ويشرح دليلنا النسخ الاحتياطي بـ Restic على VPS طريقة الإعداد.ترقية نسخة مستنسخة أولًا
أنشئوا VPS تجريبيًا من الصورة ونفّذوا عليه الإجراء كاملًا. دوّنوا كل سؤال تطرحه الأداة وكل خدمة تفشل وكل مستودع يُعطَّل. يجب ألا تحمل ترقية الإنتاج أي مفاجأة.
تحديث 22.04 بالكامل
نفّذوا
sudo apt updateثمsudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=trueكما توصي وثائق Ubuntu Server. وإذا وُجد الملف/run/reboot-requiredفأعيدوا التشغيل قبل المتابعة.فتح جلسة تصمد أمام انقطاع الاتصال
شغّلوا
tmux new -s upgrade(أوscreen) قبل الترقية كي لا يوقف فقدان اتصال SSH العمل الجاري. وأبقوا وحدة تحكم المزوّد مفتوحة في تبويب آخر.بدء الترقية
تحققوا أولًا من عرض إصدار جديد بالأمر
do-release-upgrade -cثم نفّذواsudo do-release-upgrade. تلخّص الأداة ما ستفعله وتطلب التأكيد. تحذير من الوثائق: بعد انتهاء التنزيل لا يمكن إلغاء العملية. وهذه نقطة اللاعودة، ومن بعدها يكون التراجع باستعادة الصورة.الإجابة عن الأسئلة وإعادة التشغيل والتفعيل من جديد
احتفظوا بنسختكم من كل ملف إعداد عدّلتموه، وهو الخيار الافتراضي، باستثناء الملفات اللازمة لإقلاع النواة الجديدة. أعيدوا التشغيل حين تطلب الأداة ذلك، لأن النظام لا يُعدّ مرقّى إلا بعد إعادة التشغيل. ثم فعّلوا المستودعات الخارجية المعطّلة بعد إعادة كتابتها لـ 24.04، وأعيدوا تنفيذ خطة الاختبار.
إجراء خادم cPanel باستخدام ELevate
التحقق من نقطة الانطلاق
راجعوا ترخيص cPanel وإصدار cPanel & WHM المتوقع في وثائق ELevate وآخر إصدار فرعي مثبّت. حدّثوا حزم النظام بالأمر
apt upgrade. وتأكدوا من أن إصدار MySQL أو MariaDB متوافق مع Ubuntu 24.04.أخذ صورة كاملة للخادم
لا تأخذ ELevate أي نسخة احتياطية قبل الترقية. التقطوا لقطة للخادم كله واختبروا استعادتها: فهي طريق التراجع الوحيد الذي تصفه وثائق ELevate عند الفشل الخطير.
تنزيل السكربت
نفّذوا
wget -O /scripts/elevate-cpanel https://raw.githubusercontent.com/cpanel/elevate/release/elevate-cpanelثمchmod 700 /scripts/elevate-cpanel. يجب أن يعمل السكربت من/scriptsوأن يكون محدَّثًا.تشغيل الفحص التجريبي
الأمر
/scripts/elevate-cpanel --checkلا يغيّر شيئًا ويسرد العوائق المعروفة: مساحة القرص وملفsshd_configوPHP القديم جدًا وإصدار JetBackup الأقدم من 5 وبيئة الحاويات وأسماء واجهات الشبكة بصيغةethX. أعيدوا تشغيله حتى يصبح التقرير فارغًا.رفع العوائق واحدًا واحدًا
احذفوا أو رحّلوا المواقع التي تستعمل إصدار PHP أقدم من 8.1، واتركوا
upcpوالنسخ الاحتياطية تنتهي، وحرّروا مساحة. وإذا كانت cPanel تدير MySQL لديكم فتقترح الأداة الانتقال إلى MariaDB أثناء الترقية: اتفقوا على ذلك مع العميل قبل النافذة.البدء والمراقبة
نفّذوا
/scripts/elevate-cpanel --start. تتقدم العملية في خمس مراحل مع إعادة تشغيل بين كل مرحلة وأخرى وإعادة أخيرة في النهاية، مع أكثر من 30 دقيقة يكون فيها الخادم غير متاح. تابعوها بالأمرين/scripts/elevate-cpanel --statusو/scripts/elevate-cpanel --log. وإذا توقفت العملية عند خطأ فأصلحوه ثم نفّذوا/scripts/elevate-cpanel --continue.التحقق بعد الترقية
افتحوا WHM وراجعوا الخدمات ومواقع كل حساب وإرسال البريد واستقباله والمهام المجدولة. واختبروا المواقع بإصدار PHP الذي تستعمله فعلًا، لا صفحتها الرئيسية فقط.
ما الذي ينكسر بين 22.04 و24.04 بحسب ملاحظات الإصدار
تعتمد هذه الفقرة على ملاحظات إصدار Ubuntu 24.04 LTS، لا على تجربة أجريناها على بنيتكم. أولًا، تُعطَّل المستودعات الخارجية وPPA أثناء الترقية، فيبقى Docker أو PHP أو وكيل المراقبة على المصدر القديم حتى إعادة كتابته. وتنتقل مصادر Ubuntu إلى صيغة deb822 في /etc/apt/sources.list.d/ubuntu.sources.
من جهة الويب، ينتقل nginx إلى الإصدار 1.24 (كانت LTS السابقة تحمل 1.18) وApache إلى 2.4.58 وPHP إلى 8.3.6، بينما يوفّر 22.04 الإصدار PHP 8.1. والموقع الذي يعتمد على دالة حُذفت بين هذين الإصدارين يُكتشف وقت التشغيل لا وقت الترقية. ويصبح Python 3.12 الإصدار الافتراضي، مما يمس سكربتات الإدارة لديكم.
وفي ما يخص الاتصال، صارت إعدادات sshd_config تُقرأ بمولّد في systemd يضبط الوحدة ssh.socket: تحققوا من منفذ الاستماع بعد الترقية. ويعيد needrestart تشغيل الخدمات المتأثرة بتحديث مكتبة، حتى أثناء التحديثات التلقائية. ويُعطَّل TLS 1.0 وTLS 1.1 وDTLS 1.0 قسرًا، وقد ينقطع بذلك عميل بريد قديم. وأخيرًا تحذف أداة الترقية الحزمة freeradius دون أن يظهر ذلك دائمًا في الملخص.
ما يُختبر على النسخة المستنسخة قبل نافذة العميل
- المستودعات الخارجية — يجب إعادة تفعيل كل مصدر معطّل لـ 24.04، وإدارة مفتاحه دون
apt-key. - مواقع PHP — أعيدوا تنفيذ الصفحات الحرجة لكل موقع بإصدار PHP 8.3: النماذج والدفع والمهام المجدولة.
- nginx وApache — نفّذوا
nginx -tبعد الترقية وقارنوا المضيفين الافتراضيين والوحدات وإعادات التوجيه. - SSH — تحققوا من المنفذ والدخول بالمفتاح مع إبقاء جلسة ثانية مفتوحة قبل إغلاق الأولى.
- البريد — أرسلوا واستقبلوا، بما في ذلك من عميل قديم قد يفشل مع TLS 1.0 أو 1.1.
- الحزم المحذوفة — قارنوا
apt list --installedقبل الترقية وبعدها لاكتشاف حزمة اختفت مثلfreeradius. - المهام المجدولة والنسخ الاحتياطية — نسخة احتياطية تفشل بصمت بعد الترقية هي أغلى الأعطال.
اكتبوا خطة التراجع قبل النافذة
دوّنوا كتابةً، قبل أي تدخل، من يستعيد الصورة، وكم يستغرق ذلك، وعند أي عَرَض يُتخلّى عن الترقية. فالاستعادة هي طريق التراجع الوحيد بعد تجاوز نقطة اللاعودة: حدّدوا العتبة بهدوء، لا عند الثانية فجرًا. ويُفضَّل اختيار نافذة يستطيع فيها العميل التحقق صباح اليوم التالي.
بعد 24.04: الطريق إلى 26.04 يمرّ من هنا
تمنع وثائق Ubuntu تخطّي إصدار LTS: يُنتقل من LTS إلى التي تليها، وبالتالي فالترقية من 22.04 إلى 24.04 هي المرحلة الإلزامية قبل 26.04. ويبقى Ubuntu 24.04 تحت الصيانة الأمنية القياسية حتى مايو 2029: فبعد الترقية لا يبقى على خوادمكم استعجال. والترقية من 24.04 إلى 26.04.1 مفتوحة منذ 29 سبتمبر 2026، فالتوقيت بيدكم، وهي مشروحة في دليلنا ترقية أوبونتو 24.04 إلى 26.04 على VPS.
والمنطق نفسه، مع لوحة تحكم أخرى، في دليلنا نهاية دعم Debian 11 مع Plesk. وفي مجموعة من الخوادم، جمّعوا حسب العميل: نافذة تدخل واحدة تعالج النظام وPHP وقاعدة البيانات أقل كلفة من ثلاث زيارات.
