التحديث التلقائي لخادم أوبنتو

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

يشمل مقالنا ثلاثة أقسام:

أفضل ممارسات إدارة التطبيقات لضمان إعادة تشغيلها بشكل صحيح بعد التحديث
إعدادات الترقية التلقائية للمكتبات والحزم العاملة على الخادم
التحديث والتصحيح المباشر لنواة النظام

متطلبات العمل

نحتاج خادم يعمل بنظام التشغيل أوبونتو، مع مستخدم عادي غير المستخدم الجذر root لكنه يتمتع بصلاحيات عالية sudo لتشغيل الأوامر الإدارية عند الحاجة، ويمكن تجهيز المطلوب باتباع خطوات مقال التهيئة الأولية لخادم أوبونتو.

أفضل ممارسات إدارة التطبيقات

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

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

نظريًّا ينبغي أن تُدار جميع التطبيقات العاملة على الخادم باستخدام نظام التمهيد init system ما أمكن ذلك، و systemd هي أداة التمهيد الرئيسية في أوبنتو وفي معظم توزيعات لينكس الأخرى حيث تتيح التفاعل مع الخدمات العاملة على الخادم وإعادة تشغيلها تلقائيًا حسب الحاجة باستخدام الأمر systemctl، بناءً على ذلك فإن أي برنامج مثبت على الخادم ويعمل في الخلفية سيأتي تلقائيًا مع خدمة systemd لإدارته. بالإضافة إلى ذلك، سينشأ ملف إعدادات خاص يسمى ملف إعدادت الوحدة unit file يحتوي على تعليمات تحدد كيفية تشغيل الخدمة وإيقافها وإدارتها بواسطة systemd.

أما إذا كنا نشغل تطبيقًا خاصًا طورناه بنفسنا أو تطبيقًا ثبَّناه من مستودعات Git لا يتضمن ملف تمهيد للتكامل مع systemd، وسيصعب كتابة الملف يدويًّا ولن تكون نتائجه مضمونة، لذا يلجأ مدراء الأنظمة لاستخدام أدوات خاصة بإدارة التطبيقات مثل مدير العمليات supervisor لتوفير الوقت والجهد والاستغناء عن كتابة ملفات التمهيد يدويًا، كما يمكننا أيضًا استخدام جدولة المهام بواسطة cron مع الصيغة reboot@ لأتمتة العملية.

ويمكن إعادة التشغيل باستخدام الأمر Sudo Shutdown now -r الذي يوقف جميع العمليات العاملة ويعيد تشغيل النظام مباشرةً، كما يمكننا جدولة إعادة التشغيل لتجري في وقت لاحق في ساعة ودقيقة معينة hh:mm بدل إعادة التشغيل الفوري، علمًا أن جميع الخدمات ونقاط الوصول endpoints الضرورية في بيئة الإنتاج ينبغي أن تعود للعمل بعد أي انقطاع طارئ.

بعد أن عرضنا الطرق التي يمكن استخدامها لضمان إعادة تشغيل سليمة لجميع الخدمات أثناء عمليات الصيانة، لننتقل لشرح طريقة جدولة التحديثات التلقائية.

إعدادات الترقية التلقائية

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

يوفر أوبنتو أداة فريدة لتثبيت التصحيحات الأمنية patches والترقيات الأخرى غير المُراقبة التي لا تحتاج إلى تدخل بشري لإنجازها، تسمى unattended-upgrades وهي مثبتة تلقائيًا في معظم خوادم أوبنتو، ويمكن تثبيتها يدويًا باستخدام أوامر apt التالية:

$ sudo apt update
$ sudo apt install unattended-upgrades

يمكن التأكد من عمل الخدمة unattended-upgrades باستخدام systemctl كما يلي:

$ sudo systemctl status unattended-upgrades.service

إذا كانت الخدمة تعمل، سنحصل على خرج يشبه التالي:

unattended-upgrades.service - Unattended Upgrades Shutdown
     Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2022-02-14 17:51:49 UTC; 3h 4min ago
       Docs: man:unattended-upgrade(8)
   Main PID: 829 (unattended-upgr)
      Tasks: 2 (limit: 1137)
     Memory: 10.6M
     CGroup: /system.slice/unattended-upgrades.service

ستعمل الأداة unattended-upgrades بإعداداتها الافتراضية على تثبيت كافة الإصلاحات والتحديثات المتوفرة للحزم التابعة لمستودعات أوبنتو، أما إذا كنا نستخدم إصدارات أقدم من بعض الحزم وأردنا تجنب التعديلات على المستودع الأولي upstream changes أو كان خادمنا يستخدم مستودعات طرف ثالث تتبع لجهات خارجية إلى جانب مستودعات أوبنتو فسنحتاج عندها لتعديل إعدادات unattended-upgrades الافتراضية وضبطها بطريقة مختلفة.

تُخَزَّن إعدادات هذه الأداة في الملف ‎/etc/apt/apt.conf.d/50unattended-upgrades ويمكننا فتحه وتحريره بواسطة أي محرر نصوص مثل نانو nano أو غيره كما يلي:

$ sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

