🎯 この章で学ぶこと

  • パッケージ管理とは何か、なぜ手動インストールより優れているのか
  • 「リポジトリ(公式の倉庫)」という考え方と、その安全性
  • 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 というソフトが探され、ダウンロードされ、インストールされ、すぐ使える状態になりました。この「ソフトのひとまとまり」をパッケージと呼び、それを導入・更新・削除する仕組みをパッケージ管理システム(パッケージマネージャー)と呼びます。

手動インストールと比べたとき、パッケージ管理には大きな利点があります。

💡 スマホのアプリストアに似ている

この仕組みは、スマホの 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 の違いです。名前が似ていますが役割はまったく別で、混同しやすいポイントです。

だから更新は「まず 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 と apt-get の関係

古い資料では 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 upgradesudo 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 の関係

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 / pacmanOS全体で使うソフト・コマンド・ライブラリ
言語向け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 形式のインストール — 「このコマンドを貼り付けるだけ」という手順は、ネット越しに取得したスクリプトを中身を見ないまま管理者権限で実行することを意味します。配布元が乗っ取られていれば、そのまま乗っ取りが成立します。せめて一度ファイルに保存して中身を確認する、信頼できる配布元にだけ使う、といった慎重さが必要です。

「便利だから」と手軽な手順に飛びつく前に、「これはどこから来たソフトか」を一呼吸おいて考える——それがサプライチェーンを守る第一歩です。この話題はセキュリティ中級・上級コースでより深く扱います。

まとめ

練習問題

問題 6-1

同僚が「apt update したのに、ソフトのバージョンが古いままだ」と困っています。何が起きているのか、apt update と apt upgrade の違いに触れて説明してください。

解答を見る

apt update は「リポジトリにどんな新しい版があるか」という在庫リストを最新にするだけで、インストール済みソフト自体は更新しません。実際に新しい版へ入れ替えるのは apt upgrade の役目です。同僚は在庫リストを更新しただけで、本体の更新をしていないため古いままなのです。正しくは sudo apt update のあとに sudo apt upgrade を実行します(sudo apt update && sudo apt upgrade と1行でまとめてもよい)。

問題 6-2

あなたは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 に変わるだけです。

問題 6-3

あるツールの公式サイトに「以下を実行するだけでインストールできます」として、curl https://example-tool.dev/install.sh | bash というコマンドが載っていました。このやり方には、公式リポジトリからの apt install と比べてどんなリスクがありますか。より安全にするにはどうすればよいですか。

解答を見る

このコマンドは、ネット越しに取得したスクリプトを中身を確認しないまま実行します(しばしば管理者権限で)。配布元のサイトが乗っ取られていたり、通信が改ざんされたりすると、そのまま悪意あるコードを実行してしまう危険があります。公式リポジトリからの apt install は電子署名で改ざんや偽物が検証されますが、この方式にはその検証がありません。より安全にするには、スクリプトをいったんファイルに保存して中身を読んでから実行する、配布元が本当に信頼できるか確認する、可能なら公式リポジトリや署名付きパッケージでの導入を優先する、といった対策が有効です。