dnf apt rpm dpkg LinuC101 第6回

新卒インフラエンジニア向けLinuC 101 試験対策シリーズの第6回です。前回はコンテナと仮想マシンを動かして「実行レイヤー」の違いを学びました。今回はもう一段下に降り、そのソフトウェアそのものを、どう入手し、どう更新し、どう削除するかを扱います。

本シリーズで 唯一 AlmaLinux と Ubuntu の両方を本格的に使う回です。RHEL系の dnf / rpm と Debian系の apt / dpkg を比較しながら、現場で「どっちのコマンドだっけ？」と一瞬で頭を切り替えられる地力を作ります。

今ここマップ

LinuC 101 試験対策シリーズ（全12回）

  第1回 Linuxの起動・接続・停止
  第2回 ブートプロセスの仕組み
  第3回 systemdマスター講座
  第4回 プロセス管理とハードウェア基礎
  第5回 仮想マシンとコンテナの基礎
▶ 第6回 パッケージ管理マスター    ← いまここ
  第7回 ファイル操作の実践
  第8回 パーミッション・所有者・特殊権限
  第9回 コマンドライン・リダイレクト・パイプ
  第10回 テキスト処理（grep / sed / awk）
  第11回 vi/vim 入門
  第12回 ディスク・パーティション・ファイルシステム

この記事で身につくこと