بمجرد فتح الملف، سنلاحظ أنه سهل القراءة ومشروح جيدًا، ويتضمن مجموعة من التعليقات التي تشرح التعليمات البرمجية ووظائفها، تتضمن كتلة التعليمات الأولى في الملف أسماء الحزم التي ستُحَدِّثها الأداة تلقائيًا ولها القالب العام لأسماء مستودعات حزم أوبنتو، وهي افتراضيًا ملفات المستودع المركزي core repository وملفات مستودع الحماية security-، أما مستودعات updates- و proposition- و backports- فتحديثها مُعطّل افتراضيًا ويُترك للمستخدم حرية تفعيلها من عدمه، لأنها قد تتضمن تعديلات جذرية على حزم النظام لذا نجد أن أسطرها تبدأ برمز التعليق //، ويمكن إزالته إن رغبتنا بتفعيل التحديثات التلقائية لها.

إذا تابعنا تصفح الملف، سنجد عددًا من الأسطر التي يمكن التحكم بخياراتها باستخدام true أو false، على سبيل المثال يوجد خيار خاص بتفعيل إعادة التشغيل التلقائية بعد تثبيت الحزم التي تتطلب إعادة تشغيل كي تتفعل وتدخل حيز التنفيذ، يمكن تفعيل هذا الخيار بإزالة رمز التعليق // وتبديل القيمة false إلى true، لكن اتخاذ قرار كهذا سيعرضنا لانقطاعات غير متوقعة في الخدمة نتيجة إعادة التشغيل وينبغي أن تكون طبيعة تطبيقاتنا قادرة على تحمل التبعات الناتجة عن ذلك.

// Automatically reboot *WITHOUT CONFIRMATION* if
//  the file /var/run/reboot-required is found after the upgrade
//Unattended-Upgrade::Automatic-Reboot "false";

بعد الانتهاء من إجراء التعديلات، نحفظ التغييرات على الملف ونغلقه بالخطوات التي تناسب محرر النصوص المستخدم ففي nano مثلًا نضغط على Ctrl+X ثم Y وبعدها Enter.

والآن نعيد تشغيل الخدمة unattended-upgrades وفق الأمر التالي لتصبح التعديلات سارية المفعول:

$ sudo systemctl restart unattended-upgrades.service

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

التحديث والتصحيح المباشر لنواة النظام

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

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

أما إذا كنا لا نمانع بإجرائها تلقائيًا مع ما يترتب عليها من فترات انقطاع في الخدمة، فيمكننا ضبط ذلك في إعدادات التحديثات غير المُراقبة unattended updates بواسطة apt ليجري تحديث نواة النظام وتثبيت إصدارتها الجديدة مع بقية الحزم، وسيستخدم خادمنا النواة الجديدة المُحَدَّثة تلقائيًا بعد إعادة التشغيل، لكن عادةً ما يلجأ مديرو النظام في بيئات التشغيل الحقيقية لأساليب تضمن استمرارية تقديم الخدمة للعملاء مثل استخدام موازن حمل يوجه حركة مرور البيانات إلى الخوادم البديلة أثناء إعادة تشغيل الخادم الذي يُحَدِّث نواته، وتكرار العملية مع بقية الخوادم بالترتيب ليكتمل تحديث المجموعة كلها دون أن يشعر المستخدم بالانقطاع.

تفعيل التصحيح المباشر Livepatch لإبقاء الخادم يعمل عند تحديث النواة

يوفر نظام لينكس ميزة مفيدة تدعى التصحيح المباشر live patching تسمح لنا بتحديث النواة kernel دون إعادة التشغيل، ويُشرف على التصحيحات المباشرة -وفق هذه الميزة- أداتان أساسيتان هما:

Canonical الخاصة بأنظمة أوبنتو حصرًا
KernelCare التي تدعم معظم توزيعات لينكس الشهيرة إلى جانب أوبنتو

علمًا أننا نحتاج لتسجيل حساب على موقع كلتا الأداتين لاستخدامهما، وتوفر Canonical إمكانية التسجيل والاستخدام المجاني للأفراد.

يمكن تسجيل الدخول إلى Canonical والحصول على مفتاح خاص بالتصحيح المباشرة من هذا الرابط، ويمكننا بعدها تثبيت الحزمة canonical-livepatch بواسطة snap -وهو مدير حزم آخر يعمل إلى جانب apt في أنظمة أوبنتو- كما يلي:

$ sudo snap install canonical-livepatch

ثم نكتب الأمر التالي لتفعيل الحزمة canonical-livepatch، ولا ننسى استبدال your-key بمفتاحنا الخاص الذي حصلنا عليه من موقع Canonical:

$ sudo canonical-livepatch enable your-key

بعد التنفيذ ستظهر رسالة واضحة تعلمنا بنجاح تثبيت الخدمة Successfully enabled device وبذلك ستصبح canonical-livepatch خدمة عاملة على نظامنا، وستعمل في الخلفية ويمكن التأكد من ذلك بالاستعلام عن حالتها بواسطة canonical-livepatch status كما يلي:

$ sudo canonical-livepatch status

سنحصل على خرج يشبه التالي:

last check: 50 seconds ago
kernel: 5.15.0-25-generic
server check-in: succeeded
patch state: ✓ all applicable livepatch modules inserted
patch version: 84.1
tier: updates (Free usage; This machine beta tests new patches.)
machine id: 2565a9e7fc9f4405a167e4caf9b9dcf3

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

الخلاصة

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

ترجمة -وبتصرف- لمقال How to Keep Ubuntu 22.04 Servers Updated لصاحبه Alex Garnett.