วิธีตั้งค่า dnf-automatic อัปเดตความปลอดภัย Rocky/Alma

หน้าที่ของ dnf-automatic บน Rocky Linux และ AlmaLinux

dnf-automatic คือเครื่องมือสำหรับจัดการการอัปเดตความปลอดภัยแบบอัตโนมัติบน Rocky Linux และ AlmaLinux โดยเป็นโปรแกรมขนาดเล็กที่ทำงานผ่าน systemd timer ซึ่งจะอ่านค่าจาก /etc/dnf/automatic.conf และดำเนินการตามที่ไฟล์นั้นอนุญาต การติดตั้งทำได้ด้วยคำสั่งเดียว เนื้อหาที่เหลือในคู่มือนี้จะกล่าวถึงการตั้งค่าที่จะกำหนดว่าเครื่องมือนี้จะช่วยปกป้องเซิร์ฟเวอร์ของคุณหรือเพียงแค่ทำงานผ่านไปโดยไม่เกิดผลใดๆ

หากคุณเคยใช้งาน Debian หรือ Ubuntu เครื่องมือนี้ทำหน้าที่เดียวกับ unattended-upgrades บน Ubuntu VPS โดยมีความแตกต่างที่สำคัญประการหนึ่งคือ ความหมายของคำว่า "security" สำหรับตัวจัดการแพ็กเกจ บน Ubuntu คำนี้หมายถึง archive pocket แยกต่างหาก แต่ในตระกูล RHEL คำนี้คือ metadata ที่แนบมากับประกาศแจ้งเตือน (advisory) ซึ่ง metadata ดังกล่าวอาจขาดหายไปหรือล้าสมัยได้ หากคุณกำหนดให้ dnf-automatic ทำงานกับ repository ที่ไม่มีข้อมูล advisory ระบบจะไม่ติดตั้งสิ่งใดเลยแต่จะรายงานว่าดำเนินการสำเร็จ

คู่มือนี้เขียนขึ้นโดยอ้างอิง Rocky Linux 9 และ AlmaLinux 9 ซึ่งใช้ DNF 4 (DNF เป็นตัวจัดการแพ็กเกจของตระกูล RHEL) ณ เดือนสิงหาคม 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 ถูกเพิ่มเข้ามาใน DNF เวอร์ชัน 4.15 และ Red Hat ได้นำฟีเจอร์นี้มาใส่ใน dnf-4.14.0-6.el9 ในเดือนพฤศจิกายน 2023 ผ่านประกาศ RHBA-2023:6645 ทั้ง Rocky 9 และ AlmaLinux 9 ได้ทำการ build แพ็กเกจนั้นใหม่ ดังนั้นเซิร์ฟเวอร์ที่เป็นปัจจุบันจึงมีฟีเจอร์นี้ ในขณะที่เซิร์ฟเวอร์ที่ไม่ได้อัปเดตเลยตั้งแต่ปี 2023 จะไม่มี

ไฟล์ตั้งค่าคือ /etc/dnf/automatic.conf สำเนาที่มาพร้อมกับแพ็กเกจจะแสดงรายการตัวเลือกทั้งหมดที่ build นี้รองรับ พร้อมค่าเริ่มต้นที่ถูกใส่เครื่องหมายคอมเมนต์ไว้ ให้อ่านไฟล์นั้นหนึ่งรอบก่อนเริ่มแก้ไข เพราะไฟล์ดังกล่าวคือข้อมูลที่ถูกต้องที่สุดสำหรับเวอร์ชันที่คุณใช้งานอยู่

สวิตช์สองตัวที่กำหนดการทำงาน

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 เพื่อดู flag ที่แท้จริงซึ่ง 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 ไม่ได้ระบุว่าการอัปเดตใดเป็นการอัปเดตด้านความปลอดภัยโดยการเปรียบเทียบเลขเวอร์ชัน แต่ DNF จะอ่านข้อมูล metadata ของ errata ซึ่งเป็นไฟล์ที่เรียกว่า updateinfo.xml ที่เผยแพร่อยู่ภายใน repository โดยที่คำแนะนำ (advisory) แต่ละรายการจะระบุรายการแพ็กเกจที่แก้ไขช่องโหว่นั้นๆ AlmaLinux เผยแพร่ข้อมูลนี้ในรูปแบบ ALSA advisories ส่วน Rocky เผยแพร่ในรูปแบบ RLSA ทั้งนี้ upgrade_type = security จะสร้างตัวกรองจาก metadata ดังกล่าวและอัปเกรดเฉพาะแพ็กเกจที่ตรงกับเงื่อนไขเท่านั้น

