เทียบคำสั่ง 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 อย่างที่ไม่มีใน apt ได้แก่ การเพิ่ม repository, การย้อนกลับ transaction, การติดตั้ง package group และการรันอัปเดตแบบอัตโนมัติ

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

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

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

มีรายละเอียดหนึ่งที่สำคัญหากคุณเขียนสคริปต์: dnf check-update จะจบการทำงานด้วยสถานะ 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

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

# 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 จึงไม่มีบริการใดที่รองรับ PPA

สิ่งที่ 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 และระบบที่สร้างใหม่จาก RHEL ประกอบด้วยสองคำสั่งดังนี้:

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 มันเป็นสิ่งที่ใกล้เคียงที่สุดกับ PPA แบบครอบจักรวาลในโลกนี้ และคู่มือจำนวนมากต่างก็ตั้งสมมติฐานว่าคุณได้เปิดใช้งานมันไว้แล้ว หาก 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 ซึ่งเป็นคลังเก็บไลบรารีที่มาพร้อมกับดิสทริบิวชันแต่ไม่ได้ถูกเปิดใช้งานโดยค่าเริ่มต้น แพ็กเกจ EPEL ส่วนใหญ่ต้องอาศัยไลบรารีในคลังนี้ ดังนั้นการเปิดใช้งาน EPEL โดยไม่มี CRB จะไม่ทำให้เกิดข้อผิดพลาดในทันที แต่จะไปล้มเหลวในภายหลังระหว่างการติดตั้ง เนื่องจากไม่สามารถแก้ไข dependency ของแพ็กเกจที่คุณอาจไม่เคยรู้จักมาก่อนได้ ให้เปิดใช้งาน CRB ก่อนแล้วข้อผิดพลาดประเภทนี้จะหมดไป

สำหรับ RHEL โดยตรง CRB จะมาพร้อมกับการสมัครสมาชิกของคุณแทนที่จะผ่าน 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

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 จะทำหน้าที่รายงานผลเท่านั้น แต่ละ unit เหล่านี้จะเขียนทับการตั้งค่า 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 จะเปลี่ยนผ่านช้ากว่า ดังนั้นอย่าคาดเดาจากชื่อดิสทริบิวชัน ให้รันคำสั่ง dnf --version บนเซิร์ฟเวอร์ของคุณแล้วอ่านบรรทัดแรก เพราะตัวเลขนั้นจะเป็นตัวกำหนดว่าคุณต้องใช้ไวยากรณ์ใดจากรายการด้านล่างนี้

ตัวอย่างที่ชัดเจนที่สุดมาจาก Docker ซึ่งเผยแพร่คำสั่งสำหรับเพิ่ม repository ที่แตกต่างกันสำหรับทั้งสองเวอร์ชัน บน RHEL และดิสทริบิวชันที่สร้างใหม่จาก RHEL ซึ่งใช้ 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 บนเซิร์ฟเวอร์ ก็คือการตัดสินใจในลักษณะเดียวกันภายใต้ระบบของ apt

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

FAQ

คำสั่งเทียบเท่า apt update ใน dnf คืออะไร

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

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

ไม่มี 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 บันทึกว่าคุณต้องการใช้งานแพ็กเกจนั้นจริงๆ