เทียบคำสั่ง apt และ dnf สำหรับ Rocky Linux และ Fedora

คำตอบโดยย่อ

การเปลี่ยนจาก apt ไปใช้ dnf ส่วนใหญ่เป็นการเปลี่ยนคำสั่งที่ใช้ apt install nginx จะกลายเป็น dnf install nginx ส่วน apt remove nginx จะกลายเป็น dnf remove nginx สำหรับ apt update นั้นไม่มีคำสั่งที่เทียบเท่าโดยตรง เนื่องจาก dnf จะรีเฟรช metadata ของ repository ให้โดยอัตโนมัติเมื่อข้อมูลในแคชเก่าเกินไป การเรียนรู้คำสั่งพื้นฐานเหล่านี้ใช้เวลาเพียงครู่เดียว แต่ส่วนที่มีประโยชน์จริงคือการเรียนรู้ 4 การทำงานที่ไม่มีคำสั่งเทียบเท่ากันเลย ได้แก่ การเพิ่ม repository, การย้อนกลับรายการที่ทำไปแล้ว (undo), การติดตั้งกลุ่มแพ็กเกจ และการรันอัปเดตแบบอัตโนมัติ

คำสั่งทุกคำสั่งด้านล่างนี้เขียนขึ้นเพื่อให้คุณนำไปรันบนเซิร์ฟเวอร์ของคุณเอง โปรดอ่านสรุปรายการการทำงานที่ dnf แสดงผลก่อนที่คุณจะตอบ y โดยเฉพาะอย่างยิ่งในกรณีที่มีการลบแพ็กเกจออก

distro ใดใช้ dnf และ distro ใดใช้ apt

dnf เป็นตัวจัดการแพ็กเกจบน Fedora, บน Red Hat Enterprise Linux (RHEL) และบนระบบที่สร้างใหม่จาก RHEL ได้แก่ Rocky Linux, AlmaLinux และ CentOS Stream ส่วน apt เป็นตัวจัดการแพ็กเกจบน Debian และทุกระบบที่พัฒนาต่อจาก Debian ซึ่งบน VPS มักจะหมายถึง Ubuntu เสมอ ไม่มีคำตอบที่สาม หากรายการอิมเมจของผู้ให้บริการของคุณมี Rocky Linux หรือ AlmaLinux แสดงว่าคุณกำลังใช้ dnf หากมี Ubuntu แสดงว่าคุณกำลังใช้ apt เหตุผลที่ฝั่งหนึ่งของความแตกต่างนี้มีถึงสี่ชื่อสำหรับระบบที่แทบจะเหมือนกันเป็นเรื่องที่ควรทราบก่อนตัดสินใจเลือก และ ประวัติความเป็นมาของ Red Hat Linux ที่กลายเป็น Fedora, RHEL, CentOS, Rocky และ AlmaLinux จะอธิบายที่มาของแต่ละระบบ

รูปแบบของแพ็กเกจจะขึ้นอยู่กับเครื่องมือที่ใช้ dnf ติดตั้งไฟล์ .rpm และฐานข้อมูลของมันคือ rpm ส่วน apt ติดตั้งไฟล์ .deb และฐานข้อมูลของมันคือ dpkg นี่คือเหตุผลว่าทำไมหน้าติดตั้งซอฟต์แวร์ของผู้ผลิตหลายรายจึงมีแท็บแยกสำหรับแต่ละตระกูล และทำไมไฟล์ .deb ที่ดาวน์โหลดมาจากหน้า release ของโปรเจกต์จึงใช้งานไม่ได้บน Rocky Linux

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

คำสั่ง apt และคำสั่ง dnf ที่เทียบเท่ากัน

การติดตั้ง การลบ การค้นหา และการแสดงข้อมูล คำสั่งเหล่านี้ใช้คำที่เกือบจะเหมือนกันทั้งสองฝั่ง

# apt
sudo apt install nginx
sudo apt remove nginx
apt search nginx
apt show nginx

# dnf
sudo dnf install nginx
sudo dnf remove nginx
dnf search nginx
dnf info nginx

