تصحيح نواة VPS مباشرة أم إعادة التشغيل؟

ما الذي يفعله تصحيح النواة المباشر على VPS

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

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

غالباً ما يُقدَّم التصحيح المباشر كميزة ضمن خطة مُدارة. أما على خادم غير مُدار، فيمكنك تفعيله بنفسك باستخدام أمرين، ومن المفيد معرفة ذلك قبل أن تدفع مقابل الفرق بين VPS مُدار وVPS غير مُدار.

كيف يعمل تصحيح النواة المباشر؟

تحتوي النواة على مكوّن مدمج للتصحيح المباشر، وقد جرى تضمينه باستخدام CONFIG_LIVEPATCH. تحقّق من وجوده في النواة قيد التشغيل:

grep CONFIG_LIVEPATCH /boot/config-$(uname -r)

يعني ظهور سطر يقرأ CONFIG_LIVEPATCH=y أن النواة قيد التشغيل بُنيت مع تضمين هذا المكوّن. إذا لم يكن موجوداً، فلن تتمكن أي خدمة للتصحيح المباشر من تنفيذ أي إجراء على ذلك الجهاز.

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

تترتب على هذه الجملة نتيجتان، وكلتاهما مهمتان لاحقاً. لا يمكن تصحيح سوى الدالة التي يستطيع ftrace وضع خطّاف عليها، ولذلك لا يمكن تصحيح الدالة المترجمة من دون استدعاء الدخول هذا على الإطلاق. كما أن وحدة التصحيح هي الدالة بأكملها، وليست سطراً واحداً داخلها.

الجزء الأصعب هو تبديل الشيفرة بأمان على نظام قيد التشغيل. إذا كانت الشيفرة القديمة لا تزال تعمل على مكدس إحدى وحدات CPU عند تبديل الدالة، فستحصل على مزيج من السلوك القديم والجديد. يتعامل Linux الأساسي مع ذلك باستخدام نموذج اتساق لكل مهمة، وتصفه وثائق النواة بأنه نموذج هجين: "يستخدم اتساق kGraft لكل مهمة والتبديل عند حاجز استدعاءات النظام، مع دمجهما بتبديل تتبّع المكدس في kpatch." تنتقل المهام إلى الشيفرة الجديدة واحدة تلو الأخرى، وفقط عندما تستطيع النواة إثبات أن المهمة لا تنفّذ حالياً داخل دالة مصححة. وإلى أن تنتقل جميع المهام، يبقى التصحيح في حالة انتقالية.

يمكنك رؤية النتيجة بنفسك. تظهر التصحيحات المطبّقة تحت /sys/kernel/livepatch، في دليل مستقل لكل تصحيح، مع إدراج الدوال المصححة داخله.

ls /sys/kernel/livepatch/

تعني القائمة الفارغة عدم تحميل أي تصحيح مباشر في الذاكرة. وهذا هو الوضع الابتدائي المعتاد على خادم جديد.

ما الذي لا يستطيع تصحيح النواة الحي إصلاحه

تُطبَّق التصحيحات على أجسام الدوال. أما كل شيء آخر فلا يُصحَّح.

• هياكل البيانات المتغيّرة. إذا أضاف الإصلاح upstream حقلاً إلى struct أو غيّر معنى حقل موجود، فلا توجد طريقة آمنة لإعادة كتابة الكائنات التي خُصّصت في الذاكرة وتُستخدم حالياً. يذكر مشروع kpatch الحالة المكافئة مباشرةً: "Patches which modify statically allocated data are not directly supported." توجد shadow variables وcallbacks كحل بديل، لكنها تُكتب يدوياً لكل تصحيح وليست آلية.
• الإصلاحات الموزعة على عدة دوال في الوقت نفسه. يحتاج الإصلاح الذي يغيّر ترتيب الأقفال عبر مجموعة من الدوال إلى تغييرها كلها معاً. ويبدّل نموذج الاتساق المهام بدلاً من تجميد الجهاز بأكمله في لحظة واحدة.
• شفرة التهيئة. تكون الدوال الموسومة بـ __init قد نُفِّذت وحُرِّرت بحلول وقت عمل الخادم، لذلك لا يبقى شيء يمكن إعادة توجيهه.
• إصدارات النواة الجديدة والميزات الجديدة. ينقلك التصحيح الحي بين مستويات التصحيح داخل سلسلة نواة واحدة. ولا ينقلك أبداً من سلسلة إلى أخرى، كما أنه لا يضيف أي ميزة. إذا أردت ميزة من سلسلة أحدث، مثل التغييرات التي أُدخلت في Linux 7.1، فعليك تثبيت تلك النواة وتشغيلها عند الإقلاع.
• مساحة المستخدم. توضّح Canonical الحد الفاصل نفسه: "Canonical Livepatch does not patch userspace libraries like OpenSSL or glibc, because that is the responsibility of unattended-upgrades or a systems management tool." وجود نواة مصحَّحة حياً بجانب OpenSSL قديم لا يعني أن الخادم مصحَّح، لذلك اترك unattended upgrades تتولى حزم مساحة المستخدم على الخادم نفسه.

