去年のBoFでプランB(identで差分をとる)案が出たのですが、プランC(mtreeで差分をとる)案になりました。

背景

  • 粒度については、細かい方が（特にセキュリティ上）のぞましいだろう
  • Debian小史いわく .. 構成要素そのものが改善されたときにアップデートできることを保証する
  • NetBSD、たしかに今でも手動で大味なアップデートはできるけれど、
    • 細かい制御がきかないのは欠点
    • なにより、現状、何がいつアップデートされたのか、更新したからするべきなのか、細かい追跡が人的作業
    • もともとはfdgw3計画の背景としてNetBSDをモジュラーにするという話があったのですが、そっちは、もうやってないですけど、コンテナのために小さい環境をつくるというのが時代の最先端なので、一周まわって時代がおいついてきた？ e.g. マイクロサービスとかっすね〜
    • 問題は、NetBSDでコンテナ？そっちやな〜

ベースパッケージ(basepkg)配布サービス

  • 拘束条件

    • 金ならないので、しょぼいマシンでもOK
    • でも autobuild に daily で追いついていけないといけない

  • Plan A v0.1.0

    • 自分でソースからビルドする or nycdnからダウンロードして切る
    • とにかく作る
    • アップデートの方法は？security advisoryやらなにやらをみて設定ファイルを手動で作成する必要がある
    • これは人手とマシンパワーがかかりすぎるので、いまいちというか、ダメ

  • Plan B v0.2.0 - v0.5.0

    • nycdnからダウンロードして切る
    • ident情報をたよりに差分を判定する
    • ident情報からバージョンを追跡しているので、特定のベースパッケージのソースコード差分情報も表示できて◎
    • CSRG由来のソースコード以外にはidentで見られない。X11はもちろん、opensslやpostfixなど重要な部分でダメ。 (そもそもNetBSDのソースコードにもないのもあるのでつけたほうが…)
    • リファレンス実装のクライアントにはモードが二つある、自分でも間違える、ダメこれ ;-)

  • Plan C v0.6.0予定(まだ master branch にはマージされていない。github の feature/mtree-based branch)

    • nycdnからダウンロードして切る
    • tarball (e.g. base.tgz etc.tgz)内の/etc/mtreeに SHA256 でそのtaball内の情報があるので、そこを見て差分をとる
    • ident差分と異なり特定のベースパッケージのソースコード差分情報を確実に表示できるか？というと、、、ちょっと残念
    • リファレンス実装のクライアントの挙動を変更 (v0.5.9)
      1. リリースからの差分を、すべて作成
        • sysinstでインストールすると
        • これの切り替えにより、すべてリビルドしなおす、ある日付の時点でリビルド、8.0リリースもリビルド
      2. sysinstをなおして現在の情報を 　 1. 当面トラフィックに無駄が多いが将来インストーラをなおす方向で
    • メタデータが修正されると 8.0 release まで遡って再生成
      • ビルドシステムの実装
      • リリースエンジニアリング
      • 使うbasepkgのバージョン管理
      • メタデータが修正されると 8.0 release まで遡って再生成

議論、課題

  • バージョニングは日付しかないとおもう
  • 粒度の妥当性検証は将来の課題(現状メタデータは信じる、正義）
  • Stableは、まぁいいとしても(うそ?)、一般には/etc/マージ問題という大物
    • etcupdate は新旧の /etc/mtree/sets.etc を比較して、なんかかんかするスクリプトなので、 etc--.tgz を作成するさいに etc/mtree/sets.etc に、そのパッケージの中身だけ入って入れ歯OKかな？
    • 注意点: ただし、そのsets.etcを/etc/mtree/に上書きしちゃダメなので、差分だけ上書き(マージ)しないといけないね