تحديثات Ubuntu التلقائية: unattended-upgrades

لماذا يستحق إعداد التحديثات الأمنية التلقائية العناء

الخادم الذي لا تُثبَّت عليه التصحيحات هو أسهل هدف على الإنترنت كله. معظم اختراقات الخوادم الصغيرة لا تتطلب مهارة تُذكر؛ فهي في الغالب استغلال لثغرة معروفة في حزمة قديمة لم يحدّثها صاحبها قط. يوفّر Ubuntu أداة تسدّ هذه الفجوة من تلقاء نفسها: يثبّت unattended-upgrades التحديثات الأمنية تلقائيًا، وفق جدول زمني، دون أن تسجّل الدخول. إنها أرخص مكسب أمني متاح على خادم VPS، وعلى Ubuntu لا يتطلب إعدادها سوى دقائق معدودة.

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

الخطوة 1: ثبّته وفعّله

على Ubuntu 24.04 غالبًا ما تكون الحزمة موجودة مسبقًا لكنها ليست مفعّلة دائمًا. ثبّتها وفعّلها:

sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

تطرح مطالبة dpkg-reconfigure سؤالًا واحدًا بنعم أو لا، وهو ما إذا كان ينبغي تنزيل التحديثات المستقرة وتثبيتها تلقائيًا. أجب بنعم. هذا يكتب الملف الذي يفعّل المهمة اليومية:

cat /etc/apt/apt.conf.d/20auto-upgrades

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

السطر الأول يحدّث قائمة الحزم يوميًا؛ والثاني يشغّل التحديث التلقائي يوميًا. وضبط كليهما على 1 يعني أن الجهاز يتحقق من التحديثات الأمنية ويطبّقها كل يوم، عبر مؤقت systemd، دون أي إجراء إضافي منك.

الخطوة 2: قرر ما يُطبَّق تلقائيًا

تقع السياسة في الملف /etc/apt/apt.conf.d/50unattended-upgrades. افتحه وانظر إلى كتلة Allowed-Origins قرب بدايته:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}";
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
};

الأسطر المنتهية بـ -security هي التي تهمّ، وهي مفعّلة افتراضيًا. هذه هي السياسة المتحفظة: التحديثات الأمنية تُطبَّق، بينما تُترك تحديثات الميزات العادية لك لتطبّقها يدويًا حين تختار. يمكنك إضافة سطر المصدر "${distro_id}:${distro_codename}-updates" لتطبيق كل التحديثات تلقائيًا، لكن بالنسبة لخادم يستضيف ما يهمّك، فإن الاكتفاء بتطبيق التصحيحات الأمنية تلقائيًا هو الخيار الافتراضي الأكثر أمانًا. اتركه على حاله الافتراضية ما لم يكن لديك سبب محدد لغير ذلك.

الخطوة 3: تعامل مع إعادة التشغيل

بعض التحديثات، كالنواة (kernel) أو مكتبة أساسية، لا يكتمل مفعولها إلا بعد إعادة التشغيل. لن يعيد unattended-upgrades تشغيل خادمك ما لم تطلب منه ذلك، ما يعني أن نواة مصحَّحة قد تبقى دون استخدام إلى أن تعيد التشغيل بنفسك يومًا ما. قرر كيف تريد التعامل مع هذا، واضبطه صراحةً في 50unattended-upgrades:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

هذا يعيد تشغيل الخادم الساعة الرابعة فجرًا، عندما يستوجب تحديثٌ ذلك، ولا يحدث في غير هذه الحالة. على خادم VPS منفرد لا يوجد فيه تجمّع (cluster) للتحويل إليه، تكون إعادة التشغيل القصيرة في الصباح الباكر عادةً المقايضة الصحيحة للبقاء محدَّثًا مع تصحيحات النواة. أما إذا كان خادمك يشغّل شيئًا يجب ألا يعيد التشغيل بشكل غير متوقع أبدًا، فاترك إعادة التشغيل معطّلة، واجعل من عادتك أن تعيد التشغيل بنفسك بعد التحقق من /var/run/reboot-required.

