マイニングを通して見えてきた、Debian/Ubuntu 系と Red Hat 系の違い

前回の記事の続き

interier.hatenablog.com

前回マイニングを実際に実現すること自体は成功した。
今度は実際に打ったコマンドをもう少し掘り下げて学んでみたいと思う。

● apt update
これは「最新のパッケージ情報を取りに行く」。 いわば “カタログの更新”。

● apt upgrade
これは「実際にアップデートを適用する」。 つまり “中身の更新”。

debian系のUbuntuをもとにZorinOSはAPTなんだけど、Red Hat 系（RHEL / Rocky / AlmaLinux）だとまた別のコマンドとなる。

● インデックス更新（更新確認）

dnf check-update

● 実際の更新

dnf update

docker run -it --rm \

docker run -it --rm \

docker run -it --rm \

● sudo apt install -y ca-certificates curl gnupg lsb-release
Docker のリポジトリを追加するために必要なパッケージを揃える工程。

● -y

すべての質問に自動で「yes」 → スクリプトや自動化でよく使う

● ca-certificates

Docker や XMRig をセットアップしたとき、 外部サイトにアクセスすることになる。

• Docker の公式リポジトリ

• GitHub

• XMRig のダウンロード元

• SupportXMR の API

• APT の外部リポジトリ

これらはすべて HTTPS で通信している。

HTTPS では、 サーバーが提示する証明書を検証する必要がある。

その検証に使うのが CA の公開鍵。

つまり ca-certificates がないと：

• HTTPS が信用できない

• APT が外部リポジトリに接続できない

• curl が証明書エラーで止まる

• Docker の GPG キー取得が失敗する

• GitHub からのダウンロードが拒否される

実際、証明書が壊れている環境だと curl: (60) SSL certificate problem というエラーが出る。

APT は HTTPS リポジトリを扱うとき、
必ず証明書を検証する。例えば・・・・・

deb [arch=amd64] https://download.docker.com/linux/ubuntu jammy stable

APT はこう動く：

1. サーバーが証明書を提示

2. APT がその証明書を CA の公開鍵で検証

3. 問題なければ通信を許可

4. パッケージ情報を取得

つまり、APT の安全性は ca-certificates が正しくインストールされていることが前提。

処理ステップ	具体的に何が起きているか	技術的ポイント（LPIC/LinuC）
① サーバーが証明書を提示	APT がリポジトリ（例：https://download.docker.com）へ接続すると、サーバー側が「これが私の証明書です」と送ってくる	HTTPS の基本動作。TLS ハンドシェイクの最初の段階
② APT がその証明書を CA の公開鍵で検証	サーバー証明書が本物かどうか、ca-certificates に含まれる「信頼された認証局（CA）」の公開鍵で検証する	公開鍵暗号方式、CA、信頼チェーン（root → intermediate → server）
③ 問題なければ通信を許可	証明書が正しければ、APT は「このサーバーは信頼できる」と判断し、暗号化された通信を開始する	TLS セッション確立、MITM（中間者攻撃）防止
④ パッケージ情報を取得	APT がリポジトリから Packages や Release などのメタ情報をダウンロードし、/var/lib/apt/lists/ に保存する	APT のインデックス更新（apt update の本質）

● curl

 curl = URL を指定して、いろんなプロトコル越しにデータを取りに行くコマンドラインクライアント。

gnupg と lsb-release はセットで使われる

外部リポジトリを追加するときの流れはこうなる：

1. curl で GPG キーを取得

2. gnupg でそのキーが本物か検証

3. lsb-release で OS の種類・コードネームを判定

4. APT が正しいリポジトリを安全に使う

あなたが Docker を入れたとき、 この流れが全部裏で動いていた。