SSD Nodes Learn Hosting plans →
Hướng dẫn Matt ConnorBởi Matt Connor · Cập nhật ngày 2026-09-04

apt sang dnf: lệnh tương đương trên Rocky, Fedora

Tra bảng lệnh dnf tương đương apt trên Rocky, AlmaLinux và Fedora, kèm cách thêm repository, hoàn tác transaction, cài group và chạy update tự động.

Câu trả lời ngắn

Chuyển từ apt sang dnf chủ yếu là thay đổi cách gọi. apt install nginx trở thành dnf install nginx. apt remove nginx trở thành dnf remove nginx. apt update không có lệnh tương đương trực tiếp, vì dnf tự làm mới metadata của repository khi bản cache đã cũ. Phần chuyển đổi đơn giản chỉ chiếm một màn hình. Phần hữu ích là 4 thao tác không có ánh xạ trực tiếp: thêm repository, hoàn tác một transaction, cài một package group và chạy update không cần giám sát.

Mọi command bên dưới đều được viết để bạn chạy trên server của mình. Hãy đọc phần tóm tắt transaction mà dnf in ra trước khi trả lời y, đặc biệt khi gỡ package.

Bản distro nào dùng dnf và bản nào dùng apt

dnf là package manager trên Fedora, Red Hat Enterprise Linux (RHEL) và các bản rebuild của RHEL: Rocky Linux, AlmaLinux và CentOS Stream. apt là package manager trên Debian và mọi distro dẫn xuất từ Debian, mà trên VPS gần như luôn là Ubuntu. Không có lựa chọn thứ ba. Nếu danh sách image của nhà cung cấp có Rocky Linux hoặc AlmaLinux, bạn sẽ dùng dnf. Nếu có Ubuntu, bạn sẽ dùng apt. Lý do một nhánh có bốn tên cho một hệ thống về cơ bản là giống nhau là câu chuyện đáng tìm hiểu trước khi bạn chọn giữa hai nhánh này. Red Hat Linux đã trở thành Fedora, RHEL, CentOS, Rocky và AlmaLinux như thế nào giải thích nguồn gốc của từng bản.

Định dạng package đi kèm với công cụ. dnf cài các file .rpm và database của nó là rpm. apt cài các file .deb và database của nó là dpkg. Vì vậy, nhiều trang hướng dẫn cài đặt của vendor có một tab cho mỗi họ distro. Đây cũng là lý do một .deb tải từ trang release của project sẽ vô dụng trên Rocky Linux.

Dù bạn dùng họ distro nào, lần đăng nhập đầu tiên vẫn cần thực hiện các bước giống nhau. Mười phút đầu tiên trên một VPS mới áp dụng cho cả hai. Chỉ có lệnh cài đặt là khác.

Mọi lệnh apt và lệnh tương đương trong dnf

Cài đặt, gỡ bỏ, tìm kiếm và hiển thị. Hai bên dùng gần như cùng từ khóa.

# 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 là dnf info. Đây là động từ duy nhất được đổi tên trong nhóm, nhưng có một khác biệt về hành vi dễ gây nhầm. dnf remove cũng gỡ các dependency không còn gì khác cần, còn apt remove giữ chúng lại để dùng cho lần apt autoremove sau. Vì vậy, khi gỡ một tiện ích nhỏ trên Rocky Linux, hệ thống có thể đề xuất gỡ thêm cả chục thư viện. Hãy đọc danh sách trước khi xác nhận.

Làm mới metadata, kiểm tra các bản cập nhật đang chờ và nâng cấp.

# 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 là bắt buộc ở phía apt, vì apt sử dụng metadata đang lưu trên máy và có thể cài một phiên bản đã rời archive từ vài tháng trước. dnf kiểm tra tuổi của cache trước mỗi transaction và tự tải metadata mới, nên sudo dnf makecache chỉ dùng để buộc tải ngay thay vì chờ đến lần cài đặt tiếp theo.

apt tách việc nâng cấp toàn bộ hệ thống thành hai lệnh, còn dnf thì không. apt upgrade từ chối gỡ bất kỳ package nào đang được cài, nên sẽ dừng khi bản cập nhật yêu cầu gỡ một package. apt full-upgrade là phiên bản được phép gỡ package. dnf không có hạn chế này, nghĩa là dnf upgrade tương đương với apt full-upgrade, không phải apt upgrade. dnf update là alias cũ của cùng lệnh và vẫn hoạt động.

