ترقية Ubuntu 24.04 إلى 26.04 على VPS بأمان

متى يمكنك ترقية Ubuntu 24.04 إلى 26.04؟

يمكنك الآن ترقية Ubuntu 24.04 إلى 26.04 على VPS. منذ 29 سبتمبر 2026، عندما فعّلت Canonical الترقيات من 24.04 LTS، يقدّم do-release-upgrade على خادم يعمل بالإصدار 24.04 الإصدار 26.04.1. صدر Ubuntu 26.04 LTS (Resolute Raccoon) في 23 أبريل 2026، لكن Canonical لا تفتح مسار الترقية من إصدار LTS إلى إصدار LTS إلا بعد صدور أول إصدار نقطي، لأن هذا الإصدار يضم إصلاحات أخطاء التثبيت والترقية التي اكتُشفت خلال الأشهر الأولى. هذه المرة تجاوز الانتظار موعد الإصدار النقطي نفسه: صدر 26.04.1 في 27 أغسطس 2026، وأجّلت Canonical الترقية بضعة أسابيع إضافية لإصدار backports مخططة تصلح حالات تراجع في إصدار حديث من rust-coreutils. إذا كان ترقيم الإصدارات جديداً عليك، فإن 26.04.1 ليس Ubuntu مختلفاً، بل هو الإصدار 26.04 نفسه بعد دمج إصلاحات أربعة أشهر في وسائط التثبيت، ولهذا تحديداً هو أول إصدار ستقدمه Canonical لخادم موجود.

حتى 29 سبتمبر، كان تشغيل الفحص على خادم يعمل بالإصدار 24.04 يعرض ما يلي:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

لم يكن ذلك عطلاً في الخادم، وإذا كنت لا تزال تراه اليوم، فتحقق من الإعداد الذي يعتمد عليه. يحتوي /etc/update-manager/release-upgrades على Prompt=lts في Ubuntu Server، وهذا يعني أن الأداة لا تعرض إلا إصدار الدعم طويل الأمد التالي، وفقط بعد أن تفتح Canonical المسار إليه. اتركه مضبوطاً على lts على أي حال، لأن normal سيعرض أيضاً الإصدارات المؤقتة قصيرة الدعم في إصدار لاحق. خلال فترة الانتظار، عرضت Canonical do-release-upgrade -d لمن لا يريد الانتظار؛ أما الآن بعد فتح المسار، فالأمر البسيط هو الأمر الذي تسميه إعلاناتها للخوادم. اقرأ ما الذي تغيّر في 26.04.1 ومتى فُتح مسار الترقية قبل أن تبدأ. لا يستطيع خادم لا يزال يعمل بالإصدار 22.04 تنفيذ هذه القفزة مباشرة، لأن أداة الترقية تعرض دائماً إصدار LTS التالي فقط، لذلك يشرح ترقية 22.04 إلى 26.04 عبر 24.04 خطوة الترقية الأولى ولقطة النظام التي يجب أخذها قبل الخطوة الثانية.

كل أمر أدناه تنفذه بنفسك على خادمك، وبالترتيب المحدد. لا يمكن تجربة ترقية الإصدار مسبقاً على الجهاز الذي تجري ترقيته. فهي تستبدل kernel ومكتبة C، وتحتاج إلى إعادة تشغيل لإكمال العملية.

هل ينبغي لك الترقية أصلاً؟

يتلقى Ubuntu 24.04 تحديثات أمان قياسية حتى 2029، لذلك لا يواجه خادم الإنتاج العامل أي موعد نهائي للترقية. أجرِ الترقية لأنك تحتاج إلى ميزة يوفرها 26.04، مثل PHP 8.5 أو PostgreSQL 18 أو MySQL 8.4 LTS أو OpenSSH 10.2 أو kernel الإصدار 7. لا يُعد ارتفاع رقم الإصدار سبباً كافياً للمساس بجهاز يخدم العملاء.

لا تُجرِ الترقية على الخادم نفسه إذا انطبق أي مما يلي:

• لم تفتح وحدة تحكم موفّر الخدمة (VNC أو serial) وتسجّل الدخول إليها من قبل. وحدة التحكم هذه هي الطريقة الوحيدة لاستعادة الوصول إلى الخادم إذا تعطل SSH، ومعرفة أنها لا تعمل بعد فقدان الوصول تكون متأخرة جداً.
• لا يمكنك تحمّل ساعة من التوقف، ولا تملك خطة rollback.
• تعتمد حزمة البرامج لديك على مستودع تابع لجهة خارجية لم ينشر حزمته لـ resolute بعد.
• بُني الخادم يدوياً قبل أكثر من عامين، ولا يعرف أحد ما الموجود عليه.