apt show คือ dnf info นี่เป็นคำกริยาเดียวในกลุ่มที่เปลี่ยนชื่อไป แต่มีพฤติกรรมหนึ่งที่ต่างออกไปและมักทำให้ผู้ใช้สับสน dnf remove จะลบ dependency ที่ไม่มีแพ็กเกจอื่นใช้งานออกไปด้วย ในขณะที่ apt remove จะทิ้งแพ็กเกจเหล่านั้นไว้เผื่อการใช้งานใน apt autoremove ดังนั้นการลบยูทิลิตี้ขนาดเล็กเพียงตัวเดียวบน Rocky Linux อาจส่งผลให้ต้องลบไลบรารีที่เกี่ยวข้องออกไปนับสิบตัว โปรดอ่านรายการก่อนยืนยันการดำเนินการ

การรีเฟรช metadata การตรวจสอบรายการที่รออัปเดต และการอัปเกรด

# apt
sudo apt update
apt list --upgradable
sudo apt install --only-upgrade nginx
sudo apt upgrade

# dnf
sudo dnf makecache
dnf check-update
sudo dnf upgrade nginx
sudo dnf upgrade

apt update เป็นสิ่งที่จำเป็นต้องทำในฝั่ง apt เพราะ apt จะใช้ metadata ที่อยู่ในดิสก์โดยไม่สนใจว่าจะเป็นเวอร์ชันเก่าที่หลุดจาก archive ไปนานแล้วหรือไม่ ส่วน dnf จะตรวจสอบอายุของ cache ก่อนทำธุรกรรมทุกครั้งและจะดาวน์โหลด metadata ใหม่โดยอัตโนมัติ ดังนั้น sudo dnf makecache จึงใช้สำหรับบังคับให้ดาวน์โหลดทันทีแทนที่จะรอจนกว่าจะถึงการติดตั้งครั้งถัดไป

apt แยกการอัปเกรดทั้งระบบออกเป็นสองคำสั่ง แต่ dnf ไม่ได้แยก apt upgrade จะปฏิเสธการลบแพ็กเกจที่ติดตั้งอยู่ ดังนั้นมันจะหยุดทำงานทันทีหากการอัปเดตจำเป็นต้องลบแพ็กเกจใดแพ็กเกจหนึ่งออก apt full-upgrade คือเวอร์ชันที่อนุญาตให้ลบได้ dnf ไม่มีข้อจำกัดนี้ ซึ่งหมายความว่า dnf upgrade เทียบเท่ากับ apt full-upgrade ไม่ใช่ apt upgrade ส่วน dnf update เป็นชื่อเรียกเก่าของคำสั่งเดียวกันและยังคงใช้งานได้

มีรายละเอียดหนึ่งที่สำคัญหากคุณเขียนสคริปต์: dnf check-update จะส่งค่า exit status เป็น 100 เมื่อมีรายการรออัปเดต และเป็น 0 เมื่อไม่มีรายการใดๆ ส่วน apt list --upgradable จะส่งค่าเป็น 0 เสมอไม่ว่าจะมีรายการอัปเดตหรือไม่ ดังนั้นสคริปต์จึงจำเป็นต้อง parse ผลลัพธ์ที่ได้ออกมา

การแสดงรายการแพ็กเกจที่ติดตั้ง และการค้นหาว่าไฟล์ใดเป็นของแพ็กเกจไหน

# apt
dpkg -l
dpkg -S /usr/sbin/nginx
dpkg -L nginx
apt-file search /usr/sbin/nginx

# dnf
dnf list --installed
rpm -qf /usr/sbin/nginx
rpm -ql nginx
dnf provides /usr/sbin/nginx

บรรทัดสุดท้ายของแต่ละบล็อกตอบคำถามที่ต่างออกไปจากด้านบน dpkg -S และ rpm -qf จะค้นหาเฉพาะแพ็กเกจที่ติดตั้งอยู่แล้วเท่านั้น จึงตอบคำถามว่า "แพ็กเกจใดนำไฟล์นี้มาไว้ที่นี่" ส่วน apt-file search และ dnf provides จะค้นหาใน repository จึงตอบคำถามว่า "ต้องติดตั้งแพ็กเกจใดเพื่อให้ได้ไฟล์นี้มา" apt-file เป็นแพ็กเกจแยกต่างหากบน Ubuntu และจำเป็นต้องใช้ sudo apt-file update ก่อนการใช้งานครั้งแรก ส่วน dnf provides ไม่ต้องการสิ่งใดเพิ่มเติม แม้ว่าการรันครั้งแรกอาจจะช้าเนื่องจาก dnf ต้องดาวน์โหลดรายการไฟล์จาก repository มาเพื่อประมวลผลคำตอบ