يوجد أيضاً حد متعلق بدرجة الخطورة في خدمة Ubuntu. تقول Canonical إن الخدمة "تطبّق تصحيحات على ثغرات النواة ذات تصنيفات الخطورة الحرجة والعالية وفق نظام Common Vulnerability Scoring System (CVSS) وتصنيفات أولوية Ubuntu." يعرّف معرّف CVE (common vulnerabilities and exposures) ثغرة واحدة، بينما تمثل CVSS الدرجة المرتبطة بها. تُصلَح ثغرة CVE في النواة ذات التصنيف المتوسط داخل الحزمة الموجودة على القرص، ولا تُصحَّح حياً. لذلك تصل إلى النواة قيد التشغيل عند إعادة التشغيل التالية، وليس قبل ذلك.

ما خيارات ترقيع النواة المباشر؟

توجد ثلاث سلاسل مستخدمة على نطاق واسع، وكلها تعتمد على آلية النواة نفسها.

يُوفَّر Canonical Livepatch عبر Ubuntu Pro. استخدام Ubuntu Pro مجاني للاستخدام الشخصي، وتنص صياغة Canonical على أنه «مجاني للاستخدام الشخصي حتى 5 أجهزة فعلية، وسيظل كذلك دائماً»، ويرتفع الحد إلى 50 جهازاً لأعضاء Ubuntu Community الرسميين. هذا هو الحد الموثق حتى August 2026. يتطلب الاستخدام التجاري اشتراكاً مدفوعاً. يُمنح الدعم لكل سلسلة نواة ولكل نكهة، ويشمل نوى التوافر العام (GA) لإصدارات الدعم طويل الأمد (LTS) المدعومة، إضافة إلى نوى تمكين العتاد (HWE) الخاصة بها، عبر نكهات مثل generic وaws وazure وgcp وoracle وibm وlowlatency. تحقّق من نواتك مقابل قائمة النوى المنشورة من Canonical قبل الاعتماد عليها.

KernelCare، من TuxCare، هو وكيل تجاري يدعم العديد من التوزيعات، بما في ذلك التوزيعات التي لا توفر لها الجهة المطوِّرة خدمة رسمية. يتضمن التثبيت الموثق استخدام سكربت المورّد، curl -s -L https://kernelcare.com/installer | bash، ثم /usr/bin/kcarectl --register KEY للحصول على ترخيص قائم على مفتاح. يتحقق الوكيل بعد ذلك من وجود ترقيعات جديدة وفق جدوله الخاص، ويفرض /usr/bin/kcarectl --update إجراء تحقق فوري. اقرأ برنامج التثبيت قبل تمريره إلى shell على خادم مهم.

kpatch وkGraft هما الأساس التاريخي لهذه التقنية. نشأ kGraft لدى SUSE، بينما نشأ kpatch لدى Red Hat، وأصبحت نواة الترقيع المباشر في Linux upstream اليوم دمجاً للفكرتين. يتراجع استخدام kpatch نفسه تدريجياً؛ إذ يذكر ملف README الخاص به أنه ابتداءً من Linux 6.19 «أصبح مشروع kpatch مهجوراً وفي وضع الصيانة»، مع استبدال kpatch-build بـ klp-build في نواة upstream. على RHEL وإصداراته المعاد بناؤها، استخدم الخدمة الخاصة بالتوزيعة بدلاً من بناء الترقيعات يدوياً.

اختر بناءً على ما تدعمه توزيعتك وما يسمح به ترخيصك. النتيجة على مستوى النواة واحدة في جميع الحالات.

كيفية تفعيل Canonical Livepatch على Ubuntu

احصل أولاً على token من صفحة حساب Ubuntu Pro. يحتاج كلا الأمرين أدناه إلى اتصال شبكة صادر يعمل، لأن العميل يتصل بخوادم Canonical لإلحاق النظام بالحساب وتنزيل التصحيحات.