غالباً ما يكون البديل أفضل: أنشئ VPS جديداً يعمل بـ26.04، وثبّت حزمة البرامج لديك واستعد البيانات، ثم بدّل DNS بعد التأكد من أنه يستجيب بشكل صحيح. يمكنك إبقاء الخادم القديم قيد التشغيل حتى يثبت الخادم الجديد استقراره، ويصبح rollback تغييراً في DNS بدلاً من استعادة نسخة احتياطية. إذا اخترت هذا المسار، فابدأ بـالدقائق العشر الأولى على VPS جديد وابنِ الخادم الجديد بطريقة صحيحة.

الخطوة 1: أنشئ نسخة احتياطية يمكنك الاستعادة منها

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

أنشئ تفريغاً لقواعد البيانات يدوياً أولاً. التفريغ إحدى طرق إجراء نسخة احتياطية لقاعدة بيانات قيد التشغيل.

sudo -u postgres pg_dumpall | sudo tee /var/backups/pg-all.sql > /dev/null
sudo mysqldump --all-databases --single-transaction --routines | sudo tee /var/backups/mysql-all.sql > /dev/null
sudo tar czf /var/backups/etc-before-upgrade.tgz -C / etc
sudo chmod 600 /var/backups/pg-all.sql /var/backups/mysql-all.sql

يوفّر --single-transaction تفريغاً متسقاً لجداول InnoDB فقط. تحتاج جداول MyISAM إلى أقفال لإجراء تفريغ متسق. أما أرشيف tarball الخاص بـ/etc فهو الملف الذي ستحتاج إليه فعلياً، لأنه يحتوي على كل ملفات الإعداد التي سيسألك عنها الترقية بعد قليل.

النسخة الاحتياطية التي لم تستعد منها شيئاً من قبل ليست إلا تخميناً. استخرج منها ملفاً واحداً الآن، قبل أن تحتاج إليه تحت الضغط.

الخطوة 2: طبّق التحديث الكامل على 24.04 أولاً

يرفض do-release-upgrade العمل على نظام توجد فيه حالة حزم معطّلة، كما أن 24.04 التي طُبّقت عليها التصحيحات جزئياً تجعل قراءة كل فشل لاحق أكثر صعوبة.

sudo apt update
sudo apt full-upgrade
sudo apt --purge autoremove
sudo dpkg --audit
apt-mark showhold

عدم طباعة dpkg --audit لأي شيء يعني أنه لا توجد حزمة نصف مهيّأة. وعدم طباعة apt-mark showhold لأي شيء يعني أنه لا توجد حزمة عليها تثبيت dpkg. لا يعرض ذلك تفضيلات APT المثبّتة، وهي آلية منفصلة يمكنها أيضاً منع تحديث حزمة؛ وتتحقق الخطوة 3 من هذه التفضيلات. حرّر أي شيء تعرضه showhold باستخدام sudo apt-mark unhold واسم الحزمة، أو تقبّل أن التثبيت موجود لسبب وتوقف هنا.

أعد التشغيل إذا تغيّرت النواة، لكي تجري الترقية من جهاز يعمل فعلياً بالتعليمات البرمجية التي يعتقد أنه يعمل بها.

[ -f /var/run/reboot-required ] && sudo reboot

ثم تحقّق من مساحة القرص. ينزّل برنامج الترقية مجموعة الحزم الجديدة كاملة قبل تثبيت أي شيء، ويتوقف برسالة تذكر نظام الملفات إذا لم تتوفر مساحة كافية.

df -h / /boot

تكون النوى القديمة هي السبب عادةً، ويزيلها sudo apt --purge autoremove.

هناك أمر آخر يجب إيقافه قبل البدء: إذا بدأت التحديثات الأمنية التلقائية أثناء التنفيذ، فستحتجز قفل dpkg، ويتوقف برنامج ترقية الإصدار مع Could not get lock /var/lib/dpkg/lock-frontend. شغّل sudo systemctl stop unattended-upgrades أولاً، ثم شغّله مرة أخرى عند الانتهاء.