หากต้องการแสดงรายการไฟล์ภายในแพ็กเกจที่คุณยังไม่ได้ติดตั้ง ให้ใช้ dnf repoquery -l nginx สำหรับฝั่ง apt คือ apt-file list nginx

การลบอัตโนมัติ การล้าง cache และการล็อกเวอร์ชัน

# apt
sudo apt autoremove
sudo apt clean
sudo apt-mark hold nginx
apt-mark showhold
sudo apt-mark unhold nginx

# dnf
sudo dnf autoremove
sudo dnf clean all
sudo dnf versionlock add nginx
dnf versionlock list
sudo dnf versionlock delete nginx

versionlock ไม่ได้ถูกติดตั้งมาเป็นค่าเริ่มต้นบน Rocky Linux หรือ AlmaLinux ดังนั้นบรรทัดแรกของกลุ่มนี้จะล้มเหลวด้วยข้อผิดพลาด No such command: versionlock บนเครื่องใหม่ ให้ติดตั้งก่อนด้วย sudo dnf install python3-dnf-plugin-versionlock ส่วน apt ไม่ต้องการสิ่งใดเพิ่มเติมสำหรับ apt-mark hold เพราะการล็อกเวอร์ชัน (hold) เป็นสถานะของ dpkg ไม่ใช่ปลั๊กอิน

จุดที่การแมปปิ้งไม่ตรงกัน: การเพิ่ม repository

นี่คือส่วนที่ทำให้ผู้ดูแลระบบ Ubuntu ต้องคอยค้นหาคำสั่งที่ไม่มีอยู่จริง ใน dnf ไม่มีคำสั่ง add-apt-repository และไม่มี Personal Package Archives (PPA) เนื่องจาก PPA เป็นบริการที่รันโดย Launchpad ซึ่งเป็นโครงสร้างพื้นฐานของ Ubuntu ในโลกของ RPM ไม่มีที่ใดให้บริการในลักษณะเดียวกัน

สิ่งที่ dnf มีทดแทนคือไฟล์ข้อความธรรมดาหนึ่งไฟล์ต่อหนึ่ง repository ใน /etc/yum.repos.d/ โดยลงท้ายด้วย .repo

[docker-ce-stable]
name=Docker CE Stable
baseurl=https://download.docker.com/linux/centos/$releasever/$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg

$releasever และ $basearch เป็นตัวแปรของ dnf โดย dnf จะเติมหมายเลขเวอร์ชันหลักและสถาปัตยกรรม CPU ของคุณให้โดยอัตโนมัติขณะรันไทม์ ดังนั้นไฟล์เดียวกันจึงสามารถใช้งานได้ทั้งบนเวอร์ชัน 9 และ 10 รวมถึงบน x86_64 และ aarch64

ผู้จำหน่ายส่วนใหญ่จะเผยแพร่ไฟล์ดังกล่าวและแนะนำให้คุณดาวน์โหลดมาใช้งาน คำแนะนำของ Docker สำหรับ RHEL และรุ่นที่ build ใหม่จาก source เดียวกันประกอบด้วยสองคำสั่ง:

sudo dnf -y install dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

บรรทัดแรกจำเป็นต้องมีเพราะ config-manager เป็นปลั๊กอิน ไม่ใช่ส่วนหนึ่งของตัว dnf เอง หากข้ามขั้นตอนนี้ไป บรรทัดที่สองจะล้มเหลวด้วยข้อผิดพลาด No such command: config-manager ไม่มีสิ่งใดขัดขวางไม่ให้คุณดาวน์โหลดไฟล์ .repo เดียวกันนั้นด้วย curl ไปไว้ใน /etc/yum.repos.d/ ด้วยตนเอง ซึ่งจะได้ผลลัพธ์ที่เหมือนกันทุกประการ การติดตั้ง Docker บน VPS ได้อธิบายขั้นตอนฝั่ง Debian ซึ่งมีขั้นตอนที่เทียบเท่ากันคือการเขียน source list และ signing key ลงในสองไดเรกทอรีที่แยกจากกัน