Một chi tiết cần lưu ý khi viết script: dnf check-update thoát với status 100 khi đang có bản cập nhật chờ xử lý và 0 khi không có bản cập nhật nào. apt list --upgradable thoát với 0 trong cả hai trường hợp, nên script phải parse output của lệnh.

Liệt kê các package đã cài và tìm package sở hữu một file.

# 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

Dòng cuối của mỗi block trả lời một câu hỏi khác với các dòng phía trên. dpkg -S và rpm -qf chỉ tìm trong các package đã cài, nên trả lời câu hỏi “package nào đã đặt file này ở đây”. apt-file search và dnf provides tìm trong các repository, nên trả lời câu hỏi “cần cài package nào để có file này”. apt-file là một package riêng trên Ubuntu và cần sudo apt-file update trước lần chạy đầu tiên. dnf provides không cần gì thêm, dù lần chạy đầu có thể chậm vì dnf phải tải danh sách file của repository để tìm câu trả lời.

Để liệt kê các file bên trong một package chưa cài, dùng dnf repoquery -l nginx. Ở phía apt, lệnh tương ứng là apt-file list nginx.

Tự động gỡ dependency, dọn cache và giữ một phiên bản.

# 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 không được cài mặc định trên Rocky Linux hoặc AlmaLinux, nên dòng đầu tiên trong các dòng trên sẽ thất bại với No such command: versionlock trên một máy mới cài. Trước tiên hãy cài nó bằng sudo dnf install python3-dnf-plugin-versionlock. apt không cần gì thêm cho apt-mark hold, vì hold là một trạng thái của dpkg chứ không phải plugin.

Vị trí ánh xạ không còn đúng: thêm một repository

Đây là phần khiến admin Ubuntu phải tìm một command không tồn tại. Trên dnf không có add-apt-repository, và cũng không có personal package archive (PPA). PPA là một service do Launchpad cung cấp, còn Launchpad là hạ tầng của Ubuntu. Trong hệ sinh thái RPM không có thành phần nào cung cấp dịch vụ tương tự.

Thay vào đó, dnf dùng một plain text file cho mỗi repository trong /etc/yum.repos.d/, với phần mở rộng là .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 và $basearch là các biến dnf. dnf điền số phiên bản major và kiến trúc CPU khi chạy, nên cùng một file hoạt động trên version 9 và version 10, cũng như trên x86_64 và aarch64.

Hầu hết vendor đều publish file này và hướng dẫn bạn tải xuống. Hướng dẫn chính thức của Docker cho RHEL và các bản rebuild của RHEL gồm 2 command:

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

Dòng đầu tiên cần thiết vì config-manager là một plugin, không phải thành phần tích hợp của dnf. Nếu bỏ qua dòng này, dòng thứ hai sẽ fail với No such command: config-manager. Bạn cũng có thể tự tải cùng file .repo bằng curl vào /etc/yum.repos.d/, và kết quả hoàn toàn giống nhau. Cài đặt Docker trên VPS trình bày cách thực hiện tương tự ở phía Debian, trong đó bước tương đương ghi source list và signing key vào 2 thư mục khác nhau.

Khác biệt về layout quyết định nơi bạn cần kiểm tra khi repository gặp lỗi. apt lưu định nghĩa trong /etc/apt/sources.list và /etc/apt/sources.list.d/, còn signing key được lưu riêng dưới /etc/apt/keyrings/. dnf lưu mọi thứ trong /etc/yum.repos.d/, còn key là một URL bên trong file .repo, nên chỉ có một file để đọc và một file để xóa. Các phiên bản apt mới hơn đang chuyển sang cấu trúc tương tự với định dạng deb822, dùng một file .sources cho mỗi repository. Nếu bạn từng gặp lỗi duplicate sources của deb822 trên Ubuntu, thì bạn đã gặp phần apt của vấn đề này.

EPEL là repository mà hầu hết hướng dẫn đều mặc định có

