הגדרת עדכוני אבטחה אוטומטיים ב-Rocky ו-AlmaLinux

מה עושה dnf-automatic ב-Rocky Linux וב-AlmaLinux

הכלי dnf-automatic הוא הדרך לבצע עדכוני אבטחה אוטומטיים ב-Rocky Linux וב-AlmaLinux. זוהי תוכנית קטנה, המופעלת על ידי systemd timer, הקוראת את /etc/dnf/automatic.conf ומיישמת את מה שקובץ זה מתיר. ההתקנה מתבצעת באמצעות פקודה אחת. שאר המדריך עוסק בהגדרות הקובעות אם הכלי יגן על השרת או יפעל בשקט מבלי לבצע דבר.

אם הגעתם מ-Debian או מ-Ubuntu, מדובר באותו תפקיד ש-unattended-upgrades מבצע ב-VPS מבוסס Ubuntu. הבדל אחד חשוב יותר מכל השאר: המשמעות של המילה "security" עבור מנהל החבילות. ב-Ubuntu מדובר במאגר נפרד. במשפחת RHEL מדובר במטא-דאטה המצורף לעדכונים מפורסמים (advisories), ומטא-דאטה זה עלול להיות חסר או לא מעודכן. אם תפנו את dnf-automatic למאגר ללא נתוני advisory, הוא לא יתקין דבר וידווח על הצלחה.

מדריך זה נכתב עבור Rocky Linux 9 ו-AlmaLinux 9, המשתמשות ב-DNF 4 (מנהל החבילות במשפחת RHEL), נכון לאוגוסט 2026. גרסאות 10 עברו ל-DNF5 ושמות הקבצים שם השתנו, לכן הן קיבלו סעיף נפרד לקראת הסוף. כל פקודה להלן מיועדת להרצה בשרת שלכם, כאשר הפלט הצפוי מופיע לצדה.

התקנת dnf-automatic וקריאת קובץ התצורה המצורף

הפעלת עדכונים אוטומטיים צריכה להתבצע כחלק מהגדרת השרת הראשונית, כפי שמתואר ב-עשר הדקות הראשונות בשרת VPS חדש, מיד לאחר יצירת משתמש שאינו root והגדרת ה-firewall.

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 ביצעה לה backport לתוך 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 היא דרך ישנה יותר לפיזור עומסים בין שרתים רבים, כיום ה-timer מבצע את התפקיד הזה. הריצו את systemctl cat dnf-automatic.service כדי לראות את ה-flags המדויקים שמועברים לשירות המותקן.

