\ay diary

apt-proxyがあまりにもよくささるのでapt-cacher-ngを試してみている。比較的新しいパッケージのようでsidにしかパッケージがないが、rebuildすればetchでも使える。今のところ特に問題なく動作しているが、少し様子を見てみようと思う。以下、間違いがあるかもしれないけれど。

apt-cacher-ngはAPT用のキャッシュ機能付きプロキシであり、二種類のリクエストに対応している。一つは一般的なHTTPプロキシとして運用する形態。もう一つは自身で仮想的なURIをサービスする形態。両者の違いはapt-cacher-ngのクライアントととなるAPTの設定を考えればすぐに分かる。まず前者、HTTPプロキシとしてapt-cacher-ngを動作させている環境を考える。このときに必要なAPTの設定は以下の内容で/etc/apt/apt.conf.d/02proxyといった名前のファイルを作ることになる。

Acquire::http { Proxy "http://acng.example.jp:3142"; };

これはAPTに対するHTTPプロキシの設定で、acng.example.jp:3142というのがapt-cacher-ngを動作させているホスト名とポートになる(3142はデフォルト設定のポート)。次に後者、仮想的なURIでのサービスが行われている環境では、そのURIを/etc/apt/sources.list.d/acng.listといった名前のファイルに記述しておく。たとえば次のように。

deb http://acng.example.jp:3142/debian etch main

これはつまり通常通りのsources.listの設定であって、使用するアーカイブのURIをapt-cacher-ngで提供しているものに合わせればよい(むろんHTTPプロキシの設定は不要となる)。

これらの運用上の違いとしては、前者ではsources.listの設定をごく普通に行えばよいのに対し、後者ではプライベートなURIでsources.listを構成しなければならない。よって今動いているシステムについて移行させようとするなら前者のほうが手間が少なくてすむ。一方、後者では、一つの仮想URIに複数のアーカイブを明示的に対応付けられるため、実際にアクセスするアーカイブを中央で管理するといったことが簡単に(あるいは明示的に)できる*1。

さて、そのためのapt-cacher-ng側の設定である。これは/etc/apt-cacher-ng/acng.confを中心に行う。ポートの設定やログの設定などいくつかのディレクティブが見られるはずだが、それらは適当にしておいて、apt-cacher-ngで提供するアーカイブへのアクセスの設定を見ていく。

使用するディレクティブはRemap-nameである。書式は以下の通り。

Remap-name: request-pattern ... [ ; archive-uri ... ]

これにより、リクエストされたURIをどのアーカイブに中継するかというルールの定義をしていく。

Remap-に続くnameは、キャッシュ管理のための名前となる。同じ名前で複数のルール定義を行うと、中継先アーカイブからの得られるリソースがすべて同じキャッシュに投入される。中継先を指定するのはarchive-uriで、基本的には通常sources.listに記述する際のDebianアーカイブのURIのベース部分、たとえばhttp://ftp.jp.debian.org/debian/などを記述する。つまり、リクエストされたURIのベース部分がarchive-uriに置き換えられて中継先のURIとなる。

では、どのようなURIを持つリクエストに対してルールを適用するかだが、request-patternによってそれを指定する。この部分に記述した文字列とリクエストされたURIとが比較され、マッチした場合にそのルールが適用される(ワイルドカードや正規表現は使えない)。比較対象となるのはリクエストされたURIそのもので、HTTPプロキシとして運用しているならhttp://から始まるURIであり、仮想URIでの運用なら通常はパス部分だけのURIとなる。request-patternにはhttp://から始まるURI、パス部分だけのURI、ホスト名がトップディレクトリとなるよう変形したパス名のいずれが記述できる。前二者については前方一致していればマッチしたとみなされる。最後の一つについては、リクエストされたURIを同じように変形した上で前方一致していればマッチしたとみなされる。

たとえば/ftp.jp.debian.org/debian/がルールで指定されていたとすると、http://ftp.jp.debian.org/debian/dists/...のようなURIを持つリクエストがマッチする。また、/ftp.debian.org/debian/dists/...のようなURIを持つリクエストについても同様にマッチする。つまり、HTTPプロキシとして運用している場合には、リクエストされるURIがhttp://から始まるものとなり、仮想的なURIで運用している場合には、その仮想的なURIのパス部分になる。したがって、apt-cacher-ngをHTTPプロキシとして運用するか、仮想URIで運用するかについては、apt-cacher-ng側から見るとそれほど厳密な違いというわけではないとも言える。

