RHEL 基礎 #3 dnf とパッケージ管理 — repo、modules、AppStream

インフラ Linux RHEL dnf パッケージ管理
読了 11分

#2 で RHEL マシンを立ち上げて登録まで終えました。次は その上に何かをインストールしたり削除したりする作業 を扱う番です。RHEL のパッケージ管理は dnf 一つに統一されています。Ubuntu の apt と同じ役割です。

RHEL 基礎 シリーズでこの記事の位置:

rpm / yum / dnf — 一行で整理 #

まず混同しやすい三つの単語から整理しておきます。

ツール扱う対象一行で
rpm.rpm ファイル一つ依存関係の自動解決なし。直接受け取った .rpm をインストールするときだけ稀に使う。
yumリポジトリ + 依存関係RHEL 5~7 の標準。RHEL 8 からは事実上 dnf の別名。
dnfリポジトリ + 依存関係 + modulesRHEL 8 から標準。Python で書き直された yum。

RHEL 9 では yum コマンドを叩いても動きます。単に dnf へのシンボリックリンクになっているだけです。新しい資料を検索したり新しいコマンド (dnf module) を使うなら dnf で統一する方が良いです。

確認 
$ which yum
/usr/bin/yum
$ ls -l /usr/bin/yum
lrwxrwxrwx. 1 root root 5 ... /usr/bin/yum -> dnf-3

dnf の日常コマンド群 #

一番よく使うコマンドから。

検索 — search / info / list #

パッケージを探す 
$ dnf search nginx
=================== Name & Summary Matched: nginx ===================
nginx.aarch64 : A high performance web server and reverse proxy server
nginx-mod-http-image-filter.aarch64 : Nginx HTTP image filter module
...

$ dnf info nginx
Name         : nginx
Version      : 1.20.1
Release      : 20.el9
Architecture : aarch64
Size         : 593 k
Source       : nginx-1.20.1-20.el9.src.rpm
Repository   : rhel-9-for-aarch64-appstream-rpms
Summary      : A high performance web server and reverse proxy server
URL          : https://nginx.org
License      : BSD
Description  : ...

info のほうが情報量が多くてよく見ます。Repository の項目でどのリポジトリから来たか分かります — 上の例では AppStream リポジトリ。

一覧 
$ dnf list installed | head           # インストール済みパッケージ
$ dnf list available nginx*           # インストール可能なパッケージ
$ dnf list updates                    # アップデート可能なパッケージ

インストール — install #

インストール 
$ sudo dnf install nginx
Dependencies resolved.
============================================================
 Package                Arch     Version           Repository      Size
============================================================
Installing:
 nginx                  aarch64  1:1.20.1-20.el9   appstream      593 k
Installing dependencies:
 nginx-filesystem       noarch   1:1.20.1-20.el9   appstream       11 k
 ...

Transaction Summary
============================================================
Install  6 Packages

Total download size: 1.3 M
Installed size: 4.2 M
Is this ok [y/N]:

複数まとめてインストールでき (dnf install nginx git vim)、依存関係も自動で引き連れます。自動 yes が必要なら -y を付けます。自動化スクリプトではよく使いますが、手動作業では依存リストを一度見て決める習慣が良いです。

ローカルの .rpm をインストール 
$ sudo dnf install ./some-package.rpm

ダウンロードした単一の .rpm ファイルも dnf install でインストールすれば依存関係を自動で解決してくれます。rpm -i よりほぼ常にこちらが正解です。

削除 — remove #

削除 
$ sudo dnf remove nginx
Dependencies resolved.
=========================================================
Removing:
 nginx              ...
Removing unused dependencies:
 nginx-filesystem   ...

インストール時に一緒に引っ張ってきた依存関係も他で使われていなければ自動で片付けられます (autoremove 動作が組み込み)。Ubuntu で apt remove + apt autoremove の二段階を踏むのを一度で。

落とし穴 — dnf remove がコアパッケージ (例: systemd、kernel) まで一緒に消そうとしたら即座に止まって入力確認を見直してください。依存関係が四方に絡んでいるところでは、パッケージ一つ消したつもりがシステムが起動不能になることもあります。知らない依存リストは必ず立ち止まって読んでください。

アップデート — update / upgrade #

アップデート 
$ sudo dnf check-update           # アップデート可能なものだけ確認 (変更なし)
$ sudo dnf update                 # 全パッケージを最新に
$ sudo dnf update nginx           # 一つだけ

