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

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

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

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

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

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

يُعد تفعيل التحديثات التلقائية جزءاً من بقية خطوات الإعداد في الدقائق العشر الأولى على VPS جديد، مباشرة بعد إنشاء مستخدم ليس root وإعداد جدار ناري. إذا لم تكن قد أعددت الجدار الناري بعد، فإن firewalld هو الجدار الناري الذي يأتي مع Rocky وAlmaLinux، وتتيح بضعة أوامر فتح SSH، وفتح المنفذ الذي يستمع عليه موقعك، وجعل هذه الإعدادات تستمر بعد إعادة التشغيل.

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 في upstream ضمن DNF 4.15، ثم أضافته Red Hat إلى dnf-4.14.0-6.el9 في نوفمبر 2023 من خلال advisory 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

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

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. يبدأ كل منها البرنامج نفسه مع flags في سطر الأوامر، وتتجاوز هذه flags قيم 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 تشغيل خدماتك

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

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 عملها برمز خروج غير صفري عندما تكون إعادة التشغيل مطلوبة، وكذلك عندما يفشل الأمر نفسه. لذلك لا يمكن لرمز الخروج وحده التمييز بين الحالتين. اقرأ نص المخرجات.

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

تُعد الحاويات حالة منفصلة، لأن dnf-automatic يصحح حزم المضيف ولا يلمس userland المضمّن في image. لذلك يحتاج الخادم الذي يشغّل Docker Engine على Rocky Linux أو AlmaLinux أيضاً إلى سحب images من جديد وإعادة إنشاء الحاويات قبل أن يصل الإصلاح إلى الشفرة التي تقدّم network traffic فعلياً.

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

[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 التي شُغّلت يدوياً. وتحتاج أيضاً إلى وصول عبر وحدة التحكم أو وضع الإنقاذ من مزود الخدمة، لأن kernel لا يقلع لا يمكن إصلاحه عبر SSH. إذا كان أي من الأمرين غير متاح، فأبقِ ‏reboot = never معطلاً، وأعد التشغيل يدوياً بعد قراءة السجل.

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

في Rocky 9 وAlmaLinux 9، كل ما سبق متطابق، بما في ذلك مسار الإعدادات وأسماء الوحدات. ينشر كلاهما نشرات تصحيح، لذلك يحتوي upgrade_type = security على بيانات يمكن تصفيتها. تُعد نشرات Rocky القديمة الموضحة سابقاً من المواضع القليلة التي يختلف فيها سلوكهما اليومي فعلياً، لذلك إذا لم يُجهَّز الخادم بعد، فضع ذلك في الحسبان إلى جانب وعد التوافق ودعم المعالجات الأقدم اللذين يميزان بينهما.

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

انتقل Rocky 10 وAlmaLinux 10 إلى DNF5، الذي أعاد تسمية بعض العناصر. توضح وثائق DNF5 المصدرية أن المؤقت هو 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. لم يطابق مرشح الأمان أي شيء، إما لأن أياً من التحديثات المعلّقة لا يحمل advisory، أو لأن المستودع لا ينشر بيانات advisory.

يبدو أن إعداداً ما مُهمَل. يسجّل 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، وفقط إذا كانت مستودعاتك تنشر بيانات errata الوصفية. ينشر كل من 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 تشغيل خادمي بعد تحديث kernel؟

لن يفعل ذلك إلا إذا طلبت منه ذلك. يكون الخيار 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 بعد نافذة التحديث للعثور على الخدمات التي ما زالت تشغّل شيفرة قديمة.