الخطوة 3: تحقّق من المستودعات التابعة لجهات خارجية والحزم المثبّتة بإصدارات محددة

افتراضياً، يعطّل do-release-upgrade كل مصدر APT ليس تابعاً لـ Ubuntu، لأن الحزمة المبنية لـ noble قد تتسبب في تعطل نظام resolute. أما الخيار --allow-third-party فيها، فيُبقي هذه المصادر مفعّلة، وهذا ينطوي على الخطر نفسه تحديداً. اعرف ما الذي ستُبقيه مفعّلاً قبل أن تتخذ الأداة القرار نيابةً عنك.

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |Types:|URIs:|Suites:)' /etc/apt/sources.list.d/
ubuntu-security-status --thirdparty
ls /etc/apt/preferences.d/

يستخدم Ubuntu 24.04 تنسيقين في هذا الدليل: ملفات .list القديمة ذات السطر الواحد، وملفات .sources بتنسيق deb822 التي تحتوي على الحقلين Types: وSuites:. يعطّل الترقية الافتراضية كليهما. يسرد ubuntu-security-status --thirdparty الحزم المثبّتة التي لا يوفّرها أي أرشيف Ubuntu، وهو العدد الفعلي لما أضفته إلى النظام. لا يُقرأ الملف في /etc/apt/preferences.d/ كملف تثبيت بإصدار محدد إلا إذا لم يكن لاسمه امتداد، أو انتهى بـ .pref، وكان يحتوي على أحرف وأرقام وواصلات وشرطات سفلية ونقاط فقط؛ ويتجاهل APT أي ملف آخر، وعادةً يعرض إشعاراً بذلك. قد يؤدي ملف تثبيت يذكر noble إلى إبقاء حزمة على إصدار قديم بعد الترقية، تبعاً للإصدارات التي ما تزال متاحة والأولوية التي يحددها الملف. لذلك اقرأ كل ملف وقرّر ما إذا كان لا يزال مطلوباً.

لكل مستودع تابع لجهة خارجية، تأكد من أن المورّد نشر إصداراً للاسم الرمزي الجديد قبل أن تبدأ. تُدرج إصدارات Docker في https://download.docker.com/linux/ubuntu/dists/، ويعرض المورّدون الآخرون الدليل نفسه. يؤدي توجيه مصدر إلى إصدار غير موجود إلى ظهور الرسالة التالية عند أول apt update بعد الترقية:

E: The repository 'https://download.docker.com/linux/ubuntu resolute Release' does not have a Release file.

ينشر Docker الآن إصدار resolute. اترك أي مصدر لإصدار غير موجود معطّلاً إلى أن ينشره المورّد. إن تعديل الاسم الرمزي إلى اسم بنى له المورّد حزمَه هو طريقة لتثبيت حزم مرتبطة بمكتبات النظام الخاطئة.

الخطوة 4: شغّل الترقية داخل tmux، وليس داخل جلسة SSH عادية

يعمل برنامج ترقية الخادم عادةً داخل GNU screen، ويدعم إعادة الاتصال بعد انقطاع الاتصال. لذلك لا يؤدي فقدان اتصال SSH وحده إلى إيقاف الترقية. شغّله أيضاً داخل جلسة tmux خاصة بك، حتى تتوفر لديك جلسة مُسمّاة يمكنك إعادة الاتصال بها.

sudo apt install -y tmux
tmux new -s upgrade

داخل تلك الجلسة:

sudo ufw allow 1022/tcp
sudo do-release-upgrade

يشغّل برنامج الترقية خادم SSH ثانياً على المنفذ 1022 قبل أن يغيّر أي شيء، ويعرض رسالة تفيد بذلك:

To make recovery in case of failure easier, an additional sshd will be started on port '1022'. If anything goes wrong with the running ssh you can still connect to the additional one.

لا يفتح البرنامج منفذ الجدار الناري لهذا المنفذ، لأن فتح منفذ في الجدار الناري دون طلب ذلك سيكون مفاجئاً وغير مناسب. افتح المنفذ 1022 بنفسك قبل البدء، وأغلقه عند الانتهاء باستخدام sudo ufw delete allow 1022/tcp. تذكّر أن مزود الخدمة قد يشغّل جداراً نارياً ثانياً في لوحة التحكم الخاصة به، خارج الخادم.

