لماذا لا تستعجل الترقية، ومتى تصبح معقولة
صدر أوبونتو 26.04 LTS في 23 أبريل 2026. وكما في كل إصدار LTS، لا تفتح Canonical الانتقال من الإصدار LTS السابق إلا عند أول إصدار نقطي: أُعلن عن 26.04.1 في 27 أغسطس 2026، لكن عرض الترقية أُجّل بضعة أسابيع أخرى ريثما تُنقل إصلاحات لتراجعات في rust-coreutils. ثم أعلن فريق الإصدار فتح الترقية في 29 سبتمبر 2026، مع طرح تدريجي على أجهزة سطح المكتب وإتاحة do-release-upgrade في أي وقت على الخوادم.
لنكن صريحين: لا شيء يستعجل. يتلقى أوبونتو 24.04 LTS تحديثات الأمان القياسية حتى مايو 2029، وحتى مايو 2034 مع Ubuntu Pro. خادم VPS بإصدار 24.04 محدَّث ليس خادماً مكشوفاً. أما 26.04 فمدعوم حتى مايو 2031.
تصبح الترقية معقولة حين تجتمع ثلاثة شروط: أن تنشر مستودعاتكم الخارجية (Docker وPHP وNode ووكلاء المراقبة) حزماً لـ resolute، وأن تجتاز نسخة مستنسخة من الخادم الترقية مع حزمتكم البرمجية الفعلية، وأن تتوفر نافذة صيانة متفق عليها مع العميل. وبالنسبة لوكالة، فاللحظة المناسبة غالباً هي لحظة توحيد الأسطول: قاعدة واحدة للتوثيق بدل اثنتين.
ما يتيحه لكم هذا الدليل
- الحسم بين الترقية في المكان وخادم VPS جديد — وفق معايير قابلة للقياس لا وفق العادة.
- امتلاك شبكة أمان حقيقية — نسخة احتياطية استُعيدت مرة على الأقل، لا لقطة لم يختبرها أحد.
- الصمود أمام انقطاع SSH — بفضل جلسة
screenالتي تفتحها الأداة بنفسها والخادم الاحتياطي على المنفذ 1022. - معرفة موضع نقطة اللاعودة — وبالتالي ما يجب أن تغطيه نسختكم الاحتياطية قبل بلوغها.
- توقّع ما سيتعطل —
sudo-rsوrust-coreutilsوPHP وMySQL وOpenSSH وdocker-composev1 والمستودعات الخارجية. - إعادة تشغيل المستودعات الخارجية — باسم الإصدار الصحيح ودون العودة إلى
apt-key. - تكرار الإجراء على أسطول كامل — كل خطوة يُتحقق منها بأمر، فيمكن إعادة إنتاجها.
الترقية في المكان أم إعادة التثبيت على خادم جديد
تحافظ الترقية في المكان على عنوان IP ومفاتيح المضيف في SSH والحسابات والإعدادات. وتفشل غالباً حيث ابتعد الخادم عن التثبيت القياسي. أما إعادة التثبيت على خادم VPS جديد فتكلّف عملية ترحيل، لكنها تُبقي الخادم القديم سليماً حتى تحويل DNS: إنه السيناريو الوحيد الذي يتيح تراجعاً حقيقياً.
احسموا الأمر بأربعة أسئلة. كم مستودعاً خارجياً وPPA مفعّلاً؟ ما زاد على اثنين أو ثلاثة يصبح كل منها مجهولاً تعطّله الأداة أثناء الترقية. هل سبق أن استُعيدت نسختكم الاحتياطية؟ إن لم يحدث، فالترقية في المكان مجازفة. ما مدى تحمّل العميل للتوقف؟ تستغرق الترقية عدة ساعات حسب توثيق أوبونتو، ويُعاد تشغيل الجهاز في النهاية. هل الخادم موصوف بالشيفرة (Ansible أو cloud-init أو Compose)؟ إن كان كذلك، فإعادة بناء خادم جديد سريعة وتصبح إعادة التثبيت الخيار الأكثر أماناً.
قاعدة عملية: خادم موثّق وحزمة برمجية في حاويات، أعيدوا التثبيت؛ خادم قديم بمستودعات خارجية قليلة ونسخة احتياطية مجرّبة، رقّوا في المكان، بعد تجربة على نسخة مستنسخة.
المتطلبات قبل تشغيل أي شيء
يجب أن يعمل الخادم بإصدار 24.04 محدَّث بالكامل: يرفض do-release-upgrade غير ذلك برسالة صريحة. خصّصوا نافذة من عدة ساعات، وشخصاً حاضراً للرد على أسئلة الأداة، ووحدة تحكم خارج النطاق (وحدة تحكم الويب أو VNC لدى المزوّد) في حال لم يعد SSH. ويجب أن يكون ممكناً فتح المنفذ 1022/tcp مؤقتاً في الجدار الناري.
تحسب الأداة بنفسها المساحة اللازمة على القرص وتتوقف إن نقصت: تحققوا من df -h / وdf -h /boot مسبقاً، وأفرغوا ذاكرة APT المؤقتة عند الحاجة. وعلى مستوى التطبيقات، تحتاجون نسخة احتياطية من البيانات خارج الخادم، ولقطة للجهاز كاملاً توفرها المنصة.
ملاحظة للأمانة: التغييرات المذكورة أدناه مصدرها ملاحظات الإصدار الرسمية لـ 26.04 وتوثيق الحزم المعنية. لم نرصدها بتجربة كاملة من جانبنا على حزمة Docker وNginx وPHP-FPM. ولهذا بالضبط يمر الإجراء عبر نسخة مستنسخة.
الإجراء خطوة بخطوة
جرد ما يأتي من خارج التوزيعة
اعرضوا مصادر APT الخارجية بالأمر
ls /etc/apt/sources.list.d/وحدّدوا الحزم الواقعة خارج أرشيف أوبونتو بالأمرapt list --installed 2>/dev/null | grep -v ubuntu. سجّلوا إصدار PHP (php -v)، ووجود ملف Compose القديم (which docker-compose && docker-compose version)، ومحتوى/etc/sudoers.d/. هذه القائمة هي خطة اختباركم.النسخ الاحتياطي ثم الاستعادة مرة واحدة
لقطة الخادم على المنصة لا تكون شبكة أمان إلا إذا استُعيدت مرة على الأقل. خذوا اللقطة، واستعيدوها على جهاز اختبار، وتحققوا من تشغيل الخدمات. وأضيفوا إليها نسخة احتياطية للتطبيقات خارج الخادم (قواعد البيانات والمجلدات و
/etc): يشرح دليلنا النسخ الاحتياطي بـ Restic على VPS طريقة الإعداد.ترقية نسخة مستنسخة أولاً
أنشئوا خادم VPS للاختبار من اللقطة (ابتداءً من 99 درهم/شهر) وطبّقوا عليه الإجراء كاملاً. سجّلوا كل سؤال تطرحه الأداة، وكل خدمة متعطلة، وكل مستودع معطَّل. يجب ألا تحمل ترقية الإنتاج أي مفاجأة بعد ذلك.
تحديث 24.04 بالكامل
يوصي توثيق Ubuntu Server بالأمر
sudo apt updateثمsudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true. إذا وُجد الملف/run/reboot-requiredفأعيدوا التشغيل قبل المتابعة. وتحققوا أخيراً من أن/etc/update-manager/release-upgradesيحتوي علىPrompt=lts.تجهيز الوصول الاحتياطي
عند التشغيل عبر SSH، تنبّه الترقية إلى أنها ستشغّل خادم SSH إضافياً على المنفذ 1022 دون فتحه في الجدار الناري. افتحوه بأنفسكم:
sudo ufw allow 1022/tcp. وأبقوا وحدة تحكم الويب لدى المزوّد مفتوحة في تبويب آخر.إطلاق الترقية
نفّذوا
sudo do-release-upgradeدون-d: هذا الخيار مخصص لإصدارات التطوير ولم يعد ضرورياً منذ فتح مسار LTS. تعيد الأداة تشغيل نفسها داخل جلسةscreenباسمubuntu-release-upgrade-screen-window. إذا انقطع اتصالكم، أعيدوا الاتصال واستأنفوها بالأمرsudo screen -d -r ubuntu-release-upgrade-screen-window. السجلات موجودة في/var/log/dist-upgrade/.الإجابة عن الأسئلة دون ردود فعل آلية
تعلن الأداة عن المستودعات الخارجية المعطّلة، ثم عن عدد الحزم التي ستُثبَّت وتُحدَّث وتُحذف. اقرؤوا قائمة الحذف. ولكل ملف إعدادات معدَّل محلياً (
sshd_configوphp.iniوnginx.conf)، احتفظوا بنسختكم افتراضياً وقارنوا لاحقاً بالملف.dpkg-dist.عبور نقطة اللاعودة عن وعي
توثيق أوبونتو واضح: بمجرد انتهاء التنزيل لا يمكن إلغاء العملية. تُستبدل الحزم ولا توفّر التوزيعة أي طريق للعودة إلى 24.04. ومن تلك اللحظة، تراجعكم الوحيد هو استعادة اللقطة من الخطوة 2.
إعادة التشغيل والتحقق
لا يُعدّ النظام مُرقّى إلا بعد إعادة التشغيل المقترحة في نهاية الإجراء. تحققوا بعدها من
cat /etc/os-releaseوuname -rوsystemctl --failedومن سجلات خدماتكم. ثم أغلقوا المنفذ الاحتياطي بالأمرsudo ufw delete allow 1022/tcp.إعادة تفعيل المستودعات الخارجية ثم Docker
أعيدوا كتابة كل مصدر خارجي باسم الإصدار
resolute. يوثّق Docker ملف مصدر بصيغة.sourcesيقرأ سطرSuitesفيه الاسم من/etc/os-release. وبالنسبة لـ PHP، يحيل مستودع PPA الخاص بـ Ondřej Surý الآن إلىpackages.sury.org/php/لإصدار Resolute. ثم تحققوا من حزمكم البرمجية بدليلنا الانتقال إلى Docker v29 على VPS.
24.04 و26.04: ما الذي يتغير تحت تطبيقاتكم
مرّر الجدول أفقيًا
| المكوّن | Ubuntu 24.04 LTS | Ubuntu 26.04 LTS |
|---|---|---|
| النواة (GA) | 6.8 | 7.0 |
| PHP (أرشيف أوبونتو) | 8.3 | 8.5 |
| Python 3 | 3.12 | 3.14 |
| OpenSSL | سلسلة 3.0 | سلسلة 3.5 |
| OpenSSH | 9.6p1 | 10.2p1، مع إزالة مفاتيح DSA |
| MySQL | 8.0 | 8.4 LTS، و`mysql_native_password` مقفل افتراضياً |
| sudo وcoreutils | sudo بلغة C وGNU coreutils | `sudo-rs` و`rust-coreutils` افتراضياً؛ وتبقى `cp` و`mv` و`rm` من GNU |
| Compose | حزمة `docker-compose` v1 (1.29.2) | حزمة v1 غير موجودة؛ `docker-compose-v2` (2.40.3) |
ما الذي يتعطل: ما تقوله ملاحظات الإصدار
التغيير الأوضح هو sudo-rs الذي صار المزوّد الافتراضي. ويبقى التنفيذ الأصلي مثبتاً باسم sudo.ws. قد تُحدث إعدادات مثل requiretty أو timestamp_type أو mailto في ملف sudoers خطأ إعداد غير معروف، ولا يوجد تسجيل للمدخلات والمخرجات، وأُزيلت sudo-ldap. والعودة إلى sudo القديم تمر عبر sudo update-alternatives --set sudo /usr/bin/sudo.ws، وهو ما لا ينصح به إعلان أوبونتو دون أن يمنعه.
تأتي الأدوات الأساسية من rust-coreutils باستثناء cp وmv وrm. وما زالت ملاحظات الإصدار تذكر ثغرات CVE مفتوحة في هذه الحزمة وخللاً في توريث ACL مع mkdir -p. وتعيد الحزمة coreutils-from-gnu إصدارات GNU إذا اعتمد عليها سكربت نسخ احتياطي أو نشر.
وبالنسبة لخادم ويب، انتبهوا أيضاً إلى أن apt-key أُزيل، وأن الوحدة libapache2-mod-php تفقد JIT الخاص بـ PHP بسبب إعداد تحصين في systemd (يُنصح بـ PHP-FPM)، وأن دعم cgroup v1 يختفي مع systemd 259.
التغييرات التي يجب اختبارها على النسخة المستنسخة
- sudo — شغّلوا
sudo visudo -cوأعيدوا تشغيل سكربتاتكم التي تستدعيsudoدون طرفية. - سكربتات shell — شغّلوا النسخ الاحتياطي والنشر كما هي؛ يظهر أي اختلاف في
rust-coreutilsعلى الخيارات النادرة لـdateأوlsأوstat. - PHP 8.5 — تحققوا من الامتدادات المحمّلة بالأمر
php -mومن توافق أنظمة إدارة المحتوى؛ فالانتقال من 8.3 يتخطى إصداراً رئيسياً وسيطاً. - MySQL 8.4 — الحسابات التي تستخدم
mysql_native_passwordمقفلة افتراضياً؛ حدّدوها قبل الترقية. - SSH — لم تعد مفاتيح DSA مقبولة، وصار OpenSSH يحذّر حين لا يكون تبادل المفاتيح مقاوماً للحوسبة الكمّية.
- Compose v1 — لم تعد حزمة
docker-composev1 موجودة في 26.04؛ وكل سكربت يستدعيdocker-composeبشرطة يجب أن ينتقل إلىdocker compose. - مزامنة الوقت — يحل chrony محل systemd-timesyncd في التثبيتات الجديدة؛ وعلى خادم مُرقّى يكون التحويل يدوياً واختيارياً.
- المستودعات الخارجية — يجب إعادة كتابة كل مصدر معطَّل لـ
resolute، وإدارة مفتاحه خارجapt-key.
إغلاق ما فتحته الترقية
بعد إعادة التشغيل، تحققوا من اختفاء الخادم الاحتياطي (يجب ألا يُرجع sudo ss -tlnp | grep 1022 شيئاً) ومن إزالة قاعدة الجدار الناري. قارنوا /etc/ssh/sshd_config بالملف sshd_config.dpkg-dist إن وُجد، ثم تحققوا من صحة الإعداد بالأمر sudo sshd -t قبل أي إعادة تشغيل للخدمة. وتصلح بعد ذلك قائمة تحصين لينكس فحصاً شاملاً.
استكشاف الأخطاء: الرسائل التي قد تظهر لكم
«Please install all available updates for your release before upgrading.» النظام غير محدَّث بالكامل: أعيدوا تنفيذ أمر apt dist-upgrade من الخطوة 4، بما في ذلك خيار التحديثات المرحلية.
«You have not rebooted after updating a package which requires a reboot.» نواة أو مكتبة تنتظر إعادة التشغيل. أعيدوا التشغيل ثم أطلقوا الترقية من جديد.
«No new release found.» تحققوا من Prompt=lts في /etc/update-manager/release-upgrades. ومع Prompt=never تصرّح الأداة بذلك وترفض.
«Required apt sources are missing» لم تعد الأداة تجد مصدر أوبونتو صالحاً، وغالباً بسبب مرآة خاصة. وافقوا على المتابعة بالمصادر الافتراضية، أو أصلحوا المصدر الرئيسي قبل إعادة المحاولة.
قائمة حزم أجنبية لا يمكن تمريرها. تذكر ملاحظات الإصدار هذا الخلل عند الترقية من 24.04: ألغوا، واحذفوا الحزم الأجنبية غير الضرورية، ثم أعيدوا المحاولة.
انقطع اتصال SSH. أعيدوا الاتصال على المنفذ 22 أو 1022، ثم استأنفوا الجلسة بالأمر sudo screen -d -r ubuntu-release-upgrade-screen-window.
ترقية لكل خادم، وطريقة واحدة للأسطول كله
الانتقال من 24.04 إلى 26.04 ليس حالة طارئة: إنه مشروع يُخطَّط له قبل مايو 2029، بإيقاعكم وإيقاع عملائكم. ما يصنع الفرق ليس الأمر، فهو سطر واحد، بل ما يحيط به: جرد، ونسخة احتياطية استُعيدت فعلاً، وتجربة على نسخة مستنسخة، ونافذة متفق عليها، وتراجع تعرفون كيف تنفذونه.
وبالنسبة لوكالة، تكمن الفائدة في جعل هذا الإجراء روتيناً. دوّنوا التغييرات التي صادفتموها على أول نسخة مستنسخة، فتصبح خطة اختبار الخوادم التالية. وينتهي الأسطول كله على قاعدة واحدة، موثّقة مرة واحدة، ومدعومة حتى مايو 2031. يصف هذا الدليل الإجراء؛ وتبقى ترقية الإصدار على عاتقكم، ولا ينفذها ServOrbit على خادمكم.
