تنظیم آپدیت امنیتی خودکار dnf-automatic در Rocky و Alma

عملکرد 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 و تنظیم فایروال انجام شود. اگر هنوز فایروال را تنظیم نکرده‌اید، firewalld همان ابزاری است که Rocky و AlmaLinux به‌صورت پیش‌فرض ارائه می‌دهند؛ با چند دستور ساده می‌توانید SSH و پورت سرویس خود را باز کرده و تنظیمات را برای پس از reboot نیز پایدار کنید.

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: فقط بسته‌هایی که در توصیه‌نامه‌های امنیتی ذکر شده‌اند، نصب می‌شوند.

یک نقطه شروع منطقی برای یک 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 باشد، فیلتر با هیچ موردی مطابقت پیدا نمی‌کند و عملیات با این خط در لاگ به پایان می‌رسد:

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

ابزار 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) جدید موردی است که فقط با ری‌استارت سیستم اصلاح می‌شود، زیرا هسته در حال اجرا را نمی‌توان در لحظه جایگزین کرد. اگر می‌خواهید به‌روزرسانی‌های یک صبح خاص را در این دو دسته طبقه‌بندی کنید، کدام به‌روزرسانی‌ها نیاز به ری‌استارت دارند و کدام فقط نیاز به ری‌استارت سرویس دارند خروجی را بسته به بسته بررسی می‌کند.

کانتینرها مورد متفاوتی هستند، زیرا dnf-automatic بسته‌های میزبان (host) را وصله می‌کند و هرگز به فضای کاربری (userland) که در یک ایمیج تعبیه شده دست نمی‌زند؛ بنابراین سیستمی که Docker Engine روی Rocky Linux یا AlmaLinux اجرا می‌کند، برای اینکه اصلاحات به کدی که در حال سرویس‌دهی به ترافیک است برسد، نیاز دارد که ایمیج‌هایش دوباره pull شده و کانتینرهایش بازسازی شوند.

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

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

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

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

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

در Rocky 9 و AlmaLinux 9، تمام موارد ذکر شده در بالا، از مسیر فایل‌های پیکربندی گرفته تا نام unitها، کاملاً یکسان هستند. هر دو توزیع، errata منتشر می‌کنند، بنابراین upgrade_type = security داده‌هایی برای فیلتر کردن در اختیار دارد. errata قدیمی Rocky که پیش‌تر توصیف شد، یکی از معدود مواردی است که رفتار روزمره آن‌ها را متمایز می‌کند؛ بنابراین اگر سرور هنوز راه‌اندازی نشده است، این موضوع را در کنار تعهد به سازگاری و پشتیبانی از پردازنده‌های قدیمی که این دو را از هم جدا می‌کند در نظر بگیرید.

CentOS Stream یک استثنا است و این استثنایی جدی محسوب می‌شود. مخازن Stream فاقد updateinfo.xml هستند، بنابراین فیلتر امنیتی هرگز مطابقت پیدا نمی‌کند و هر اجرا وضعیت No security updates needed را گزارش می‌دهد. در Stream، از upgrade_type = default استفاده کنید و بپذیرید که تمام به‌روزرسانی‌ها را دریافت خواهید کرد. همچنین Stream جلوتر از RHEL حرکت می‌کند، بنابراین تنظیمات در یک سرور Stream نسبت به همان تنظیمات در Rocky یا AlmaLinux تغییرات بیشتری دارند. این تفاوت ناشی از بسته‌بندی نیست، بلکه نتیجه تصمیم سال 2020 شرکت Red Hat برای تبدیل CentOS به یک پیش‌نمایش غلتان (rolling preview) از RHEL است؛ همان تصمیمی که باعث پیدایش Rocky Linux و 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 را بخوانید.

آیا همچنان باید سروری که خودش را پچ می‌کند بررسی کنم؟

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