Extra Packages for Enterprise Linux (EPEL) là một dự án Fedora build các package Fedora cho RHEL và các bản rebuild của RHEL. Đây là thứ gần nhất với một PPA dùng chung cho hệ sinh thái này, và rất nhiều tutorial mặc định rằng EPEL đã được enable. Nếu dnf install trả về No match for argument cho một package mà bạn thấy trên chính website của dự án, EPEL là thứ đầu tiên cần kiểm tra.

Trên Rocky Linux và AlmaLinux:

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

CRB là CodeReady Builder, một repository chứa các thư viện được phân phối cùng hệ điều hành nhưng không được enable mặc định. Hầu hết package EPEL đều phụ thuộc vào một thành phần trong đó, nên việc enable EPEL mà chưa enable CRB không báo lỗi ngay lúc đó. Lỗi chỉ xuất hiện sau, khi install, dưới dạng dependency chưa được đáp ứng cho một package mà bạn chưa từng nghe đến. Hãy enable CRB trước để loại bỏ nhóm lỗi này.

Trên chính RHEL, CRB được cung cấp thông qua subscription của bạn thay vì qua config-manager, vì vậy hãy làm theo hướng dẫn EPEL của Red Hat cho bước này. Fedora không cần các bước này vì repository chính của Fedora đã chứa những package được EPEL backport. Chính sách của EPEL là không bao giờ thay thế package mà RHEL phát hành, nên việc thêm repository này không thay đổi những gì đã được cài trên server.

dnf history undo, tính năng apt không có

dnf ghi lại mọi transaction và có thể tạo transaction ngược để hoàn tác một transaction.

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

dnf history in danh sách các transaction được đánh số, kèm theo command line đã khởi chạy từng transaction. undo tạo transaction ngược: các package được transaction đó cài sẽ bị gỡ, còn các package được nâng cấp sẽ quay lại version trước đó. Đây là tính năng mà người dùng apt thường thiếu nhất sau khi chuyển sang dnf.

Tính năng này có giới hạn thực tế. Bạn nên biết rõ các giới hạn đó trước khi dựa vào nó. undo chỉ có thể cài lại một version của package nếu version đó vẫn còn trong repository đang được enable. Khi build cũ đã bị xóa khỏi mirror, thao tác undo sẽ fail với lỗi không tìm thấy package. Rollback cũng chỉ tác động đến package database. File cấu hình bị lần nâng cấp ghi đè vẫn giữ nội dung đã bị ghi đè. Database schema đã được service migrate khi khởi động lần đầu vẫn giữ schema mới. dnf khôi phục các file. Nó không khôi phục dữ liệu của bạn.

apt không có tính năng tương đương. /var/log/apt/history.log ghi chính xác những gì đã xảy ra, bao gồm command line, nhưng đọc log không phải là undo transaction. Cách khôi phục với apt phải thực hiện thủ công: chạy apt list -a nginx để xem archive vẫn còn giữ những version nào, sau đó chạy sudo apt install nginx=<exact version string> để pin một version, và thêm sudo apt-mark hold nginx để lần upgrade tiếp theo không hoàn tác thay đổi của bạn.

Nhóm package không có tương đương trong apt

dnf có thể cài một tập package được đặt tên bằng một lệnh.

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

Các tài liệu cũ thường viết dnf groupinstall "Development Tools". Alias đó hoạt động trên dnf 4 và đã bị loại bỏ trong dnf 5, vì vậy dnf group install gồm hai từ là cách viết duy nhất hoạt động ở mọi phiên bản. Hãy dùng cách này và không cần bận tâm thêm.

apt không có nhóm package. Khái niệm gần nhất của Debian là metapackage, một package gần như rỗng chỉ chứa danh sách dependency, chẳng hạn như build-essential. Khác biệt thực tế xuất hiện khi gỡ cài đặt: xóa metapackage vẫn giữ các dependency của nó trên hệ thống cho đến khi bạn chạy apt autoremove, còn dnf group remove sẽ xóa các package thuộc nhóm trong cùng một transaction.

unattended-upgrades và dnf-automatic

Cả hai nhóm đều cung cấp cách cài đặt bản cập nhật khi không có ai đăng nhập. Hai nhóm này chỉ giống nhau ở mục đích.

Trên Ubuntu và Debian, package là unattended-upgrades, được cấu hình trong /etc/apt/apt.conf.d/50unattended-upgrades. Tại đây, bạn liệt kê các origin mà package được phép tải về. Thiết lập unattended upgrades trên Ubuntu trình bày file cấu hình này và câu hỏi về việc reboot đi kèm.

