コグノスケ

独自のaptサーバー - その2 - apt-ftparchiveの設定、実行

目次: apt

WebサーバーあるいはFTPサーバーでDebianパッケージを配布する場合、*.debファイル以外にContents, Package, Releaseファイルが必要です。これらのファイルを作成するためのツールがapt-ftparchiveです。

今回はHTMLサーバーで配布することを考えます。Debianだと /var/wwwがルートディレクトリになっていることが多いと思います。以降 /var/wwwがルートディレクトリだとします。

ディレクトリ構成は前回紹介（2019年8月11日の日記参照）したDockerのディレクトリ構成に習うとします。Debianパッケージはどんなファイルでも良いです（後ほどテストするときのためamd64向けのパッケージのほうが良いです）が、今回はDockerのパッケージを1つダウンロードしてきて試します。

# cd /var/www

# tree linux

linux
|-- conf
|   |-- apt_generate_debian_buster.conf
|   `-- apt_release_debian_buster.conf
`-- debian
    `-- dists
        `-- buster
            |-- pool
            |   `-- stable
            |       `-- amd64
            |           `-- docker-ce_19.03.1~3-0~debian-buster_amd64.deb
            `-- stable
                `-- binary-amd64

9 directories, 3 files

Debianパッケージのみを配置した後のディレクトリ構造は上記のようになります。

apt-ftparchiveの設定ファイル

設定ファイルはapt_generate_debian_buster.confとapt_release_debian_buster.confと2つを使います。前者はディレクトリ構造を指定するファイルで、apt-ftparchive generateの引数に指定します。後者はリリース情報（ラベル、オリジナルなど）を指定するファイルで、apt-ftparchive releaseの -cオプションに指定します。

各設定ファイルの書き方を紹介します。

Dir::ArchiveDir ".";
Dir::CacheDir   "dists/buster";
Default::Packages::Compress   ". gzip bzip2";
Default::Packages::Extensions ".deb";
Default::Sources::Compress    ". gzip bzip2";
Default::Contents::Compress   ". gzip bzip2";
Default::FileMode             0644;
TreeDefault::Directory        "dists/buster/pool/stable/amd64";
TreeDefault::Packages         "dists/buster/stable/binary-amd64/Packages";

Tree "dists/buster" {
    Sections "stable";
    Architectures "amd64";
};

BinDirectory "dists/buster/stable/binary-amd64" {
    Packages "dists/buster/stable/binary-amd64/Packages";
    Contents "dists/buster/stable/Contents-amd64";
};

この設定ファイルにはいくつかディレクトリパスが登場します。パスはapt-ftparchiveを実行するディレクトリ（/var/www/linux/buster）からの相対パスで記述します。

Tree::SectionsとTree::Architecturesは少し特殊で、ディレクトリパスの一部を構成します。{Tree}/{Sections} ディレクトリにContentsファイルが作成され、{Tree}/{Sections}/{Architectures} ディレクトリにPackagesファイルが作成されます。

...

Tree "dists/buster" {
    Sections "stable testing";
    Architectures "amd64";
};

上記のようにTree::Sectionsには複数のセクションが指定でき、Tree::Architecturesには複数のアーキテクチャが指定できるはずですが、今のところTreeDefault::Packagesとの対応がよくわからず、使いこなせていません。複数のセクションを同時に指定する手段が見つかったら、また日記で書こうと思います。

APT::FTPArchive::Release {
    Architectures "amd64";
    Components "stable";
    Label "Test Label";
    Origin "Test";
    Suite "buster";
};

リリース情報を記述するファイルは上記のように書きます。APT::FTPArchive::Releaseには他のフィールドも記述できます。apt-ftparchiveのreleaseコマンドのヘルプ（リンク）によると「Origin, Label, Suite, Version, Codename, Date, NotAutomatic, ButAutomaticUpgrades, Acquire-By-Hash, Valid-Until, Signed-By, Architectures, Components, Description」が指定できるとのことですが、意味が説明されておらず、何を書くべきなのかわかりません……。

apt-ftparchiveの実行

設定ファイルを記述した後はapt-ftparchiveを実行して、Debianパッケージの情報について記述したContents, Packages, Releaseの各ファイルを作成します。

# export TARGET=debian
# export DIST=buster
# export SECT=stable
# export ARCH=amd64
# mkdir -p /var/www/linux/${TARGET}/dists/${DIST}/${SECT}/binary-${ARCH}
# mkdir -p /var/www/linux/${TARGET}/dists/${DIST}/pool/${SECT}/${ARCH}


### *.debファイルをコピーする（モジュールによってコピー元は違うと思うので、これは一例）
### cp *.deb /var/www/linux/${TARGET}/dists/${DIST}/pool/${SECT}/${ARCH}


### Packages, Contentsファイルを作る
### linux/debianの下でapt-ftparchiveを実行しないと *.debが見つからないといわれる

# cd /var/www/linux/${TARGET}
# find . -name "Contents-*" -or -name "Contents-*.*" | xargs rm -f
# find . -name "Packages" -or -name "Packages.*" -or -name "packages-*" | xargs rm -f
# find . -name Release -or -name Release.gpg -or -name InRelease | xargs rm -f
# apt-ftparchive generate ../conf/apt_generate_${TARGET}_${DIST}.conf


### Releaseファイルを作る
### linux/debian/dists/busterの下でapt-ftparchiveを実行しないと、
### 後ほどapt-getを実行した際にパッケージが見つからないといわれる

# cd /var/www/linux/${TARGET}/dists/${DIST}
# apt-ftparchive release -c=../../../conf/apt_release_${TARGET}_${DIST}.conf . > Release

作成手順は以上のような感じですが、かなりパスに依存した動きで癖が強いです。正直言ってわかりにくいです。

# tree linux

linux
|-- conf
|   |-- apt_generate_debian_buster.conf
|   `-- apt_release_debian_buster.conf
`-- debian
   `-- dists
        `-- buster
            |-- Release
            |-- packages-amd64.db
            |-- pool
            |   `-- stable
            |       `-- amd64
            |           `-- docker-ce_19.03.1~3-0~debian-buster_amd64.deb
            `-- stable
                |-- Contents-amd64
                |-- Contents-amd64.bz2
                |-- Contents-amd64.gz
                `-- binary-amd64
                    |-- Packages
                    |-- Packages.bz2
                    `-- Packages.gz

コマンド実行後、Contents, Packages, Releaseファイルが生成され、上記のように配置されます。

独自aptサーバー完成ならず？

Contents, Packages, Releaseファイルがあればapt-getにaptサーバーとして認識してもらえるはずです。

deb [arch=amd64] http://192.168.1.1/linux/debian/ buster stable

適当なDebianマシンのaptの設定ファイルに、さきほど作成した独自aptサーバーを追加し apt-get updateを実行します。HTTPサーバーのIPアドレスは192.168.1.1とします。

# apt-get update

Ign:1 http://192.168.1.1/linux/debian buster InRelease
Get:2 http://192.168.1.1/linux/debian buster Release [3233 B]
Ign:3 http://192.168.1.1/linux/debian buster Release.gpg
Hit:4 http://ftp.jp.debian.org/debian testing InRelease
Reading package lists... Done
E: The repository 'http://192.168.1.1/linux/debian buster Release' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

残念ながらエラーになりました……。

Contents, Packages, Releaseファイルを作成しても終わりではありません。aptには悪意ある者がDebianパッケージを改変しても検知できる仕組みが搭載されていて、その対応をしないと「信用できないリポジトリ」だといわれてエラーになります。

（追記）下記が間違っていたので直しました。

（誤）
TreeDefault::Directory        "dists/buster/pool/stable/stable/amd64";

（正）
TreeDefault::Directory        "dists/buster/pool/stable/amd64";

独自のaptサーバー - その1 - ディレクトリ構成

目次: apt

会社で独自のDebianパッケージを配布する際に、難しくてかなり困ったので、下調べの結果を兼ねてメモしておきます。

やりたいこととしては、独自に作成したDebianパッケージ（*.debファイル）を、

• 複数のOS: Debian, Ubuntuなど
• 複数の版: stable, testing, nightlyなど
• 複数のアーキテクチャ: amd64, arm64など

この3つをどのように組み合わせても対応できるような、ディレクトリ構成と、aptサーバーの設定を作成することです。

Dockerが参考になる

ディレクトリ構成は、最初から考えるのは大変なので、参考としてDockerのaptリポジトリ（リンク）を見てみます。

debian/
    dists/
        buster/ : Debian 10.0
            edge/ : なんだろ？
            nightly/ : 1日ごとにビルドされた版
            pool/ : *.debが入っているディレクトリ
            stable/ : 安定版
            test/ : テスト版？
        jessie/  : Debian 8.0
        stretch/ : Debian 9.0
        wheezy/  : Debian 7.0
    gpg : GnuPGの公開鍵、apt-keyで追加する

ubuntu/
    dists/
        artful/  : Ubuntu 17.10
        bionic/  : Ubuntu 18.04 LTS
        cosmic/  : Ubuntu 18.10
        disco/   : Ubuntu 19.04
        trusty/  : Ubuntu 14.04 LTS
        xenial/  : Ubuntu 16.04 LTS
        yakkety/ : Ubuntu 16.10
        zesty/   : Ubuntu 17.04
    gpg : GnuPGの公開鍵、apt-keyで追加する

こんな作りになっています。debian/distsもしくはubuntu/distsの下に各バージョンのコードネームが並んでいます。例えばdebian/dists/busterであればDebian 10.0用です。

コードネームのディレクトリの下には、各版stable, test用のディレクトリが並んでいます。poolディレクトリは版名ではなくて、パッケージファイル *.debを格納するディレクトリです。

debian/
    dists/
        buster/ : Debian 10.0
            edge/ : なんだろ？
            nightly/ : 1日ごとにビルドされた版
                binary-amd64/ : PC, 64bit用パッケージ情報
                    Packages   : パッケージ一覧
                binary-arm64/ : AArch64用パッケージ情報
                binary-armhf/ : AArch32用パッケージ情報
                Contents-amd64 : PC, 64bit用
                Contents-arm64 : AArch64用
                Contents-armhf : AArch32用
            pool/ : *.debが入っているディレクトリ
                edge/ : stableと同じ構成
                nightly/ : stableと同じ構成
                stable/
                    amd64/ : PC, 64bit用 *.deb
                    arm64/ : AArch64用 *.deb
                    armhf/ : AArch32用 *.deb
                test/ : stableと同じ構成
            stable/ : 安定版
            test/ : テスト版
            InRelease   : GnuPGの署名が追記されたReleaseファイル
            Release     : Contents, PackagesのSHAハッシュ一覧が書かれたファイル
            Release.gpg : GnuPGの署名だけ書かれたファイル

Debian向けとUbuntu向けはほぼ同じ構成です。

ヘッドフォンの謎のノイズ

オーディオは専門ではないし、神の耳も持っていないので、細かい音質うんぬんは全くわからないし、高級○○ケーブルなどはオカルトの一種とすら思っていますが……。

音質で唯一体験したことを思い出したので、メモしておきます。

以前はテレビのファーム開発をしていたため、職場ではテストのために少し良い（1万円〜2万円レベルの）ヘッドホン（SHURE SRH440-A）を使っていました。

何も鳴らしていないのに、ヘッドホンからたまにブーン……という微かなノイズと、バリ、バリ！という大きめのノイズが聞こえていました。

スマホとヘッドフォン

最初、評価ボードか機材の故障を疑っていたのですが、なんと原因は自分のスマホでした。

前者のブーン……ノイズは、ヘッドホンのケーブルをくるくると丸めて束ねた上に、スマホを置いていたため、スマホの電波を拾ってノイズになっていたようです。

たまにしか鳴らないのは、パケット通信のときしか強く電波を発しないからですかね？スマホを机の上に置かないようにしたらノイズは聞こえなくなりました。

家の安いヘッドホンで同じことをしても、ノイズは聞こえなかったので、感度の良いヘッドホンじゃないと拾わない（？）のかもしれません。

後者のバリバリ！ノイズは、ヘッドホンアンプの上にスマホを置きっぱにしたときに鳴っていました。ノイズを増幅するのか、かなり目立つバリバリ音が聞こえていました。

これもスマホとアンプを遠ざけて置くことで、ノイズが消えました。

謎が解ければ何てこと無い原因でしたけど、最初はわからなくて、このヘッドフォン壊れているんだろうか？不良品かしら……？とか思っていました。冤罪でした、ごめんねヘッドホンさん。

タチの悪い内蔵音源

音質でもう一つ思い出したのが、先代ノートPC（ThinkPad Edge E420）のアナログオーディオ出力は、常にシューシューというノイズが聞こえていたことです。

2010年は遥かに過ぎて、こんなにノイズが鳴るオーディオがあるはずない、聞き間違いだろうと思いきや、安物のオシロで見てもすぐわかるくらいノイズが載っていてショックでした。Conexantさん勘弁してよ……と思いました。

測定結果は、以前の日記に書いています（2014年10月18日の日記参照）。あれからもう五年も経ったのか。早いものだ。

メモ: 技術系？の話はFacebookから転記しておくことにした。リンクなどを追記。

RISC-V原典

RISC-V原典という本も買って読んでいます。どちらかというと頭から読む本ではなく、辞書的な本です。命令一覧の章はとても便利ですね。

RISC-V原典では「過去のアーキテクチャが患ったインクリメンタリズム」と他のアーキテクチャの複雑さを評していましたが、RISC-Vは出来たばかりなので「今」シンプルなのは当然だよね……などと思ったりしました。

RISC-Vと昔のARM

RISC-Vは命令セットの独自拡張を許しているため、同じRISC-V CPUを名乗っていても「A社CPUとB社CPUでは、同じバイナリが実行できない」ことがありえます。

ARMやx86も互換性のないCPUは存在しますが、共通の命令セットが大きいためあまり問題にはなりません。一方RISC-Vは共通命令セットが小さい（RV32I、MMUなしのマイコンレベル）ので、非互換性で問題が起きそうですね。ARMでいうとCortex-A系とCortex-M系を混ぜて売るようなもので、混乱を招きそうです……。

このタイプの命令拡張方式で私が思い出したのはARMです。ARMも昔はARMv5TEJのように、対応する拡張命令をアルファベットで追記する、似たような方式を採用していましたが、ARMv6で拡張命令に全て対応したため、拡張命令方式は消滅しました。

未来予想

私の予想としては、スマートフォン、デジタル家電、PCのような、比較的高性能な分野にはRV64GC（G = IMAFD、multiple, atomic, float, double）が共通命令セットになり、マイコン系にはRV32IかIMくらいが共通命令セットになる、辺りが落としどころかなと思います。

RISC-Vも「インクリメンタリズム」に陥る未来は避けられず、拡張に次ぐ拡張でゴチャゴチャになる未来を迎えると思いますが、20年後、

• RISC-Vがそもそも使われているか
• RISC-Vは今と同じことを言えるくらいシンプルを維持できるか
• RISC-Vが別のアーキから同じ欠点を指摘されていないか（歴史は繰り返す…）

期待が大きいだけに、将来的にどうなるか、楽しみです。