الخطوة 4: تحقق من أنه يعمل

لا تنتظر يومًا كاملًا لتعرف هل تعمل المهمة أم لا. شغّل تشغيلًا تجريبيًا (dry run) يُظهر بالضبط ما الذي سيُطبَّق، دون أن يُغيّر شيئًا:

sudo unattended-upgrade --dry-run --debug

يسرد الناتج الحزم التي يأخذها في الاعتبار والمصادر التي تأتي منها، بحيث ترى السياسة وهي تعمل فعليًا. وبعد أن تعمل المهمة الحقيقية مرة واحدة على الأقل، يوجد سجلّها هنا:

cat /var/log/unattended-upgrades/unattended-upgrades.log

ذلك السجلّ هو الجواب عن السؤال: «هل يُحدِّث خادمي نفسه فعلًا؟». فإن كان يُظهر تثبيت حزم أمنية وفق جدول زمني، فالمهمة تعمل.

أين يقع هذا ضمن الصورة الأكبر

التحديثات التلقائية طبقة واحدة من طبقات الخادم المحصَّن، لا الحل كله. فهي تمنع الأخطاء المعروفة من البقاء دون تصحيح، لكنها لا تفعل شيئًا حيال من يستطيع تسجيل الدخول أو ما هو مكشوف. اقرنها بـتحصين SSH بالمفاتيح فقط حتى لا يُخترق الباب الأمامي بالقوة الغاشمة، وبـجدار حماية UFW يرفض كل شيء افتراضيًا بحيث لا يصل إلا ما تختاره أنت، وبـمستخدمي خدمة محدودي الصلاحيات حتى لا يتمكن تطبيق مخترَق من الاستيلاء على الجهاز كله. التحديث يسدّ الثغرات التي تعرفها؛ أما الطبقات الأخرى فتحدّ من الضرر الناتج عمّا لا تعرفه.

FAQ

هل يطبّق unattended-upgrades كل التحديثات أم التحديثات الأمنية فقط؟

بحسب الإعداد الافتراضي، التحديثات الأمنية فقط. تفعّل كتلة Allowed-Origins في /etc/apt/apt.conf.d/50unattended-upgrades مصادر -security، وتترك تحديثات الميزات العادية لك لتطبّقها يدويًا. هذا أمر مقصود: فالتصحيحات الأمنية منخفضة المخاطر وتستحق أن تُطبَّق تلقائيًا، بينما تحديثات الميزات قد تغيّر السلوك، لذا ينبغي لمعظم الخوادم الإبقاء على الإعداد الافتراضي المتحفظ.

هل ستعيد التحديثات التلقائية تشغيل خادمي؟

فقط إن طلبت منها ذلك. اضبط Unattended-Upgrade::Automatic-Reboot "true" وقيمة Automatic-Reboot-Time في الإعدادات، فيعيد الخادم تشغيل نفسه في ذلك الوقت متى استوجب تحديثٌ ذلك، كما بعد تصحيح النواة مثلًا. وإن تُرك معطّلًا، تنتظر النواة المصحَّحة حتى تعيد التشغيل بنفسك؛ تحقق من /var/run/reboot-required لمعرفة متى تكون إعادة التشغيل معلّقة.

كيف أتحقق من أن التحديثات التلقائية تعمل بالفعل؟

نفّذ sudo unattended-upgrade --dry-run --debug لترى ما سيُطبَّق الآن دون أن يتغيّر شيء، واقرأ /var/log/unattended-upgrades/unattended-upgrades.log لسجلّ التشغيلات السابقة؛ وتُسجَّل كل عملية تثبيت تلقائية أيضًا في /var/log/apt/history.log. فإن أظهر السجلّ تثبيت حزم أمنية وفق جدول يومي، فالمؤقت يعمل. وإن طبع التشغيل التجريبي No packages found that can be upgraded unattended، فإما أن كل شيء محدَّث بالفعل أو أن مصادرك المسموح بها أضيق من أن تطابق مستودع الأمان.

هل يكفي unattended-upgrades لإبقاء خادمي آمنًا؟

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