ความแตกต่างของโครงสร้างไฟล์เป็นตัวกำหนดว่าคุณควรตรวจสอบที่ใดเมื่อ repository ทำงานผิดปกติ apt เก็บคำนิยามไว้ใน /etc/apt/sources.list และ /etc/apt/sources.list.d/ โดยเก็บ signing key แยกไว้ต่างหากภายใต้ /etc/apt/keyrings/ ส่วน dnf เก็บทุกอย่างไว้ใน /etc/yum.repos.d/ และ key จะเป็น URL ที่ระบุอยู่ภายในไฟล์ .repo ดังนั้นจึงมีเพียงไฟล์เดียวที่ต้องอ่านและไฟล์เดียวที่ต้องลบ apt เวอร์ชันใหม่ได้เปลี่ยนมาใช้รูปแบบที่คล้ายกันนี้ด้วยฟอร์แมต deb822 ซึ่งใช้ไฟล์ .sources หนึ่งไฟล์ต่อหนึ่ง repository หากคุณเคยพบ ข้อผิดพลาด deb822 duplicate sources บน Ubuntu แสดงว่าคุณได้พบปัญหาในฝั่งของ apt ที่มีลักษณะเดียวกันนี้แล้ว

EPEL คือคลังซอฟต์แวร์ที่คู่มือส่วนใหญ่ถือเป็นมาตรฐาน

Extra Packages for Enterprise Linux (EPEL) เป็นโครงการของ Fedora ที่สร้างแพ็กเกจจาก Fedora เพื่อนำมาใช้บน RHEL และระบบที่สร้างจาก RHEL (rebuilds) นี่คือสิ่งที่ใกล้เคียงที่สุดกับ universal PPA ในโลกของ Linux และคู่มือจำนวนมากต่างถือว่ามีการเปิดใช้งาน EPEL ไว้แล้ว หาก dnf install ตอบกลับว่า No match for argument สำหรับแพ็กเกจที่คุณเห็นบนเว็บไซต์ของโครงการเอง EPEL คือสิ่งแรกที่ควรตรวจสอบ

บน Rocky Linux และ AlmaLinux:

sudo dnf config-manager --set-enabled crb
sudo dnf install epel-release
sudo dnf makecache

CRB คือ CodeReady Builder ซึ่งเป็นคลังเก็บไลบรารีที่มาพร้อมกับ distribution แต่ไม่ได้ถูกเปิดใช้งานโดยค่าเริ่มต้น แพ็กเกจ EPEL ส่วนใหญ่มี dependency ที่อยู่ใน CRB ดังนั้นการเปิดใช้งาน EPEL โดยไม่มี CRB จะไม่ทำให้เกิดข้อผิดพลาดในทันที แต่จะไปล้มเหลวในภายหลังระหว่างการติดตั้ง เนื่องจากไม่สามารถแก้ไข dependency ของแพ็กเกจที่คุณอาจไม่เคยรู้จักมาก่อนได้ การเปิดใช้งาน CRB ก่อนจะช่วยขจัดข้อผิดพลาดประเภทนี้ไปได้

สำหรับ RHEL โดยตรง CRB จะมาพร้อมกับ subscription ของคุณแทนที่จะผ่าน config-manager ดังนั้นให้ปฏิบัติตามคำแนะนำเรื่อง EPEL ของ Red Hat สำหรับขั้นตอนนี้ ส่วน Fedora ไม่จำเป็นต้องทำสิ่งเหล่านี้ เนื่องจากคลังซอฟต์แวร์หลักมีสิ่งที่ EPEL นำมา backport ไว้ให้อยู่แล้ว นโยบายของ EPEL คือจะไม่แทนที่แพ็กเกจที่ RHEL จัดเตรียมไว้ให้ ดังนั้นการเพิ่มคลังซอฟต์แวร์นี้จึงไม่ส่งผลกระทบต่อสิ่งที่ติดตั้งอยู่บนเซิร์ฟเวอร์ของคุณแล้วแต่อย่างใด