إذا انقطع الاتصال رغم ذلك، سجّل الدخول مجدداً وشغّل tmux attach -t upgrade. استمرت الترقية في العمل أثناء غيابك. وإذا لم تستمر، ووجدت عند عودتك أن dpkg أو مصادر apt في حالة إعداد جزئي، بحيث يكون جزء منها noble والجزء الآخر resolute، فتغطي استعادة ترقية إصدار فاشلة إصلاح حالة الحزم ومعرفة الوقت الذي يجب أن تتوقف فيه عن الإصلاح وتستعيد اللقطة بدلاً من ذلك.

الخطوة 5: أجب عن مطالبات ملف الإعدادات بعناية

يعرض dpkg المطالبات فقط للملفات التي عدّلتها أنت أو أحد البرامج النصية. لذلك، كل مطالبة تتعلق بملف عدّلته أنت أو أحد البرامج النصية، ويؤدي الضغط على Enter إلى الاحتفاظ بالإصدار الحالي افتراضياً.

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

اضغط D أولاً في كل مرة. اقرأ ما تغيّر، ثم قرر الاحتفاظ بإصدارك باستخدام N أو تثبيت إصدار المشرف على الحزمة. الإعداد الافتراضي هو N بالفعل، لكن الاحتفاظ بالملف القديم ليس آمناً مع كل حزمة؛ إذ تكون بعض تغييرات الإعدادات مطلوبة حتى يعمل النظام الذي تمت ترقيته.

للاحتفاظ بملفك تكلفة: لن تحصل على الإعدادات الافتراضية الجديدة. سوِّ الفروق بعد ذلك، عندما يعمل الخادم ولا تكون تحت ضغط الوقت.

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-new'

كل ملف يعرضه النظام هو إصدار المشرف على الحزمة، وقد حُفظ بجوار ملفك. قارن بين الملفين واحداً تلو الآخر، وانسخ الإعدادات المهمة إلى ملفك. يتطلب ملفان عناية إضافية: /etc/ssh/sshd_config، لأن الإجابة الخاطئة تنهي جلستك، وإعدادات خادم الويب، لأن الإجابة الخاطئة توقف المواقع.

منذ Ubuntu 24.04، تعيد الخدمات المتأثرة التشغيل تلقائياً افتراضياً عبر needrestart. إذا أعدت تفعيل وضعه التفاعلي، فاقبل القائمة الكاملة. يظل الـdaemon الذي يستخدم مكتبة مشتركة قديمة عرضة للأخطاء التي أصلحها التحديث إلى أن يُعاد تشغيله.

الخطوة 6: أعد التشغيل، ثم افحص الجهاز

sudo reboot

بعد عودة الجهاز للعمل:

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | head -50
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

يجب أن يعرض lsb_release -a النتيجتين Release: 26.04 وCodename: resolute. يجب أن يعرض uname -r نواة بإصدار 7.0. يجب أن يسرد systemctl --failed وحدات بعدد صفر، وأي وحدات يسردها تكون مهمتك التالية. يحدّث apt update الأخير فهارس الحزم، ثم يثبّت apt full-upgrade أي تحديثات نُشرت منذ أن جلبت عملية الترقية حزمها.

PostgreSQL 16 إلى 18: مجموعة البيانات التي تبقى بهدوء على الإصدار القديم

يأتي Ubuntu 24.04 مع PostgreSQL 16، ويأتي Ubuntu 26.04 مع PostgreSQL 18. يثبّت الترقية الإصدار 18 إلى جانب الإصدار 16، ولا تنقل بياناتك. تنشئ طبقة Debian ‏postgresql-common مجموعة رئيسية عند تثبيت حزمة الخادم فقط عندما لا توجد أي مجموعات بعد. لذلك لا تحصل مجموعة PostgreSQL 16 الموجودة تلقائياً على مجموعة 18 فارغة على المنفذ 5433. ويستمر تطبيقك في الاتصال بالمنفذ 5432 دون أن يبدو أي خلل، ولهذا يكتشف الناس المشكلة بعد أشهر.

pg_lsclusters

يعني إدخال الإصدار 16 أن هذه المجموعة لا تزال تعمل على الإصدار 16. إذا أدرج pg_lsclusters أيضاً مجموعة 18 main، فتحقق من أنها فارغة قبل إزالتها باستخدام sudo pg_dropcluster --stop 18 main، لأن pg_upgradecluster لن يكتب في مجموعة هدف موجودة مسبقاً. نفّذ الترحيل عندما تتمكن من إيقاف التطبيق:

sudo pg_upgradecluster 16 main
pg_lsclusters
sudo -u postgres vacuumdb --all --analyze-only

تفرغ الطريقة الافتراضية بيانات الإصدار 16 ثم تعيد تحميلها في الإصدار 18، لذلك تحتاج إلى مساحة قرص حرة تعادل حجم قاعدة البيانات تقريباً. يستخدم -m upgrade pg_upgrade بدلاً من ذلك، وهو أسرع بكثير مع قواعد البيانات الكبيرة. عند اكتماله، اقرأ العمود Port: تتولى المجموعة الجديدة المنفذ 5432، وتبقى المجموعة القديمة متوقفة. تنفّذ آلية الترقية المضمّنة في الحزمة عملية analyze تلقائياً؛ ويعيد الأمر أعلاه تنفيذها صراحةً.

اختبر التطبيق على المجموعة الجديدة لبضعة أيام. بعد ذلك فقط أزل المجموعة القديمة:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

يُعد دليل بيانات المجموعة القديمة أسرع وسيلة تراجع متاحة لك. لا تحذفه في يوم الترقية.

MySQL 8.0 إلى 8.4: الخيار المحذوف الذي يوقف الخادم

ينقل 26.04 إصدار MySQL من 8.0 إلى 8.4 LTS، وهناك تغييران يتسببان في مشكلات للخوادم.

أولاً، يرفض mysqld البدء عندما يحتوي ملف الإعدادات على خيار أزالته النسخة الجديدة. ويُعد default_authentication_plugin الخيار الأكثر شيوعاً، لأن كثيراً من الأدلة الأقدم توصي بتعيينه. تفشل الخدمة، ويذكر journalctl -u mysql -n 50 المتغير غير المعروف مباشرة. احذف ذلك السطر من الملف الموجود ضمن /etc/mysql/mysql.conf.d/، ثم نفّذ sudo systemctl start mysql.

ثانياً، لم تعد إضافة mysql_native_password مفعّلة افتراضياً في 8.4، لذلك لا يستطيع أي حساب لا يزال يستخدمها تسجيل الدخول إطلاقاً. تحقّق من ذلك بينما لا تزال تستخدم 8.0:

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

انقل كل حساب يظهر لديه mysql_native_password قبل الترقية، ثم حدّث كلمة المرور في إعدادات تطبيقك:

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

إذا كانت مكتبة العميل قديمة جداً ولا تدعم caching_sha2_password، يمكنك إعادة تفعيل الإضافة القديمة في 8.4 بإضافة mysql_native_password=ON ضمن [mysqld]. اعتبر ذلك حلاً مؤقتاً له تاريخ انتهاء، لأن MySQL أزال الإضافة في 9.0.

PHP 8.3 إلى 8.5: تشير vhosts إلى socket لم يعد موجوداً

تأتي 24.04 مع PHP 8.3، وتأتي 26.04 مع PHP 8.5. تُثبّت الحزم الملفات في مسارات مرتبطة بالإصدار، ولا يعيد أي شيء كتابة إعدادات خادم الويب لديك. يشير vhost في nginx الذي يحتوي على fastcgi_pass unix:/run/php/php8.3-fpm.sock; الآن إلى socket لا تنشئه أي عملية، لذلك يعيد كل طلب PHP الرمز 502، ويعرض سجل أخطاء nginx ما يلي:

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)

وجّه الإعداد إلى socket الجديد، ثم اختبر الإعداد وأعد التحميل:

sudo sed -i 's/php8.3-fpm.sock/php8.5-fpm.sock/' /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

تختلف المشكلة مع Apache عند استخدام mod_php: لن يبدأ Apache إطلاقاً، ويبلغ sudo apache2ctl -t بأنه لا يستطيع تحميل libphp8.3.so لأن الملف غير موجود. الوحدة المفعّلة هي symlink إلى حزمة لم تعد موجودة.

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo systemctl restart apache2

إذا أنشأت الخادم باتباع مكدس LAMP على Ubuntu 24.04، فتحقق من كلا المسارين، لأن الدليل يترك لديك اسم وحدة مرتبطاً بالإصدار واسم socket مرتبطاً بالإصدار.

