(更新: 2014-01-14) メタデータのうち， * fstab は必須でなくなった (あれば上書き) * expiry も必須でなくなった (なければ expire しない) ---- (このページはメモです．そのうち消えるかも?) これを読んだそのまま * http://lists.linuxcontainers.org/pipermail/lxc-devel/2014-January/006992.html Hey everyone, First of all, sorry for coming up with that so late in the 1.0 development cycle. I tried to convince myself for a long time that this wasn't necessary but reality is that with unprivileged containers, we need to start thinking about new ways to let our users create containers. 非特権コンテナでは，コンテナ作成の新しい方法を考える必要がある． So briefly put, the idea is to introduce a new template called simply enough "download" (I'm open to better name suggestions) which instead of doing our usual magic of building a rootfs locally will instead download a pre-built rootfs and some metadata from a central server. このためのアイデアは，簡単な名前である "download" という新しいテンプレートを導入することだ (もっと良い名前があれば募集中)．これは現在の通常のテンプレートで行うローカルで rootfs を構築する代わりに，事前にビルドされた rootfs とメタデータを中央サーバからダウンロードするというものである． My goal is to make the dependencies of that template minimal enough that it should be able to run on every distribution that ships LXC, ideally, including Android. 目標は，LXC を提供する全てのディストリビューションで実行することができるくらい，テンプレートの依存性を十分に小さくするというものである．理想としては Android を含む． Now as for the implementation, the plan is to bring up a new server on the linuxcontainers.org domain which will sit at: https://images.linuxcontainers.org 現時点では実装に関しては，計画は https://images.linuxcontainers.org として linuxcontainer.org ドメインに新サーバを構築することである． The structure of that server will be something like そのサーバの構造は以下のようなものである． ├── images │ ├── debian │ │ └── wheezy │ │ └── armhf │ │ └── default │ │ └── 2014-01-10_19:35 │ │ ├── meta.tar.gz │ │ ├── meta.tar.gz.asc │ │ ├── rootfs.tar.gz │ │ └── rootfs.tar.gz.asc │ └── ubuntu │ └── 14.04 │ └── amd64 │ └── default │ └── 2014-01-10_19:30 │ ├── meta.tar.gz │ ├── meta.tar.gz.asc │ ├── rootfs.tar.gz │ └── rootfs.tar.gz.asc └── meta └── 1.0 ├── index-system ├── index-system.asc ├── index-user └── index-user.asc So the filesystem structure is fairly logical and user friendly. Now as for the details of the various files. ファイルシステム構造は完全にロジカルでユーザフレンドリーである．現時点では，それぞれのファイルに関しては， rootfs.tar.gz is a tarball of only the root filesystem of the container with the tarball starting at what will be the root of the container. rootfs.tar.gz は，コンテナの root ファイルシステムだけの tarball であり，tarball はコンテナの root 以下のもの． meta.tar.gz is a tarball containing a bit of metadata which the template script will need, that includes: - config (mandatory; text file containing a minimal set of config options to include in the container's config) - fstab (mandatory; a standard fstab text file) - expiry (mandatory; text file containing the Unix Epoch of the recommended expiry date for the image) - create-message (mandatory; text file which will be displayed to the user post-create) - *. (optional; any of the above may be overriden by appending . to their name which will be used instead of the original if the compat-level matches that of the currently running LXC). meta.tar.gz はテンプレートスクリプトに必要なメタデータが少し含まれている tarball である．これには以下が含まれる． - config (必須; コンテナの設定ファイルに含める最小セットの設定オプションを含むテキストファイル) - fstab (必須; 標準の fstab テキストファイル) - expiry (必須; イメージの推奨の有効期限である Unix Epoch を含むテキストファイル) - create-message (必須; コンテナ作成後にユーザに表示するテキストファイル) - *. (オプション; 上に挙げたファイルに . を付加し，そのファイルを， 現在実行している LXC のバージョンと がマッチする場合にそのファイルを上書きする) The index-* files are standard CSV files with the following syntax: - ;;;;; index-* ファイルは標準的な CSV ファイルで，以下のようなシンタックスである: - ;;;;; index-system is for system containers, index-user is for unprivileged containers. index-{system|user}. is also supported and overrides the main index if found. index-system はシステムコンテナ (特権で実行するコンテナ) のためのもので，index-user は非特権コンテナのためのものである．index-{system|user}. というファイルもサポートされ，存在する場合はメインの index を上書きする． All of those files are signed by the server's GPG key which will be stored in-line in the script. これらのファイルの全てはサーバの GPG キーで署名され，スクリプト内にインラインで含まれる． The template itself will require the following arguments: - distribution - version - architecture テンプレート自身は以下の変数が必要である: - distribution - version - architecture And the following will be optional: - variant [default: default] - server [default: https://images.linuxcontainers.org] - pubkey [default: inline gpg key] - no-validate [default: off] 以下はオプショナルである: - variant [default: default] - server [default: https://images.linuxcontainers.org] - pubkey [default: inline gpg key] - no-validate [default: off] The goal for the template is to only depend on: - POSIX shell - wget - tar - gzip テンプレートの目標は以下だけに依存するものであることである: - POSIX shell - wget - tar - gzip Which should be satisfiable even by busybox. これは busybox のテンプレートでさえも満たす必要がある． However, the template will require --no-validate if gpg isn't also installed on the system. しかし，gpg がインストールされていないシステムでは，テンプレートに --no-validate が必要である． The initial set of distros to be supported that way will be any distro that can currently be built from an Ubuntu system (as that's what linuxcontainers.org uses) and that uses the new common-config (currently only ubuntu and ubuntu-cloud) setup (as I really don't want massive config files that change all the time to be part of those images). このようにサポートされるディストリビューションの初期セットは現時点で (linuxcontainers.org で使用している) Ubuntu システムからビルドでき，新しい (現時点では ubuntu と ubuntu-cloud だけで) 共通の設定を使用する任意のディストリビューションとなる (四六時中，これらのイメージのために巨大な設定ファイルを変更ばっかりしてるのいやだしねー) The compat-level stuff mentioned above is there to allow us to change the way the server works without breaking backward compatibility. It also allows us to introduce new templates to the system only for releases of LXC which support them. The initial value will be "1" and I'm going to need a very very good reason for bumping it (which is why I want all those distros to use lxc.include for their config). 前述の compat-level は，サーバが後方互換性を損なう事なく動作を変更できるようにするためのものである．また，特定の LXC のリリースのみをサポートする新しいテンプレートをシステムに導入することも可能になる．初期値は "1" になり，これを増やすための非常に非常に良い理由が必要になる予定である (これはなぜ私がこれら全てのディストリビューションで，設定ファイル中で lxc.include を使ってほしい理由である)． With all that said, I'll start working on the implementation of this and hope to have the server working with ubuntu and debian images published over the next few days. If any other distro is interested (I very much hope they all will), start by switching to lxc.include for your config, using something similar to what ubuntu is doing, then get in touch with me. 私はこの実装を開始し，ここ数日のうちに公開する ubuntu と debian イメージで動くサーバを持てればいいなと思う．もし，他のディストリビューションが興味があれば (全てがそうだと期待!!)，ubuntu がしている事と同じようにして，設定を lxc.include にスイッチすることから初めてほしい．そして私に連絡してね． * (参考) http://lists.linuxcontainers.org/pipermail/lxc-devel/2014-January/007007.html ---- Just a quick note for the new template you'd create to unpack this, to hopefully save you a bit of frustration: as with the ubuntu-cloud template, you have to do tar --anchored --exclude="dev/*" --numeric-owner -xpzf "$cache/$filename" and then create bind mount fstab entries for the crucial devices. ---- pre-build にする理由 > > Not an objection but a question to understand more. I'm assuming the > > problem is the tools that used for bootstrapping (like > > debootstrap/febootstrap etc.) requiring some privileges. If that's the > > case, can't we write something (like setting suid bit or giving > > required capabilities via libcap) to make unprivileged user to create > > the container using regular templates? > > The main problem we have at the moment is anything attempting to mknod. > Then we have some templates like fedora which use loop mounts and other > similar restricted kernel features. And to be clear, adding suid bits won't help as the templates run in a user namespace. Mounting block filesystems and creating devices are not allowed there for now, period.