Ubuntu Weekly Recipe

第489回 ARM向けバックポートリポジトリをaptlyで作る

この記事を読むのに必要な時間:およそ 6 分

第485回で紹介したaptlyを使えば,簡単に自分専用のリポジトリを構築できます。さらに第487回の方法で任意のアーキテクチャーのパッケージを作ることができます。今回は応用編ということで,ARM用のバイナリパッケージを提供するバックポートリポジトリを作ってみましょう。

リポジトリの作成

第487回でバイナリパッケージの作成方法を学びました。次はそれを公開するリポジトリをaptlyを用いて作成しましょう。aptlyのインストール方法や基本的な使い方は第485回を参照してください。

aptlyで作ったリポジトリのフロントエンド部分(HTTPサーバー部分)はNginxを使うことにします。第485回ではaptlyが作ったユーザーローカルのディレクトリ~/.aptly/public/をリポジトリとして公開していましたが,NginxなどのHTTPサーバーから外部に公開するのであれば/srv以下のディレクトリに置くのが無難でしょう。よってaptlyを実行するユーザーのホームディレクトリに~/.aptly.confを次のような内容で作成します。もしくは/etc/aptly.confとしてシステムグローバルな設定にしてもかまいません。

{
  "architectures": [ "all", "source", "armhf" ],
  "FileSystemPublishEndpoints": {
    "pomera": {
      "rootDir": "/srv/aptly"
    }
  }
}

「pomera」として公開するリポジトリを/srv/aptly以下に作るよう設定しています。当然のことながらaptlyコマンドを実行するユーザーは該当ディレクトリへの書き込み権限が必要になります。architecturesにはアーキテクチャー非依存とソースパッケージ,それにarmhfを記述していますが,限定しないのであれば空でもかまいません。この設定は個々のaptlyコマンドの-architectureオプションで上書き可能です。

またローカルリポジトリも作りましょう。

$ aptly repo create -distribution=xenial-backports -component=main xenial-armhf

-distributionは公開時のディストリビューション名であり,Ubuntuのリポジトリ/etc/apt/sources.listでいうところの「xenial」「zesty」です。-componentはUbuntuでいうところのmain・universeのようにパッケージの種別ごとに別のディレクトリにしたいときに使用します。最後の「xenial-armhf」がaptlyにおけるリポジトリの名前になります。

パッケージのリポジトリへの取り込み

aptlyのローカルリポジトリにパッケージを取り込みます。第487回でも説明したように,パッケージは「ソースパッケージ」「バイナリパッケージ」の二種類にわかれます。またそれぞれの種類のパッケージは複数のファイルから構成されます。aptlyはこれらのパッケージを取り込むことでリポジトリを構築するのです。

個々のパッケージを構成するファイル群は.changesファイル」としてリストアップされます。.changesファイルにはファイル名だけでなくそのハッシュ値も記録されているために,そのファイルにGPGによる署名を加えるだけでパッケージを構成するファイル群の正当性を担保できるわけです。第487回では話を簡単にするために特に署名のことは考慮せずdebファイルを直接取り込みました。しかしなら単一のソースパッケージから複数のバイナリパッケージを生成する場合は.changesファイルを用いて一度に取り込めたほうが便利ですし,よりまっとうな方法と言えます。今回はその方法を紹介しましょう。

まずは.changesファイルに署名を行う人のGPG公開鍵をaptlyユーザーの鍵束に取り込んでおきます。

(パッケージに署名を行うマシン上で,公開鍵をエクスポートする)
$ gpg --export --armor --output shibata.asc shibata@example.com
$ file shibata.asc
shibata.asc: PGP public key block Public-Key (old)

上記の手順でエクスポートした公開鍵ファイルshibata.ascをaptlyが動くマシン上に何らかの安全な経路を使ってコピーしておきます※1)⁠もちろん鍵サーバーを経由する方法でもかまいません。

※1
公開鍵ファイルのold,newの違いはRFC4880を参照してください。

aptlyが動いているマシン上で,この公開鍵を取り込みます。aptly自身はaptlyコマンドを実行したユーザーの~/.gnupg/trustedkeys.gpgを鍵束として使用しますので,--keyringオプションで指定する必要があります。

$ gpg --no-default-keyring --keyring trustedkeys.gpg --import shibata.asc
gpg: keyring `/home/aptly/.gnupg/trustedkeys.gpg' created
gpg: key DF3CCF34: public key "Mitsuya Shibata <shibata@example.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
gpg: public key of ultimately trusted key 73C2FAC3 not found
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u

最後に取り込んだGPG公開鍵で署名された.changesファイルをリポジトリに取り込んでみましょう。第487回のやり方に沿ってパッケージをビルドしていれば,ソースパッケージについてはGPG公開鍵による署名が行われているはずです。このソースパッケージをaptlyを実行するマシン上にコピーし,次のコマンドを実行してください。

$ aptly repo include -repo=xenial-armhf tmux_2.5-3build1~ubuntu16.04.1_source.changes
gpgv: Signature made Sat Sep  2 12:18:40 2017 JST using RSA key ID DF3CCF34
gpgv: Good signature from "Mitsuya Shibata <shibata@example.com>"
Loading repository xenial-armhf for changes file tmux_2.5-3build1~ubuntu16.04.1_source.changes...
[+] tmux_2.5-3build1~ubuntu16.04.1_source added

-repoオプションで取り込むリポジトリ名を指定します。省略した場合は,.changesファイルのDistributionフィールドの名前が使われます。また.changesファイルの代わりにディレクトリを指定した場合は,そのディレクトリ内部の.changesファイルを順番にチェックしていきます。

-uploaders-fileオプションを使うと,ユーザー単位でリポジトリへのアップロード権限を細かく設定するJSONファイルを指定できます。詳細は公式ドキュメントの「UPLOADERS.JSON」の項目を参照してください。このオプションを指定しない場合は,すべてのユーザーが自由にパッケージを取り込める状態となります。ただしその場合もオプションで無効化しない限り,.changesファイルの署名のチェックは行います。ちなみにaptly repo createのときにも指定できます。

同じ名前・アーキテクチャー・バージョンのファイルを同じリポジトリ上に取り込みたい場合は,明示的に-force-replaceオプションを付けなくてはなりません。

リポジトリにパッケージを取り込むことに成功したら,オリジナルのパッケージファイルは削除されます。もし残したい場合は-no-remove-filesオプションを付けてください。

aptly repo showコマンドで,そのローカルリポジトリ上にあるパッケージのリストを得られます。

$ aptly repo show --with-packages=true xenial-armhf
Name: xenial-armhf
Comment:
Default Distribution: xenial-backports
Default Component: main
Number of packages: 1
Packages:
  tmux_2.5-3build1~ubuntu16.04.1_source

著者プロフィール

柴田充也(しばたみつや)

Ubuntu Japanese Team Member株式会社 創夢所属。数年前にLaunchpad上でStellariumの翻訳をしたことがきっかけで,Ubuntuの翻訳にも関わるようになりました。

コメント

コメントの記入