آموزش نصب و تنظیم dnf-automatic در Rocky و AlmaLinux

عملکرد dnf-automatic در Rocky Linux و AlmaLinux

ابزار dnf-automatic روشی برای دریافت خودکار به‌روزرسانی‌های امنیتی در Rocky Linux و AlmaLinux است. این یک برنامه کوچک است که توسط یک systemd timer اجرا می‌شود، فایل /etc/dnf/automatic.conf را می‌خواند و آنچه را که در آن فایل مجاز دانسته شده است، اعمال می‌کند. نصب آن تنها با یک دستور انجام می‌شود. باقی این راهنما به تنظیماتی می‌پردازد که تعیین می‌کنند آیا این ابزار از سرور شما محافظت می‌کند یا بی‌سروصدا هیچ کاری انجام نمی‌دهد.

اگر از Debian یا Ubuntu آمده‌اید، این ابزار همان وظیفه‌ای را انجام می‌دهد که unattended-upgrades در یک VPS اوبونتو انجام می‌دهد. یک تفاوت بیش از سایر موارد اهمیت دارد: معنای کلمه "security" برای مدیر بسته. در اوبونتو، این یک مخزن (archive pocket) جداگانه است. در خانواده RHEL، این داده‌ها متادیتای پیوست‌شده به توصیه‌های منتشرشده (advisories) هستند و این متادیتا ممکن است ناقص یا قدیمی باشد. اگر dnf-automatic را به مخزنی بدون داده‌های advisory متصل کنید، هیچ‌چیز نصب نمی‌کند و در عین حال وضعیت را موفقیت‌آمیز گزارش می‌دهد.

این راهنما برای Rocky Linux 9 و AlmaLinux 9 نوشته شده است که تا آگوست 2026 از DNF 4 (مدیر بسته در خانواده RHEL) استفاده می‌کنند. نسخه‌های 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 معرفی شد و Red Hat آن را در نوامبر 2023 طی ابلاغیه RHBA-2023:6645 به نسخه dnf-4.14.0-6.el9 بک‌پورت کرد. توزیع‌های Rocky 9 و AlmaLinux 9 این بسته را بازسازی می‌کنند، بنابراین یک سرور به‌روز آن را دارد، اما سروری که از سال 2023 دست‌نخورده باقی مانده، فاقد آن است.

فایل پیکربندی در مسیر /etc/dnf/automatic.conf قرار دارد. نسخه پیش‌فرض این فایل، تمامی گزینه‌هایی که این نسخه از برنامه پشتیبانی می‌کند را به همراه مقادیر پیش‌فرض آن‌ها به‌صورت کامنت‌شده فهرست کرده است. پیش از ویرایش، یک‌بار آن را مطالعه کنید، زیرا این فایل مرجع اصلی برای نسخه نصب‌شده روی سیستم شماست.

دو سوییچی که تعیین‌کننده عملکرد هستند

download_updates و apply_updates در بخش [commands]، رفتار سیستم را تعیین می‌کنند. هر دو در EL9 (نسخه Enterprise Linux 9 که پایه مشترک Rocky 9 و AlmaLinux 9 است) به‌صورت پیش‌فرض no هستند؛ بنابراین اگر dnf-automatic را بدون ویرایش فعال کنید، فقط موجود بودن به‌روزرسانی‌ها را به شما اطلاع می‌دهد.

• هر دو no: ابزار dnf-automatic فقط به‌روزرسانی‌های موجود را گزارش می‌دهد و هیچ تغییری در سیستم ایجاد نمی‌کند.
• download_updates = yes با apply_updates = no: بسته‌ها در کش DNF دانلود می‌شوند. نصب بسته‌ها سریع انجام شده و نیازی به شبکه ندارد، اما در آن لحظه تغییری در سیستم اعمال نمی‌شود.
• هر دو yes با upgrade_type = default: تمام به‌روزرسانی‌های موجود، اعم از امنیتی یا غیرامنیتی، نصب می‌شوند.
• هر دو yes با upgrade_type = security: فقط بسته‌هایی که در یک توصیه امنیتی (security advisory) نام برده شده‌اند، نصب می‌شوند.

یک نقطه شروع منطقی برای یک 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 روشی قدیمی برای توزیع بار بین چندین ماشین است و امروزه این وظیفه بر عهده timer است. دستور 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 برای تشخیص به‌روزرسانی امنیتی، شماره نسخه‌ها را با هم مقایسه نمی‌کند. این ابزار فراداده‌های errata را می‌خواند: فایلی به نام updateinfo.xml که درون مخزن منتشر می‌شود و هر توصیه امنیتی (advisory) در آن، بسته‌هایی را که مشکل را برطرف می‌کنند فهرست کرده است. AlmaLinux این موارد را به عنوان توصیه‌های ALSA و Rocky آن‌ها را به عنوان RLSA منتشر می‌کند. upgrade_type = security یک فیلتر بر اساس آن فراداده می‌سازد و فقط بسته‌هایی را که با آن مطابقت دارند ارتقا می‌دهد.

این موضوع دو پیامد دارد که هر دو برای کاربران غافلگیرکننده هستند.

