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

Câu trả lời ngắn

Chuyển từ apt sang dnf phần lớn chỉ là thay đổi thuật ngữ. 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 package group và chạy update không cần giám sát.

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

Bản phân phối 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 từ RHEL: Rocky Linux, AlmaLinux và CentOS Stream. apt là package manager trên Debian và mọi hệ điều hành 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.

Định dạng package đi cùng 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ọ hệ điều hành. Đây cũng là lý do .deb tải từ trang release của một project sẽ không dùng được trên Rocky Linux.

Dù bạn chọn họ hệ điều hành nào, các việc cần làm khi đăng nhập lần đầu vẫn giống nhau. Mười phút đầu tiên trên một VPS mới áp dụng cho cả hai. Chỉ 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ỡ cài đặt, tìm kiếm và xem thông tin. Hai bên dùng gần như cùng một cú pháp.

# 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 này, nhưng có một khác biệt về hành vi dễ gây nhầm lẫn. dnf remove cũng gỡ các dependency mà không còn gói nào khác cần, còn apt remove giữ chúng lại để dùng cho một apt autoremove sau này. 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 có trên ổ đĩa và có thể cài một phiên bản đã rời archive từ nhiều tháng trước. dnf kiểm tra độ cũ 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 metadata ngay lúc này thay vì chờ đến lần cài đặt tiếp theo.

apt chia việc nâng cấp toàn bộ hệ thống thành hai mức, còn dnf thì không. apt upgrade từ chối gỡ bất kỳ package nào đã cài, nên sẽ dừng lại khi một 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, nên 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 quan trọng khi viết script: dnf check-update trả về status 100 khi đang có bản cập nhật chờ xử lý và 0 khi không có. apt list --upgradable trả về 0 trong cả hai trường hợp, nên script phải phân tích 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 khối 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 chúng trả lời câu hỏi “package nào đã đặt file này ở đây”. apt-file search và dnf provides tìm trong repository, nên chúng 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 thêm gì, dù lần chạy đầu tiên có thể chậm vì dnf tải các file danh sách của repository để thực hiện tìm kiếm.

Để 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ỡ package không còn cần, 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ẽ lỗ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 thêm gì cho apt-mark hold, vì việc giữ package là một trạng thái của dpkg chứ không phải plugin.

Khi cách ánh xạ không còn đúng: thêm một repository

Đây là phần khiến quản trị viên 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ó các kho package cá nhân (PPA). PPA là một dịch vụ do Launchpad vận hành, 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 file plain text cho mỗi repository trong /etc/yum.repos.d/, với phần mở rộng .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 của 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 đó và hướng dẫn bạn tải về. 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ả là như nhau. Cài đặt Docker trên VPS trình bày phần tương ứng trên Debian, trong đó bước này ghi source list và signing key vào 2 thư mục khác nhau.

Sự khác biệt về cấu trúc 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 bạn chỉ cần đọc một file và xóa một file. Các phiên bản apt mới hơn đang chuyển sang cấu trúc tương tự bằng định dạng deb822, với 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 tương ứng của apt trong vấn đề này.

EPEL là kho 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 xây dựng 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 trong hệ sinh thái này, và rất nhiều hướng dẫn giả định rằng nó đã đượ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 package trong đó, nên việc enable EPEL mà chưa enable CRB sẽ không fail ngay lúc đó. Nó chỉ fail về sau, tại thời điểm cài đặt, với lỗi dependency chưa được thỏa mãn đối với 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 chính thức của Red Hat cho bước đó. Fedora không cần những bước này vì repository chính của Fedora đã chứa các package mà EPEL backport. Chính sách của EPEL là không bao giờ thay thế package do RHEL phát hành, nên việc thêm repository này không thay đổi bất kỳ thứ gì đã được cài trên server của bạn.

dnf history undo, điều apt không làm đượ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 transaction được đánh số, kèm 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 về 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ế, và bạn nên biết rõ 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 bật. Vì vậy, khi bản 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ỉ dừng ở package database. Nếu bản nâng cấp đã ghi đè config file thì file đó vẫn bị ghi đè. Nếu service đã migrate database schema trong lần khởi động đầu tiên thì schema vẫn ở trạng thái đã migrate. 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 lại 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 recovery phía apt là làm thủ công: chạy apt list -a nginx để xem archive vẫn còn các version nào, sau đó chạy sudo apt install nginx=<exact version string> để pin một version, rồi 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.

