クイックスタート: 午前2時の緊急事態、DNFがすぐに解決！
以前、会社のプロダクションサーバーがセキュリティパッチ適用後にエラーを吐いたことがあります。時刻は午前2時、心臓はバクバク。最初に考えたのは、エラーの原因となっているソフトウェアパッケージを迅速に特定し、対処することでした。その時、DNFが救世主となりました。もしあなたが同様の状況に陥っている、または単にDNFに慣れたいと思っているなら、ここに習得すべき知識があります。問題が発生した時に苦労しないようにしましょう！
DNF (Dandified YUM) は、RHEL 8+、CentOS Stream、Rocky Linux、AlmaLinuxなどのRPMベースのオペレーティングシステムにおけるデフォルトのパッケージマネージャーです。YUMの後継として、優れたパフォーマンス、より安定した依存関係解決機能、そして多くの便利な機能を提供します。
夜を乗り切るための基本的なDNFコマンド:
# 1. システムの更新 (常に最優先事項)
sudo dnf update
# 2. ソフトウェアパッケージのインストール (例: nginx)
sudo dnf install nginx
# 3. ソフトウェアパッケージの削除
sudo dnf remove nginx
# 4. パッケージの検索 (正確な名前を覚えていない場合)
dnf search "php-fpm"
# 5. 特定のファイルを含むパッケージの検索 ("command not found" のデバッグに非常に便利)
dnf provides /usr/bin/htpasswd
上記の5つのコマンドだけで、基本的なソフトウェア管理タスクの大部分を実行できます。これらを習得すれば、サーバーでの作業に自信が持てるようになるでしょう。
詳細解説: DNFとYUMの違いと仕組み
CentOS 7以前のRHELバージョンで作業した経験がある方なら、YUMには非常に慣れているはずです。RHEL 8+およびRocky LinuxやAlmaLinuxのような後継ディストリビューションに移行する際、DNFが新しい代替ソリューションとなりました。それは単に名前が変わっただけでなく、技術的な大きな進歩でもあります。
DNF vs YUM: なぜDNFなのか？
- 新しいバックエンド技術: DNFはopenSUSEの
libsolvライブラリを使用しており、YUMよりもはるかに高速かつ信頼性の高い依存関係解決を実現します。これは、特に複雑なソフトウェアパッケージを更新する際に非常に重要な要素です。 - モジュール管理: DNFはモジュールとストリームの概念を導入し、同じシステム上で同じソフトウェアの複数のバージョン (例: PHP 7.4とPHP 8.0) を競合することなくインストールできるようにします。YUMにはこの機能がありませんでした。
- 安定したAPI: DNFには明確に定義されたAPIがあり、サードパーティツールとの統合が容易になりました。
基本的に、DNFはYUMのより良く、よりスマートなバージョンと考えることができます。
リポジトリの管理: ソフトウェアの供給源
リポジトリは、DNFがソフトウェアパッケージを検索してダウンロードする場所です。リポジトリの設定ファイルは通常/etc/yum.repos.d/ディレクトリに配置されます。各.repoファイルは1つ以上のリポジトリを定義します。
# システムでアクティブなリポジトリを一覧表示
dnf repolist
# 有効化済みおよび無効化済みのリポジトリの詳細を表示
dnf repolist all
新しいリポジトリを追加するには (例: EPEL – Extra Packages for Enterprise Linux、メインリポジトリにないパッケージに非常に便利なリポジトリ):
# EPELリポジトリの設定を含むパッケージをインストール
sudo dnf install epel-release
# その後、リポジトリリストを再度確認
dnf repolist
時々、リポジトリを手動で有効化または無効化する必要があります。これには2つの方法があります。対応する.repoファイルを編集するか、以下のコマンドを使用します。
# リポジトリを有効にする
sudo dnf config-manager --set-enabled <repo_id>
# リポジトリを無効にする
sudo dnf config-manager --set-disabled <repo_id>
パッケージとパッケージグループ情報の検索
dnf search以外にも、ソフトウェアパッケージについてさらに詳しく調べるためのコマンドがあります。
# パッケージの詳細情報 (バージョン、サイズ、説明など) を表示
dnf info nginx
# 利用可能なすべてのパッケージまたはインストール済みのパッケージを一覧表示
dnf list
dnf list installed
dnf list available
# DNFはパッケージグループ (group) のインストールもサポートしており、特定のタスクに非常に便利です
dnf group list
dnf group install "Development Tools"
システムの更新と管理: 安全第一
# アップデートがあるかどうかのみ確認し、インストールはしない
dnf check-update
# すべてのパッケージを最新バージョンに更新
sudo dnf upgrade
私が**非常に価値がある**と感じている機能はdnf historyです。これは、DNFで行われたすべての操作を記録します。何度救われたかわかりません！
# DNFトランザクションの履歴を表示
dnf history
# 特定のトランザクションの詳細を表示 (例: トランザクションID 50)
dnf history info 50
# トランザクションを元に戻す (何か問題があった場合)
sudo dnf history undo 50
# 元に戻す操作をやり直す
sudo dnf history redo 50
正直な話、ある時、午前2時にパッケージを更新した後、サーバーがフリーズしました。幸いなことに、dnf history undoが元に戻すのを助けてくれました。そうでなければ、一週間眠れない夜を過ごしたことでしょう。
応用編: DNFがインストールと削除以上のものとなる時
モジュールとストリームの管理: 柔軟な力
前述の通り、モジュール管理機能はDNFのハイライトです。これにより、競合を心配することなく、異なるバージョンのソフトウェアをインストールできます。例えば、古いアプリケーションにはPHP 7.4が必要で、新しいアプリケーションにはPHP 8.0が必要な場合です。
# 利用可能なすべてのモジュールとストリームを一覧表示
dnf module list
# PHP 8.0 ストリームを有効にしてインストール
sudo dnf module enable php:8.0
sudo dnf install php php-fpm
# PHP 7.4 に切り替える場合 (現在のストリームをリセットする必要がある)
sudo dnf module reset php
sudo dnf module enable php:7.4
sudo dnf install php php-fpm
この機能は、異なるソフトウェアバージョン要件に直面する開発およびプロダクション環境において非常に重要です。
DNFのオフライン利用: 困難な状況への備え
サーバーがインターネットに接続されていない状況 (例: 社内ネットワークのサーバー、エアギャップ環境) があります。このような場合、パッケージのダウンロードとオフラインでのインストールが不可欠になります。
# nginx パッケージとそのすべての依存関係を現在のディレクトリにダウンロード
sudo dnf download --resolve --destdir=./ nginx
# その後、これらの.rpmパッケージをオフラインサーバーにコピーして手動でインストールできます
sudo rpm -ivh *.rpm
DNFの最適化: 速度と効率の向上
/etc/dnf/dnf.conf設定ファイルを通じてDNFの動作を微調整できます。
# dnf.confにおけるいくつかの便利なカスタマイズ例
[main]
kecache=True # ダウンロードしたパッケージをキャッシュに保持し、再インストールを高速化
max_parallel_downloads=10 # 10個のパッケージを同時にダウンロードし、更新速度を向上
deltarpm=True # パッケージの変更部分のみをダウンロードし、帯域幅を節約
これらの小さな調整は、DNFを頻繁に使用する際のパフォーマンスに大きな違いをもたらすことがあります。
血と汗の経験: CentOS 7からAlmaLinuxへの移行とDNFの役割
私の会社にはまだいくつかのCentOS 7サーバーが稼働していました。私はそれらをAlmaLinuxに移行するという課題に直接取り組みました。この移行プロセスにおいて、DNFは重要な役割を果たしました。OSを移行した後、多くのサービスとソフトウェアを再インストールする必要がありました。DNFの強力な依存関係解決能力と柔軟なモジュール管理のおかげで、このプロセスは非常にスムーズに進みました。
CentOS 7上で複雑な依存関係を持ついくつかの古いサービスがあったのを覚えています。しかし、AlmaLinuxに移行してDNFを使用すると、すべてがはるかに管理しやすくなりました。YUMを使用していた頃のような面倒な依存関係エラーに悩まされることなく、必要なPHPやMySQLのバージョンを簡単に再インストールできました。DNFは、もともと非常にストレスの多いプロセスであったものから、本当に負担を軽減してくれました。
実践的なヒント: DNFを強力な味方にするために
システム管理者なら誰でも知っていることですが、理論と現実は大きく異なります。以下に、DNFをより効果的に使用するための私がまとめたヒントをいくつか紹介します。
- 常にアウトプットを注意深く読む: DNFは、インストール、更新、または削除されるパッケージのリストを提示することがよくあります。無意識に
yとEnterを打つのは絶対にやめましょう。以前、リストを注意深く読まなかったために、重要な依存関係を誤って削除しそうになったことがあります。 - 定期的にキャッシュをクリーンアップする: DNFのキャッシュは
/var/cache/dnfにあります。クリーンアップしないと、かなりのディスク容量を占有する可能性があります。 - 依存関係を理解する: DNFは依存関係を自動的に解決します。しかし、特に外部ソースからソフトウェアをインストールする場合やエラーが発生した場合、どのパッケージがどのパッケージに依存しているかを理解する必要があります。
dnf providesとdnf repoquery --requires(dnf-utilsのインストールが必要) は非常に役に立ちます。 - バックアップは金なり: 大規模なシステムアップデート (例: Rocky 8からRocky 9へのアップグレード) を実行する前には、常にサーバーをバックアップするか、仮想マシンのスナップショットを作成してください。DNFはパッケージのロールバックを助けることができますが、OS全体に重大な問題が発生した場合にあなたを救うことはできません。
- DNFでエラーが発生した場合:
- ネットワーク接続を確認する: 時々、エラーは単純にリポジトリに接続できないだけです。
- リポジトリ設定を確認する:
.repoファイルに構文エラーがないか、または間違ったパスを指していないかを確認してください。 - キャッシュをクリアして再試行する: 時々キャッシュが破損していることがあります。
- Google/Stack Overflowでエラーを検索する: 多くのDNFエラーは他の人も経験し、解決しています。
dnf historyはあなたの最高の友人です: すでに強調しましたが、繰り返させてください。デバッグが必要な場合や以前の状態に戻す必要がある場合の救世主です。決して忘れてはいけません！
sudo dnf clean all
# repoquery のために dnf-utils をインストール
sudo dnf install dnf-utils
# パッケージの依存関係を表示
dnf repoquery --requires nginx
DNFは非常に強力で柔軟です。これらの共有が、RHEL/Rocky LinuxでDNFを扱う際に、あなたがより自信を持ち、真夜中にサーバーがエラーを報告しても「心臓がバクバク」することなく対応できるようになることを願っています。