ผลลัพธ์ที่ตามมามี 2 ประการ ซึ่งมักสร้างความประหลาดใจให้กับผู้ใช้งาน

ประการแรก หากไม่มี metadata ก็จะไม่มีการอัปเดตเกิดขึ้น หาก repository ไม่มีไฟล์ 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 ไม่แสดงผลลัพธ์ใดๆ เลย แสดงว่าอาจไม่มีแพ็กเกจที่รอการอัปเดตซึ่งมี advisory กำกับอยู่ หรือ repository นั้นไม่มีข้อมูล advisory ให้ตรวจสอบ ทั้ง Rocky และ AlmaLinux มีการเผยแพร่ข้อมูลนี้ ดังนั้นบนระบบทั้งสองนี้ รายการที่ว่างเปล่ามักหมายถึงไม่มีการอัปเดตความปลอดภัยจริงๆ แต่สำหรับ CentOS Stream นั้นไม่มีการเผยแพร่ข้อมูลนี้เลย

ประการที่สอง โหมดความปลอดภัยไม่ใช่การเปลี่ยนแปลงเพียงเล็กน้อย dnf-automatic จะเพิ่มตัวกรองความปลอดภัยเข้าไปแล้วจึงรันกระบวนการอัปเกรดตามปกติ ดังนั้นแพ็กเกจที่ระบุใน advisory จะถูกอัปเกรดไปยังเวอร์ชันล่าสุดใน repository และจะดึงแพ็กเกจ dependency ที่เกี่ยวข้องมาด้วย การอัปเกรดแบบจำกัดขั้นตอน (การอัปเกรดไปยังเวอร์ชันที่เก่าที่สุดที่แก้ไขช่องโหว่ได้) จะทำได้โดยการรัน dnf upgrade-minimal --security ด้วยตนเองเท่านั้น ซึ่ง dnf-automatic ไม่มีค่าคอนฟิกสำหรับรองรับการทำงานนี้

มีข้อควรระวังเพิ่มเติมสำหรับ Rocky คือ Rocky สร้าง errata จากข้อมูลของ Red Hat ผ่าน pipeline ของตนเอง ซึ่ง pipeline ดังกล่าวอาจมีความล่าช้า ในเดือนกันยายน 2025 ผู้ใช้งานรายงานว่า updateinfo.xml ของ Rocky 9 BaseOS ไม่มีการอัปเดตตั้งแต่เดือนธันวาคม 2024 ส่งผลให้ --security ขาดข้อมูล advisory ล่าสุดไป ซึ่งทีมงาน Rocky ได้ยืนยันว่าเป็นปัญหาที่ทราบกันดี หากคุณต้องพึ่งพา upgrade_type = security ให้เปรียบเทียบรายการ advisory กับประกาศ RLSA ล่าสุดอยู่เสมอ สำหรับเซิร์ฟเวอร์ที่ให้ความสำคัญกับการครอบคลุมของแพตช์มากกว่าการควบคุมการเปลี่ยนแปลง การใช้ upgrade_type = default ตามกำหนดเวลาที่คุณเลือกเองจะเป็นการตั้งค่าที่ปลอดภัยกว่า

systemd timer ที่ทำหน้าที่รันงานจริง

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

list-timers ควรแสดงผลหนึ่งแถวพร้อมเวลาในคอลัมน์ NEXT ซึ่งเป็นเวลาในอีกประมาณหนึ่งวันข้างหน้า หากตารางว่างเปล่าแสดงว่า timer ยังไม่ได้ถูกเปิดใช้งาน ทำให้ไม่มีงานใดทำงานเลย