Trên Rocky Linux, AlmaLinux và Fedora, package là dnf-automatic. systemd timer mà bạn enable sẽ quyết định hành vi.

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

dnf-automatic-install.timer tải và áp dụng các bản cập nhật. dnf-automatic-download.timer chỉ tải chúng rồi dừng, để bạn tự cài đặt. dnf-automatic-notifyonly.timer chỉ báo cáo. Mỗi unit này override thiết lập apply_updates trong /etc/dnf/automatic.conf, vì vậy timer bạn chọn quan trọng hơn nội dung file cấu hình. Cài đặt bản cập nhật không restart những tiến trình vẫn đang chạy code cũ. Vì vậy, trước khi cho rằng máy đã được patch, hãy kiểm tra bản cập nhật nào cần reboot và bản cập nhật nào chỉ cần restart service.

Để chỉ cài các bản sửa lỗi bảo mật, hãy đặt upgrade_type = security trong /etc/dnf/automatic.conf. Bộ lọc này phụ thuộc vào việc repository của bạn có publish security errata hay không, vì vậy trước tiên hãy kiểm tra bằng dnf updateinfo list security. Kết quả rỗng trên một máy đang có bản cập nhật chờ xử lý nghĩa là metadata không có ở đó, và khi đó security sẽ không cài đặt gì cả.

Trên Fedora, dnf 5 đổi tên unit. Unit đó là dnf5-automatic.timer và đọc cùng /etc/dnf/automatic.conf.

yum còn là một command thực sự không?

Có. Nhưng bản thân nó không thực hiện thao tác riêng nào. Trên Rocky Linux, AlmaLinux và CentOS Stream, /usr/bin/yum là symbolic link trỏ đến dnf. Kiểm tra trên máy của bạn:

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

Cú pháp yum cũ vẫn xuất hiện trong các tutorial vì phần lớn vẫn được chuyển thẳng sang dnf. yum install, yum remove và yum update đều hoạt động. Có một thói quen bạn nên bỏ: yum-config-manager vẫn tồn tại dưới dạng binary riêng trên các hệ thống dùng dnf 4, nhưng dnf config-manager là cách viết được tài liệu hiện tại sử dụng và vẫn hoạt động khi máy chuyển sang dnf 5.

dnf 4 và dnf 5: kiểm tra trước khi sao chép lệnh

dnf 5 là bản viết lại và đã thay đổi cách viết của một số lệnh. Fedora 41 trở lên phát hành nó dưới dạng dnf. Các bản rebuild cho doanh nghiệp chuyển đổi chậm hơn, vì vậy không được đoán dựa trên tên bản phân phối. Chạy dnf --version trên chính server của bạn và đọc dòng đầu tiên, vì số phiên bản đó quyết định bạn cần dùng cú pháp nào bên dưới.

Docker là ví dụ rõ nhất vì Docker công bố một lệnh cấu hình repository khác nhau cho từng phiên bản. Trên RHEL và các bản rebuild của RHEL, với dnf 4:

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

Trên Fedora, với dnf 5:

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

Cùng một vendor, cùng một mục đích, nhưng cú pháp khác nhau. dnf 5 chuyển config-manager thành công cụ điều khiển bằng subcommand, vì vậy flag --add-repo cũ không được chấp nhận và bạn nhận lỗi usage thay vì có repository. Một thay đổi khác bạn sẽ gặp là bật repository: dnf config-manager --set-enabled crb trên dnf 4 trở thành dnf config-manager setopt crb.enabled=1 trên dnf 5.

Lựa chọn thực sự quan trọng

Chọn bản phân phối server chỉ dựa trên package manager là sai tiêu chí. dnf và apt thực hiện cùng một việc, còn bộ thuật ngữ của chúng chỉ cần một buổi chiều để làm quen. Điều ảnh hưởng đến cả năm sử dụng của bạn là mô hình release phía sau repository. Fedora phát hành nhanh, và một release nhất định sẽ ngừng nhận update khoảng 13 tháng sau khi xuất hiện. Điều này phù hợp với workstation nhưng gây nhiều khó khăn cho server mà bạn không muốn build lại. Rocky Linux và AlmaLinux bám theo RHEL, nên bạn có thời gian support 10 năm và các package version được giữ ổn định có chủ đích. Ubuntu cung cấp cả hai mô hình, và sự khác nhau giữa Ubuntu LTS và các release interim trên server cũng chính là quyết định tương tự trong hệ sinh thái apt.