Remap-の二つめと三つめの部分については、空白で区切って複数のエントリを記述することができるが、より簡単に記述できるよう別ファイルから読み込ませることもできる。特に二つめのパターン部についてはあらかじめDebianアーカイブのミラーにマッチさせるためのファイルが用意されている。デフォルトの設定に含まれる以下の記述がそれで、file:から始まる文字列を記述することで、/etc/apt-cacher-ng以下のファイルを読み込ませることができる(ここではワイルドカードが使える)。

Remap-debrep: file:deb_mirror*.gz /debian ; file:backends_debian

file:で読み込ませるファイルの書式は、パターンについてはメールメッセージに似た形式になり、中継先アーカイブについてはURIのリストとなる。前者についての詳しい書き方は明らかではないが、見ればなんとなく意味はとれると思う。デフォルト状態での/etc/apt-cacher-ng/backends_debianは空のファイルであるが、このように中継先がまったく指定されていない場合にはリクエストされたURIにそのまま中継される。この場合、一般的なHTTPプロキシと同じような動作となるが、したがって、仮想URI運用の際には中継先を指定しなければならないことになる。

ここで設定例をいくつか。

# deb_mirror*.gzからパターンを読み込み、backends_debianにリスされたURIに中継する。
# backends_debianが空ならリクエストURIにそのまま中継する。
Remap-debrep: file:deb_mirror*.gz /debian ; file:backends_debian
 
# http://acng.example.jp:3142/debianによる仮想URI運用。
# 二つのDebianアーカイブのミラーにサイトに中継する。
Remap-debrep: /debian ; http://ftp.jp.debian.org/debian/ http://ftp.us.debian.org/debian/
 
# http://foo.example.com/debianに対するリクエストを
# http://private-mirror.example.jp/foo-debian-mirror/debainに中継する
Remap-foo: /foo.example.com/debian ; http://private-mirror.example.jp/foo-debian-mirror/debain/

一つめと二つめのルールは、どちらも名前がdebrepとなっている。このため、どちらのルールにマッチしたとしても同じキャッシュが用いられる(/var/cache/apt-cacher-ng/debrep以下にキャッシュが作られる)。

設定ができたらapt-cacher-ngを起動させる。このとき、前述したサービス形態のこととは別に、apt-cacher-ngの動作のさせ方にも二通りの方法がある。一つはapt-cacher-ngというサーバプログラムだけによってAPTからのリクエストを処理する形態、もう一つはinetd配下に橋渡し役のプログラムin.acngを置き、それを経由してAPTからのリクエストを処理する形態である。現在のところapt-cacher-ng自体にはアクセス制御の機能がないため、それが必要な状況ではinetdとtcpdの組み合わせで制御を行わなくてはならない(最後に述べる通り、外部からアクセス可能なホストについては基本的に後者で運用する必要がある)。ちなみにbindアドレスの設定もできない。

前者、単体で動作させるには特別な設定はいらない。通常通りinvoke-rc.d apt-cacher-ng startなどしとて起動すればよい。設定ファイルのPortに記述されたポート(デフォルトで3142)でサービスが提供されるはずである。後者についてはinetdの設定が必要となる。inetdにはいくつかの実装があるがopenbsd-inetdなどはtcpwrapperを含んでいて使いやすい(tcpwrapper機能を使うためには/etc/defaults/openbsd-inetdにOPTIONS='-l'のような記述を入れておくこと)。ともかくinetd.confの設定を行うために以下を実行する(手動でエントリを記述する場合のはリロードを忘れずに)。

# update-inetd --add '9999\t\tstream\ttcp\tnowait\tapt-cacher-ng\t/usr/lib/apt-cacher-ng/in.acng /var/run/apt-cacher-ng/socket'

in.acngは、引数で指定したソケットを使ってapt-cacher-ngにアクセスすることで、APTに対するサービスを行う。つまりinetd経由で動せさせるとしてもapt-cacher-ngは動作させておく必要がある。となると、apt-cacher-ngがサービスしているポートはそのままとなってしまい、これはよろしくない。このようなときにはacfg.confのPortで-1を指定してやるとよいようだ。

Port: -1

これにより、TCPポートを使用せず、UNIXドメインソケットのみを使用して動作するようになる。あとは/etc/hosts.allowと/etc/hosts.denyでアクセス制御を行えばよい。

最後に運用状態を参照しておこう。apt-cacher-ngでは、設定ファイルのReportPageに指定したURI(デフォルトのままならhttp://acng.example.jp:3142/acng-report.html)にアクセスすると送受信されたデータ量やキャッシュがどの程度活用されたかを参照できる。また、キャッシュに対する制御やパッケージの追加といった操作も同じページから実行できることには特に注意が必要となる。このことがあるため、とりわけ外部からのアクセスが可能なホストにおいては少なくともReportPageに対して外部からアクセスできないよう適切なアクセス制御を行っておかなくてはならない。