update と upgrade は RHEL/dnf では事実上同じ動作です (他のディストリビューションでは違うこともあります)。通常は update をよく使います。

依存関係の追跡 — repoquery #

深く入るときによく使うコマンドです。

repoquery 
$ dnf repoquery --requires nginx       # nginx が依存しているもの
$ dnf repoquery --whatrequires nginx   # nginx に依存しているもの
$ dnf repoquery -l nginx               # パッケージがインストールするファイル一覧
$ dnf repoquery --provides nginx       # パッケージが提供する仮想名

特に dnf repoquery -l <パッケージ> — どのパッケージがどのファイルを置いたか追うときによく使います。

dnf history — 時を巻き戻すコマンド #

最も RHEL らしい機能。すべての dnf トランザクションが履歴に残り、トランザクション単位で巻き戻せます。

履歴を見る 
$ sudo dnf history
ID  | Command line          | Date and time    | Action(s)   | Altered
----------------------------------------------------------------------
 12 | install nginx          | 2026-04-11 14:23 | Install     |    6
 11 | update -y              | 2026-04-11 09:01 | I, U        |   42
 10 | install git vim        | 2026-04-10 17:45 | Install     |    8
  9 | system upgrade ...     | 2026-04-10 16:02 | Install     |  362
特定の履歴を詳しく 
$ sudo dnf history info 12
Transaction ID : 12
Begin time     : 2026-04-11 14:23:08
Command Line   : install nginx
Packages Altered:
    Install nginx-1:1.20.1-20.el9.aarch64        @appstream
    Install nginx-filesystem-1:1.20.1-20.el9.noarch  @appstream
    ...
巻き戻し / 再適用 
$ sudo dnf history undo 12      # 12 番目のトランザクションを巻き戻す
$ sudo dnf history redo 12      # 再適用

運用でよく使うのは 障害直後の dnf history です。「さっき何を変えたんだっけ?」の答えがそこにあります。apt にはない機能です。

BaseOS と AppStream — 二つのリポジトリが分かれている理由 #

#2 で dnf repolist を叩くと二行出ました。

リポジトリ一覧 
$ dnf repolist
repo id                               repo name
rhel-9-for-aarch64-appstream-rpms     Red Hat Enterprise Linux 9 - AppStream
rhel-9-for-aarch64-baseos-rpms        Red Hat Enterprise Linux 9 - BaseOS

二つのリポジトリが別々にある理由があります。

BaseOS — 変わらない OS コア #

BaseOS の中身 
カーネル / glibc / systemd / coreutils / openssl / NetworkManager
        ↑ OS が OS として動くのに必須の部品

RHEL 9 のライフサイクル (10 年) の間、メジャーバージョンはほぼ変わりません。 セキュリティパッチだけが入ります。「運用中システムの安定性」が BaseOS の約束です。

AppStream — 速く変えられる応用パッケージ #

AppStream の中身 
PostgreSQL / Python / Node.js / nginx / Apache / Redis / Ruby / PHP / ...
        ↑ 人間が選んでインストールする応用 / 言語 / DB / サーバー

ここでは 同じ RHEL 9 の中でも別のメジャーバージョンを選んでインストールできます。PostgreSQL 13 / 15 / 16、Python 3.9 / 3.11 / 3.12 という具合に。これを可能にするのが modules です。

この分離は RHEL 8 から導入された AppStream のコンセプトです。RHEL 7 までは一つのパッケージに一つのメジャーバージョンしか入れられず、PostgreSQL の新バージョンを使うには外部リポジトリ (postgresql.org の PGDG repo) を追加する必要がありました。AppStream 以後は RHEL 公式リポジトリの中で選べるようになりました。

dnf module — 同じパッケージの複数バージョン #

PostgreSQL を例に見ます。

モジュール一覧 
$ dnf module list postgresql
Red Hat Enterprise Linux 9 for aarch64 - AppStream
Name         Stream    Profiles                  Summary
postgresql   13        client, server [d]        PostgreSQL server and client module
postgresql   15        client, server [d]        PostgreSQL server and client module
postgresql   16        client, server [d]        PostgreSQL server and client module

三つのメジャーバージョンが見えます。各バージョンの隣の Stream がそのバージョンの識別子で、Profile は「どんな用途でインストールするか」をまとめておいたセットです。

