تحديثات الأمان التلقائية بـ dnf-automatic على Rocky وAlma

ما الذي يفعله dnf-automatic على Rocky Linux وAlmaLinux

يتيح لك dnf-automatic تثبيت تحديثات الأمان تلقائياً على Rocky Linux وAlmaLinux. وهو برنامج صغير واحد يبدأ بواسطة مؤقت systemd، ويقرأ /etc/dnf/automatic.conf ثم يطبّق ما تسمح به إعدادات ذلك الملف. يتطلب التثبيت أمراً واحداً. ويتناول باقي هذا الدليل الإعدادات التي تحدد ما إذا كان سيحمي الخادم أو لن يفعل شيئاً بصمت.

إذا كنت قادماً من Debian أو Ubuntu، فهذه هي المهمة نفسها التي ينفذها unattended-upgrades على خادم VPS يعمل بـUbuntu. لكن هناك فرقاً أهم من جميع الفروق الأخرى: معنى كلمة "الأمان" لدى مدير الحزم. في Ubuntu، يكون الأمان مستودعاً منفصلاً. أما في عائلة RHEL، فهو بيانات وصفية مرفقة بالتنبيهات المنشورة، وقد تكون هذه البيانات مفقودة أو قديمة. إذا وجّهت dnf-automatic إلى مستودع لا يحتوي على بيانات التنبيهات، فلن يثبّت أي شيء مع الإبلاغ عن نجاح العملية.

كُتب هذا الدليل استناداً إلى Rocky Linux 9 وAlmaLinux 9، اللذين يستخدمان DNF 4، إذ إن DNF هو مدير الحزم في عائلة RHEL، وذلك اعتباراً من August 2026. انتقلت الإصدارات 10 إلى DNF5، وتتغير الأسماء فيها، لذلك خُصص لها قسم مستقل قرب نهاية الدليل. كل أمر أدناه مخصص لتشغيله على خادمك، مع عرض النتيجة المتوقعة بجانبه.

ثبّت dnf-automatic واقرأ ملف الإعداد الذي يأتي معه

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

sudo dnf install -y dnf-automatic
rpm -q dnf dnf-automatic
systemctl is-enabled dnf-automatic.timer

يطبع systemctl is-enabled القيمة disabled عند التثبيت الجديد، لأن تثبيت الحزمة لا يبدأ أي شيء. وهذا هو السبب الأكثر شيوعاً لكون خادم يحتوي على dnf-automatic من دون أن يكون قد طبّق تحديثاً واحداً.

يؤثر إصدار DNF في أحد الخيارات. ظهر الإعداد reboot في DNF 4.15 upstream، وأعاد Red Hat إدراجه في dnf-4.14.0-6.el9 في نوفمبر 2023 عبر التنبيه RHBA-2023:6645. تعيد Rocky 9 وAlmaLinux 9 بناء هذه الحزمة، لذلك يتوفر الإعداد على خادم حالي، لكنه لا يتوفر على خادم لم يُحدَّث منذ 2023.

ملف الإعداد هو /etc/dnf/automatic.conf. تسرد النسخة التي تأتي مع الحزمة كل خيار يفهمه هذا الإصدار، مع وضع قيمته الافتراضية في تعليق. اقرأ الملف مرة واحدة قبل تعديله، لأنه المرجع الفعلي لإصدارك.

المفتاحان اللذان يحددان ما سيحدث

يحددان download_updates وapply_updates في قسم [commands] السلوكَ الفعلي. يكون كلاهما no افتراضياً في EL9 (Enterprise Linux 9، الأساس المشترك لـ Rocky 9 وAlmaLinux 9)، لذلك فإن تفعيل dnf-automatic دون تعديل سيعرض التحديثات المتاحة فقط.

• كلا no: يعرض dnf-automatic التحديثات المتاحة ولا يغيّر شيئاً على الخادم.
• download_updates = yes مع apply_updates = no: تُنزَّل الحزم إلى ذاكرة DNF المؤقتة. يصبح التثبيت سريعاً ولا يحتاج إلى الشبكة، لكن لا يتغير شيء الليلة.
• كلا yes مع upgrade_type = default: يُثبَّت كل تحديث متاح، سواء أكان أمنياً أم لا.
• كلا yes مع upgrade_type = security: تُثبَّت فقط الحزم المذكورة في نشرة أمنية.

نقطة بداية مناسبة لـ VPS متاح للعامة:

[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
random_sleep = 0
network_online_timeout = 60
reboot = never

يحدد network_online_timeout عدد الثواني التي ينتظر خلالها التشغيل شبكة عاملة قبل التوقف، وهذا مهم على خادم أُعيد تشغيله للتو. أما random_sleep فهي طريقة أقدم لتوزيع الحمل بين عدة أجهزة، ويتولى المؤقت هذه المهمة الآن. شغّل systemctl cat dnf-automatic.service لعرض العلامات التي تمررها الخدمة المورَّدة بدقة.

أثبت أن الملف ينفذ ما تتوقعه، من دون الانتظار حتى الساعة 06:00:

sudo systemctl start dnf-automatic.service
sudo journalctl -u dnf-automatic.service -n 50 --no-pager

يعرض السجل ما فحصه التشغيل وما نفذه. يمكنك أيضاً فرض سلوك واحد من سطر الأوامر، ويؤثر ذلك في هذا التشغيل وحده دون تعديل الملف:

sudo dnf-automatic --downloadupdates --no-installupdates

ما الذي يعنيه upgrade_type = security فعلياً على Rocky وAlma

لا يحدد DNF أن التحديث تحديث أمني من خلال مقارنة أرقام الإصدارات. بل يقرأ البيانات الوصفية للتنبيهات: ملفاً يسمى updateinfo.xml منشوراً داخل المستودع، حيث يسرد كل تنبيه الحزم التي تعالج المشكلة. تنشر AlmaLinux هذه التنبيهات بصيغة تنبيهات ALSA، بينما تنشرها Rocky بصيغة RLSA. ينشئ upgrade_type = security مرشحاً من هذه البيانات الوصفية، ثم يحدّث الحزم التي يطابقها فقط.

تترتب على ذلك نتيجتان، وكلتاهما تفاجئان المستخدمين.

أولاً، لا توجد تحديثات من دون بيانات وصفية. إذا لم يتضمن المستودع أي updateinfo.xml، فلن يطابق المرشح شيئاً، وتنتهي العملية بالسطر التالي في السجل:

No security updates needed, but 3 updates available

لن يكون الخادم قد تلقى التصحيحات، ولن يُبلّغ أي فشل. تحقّق من ذلك بنفسك:

dnf updateinfo list --security
dnf check-update

إذا كان dnf check-update يسرد حزم بينما لا يطبع dnf updateinfo list --security أي شيء، فإما ألا تتضمن التحديثات المعلقة أي حزمة لها تنبيه، أو ألا يحتوي المستودع على بيانات تنبيهات يمكن قراءتها. تنشر Rocky وAlmaLinux هذه البيانات، لذلك يكون الفراغ في القائمتين عادةً نتيجة فعلية على هذين النظامين. أما CentOS Stream فلا ينشرها إطلاقاً.

ثانياً، لا يطبّق وضع الأمان تغييراً محدوداً. يضيف dnf-automatic مرشح الأمان، ثم يشغّل مسار الترقية العادي. لذلك تنتقل الحزمة المذكورة في تنبيه إلى أحدث إصدار متاح في المستودع، وتجلب معها تبعياتها. أما التغيير الأصغر، أي الانتقال فقط إلى أقدم إصدار يعالج التنبيه، فيُنفّذ عبر dnf upgrade-minimal --security يدوياً. لا يوفّر dnf-automatic إعداداً لهذا السلوك.

تنطبق ملاحظة إضافية على Rocky. تنشئ Rocky بيانات التنبيهات من بيانات Red Hat عبر مسارها الخاص، وقد تأخر هذا المسار. في سبتمبر 2025، أفاد المستخدمون بأن updateinfo.xml الخاص بـRocky 9 BaseOS لم يتغير منذ ديسمبر 2024، ولذلك كانت --security تفتقد التنبيهات الحديثة. وأكد موظفو Rocky أن هذه مشكلة معروفة. إذا كنت تعتمد على upgrade_type = security، فقارن قائمة التنبيهات بإعلانات RLSA الحديثة من وقت إلى آخر. وعلى خادم تكون فيه شمولية التغطية أهم من ضبط التغييرات، يكون تفعيل upgrade_type = default وفق جدول تختاره أكثر أماناً.

مؤقت systemd الذي يشغّل المهمة فعلياً

sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers dnf-automatic.timer

يجب أن يعرض list-timers صفاً واحداً يحتوي على وقت NEXT يبعد نحو يوم. يعني الجدول الفارغ أن المؤقت غير مفعّل، ولذلك لن تُشغّل المهمة أبداً.

يعمل المؤقت المضمّن في الحزمة عند *-*-* 6:00 باستخدام RandomizedDelaySec=60m وPersistent=true. يوزّع التأخير العشوائي الخوادم على مدار ساعة، حتى لا يصل كل خادم إلى المرآة في الثانية نفسها. يعني Persistent=true أن الجهاز الذي كان متوقفاً عند الساعة 06:00 يشغّل المهمة الفائتة بعد إقلاعه بوقت قصير، بدلاً من تخطي ذلك اليوم.

غيّر الجدول باستخدام drop-in. لا تعدّل الوحدة المضمّنة في الحزمة، لأن ترقية الحزمة تستبدل الملفات الموجودة ضمن /usr/lib/systemd/system.

sudo systemctl edit dnf-automatic.timer

[Timer]
OnCalendar=
OnCalendar=*-*-* 03:30
RandomizedDelaySec=30m

السطر الفارغ OnCalendar= مطلوب. تتراكم قيمة OnCalendar، ولذلك، من دون إعادة التعيين هذه، تحتفظ بإدخال الساعة 06:00 وتضيف إدخالاً ثانياً، فتُشغّل المهمة مرتين يومياً. أكّد النتيجة باستخدام systemctl list-timers dnf-automatic.timer واقرأ العمود NEXT. تنطبق قواعد drop-in نفسها على أي مهمة أخرى تجدولها، كما هو موضح في كتابة وحدات خدمة ومؤقتات systemd.

إليك المشكلة. تتضمن الحزمة ثلاثة مؤقتات إضافية: dnf-automatic-notifyonly.timer وdnf-automatic-download.timer وdnf-automatic-install.timer. يبدأ كل منها البرنامج نفسه باستخدام خيارات سطر الأوامر، وتتجاوز هذه الخيارات download_updates وapply_updates المحددتين في ملف الإعداد. فعّل أحدها إلى جانب dnf-automatic.timer، وستُشغّل المهمة مرتين بسلوكين مختلفين، ما يبدو تماماً كما لو أن ملف الإعداد قد جرى تجاهله. فعّل مؤقتاً واحداً وتحقق:

systemctl list-unit-files 'dnf-automatic*'

متى أعرف أن شيئاً ما تم تثبيته؟

يتحكم emit_via في قسم [emitters] بإعداد التقارير. في systemd، يكتب مُرسِل stdio إلى journal، وهو الخيار الموثوق لأنه لا يحتاج إلى تثبيت أي شيء آخر:

sudo journalctl -u dnf-automatic.service --since -7d --no-pager

يكتب مُرسِل motd التقرير في /etc/motd ويستبدل محتويات ذلك الملف. إذا كنت تحتفظ برسالة تسجيل الدخول فيه، فاترك هذا المُرسِل معطلاً.

يفتح مُرسِل email اتصال SMTP (بروتوكول نقل البريد البسيط) إلى email_host على email_port، وتكون القيم الافتراضية لهما localhost و25. لا يستمع أي شيء إلى هذا المنفذ في VPS جديد، لذلك يُرفض الاتصال ولا تُرسل أي رسالة. شغّل ss -lnt | grep ':25' قبل الاعتماد عليه، وأعد إعداد Postfix للعمل كمرحل للإرسال فقط إذا كان الناتج فارغاً. عندما يعمل البريد، يكون عنوان الرسالة Updates applied on 'web01'.، مع أخذ الاسم من system_name.

بالنسبة إلى أي حالة أخرى، يمرر مُرسِل command التقرير إلى برنامج تملكه عبر الإدخال القياسي:

[emitters]
emit_via = stdio, command
system_name = web01.example.com
send_error_messages = yes

[command]
command_format = /usr/local/bin/notify-ops
stdin_format = {body}

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

لا يعيد dnf-automatic تشغيل خدماتك

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

sudo dnf install -y dnf-plugins-core
dnf needs-restarting -s
dnf needs-restarting -r

تعرض -s خدمات systemd التي تغيّرت ملفاتها بعد بدء تشغيلها. تجيب -r عن سؤال واحد، وتطبع إحدى النتيجتين التاليتين:

Core libraries or services have been updated since boot-up:
  * kernel
Reboot is required to fully utilize these updates.

No core libraries or services have been updated since boot-up.
Reboot should not be necessary.

ليست -r أداة تحليل عميق. فهي تتحقق من قائمة ثابتة من الحزم: kernel، وkernel-core، وkernel-rt، وglibc، وlinux-firmware، وsystemd، وdbus، وdbus-broker، وdbus-daemon، وmicrocode_ctl. إذا ثُبّتت إحداها بعد آخر إقلاع، فستحصل على النتيجة الأولى. أضف أسماء حزمك الخاصة إلى ملف ينتهي بـ.conf ضمن /etc/dnf/plugins/needs-restarting.d/ عندما تحتاج مكونات أخرى على الخادم إلى إعادة تشغيل كي تصبح التغييرات فعّالة.

هناك قيد مهم في البرامج النصية: تُرجع dnf needs-restarting -r قيمة خروج غير صفرية سواء كانت إعادة التشغيل مطلوبة أم فشل الأمر نفسه، لذلك لا تكفي قيمة الخروج وحدها للتمييز بين الحالتين. اقرأ نص المخرجات.

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

هل ينبغي أن يعيد الخادم تشغيل نفسه؟

[commands]
reboot = when-needed
reboot_command = shutdown -r +5 'Rebooting after applying package updates'

يكون reboot = never هو الإعداد الافتراضي. يعيد when-changed التشغيل بعد تطبيق أي تحديث. ولا يعيد when-needed التشغيل إلا عندما يشير الفحص الذي يقف وراء needs-restarting -r إلى استبدال حزمة أساسية، وهذا ما يريده معظم مالكي الخوادم المنفردة، مع تحديد نافذة المؤقت بأنفسهم. يتيح reboot_command الافتراضي للمستخدمين الذين سجّلوا الدخول تحذيراً مدته خمس دقائق عبر shutdown، ويمكنك زيادة هذه المدة.

احسم أمرين قبل تفعيل ذلك. يجب أن تبدأ كل خدمة تعتمد عليها تلقائياً عند الإقلاع. هذه هي الفجوة المعتادة في حزمة Docker Compose التي بدأ تشغيلها يدوياً. وتحتاج أيضاً إلى وصول عبر وحدة التحكم أو وضع الإنقاذ من موفّر الخدمة، لأن النواة التي لا تقلع لا يمكن إصلاحها عبر SSH. إذا كان أي من الأمرين غير متاح، فاترك reboot = never كما هو، وأعد التشغيل يدوياً بعد قراءة السجل.

Rocky وAlmaLinux وCentOS Stream: أوجه الاختلاف بينها

في Rocky 9 وAlmaLinux 9، كل ما سبق متطابق، بما في ذلك مسار الإعدادات وأسماء الوحدات. ينشر كلا النظامين نشرات تصحيح، ولذلك تتوفر لدى upgrade_type = security بيانات يمكن تصفيتها.

يُعد CentOS Stream الاستثناء، وهو استثناء جوهري. لا تحتوي مستودعات Stream على updateinfo.xml، لذلك لا يمكن لمرشح الأمان أن يطابق أي شيء، وتُبلغ كل عملية تشغيل عن No security updates needed. في Stream، استخدم upgrade_type = default وتقبّل أنك تثبّت كل تحديث. يعمل Stream أيضاً بإصدارات أحدث من RHEL، لذلك يطبّق هذا الإعداد تغييرات أكثر على خادم Stream مقارنةً بالإعداد نفسه على Rocky أو AlmaLinux.

انتقل Rocky 10 وAlmaLinux 10 إلى DNF5، الذي أعاد تسمية بعض العناصر. توثيق DNF5 upstream يذكر أن المؤقت هو dnf5-automatic.timer، ويضع الإعدادات الافتراضية المضمّنة مع الحزمة في /usr/share/dnf5/dnf5-plugins/automatic.conf، بينما تبقى تجاوزاتك في /etc/dnf/automatic.conf، ويجعل القيمة الافتراضية لـ download_updates هي yes بدلاً من no، ويضيف distro-sync بوصفه upgrade_type. أما استعلام النشرات فهو dnf advisory list، مع الإبقاء على updateinfo كاسم مستعار. تحقّق مما ثبّته إصدارك فعلياً قبل نسخ أسماء الحزم أو الوحدات من دليل كُتب لـ 9:

dnf list --available '*automatic*'
systemctl list-unit-files '*automatic*'

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

أوضاع الفشل والنصوص التي ستراها

لا يعمل شيء مطلقاً. يعرض systemctl list-timers dnf-automatic.timer جدولاً فارغاً، ويعرض systemctl is-enabled dnf-automatic.timer القيمة disabled. تم تثبيت الحزمة، لكن المؤقت لم يُثبَّت قط.

تعمل المهمة لكنها لا تثبّت شيئاً. يحتوي السجل على No security updates needed, but 3 updates available. لم يطابق مرشح الأمان أي شيء، إما لأن أياً من التحديثات المعلّقة لا يحمل تنبيهاً أمنياً، أو لأن المستودع لا ينشر بيانات التنبيهات الأمنية.

يبدو أن أحد الإعدادات مُهمَل. يسجّل DNF خياراً غير معروف في automatic.conf عند مستوى التصحيح، ثم يستخدم القيمة الافتراضية. لذلك لا يغيّر المفتاح المكتوب خطأً أي شيء ولا يصدر تحذيراً. اكتب apply_update = yes، وستبقى apply_updates بالقيمة no، لذلك سيستمر الخادم في التنزيل ولن يثبّت شيئاً. بعد أي تعديل، شغّل sudo systemctl start dnf-automatic.service واقرأ السجل بدلاً من الوثوق بالملف.

تعمل المهمة مرتين يومياً. هناك مؤقتان مفعّلان. يوضح systemctl list-unit-files 'dnf-automatic*' أيّهما مفعّل، وتمرّر المؤقتات الإضافية خيارات تتغلب على ملف الإعدادات.

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

لا تزال خدمة جرى ترقيعها تعرض الإصدار القديم. الملف الموجود على القرص جديد، لكن العملية الموجودة في الذاكرة قديمة. يحدّد dnf needs-restarting -s الخدمات التي يجب إعادة تشغيلها.

FAQ

هل يثبّت dnf-automatic التحديثات الأمنية فقط على Rocky Linux؟

فقط إذا ضبطت upgrade_type = security في /etc/dnf/automatic.conf، وفقط إذا كانت مستودعاتك تنشر بيانات وصفية للإشعارات الأمنية. ينشر كل من Rocky Linux وAlmaLinux هذه البيانات، لذلك يملك المرشح إشعارات يطابقها. الإعداد الافتراضي المضمّن هو upgrade_type = default، الذي يثبّت كل تحديث متاح عند apply_updates = yes.

لماذا يعرض dnf-automatic الرسالة "لا توجد تحديثات أمنية مطلوبة، لكن تتوفر 3 تحديثات"؟

يحدد DNF التحديث الأمني بقراءة updateinfo.xml من المستودع، حيث يسرد كل إشعار الحزم التي تعالجه. عندما تكون هذه البيانات الوصفية مفقودة أو قديمة، لا يطابق المرشح الأمني أي شيء، بينما تظل التحديثات العادية معلّقة، فتظهر هذه الرسالة تحديداً. هذا متوقع في CentOS Stream، الذي لا ينشر أي بيانات errata. في Rocky أو AlmaLinux، قارن dnf updateinfo list --security مع dnf check-update وتحقق من أن بياناتك الوصفية حديثة.

هل سيعيد dnf-automatic تشغيل الخادم بعد تحديث النواة؟

ليس ما لم تطلب منه ذلك. يكون الخيار reboot مضبوطاً افتراضياً على never. اضبط reboot = when-needed، وعندها تعيد عملية التشغيل النظام فقط عندما يكتشف الفحص الذي ينفذه dnf needs-restarting -r أن حزمة أساسية مثل kernel أو glibc استُبدلت منذ الإقلاع. يعيد reboot = when-changed التشغيل بعد تطبيق أي تحديث. ويستخدم كلا الخيارين reboot_command، الذي يكون مضبوطاً افتراضياً على shutdown -r +5 مع رسالة تحذير للمستخدمين المسجّلين الدخول.

كيف أغيّر وقت تشغيل dnf-automatic؟

شغّل sudo systemctl edit dnf-automatic.timer وأضف قسماً [Timer] يحتوي على سطر OnCalendar= فارغ يتبعه الجدول الزمني، مثل OnCalendar=*-*-* 03:30. السطر الفارغ مطلوب لأن OnCalendar تتراكم، ولذلك يؤدي حذفه إلى الإبقاء على عملية التشغيل المضمّنة عند 06:00 وإضافة عملية ثانية. تحقّق باستخدام systemctl list-timers dnf-automatic.timer واقرأ العمود NEXT.

هل ما زلت بحاجة إلى فحص خادم يثبّت التحديثات تلقائياً؟

نعم. يثبّت dnf-automatic الحزم ثم يتوقف. ولا يعيد تشغيل الخدمات، كما أنه لا يرسل أي شيء ستراه ما لم تسمِّ emit_via جهة إرسال تتابعها فعلياً. اضبط emit_via على stdio كحد أدنى، وفعّل send_error_messages حتى تُبلَّغ عن حالات الفشل أيضاً، وشغّل dnf needs-restarting -s بعد فترة تثبيت التحديثات للعثور على الخدمات التي ما زالت تشغّل شيفرة قديمة.