sudo pro attach TOKEN
sudo pro status

يؤدي تشغيل sudo pro attach دون token إلى بدء مسار يعتمد على المتصفح بدلاً من ذلك، ويطبع code لإدخاله في موقع Canonical. يؤدي الإلحاق إلى تفعيل الخدمات الموصى بها تلقائياً، وتشمل Livepatch في إصدارات LTS الحالية. استخدم sudo pro attach --no-auto-enable إذا كنت تفضّل اختيار الخدمات بنفسك.

إذا لم يكن Livepatch مفعّلاً:

sudo pro enable livepatch
sudo canonical-livepatch status

تعمل الخدمة من snap canonical-livepatch، لذلك يجب أن يعمل snapd حتى تكتمل خطوة التفعيل. يطبع pro status جدولاً بالخدمات مع استحقاق كل خدمة وحالتها. يطبع canonical-livepatch status التفاصيل الخاصة بكل kernel، وتعرض وثائق Canonical مخرجات بهذا الشكل:

last check: 52 seconds ago
kernel: 5.4.0-216.236-generic
server check-in: succeeded
kernel state: ✓ kernel series 5.4 is covered by Livepatch
patch state: ✓ all applicable livepatch kernel modules applied
patch version: 113.1

تحمل سطران الإجابة. يوضح kernel state ما إذا كانت سلسلة kernel التي تشغّلها مشمولة بالخدمة أصلاً. وهذا هو السطر الذي تتغير حالته إلى خطأ عند الإقلاع باستخدام kernel لا يدعمه Livepatch. يوضح patch state ما إذا كانت التصحيحات التي تنطبق على ذلك kernel قد حُمّلت فعلياً. إذا كان kernel مشمولاً ولم تُطبَّق عليه تصحيحات، فالمشكلة في العميل. أما إذا كان kernel غير مشمول، فالمشكلة في kernel، ولا يمكن لأي إعداد في العميل إصلاحها.

كيف أعرف ما إذا كانت إعادة التشغيل معلّقة؟

تزيل تقنية Livepatch الحاجة إلى التدخل الطارئ، لذلك لا تعود إعادة التشغيل المعلّقة واضحة. عليك البحث عن مؤشراتها.

ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs

ينشئ مدير الحزم /var/run/reboot-required عندما يحتاج أحد الحزم المثبّتة إلى إعادة تشغيل لتطبيق التغيير، كما أن تثبيت حزمة linux-image جديدة ينشئه دائماً. يسرد ملف .pkgs الحزم التي طلبت ذلك. إذا أعاد الأمر الأول القيمة No such file or directory، فهذا يعني أن أياً من الحزم لم يطلب إعادة التشغيل منذ آخر إقلاع للجهاز. في إصدارات Ubuntu الحالية، يكون /var/run رابطاً رمزياً إلى /run، لذلك يصل كلا المسارين إلى الملف نفسه.

يوجد هذا المؤشر في tmpfs ويُعاد ضبطه عند كل إقلاع، لذلك تحقّق منه مقابل النواة نفسها:

uname -r
dpkg -l 'linux-image-*' | grep ^ii

يعرض uname -r النواة التي تعمل حالياً. ويعرض الأمر الثاني حزم النواة المثبّتة على القرص. إذا وجدت في تلك القائمة حزمة linux-image أحدث من الإصدار الذي يعرضه uname -r، فهذا يعني أن الجهاز يعمل بنواة قديمة، بغض النظر عن حالة Livepatch. هذا هو الفحص المهم، لأن live patching مصمم لجعل النواة العاملة آمنة، لا لجعلها الأحدث.

أما جانب userspace من السؤال نفسه، فتكون needrestart مثبّتة افتراضياً على Ubuntu Server، وتعرض الخدمات العاملة التي لا تزال تحتفظ بملفات مكتبات محذوفة.

sudo needrestart -r l

تعني مجموعة العلمين -r l «العرض فقط»، لذلك تعرض النتائج ولا تغيّر شيئاً.

لماذا لا تختفي الحاجة إلى إعادة التشغيل

لم تتغير نواة النظام الموجودة على القرص. تُحمَّل التصحيحات المباشرة إلى النواة قيد التشغيل، ولا تُكتب مطلقاً في صورة الإقلاع. لذلك، تبدأ بعد إعادة التشغيل باستخدام أي linux-image يختاره محمّل الإقلاع، ثم يعيد عميل Livepatch تطبيق التصحيحات التي لا تزال منطبقة. خلال الفترة بين هاتين اللحظتين، تعمل بشيفرة غير مصححة. وهذا سبب إضافي للإقلاع باستخدام نواة حديثة بدلاً من نواة قديمة.

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