การใช้ dnf history undo ซึ่งเป็นสิ่งที่ apt ทำไม่ได้

dnf จะบันทึกทุกธุรกรรมที่เกิดขึ้น และสามารถสร้างการทำงานย้อนกลับของธุรกรรมนั้นได้

sudo dnf history
sudo dnf history info 42
sudo dnf history undo 42

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

ฟีเจอร์นี้มีข้อจำกัดที่แท้จริงซึ่งควรทราบก่อนที่จะพึ่งพามัน undo สามารถติดตั้งแพ็กเกจเวอร์ชันเดิมกลับมาได้ก็ต่อเมื่อเวอร์ชันนั้นยังคงมีอยู่ใน repository ที่เปิดใช้งานอยู่เท่านั้น ดังนั้นเมื่อ build เก่าถูกลบออกจาก mirror การ undo จะล้มเหลวด้วยข้อผิดพลาด not-found นอกจากนี้ การ rollback จะหยุดอยู่แค่ที่ฐานข้อมูลของแพ็กเกจเท่านั้น ไฟล์คอนฟิกที่ถูกเขียนทับระหว่างการอัปเกรดจะยังคงอยู่ในสถานะที่ถูกเขียนทับ และ schema ของฐานข้อมูลที่บริการได้ทำการ migrate ไปแล้วในตอนเริ่มต้นก็จะยังคงถูก migrate อยู่เช่นเดิม dnf จะนำไฟล์กลับมาให้ แต่ไม่ได้นำข้อมูลของคุณกลับมาให้

apt ไม่มีฟังก์ชันที่เทียบเท่ากัน /var/log/apt/history.log จะบันทึกสิ่งที่เกิดขึ้นจริงรวมถึงคำสั่งที่ใช้ แต่การอ่าน log ไม่ใช่การย้อนกลับการทำงาน การกู้คืนในฝั่ง apt ต้องทำด้วยตนเอง: ให้รัน apt list -a nginx เพื่อดูว่า archive ยังคงเก็บเวอร์ชันใดไว้บ้าง จากนั้นใช้ sudo apt install nginx=<exact version string> เพื่อระบุเวอร์ชันที่ต้องการ (pin) และเพิ่ม sudo apt-mark hold nginx เพื่อป้องกันไม่ให้การอัปเกรดครั้งถัดไปลบล้างการแก้ไขของคุณ

apt ไม่มีคำสั่งเทียบเท่ากับ package groups

dnf สามารถติดตั้งชุดแพ็กเกจที่กำหนดไว้ได้ด้วยคำสั่งเดียว

dnf group list
dnf group info "Development Tools"
sudo dnf group install "Development Tools"

คู่มือรุ่นเก่ามักเขียนว่า dnf groupinstall "Development Tools" ซึ่งนามแฝงนี้ใช้งานได้บน dnf 4 แต่ถูกตัดออกไปแล้วใน dnf 5 ดังนั้นการเขียนแบบสองคำว่า dnf group install จึงเป็นวิธีเดียวที่ใช้ได้กับทุกเวอร์ชัน ให้ใช้รูปแบบนี้และไม่ต้องกังวลเรื่องอื่นอีก

apt ไม่มีระบบกลุ่ม แพ็กเกจที่ใกล้เคียงที่สุดใน Debian คือ metapackage ซึ่งเป็นแพ็กเกจเปล่าที่บรรจุเพียงรายการ dependency ไว้เท่านั้น เช่น build-essential ความแตกต่างในทางปฏิบัติจะเห็นได้ชัดตอนลบแพ็กเกจ: การลบ metapackage จะทิ้ง dependency ไว้ในระบบจนกว่าคุณจะรันคำสั่ง apt autoremove ในขณะที่ dnf group remove จะลบแพ็กเกจทั้งหมดในกลุ่มออกไปพร้อมกันในการทำรายการเพียงครั้งเดียว

unattended-upgrades และ dnf-automatic

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

