วิธีตั้งค่า dnf-automatic บน Rocky Linux และ AlmaLinux

การทำงานของ 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 และตั้งค่า 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 ถูกเพิ่มเข้ามาใน 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: จะติดตั้งเฉพาะแพ็กเกจที่ระบุไว้ในประกาศด้านความปลอดภัยเท่านั้น

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

ประการที่สอง โหมดความปลอดภัยไม่ใช่การเปลี่ยนแปลงขั้นต่ำ dnf-automatic จะเพิ่มตัวกรองความปลอดภัยแล้วจึงดำเนินการตามเส้นทางอัปเกรดปกติ ดังนั้นแพ็กเกจที่ระบุในประกาศจะถูกอัปเกรดไปยังเวอร์ชันล่าสุดใน repository และดึงแพ็กเกจที่เกี่ยวข้อง (dependencies) มาด้วย การอัปเกรดแบบจำกัดขั้นตอน ซึ่งเป็นการขยับไปที่เวอร์ชันแรกสุดที่แก้ไขช่องโหว่นั้นๆ จะทำได้โดยการใช้ 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 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 การหน่วงเวลาแบบสุ่มช่วยกระจายภาระงานของเซิร์ฟเวอร์จำนวนมากในช่วงเวลาหนึ่งชั่วโมง เพื่อไม่ให้ทุกเซิร์ฟเวอร์เข้าถึง 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 units

ข้อควรระวังคือ แพ็กเกจยังมาพร้อมกับ timer อีกสามรายการ ได้แก่ dnf-automatic-notifyonly.timer, dnf-automatic-download.timer และ dnf-automatic-install.timer แต่ละรายการจะเริ่มโปรแกรมเดียวกันด้วย command-line flags ซึ่ง flags เหล่านั้นจะไป 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 ไม่ได้รีสตาร์ทเซอร์วิสของคุณ

การติดตั้งแพ็กเกจเป็นการแทนที่ไฟล์บนดิสก์ กระบวนการที่กำลังทำงานอยู่จะยังคงใช้โค้ดเก่าในหน่วยความจำ ดังนั้นไลบรารีที่ได้รับการแก้ไข (patch) จะไม่มีผลกับ daemon ที่เริ่มทำงานไปเมื่อเดือนที่แล้ว ช่องว่างระหว่างสถานะที่ติดตั้งแล้วกับสถานะที่มีผลจริงคือเหตุผลที่การทำ unattended patching จำเป็นต้องมีนโยบายการรีสตาร์ท ไม่ใช่แค่นโยบายการติดตั้งเพียงอย่างเดียว

sudo dnf install -y dnf-plugins-core
dnf needs-restarting -s
dnf needs-restarting -r

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

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

เซิร์ฟเวอร์ควรทำการรีบูตตัวเองหรือไม่?

[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 จะแจ้งเตือนผู้ใช้ที่ล็อกอินอยู่ล่วงหน้า 5 นาทีผ่านทาง shutdown ซึ่งคุณสามารถขยายระยะเวลาดังกล่าวได้

ควรพิจารณาสองประเด็นก่อนเปิดใช้งานฟังก์ชันนี้ ประการแรก บริการทุกอย่างที่คุณใช้งานต้องตั้งค่าให้เริ่มทำงานเองโดยอัตโนมัติเมื่อบูตเครื่อง ซึ่งมักเป็นปัญหาที่พบได้บ่อยใน Docker Compose stack ที่ถูกสั่งเริ่มทำงานด้วยมือ ประการที่สอง คุณต้องมีสิทธิ์เข้าถึงผ่านคอนโซลหรือโหมดกู้คืน (rescue access) จากผู้ให้บริการของคุณ เนื่องจากเคอร์เนลที่ไม่สามารถบูตได้จะไม่สามารถแก้ไขผ่าน SSH ได้ หากขาดเงื่อนไขข้อใดข้อหนึ่ง ให้คงค่า reboot = never ไว้ และทำการรีบูตด้วยตนเองหลังจากตรวจสอบ log ใน journal แล้ว

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

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

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

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