ודאו שהקובץ מבצע את הפעולה הרצויה, מבלי להמתין לשעה 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 לא קובע אם עדכון הוא עדכון אבטחה על ידי השוואת מספרי גרסאות. הוא קורא מטא-נתונים של errata: קובץ בשם updateinfo.xml שמתפרסם בתוך המאגר (repository), שבו כל התראה (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 שלה מנתוני Red Hat דרך צינור עיבוד (pipeline) משלה, וצינור זה נוטה להשתרך מאחור. בספטמבר 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 חלים על כל משימה אחרת שתתזמנו, נושא המכוסה ב-כתיבת יחידות service ו-timer ב-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, ה־emitter מסוג stdio כותב ליומן (journal), וזו האפשרות האמינה ביותר כיוון שהיא אינה דורשת התקנה של רכיבים נוספים:

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

ה־emitter מסוג motd כותב את הדו"ח לתוך /etc/motd ומחליף את תוכן הקובץ. אם אתם משתמשים שם בבאנר התחברות (login banner), אל תשתמשו ב־emitter זה.

ה־emitter מסוג email פותח חיבור SMTP (פרוטוקול העברת דואר פשוט) אל email_host בפורט email_port, שערכי ברירת המחדל שלהם הם localhost ו-25. בשרת VPS חדש אין שירות שמאזין בפורט זה, לכן החיבור נדחה ולא נשלח דואר. הריצו את ss -lnt | grep ':25' לפני שתסתמכו על אפשרות זו, והגדירו Postfix במצב relay-only אם הפלט נותר ריק. כאשר הדואר עובד, נושא ההודעה יהיה Updates applied on 'web01'., והוא ימשוך את השם מתוך system_name.

עבור כל צורך אחר, ה־emitter מסוג 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 אינו מבצע הפעלה מחדש לשירותים שלכם

התקנת חבילה מחליפה קבצים על הדיסק. תהליך שכבר רץ שומר את הקוד הישן בזיכרון, לכן ספרייה שעברה תיקון (patch) לא תשפיע על 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 מסיים עם קוד יציאה שאינו אפס גם כאשר נדרש אתחול וגם כאשר הפקודה עצמה נכשלה, לכן לא ניתן להבחין ביניהם על סמך קוד היציאה בלבד. קראו את טקסט הפלט.

הפעלה מחדש של שירות היא הצעד המצומצם יותר ובדרך כלל הנכון. הפעילו מחדש את ה-SSH daemon מתוך סשן 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 stack that was started by hand. כמו כן, עליכם לוודא שיש לכם גישת קונסולה או גישת הצלה (rescue) מהספק שלכם, כיוון שלא ניתן לתקן ליבה שאינה עולה דרך SSH. אם אחד מהתנאים הללו חסר, השאירו את reboot = never ובצעו אתחול בעצמכם לאחר קריאת ה-journal.

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, לכן הגדרות מסוימות משתנות בה בתדירות גבוהה יותר מאשר ב-Rocky או ב-AlmaLinux.

Rocky 10 ו-AlmaLinux 10 עברו ל-DNF5, מה שמשנה את שמות הרכיבים. התיעוד הרשמי של DNF5 מציין את ה-timer כ-dnf5-automatic.timer, מציב את ברירות המחדל של התוכנה ב-/usr/share/dnf5/dnf5-plugins/automatic.conf כאשר הדריסות שלכם נשמרות ב-/etc/dnf/automatic.conf, מגדיר את download_updates כ-yes כברירת מחדל במקום no, ומוסיף את 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. החבילה הותקנה, אך ה־timer מעולם לא הופעל.

המשימה רצה אך לא מתקינה דבר. ה־journal מכיל את No security updates needed, but 3 updates available. מסנן האבטחה לא מצא התאמות, כיוון שאין עדכונים ממתינים עם המלצות אבטחה, או כיוון שהמאגר אינו מפרסם נתוני אבטחה.

הגדרה נראית כאילו היא מתעלמת מהשינוי. DNF מתעד אפשרות לא מוכרת ב־automatic.conf ברמת debug ומשתמש בערך ברירת המחדל; לכן, מפתח עם שגיאת כתיב לא משנה דבר ולא מציג אזהרה לאיש. כתבו apply_update = yes ו־apply_updates נשאר על no, כך שהשרת מוריד נתונים לנצח אך לא מתקין דבר. לאחר כל עריכה, הריצו את sudo systemctl start dnf-automatic.service וקראו את ה־journal במקום להסתמך על הקובץ.

המשימה רצה פעמיים ביום. שני timers מופעלים. systemctl list-unit-files 'dnf-automatic*' מציג אילו מהם פעילים, והנוספים מעבירים דגלים (flags) שגוברים על קובץ התצורה שלכם.

לא מגיע דואר. או שאין שירות המאזין בפורט 25 עבור ה־emitter של 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 מדווח "No security updates needed, but 3 updates available"?

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 מתקין חבילות ועוצר שם. הוא אינו מבצע הפעלה מחדש לשירותים (daemons), והוא לא מדווח על דבר שתראו אלא אם emit_via מציין מפיץ הודעות שאתם באמת קוראים. הגדירו את emit_via ל-stdio לכל הפחות, הפעילו את send_error_messages כדי שגם כשלים ידווחו, והריצו את dnf needs-restarting -s לאחר חלון עדכונים כדי למצוא שירותים שעדיין מריצים קוד ישן.