TT Lab
はじめる
学ぶ 学習パス コース

パッケージ管理

リポジトリとは結局インデックスファイル一つだ

TT Labで続きを見る

一言でいうと

aptリポジトリの実体は、.debファイルが置かれたディレクトリ + Packagesというインデックスファイルです。それさえあれば、file:///も立派なリポジトリになります。

なぜ必要なのか

エアギャップ環境、社内標準イメージ、CIキャッシュ。インターネットに出られない、または出てはいけない環境は、思ったより多いものです。このとき選択肢は2つです。必要な.debを1つずつ手で運ぶか、リポジトリ自体を内側に立てるか。1つ目は3回ほど繰り返すと耐えられなくなり、2つ目は一度作れば使い続けられます。

どう動くのか

aptがリポジトリから実際に読むものは、驚くほど単純です。

저장소 루트/
  Packages         <- 각 .deb 의 control 필드 + Filename + Size + SHA256
  Packages.gz      <- 위의 압축본 (apt 는 압축본을 선호한다)
  Release          <- 저장소 메타데이터 (Origin, Suite, Components, 체크섬)
  *.deb            <- 실제 패키지 파일

Packagesは、各パッケージのcontrolフィールドをつなげて、そこにFilename(リポジトリルートを基準とした相対パス)、Size、SHA256を加えたテキストファイルです。これを作ってくれるツールが、dpkg-scanpackages(簡単)とapt-ftparchive(大規模)です。

cd /root/repo
dpkg-scanpackages . /dev/null > Packages
gzip -kf Packages

そして、sources.listに1行を追加します。

deb [trusted=yes] file:/root/repo ./

最後の./がflatリポジトリ(dists/の階層なしで、ルートにPackagesがある形)を意味します。[trusted=yes]は、GPG署名のないリポジトリを信頼するという印です。ラボや社内の一時的なリポジトリではよく使いますが、運用リポジトリなら必ず署名する必要があります。署名のないリポジトリは、途中で誰かが.debをすり替えても気づけません。

ここで、2つの層の検証を区別する必要があります。

層 何を保証するか ツール
チェックサム(SHA256) 転送中の破損がなかった sha256sum -c
署名(GPG) 出どころが自分の知っている場所である gpg --verify、apt-key/signed-by

同じ媒体にだけ入っているチェックサムは、媒体がまるごと入れ替わると一緒に変わります。そのため、完全性の最後の砦は、常に署名です。

現場での姿

「リポジトリにパッケージを入れたのに、サーバーから見えない」。エアギャップ環境の運用で最も多く寄せられる報告です。原因の大半は、次の2つのどちらかです。インデックスを作り直していないか(dpkg-scanpackages / createrepo_c --updateを忘れた)、クライアントがキャッシュを更新していないか(apt-get updateをしていない)。どちらも「ファイルは確かにそこにあるのに」という、やりきれない状況を作ります。

リポジトリ名にスナップショットの日付を入れておく習慣。name=LabHub local (snapshot 2026-08-15)のように書いておくと、半年後に「このサーバーは、いつの時点のコンテンツでインストールされたのか」という質問に、apt-cache policyの1行で答えられます。

エアギャップ環境への持ち込みを手順にする

前のモジュールでUSBを3–4回往復する話をしました。それをなくすには、持ち込みを場当たり的なお使いではなく、再現できる手順にする必要があります。要領は、「何を持っていくか」を、外側で機械的に計算しておくことです。

依存関係を丸ごと解いた結果を取得する。外側の同じディストリビューション・同じバージョンの環境で、必要なパッケージをインストールしてみて、そのとき取得されたすべてのファイルを集めます。実際にインストールまでしてみることが重要です。一覧だけを計算すると、内側の環境にすでにあるものとないものの差のために、ずれやすくなります。そのため、内側と同じ状態のコンテナを外側に1つ作っておくことが、この作業の核心となる仕掛けです。

バンドルにマニフェストを一緒に入れる。ファイルの一覧、各ファイルのチェックサム、どのディストリビューションのどの時点のリポジトリから取得したか、そして何をインストールしようとしていたのか。この文書がないと、数か月後にそのUSBが何なのか、誰にもわかりません。

内側で検証してインストールする。マニフェストのチェックサムで転送の破損を確認し、可能なら署名まで確認してから、リポジトリを更新します。先ほど見たとおり、チェックサムは破損だけを、署名は出どころを保証します。

インストール結果を記録として残す。どのサーバーにいつどのバンドルを入れたかが残っていてこそ、次に問題が起きたとき、「このサーバーはどの時点のものか」に答えられます。先ほど述べたリポジトリ名にスナップショットの日付を入れておく習慣が、この記録の最も安上がりな形です。

この手順の価値は、時間の節約だけではありません。エアギャップ環境で最も危険なのは、急いでいるという理由で検証を飛ばすことで、手順が文書としてあれば、急いでいるときでも、どの段階なら飛ばしてよいのかが自分でわかります。

次のラボですること

2つのラボを続けて行います。まず自分でビルドした.debでflatリポジトリを立てて、インストールまで行い、そのあとは、すでにインストールされているパッケージの依存関係をまるごとダウンロードして、マニフェストとチェックサムを備えた持ち込みバンドルを作り、オフラインインストールを再現します。