第2部 使いこなす
第6章 パッケージ管理 — apt・dnf・pacman
Linuxではソフトを「サイトから探して手動でダウンロード」する必要はほとんどありません。コマンド1つで導入・更新・削除ができ、面倒な依存関係も自動で解決してくれます。この仕組みがパッケージ管理です。
🎯 この章で学ぶこと
- パッケージ管理とは何か、なぜ手動インストールより優れているのか
- 「リポジトリ(公式の倉庫)」という考え方と、その安全性
- Debian系の
apt、Red Hat系のdnf/yumの基本操作 - Arch の
pacman、snap/flatpak、pip/npm との棲み分け - アップデートがセキュリティに直結する理由
6.1 パッケージ管理とは
Windowsでソフトを入れるときは、公式サイトを探してインストーラー(.exe)をダウンロードし、ダブルクリックしてウィザードを進める——という流れが一般的です。Linuxではこれとはまったく違うやり方が主流です。
$ sudo apt install tree
...
The following NEW packages will be installed:
tree
...
Setting up tree (2.0.2-1) ...
$ tree --version
tree v2.0.2 (c) 1996 - 2022 by Steve Baker, ...
たったこれだけで、tree というソフトが探され、ダウンロードされ、インストールされ、すぐ使える状態になりました。この「ソフトのひとまとまり」をパッケージと呼び、それを導入・更新・削除する仕組みをパッケージ管理システム(パッケージマネージャー)と呼びます。
手動インストールと比べたとき、パッケージ管理には大きな利点があります。
- 探す手間がない — ソフト名を指定するだけ。公式サイトをさまよう必要がありません。
- 依存関係を自動解決 — あるソフトが動くのに別のソフト(ライブラリ)が必要なとき、それも一緒に自動で入れてくれます。「AをいれるにはBが要る、BにはCが要る…」を人間が追う必要がありません。
- 更新も一括 — 入れたソフトすべてを、コマンド1つでまとめて最新版に更新できます。
- きれいに削除できる — 不要になったら関連ファイルごと消せます。「アンインストールしても残骸が残る」といった悩みが起きにくいです。
この仕組みは、スマホの App Store や Google Play にそっくりです。信頼できる公式のストアから、名前を選んでインストールし、更新の通知が来たらまとめてアップデートする——パッケージ管理はまさに「Linux版アプリストアをコマンドで操作するもの」だと考えると分かりやすいです。違いは、GUIのストア画面ではなくコマンドで操作する点、そして無数のサーバーへ同じ操作を自動で流せる点です。
6.2 リポジトリという「公式の倉庫」
「名前を指定するだけでソフトが手に入るなら、その中身はどこから来るの?」——答えがリポジトリ(repository、倉庫)です。リポジトリは、ディストリビューションの提供元が管理する信頼できるソフトの配布倉庫で、そこには膨大な数のパッケージが、検証・署名されたうえで並んでいます。
パッケージマネージャーは、あらかじめ登録されたリポジトリの一覧から目的のソフトを探し出し、ダウンロードします。ここが安全性の鍵です。
| 公式リポジトリからの導入 | 野良インストール(手動DL) | |
|---|---|---|
| 入手元 | ディストリ提供元が管理する検証済みの倉庫 | 個人サイト・不明な配布元など様々 |
| 改ざんチェック | 電子署名で検証される(コンピュータ大全のハッシュ・署名の考え方) | 基本的に自分任せ |
| 依存関係 | 自動で解決 | 自分で調べて手作業 |
| 更新 | コマンドで一括 | また手動でダウンロードし直し |
| 安全性 | 高い | 配布元次第。マルウェアの危険 |
公式リポジトリのパッケージには電子署名が付いており、ダウンロード時に「途中で改ざんされていないか」「本当に公式が配布したものか」が自動で確認されます。だから apt install で入れたソフトは信頼できるのです。一方、素性の分からないサイトから落とした .deb ファイルや、「このコマンドを貼り付けて実行するだけ」というインストール手順は、この検証を通らないため、リスクを自分で引き受けることになります(6.6とセキュリティコラムで詳述)。
6.3 Debian系のapt
第1章で見たように、ディストリビューションには系統があり、系統ごとにパッケージマネージャーが違います。まずはUbuntu・DebianなどDebian系で使う apt です。このコースの基準もこちらです。よく使うのは次のコマンド群です。
| コマンド | 何をするか |
|---|---|
sudo apt update | リポジトリの「最新の在庫リスト」を取り込む(ソフト自体は更新しない) |
sudo apt upgrade | インストール済みのソフトを最新版に更新する |
sudo apt install パッケージ名 | ソフトを新しく導入する |
sudo apt remove パッケージ名 | ソフトを削除する(設定ファイルは残す) |
sudo apt purge パッケージ名 | 設定ファイルごと完全に削除する |
apt search キーワード | キーワードでパッケージを検索する |
apt show パッケージ名 | パッケージの詳細情報を表示する |
とても大事なのが update と upgrade の違いです。名前が似ていますが役割はまったく別で、混同しやすいポイントです。
apt update… リポジトリに今どんな新しい版があるかという「在庫リスト」を最新にするだけ。実際のソフトはまだ変わりません。apt upgrade… 取り込んだ在庫リストをもとに、実際にソフトを新しい版へ入れ替える。
だから更新は「まず update で在庫を確認 → 次に upgrade で入れ替え」の順で、セットで行うのが基本です。実際の流れを見てみましょう。
$ sudo apt update
Hit:1 http://archive.ubuntu.com/ubuntu jammy InRelease
Get:2 http://security.ubuntu.com/ubuntu jammy-security InRelease [110 kB]
...
Reading package lists... Done
Building dependency tree... Done
12 packages can be upgraded. Run 'apt list --upgradable' to see them.
$ sudo apt upgrade
Reading package lists... Done
...
The following packages will be upgraded:
curl libcurl4 openssl ...
12 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 8,540 kB of archives.
Do you want to continue? [Y/n] y
...
検索とインストールも見ておきましょう。「httpサーバーを入れたいが正確なパッケージ名が分からない」といった場面では apt search が役立ちます。
$ apt search nginx
Sorting... Done
Full Text Search... Done
nginx/jammy-updates 1.18.0-6ubuntu14 all
small, powerful, scalable web/proxy server
...
$ sudo apt install nginx
...
The following additional packages will be installed:
nginx-common nginx-core ...
0 upgraded, 3 newly installed, 0 to remove ...
Do you want to continue? [Y/n] y
...
Setting up nginx (1.18.0-6ubuntu14) ...
ここで注目してほしいのは、nginx をひとつ指定しただけで nginx-common や nginx-core といった必要な関連パッケージ(依存関係)も自動で一緒に入っている点です。これがパッケージ管理の便利さの真骨頂です。削除も同様に簡単です。
$ sudo apt remove nginx
...
The following packages will be REMOVED:
nginx
0 upgraded, 0 newly installed, 1 to remove ...
Do you want to continue? [Y/n] y
古い資料では apt-get install や apt-cache search という書き方をよく見かけます。これらは今も使えますが、現在は人が対話的に使う分には、より見やすくまとまった apt(apt install / apt search など)を使うのが標準です。スクリプトの中では挙動が安定している apt-get が好まれることもあります。当面は apt を覚えておけば十分です。
6.4 Red Hat系のdnf / yum
RHEL、Rocky Linux、AlmaLinux、Fedora などのRed Hat系では、apt の代わりに dnf(古い環境では yum)を使います。考え方はまったく同じで、コマンド名と一部の言い回しが違うだけです。apt との対応を押さえれば、すぐに使えます。
| やりたいこと | Debian系(apt) | Red Hat系(dnf) |
|---|---|---|
| 在庫リスト更新 | sudo apt update | (基本は自動。sudo dnf check-update) |
| ソフトを更新 | sudo apt upgrade | sudo dnf upgrade |
| 導入 | sudo apt install 名前 | sudo dnf install 名前 |
| 削除 | sudo apt remove 名前 | sudo dnf remove 名前 |
| 検索 | apt search 語 | dnf search 語 |
| 詳細表示 | apt show 名前 | dnf info 名前 |
Red Hat系での導入例です。apt とほとんど同じ感覚で使えることが分かります。
# dnf install nginx
Last metadata expiration check: 0:05:12 ago ...
Dependencies resolved.
================================================================
Package Arch Version Repository Size
================================================================
Installing:
nginx x86_64 1:1.20.1-14 appstream 565 k
Installing dependencies:
...
Is this ok [y/N]: y
...
Complete!
大切なのは、「導入・更新・削除・検索」という4つの操作は、どの系統でも同じように存在するという点です。系統が変わっても、コマンド名の対応表さえあれば戸惑いません。「Debian系は apt、Red Hat系は dnf/yum」——第1章で覚えたこの対応が、ここで実際に効いてきます。
dnf は yum の後継として作られた新しいツールです。現在のRed Hat系では dnf が標準で、多くの環境では yum と打っても dnf が呼び出されるよう設定されています。古い手順書に yum install と書かれていても、そのまま動くことがほとんどです。
6.5 その他のパッケージ管理 — pacman・snap・flatpak・言語ごと
Arch Linux の pacman
上級者に人気のArch Linux系では pacman を使います。オプションの文字が独特ですが、やることは同じです。参考までに対応を挙げておきます。
| 操作 | pacman |
|---|---|
| 導入 | sudo pacman -S 名前 |
| 更新(在庫更新+全更新) | sudo pacman -Syu |
| 削除 | sudo pacman -R 名前 |
| 検索 | pacman -Ss 語 |
ディストリを問わない snap / flatpak
apt や dnf は「そのディストリ専用」の仕組みですが、snap と flatpak はディストリを問わず同じ形式で使える新しい配布方式です。アプリを必要な部品ごと1つに丸ごと包んで配るため、依存関係の相性問題が起きにくいのが特徴です。その代わりサイズが大きく、起動がやや遅い傾向があります。デスクトップ向けアプリでよく使われます。
$ sudo snap install code --classic
code 1.90.0 from Visual Studio Code (vscode✓) installed
言語ごとのパッケージ管理との棲み分け
ここが初学者の混乱ポイントです。apt のようなOS向けのパッケージ管理とは別に、プログラミング言語にはその言語専用のパッケージ管理があります。Pythonの pip(入門コース〈Python〉第7章)、Node.jsの npm などです。役割の違いを整理しましょう。
| 種類 | 例 | 扱う対象 |
|---|---|---|
| OS向け | apt / dnf / pacman | OS全体で使うソフト・コマンド・ライブラリ |
| 言語向け | pip(Python)/ npm(Node.js) | その言語のプログラムから使う専用ライブラリ |
目安として、「Linuxのコマンドやサーバーソフトを入れるなら apt/dnf」「Pythonのライブラリを入れるなら pip」と使い分けます。どちらも「依存関係を解決してソフトを入れる」点は同じですが、管理する世界が違うのです。両者を混ぜると管理が煩雑になるため、目的に応じて適切なほうを選びます。
6.6 アップデートの重要性
パッケージ管理でいちばん地味で、いちばん大切なのがアップデート(更新)です。「動いているのに、なぜわざわざ更新するの?」——理由はセキュリティにあります。
ソフトウェアには、後から脆弱性(セキュリティ上の欠陥)が見つかることがあります。開発元はそれを修正した新しい版を配布しますが、あなたが更新しなければ、欠陥は開いたままです。攻撃者は「まだ更新していないサーバー」を狙って、既知の脆弱性を突いて侵入してきます。放置された古いソフトは、そのまま侵入口になるのです。
だからサーバー運用では、次のように在庫更新と本体更新を続けて実行するのが定番です。
$ sudo apt update && sudo apt upgrade
Hit:1 http://archive.ubuntu.com/ubuntu jammy InRelease
...
Reading package lists... Done
The following packages will be upgraded:
openssl libssl3 ...
14 upgraded, 0 newly installed ...
Do you want to continue? [Y/n] y
ここで使った && は「前のコマンドが成功したら、続けて次を実行する」という意味です(第8章で詳しく扱います)。つまり「在庫リストの更新が成功したら、そのまま本体を更新する」を1行でまとめています。これを定期的に行う習慣が、サーバーを安全に保つ土台になります。第7章で学ぶ cron を使えば、この更新チェックを自動化することもできます。
「更新して動かなくなったら困る」と更新をためらう気持ちは分かります。重要な本番サーバーでは、まずテスト環境で試すなどの慎重さも必要です。しかしセキュリティ更新を放置するリスクは、それを上回ります。大きな情報漏えい事件の多くが、「既に修正版が出ていたのに更新していなかった」古い脆弱性を突かれて起きています。更新は運用の基本動作です。
あなたのサーバーに入るソフトは、すべて「どこかから運ばれてきた」ものです。このソフトの供給経路(サプライチェーン)のどこかに悪意が紛れ込めば、正規の手順で入れたつもりのソフトがマルウェアだった、という事態が起こり得ます。パッケージ管理は、その供給経路の入口を守る最初の関所です。
守りの原則はシンプルです。公式リポジトリを使うこと。公式リポジトリのパッケージは電子署名で検証され、改ざんや偽物が排除されます。一方で注意すべきなのが次の2つです。
- 野良の
.deb/.rpm— 素性の分からないサイトから落としたパッケージファイルは、署名検証をすり抜けます。中身がマルウェアでも気づけません。導入元が信頼できるかを必ず確認します。 curl ... | bash形式のインストール — 「このコマンドを貼り付けるだけ」という手順は、ネット越しに取得したスクリプトを中身を見ないまま管理者権限で実行することを意味します。配布元が乗っ取られていれば、そのまま乗っ取りが成立します。せめて一度ファイルに保存して中身を確認する、信頼できる配布元にだけ使う、といった慎重さが必要です。
「便利だから」と手軽な手順に飛びつく前に、「これはどこから来たソフトか」を一呼吸おいて考える——それがサプライチェーンを守る第一歩です。この話題はセキュリティ中級・上級コースでより深く扱います。
まとめ
- パッケージ管理は、コマンドでソフトを導入・更新・削除し、依存関係も自動解決する仕組み(Linux版アプリストア)
- ソフトは「リポジトリ(公式の倉庫)」から、電子署名で検証されて配布される。だから安全
- Debian系は
apt。update(在庫リスト更新)とupgrade(本体更新)は別物でセットで使う - Red Hat系は
dnf/yum、Archはpacman。操作は同じで名前が違うだけ - snap/flatpakはディストリ非依存、pip/npmは言語ごと。目的で使い分ける
- アップデートの放置は侵入口になる。
sudo apt update && sudo apt upgradeを定期的に。公式リポジトリを使い、野良やcurl | bashに注意
練習問題
同僚が「apt update したのに、ソフトのバージョンが古いままだ」と困っています。何が起きているのか、apt update と apt upgrade の違いに触れて説明してください。
解答を見る
apt update は「リポジトリにどんな新しい版があるか」という在庫リストを最新にするだけで、インストール済みソフト自体は更新しません。実際に新しい版へ入れ替えるのは apt upgrade の役目です。同僚は在庫リストを更新しただけで、本体の更新をしていないため古いままなのです。正しくは sudo apt update のあとに sudo apt upgrade を実行します(sudo apt update && sudo apt upgrade と1行でまとめてもよい)。
あなたはRocky Linux(Red Hat系)のサーバーで作業しています。git を新しく導入したいのですが、いつも使っている sudo apt install git は「コマンドが見つからない」と言われます。(1)なぜですか。(2)正しいコマンドを書いてください。
解答を見る
(1)apt はDebian系(Ubuntu・Debianなど)のパッケージマネージャーで、Red Hat系のRocky Linuxには入っていないからです。系統が違うとパッケージマネージャーも変わります。(2)Red Hat系では dnf(または yum)を使います。sudo dnf install git
やろうとしている「導入」という操作自体は共通で、コマンド名だけが apt → dnf に変わるだけです。
あるツールの公式サイトに「以下を実行するだけでインストールできます」として、curl https://example-tool.dev/install.sh | bash というコマンドが載っていました。このやり方には、公式リポジトリからの apt install と比べてどんなリスクがありますか。より安全にするにはどうすればよいですか。
解答を見る
このコマンドは、ネット越しに取得したスクリプトを中身を確認しないまま実行します(しばしば管理者権限で)。配布元のサイトが乗っ取られていたり、通信が改ざんされたりすると、そのまま悪意あるコードを実行してしまう危険があります。公式リポジトリからの apt install は電子署名で改ざんや偽物が検証されますが、この方式にはその検証がありません。より安全にするには、スクリプトをいったんファイルに保存して中身を読んでから実行する、配布元が本当に信頼できるか確認する、可能なら公式リポジトリや署名付きパッケージでの導入を優先する、といった対策が有効です。