บน Ubuntu และ Debian แพ็กเกจที่ใช้คือ unattended-upgrades ซึ่งตั้งค่าผ่าน /etc/apt/apt.conf.d/50unattended-upgrades โดยคุณต้องระบุแหล่งที่มา (origins) ที่อนุญาตให้ดึงข้อมูลมาติดตั้ง การตั้งค่า unattended upgrades บน Ubuntu ครอบคลุมรายละเอียดของไฟล์คอนฟิกดังกล่าวและประเด็นเรื่องการรีบูตที่เกี่ยวข้อง

บน Rocky Linux, AlmaLinux และ Fedora แพ็กเกจที่ใช้คือ dnf-automatic โดยพฤติกรรมการทำงานจะขึ้นอยู่กับ systemd timer ที่คุณเปิดใช้งาน

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic-install.timer
systemctl list-timers 'dnf-automatic*'

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

หากต้องการจำกัดให้ติดตั้งเฉพาะอัปเดตด้านความปลอดภัย ให้ตั้งค่า upgrade_type = security ใน /etc/dnf/automatic.conf ตัวกรองนี้ขึ้นอยู่กับว่า repository ของคุณมีการเผยแพร่ security errata หรือไม่ ดังนั้นควรตรวจสอบก่อนด้วย dnf updateinfo list security หากผลลัพธ์ว่างเปล่าในขณะที่เครื่องมีอัปเดตค้างอยู่ แสดงว่าไม่มีข้อมูล metadata ดังกล่าว และ security จะไม่ติดตั้งสิ่งใดเลย

บน Fedora, dnf 5 ได้เปลี่ยนชื่อ unit ใหม่เป็น dnf5-automatic.timer ซึ่งจะอ่านค่าจาก /etc/dnf/automatic.conf ตัวเดียวกัน

yum ยังคงเป็นคำสั่งที่ใช้งานได้จริงหรือไม่?

ใช่ และตัวมันเองไม่ได้ทำงานใดๆ บน Rocky Linux, AlmaLinux และ CentOS Stream นั้น /usr/bin/yum เป็น symbolic link ที่ชี้ไปยัง dnf ตรวจสอบของคุณได้ด้วยคำสั่งนี้:

ls -l /usr/bin/yum
dnf --version

ไวยากรณ์แบบเก่าของ yum ยังคงปรากฏในบทเรียนต่างๆ เพราะคำสั่งส่วนใหญ่ยังคงส่งผ่านไปยัง dnf ได้โดยตรง ทั้ง yum install, yum remove และ yum update ล้วนใช้งานได้ แต่มีนิสัยหนึ่งที่ควรเลิกทำ: yum-config-manager ยังคงมีอยู่ในฐานะ binary แยกต่างหากบนระบบ dnf 4 แต่ dnf config-manager คือรูปแบบที่เอกสารปัจจุบันใช้ และเป็นรูปแบบที่จะยังคงใช้งานได้เมื่อย้ายระบบไปใช้ dnf 5

dnf 4 และ dnf 5: ตรวจสอบก่อนคัดลอกคำสั่ง

dnf 5 เป็นการเขียนโปรแกรมขึ้นใหม่ทั้งหมด ซึ่งมีการเปลี่ยนการสะกดของคำสั่งหลายรายการ Fedora 41 และเวอร์ชันที่ใหม่กว่ามาพร้อมกับ dnf ส่วนการแจกจ่ายแบบ enterprise rebuilds นั้นเปลี่ยนผ่านช้ากว่า ดังนั้นอย่าคาดเดาจากชื่อของ distribution ให้รัน dnf --version บนเซิร์ฟเวอร์ของคุณเองแล้วอ่านบรรทัดแรก เพราะตัวเลขนั้นจะเป็นตัวกำหนดว่าคุณต้องใช้ไวยากรณ์ใดจากรายการด้านล่างนี้

ตัวอย่างที่ชัดเจนที่สุดมาจาก Docker ซึ่งเผยแพร่คำสั่งสำหรับเพิ่ม repository ที่แตกต่างกันสำหรับแต่ละเวอร์ชัน บน RHEL และเวอร์ชันที่สร้างใหม่ (rebuilds) ซึ่งใช้ dnf 4:

sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

บน Fedora ซึ่งใช้ dnf 5:

sudo dnf config-manager addrepo --from-repofile https://download.docker.com/linux/fedora/docker-ce.repo

ผู้จำหน่ายเดียวกัน งานเดียวกัน แต่ใช้คำสั่งต่างกัน dnf 5 เปลี่ยนให้ config-manager กลายเป็นเครื่องมือที่ขับเคลื่อนด้วยคำสั่งย่อย (subcommand) ดังนั้นแฟล็ก --add-repo แบบเดิมจึงไม่สามารถใช้งานได้ และคุณจะได้รับข้อผิดพลาดเรื่องการใช้งานแทนที่จะได้ repository อีกคำสั่งหนึ่งที่คุณจะพบคือการเปิดใช้งาน repository: dnf config-manager --set-enabled crb ใน dnf 4 จะกลายเป็น dnf config-manager setopt crb.enabled=1 ใน dnf 5

ทางเลือกที่สำคัญจริง

การเลือก Linux distribution โดยพิจารณาจาก package manager เพียงอย่างเดียวถือเป็นจุดโฟกัสที่ผิด dnf และ apt ทำงานได้เหมือนกัน และคำสั่งต่างๆ สามารถเรียนรู้ได้ภายในเวลาไม่กี่ชั่วโมง สิ่งที่จะส่งผลต่อการใช้งานตลอดทั้งปีของคุณคือ release model ของ repository นั้นๆ Fedora มีการอัปเดตที่รวดเร็ว โดยแต่ละเวอร์ชันจะหยุดรับการสนับสนุนหลังจากเปิดตัวไปแล้วประมาณ 13 เดือน ซึ่งเหมาะสมสำหรับเครื่อง workstation แต่จะสร้างความยุ่งยากให้กับเซิร์ฟเวอร์ที่คุณไม่ต้องการติดตั้งใหม่บ่อยๆ Rocky Linux และ AlmaLinux อ้างอิงตาม RHEL ทำให้คุณได้รับระยะเวลาการสนับสนุนนานถึง 10 ปี และเวอร์ชันของแพ็กเกจจะถูกคงไว้ให้เสถียรตามวัตถุประสงค์ Ubuntu มีให้เลือกทั้งสองรูปแบบ และ ความแตกต่างระหว่าง Ubuntu LTS กับ interim releases บนเซิร์ฟเวอร์ ก็คือการตัดสินใจในลักษณะเดียวกันภายใต้ระบบของ apt

ณ เดือนสิงหาคม 2026 ทั้งหมดนี้เป็นเพียง VPS image ทั่วไป ให้เลือกช่วงเวลาการสนับสนุนที่คุณต้องการ แล้วเรียนรู้คำสั่งทั้ง 10 รายการข้างต้น

FAQ

คำสั่งใดใน dnf ที่เทียบเท่ากับ apt update?

ไม่มีคำสั่งที่คุณจำเป็นต้องเรียกใช้ dnf จะตรวจสอบความเก่าของ metadata ที่แคชไว้ก่อนทำธุรกรรมทุกครั้ง และจะดาวน์โหลดชุดใหม่เมื่อชุดเดิมหมดอายุ ดังนั้น dnf install บนเซิร์ฟเวอร์ที่คุณไม่ได้แตะต้องมาเป็นเดือนก็ยังคงเห็นแพ็กเกจที่เป็นปัจจุบัน sudo dnf makecache มีอยู่จริงและเป็นการบังคับให้ดาวน์โหลด แต่ประโยชน์ที่แท้จริงของมันคือการเลื่อนเวลาการดาวน์โหลดไปเป็นช่วงเวลาที่คุณเลือก แทนที่จะไปรอตอนที่คุณกำลังจะติดตั้งแพ็กเกจถัดไป คำสั่งที่ตอบคำถามว่า "มีอะไรอัปเดตบ้าง" คือ dnf check-update ซึ่งเทียบเท่ากับ apt list --upgradable และจะส่งสถานะ 100 กลับมาเมื่อมีการอัปเดตพร้อมใช้งาน

มีสิ่งที่เทียบเท่ากับ PPA บน Rocky Linux หรือ Fedora หรือไม่?