لا تنتقل إعدادات php.ini أيضاً. توجد memory_limit وupload_max_filesize وأي إعدادات أخرى ضبطتها في /etc/php/8.3/، وتبدأ شجرة الإصدار الجديد من الإعدادات الافتراضية. قارِن الملفين وانسخ القيم يدوياً. يؤدي نسخ الملف القديم بالكامل فوق الملف الجديد إلى نقل إعدادات 8.3 الافتراضية إلى تثبيت 8.5. ثم شغّل php -m وقارِن الناتج: تحتاج الإضافة المثبّتة باسم php8.3-redis إلى الحزمة php8.5-، وإذا كانت قد جاءت من PPA، فعّل برنامج الترقية تعطيل ذلك المصدر وتصبح الإضافة مفقودة ببساطة.

تحتاج الشهادات إلى فحص مستقل. شغّل sudo certbot renew --dry-run --run-deploy-hooks بعد الترقية. يختبر ذلك مسار التجديد بالكامل، بما في ذلك hook إعادة تحميل خادم الويب، من دون تعديل الشهادة المستخدمة حالياً. إذا كان hook يستدعي اسم خدمة أو ملفاً تنفيذياً تغيّر، فسيفشل هنا أمامك بدلاً من أن يفشل بصمت عند التجديد التالي. يوضّح Certbot مع Let's Encrypt على nginx الشكل الذي ينبغي أن تكون عليه تلك الـhooks.

SSH: الخطأ الذي ينهي الجلسة التي تعمل فيها

موجّه sshd_config هو الموضع الذي يتسبب فيه المستخدمون في منع أنفسهم من الدخول. تؤدي الإجابة بـY إلى تثبيت ملف المشرف على الحزمة، ما يحذف PermitRootLogin وPasswordAuthentication وAllowUsers وPort وكل سطر آخر أضفته. إذا كان جدارك الناري يسمح بمنفذ مخصص فقط، وكان الإعداد المرفق يستمع على 22، فسيُرفض الاتصال التالي، وستكون الجلسة التي تعمل فيها آخر جلسة متاحة لك.