لا تُطبَّق إصلاحات النواة ذات الخطورة المتوسطة والمنخفضة مباشرة. تبقى هذه الإصلاحات في الحزمة الموجودة على القرص، ولا تصل إليك إلا عند الإقلاع.

تراكم النوى التي تعمل لفترات طويلة أيضاً حالة داخلية لا تنظفها عملية التصحيح. ومن المفيد نقل موقف Canonical نفسه، لأنه الموقف الصريح: إن Livepatch «ليس بديلاً عن إعادة التشغيل. بل هو أداة تمنحك تحكماً أكبر من خلال منع عمليات إعادة التشغيل غير المجدولة». والكلمة التي تحمل المعنى هنا هي غير المجدولة. ما زلت تعيد التشغيل، لكنك تختار الوقت.

كيفية جدولة إعادة تشغيل يعود بعدها النظام للعمل

تكون إعادة تشغيل VPS إجراءً باتجاه واحد إذا تعذّر عليك الوصول إلى وحدة التحكم. قبل كتابة reboot، تأكد من قدرتك على الدخول مجدداً إذا لم يعد الجهاز للعمل.

• تأكد من أن مزود الخدمة يتيح وحدة تحكم تسلسلية أو عرض VNC (الحوسبة الشبكية الافتراضية) في لوحة التحكم، وافتحها الآن بدلاً من انتظار حدوث العطل.
• تحقق من المساحة الحرة باستخدام df -h /boot. إذا امتلأ /boot، فقد تفشل حزمة kernel أثناء كتابة initramfs (نظام الملفات الأولي في الذاكرة)، ما قد يترك إدخالاً في محمّل الإقلاع يشير إلى صورة لم يكتمل إنشاؤها.
• أبقِ kernel أقدم واحداً على الأقل، وتأكد من أنه يعمل. يعرضه GRUB ضمن "Advanced options for Ubuntu"، ويُعد تشغيله أسرع وسيلة للتعافي عند فشل kernel جديد.
• تعرّف على وضع الإنقاذ لدى مزود الخدمة قبل أن تحتاج إليه. إذا عرضت وحدة التحكم مطالبة initramfs بعد إعادة التشغيل، فهناك تُجرى عملية الإصلاح.

بعد ذلك، أعد التشغيل في وقت تكون فيه مستيقظاً:

sudo shutdown -r +5 "Kernel update, back in a moment"

تُجدول هذه العملية إعادة التشغيل بعد خمس دقائق، وترسل رسالة إلى المستخدمين المسجّلين الدخول. يلغي sudo shutdown -c هذه العملية. عند عودة الجهاز للعمل، تحقق من الجزأين معاً:

uname -r
sudo canonical-livepatch status

يجب أن يعرض uname -r الآن kernel الأحدث، كما يجب أن يوضح ناتج الحالة أن السلسلة الجديدة مشمولة. إذا لم يعد الجهاز للعمل إطلاقاً، فغالباً ما يكون العطل في مسار الإقلاع لا في الشبكة، ويكون مسار الاسترداد هو الوارد في الدليل الخاص بـVPS الذي لا يقلع بعد تحديث kernel.

لماذا لا يزال تنظيف النوى القديمة ضرورياً

تجعل تقنية التصحيح المباشر هذه المشكلة أسوأ لا أفضل، لأنها تلغي الحاجة الملحّة إلى إعادة التشغيل بينما تستمر حزم linux-image في التثبيت. تثبّت كل نواة صورة إقلاع، وinitramfs، وشجرة modules، وعادةً حزمة headers. على VPS صغير يحتوي على قسم /boot منفصل بسعة بضع مئات من الميغابايت، تملأ ثلاث أو أربع نوى هذا القسم.

يؤدي امتلاء /boot إلى فشل تثبيت النواة التالية، وهكذا ينتهي الأمر بجهاز غير قادر على تثبيت التحديث الذي يحتاج إليه. يزيل مسار apt autoremove النوى القديمة عندما تصبح مؤهلة للإزالة، لكن النوى لا تكون مؤهلة دائماً على جهاز لا يُعاد تشغيله، لأن مدير الحزم لن يتقاعد عن نواة قد تكون قيد التشغيل حالياً.

