Linuxエンジニア養成講座 第19回｜全36回・フェーズ3「ネットワークとインフラ基盤」の4回目（4/12回目）です。
前回まで: 第16回でTCP/IPの基礎、第17回でnmcliによるIP設定と疎通確認、第18回でalma-proxyを使ったプロキシ・DNS・NTPのクライアント設定を学びました。
今回学ぶこと: dnf のリポジトリ構造を理解し、GPG鍵の意味を知った上で、EPELリポジトリを導入します。
この記事を読み終えると、以下のことができるようになります。
- dnf のリポジトリ構造（BaseOS / AppStream / Extras / EPEL）を説明できる
- GPG鍵の役割を「なぜ必要か」から説明できる
- プロキシ経由で EPEL リポジトリを導入し、パッケージをインストールできる
dnf repolist・dnf info・dnf historyでパッケージとリポジトリの状態を確認できる- リポジトリを一時的に有効化・無効化できる
dnf history undoでインストールをロールバックできる
alma-proxy 起動確認（前提条件）
今回の操作は、すべて alma-main で行います。パッケージのダウンロードには alma-proxy（Squid プロキシ）経由のインターネット接続が必要です。まず alma-proxy が起動しているか確認してください。
alma-mainで実行
実行コマンド：
$ curl -s -o /dev/null -w "%{http_code}" -x http://10.0.1.254:3128 http://repo.almalinux.orgHTTP ステータスコードが返ってくれば、alma-proxy のプロキシは動作しています。000 や接続エラーが返る場合は、alma-proxy の VM が起動しているか、Squid サービスが稼働しているか確認してください。
なお、alma-proxy の Squid はホワイトリスト方式で運用しています。許可されたドメインへの通信だけが中継され、それ以外はブロックされます。試しに許可されていないドメインにアクセスしてみましょう。
実行コマンド：
$ curl -s -o /dev/null -w "%{http_code}" -x http://10.0.1.254:3128 http://google.com実行結果：
403403（Forbidden）が返ります。これが企業ネットワークにおけるプロキシの典型的な動作です。業務に必要なドメインだけを許可し、それ以外はブロックする。前回学んだプロキシの仕組みが、ここで活きています。
なぜパッケージ管理が必要なのか
Linux にソフトウェアを入れる方法は、大きく分けて2つあります。
- ソースコードをダウンロードして自分でコンパイルする
- パッケージマネージャを使ってインストールする
ソースコードからのコンパイルには、ビルドツールの準備、依存ライブラリの解決、インストール先の管理が必要です。1つのソフトウェアを入れるだけで何十分もかかることがあります。サーバーが100台あれば、同じ作業を100回繰り返すことになります。
パッケージマネージャはこの問題を解決します。ビルド済みのバイナリを「パッケージ」という単位にまとめ、依存関係の解決からインストール・アップデート・削除までを一元管理します。AlmaLinux 9 では dnf がその役割を担っています。
依存関係と dnf の役割
ソフトウェアは他のソフトウェアに依存していることがほとんどです。たとえば「Aを動かすにはBが必要、Bを動かすにはCが必要」という連鎖です。これを「依存関係」と呼びます。
dnf は、パッケージをインストールする際に依存関係を自動で解決します。「htop をインストールして」と指示すれば、htop が動作するために必要な hwloc-libs も一緒にインストールしてくれます。この「依存関係の自動解決」が、パッケージマネージャ最大の利点です。
dnf の設定ファイル（/etc/dnf/dnf.conf の再確認）
第7回で「おまじない」として /etc/dnf/dnf.conf に proxy= 行を追加しました。前回でプロキシの仕組みを学んだので、ここで改めてこのファイルの内容を確認しましょう。
alma-mainで実行
実行コマンド：
$ cat /etc/dnf/dnf.conf実行結果：
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
best=True
skip_if_unavailable=False
proxy=http://10.0.1.254:3128各設定値の意味は次の通りです。
gpgcheck=1— パッケージの GPG 署名を検証する（後述）installonly_limit=3— カーネルなど「インストール専用」パッケージの保持数clean_requirements_on_remove=True— パッケージ削除時に不要になった依存パッケージも削除するbest=True— 最新バージョンのパッケージを優先するskip_if_unavailable=False— リポジトリに接続できない場合はエラーにするproxy=http://10.0.1.254:3128— パッケージのダウンロードに alma-proxy の Squid を使う
proxy= が alma-proxy の Squid を指しているのは、前回の学びと一致します。dnf がパッケージをダウンロードするとき、この設定に従って 10.0.1.254:3128（alma-proxy の Squid）を経由してインターネット上のリポジトリにアクセスします。
各オプションの詳細は man dnf.conf で確認できます。
リポジトリの仕組み
リポジトリとは「パッケージの棚」
リポジトリ（repository）は、パッケージが置いてあるサーバーのことです。書店にたとえると、「技術書コーナー」「文庫コーナー」のように、目的別に棚が分かれているイメージです。dnf はこれらの棚（リポジトリ）にアクセスして、必要なパッケージを取得します。
現在有効なリポジトリを確認してみましょう。
alma-mainで実行
実行コマンド：
$ dnf repolist実行結果：
repo id repo の名前
appstream AlmaLinux 9 - AppStream
baseos AlmaLinux 9 - BaseOS
extras AlmaLinux 9 - Extras3つのリポジトリが有効です。これらが AlmaLinux 9 の標準リポジトリです。
AlmaLinux 9 の標準リポジトリ（BaseOS / AppStream / Extras）
3つの標準リポジトリには、それぞれ役割があります。
- BaseOS — OS の基盤となるパッケージ（カーネル、systemd、coreutils など）。サポート期間全体を通じて安定性が保証される
- AppStream — アプリケーション層のパッケージ（httpd、mariadb-server、python3 など）。モジュールストリームにより複数バージョンを提供できる
- Extras — 上記2つに含まれない補助パッケージ。epel-release もここから提供される
これまでの回で dnf install したパッケージも、この3つのリポジトリから取得していました。たとえば 第7回でインストールした vim-enhanced は AppStream、tree は BaseOS から取得されています。
.repo ファイルを読んでみる
リポジトリの設定は /etc/yum.repos.d/ ディレクトリにある .repo ファイルに記述されています。どんなファイルがあるか見てみましょう。
alma-mainで実行
実行コマンド：
$ ls /etc/yum.repos.d/実行結果：
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多くの .repo ファイルがありますが、先ほど dnf repolist で表示されたのは3つだけでした。つまり、ファイルは存在するが「無効化」されているリポジトリもあるということです。
BaseOS リポジトリの設定ファイルを読んでみましょう。
実行コマンド：
$ cat /etc/yum.repos.d/almalinux-baseos.repo実行結果（[baseos] セクション）：
[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]— リポジトリID。dnf repolistの「repo id」に対応するname=— 表示名。$releaseverは AlmaLinux のバージョン（9）に自動置換されるmirrorlist=— ミラーサーバーの一覧URL。地理的に近いサーバーから自動選択されるenabled=1— このリポジトリが有効（0にすると無効化）gpgcheck=1— パッケージの GPG 署名を検証するgpgkey=— 署名検証に使う GPG 公開鍵ファイルのパス
$releasever や $basearch は dnf の変数です。AlmaLinux 9 の x86_64 環境では、それぞれ 9 と x86_64 に展開されます。
GPG鍵 — パッケージの「身元証明」
なぜGPG鍵が必要なのか
パッケージはインターネット上のサーバーからダウンロードします。では、そのパッケージが本物であることをどう確認するのでしょうか。
もし悪意のある第三者がミラーサーバーを改ざんし、マルウェア入りのパッケージに差し替えたらどうなるでしょう。GPG 署名の検証なしにインストールすれば、サーバーが乗っ取られる危険があります。
GPG（GNU Privacy Guard）鍵は、この問題を防ぐ仕組みです。流れは次の通りです。
- パッケージの提供元（AlmaLinux プロジェクトなど）が「秘密鍵」でパッケージに署名する
- 利用者は「公開鍵」を使って署名を検証する
- 署名が正しければ、パッケージが改ざんされていないことが保証される
先ほどの .repo ファイルにあった gpgcheck=1 と gpgkey= が、この仕組みを担っています。gpgcheck=1 は「署名を必ず検証せよ」、gpgkey= は「検証に使う公開鍵はこのファイルだ」という意味です。
GPG鍵のインポート確認
GPG 公開鍵ファイルは /etc/pki/rpm-gpg/ ディレクトリに配置されています。現在の状態を確認しましょう。
alma-mainで実行
実行コマンド：
$ ls /etc/pki/rpm-gpg/実行結果：
RPM-GPG-KEY-AlmaLinux-9AlmaLinux 9 の公開鍵が1つあります。この鍵は OS インストール時に自動配置されたものです。
RPM のデータベースに登録されている鍵も確認してみましょう。
実行コマンド：
$ rpm -qa gpg-pubkey*実行結果：
gpg-pubkey-b86b3716-61e69f29gpg-pubkey-b86b3716-61e69f29 が AlmaLinux 9 の鍵です。パッケージをインストールするたびに、この鍵を使って署名が検証されています。
EPELリポジトリを導入する
EPELとは何か
EPEL（Extra Packages for Enterprise Linux）は、Fedora プロジェクトが提供する追加パッケージリポジトリです。RHEL 系ディストリビューション（AlmaLinux、Rocky Linux、CentOS Stream など）の標準リポジトリには含まれていないが、現場でよく使われるツールが収録されています。
たとえば htop（高機能プロセスビューア）、fail2ban（不正アクセス対策）、jq（JSON処理）などは EPEL から提供されます。インフラエンジニアの現場では EPEL を導入しているサーバーが多いため、導入手順を覚えておくと役立ちます。
プロキシ経由でのEPEL導入
EPEL の導入は、epel-release パッケージをインストールするだけです。このパッケージは AlmaLinux の Extras リポジトリに含まれています。
alma-mainで実行
実行コマンド：
$ sudo dnf install -y epel-release実行結果：
メタデータの期限切れの最終確認: 0:08:57 前の 2026年04月02日 17時52分26秒 に実施しました。
依存関係が解決しました。
================================================================================
パッケージ Arch バージョン リポジトリー サイズ
================================================================================
インストール:
epel-release noarch 9-9.el9 extras 18 k
トランザクションの概要
================================================================================
インストール 1 パッケージ
ダウンロードサイズの合計: 18 k
インストール後のサイズ: 26 k
パッケージのダウンロード:
epel-release-9-9.el9.noarch.rpm 182 kB/s | 18 kB 00:00
--------------------------------------------------------------------------------
合計 24 kB/s | 18 kB 00:00
トランザクションを確認しています
トランザクションの確認に成功しました。
トランザクションをテストしています
トランザクションのテストに成功しました。
トランザクションを実行しています
準備中 : 1/1
インストール中 : epel-release-9-9.el9.noarch 1/1
scriptletの実行中: epel-release-9-9.el9.noarch 1/1
Many EPEL packages require the CodeReady Builder (CRB) repository.
It is recommended that you run /usr/bin/crb enable to enable the CRB repository.
検証中 : epel-release-9-9.el9.noarch 1/1
インストール済み:
epel-release-9-9.el9.noarch
完了しました！「CRB repository を有効にすることを推奨」というメッセージが表示されます。CRB（CodeReady Builder）は開発向けの追加パッケージを含むリポジトリですが、今回は有効にしなくても問題ありません。
リポジトリの一覧を再確認しましょう。
実行コマンド：
$ dnf repolist実行結果：
repo id repo の名前
appstream AlmaLinux 9 - AppStream
baseos AlmaLinux 9 - BaseOS
epel Extra Packages for Enterprise Linux 9 - x86_64
epel-cisco-openh264 Extra Packages for Enterprise Linux 9 openh264 (From Cisco) - x86_64
extras AlmaLinux 9 - Extrasepel と epel-cisco-openh264 が追加されました。epel-release パッケージが .repo ファイルと GPG 公開鍵ファイルを配置してくれたのです。
EPEL の .repo ファイルも確認してみましょう。
実行コマンド：
$ head -15 /etc/yum.repos.d/epel.repo実行結果：
[epel]
name=Extra Packages for Enterprise Linux 9 - $basearch
# It is much more secure to use the metalink, but if you wish to use a local mirror
# place its address here.
#baseurl=https://download.example/pub/epel/9/Everything/$basearch/
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-9&arch=$basearch&infra=$infra&content=$contentdir
enabled=1
gpgcheck=1
countme=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-9
[epel-debuginfo]
name=Extra Packages for Enterprise Linux 9 - $basearch - Debug
# It is much more secure to use the metalink, but if you wish to use a local mirror
# place its address here.BaseOS リポジトリと同じ構造です。gpgkey= が RPM-GPG-KEY-EPEL-9 を指しているのが分かります。/etc/pki/rpm-gpg/ ディレクトリも確認しましょう。
実行コマンド：
$ ls /etc/pki/rpm-gpg/実行結果：
RPM-GPG-KEY-AlmaLinux-9
RPM-GPG-KEY-EPEL-9EPEL の GPG 公開鍵ファイルが追加されています。ただし、この時点ではまだ RPM データベースには登録されていません。
実行コマンド：
$ rpm -qa gpg-pubkey*実行結果：
gpg-pubkey-b86b3716-61e69f29AlmaLinux の鍵のみです。EPEL の鍵はファイルとして配置されましたが、RPM データベースへのインポートは EPEL リポジトリからパッケージを初めてインストールするときに行われます。この2段階の動作を次のセクションで確認しましょう。
EPELからパッケージをインストール（htop）
EPEL リポジトリが使えるようになったので、試しに htop をインストールします。htop は 第12回で学んだ top コマンドの高機能版で、プロセスの状態をカラフルに表示できます。
インストール前に、htop がどのリポジトリから提供されるか確認しましょう。
alma-mainで実行
実行コマンド：
$ dnf info htop実行結果：
利用可能なパッケージ
名前 : htop
バージョン : 3.3.0
リリース : 1.el9
Arch : x86_64
サイズ : 198 k
ソース : htop-3.3.0-1.el9.src.rpm
リポジトリー : epel
概要 : Interactive process viewer
URL : http://hisham.hm/htop/
ライセンス : GPLv2+
説明 : htop is an interactive text-mode process viewer for Linux, similar to
: top(1).「リポジトリー : epel」と表示されています。EPEL から提供されていることが確認できました。ではインストールします。
実行コマンド：
$ sudo dnf install -y htop実行結果：
依存関係が解決しました。
================================================================================
パッケージ Arch バージョン リポジトリー サイズ
================================================================================
インストール:
htop x86_64 3.3.0-1.el9 epel 198 k
依存関係のインストール:
hwloc-libs x86_64 2.4.1-6.el9_7 baseos 2.1 M
トランザクションの概要
================================================================================
インストール 2 パッケージ
ダウンロードサイズの合計: 2.3 M
インストール後のサイズ: 3.5 M
パッケージのダウンロード:
(1/2): htop-3.3.0-1.el9.x86_64.rpm 1.1 MB/s | 198 kB 00:00
(2/2): hwloc-libs-2.4.1-6.el9_7.x86_64.rpm 5.5 MB/s | 2.1 MB 00:00
--------------------------------------------------------------------------------
合計 1.6 MB/s | 2.3 MB 00:01
Extra Packages for Enterprise Linux 9 - x86_64 1.6 MB/s | 1.6 kB 00:00
GPG 鍵 0x3228467C をインポート中:
Userid : "Fedora (epel9) "
Fingerprint: FF8A D134 4597 106E CE81 3B91 8A38 72BF 3228 467C
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-9
鍵のインポートに成功しました
トランザクションを確認しています
トランザクションの確認に成功しました。
トランザクションをテストしています
トランザクションのテストに成功しました。
トランザクションを実行しています
準備中 : 1/1
インストール中 : hwloc-libs-2.4.1-6.el9_7.x86_64 1/2
インストール中 : htop-3.3.0-1.el9.x86_64 2/2
scriptletの実行中: htop-3.3.0-1.el9.x86_64 2/2
検証中 : hwloc-libs-2.4.1-6.el9_7.x86_64 1/2
検証中 : htop-3.3.0-1.el9.x86_64 2/2
インストール済み:
htop-3.3.0-1.el9.x86_64 hwloc-libs-2.4.1-6.el9_7.x86_64
完了しました！ 出力をよく見てください。2つの注目ポイントがあります。
1. 依存関係の自動解決
htop をインストールしただけなのに、hwloc-libs も一緒にインストールされています。htop が動作するために hwloc-libs が必要だからです。しかも hwloc-libs は EPEL ではなく baseos リポジトリから取得されています。dnf はリポジトリをまたいで依存関係を解決できるのです。
2. GPG 鍵の自動インポート
「GPG 鍵 0x3228467C をインポート中」と表示されています。EPEL リポジトリから初めてパッケージをインストールしたため、ここで GPG 鍵が RPM データベースにインポートされました。確認してみましょう。
実行コマンド：
$ rpm -qa gpg-pubkey*実行結果：
gpg-pubkey-b86b3716-61e69f29
gpg-pubkey-3228467c-613798ebEPEL の鍵（gpg-pubkey-3228467c）が追加されています。整理すると、GPG 鍵の導入は次の2段階で行われます。
epel-releaseインストール時 — 鍵ファイルが/etc/pki/rpm-gpg/に配置される- EPEL パッケージの初回インストール時 — 鍵が RPM データベースにインポートされる
htop がインストールされたか確認しましょう。
実行コマンド：
$ htop --version実行結果：
htop 3.3.0インストールが完了しました。htop を引数なしで実行するとプロセスビューアが起動します。q キーで終了できます。
dnf の便利な操作
パッケージを調べる（search / info / provides）
パッケージの情報を調べるコマンドは3つあります。用途に応じて使い分けましょう。
dnf search — パッケージ名や説明からキーワード検索
alma-mainで実行
実行コマンド：
$ dnf search httpd実行結果（先頭部分）：
============================= 名前 完全一致: httpd =============================
httpd.x86_64 : Apache HTTP Server
=========================== 名前 & 概要 一致: httpd ============================
almalinux-logos-httpd.noarch : AlmaLinux-related icons and pictures used by httpd
httpd-core.x86_64 : httpd minimal core
keycloak-httpd-client-install.noarch : Tools to configure Apache HTTPD as Keycloak client「名前 完全一致」と「名前 & 概要 一致」に分けて表示されます。「このソフトウェアのパッケージ名は何だろう」と探すときに使います。httpd は 第29回で構築する Apache HTTP Server のパッケージ名です。
dnf info — パッケージの詳細情報を表示
実行コマンド：
$ dnf info httpd実行結果：
利用可能なパッケージ
名前 : httpd
バージョン : 2.4.62
リリース : 7.el9_7.3
Arch : x86_64
サイズ : 45 k
ソース : httpd-2.4.62-7.el9_7.3.src.rpm
リポジトリー : appstream
概要 : Apache HTTP Server
URL : https://httpd.apache.org/
ライセンス : ASL 2.0
説明 : The Apache HTTP Server is a powerful, efficient, and extensible
: web server.バージョン、リポジトリ、ライセンスなどの詳細が分かります。「インストール前にバージョンを確認する」のは現場での基本動作です。
dnf provides — 「このファイルはどのパッケージに含まれるか」を逆引き
実行コマンド：
$ dnf provides /usr/bin/htop実行結果：
htop-3.3.0-1.el9.x86_64 : Interactive process viewer
Repo : @System
一致:
ファイル名 : /usr/bin/htop
htop-3.3.0-1.el9.x86_64 : Interactive process viewer
Repo : epel
一致:
ファイル名 : /usr/bin/htop/usr/bin/htop が htop パッケージに含まれていることが分かります。「このコマンドが見つからない。どのパッケージをインストールすればいいのか」という場面で dnf provides が活躍します。これらのコマンドの詳細オプションは man dnf で確認できます。
リポジトリの有効化/無効化（config-manager）
リポジトリを一時的に無効化・有効化できます。たとえばテスト環境で EPEL を無効にして標準パッケージだけを使いたい場合などに便利です。
alma-mainで実行
実行コマンド：
$ sudo dnf config-manager --set-disabled epel実行コマンド：
$ dnf repolist実行結果：
repo id repo の名前
appstream AlmaLinux 9 - AppStream
baseos AlmaLinux 9 - BaseOS
epel-cisco-openh264 Extra Packages for Enterprise Linux 9 openh264 (From Cisco) - x86_64
extras AlmaLinux 9 - Extrasepel が一覧から消えました。.repo ファイル内の enabled= が 0 に変更されています。再度有効化しましょう。
実行コマンド：
$ sudo dnf config-manager --set-enabled epel実行コマンド：
$ dnf repolist実行結果：
repo id repo の名前
appstream AlmaLinux 9 - AppStream
baseos AlmaLinux 9 - BaseOS
epel Extra Packages for Enterprise Linux 9 - x86_64
epel-cisco-openh264 Extra Packages for Enterprise Linux 9 openh264 (From Cisco) - x86_64
extras AlmaLinux 9 - Extrasepel が復活しました。なお、dnf install --disablerepo=epel パッケージ名 のようにコマンド実行時だけ一時的に無効化する方法もあります。.repo ファイルを変更せずにすむので、1回限りの用途ではこちらが便利です。
dnf history — 変更履歴とロールバック
dnf は過去のインストール・アップデート・削除の履歴をすべて記録しています。
alma-mainで実行
実行コマンド：
$ dnf history実行結果：
ID | コマンドライン | 日時 | 動作 | 変更さ
-------------------------------------------------------------------------------
7 | install -y htop | 2026-04-02 18:02 | Install | 2 <
6 | install -y epel-release | 2026-04-02 18:01 | Install | 1 >E
5 | install -y tar vim-enhan | 2026-04-02 17:52 | Install | 1
4 | install -y lsof | 2026-03-31 05:30 | Install | 2
3 | install -y tar vim-enhan | 2026-03-31 05:29 | Install | 13
2 | install -y bind-utils | 2026-03-24 13:52 | I, U | 10 <
1 | | 2026-03-24 12:30 | Install | 392 >E「ID 7」で htop をインストールし、2パッケージ（htop + hwloc-libs）が変更されたことが分かります。ID 1 の392パッケージは OS インストール時のものです。
特定のトランザクションの詳細を見るには dnf history info を使います。
実行コマンド：
$ dnf history info last実行結果：
トランザクション ID : 7
開始時間 : 2026年04月02日 18時02分28秒
開始 rpmdb : c140c1f19952acdebbe0f1474acffc935fe0092e16538d605fb1c899a67b31e4
終了時間 : 2026年04月02日 18時02分29秒 (1 秒)
終了 rpmdb : 89026d3c36e8e68a5b1773f5f749b9fc09baebc8fe658fa9bef3aba1dbe7bcf4
ユーザー : developer
終了コード : 成功
リリースバージョン : 9
コマンドライン : install -y htop
コメント :
変更されたパッケージ:
インストール hwloc-libs-2.4.1-6.el9_7.x86_64 @baseos
インストール htop-3.3.0-1.el9.x86_64 @epel last は「最新のトランザクション」を意味します。ID を指定して dnf history info 7 のように確認することもできます。
ロールバック（undo）
「間違えてパッケージを入れてしまった」という場面では、dnf history undo で取り消しができます。これは「やってみよう」セクションで実践します。
パッケージグループ（group list / group info）
dnf には、関連するパッケージを一括でインストールする「グループ」機能があります。
alma-mainで実行
実行コマンド：
$ dnf group list実行結果（先頭部分）：
利用可能な環境グループ:
サーバー (GUI 使用)
サーバー
ワークステーション
KDE Plasma デスクトップワークスペース
仮想化ホスト
カスタムオペレーティングシステム
インストール済みの環境グループ:
最小限のインストール
利用可能なグループ:
コンソールインターネットツール
コンテナー管理
.NET Development
RPM 開発ツール
開発ツール
グラフィカル管理ツール
ヘッドレス管理「インストール済みの環境グループ: 最小限のインストール」と表示されています。この検証環境が Minimal Install であることがここからも確認できます。「開発ツール」グループには gcc や make などのビルドツールが含まれており、sudo dnf group install "開発ツール" で一括導入できます。今回はインストールしませんが、ソースコードからコンパイルが必要な場面で使うことがあります。
キャッシュの管理（clean / makecache）
dnf はリポジトリのメタデータ（パッケージ一覧・依存関係情報など）をローカルにキャッシュしています。キャッシュが古くなると、存在しないバージョンを参照してエラーになることがあります。
alma-mainで実行
実行コマンド：
$ sudo dnf clean all実行結果：
42 ファイルが削除されましたclean all でキャッシュを全削除します。その後、makecache で最新のメタデータを再取得します。
実行コマンド：
$ sudo dnf makecache実行結果（末尾部分）：
AlmaLinux 9 - AppStream 5.1 MB/s | 18 MB 00:03
AlmaLinux 9 - BaseOS 1.0 MB/s | 20 MB 00:19
AlmaLinux 9 - Extras 30 kB/s | 21 kB 00:00
Extra Packages for Enterprise Linux 9 - x86_64 1.6 MB/s | 20 MB 00:13
Extra Packages for Enterprise Linux 9 openh264 1.4 kB/s | 2.5 kB 00:01
メタデータキャッシュを作成しました。各リポジトリからメタデータを取得しています。「dnf install がなぜか失敗する」というとき、まず dnf clean all && dnf makecache を試すのは現場での定石です。
ヒヤリハット — gpgcheck=0 の罠
現場のヒヤリハット
ある現場で、自社パッケージリポジトリからの dnf install が GPG 署名エラーで失敗したことがありました。急いでいた担当者は .repo ファイルの gpgcheck=1 を gpgcheck=0 に変更して問題を回避しました。
そのまま gpgcheck=0 が放置され、数か月後にそのリポジトリサーバーが侵害されました。署名検証が無効化されていたため、改ざんされたパッケージがそのままインストールされ、複数のサーバーにバックドアが仕込まれる事態になりました。
GPG 署名エラーが出たときの正しい対処は、gpgcheck=0 にすることではなく、正しい GPG 鍵をインポートすることです。「動けばいい」で設定を緩めると、セキュリティの穴を自分で開けてしまいます。
やってみよう
ここまでの知識を使って、以下の演習に取り組んでください。すべて alma-main で実行します。
演習1: パッケージの調査
dnf search jsonを実行し、JSON 関連のパッケージを探してください- 検索結果から
jqパッケージを見つけ、dnf info jqでリポジトリとバージョンを確認してください jqがどのリポジトリから提供されているか確認してください（EPEL のはずです）
演習2: dnf history undo でロールバック
sudo dnf install -y jqで jq をインストールしてくださいjq --versionでインストールされたことを確認してくださいdnf historyで jq インストールのトランザクション ID を確認してくださいsudo dnf history undo last -yでロールバックしてくださいjq --versionを再度実行し、jq が削除されたことを確認してください（「command not found」になるはずです）dnf historyを確認し、undo のトランザクションが記録されていることを確認してください
ロールバックが正常に動作することを確認できたら、演習は完了です。jq は削除した状態のままで問題ありません。
演習3: リポジトリの一時的な無効化
sudo dnf config-manager --set-disabled epelで EPEL を無効化してくださいdnf repolistで EPEL が消えていることを確認してくださいdnf info htopを実行し、「エラー: 一致するものがありません」のようなメッセージが出ることを確認してください（htop はインストール済みですが、リポジトリが無効なのでリポジトリ情報を取得できません）sudo dnf config-manager --set-enabled epelで EPEL を再度有効化してくださいdnf repolistで EPEL が復活していることを確認してください
演習後、EPEL は有効な状態に戻してください。以降の回でも EPEL を使います。
理解度チェック
以下の文が正しければ「○」、誤りなら「×」と答えてください。
Q1. AlmaLinux 9 の BaseOS リポジトリには、httpd や mariadb-server などのアプリケーション層のパッケージが含まれている。
Q2. gpgcheck=1 は、パッケージが改ざんされていないことを GPG 署名で検証する設定である。
Q3. EPEL リポジトリは epel-release パッケージをインストールすることで導入できる。
Q4. dnf provides /usr/bin/htop は、htop コマンドがどのパッケージに含まれるかを調べるコマンドである。
Q5. dnf config-manager --set-disabled epel を実行すると、EPEL リポジトリの .repo ファイルが削除される。
Q6. dnf history undo を使うと、過去のインストール操作を取り消して、パッケージをロールバックできる。
Q7. EPEL の GPG 鍵は、epel-release パッケージをインストールした時点で RPM データベースにインポートされる。
解答
Q1. × — httpd や mariadb-server は AppStream リポジトリから提供されます。BaseOS は OS の基盤パッケージ（カーネル、systemd など）を収録しています。
Q2. ○ — gpgcheck=1 により、ダウンロードしたパッケージの GPG 署名が検証され、改ざんがないことが確認されます。
Q3. ○ — sudo dnf install -y epel-release で .repo ファイルと GPG 公開鍵が配置され、EPEL が利用可能になります。
Q4. ○ — dnf provides はファイルパスからパッケージを逆引きするコマンドです。
Q5. × — .repo ファイルは削除されません。ファイル内の enabled= が 0 に変更されるだけです。
Q6. ○ — dnf history undo トランザクションID で、指定したトランザクションの操作を逆転できます。
Q7. × — epel-release インストール時には鍵ファイルが /etc/pki/rpm-gpg/ に配置されるだけです。RPM データベースへのインポートは、EPEL リポジトリからパッケージを初めてインストールするときに行われます。
まとめと次回予告
今回は dnf によるパッケージ管理の全体像を学びました。
覚えておいてほしいポイントは次の3つです。
- AlmaLinux 9 には BaseOS・AppStream・Extras の3つの標準リポジトリがある。EPEL は
epel-releaseで追加できる - GPG 鍵はパッケージの「身元証明」。
gpgcheck=0にしてはいけない dnf historyで変更履歴を確認し、dnf history undoでロールバックできる
第7回から「おまじない」として使ってきた proxy= 設定、前回で学んだプロキシの仕組み、そして今回のリポジトリ構造。3つの知識がつながった感覚があれば、順調に進んでいます。
各コマンドの詳細オプションを知りたいときは man dnf や dnf --help を参照してください。すべてを暗記する必要はなく、「こういうことができる」と知っておけば、必要なときに調べられます。
次回の第20回「ファイアウォール（firewalld）」では、サーバーへの通信を制御する firewalld を学びます。zone・service・port の概念を理解し、firewall-cmd でルールを設定する方法を実践します。パッケージをインストールできるようになった今、サーバーを「守る」技術へと進みましょう。
シリーズ一覧
フェーズ1: エンジニアのいろは（第1回〜第3回）
フェーズ2: Linux基礎（第4回〜第15回）
- 第4回 Linuxとは何か＋環境確認
- 第5回 SSH接続とターミナル操作
- 第6回 ファイルシステムとディレクトリ構造
- 第7回 基本コマンド（ファイル操作）
- 第8回 基本コマンド（テキスト処理・パイプとリダイレクト）
- 第9回 viエディタ
- 第10回 ユーザーとグループ管理
- 第11回 パーミッションと所有権
- 第12回 プロセス管理
- 第13回 systemd
- 第14回 シェルスクリプト入門
- 第15回 フェーズ2まとめ演習
フェーズ3: ネットワークとインフラ基盤（第16回〜第27回）
- 第16回 ネットワーク基礎
- 第17回 ネットワーク設定と疎通確認
- 第18回 企業ネットワークの仕組み
- 第19回 パッケージ管理（この記事）
- 第20回 ファイアウォール（firewalld）
- 第21回 ボンディング/チーミング
- 第22回 VLAN
- 第23回 ログ管理
- 第24回 cron / systemd timer
- 第25回 ストレージ管理（LVM）
- 第26回 シェルスクリプト実践
- 第27回 SSH応用
フェーズ4: サーバー構築と運用（第28回〜第36回）