امنع ذلك قبل الترقية. يبدأ /etc/ssh/sshd_config في 24.04 بـInclude /etc/ssh/sshd_config.d/*.conf، ويحتفظ OpenSSH في معظم الإعدادات بأول قيمة يقرأها. لذلك يفوز الملف الإضافي المضمّن في الأعلى على الإعداد نفسه الموجود لاحقاً. توجد استثناءات لبعض الكلمات المفتاحية: يقبل Port وListenAddress قيم متعددة، لذلك يضيف سطر Port في ملف إضافي منفذاً بدلاً من استبدال المنفذ المحدد تحته. انقل إعداداتك إلى ملف لا تملكه dpkg:

sudo tee /etc/ssh/sshd_config.d/99-local.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf
sudo sshd -t && sudo systemctl restart ssh

عندما لا يعود أي شيء داخل /etc/ssh/sshd_config مملوكاً لك، لن يعود ذلك الموجّه مهماً: إذ تحافظ كلتا الإجابتين على إعداداتك لأنها موجودة في ملف مختلف.

يتطلب المنفذ المخصص فحصاً إضافياً، لأنه قد لا يكون في الموضع الذي تتوقعه:

systemctl is-enabled ssh.socket

إذا طبع ذلك enabled، فإن systemd يفتح منفذ الاستماع، وليس sshd. تستخدم Ubuntu تنشيط المقابس لـsshd منذ 22.10. في 24.04، يقرأ مولّد systemd إعدادَي Port وListenAddress من إعدادات sshd، ويحوّلهما إلى عناوين استماع المقبس، ولكن فقط عندما يعيد systemd تحميل وحداته. لذلك يبدو تعديل Port 2222 وكأنه لا يفعل شيئاً: إذ يصبح نافذاً بعد sudo systemctl daemon-reload && sudo systemctl restart ssh.socket، ويحمل sshd_config المرفق بالحزمة الآن ملاحظة توضح ذلك. لتعيين المنفذ مباشرةً في وحدة المقبس بدلاً من ذلك، استخدم sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

قيمة ListenStream= الفارغة مطلوبة. فهي تمسح القيمة الموروثة، ومن دونها سيستمع المقبس على 22 بالإضافة إلى 2222. طبّقها باستخدام sudo systemctl daemon-reload && sudo systemctl restart ssh.socket.

بعد الترقية، وقبل أن تغلق الجلسة التي تعمل فيها:

sudo sshd -t
sudo systemctl status ssh.socket --no-pager
sudo ss -lntp | grep -E ':(22|2222)'

ثم افتح طرفية ثانية على جهازك وسجّل الدخول مرة أخرى. إن وجود shell يعمل في تلك الطرفية الثانية هو الدليل الوحيد الموثوق. أبقِ الجلسة الأولى مفتوحة حتى تنجح في ذلك. يشرح تقوية SSH على VPS الإعدادات التي يجدر إبقاؤها في ذلك الملف الإضافي.

إذا فات الأوان بالفعل، تتيح وحدة التحكم على الويب لدى مزود الخدمة تسجيل دخول لا يستخدم SSH إطلاقاً. سجّل الدخول إليها، وأصلح الإعداد، وشغّل sudo sshd -t، ثم أعد تشغيل الخدمة. هذا هو سبب اختبار الوصول إلى وحدة التحكم قبل الترقية، لا أثناءها.

FAQ

لماذا يعرض do-release-upgrade الرسالة "No new release found" على Ubuntu 24.04؟

منذ 29 September 2026، لا يُفترض أن تظهر هذه الرسالة، لأن Canonical فعّلت في ذلك اليوم الترقية من 24.04 LTS إلى 26.04.1. قبل ذلك، كانت الرسالة متوقعة: صدر Ubuntu 26.04 LTS في 23 April 2026، وتبعه الإصدار 26.04.1 في 27 August، وظل مسار الترقية مغلقاً بضعة أسابيع إضافية بينما أصدرت Canonical إصلاحات خلفية لمشكلات التراجع في rust-coreutils. إذا استمرت الرسالة في الظهور، فتحقق من أن /etc/update-manager/release-upgrades يحتوي على Prompt=lts، وهو الإعداد الافتراضي لـ Ubuntu Server، ولا يتيح إلا الترقية إلى إصدار الدعم طويل الأمد التالي. اتركه مضبوطاً على lts.

هل يجب إعادة تشغيل الخادم لإكمال الترقية؟

نعم. تثبّت الترقية نواة جديدة، ومكتبة C جديدة، ونظام init جديداً. ويستمر النظام قيد التشغيل في استخدام الإصدارات القديمة منها إلى أن يُعاد تشغيله. يطلب do-release-upgrade إعادة التشغيل في النهاية، والخادم الذي يظل قيد التشغيل إلى "وقت لاحق" يعمل بمزيج من إصدارين. بعد عودة الخادم، افحص uname -r للتحقق من النواة الجديدة، وsystemctl --failed لمعرفة الخدمات التي لم تعمل بعد إعادة التشغيل.

هل أُجري الترقية على الخادم الحالي أم أنشئ خادماً جديداً يعمل بالإصدار 26.04؟

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

ماذا يحدث إذا انقطع اتصال SSH أثناء الترقية؟

يستخدم برنامج ترقية الخادم عادةً GNU screen، لذلك لا يؤدي انقطاع اتصال SSH بحد ذاته إلى إيقاف الترقية. إذا بدأت العملية داخل جلسة tmux المسماة المذكورة أعلاه، فأعد الاتصال وشغّل tmux attach -t upgrade لاستئنافها. كما يشغّل برنامج الترقية SSH daemon احتياطياً على المنفذ 1022 كطريقة وصول ثانية، لكنه لا يفتح جدار الحماية لهذا المنفذ. لذلك اسمح بالوصول إلى 1022 بنفسك أولاً، ثم أغلقه بعد انتهاء العملية.

يعرض موقعي الذي يعمل بـ PHP الخطأ 502 بعد الترقية. ما الذي تعطل؟

تغيّر مسار socket الخاص بـ PHP FPM مع الإصدار. يشغّل Ubuntu 24.04 إصدار PHP 8.3، بينما يشغّل 26.04 إصدار PHP 8.5، لذلك لم يعد /run/php/php8.3-fpm.sock موجوداً، في حين أن إعداد vhost الخاص بـ nginx لا يزال يشير إليه. يعرض سجل أخطاء nginx الرسالة connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). حدّث fastcgi_pass ليشير إلى socket الخاص بالإصدار 8.5، وشغّل sudo nginx -t، ثم أعد تحميل nginx. في Apache مع mod_php، يكون الإصلاح المكافئ هو sudo a2dismod php8.3، ثم sudo a2enmod php8.5 وإعادة التشغيل.