特定バージョンを有効化 + インストール 
$ sudo dnf module enable postgresql:16
$ sudo dnf module install postgresql:16/server

postgresql:16 でモジュール stream を有効化し、postgresql:16/server で server profile をインストールします。有効化された stream はシステムに一度に一つだけ — 同じマシンに PG 13 と PG 16 を同時に置くことはできません (それはコンテナで)。

モジュール情報の確認 / 無効化 
$ dnf module info postgresql:16
$ sudo dnf module disable postgresql        # すべての stream を無効化 (削除前に)
$ sudo dnf module reset postgresql          # 有効化 / 無効化を初期化

どの stream を選ぶか #

default が表示されている ([d]) stream をそのまま選ぶのが一番無難です。RHEL 9 に入っているその stream は RHEL のライフサイクル終了まで (またはモジュールによっては 5 年) パッチが保証 されます。

特定のバージョンを明示的に固定したいときだけ stream を選んで有効化します。一度 stream を決めると dnf update がその stream の中でマイナーアップデートだけ適用するので — ある日突然 PG 16 が PG 17 にジャンプすることはありません。

2026 年メモ — ユーザーパターンを見て RHEL 10 から modules の比重が下がる兆しがあります。新しい RHEL ほど “default stream” だけのモジュールも増えていますが、それでも RHEL 9 では modules が中核にあります。

外部リポジトリ — EPEL、COPR #

RHEL 公式リポジトリ (BaseOS + AppStream) にないパッケージが必要なときに二つがよく使われます。

EPEL — Extra Packages for Enterprise Linux #

Fedora コミュニティが RHEL 互換でビルドしている 追加パッケージ集。RHEL 自体にないツール (例: htop、ncdu、bat、tmux の一部モジュール) がここにあります。

EPEL を有効化 
$ sudo dnf install -y epel-release
$ sudo dnf repolist
repo id                          repo name
epel                             Extra Packages for Enterprise Linux 9
epel-cisco-openh264              ...
rhel-9-for-aarch64-appstream-rpms ...
rhel-9-for-aarch64-baseos-rpms    ...

これで EPEL のパッケージをインストールできます。

EPEL パッケージのインストール 
$ sudo dnf install htop ncdu

AlmaLinux / Rocky ユーザー — epel-release をインストールするとき dnf の動きが少し違うことがあります。通常は sudo dnf config-manager --set-enabled crb で CodeReady Linux Builder (CRB) リポジトリを先にオンにしないと EPEL の一部パッケージの依存関係が満たされません。RHEL にも CRB があります (subscription-manager repos --enable codeready-builder-for-rhel-9-aarch64-rpms)。

COPR — 個人プロジェクト用 #

Fedora の COPR はユーザーが作った臨時リポジトリを集めたところ。正式に EPEL に入る前段階のツールや、メンテナが一人のパッケージを取得するのに使います。

COPR を使う 
$ sudo dnf copr enable some-user/some-project
$ sudo dnf install some-package

運用には 推奨しません。メンテナがいなくなるとセキュリティパッチが切れます。学習・実験用にだけ。

外部リポジトリを追加するときに気を付けること #

項目なぜ
信頼できるリポジトリだけrpm は root でインストールされる。悪意あるパッケージなら終わり
GPG 署名検証gpgcheck=1 がオンであること (デフォルト)
優先度 (priority)外部リポジトリが RHEL コアパッケージを上書きすると困る
必要なときだけ有効化enabled=0 にしておき --enablerepo でその時だけオンに

運用マシンでは EPEL くらいだけオンにし、それ以外はできるだけ RHEL 公式リポジトリの中で解決するのが安全な道です。

subscription-manager でリポジトリをオン/オフ #

RHEL (AlmaLinux/Rocky ではなく) のマシンでは BaseOS / AppStream 以外にも追加リポジトリがあります。subscription によります。

有効/無効化可能なリポジトリ 
$ sudo subscription-manager repos --list | head -30
+----------------------------------------------------------+
    Available Repositories in /etc/yum.repos.d/redhat.repo
+----------------------------------------------------------+
Repo ID:   rhel-9-for-aarch64-supplementary-rpms
Repo Name: Red Hat Enterprise Linux 9 for ARM 64 - Supplementary (RPMs)
Repo URL:  ...
Enabled:   0