Tính đến tháng 8 năm 2026, tất cả các bản này đều là image VPS phổ biến. Hãy chọn thời gian support phù hợp với bạn, sau đó học 10 command ở trên.

FAQ

Tương đương của apt update trong dnf là gì?

Bạn không cần chạy lệnh nào. Trước mỗi transaction, dnf kiểm tra metadata trong cache đã cũ đến mức nào rồi tải bản mới nếu metadata đã hết hạn. Vì vậy, dnf install trên một server bạn chưa đụng đến trong một tháng vẫn thấy các package hiện tại. sudo dnf makecache có tồn tại và buộc dnf tải metadata mới, nhưng tác dụng thực tế của nó là chuyển thời gian chờ sang thời điểm bạn chọn thay vì để thời gian chờ xuất hiện trong lần cài đặt tiếp theo. Lệnh trả lời câu hỏi “đang có gì chờ tôi xử lý” là dnf check-update. Lệnh này ánh xạ đến apt list --upgradable và thoát với status 100 khi có update.

Rocky Linux hoặc Fedora có tương đương PPA không?

Không. Personal package archive là một dịch vụ của Launchpad, còn Launchpad là hạ tầng của Ubuntu, nên add-apt-repository không có gì để chuyển đổi sang. Tương đương trong hệ RPM là một file .repo trong /etc/yum.repos.d/, chứa một name, một baseurl và một gpgkey. Vendor cung cấp file này cho bạn. Trên dnf 4, sudo dnf config-manager --add-repo <url> tải file đó vào đúng vị trí; trên dnf 5, dùng sudo dnf config-manager addrepo --from-repofile <url>. Với phần mềm bổ sung nói chung, lựa chọn thường dùng là EPEL. Bạn enable EPEL bằng sudo dnf config-manager --set-enabled crb rồi chạy sudo dnf install epel-release.

Tôi có thể hoàn tác một lần dnf upgrade làm hỏng server không?

Có, nhưng có giới hạn. Chạy sudo dnf history để tìm transaction number, chạy sudo dnf history info <id> để xem chính xác transaction đã thay đổi gì, rồi chạy sudo dnf history undo <id>. Lệnh hoàn tác sẽ thất bại nếu version package cũ không còn trong bất kỳ repository nào đang được enable, vì dnf không có package để cài lại. Lệnh này cũng chỉ đảo ngược các thay đổi đối với package. File cấu hình bị upgrade ghi lại, hoặc database được service migrate trong lần khởi động đầu tiên, vẫn giữ nguyên trạng thái đó. apt hoàn toàn không có lệnh tương đương; apt chỉ lưu bản ghi trong /var/log/apt/history.log.

yum còn hoạt động trên Rocky Linux và AlmaLinux không?

Có, vì /usr/bin/yum là symbolic link trỏ đến dnf. Xác nhận trên máy của bạn bằng ls -l /usr/bin/yum. Khi nhập yum install httpd, hệ thống sẽ chạy dnf, nên phần lớn tutorial cũ vẫn hoạt động. Với script và tài liệu mới, hãy dùng dnf, vì tên yum hiện chỉ còn để tương thích. Đồng thời, nên dùng dnf config-manager thay cho binary yum-config-manager cũ hơn.

Vì sao dnf remove muốn xóa nhiều package như vậy?

Vì dnf xóa các dependency mà không còn thành phần nào khác cần trong cùng transaction, còn apt remove giữ chúng lại cho đến khi bạn chạy riêng apt autoremove. Vì vậy, một thao tác gỡ package trông nhỏ trên Ubuntu có thể in ra một danh sách dài trên Rocky Linux. Danh sách này thường là chính xác, nhưng hãy đọc trước khi xác nhận. Nếu có package trong danh sách mà bạn muốn giữ, hãy cài đặt rõ ràng package đó trước để dnf ghi nhận rằng package này được bạn chủ động yêu cầu.