timer ที่มาพร้อมกับแพ็กเกจจะทำงานที่ *-*-* 6:00 โดยมี RandomizedDelaySec=60m และ Persistent=true การหน่วงเวลาแบบสุ่ม (random delay) ช่วยกระจายภาระงานของเซิร์ฟเวอร์จำนวนมากในช่วงเวลาหนึ่งชั่วโมง เพื่อไม่ให้ทุกเซิร์ฟเวอร์เข้าถึง 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 เดียวกันนี้ใช้ได้กับงานอื่นที่คุณกำหนดเวลาไว้ ซึ่งครอบคลุมอยู่ใน การเขียน systemd service และ timer unit

ข้อควรระวัง: แพ็กเกจยังมาพร้อมกับ timer อีกสามรายการคือ dnf-automatic-notifyonly.timer, dnf-automatic-download.timer และ dnf-automatic-install.timer แต่ละรายการจะเริ่มโปรแกรมเดียวกันด้วย command-line flag ต่างกัน ซึ่ง flag เหล่านั้นจะไป override ค่า download_updates และ apply_updates จากไฟล์ config ของคุณ หากคุณเปิดใช้งาน timer เหล่านี้ควบคู่ไปกับ dnf-automatic.timer งานจะรันสองครั้งด้วยพฤติกรรมที่ต่างกัน ซึ่งจะดูเหมือนว่าไฟล์ config ของคุณถูกละเลย ให้เปิดใช้งานเพียง 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 (simple mail transfer protocol) ไปยัง 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 ไม่ได้รีสตาร์ทเซอร์วิสของคุณ

การติดตั้งแพ็กเกจเป็นการแทนที่ไฟล์บนดิสก์ กระบวนการที่ทำงานอยู่จะยังคงใช้โค้ดเดิมที่อยู่ในหน่วยความจำ ดังนั้นไลบรารีที่ได้รับการแก้ไขแล้วจะไม่มีผลกับ 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 จะส่งค่า exit status ที่ไม่ใช่ศูนย์ ทั้งในกรณีที่จำเป็นต้องรีบูตและในกรณีที่คำสั่งทำงานล้มเหลว ดังนั้นการดูเพียงค่า exit status อย่างเดียวจึงไม่สามารถแยกแยะสองกรณีนี้ออกจากกันได้ ให้ตรวจสอบจากข้อความที่แสดงผลออกมา

การรีสตาร์ทเซอร์วิสเป็นทางเลือกที่กระทบต่อระบบน้อยกว่าและมักจะเป็นวิธีที่ถูกต้อง ให้รีสตาร์ท SSH daemon จากเซสชัน SSH ที่สองที่เปิดค้างไว้ เพื่อป้องกันไม่ให้คุณถูกล็อกออกจากระบบหากการตั้งค่าผิดพลาด การอัปเดต kernel ใหม่เป็นกรณีเดียวที่ต้องรีบูตเท่านั้น เพราะ kernel ที่กำลังทำงานอยู่ไม่สามารถถูกแทนที่ในขณะที่ระบบยังรันอยู่ได้ หากคุณต้องการคัดแยกการอัปเดตในแต่ละเช้าออกเป็นสองกลุ่มนี้ การอัปเดตใดที่ต้องรีบูตและการอัปเดตใดที่ต้องรีสตาร์ทเซอร์วิส จะช่วยอธิบายวิธีการตรวจสอบผลลัพธ์ทีละแพ็กเกจ

สำหรับคอนเทนเนอร์ถือเป็นกรณีแยกต่างหาก เนื่องจาก dnf-automatic จะแพตช์เฉพาะแพ็กเกจของโฮสต์และไม่แตะต้อง userland ที่รวมอยู่ในอิมเมจ ดังนั้นเครื่องที่รัน Docker Engine บน Rocky Linux หรือ AlmaLinux จึงจำเป็นต้องดึงอิมเมจใหม่และสร้างคอนเทนเนอร์ขึ้นมาใหม่ เพื่อให้การแก้ไขมีผลกับโค้ดที่กำลังให้บริการรับส่งข้อมูลอยู่จริง

Should the box reboot itself?

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