ไม่มี PPA (Personal Package Archives) เป็นบริการของ Launchpad และ Launchpad เป็นโครงสร้างพื้นฐานของ Ubuntu ดังนั้น add-apt-repository จึงไม่มีสิ่งที่เทียบเท่ากัน สิ่งที่เทียบเท่าในรูปแบบ RPM คือไฟล์ .repo ใน /etc/yum.repos.d/ ซึ่งเก็บชื่อ, baseurl และ gpgkey ไว้ ผู้ให้บริการซอฟต์แวร์จะเผยแพร่ไฟล์ดังกล่าวให้คุณ และ sudo dnf config-manager --add-repo <url> บน dnf 4 หรือ sudo dnf config-manager addrepo --from-repofile <url> บน dnf 5 จะดาวน์โหลดไฟล์นั้นมาติดตั้งให้ สำหรับซอฟต์แวร์เสริมทั่วไป คำตอบมักจะเป็น EPEL ซึ่งคุณสามารถเปิดใช้งานได้ด้วย sudo dnf config-manager --set-enabled crb ตามด้วย sudo dnf install epel-release

ฉันสามารถย้อนกลับการอัปเกรดด้วย dnf ที่ทำให้เซิร์ฟเวอร์พังได้หรือไม่?

ได้ ภายในขอบเขตที่กำหนด ให้รัน sudo dnf history เพื่อหาหมายเลขธุรกรรม, sudo dnf history info <id> เพื่อดูว่ามีการเปลี่ยนแปลงอะไรบ้าง จากนั้นใช้ sudo dnf history undo <id> การย้อนกลับจะล้มเหลวหากแพ็กเกจเวอร์ชันเก่าไม่อยู่ใน repository ใดๆ ที่เปิดใช้งานอยู่แล้ว เพราะ dnf ไม่มีแหล่งให้ติดตั้งใหม่ นอกจากนี้ มันจะย้อนกลับเฉพาะการเปลี่ยนแปลงแพ็กเกจเท่านั้น ไฟล์การตั้งค่าที่ถูกเขียนทับโดยการอัปเกรด หรือฐานข้อมูลที่ถูกอัปเกรดโดยบริการในครั้งแรกที่เริ่มทำงาน จะยังคงอยู่ในสถานะเดิม apt ไม่มีคำสั่งที่เทียบเท่ากันเลย มีเพียงบันทึกใน /var/log/apt/history.log เท่านั้น

yum ยังคงใช้งานได้บน Rocky Linux และ AlmaLinux หรือไม่?

ใช้งานได้เพราะ /usr/bin/yum เป็น symbolic link ไปยัง dnf คุณสามารถตรวจสอบได้บนเครื่องของคุณด้วย ls -l /usr/bin/yum การพิมพ์ yum install httpd คือการรัน dnf ดังนั้นบทเรียนเก่าๆ ส่วนใหญ่จึงยังคงใช้งานได้ ให้เขียนสคริปต์และเอกสารใหม่ด้วย dnf เนื่องจากชื่อ yum มีไว้เพื่อความเข้ากันได้เท่านั้น และควรใช้ dnf config-manager แทนที่ไบนารี yum-config-manager แบบเก่า

ทำไม dnf remove ถึงต้องการลบแพ็กเกจจำนวนมาก?

เพราะ dnf จะลบ dependency ที่ไม่มีแพ็กเกจอื่นใช้งานแล้วออกไปพร้อมกับธุรกรรมเดียวกัน ในขณะที่ apt remove จะทิ้งแพ็กเกจเหล่านั้นไว้จนกว่าคุณจะรัน apt autoremove แยกต่างหาก ดังนั้นการลบที่ดูเหมือนเล็กน้อยบน Ubuntu อาจแสดงรายการยาวเหยียดบน Rocky Linux รายการที่แสดงมักจะถูกต้อง แต่ควรอ่านให้ละเอียดก่อนยืนยัน หากมีแพ็กเกจในรายการที่คุณต้องการเก็บไว้ ให้ติดตั้งแพ็กเกจนั้นแบบระบุชื่อโดยตรงก่อน เพื่อให้ dnf บันทึกว่าแพ็กเกจนั้นเป็นสิ่งที่ต้องการใช้งานจริง