1. RHEL系（dnf / rpm）と Debian系（apt / dpkg）の役割分担を説明できる
2. AlmaLinux で dnf list / search / info / install / remove / history / repolist を使い分けられる
3. Ubuntu で apt update / install / remove / search / show / list と dpkg -l / -L / -S を使い分けられる
4. リポジトリ設定（/etc/yum.repos.d/*.repo と /etc/apt/sources.list*）の構造を読める
5. 依存関係解決の仕組みと、低レベルツール（rpm -i / dpkg -i）の落とし穴を理解している

第1章：なぜパッケージ管理が必要か

サーバーで動く1つのソフトウェアは、無数の他のソフトウェアに支えられています。共有ライブラリ、設定ファイル、起動スクリプト、man ページ、ロゴアイコン、ロケールデータ……「nginx を入れる」という単純な行為の裏側で、十数個の関連パッケージが連動して配置されます。

これを すべて手作業 でやろうとすると何が起きるか、想像してみてください。

• OpenSSL のバージョンを上げたら依存している httpd が起動しなくなった
• サーバーAでは入っているライブラリがサーバーBには無く、再現性がない
• 3年前に手で展開したソフトの依存ファイルが何だったか誰も覚えていない
• CVE が公表されたが、影響を受けるサーバーの一覧が作れない

こうした問題を一気に解決するのが パッケージ管理システム です。配布・依存解決・更新・削除・監査を、すべて統一の仕組みに乗せることが目的です。

誰のための仕組みか

• 本番運用者：「このサーバーに何が入っているか」を秒で答えられる必要がある（再現性・監査）
• 開発者：新しいマシンに開発環境を素早く展開したい
• セキュリティ担当：CVE 公表時に「影響範囲のサーバー一覧 → 一括更新」を回したい
• そして自分自身：3年後の自分が同じシステムをメンテできるように

「パッケージ管理コマンドを覚える」は 暗記の話 に見えて、本質は「誰のために何を再現可能にするか」という運用設計の話です。この視点を持って各コマンドを見ていきます。

第2章：2大ファミリー — RHEL系と Debian系

Linux ディストリビューションは数百種類ありますが、パッケージ管理の系統は大きく2つに集約されます。

項目	RHEL系（Red Hat 系）	Debian系
代表的なディストロ	RHEL / AlmaLinux / Rocky Linux / CentOS Stream / Fedora	Debian / Ubuntu / Linux Mint / Raspberry Pi OS
パッケージ拡張子	.rpm	.deb
高レベルツール	dnf（旧 yum）	apt（旧 apt-get）
低レベルツール	rpm	dpkg
主リポジトリ設定	/etc/yum.repos.d/*.repo	/etc/apt/sources.list と sources.list.d/
GPG鍵置き場	/etc/pki/rpm-gpg/	/usr/share/keyrings/ や /etc/apt/keyrings/

本シリーズの検証環境では、linuc-alma が RHEL系（AlmaLinux 9.6）、linuc-ubuntu が Debian系（Ubuntu 24.04 LTS）です。記事ではこの2台を行き来して、対応関係を確認しながら学びます。

第3章：高レベル vs 低レベル — 2階層モデル

RHEL系・Debian系どちらにも 2つの層 があります。これを理解しておくと、現場でトラブルが起きたときに「どの層を見るべきか」を切り分けられます。

高レベル層は「ネット越しの調達」を扱います。リポジトリのメタデータを取りに行き、依存関係を解析し、必要なパッケージを集めてくる役割。低レベル層は「目の前のファイルを扱う」役割。ダウンロード済みの .rpm / .deb ファイルを実際に展開し、システムに登録します。

なぜ2層に分かれているのか

「依存解決」と「ファイル展開」を分離することで、いくつかの重要なメリットが生まれます。

• オフラインインストール：先に .rpm / .deb ファイルを別マシンで集めておき、ネットの無いサーバーで rpm -i / dpkg -i で展開できる
• 低レベル調査：「このパッケージのファイル一覧を見たい」「壊れていないか確認したい」だけのときに、リポジトリと通信せず瞬時に答えられる
• デバッグの切り分け：ネット側で詰まっているのか、ファイル展開で詰まっているのかが分かる

逆に、低レベル層を直接使うと依存関係が壊れることがあります。これは第7章でヒヤリハットとして紹介します。

第4章：AlmaLinux 側 — dnf と rpm

まず linuc-alma で RHEL系のパッケージ管理を一通り体験します。すでに SSH ログインしている前提で進めます。

4.1 dnf — 状態の把握

linuc-almaで実行：

$ dnf list installed | wc -l

実行結果：

420

導入済みパッケージは約420個。ヘッダー行（「インストール済みパッケージ」）が含まれるため、実数は419個です。なお、この件数は前の回までに導入したパッケージの累積で前後します（本シリーズを第1回から通して進めた場合、第4回・第5回の導入分で数件多くなります）。

linuc-almaで実行：

$ dnf list installed | head -8

実行結果：

インストール済みパッケージ
NetworkManager.x86_64                  1:1.52.0-3.el9_6               @anaconda
NetworkManager-libnm.x86_64            1:1.52.0-3.el9_6               @anaconda
NetworkManager-team.x86_64             1:1.52.0-3.el9_6               @anaconda
NetworkManager-tui.x86_64              1:1.52.0-3.el9_6               @anaconda
aardvark-dns.x86_64                    2:1.16.0-1.el9                 @appstream
acl.x86_64                             2.3.1-4.el9                    @anaconda
almalinux-gpg-keys.x86_64              9.6-1.el9                      @anaconda

3列目の @anaconda は「OS インストール時に入った」という由来情報。@appstream は「AppStreamリポジトリから後で入れた」を意味します。パッケージごとに「どこから来たか」が記録されているのが重要なポイントです。

linuc-almaで実行：

$ dnf repolist

実行結果：

repo id                          repo の名前
appstream                        AlmaLinux 9 - AppStream
baseos                           AlmaLinux 9 - BaseOS
extras                           AlmaLinux 9 - Extras

有効なリポジトリは3本。BaseOS（OSの中核パッケージ）、AppStream（言語ランタイム・ミドルウェアなど用途別パッケージ）、Extras（追加ツール）の3層構成は AlmaLinux/RHEL の標準です。

4.2 dnf — 検索と詳細表示

linuc-almaで実行：

$ dnf search tree

実行結果（メタデータ取得行を省略）：

============================ 名前 & 概要 一致: tree ============================
tree.x86_64 : File system tree viewer
cockpit-ostree.noarch : Cockpit user interface for rpm-ostree
osbuild-ostree.noarch : OSTree support
ostree.x86_64 : Tool for managing bootable, immutable filesystem trees
ostree-grub2.x86_64 : GRUB2 integration for OSTree
（中略）
=============================== 名前 一致: tree ================================
git-subtree.x86_64 : Git tools to merge and split repositories
rpm-ostree.x86_64 : Hybrid image/package system

dnf search はパッケージ名と概要の両方を検索します。「名前 & 概要 一致」「名前 一致」のグルーピングで、関連度の高い順に表示されます。

linuc-almaで実行：

$ dnf info tree

実行結果：

利用可能なパッケージ
名前         : tree
バージョン   : 1.8.0
リリース     : 10.el9
Arch         : x86_64
サイズ       : 55 k
ソース       : tree-pkg-1.8.0-10.el9.src.rpm
リポジトリー : baseos
概要         : File system tree viewer
URL          : http://mama.indstate.edu/users/ice/tree/
ライセンス   : GPLv2+ and LGPLv2+
説明         : The tree utility recursively displays the contents of directories in a
             : tree-like format.  Tree is basically a UNIX port of the DOS tree
             : utility.

注目は リポジトリー : baseos の行。このパッケージがどのリポジトリから来るかが分かるので、運用設計時のリポジトリ依存性検討に役立ちます。

4.3 dnf — インストール・履歴・削除

linuc-almaで実行：

$ sudo dnf install -y tree

実行結果（末尾のみ）：

インストール済み:
  tree-1.8.0-10.el9.x86_64

完了しました!

linuc-almaで実行：

$ which tree
$ tree --version

実行結果：

/usr/bin/tree
tree v1.8.0 (c) 1996 - 2018 by Steve Baker, Thomas Moore, Francesc Rocher, Florian Sesser, Kyosuke Tokoro

linuc-almaで実行：

$ dnf history | head -10

実行結果：

ID     | コマンドライン           | 日時             | 動作           | 変更さ
-------------------------------------------------------------------------------
     5 | install -y tree          | 2026-05-10 01:02 | Install        |    1
     4 | install -y podman        | 2026-05-10 00:25 | I, U           |   23
     3 | -q install -y wget       | 2026-05-09 19:44 | Install        |    1
     2 | install -y bind-utils    | 2026-05-09 19:42 | I, U           |   10
     1 |                          | 2026-05-09 18:45 | Install        |  392 >E

過去すべての dnf 操作が ID 付きで記録されています。「先週末のメンテで何を入れたか」「昨日 dnf update で何が変わったか」が即座に追跡できる、運用上きわめて重要な機能です。

linuc-almaで実行：

$ dnf history info 5

実行結果（抜粋）：

トランザクション ID : 5
開始時間            : 2026年05月10日 01時02分06秒
ユーザー            : developer <developer>
終了コード          : 成功
コマンドライン      : install -y tree
変更されたパッケージ:
    インストール tree-1.8.0-10.el9.x86_64 @baseos

「いつ・誰が・何を入れたか」が監査可能なログとして残ります。ID は環境ごとに異なるので、自分の環境では dnf history の出力で先頭に出てきた数字を使ってください。

後片付けに削除しておきます。linuc-almaで実行：

$ sudo dnf remove -y tree

実行結果（末尾）：

削除しました:
  tree-1.8.0-10.el9.x86_64

完了しました!

4.4 リポジトリ設定ファイル

「どこから取りに行くか」を定義するのが /etc/yum.repos.d/ 配下の .repo ファイル群です。

linuc-almaで実行：

$ ls /etc/yum.repos.d/ | grep -v .bak

実行結果：

almalinux-appstream.repo
almalinux-baseos.repo
almalinux-crb.repo
almalinux-extras.repo
almalinux-highavailability.repo
almalinux-nfv.repo
almalinux-plus.repo
almalinux-resilientstorage.repo
almalinux-rt.repo
almalinux-sap.repo
almalinux-saphana.repo

BaseOS / AppStream / Extras 以外にも HighAvailability / NFV / RT（リアルタイム）/ SAP など多数のリポ定義があります。多くは enabled=0 で無効化されており、必要なときだけ有効化します。.bak ファイルは almalinux-release パッケージ更新時のバックアップなので無視して構いません。

1ファイルの中身を見てみます。linuc-almaで実行：

$ cat /etc/yum.repos.d/almalinux-baseos.repo | head -12

実行結果：

[baseos]
name=AlmaLinux $releasever - BaseOS
#mirrorlist=https://mirrors.almalinux.org/mirrorlist/$releasever/baseos
baseurl=https://repo.almalinux.org/almalinux/$releasever/BaseOS/$basearch/os/
enabled=1
gpgcheck=1
countme=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux-9
metadata_expire=86400
enabled_metadata=1

[baseos-debuginfo]

覚えておくべき4要素：

• baseurl：リポジトリの場所（URL）
• enabled：1なら有効、0なら無効
• gpgcheck：1ならGPG署名検証を行う（基本は1）
• gpgkey：検証に使うGPG公開鍵のパス

GPG鍵の実体は別ディレクトリ。linuc-almaで実行：

$ ls /etc/pki/rpm-gpg/

実行結果：

RPM-GPG-KEY-AlmaLinux-9  RPM-GPG-KEY-redhat-beta  RPM-GPG-KEY-redhat-release

4.5 rpm — 低レベルツール

rpm はパッケージDBに直接問い合わせるツール。ネットワーク不要、瞬時に応答します。クエリは -q から始まります。

linuc-almaで実行：

$ rpm -qa | wc -l

実行結果：

420

-qa は「全パッケージ問い合わせ（query all）」。dnf list installed と同じ実数になります（件数は環境や前の回までの累積で前後します）。

linuc-almaで実行：

$ rpm -qi bash | head -15

実行結果：

Name        : bash
Version     : 5.1.8
Release     : 9.el9
Architecture: x86_64
Install Date: 2026年05月09日 18時45分16秒
Group       : Unspecified
Size        : 7738730
License     : GPLv3+
Signature   : RSA/SHA256, 2024年05月01日 03時01分28秒, Key ID d36cb86cb86b3716
Source RPM  : bash-5.1.8-9.el9.src.rpm
Build Date  : 2024年04月30日 23時33分12秒
Build Host  : x64-builder01.almalinux.org
Packager    : AlmaLinux Packaging Team <packager@almalinux.org>
Vendor      : AlmaLinux
URL         : https://www.gnu.org/software/bash

-qi（query info）はパッケージの詳細情報。インストール日時、ベンダー、ライセンス、ビルドホストまで分かります。

linuc-almaで実行：

$ rpm -ql coreutils | head -8

実行結果：

/usr/bin/[
/usr/bin/arch
/usr/bin/b2sum
/usr/bin/base32
/usr/bin/base64
/usr/bin/basename
/usr/bin/basenc
/usr/bin/cat

-ql（query list）はパッケージが提供するファイル一覧。「cat はどのパッケージから来ているか？」を逆引きしたいときは -qf を使います。

linuc-almaで実行：

$ rpm -qf /usr/bin/ls
$ rpm -qf /bin/ls

実行結果：

coreutils-8.32-39.el9.x86_64
coreutils-8.32-39.el9.x86_64

注目：/usr/bin/ls でも /bin/ls でも、同じ結果が返ります。RHEL系では /bin は /usr/bin へのシンボリックリンクですが、rpm -qf はリンクを追跡して解決してくれます。あとで Ubuntu の dpkg -S はここで挙動が変わるので、対比して覚えてください。

linuc-almaで実行：

$ rpm -V coreutils

実行結果：

（出力なし）

-V（verify）はパッケージインストール時の状態と現在のファイルを比較する検証コマンド。出力が無ければ「全ファイル変更なし」を意味します。改ざん検知やトラブル時の状態確認に使う、現場の必殺技の1つです。

第5章：Ubuntu 側 — apt と dpkg

ここから Debian系を体験します。linuc-alma から SSH で linuc-ubuntu に乗り込みます。

5.1 linuc-ubuntu に SSH 接続

linuc-almaで実行：

$ ssh developer@10.0.10.133

初回接続時は SSH 鍵の確認が出ます。yes を入力。プロンプトの @host 部分が linuc-ubuntu に変わったことを確認してください。

linuc-ubuntuで実行：

$ cat /etc/os-release | head -5

実行結果：

PRETTY_NAME="Ubuntu 24.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.3 LTS (Noble Numbat)"
VERSION_CODENAME=noble

VERSION_CODENAME の noble は Ubuntu 24.04 のコードネーム（Noble Numbat）。リポジトリ設定で noble という単語が出てきたら「Ubuntu 24.04 用のパッケージ」を指します。

5.2 apt — メタデータ更新と状態把握

Debian系の癖の1つ：apt update は パッケージ本体の更新ではなく、メタデータ（パッケージ一覧）の更新です。新人が真っ先にハマるポイント。

linuc-ubuntuで実行：

$ sudo apt update

実行結果：

Hit:2 http://archive.ubuntu.com/ubuntu noble InRelease
Get:3 http://archive.ubuntu.com/ubuntu noble-updates InRelease [126 kB]
Hit:4 http://archive.ubuntu.com/ubuntu noble-backports InRelease
Get:5 http://archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages [1969 kB]
Get:6 http://archive.ubuntu.com/ubuntu noble-updates/universe amd64 Packages [1688 kB]
Fetched 3783 kB in 1s (3080 kB/s)
Reading package lists...
Building dependency tree...
Reading state information...
141 packages can be upgraded. Run 'apt list --upgradable' to see them.

「Hit」は変更なし、「Get」は更新を取得した、という意味。最終行に「141 packages can be upgraded」と出ていますが、実際の更新は apt upgrade で実施します。

linuc-ubuntuで実行：

$ apt list --installed 2>/dev/null | wc -l

実行結果：

477

2>/dev/null は「apt はスクリプト用途では非推奨」という警告メッセージを抑制するため。実数は477（見出し行を引いて476）です。

linuc-ubuntuで実行：

$ apt list --installed 2>/dev/null | head -8

実行結果：

Listing...
adduser/noble,now 3.137ubuntu1 all [installed,automatic]
amd64-microcode/noble-updates,noble-security,now 3.20250311.1ubuntu0.24.04.1 amd64 [installed,automatic]
apparmor/now 4.0.1really4.0.1-0ubuntu0.24.04.4 amd64 [installed,upgradable to: 4.0.1really4.0.1-0ubuntu0.24.04.6]
apport-core-dump-handler/noble-updates,noble-security,now 2.28.1-0ubuntu3.8 all [installed,automatic]
apport-symptoms/noble,now 0.25 all [installed,automatic]
apport/noble-updates,noble-security,now 2.28.1-0ubuntu3.8 all [installed,automatic]
appstream/noble,now 1.0.2-1build6 amd64 [installed,automatic]

各行の [installed,automatic] は「依存関係で自動的に入った」マーク。[installed] なら「ユーザーが明示的に指定して入れた」意味。これで「不要になった依存パッケージを掃除する」判断ができます。

5.3 apt — 検索と詳細表示

linuc-ubuntuで実行：

$ apt search '^tree$'

実行結果（警告省略）：

Sorting...
Full Text Search...
tree/noble-updates 2.1.1-2ubuntu3.24.04.2 amd64
  displays an indented directory tree, in color

'^tree$' は正規表現で「treeちょうど一致」。引数なしで apt search tree とすると関連パッケージが大量に出るので、絞り込みに正規表現が便利です。

linuc-ubuntuで実行：

$ apt show tree

実行結果（警告省略）：

Package: tree
Version: 2.1.1-2ubuntu3.24.04.2
Priority: optional
Section: universe/utils
Origin: Ubuntu
Installed-Size: 111 kB
Depends: libc6 (>= 2.38)
Homepage: http://oldmanprogrammer.net/source.php?dir=projects/tree
Download-Size: 47.4 kB
APT-Sources: http://archive.ubuntu.com/ubuntu noble-updates/universe amd64 Packages
Description: displays an indented directory tree, in color
 Tree is a recursive directory listing command that produces a depth indented
 listing of files, which is colorized ala dircolors if the LS_COLORS environment
 variable is set and output is to tty.

Section: universe/utils の universe は Ubuntu のコンポーネント分類。main（公式サポート）／restricted（プロプライエタリドライバ等）／universe（コミュニティ提供）／multiverse（ライセンス制限あり）の4つです。

5.4 apt — インストールと削除

linuc-ubuntuで実行：

$ sudo apt install -y tree

linuc-ubuntuで実行：

$ which tree
$ tree --version

実行結果：

/usr/bin/tree
tree v2.1.1 © 1996 - 2023 by Steve Baker, Thomas Moore, Francesc Rocher, Florian Sesser, Kyosuke Tokoro

AlmaLinux の tree は v1.8.0、Ubuntu の tree は v2.1.1。同じ「tree」でもディストロ間でバージョンが違うのは普通のこと。LTS 系列はバージョンを安定優先で固定するため、最新を追わない判断が入ります。

linuc-ubuntuで実行：

$ sudo apt remove -y tree

実行結果（一部抜粋）：

The following packages will be REMOVED:
  tree
0 upgraded, 0 newly installed, 1 to remove and 141 not upgraded.
After this operation, 111 kB disk space will be freed.
Removing tree (2.1.1-2ubuntu3.24.04.2) ...

apt remove は パッケージ本体のみ削除し、設定ファイルは残すのが標準動作。設定ファイルごと完全削除したいときは apt purge を使います。今回の tree は設定ファイルを持たないので結果は同じですが、後述の postfix や nginx 系では大きな違いになります。

5.5 リポジトリ設定（Ubuntu 24.04 の新形式）

Ubuntu 22.04 までと 大きく変わったポイントがここ。

linuc-ubuntuで実行：

$ cat /etc/apt/sources.list

実行結果：

# Ubuntu sources have moved to /etc/apt/sources.list.d/ubuntu.sources

従来の /etc/apt/sources.list は プレースホルダに変わっています。実体は別ファイル。linuc-ubuntuで実行：

$ cat /etc/apt/sources.list.d/ubuntu.sources

実行結果：

Types: deb
URIs: http://archive.ubuntu.com/ubuntu/
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

Types: deb
URIs: http://security.ubuntu.com/ubuntu/
Suites: noble-security
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

これは deb822 形式と呼ばれる新フォーマット。Key: Value 形式で1段落＝1リポジトリ群を表現します。Ubuntu 24.04（および現代の Debian 12 以降）から標準化されました。

従来の1行型（古いUbuntu/Debianで現役）：

deb http://archive.ubuntu.com/ubuntu noble main restricted universe multiverse
deb-src http://archive.ubuntu.com/ubuntu noble main restricted universe multiverse

1行型の構造：deb <URL> <suite=ディストロ名> <component...>。LinuC 試験では1行型が出題される可能性が高いので、両形式を読み比べて構造を把握してください。要素の意味は同じです。

5.6 GPG 鍵の置き場

Debian 系の GPG 鍵置き場は時代と共に変遷しています。現代では3つの場所を意識します。

• /usr/share/keyrings/ — ディストロ標準の鍵（Ubuntu 24.04 はここを Signed-By で参照）
• /etc/apt/keyrings/ — 第三者リポジトリ追加時の現代的な推奨先（Docker, Node.js等）
• /etc/apt/trusted.gpg.d/ — 旧来の置き場（互換のため残っている）

linuc-ubuntuで実行：

$ ls /usr/share/keyrings/ | head -5

実行結果：

ubuntu-archive-keyring.gpg
ubuntu-archive-removed-keys.gpg
ubuntu-cloudimage-keyring.gpg
ubuntu-cloudimage-removed-keys.gpg
ubuntu-master-keyring.gpg

古い解説で出てくる apt-key add は非推奨です。代わりに /etc/apt/keyrings/ へ .gpg ファイルを直接配置し、リポジトリ定義の Signed-By で参照する方式が現代の作法です。

5.7 dpkg — 低レベルツール

dpkg は Debian 系の低レベルツール。rpm と役割が同じで、ネット不要・パッケージDBに直接問い合わせます。オプションの形が rpm と異なるので注意。

linuc-ubuntuで実行：

$ dpkg -l | wc -l
$ dpkg -l bash | tail -3

実行結果：

482
||/ Name           Version         Architecture Description
+++-==============-===============-============-=================
ii  bash           5.2.21-2ubuntu4 amd64        GNU Bourne Again SHell

先頭の ii は「Desired=Install / Status=Installed」。rc なら「削除済みだが設定ファイル残（Remove,Config-files）」を意味します。

linuc-ubuntuで実行：

$ dpkg -L coreutils | head -8

実行結果：

/.
/usr
/usr/bin
/usr/bin/[
/usr/bin/arch
/usr/bin/b2sum
/usr/bin/base32
/usr/bin/base64

-L（大文字）はパッケージのファイル一覧。rpm -ql と同じ役割。

逆引きを試します。linuc-ubuntuで実行：

$ dpkg -S /usr/bin/cat

実行結果：

coreutils: /usr/bin/cat

ここで実験。/bin/cat でも逆引きできるでしょうか？ AlmaLinux の rpm -qf はリンクを追跡してくれましたが……。

linuc-ubuntuで実行：

$ dpkg -S /bin/cat

実行結果：

dpkg-query: no path found matching pattern /bin/cat

失敗します。原因はシンボリックリンク。linuc-ubuntuで実行：

$ ls -la /bin

実行結果：

lrwxrwxrwx 1 root root 7 Apr 22  2024 /bin -> usr/bin

/bin は /usr/bin へのシンボリックリンク（usrmerge）。dpkg -S はパッケージDBに登録された実体パスとの完全一致で検索するので、リンク経由のパスでは見つかりません。同じ系統の作業でも、rpm と dpkg でこんな差があることを覚えておいてください。

linuc-ubuntuで実行：

$ dpkg -s bash | head -10

実行結果：

Package: bash
Essential: yes
Status: install ok installed
Priority: required
Section: shells
Installed-Size: 1900
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Architecture: amd64
Multi-Arch: foreign
Version: 5.2.21-2ubuntu4

-s（小文字）はパッケージの状態と詳細情報。rpm -qi に相当します。Essential: yes は「OS の動作に必須」を意味し、削除しようとすると強い警告が出ます。

5.8 linuc-alma に戻る

linuc-ubuntuで実行：

$ exit

プロンプトが linuc-alma に戻ったことを確認してください。

第6章：dnf と apt の対応表

「現場で頭を切り替える」ための対応表。試験対策にも実務にも使えます。

操作	RHEL系（dnf）	Debian系（apt）
メタデータ更新	（自動／dnf makecache）	sudo apt update
導入済み一覧	dnf list installed	apt list --installed
更新可能一覧	dnf list updates	apt list --upgradable
キーワード検索	dnf search <word>	apt search <word>
パッケージ詳細	dnf info <pkg>	apt show <pkg>
インストール	sudo dnf install <pkg>	sudo apt install <pkg>
削除（設定残）	sudo dnf remove <pkg>	sudo apt remove <pkg>
削除（設定ごと）	（同上）	sudo apt purge <pkg>
全パッケージ更新	sudo dnf update	sudo apt upgrade
履歴確認	dnf history	cat /var/log/apt/history.log
リポ一覧	dnf repolist	apt-cache policy

操作	RHEL系（rpm）	Debian系（dpkg）
全パッケージ一覧	rpm -qa	dpkg -l
パッケージ詳細	rpm -qi <pkg>	dpkg -s <pkg>
ファイル列挙	rpm -ql <pkg>	dpkg -L <pkg>
逆引き	rpm -qf <file>	dpkg -S <file>
個別インストール	sudo rpm -i <file.rpm>	sudo dpkg -i <file.deb>
個別削除	sudo rpm -e <pkg>	sudo dpkg -r <pkg>
改ざん検証	rpm -V <pkg>	dpkg -V <pkg> または debsums

第7章：依存関係と GPG 鍵

7.1 依存関係解決の流れ

sudo dnf install httpd と打った瞬間に裏側で起きていること：

1. メタデータ取得：リポジトリから「何が提供されているか」の一覧を取る
2. 依存ツリー構築：httpd が必要とする apr / apr-util / mod_http2 など、さらにその先まで再帰的に解析
3. 競合チェック：既に入っている別バージョンとぶつからないか確認
4. ダウンロード：必要なパッケージ群を一括取得
5. GPG 検証：各パッケージの署名を gpgkey= の鍵で検証（改ざん防止）
6. 展開：低レベル層に渡してファイルを配置
7. scriptlet 実行：パッケージごとの post-install スクリプト（ユーザー作成・サービス登録など）

2〜5 を「依存解決」と呼びます。これを rpm -i や dpkg -i で個別ファイルだけ展開しようとすると、依存パッケージが入っていなければエラーになるか、起動できないバイナリだけが配置されます。

7.2 GPG 鍵 — 改ざん検知と発行元検証

「正しい配布元から取得した、改ざんされていないパッケージか」を保証する仕組みが GPG 署名検証です。

• パッケージ作成時、配布元の秘密鍵でパッケージのハッシュ値に署名
• クライアント側は公開鍵（/etc/pki/rpm-gpg/ や /etc/apt/keyrings/）で署名を検証
• 検証失敗 → インストール拒否（gpgcheck=1 の場合）

第8章：現場での使いどころ

• 障害対応：「ある日からサービスが起動しない」→ dnf history で直近24時間の変更を確認 → 怪しい更新を dnf history undo <id> でロールバック
• セキュリティ対応：CVE 公表時に dnf updateinfo list security や apt list --upgradable で影響範囲を把握 → 検証環境で動作確認 → 本番ロールアウト
• サーバー監査：rpm -qa > pkg-list.txt / dpkg -l > pkg-list.txt で「導入済みパッケージのスナップショット」を取り、構成管理ツール（Ansible 等）で差分管理
• 新規構築の自動化：Kickstart / cloud-init / Ansible の playbook で dnf install や apt install をスクリプト化。手作業をゼロに
• 異常検知：rpm -V <pkg> でパッケージファイルの改ざんを検出。マルウェア混入や設定ミスの早期発見に
• 依存破壊の復旧：誰かが dpkg -i で勝手に入れて壊れた状態は、sudo apt --fix-broken install でほぼ自動復旧できる

第9章：ヒヤリハット — 本番で dnf update 引数なし

やってみよう

linuc-alma にログインしている前提で、演習1〜4を順に実行してください。演習1・2は linuc-alma で、演習3・4は linuc-ubuntu で実行します。

理解度チェック

○か×で答えてください。回答と解説は次回冒頭で振り返ります。

1. RHEL系の高レベルツールは dnf、低レベルツールは rpm である。
2. Ubuntu/Debian 系で apt update を実行すると、すべてのパッケージが最新版に更新される。
3. rpm -i <file.rpm> や dpkg -i <file.deb> は、パッケージファイル単体をインストールするコマンドで、依存関係を自動解決する。
4. AlmaLinux のリポジトリ設定ファイル（/etc/yum.repos.d/*.repo）の gpgcheck=1 は、パッケージの GPG 署名検証を有効にする設定である。
5. Ubuntu 24.04 で dpkg -S /bin/cat を実行すると、coreutils パッケージが返ってくる。

次回予告

第7回は「ファイル操作の実践：cp, mv, find, リンク, FHS」です。cp や mv といった基本コマンドを「使える」だけでなく、ハードリンクとシンボリックリンクの違い、find による高度な検索、そして FHS（ファイルシステム階層標準）でディレクトリの役割を体系化します。今回学んだパッケージ管理で「どこにファイルが配置されるか」を理解した上で、次はそのファイルを操作するコマンド群へ進みます。

LinuC 101 試験対策シリーズ 全12回

• 第1回 Linuxの起動・接続・停止：systemctl・login・shutdownの基本
• 第2回 ブートプロセスの仕組み：BIOS/UEFI → GRUB → systemd の流れ
• 第3回 systemdマスター講座：サービス管理・unitファイル・ターゲット
• 第4回 プロセス管理とハードウェア基礎（ps, top, lsblk, lspci, lsusb）
• 第5回 仮想マシンとコンテナの基礎：KVM・Docker・Podman 入門
• 第6回 パッケージ管理マスター：dnf / apt / rpm / dpkg の実践（本記事）
• 第7回 ファイル操作の実践：cp, mv, find, リンク, FHS
• 第8回 パーミッション・所有者・特殊権限（SUID/SGID/Sticky）
• 第9回 コマンドライン・リダイレクト・パイプの基礎
• 第10回 テキスト処理の三種の神器：grep / sed / awk + 正規表現
• 第11回 vi/vim 入門：現場で使えるエディタ操作
• 第12回 ディスク・パーティション・ファイルシステム（fdisk, mkfs, mount, LVM）