reboot = never is the default. when-changed reboots after any applied update. when-needed reboots only when the check behind needs-restarting -r says a core package was replaced, which is what most single-server owners want, paired with a timer window they picked themselves. The default reboot_command gives logged-in users five minutes of warning through shutdown, and you can widen that.

Settle two things before you turn this on. Every service you depend on has to start at boot on its own, which is the usual gap for a Docker Compose stack that was started by hand. And you need console or rescue access from your provider, because a kernel that does not boot cannot be fixed over SSH. If either is missing, keep reboot = never and reboot yourself after reading the journal.

Rocky, AlmaLinux และ CentOS Stream: ความแตกต่าง

บน Rocky 9 และ AlmaLinux 9 ทุกขั้นตอนข้างต้นเหมือนกันทั้งหมด รวมถึง path ของไฟล์ config และชื่อ unit ทั้งสองระบบมีการเผยแพร่ errata ดังนั้น upgrade_type = security จึงมีข้อมูลให้กรองได้ ปัญหา errata ของ Rocky ที่ค้างอยู่ตามที่กล่าวไปก่อนหน้านี้เป็นเพียงไม่กี่จุดที่พฤติกรรมการใช้งานจริงแตกต่างกัน ดังนั้นหากยังไม่ได้สร้างเซิร์ฟเวอร์ ให้พิจารณาประเด็นนี้ควบคู่ไปกับ คำมั่นสัญญาด้านความเข้ากันได้และการรองรับ CPU รุ่นเก่าที่แยกทั้งสองออกจากกัน

CentOS Stream เป็นข้อยกเว้นและเป็นกรณีที่ชัดเจนมาก repository ของ Stream ไม่มี updateinfo.xml ดังนั้นตัวกรองความปลอดภัยจึงไม่สามารถจับคู่ข้อมูลได้และทุกการรันจะรายงาน No security updates needed บน Stream ให้ใช้ upgrade_type = default และยอมรับว่าคุณจะได้รับทุกการอัปเดต นอกจากนี้ Stream ยังทำงานล้ำหน้ากว่า RHEL ดังนั้นการตั้งค่าดังกล่าวบนเครื่อง Stream จึงมีการเปลี่ยนแปลงบ่อยกว่าบน Rocky หรือ AlmaLinux ความแตกต่างนี้ไม่ใช่ความบังเอิญของการทำแพ็กเกจ แต่เป็นผลจากการตัดสินใจของ Red Hat ในปี 2020 ที่เปลี่ยน CentOS ให้เป็นรุ่นทดสอบแบบ rolling preview ของ RHEL ซึ่งเป็น การตัดสินใจเดียวกันที่ทำให้เกิด Rocky Linux และ 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 เท่านั้น ชุดตัวเลือกมีการเพิ่มขึ้นตั้งแต่คู่มือเหล่านั้นถูกเขียนขึ้น ดังนั้นให้ตรวจสอบไฟล์ที่มีการใส่ comment ไว้บนเครื่องของคุณเอง แทนที่จะเชื่อบทความเก่า

รูปแบบความล้มเหลวและข้อความที่คุณจะพบ

ไม่มีการทำงานใดๆ เกิดขึ้น systemctl list-timers dnf-automatic.timer แสดงตารางว่างเปล่าและ systemctl is-enabled dnf-automatic.timer แสดงผลเป็น disabled แพ็กเกจถูกติดตั้งแล้ว แต่ตัวจับเวลา (timer) ไม่เคยถูกติดตั้ง

งานทำงานแต่ไม่มีการติดตั้งสิ่งใด บันทึก journal ปรากฏข้อความ No security updates needed, but 3 updates available ตัวกรองความปลอดภัยไม่พบรายการที่ตรงกัน อาจเป็นเพราะไม่มีรายการที่รอดำเนินการใดที่มีคำแนะนำ (advisory) หรือเป็นเพราะ repository ไม่ได้เผยแพร่ข้อมูลคำแนะนำใดๆ