نخست، نبود فراداده به معنای نبود به‌روزرسانی است. اگر مخزن فاقد updateinfo.xml باشد، فیلتر با هیچ موردی مطابقت پیدا نمی‌کند و عملیات با این خط در journal پایان می‌یابد:

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 داده‌های errata خود را از طریق خط لوله (pipeline) اختصاصی خود از داده‌های 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 اجرا می‌شود. تأخیر تصادفی باعث توزیع بار روی سرورها در طول یک ساعت می‌شود تا همه سرورها در یک ثانیه به mirror متصل نشوند. Persistent=true به این معناست که اگر دستگاهی در ساعت 06:00 خاموش بوده باشد، پس از روشن شدن، عملیات عقب‌افتاده را بلافاصله اجرا می‌کند و آن روز را نادیده نمی‌گیرد.

زمان‌بندی را با استفاده از یک drop-in تغییر دهید. فایل unit اصلی را ویرایش نکنید، زیرا ارتقای بسته، فایل‌های موجود در مسیر /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 برای هر زمان‌بندی دیگری نیز صدق می‌کند که در نوشتن unitهای سرویس و تایمر systemd توضیح داده شده است.

و اما یک نکته انحرافی: این بسته سه تایمر دیگر نیز ارائه می‌دهد: dnf-automatic-notifyonly.timer، dnf-automatic-download.timer و dnf-automatic-install.timer. هر کدام همان برنامه را با flagهای خط فرمان اجرا می‌کنند و آن flagها، تنظیمات 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 می‌نویسد و محتوای آن فایل را جایگزین می‌کند. اگر بنر ورود (login banner) در آنجا دارید، از این فرستنده استفاده نکنید.

فرستنده email یک اتصال SMTP (پروتکل انتقال نامه ساده) به email_host روی email_port برقرار می‌کند که مقادیر پیش‌فرض آن‌ها localhost و 25 هستند. یک VPS تازه هیچ سرویسی در آنجا در حال گوش دادن ندارد، بنابراین اتصال رد می‌شود و ایمیلی ارسال نخواهد شد. پیش از تکیه بر این قابلیت، ss -lnt | grep ':25' را اجرا کنید و اگر خروجی خالی بود، یک Postfix با تنظیمات relay-only راه‌اندازی کنید. هنگامی که ایمیل کار کند، موضوع نامه Updates applied on 'web01'. خواهد بود که نام را از system_name می‌گیرد.

برای هر مورد دیگر، فرستنده command گزارش را از طریق ورودی استاندارد (standard input) به برنامه شما تحویل می‌دهد:

[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 است، به این معنی که اجرای ناموفق هیچ گزارشی ارسال نمی‌کند. آن را فعال کنید. سیستم وصله‌رسانی (patching) که فقط موفقیت‌ها را اعلام می‌کند، از نداشتن سیستم بدتر است، زیرا سکوت به معنای سلامت سیستم تلقی می‌شود.

ابزار dnf-automatic سرویس‌های شما را ری‌استارت نمی‌کند

نصب یک بسته، فایل‌های موجود روی دیسک را جایگزین می‌کند. فرآیندی که در حال اجراست، کد قدیمی را در حافظه نگه می‌دارد؛ بنابراین یک کتابخانه وصله‌شده (patched) برای دیمونی که ماه گذشته اجرا شده، هیچ تأثیری ندارد. این فاصله بین وضعیت «نصب‌شده» و «فعال»، دلیلی است که وصله‌سازی خودکار (unattended patching) علاوه بر سیاست نصب، به سیاست ری‌استارت نیز نیاز دارد.

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 هم در صورت نیاز به ری‌استارت و هم در صورت شکست خودِ دستور، با کد خروجی غیر صفر خارج می‌شود؛ بنابراین وضعیت خروجی (exit status) به تنهایی نمی‌تواند این دو حالت را از هم متمایز کند. متن خروجی را بخوانید.

ری‌استارت کردن یک سرویس، اقدام کوچک‌تری است و معمولاً گزینه درست محسوب می‌شود. دیمون SSH را از یک نشست SSH دوم که از قبل باز است ری‌استارت کنید تا در صورت وجود پیکربندی نادرست، دسترسی شما قطع نشود. هسته (kernel) جدید موردی است که فقط ری‌استارت سیستم به آن کمک می‌کند، زیرا هسته در حال اجرا را نمی‌توان در لحظه جایگزین کرد.

آیا سرور باید به‌طور خودکار reboot شود؟

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

مقدار پیش‌فرض reboot = never است. گزینه when-changed پس از اعمال هرگونه به‌روزرسانی، سیستم را reboot می‌کند. گزینه when-needed تنها زمانی سیستم را reboot می‌کند که بررسیِ پشتِ needs-restarting -r نشان دهد یک بسته اصلی (core package) جایگزین شده است؛ این همان چیزی است که اکثر مدیران تک‌سرور به همراه یک بازه زمانی انتخابی برای اجرا، به آن نیاز دارند. مقدار پیش‌فرض reboot_command به کاربرانِ واردشده (logged-in) از طریق shutdown پنج دقیقه هشدار می‌دهد و شما می‌توانید این زمان را افزایش دهید.

پیش از فعال‌سازی این قابلیت، دو مورد را تعیین تکلیف کنید. هر سرویسی که به آن وابسته‌اید باید به‌طور مستقل در زمان بوت شروع شود؛ این همان خلأ رایج در Docker Compose stack که به‌صورت دستی اجرا شده است می‌باشد. همچنین شما به دسترسی کنسول یا rescue از سمت ارائه‌دهنده سرور خود نیاز دارید، زیرا هسته‌ای (kernel) که بوت نمی‌شود را نمی‌توان از طریق SSH تعمیر کرد. اگر هر یک از این موارد فراهم نیست، reboot = never را حفظ کنید و پس از مطالعه لاگ‌ها در journal، خودتان عملیات reboot را انجام دهید.

تفاوت‌های Rocky، AlmaLinux و CentOS Stream

در Rocky 9 و AlmaLinux 9، تمام موارد ذکر شده در بالا، از جمله مسیر فایل‌های پیکربندی و نام unitها، کاملاً یکسان هستند. هر دو توزیع، errata منتشر می‌کنند، بنابراین 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، تایمر را dnf5-automatic.timer معرفی می‌کند، پیش‌فرض‌های ارائه‌شده را در /usr/share/dnf5/dnf5-plugins/automatic.conf قرار می‌دهد و فایل‌های جایگزین (override) شما همچنان در /etc/dnf/automatic.conf هستند. در این نسخه، مقدار پیش‌فرض download_updates به جای no، روی yes تنظیم شده و distro-sync به عنوان یک upgrade_type اضافه شده است. دستور پرس‌وجوی advisory برابر با dnf advisory list است و updateinfo به عنوان یک alias حفظ شده است. پیش از کپی کردن نام بسته‌ها یا unitها از راهنماهایی که برای نسخه 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) نیست، یا مخزن هیچ داده‌ای برای توصیه‌های امنیتی منتشر نمی‌کند.