Repo ID:   codeready-builder-for-rhel-9-aarch64-rpms
Repo Name: Red Hat CodeReady Linux Builder for RHEL 9 ARM 64 (RPMs)
...
Enabled:   0

特定のリポジトリをオンに:

CRB をオンに 
$ sudo subscription-manager repos \
    --enable codeready-builder-for-rhel-9-aarch64-rpms

$ sudo dnf repolist | grep code
codeready-builder-for-rhel-9-aarch64-rpms ...

EPEL の一部パッケージが CRB の依存関係を要求するため、EPEL をオンにするときに一緒にオンにすることがよくあります。

よく使うコマンド一表 #

この記事で広く使ったコマンドを一表にまとめます。覚える必要はなく、詰まったら戻ってきてください。

コマンドする仕事
dnf install <pkg>パッケージ + 依存関係をインストール
dnf remove <pkg>パッケージ + 不要な依存関係を削除
dnf update [<pkg>]全体または特定のパッケージをアップデート
dnf check-updateアップデート可能性だけ確認
dnf search <query>名前・概要から検索
dnf info <pkg>パッケージの詳細情報
dnf list installed/available/updates一覧
dnf repoquery -l <pkg>パッケージがインストールしたファイル一覧
dnf repoquery --whatrequires <pkg>このパッケージに依存しているもの
dnf history / history info N / history undo Nトランザクション履歴とロールバック
dnf module list <pkg>モジュール stream 一覧
dnf module enable <pkg>:<stream>モジュール stream の有効化
dnf module install <pkg>:<stream>/<profile>モジュールのインストール
dnf repolist [--all]リポジトリ一覧
dnf config-manager --set-enabled <repo>リポジトリをオン
subscription-manager repos --enable <repo>RHEL リポジトリをオン

よく出会う落とし穴 #

「パッケージが見つからない」 #

検索できないときはたいていどちらかです。

  1. リポジトリが無効 — dnf repolist で確認。AppStream がオフだと応用パッケージが見えません。
  2. EPEL など外部リポジトリが必要 — htop、ncdu のようなものは RHEL 公式にはありません。

「キャッシュが変」 #

古いメタデータで dnf が混乱したとき:

キャッシュを空に 
$ sudo dnf clean all
$ sudo dnf makecache

「modules が衝突する」 #

dnf install postgresql-server を叩いたら「module が無効化されているのでインストールできない」系のエラーが出たら、そのモジュールを有効化していないということです。dnf module list postgresql で stream を確認してから dnf module enable postgresql:16。

たまに二つのモジュールが同じパッケージを取り合って衝突したら dnf module reset <パッケージ> で初期化してから再度有効化。

「EPEL を入れたのに依存関係が解決しない」 #

ほぼ 99% は CRB (CodeReady Linux Builder) がオンになっていないケース。上で扱った subscription-manager repos --enable codeready-builder-... または AlmaLinux/Rocky なら dnf config-manager --set-enabled crb。

まとめ #

この記事で押さえた絵:

  • rpm (単一ファイル) / yum (旧名) / dnf (現在の標準) — RHEL 9 では dnf に統一。
  • 日常は install / remove / update / search / info / list だけでほぼ事足りる。
  • dnf history と history undo が RHEL らしい機能 — トランザクション単位でロールバック可能。
  • BaseOS は OS コア (10 年安定)、AppStream は応用 (複数バージョン)。
  • modules で PostgreSQL 13/15/16 のような同じパッケージの複数メジャーバージョンを選んでインストールできる。
  • EPEL は Fedora が作る RHEL 互換の追加リポジトリ — htop、ncdu のようなツールの出処。CRB と一緒にオンにすることが多い。
  • 外部リポジトリは 信頼できるところだけ / GPG 検証をオン / 運用には EPEL くらいだけ。

次 — systemd #

これでパッケージのインストールができるようになりました。次に扱うのは インストールしたものをどう立ち上げて止めて、起動時に自動で上がるようにするか — それが systemd の仕事です。

#4 systemd 入門 — サービス、target、journalctl では systemd が PID 1 としてどのようにシステム全体を握っているか、systemctl start / stop / enable / status のコマンド群、target (multi-user / graphical / rescue) の意味、最初の .service ユニットファイルを直接書いて立ち上げてみる、そして journalctl ですべてのサービスログを一箇所で見る流れまでを押さえます。

X