การตั้งค่าดูเหมือนถูกเพิกเฉย DNF บันทึกตัวเลือกที่ไม่รู้จักไว้ใน automatic.conf ที่ระดับ debug แล้วจึงใช้ค่าเริ่มต้น ดังนั้นคีย์ที่สะกดผิดจึงไม่มีผลใดๆ และไม่มีการแจ้งเตือนผู้ใช้ หากคุณเขียน apply_update = yes แต่ apply_updates ยังคงเป็น no เครื่องจะดาวน์โหลดไปเรื่อยๆ แต่ไม่เคยติดตั้ง หลังจากแก้ไขไฟล์ใดๆ ให้รัน sudo systemctl start dnf-automatic.service และอ่านจาก journal แทนการเชื่อถือไฟล์โดยตรง

งานทำงานวันละสองครั้ง มีตัวจับเวลาสองตัวที่เปิดใช้งานอยู่ systemctl list-unit-files 'dnf-automatic*' จะแสดงให้เห็นว่าตัวใดบ้าง และตัวที่เกินมานั้นมีการส่ง flag ที่ขัดแย้งกับการตั้งค่าในไฟล์ของคุณ

ไม่มีอีเมลส่งมา อาจเป็นเพราะไม่มีบริการใดรอรับการเชื่อมต่อที่พอร์ต 25 สำหรับตัวส่ง email หรือ send_error_messages ยังคงเป็น no และสิ่งเดียวที่ควรค่าแก่การรายงานคือข้อผิดพลาด

บริการที่แพตช์แล้วยังคงรายงานเวอร์ชันเก่า ไฟล์บนดิสก์เป็นเวอร์ชันใหม่แต่กระบวนการในหน่วยความจำยังเป็นเวอร์ชันเก่า dnf needs-restarting -s จะระบุชื่อบริการที่ต้องรีสตาร์ทใหม่

FAQ

dnf-automatic ติดตั้งเฉพาะอัปเดตด้านความปลอดภัยบน Rocky Linux ใช่หรือไม่?

จะทำเช่นนั้นได้ก็ต่อเมื่อคุณตั้งค่า upgrade_type = security ใน /etc/dnf/automatic.conf และ repository ของคุณต้องมีการเผยแพร่ข้อมูล errata metadata ด้วย ทั้ง Rocky Linux และ AlmaLinux มีการเผยแพร่ข้อมูลนี้ ตัวกรองจึงสามารถจับคู่กับ advisories ได้ ค่าเริ่มต้นที่มากับซอฟต์แวร์คือ upgrade_type = default ซึ่งจะติดตั้งอัปเดตที่มีอยู่ทั้งหมดทันทีที่ apply_updates = yes

ทำไม dnf-automatic ถึงรายงานว่า "No security updates needed, but 3 updates available"?

DNF ตัดสินว่าสิ่งใดคืออัปเดตด้านความปลอดภัยโดยการอ่าน updateinfo.xml จาก repository ซึ่งแต่ละ advisory จะระบุรายการแพ็กเกจที่แก้ไขปัญหานั้นไว้ เมื่อ metadata ดังกล่าวหายไปหรือล้าสมัย ตัวกรองด้านความปลอดภัยจะไม่พบรายการที่ตรงกัน ในขณะที่อัปเดตปกติยังคงค้างอยู่ จึงทำให้เกิดข้อความดังกล่าวขึ้น ซึ่งเป็นเรื่องปกติสำหรับ CentOS Stream ที่ไม่มีการเผยแพร่ errata เลย สำหรับ Rocky หรือ AlmaLinux ให้เปรียบเทียบ dnf updateinfo list --security กับ dnf check-update และตรวจสอบว่า metadata ของคุณเป็นปัจจุบัน

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 ทำหน้าที่เพียงติดตั้งแพ็กเกจแล้วจบการทำงาน มันไม่ได้รีสตาร์ท daemon และจะไม่รายงานสิ่งใดให้คุณเห็นเว้นแต่ emit_via จะระบุ emitter ที่คุณอ่านจริง ให้ตั้งค่า emit_via เป็น stdio เป็นอย่างน้อย เปิดใช้งาน send_error_messages เพื่อให้มีการรายงานความล้มเหลวด้วย และรัน dnf needs-restarting -s หลังจากช่วงเวลาการแพตช์เพื่อค้นหาบริการที่ยังคงรันโค้ดเวอร์ชันเก่าอยู่