به نظر می‌رسد یک تنظیم نادیده گرفته شده است. DNF یک گزینه ناشناخته را در automatic.conf در سطح debug ثبت می‌کند و سپس از مقدار پیش‌فرض استفاده می‌کند؛ بنابراین یک کلید با غلط املایی، تغییری ایجاد نمی‌کند و به کسی هم هشدار نمی‌دهد. اگر apply_update = yes را بنویسید و apply_updates روی no باقی بماند، سیستم برای همیشه دانلود می‌کند و هرگز نصب نمی‌کند. پس از هر ویرایش، sudo systemctl start dnf-automatic.service را اجرا کنید و به‌جای اعتماد به فایل، ژورنال را بخوانید.

جاب دو بار در روز اجرا می‌شود. دو تایمر فعال هستند. دستور systemctl list-unit-files 'dnf-automatic*' نشان می‌دهد کدام‌یک فعال است و تایمرهای اضافی، پرچم‌هایی (flags) را ارسال می‌کنند که تنظیمات فایل پیکربندی شما را نادیده می‌گیرند.

هیچ ایمیلی دریافت نمی‌شود. یا هیچ سرویسی روی پورت 25 برای ارسال‌کننده email گوش نمی‌دهد، یا send_error_messages هنوز روی no تنظیم شده است و تنها چیزی که ارزش گزارش‌دهی داشته، یک خطا بوده است.

سرویس وصله‌شده (patched) همچنان نسخه قدیمی را گزارش می‌دهد. فایل موجود روی دیسک جدید است اما پردازش در حافظه قدیمی است. دستور 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 گزارش می‌دهد "No security updates needed, but 3 updates available"؟

DNF با خواندن updateinfo.xml از مخزن، تشخیص می‌دهد چه چیزی به‌روزرسانی امنیتی محسوب می‌شود؛ جایی که هر advisory بسته‌هایی را که مشکل را رفع می‌کنند، فهرست کرده است. وقتی این متادیتا موجود نباشد یا قدیمی باشد، فیلتر امنیتی هیچ موردی را پیدا نمی‌کند در حالی که به‌روزرسانی‌های عادی در انتظار هستند؛ این دقیقاً همان خروجی را ایجاد می‌کند. این وضعیت در 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 را بخوانید.

آیا همچنان نیاز است سروری که خودش را وصله (patch) می‌کند، بررسی کنم؟

بله. dnf-automatic فقط بسته‌ها را نصب می‌کند و در همان‌جا متوقف می‌شود. این ابزار دیمون‌ها (daemons) را ری‌استارت نمی‌کند و هیچ گزارشی به شما نمی‌دهد، مگر اینکه emit_via یک emitter را نام ببرد که واقعاً آن را می‌خوانید. حداقل emit_via را روی stdio تنظیم کنید، send_error_messages را فعال کنید تا خطاها نیز گزارش شوند و پس از بازه زمانی وصله‌گذاری، dnf needs-restarting -s را اجرا کنید تا سرویس‌هایی که هنوز از کد قدیمی استفاده می‌کنند، شناسایی شوند.