لذلك تحقّق من النوى المثبّتة، واحتفظ بالنواة قيد التشغيل وبنواة احتياطية واحدة معروفة بأنها سليمة، ثم أزل البقية باستخدام الإجراء الآمن لإزالة النوى القديمة على Ubuntu. لا تزل النواة التي يعرضها uname -r حالياً.

FAQ

هل يعني تصحيح النواة مباشرةً أنني لن أضطر إلى إعادة تشغيل VPS مطلقاً؟

لا. تُحمَّل التصحيحات المباشرة إلى النواة العاملة ولا تُكتب في صورة الإقلاع، لذلك تبقى linux-image الموجودة على القرص عند الإصدار الذي أقلعت به. توضّح Canonical ذلك مباشرةً: إن Livepatch «ليس بديلاً عن إعادة التشغيل، بل أداة تمنحك تحكماً أكبر عبر منع عمليات إعادة التشغيل غير المجدولة». تنتهي التغطية أيضاً عند انتهاء دعم سلسلة النواة، ولا تُطبَّق تصحيحات النواة ذات الخطورة المتوسطة مباشرةً مطلقاً. حدّد جدولاً زمنياً لإعادة التشغيل للصيانة وفق وتيرة تختارها، بدلاً من انتظار فرض إعادة التشغيل عليك.

كيف أتحقق من أن تصحيح النواة مباشرةً يطبّق التصحيحات فعلاً؟

شغّل sudo canonical-livepatch status واقرأ سطرين. يوضّح kernel state ما إذا كانت سلسلة النواة العاملة مشمولة بالخدمة، بينما يوضّح patch state ما إذا كانت تصحيحات تلك النواة محمّلة. يمكنك أيضاً التحقق مباشرةً من جانب النواة باستخدام ls /sys/kernel/livepatch/، الذي يعرض دليلاً واحداً لكل تصحيح محمّل. تعني القائمة الفارغة أنه لا توجد تصحيحات مطبّقة في الذاكرة حالياً، بغض النظر عما يقوله العميل.

هل Ubuntu Pro مجاني على VPS شخصي؟

نعم، ضمن حد موثّق. تنص صياغة Canonical على أن Ubuntu Pro «مجاني للاستخدام الشخصي وسيظل كذلك على ما يصل إلى 5 أجهزة فعلية»، ويرتفع الحد إلى 50 جهازاً لأعضاء Ubuntu Community الرسميين، اعتباراً من August 2026. يتطلب الاستخدام التجاري اشتراكاً مدفوعاً. اربط الجهاز باستخدام sudo pro attach TOKEN مع رمز مميز من صفحة حساب Ubuntu Pro، ثم فعّل الخدمة باستخدام sudo pro enable livepatch.

لماذا لا تزال ثغرة CVE في النواة مدرجة على أنها غير مُصلحة بعد تشغيل Livepatch؟

عادةً يعود ذلك إلى أحد سببين. قد يكون التصحيح أدنى من حد الخطورة، لأن Canonical تطبّق التصحيحات المباشرة على «ثغرات النواة ذات تصنيفات الخطورة الحرجة والعالية وفق Common Vulnerability Scoring System (CVSS) وتصنيفات أولوية Ubuntu»، وتترك بقية التصحيحات للحزمة الموجودة على القرص. أو قد لا يمكن التعبير عن التصحيح كتغيير في جسم دالة، مثلاً عندما يغيّر المشروع الأصلي بنية بيانات، وهو ما لا يستطيع التصحيح المباشر تنفيذه بأمان على كائنات جرى تخصيصها مسبقاً. تُعالج الحالتان بالطريقة نفسها: ثبّت حزمة النواة المحدّثة وأقلع بها.

ما الذي لا يغطيه تصحيح النواة مباشرةً مطلقاً؟

مكوّنات مساحة المستخدم. توضّح Canonical أن Livepatch «لا يصحّح مكتبات مساحة المستخدم مثل OpenSSL أو glibc، لأن ذلك من مسؤولية unattended-upgrades أو أداة لإدارة الأنظمة». ولا يستطيع أيضاً توفير إصدار جديد من النواة أو ميزة جديدة، لأنه يستبدل أجسام الدوال داخل السلسلة التي تشغّلها بالفعل فقط. كما لا يستطيع تصحيح دوال __init، لأنها تكون قد نُفّذت وأُزيلت من الذاكرة بحلول وقت تشغيل الخادم.