【サーバー管理入門 第3回】アプリ導入の裏側を知る。dnf/rpmと「依存関係」の正体
こんにちは！「リナックス先生」です。
前回は、SSHの鍵認証を設定し、サーバーセキュリティの第一歩を踏み出しました。
これで安全に接続できるようになったので、いよいよサーバーの中に「道具（ソフトウェア）」を入れていきましょう。
先生、Windowsならソフトを入れるときは「インストーラー（setup.exe）」をダウンロードしてダブルクリックしますよね？
LinuxでもWebサイトからダウンロードしてくるんですか？
いいえ、Linux（特にサーバー用途）では、勝手にネットから拾ってきたファイルを入れるのは「御法度」よ。
公式に管理されている「倉庫（リポジトリ）」から、専用のコマンドを使って配送してもらうの。
これが「パッケージ管理」の考え方よ。
第3回となる今回は、Linuxサーバー構築の主役である「パッケージ管理システム (dnf / rpm)」について徹底解説します。
初心者は「コマンドを打てばインストールできる」と考えがちですが、プロは「どこのリポジトリから」「どんな依存関係を持って」「署名は正しいか」を意識してインストールします。
トラブルシューティングに不可欠なその裏側の仕組みを、深く掘り下げていきましょう。
本講座のカリキュラム
- サーバー管理入門：RHEL系OSの選定理由とローカル仮想環境の構築
- 初期設定とセキュリティの要：SSH鍵認証、禁止設定、ユーザー管理の鉄則
- 【今回】パッケージ管理の裏側：dnf/rpmの仕組みとリポジトリの依存関係解決
- ネットワーク設定の極意：nmcli、IPアドレス設計、DNSリゾルバの設定
- ストレージ管理とファイルシステム：LVMの概念、ディスク拡張、fstabの罠
- プロセスとサービス管理：systemd (systemctl) の仕組みとUnit定義ファイルの作成
- Webサーバー構築(Nginx)：ハイパフォーマンスWebサーバーの導入と設定最適化
- データベース構築(MariaDB)：インストール、初期セキュリティ、バックアップの基礎
- ログ管理とトラブルシュート：rsyslog、journalctl、ログローテートの設計
- 自動化の第一歩：Cronによる定期実行と管理用シェルスクリプトの作成
- バックアップと障害復旧：tar/rsyncによるデータ保全とリカバリ手順
- 監視と運用設計：サーバーのリソース監視、死活監視、そしてプロの運用論
1. RPM と DNF の決定的な違い
RHEL系Linux（Red Hat, AlmaLinux, Rocky Linux）では、ソフトウェアは「RPMパッケージ」という形式（拡張子 .rpm）で配布されています。
これを管理するためのコマンドとして rpm と dnf (旧 yum) の2つが存在しますが、現場での使い分けと内部構造の違いを理解しましょう。
RPM (Red Hat Package Manager)：現場の作業員
- 役割： 指定された
.rpmファイルをシステム（ディスク）に展開し、データベースに登録する「実行部隊」です。 - データベースの場所：
/var/lib/rpm配下にバイナリ形式でインストール情報を保持しています。 - 致命的な弱点： 「依存関係」を解決できません。
- 例：「ソフトA」をインストールしようとした時、それが動くために必要な「ライブラリB」がないと、「エラー：ライブラリBが必要です」と言って作業を放棄します。ライブラリBをどこから入手すればいいかは教えてくれません。
DNF (Dandified YUM)：物流センターの司令塔
- 役割： インターネット上の倉庫（リポジトリ）からパッケージメタデータ（目録）をダウンロードし、依存関係を計算します。「ソフトAを入れるならBとCも必要だな」と判断し、全てをダウンロードしてからRPMコマンドに「これらを順に入れてくれ」と指示を出します。
- YUMとの関係： かつての標準
yumはPython 2ベースで遅く、メモリ消費も大でした。dnfはPython 3とC言語で書き直され、爆速化しました。
※ 現在のRHEL 9でもyumコマンドは使えますが、実体はdnfへのシンボリックリンク（別名）になっています。
💡 プロの常識：rpmコマンドを使う時
基本的に、人間が手動で rpm -ivh を叩くことは現代では滅多にありません。
「常に dnf を使う」のが正解です。rpm コマンドを使うのは、以下の限定的なシーンのみです。
- インストール済みの全パッケージリストを高速に取得したい時 (
rpm -qa) - 特定のファイルが、どのパッケージに含まれていたか調べたい時 (
rpm -qf /bin/ls) - DNFリポジトリに存在しない、商用ソフト（Oracle Databaseや特殊なセキュリティエージェントなど）を単独でインストールする時
2. 「依存関係」と「共有ライブラリ」の正体
なぜLinuxには「依存関係（Dependency）」という面倒な概念があるのでしょうか？
それは、ディスク容量とメモリを節約するために、「共有ライブラリ（Shared Library）」という仕組みを採用しているからです。
共有ライブラリとは？
Windowsでいう .dll ファイル、Linuxでいう .so (Shared Object) ファイルのことです。
例えば「画面に文字を表示する機能」や「暗号化通信をする機能（OpenSSL）」は、Webサーバーもメールサーバーもデータベースも、みんなが使います。
それぞれのソフトの中に同じ機能を内包するのではなく、OS側に1つだけ置いてみんなで使い回す。これが共有ライブラリです。
依存関係地獄（Dependency Hell）からの脱却
昔のエンジニアは、このパズルを手動で解いていました。
「Aを入れるためにBが必要。Bを入れるためにCが必要。Cを入れるとDと競合する…」
これを自動解決してくれるのが DNF です。
- ユーザー「Webサーバー (nginx) を入れたい！」
- DNF「了解。計算します…nginxを動かすには『openssl-libs』と『zlib』と『pcre2』が必要です」
- DNF「リポジトリから4つともダウンロードします」
- DNF「正しい順番（ライブラリ → アプリ）でRPMにインストールさせます」
3. リポジトリの構造とセキュリティ（GPG鍵）
DNFはどこからパッケージを探してくるのでしょうか？
設定は /etc/yum.repos.d/ ディレクトリにある .repo ファイルに記述されています。
.repoファイルの中身を読む
試しに、AlmaLinuxの基本リポジトリ定義を見てみましょう。
[root@server01 ~]# cat /etc/yum.repos.d/almalinux-baseos.repo [baseos] name=AlmaLinux $releasever - BaseOS baseurl=https://repo.almalinux.org/almalinux/$releasever/BaseOS/$basearch/os/ enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux-9
- [ID]： リポジトリの一意な識別子。コマンドで
--enablerepo=baseosのように指定する時に使います。 - baseurl： インターネット上のパッケージ置き場のURL。
- enabled=1： このリポジトリを有効にする（0なら無効）。
- gpgcheck=1： 【重要】 ダウンロードしたパッケージが改ざんされていないか、デジタル署名を検証するかどうか。
GPG鍵 (GPG Key) とは？
インターネット上の経路で、悪意ある第三者がパッケージの中身をウイルスに差し替えているかもしれません。
それを防ぐため、公式リポジトリのパッケージは「秘密鍵」でデジタル署名されています。
我々のサーバー（OS）にはあらかじめ「公開鍵」が入っており、インストール直前に「このファイルは本当にAlmaLinux公式が作ったものか？」を検証しています。gpgcheck=1 は絶対に無効にしてはいけません。
4. AlmaLinux 9 のリポジトリ構成 (BaseOS / AppStream)
RHEL 8以降、リポジトリの構成が大きく変わりました。
| リポジトリ名 | 役割 |
|---|---|
| BaseOS | OSが起動・稼働するために必要不可欠なコア部分（カーネル、systemd、dnf、基本的なシェルコマンドなど）。 ライフサイクル（バージョン）はOSと同期します。 |
| AppStream | ユーザー空間で動くアプリケーション群（Apache, Nginx, PHP, Python, MariaDBなど）。 OS本体とは切り離され、頻繁に新しいバージョンが提供されます。 |
これにより、「OSの基盤は安定したまま（BaseOS）、PHPだけは最新版を使う（AppStream）」という柔軟な運用が可能になりました。
5. 実践：プロが使うDNFコマンド一覧
基本的な dnf install 以外にも、管理者が覚えておくべきコマンドがあります。
パッケージ情報の詳細調査
# 特定のコマンドがどのパッケージに含まれているか探す（神コマンド） [root@server01 ~]# dnf provides ifconfig # -> "net-tools" パッケージに入っていますよ、と教えてくれる # インストールされるファイルの一覧を見る（インストール前に確認） [root@server01 ~]# dnf repoquery -l nginx
グループインストール
開発ツール一式などをまとめて入れたい時に便利です。
# グループの一覧を見る [root@server01 ~]# dnf group list # 「Development Tools」グループ（gccやmakeの一式）を入れる [root@server01 ~]# dnf groupinstall "Development Tools"
メンテナンスとトラブルシュート
DNFの挙動がおかしい（メタデータの取得に失敗する、依存関係エラーが出る）時は、まずキャッシュをクリアします。
# 全てのキャッシュを削除してリフレッシュする [root@server01 ~]# dnf clean all # 操作履歴を確認する [root@server01 ~]# dnf history # 特定の操作を取り消す（Undo） [root@server01 ~]# dnf history undo 5
6. EPEL と CRB (CodeReady Builder) の導入
サーバー構築を進めると、必ず「公式リポジトリに欲しいソフトがない」という壁にぶつかります（例：htop, certbot, 監視ツールなど）。
そこで導入するのが、Fedoraプロジェクトがメンテナンスする高品質な追加パッケージ集「EPEL (Extra Packages for Enterprise Linux)」です。
CRB (CodeReady Builder) の重要性
ここが多くの初心者がハマるポイントです。
EPELの一部のパッケージは、RHEL標準には含まれない開発用ライブラリ（CRBリポジトリに含まれる）に依存していることがあります。
デフォルトではCRBは無効化されているため、EPELを入れるときは必ずセットでCRBも有効化してください。
# 1. EPELリリースパッケージをインストール [root@server01 ~]# dnf install epel-release -y # 2. CRBリポジトリを有効化 (config-managerを使用) [root@server01 ~]# dnf config-manager --set-enabled crb # 3. 確認 [root@server01 ~]# dnf repolist # -> "epel" と "crb" が表示されればOK
7. セキュリティアップデートの自動化（dnf-automatic）
脆弱性は日々発見されます。「毎日手動でアップデート」は現実的ではありませんが、かといって「全自動で何でもアップデート」すると、勝手にバージョンが上がってWebサイトが動かなくなるリスクがあります。
プロの折衷案として、「セキュリティパッチだけは自動で当てる」設定を紹介します。
# ツールのインストール [root@server01 ~]# dnf install dnf-automatic -y # 設定ファイルの編集 [root@server01 ~]# vi /etc/dnf/automatic.conf
以下の箇所を変更します。
[commands] # default から security に変更（セキュリティ更新のみ対象） upgrade_type = security random_sleep = 0 [emitters] # 実行結果を標準出力に残す（ログ用） emit_via = stdio [base] # 更新をダウンロードするだけでなく適用まで行う apply_updates = yes
最後にタイマーを有効化します。
[root@server01 ~]# systemctl enable --now dnf-automatic.timer
⚠️ 注意点：カーネルの更新
カーネル（OSの核）の脆弱性パッチが当たった場合、OSを再起動するまで新しいカーネルは有効になりません。dnf-automatic で更新自体はされますが、再起動のタイミングは人間が管理する必要があります。
次回予告：ネットワークを支配する
今回は、Linuxのパッケージ管理の仕組みを深掘りしました。
依存関係の解決、署名の検証、リポジトリの使い分け…これらは全て「システムを安定して稼働させる」ための先人の知恵です。
次回は、サーバー構築の最難関とも言われる「ネットワーク設定」に挑みます。
Linuxの世界では、IPアドレス一つ設定するのにも独特の作法（nmcliコマンド）があります。
ネットワークがつながらなければサーバーはただの箱。インフラエンジニア必須のスキルを習得しましょう！
▼スクリプトの実験場に最適！推奨VPS
コメント