dnfがaptと違うところ

一言でいうと

dnfの決定的な違いは、すべてのインストールがトランザクションとして記録され、元に戻せることです。aptには、これに対応する機能がありません。

なぜ必要なのか

Ubuntuから移ってきた人が最初に驚くのが、この点です。

dnf history                    # 지금까지의 모든 트랜잭션 목록
dnf history info 42            # 42번 트랜잭션에서 무엇이 바뀌었나
dnf history undo 42            # 42번을 되돌린다
dnf history rollback 41        # 41번 시점의 상태로 되돌린다

aptには/var/log/apt/history.logという記録はありますが、元に戻すコマンドはありません。この違いが運用の方法を変えます。RHEL系では「とりあえずインストールしてみて、違えば元に戻す」が可能です。

ただし、限界は明確です。以前のバージョンのパッケージがリポジトリになければ、ダウングレードは失敗します。そしてRed Hatは、システムパッケージ(selinux、selinux-policy、kernel、glibc、およびglibcに依存するgccなど)のダウングレードをサポートしないと明記しています。ロールバックは万能ではありません。

どう動くのか

コマンド対応表

作業	apt	dnf
インデックスの更新	`apt-get update`	(自動。必要なら`dnf makecache`)
インストール	`apt-get install X`	`dnf install X`
削除	`apt-get remove X`	`dnf remove X`
検索	`apt-cache search X`	`dnf search X`
情報	`apt-cache show X`	`dnf info X`
ファイル→パッケージ	`dpkg -S /path`	`dnf provides /path` (未インストールも含む)
インストール済みファイルの一覧	`dpkg -L X`	`rpm -ql X`
アップグレード	`apt-get upgrade`	`dnf upgrade`
バージョン固定	`apt-mark hold`	`dnf versionlock add`
ロールバック	なし	`dnf history undo`

dnf providesが特に強力です。aptのdpkg -Sはすでにインストール済みのファイルしか探せませんが、dnf providesは、リポジトリのメタデータを調べて、まだインストールされていないパッケージまで探してくれます。

dnf provides '*/nginx.conf'
dnf provides 'libnl-3.so.200()(64bit)'

2つ目の例が重要です。RPMでは、依存関係の単位はパッケージ名ではなくケイパビリティ(capability)です。共有ライブラリのsoname、ファイルパス、さらにはシンボルバージョンまでが、依存の対象になります。

dnf repoquery --requires httpd
dnf repoquery --requires --resolve --recursive httpd | sort -u | wc -l

--requiresは要求するケイパビリティ、--resolveはそのケイパビリティを提供するパッケージへの置き換え、--recursiveは再帰的に下へたどり続けることです。エアギャップ環境の持ち込みリストを作るときの、核心となるツールです。

リポジトリファイル

# /etc/yum.repos.d/labhub-local.repo
[labhub-local]
name=LabHub local (snapshot 2026-08-20)
baseurl=file:///srv/repo/labhub
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-labhub
metadata_expire=-1

各キーのデフォルト値を知っておくことが重要です。

enabledのデフォルトはTrue
gpgcheckのデフォルトはFalse: 明示的に有効にする必要があります
repo_gpgcheck(メタデータ署名の検証)のデフォルトはFalse
priorityのデフォルトは99
metadata_expireのデフォルトは48時間。エアギャップ環境のローカルリポジトリでは、-1(期限なし)にしておくほうがよいです
module_hotfixesのデフォルトはFalse

リポジトリの表示名にスナップショットの日付を入れておくと、半年後にdnf repolist -vの1行で、そのサーバーがいつの時点のコンテンツでインストールされたかがわかります。

キャッシュ

エアギャップ環境で最も多い報告が、「リポジトリにパッケージを入れたのに見えない」です。原因は、次の2つのどちらかです。

# 저장소 쪽: 메타데이터를 다시 만들었는가 (이걸 빼먹는 경우가 정말 많다)
createrepo_c --update /srv/repo/labhub
# 클라이언트 쪽: 캐시를 만료 표시 (가장 가벼움)
dnf clean expire-cache
# 그래도 안 되면
dnf clean metadata
# 최후의 수단
dnf clean all
dnf makecache

それぞれの定義: expire-cacheはメタデータに期限切れの印を付けるだけ、metadataはメタデータを削除、packagesはキャッシュされたパッケージを削除、allはすべてです。

現場での姿

dnf update --securityが、静かに「やることなし」で終わる場合。セキュリティ勧告(updateinfo)のメタデータがリポジトリにないと、そうなります。createrepo_cは、rpmファイルからprimary/filelists/otherだけを作れますが、勧告情報はrpmの中にありません。静かに何もしないという点が危険です。dnf updateinfo --summaryで確認する習慣が必要です。

次のラボですること

dnfでリポジトリを確認し、インストールし、providesで逆引きし、履歴でロールバックし、バージョンを固定します。