Product SiteDocumentation Site

15.3. APT 用のパッケージリポジトリの作成

Falcot Corp のメンテナンスする Debian パッケージの数は次第に増えました。この中には既存のパッケージから手元で修正したパッケージや、内部データとプログラムを配布するために最初から作成したパッケージなどがあります。
パッケージの配備を簡単にするために、管理者はこれらのパッケージを APT から直接使うことが可能なパッケージアーカイブに組み込みたいと思っています。明らかなメンテナンス上の理由により、管理者は内部パッケージと手元で再ビルドしたパッケージを別にしたいと思っています。すなわち、最終的に /etc/apt/sources.list.d/falcot.list ファイル内のエントリを以下のようにしたいと思っています。 
deb http://packages.falcot.com/ updates/
deb http://packages.falcot.com/ internal/
このため、管理者は内部 HTTP サーバ上に仮想ホストを設定して、APT リポジトリのルートとして /srv/vhosts/packages/ を割り当てます。パッケージアーカイブ自体の管理は mini-dinstall コマンド (同名のパッケージに含まれます) に委託されます。mini-dinstall ツールは incoming/ ディレクトリ (今回の場合、/srv/vhosts/packages/mini-dinstall/incoming/) を監視して、新しいパッケージがこのディレクトリにアップロードされることを待ちます。そしてパッケージがアップロードされたら、mini-dinstall は /srv/vhosts/packages/ のパッケージアーカイブにパッケージをインストールします。mini-dinstall コマンドは Debian パッケージが生成された時に作成される *.changes ファイルを読みます。*.changes ファイルには、パッケージのバージョンに対応するその他のファイル (*.deb、*.dsc、*.diff.gz/*.debian.tar.gz、*.orig.tar.gz、その他の圧縮ツールを使った場合の同等ファイル) のリストが書かれており、mini-dinstall はこのリストに従ってインストールするファイルを把握します。さらに *.changes ファイルの Distribution ヘッダフィールドには、debian/changelog ファイル内の最新エントリに書かれた対象ディストリビューションの名前 (通常 unstable) が書かれており、mini-dinstall はこの名前に従ってパッケージのインストール先を決めます。このため、管理者は対象パッケージをビルドする前に debian/changelog ファイル内の最新エントリに書かれた対象ディストリビューションの名前を必ず変更し、対象パッケージのインストール先に従ってその名前を internal または updates に設定しなければいけません。この後、mini-dinstall は APT が必要とする Packages.gz などのファイルを生成します。

ALTERNATIVE apt-ftparchive, aptly, and reprepro

必要なパッケージアーカイブが mini-dinstall を使うほど複雑なパッケージアーカイブではない場合、apt-ftparchive コマンドを使うことも可能です。apt-ftparchive ツールは指定したディレクトリの内容を調査して、その内容に対応する Packages ファイルを (標準出力に) 表示します。apt-ftparchive を使う場合、Falcot Corp の管理者はパッケージを直接 /srv/vhosts/packages/updates/ や /srv/vhosts/packages/internal/ にアップロードすることが可能です。その後以下のコマンドを実行して Packages.gz ファイルを作成します。 
$ cd /srv/vhosts/packages
$ apt-ftparchive packages updates >updates/Packages
$ gzip updates/Packages
$ apt-ftparchive packages internal >internal/Packages
$ gzip internal/Packages
apt-ftparchive sources コマンドを使えば、同様の方法で Sources.gz ファイルを作成することが可能です。
reprepro and aptly are more advanced tools for the same purpose. They can produce, manage and synchronize a number of package repositories, mirror other repositories, even cherry-pick packages from official repositories and provide them locally, create signatures of the generated package indices and thus provide signed repositories. reprepro stores packages and checksums in a Berkeley DB database file, so no database server is needed. aptly provides the same functionality, but it can be easier in handling. Unfortunately, both projects, although probably the most feature-rich solutions, are not actively developed at the moment.
reprepro comes with a lot of documentation and examples in /usr/share/doc/reprepro/, while aptly has a vast online documentation.
→ https://www.aptly.info/
mini-dinstall を設定するには、~/.mini-dinstall.conf ファイルをセットアップする必要があります。Falcot Corp では以下の通り設定しました。 
[DEFAULT]
archive_style = flat
archivedir = /srv/vhosts/packages

verify_sigs = 0
mail_to = [email protected]

generate_release = 1
release_origin = Falcot Corp
release_codename = stable

[updates]
release_label = Recompiled Debian Packages

[internal]
release_label = Internal Packages
各パッケージアーカイブに対して Release ファイルを作成することに決めた点は注目に値します。これは /etc/apt/preferences 設定ファイルを使ってパッケージインストール優先度を管理する場合に役立ちます (詳細は第 6.2.5 節「パッケージ優先度の管理」を参照してください)。

SECURITY mini-dinstall とパーミッション

Since mini-dinstall has been designed to run as a regular user, there is no need to run it as root. The easiest way is to configure everything within the user account belonging to the administrator in charge of creating the Debian packages. Since only this administrator has the required permissions to put files in the incoming/ directory, we can deduce that the administrator authenticated the origin of each package prior to deployment and mini-dinstall does not need to do it again. This explains the verify_sigs = 0 parameter (which means that signatures need not be verified). However, if the contents of packages are sensitive, we can reverse the setting and elect to authenticate with a keyring containing the public keys of persons allowed to create packages (configured with the extra_keyrings parameter); mini-dinstall will then check the origin of each incoming package by analyzing the signature integrated to the *.changes file.
mini-dinstall を実行すると、バックグラウンドでデーモンが開始されます。mini-dinstall デーモンが実行されている限り、デーモンは 30 分ごとに incoming/ ディレクトリにアップロードされた新しいパッケージを確認します。そして新しいパッケージがアップロードされると、パッケージはパッケージアーカイブに移動され、適切な Packages.gz と Sources.gz ファイルが再生成されます。デーモンの実行に問題がある場合、incoming/ ディレクトリにパッケージをアップロードしたら毎回、手作業で mini-dinstall をバッチモードで実行します (-b オプションを付けます)。mini-dinstall 他の使い方は mini-dinstall(1) マニュアルページで説明されています。

EXTRA 署名済みパッケージアーカイブの生成

APT スイートは対象のパッケージをインストールする前にそのパッケージに含まれる一連の暗号署名を確認し、そのパッケージの信頼性を確かめます (第 6.6 節「パッケージ信頼性の確認」を参照してください)。この挙動はプライベートパッケージアーカイブにとって問題です。なぜなら、プライベートパッケージアーカイブを使うマシンでは署名されていないパッケージに関する警告が表示され続けるからです。プライベートパッケージアーカイブを安全な APT メカニズムに適合させるのが真面目な管理者の仕事と言えます。
パッケージアーカイブの署名作業を助けるために、mini-dinstall には Release に対する署名の生成に使うスクリプトを指定する release_signscript 設定オプションが含まれます。ここでは mini-dinstall パッケージによって提供された /usr/share/doc/mini-dinstall/examples/ 内に含まれる sign-release.sh スクリプトが良い足掛かりとなるでしょう。しかし、このスクリプトを使うには手元で修正が必要になるかもしれません。