Package groups 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 hướng dẫn cũ thường ghi dnf groupinstall "Development Tools". Alias đó hoạt động trên dnf 4 nhưng đã 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ó groups. 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 một metapackage vẫn giữ các dependency của nó cho đến khi bạn chạy apt autoremove, trong khi dnf group remove sẽ gỡ các package thuộc group 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 công cụ 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 khai báo 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ề reboot đi kèm.

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

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 đều 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 trong file cấu hình.

Để chỉ giới hạn ở các bản vá 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ó công bố security errata hay không, vì vậy trước tiên hãy kiểm tra bằng dnf updateinfo list security. Nếu kết quả trống trên một máy đang có bản cập nhật chờ xử lý, metadata chưa có security errata. Khi đó, security sẽ không cài đặt gì cả.

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

yum vẫn là một lệnh thực không?

Có. Nhưng bản thân nó không làm gì cả. Trên Rocky Linux, AlmaLinux và CentOS Stream, /usr/bin/yum là symbolic link trỏ đến dnf. Kiểm tra trên hệ thống 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 một lệnh

dnf 5 được 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 phân phối enterprise rebuild 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.

Ví dụ rõ nhất là Docker, vì Docker cung cấp một lệnh repository khác nhau cho mỗi 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 vendor, cùng mục đích, nhưng cách viết khác nhau. dnf 5 đã biến config-manager thành công cụ điều khiển bằng subcommand, nên flag --add-repo cũ không được chấp nhận và bạn sẽ nhận lỗi usage thay vì một repository. Trường hợp khác bạn sẽ gặp là bật mộ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 vào package manager là sai trọng tâm. dnf và apt thực hiện cùng một công việc, còn việc làm quen với cách gọi chỉ mất một buổi chiều. Điều ảnh hưởng đến cả năm sử dụng của bạn là mô hình phát hành phía sau repository. Fedora phát hành nhanh và một bản phát hành cụ thể sẽ ngừng nhận update khoảng mười ba tháng sau khi ra mắt. Điều này phù hợp với workstation nhưng gây nhiều bất tiện cho server mà bạn không muốn phải cài dựng lại. Rocky Linux và AlmaLinux bám theo RHEL, nên bạn có thời hạn hỗ trợ mười năm và các phiên bản package được cố ý giữ ổn định. Ubuntu cung cấp cả hai mô hình, và sự khác biệt giữa Ubuntu LTS và bản phát hành interim trên server cũng 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 thông dụng. Hãy chọn thời hạn hỗ trợ phù hợp với bạn, rồi học mười lệnh ở 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. dnf kiểm tra độ cũ của metadata trong cache trước mỗi transaction và tải bản mới khi metadata đã hết hạn. Vì vậy, dnf install trên một server bạn không đụ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 bản mới, nhưng mục đích thực tế là chuyển thời điểm chờ sang lúc bạn chọn, thay vì để nó xảy ra 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 tương ứng với apt list --upgradable và thoát với status 100 khi có bản cập nhật.

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

Không. Personal package archive là 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 sang. Tương đương RPM là một file .repo trong /etc/yum.repos.d/, chứa một name, một baseurl và một gpgkey. Vendor publish file đó cho bạn. sudo dnf config-manager --add-repo <url> trên dnf 4 hoặc sudo dnf config-manager addrepo --from-repofile <url> trên dnf 5 sẽ tải file vào đúng vị trí. Với phần mềm bổ sung thông thường, câu trả lời thường là EPEL. Bạn enable EPEL bằng sudo dnf config-manager --set-enabled crb, sau đó chạy sudo dnf install epel-release.

Tôi có thể hoàn tác một lần nâng cấp dnf 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>. Thao tác hoàn tác sẽ fail nếu version package cũ không còn trong bất kỳ repository nào đang được enable, vì dnf không có gì để cài lại. Thao tác này cũng chỉ đảo ngược các thay đổi của package. File cấu hình bị lần nâng cấp ghi lại, hoặc database được service migrate khi khởi động lần đầu, vẫn giữ nguyên. apt hoàn toàn không có lệnh tương đương, chỉ có 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 đế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, bạn thực chất đang chạy dnf, nên hầu hết tutorial cũ vẫn hoạt động. Hãy dùng dnf trong script và tài liệu mới, vì tên yum chỉ tồn tại để tương thích. Đồng thời nên ưu tiên 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 package 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 có vẻ nhỏ trên Ubuntu có thể hiển thị 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ữ lại, hãy cài đặt rõ ràng package đó trước để dnf ghi nhận rằng package được yêu cầu độc lập.