[Lxc-users] [lxc-devel] Working LXC templates?

Tony Su tonysu at su-networking.com
Sun Sep 8 23:08:39 UTC 2013


After putting some thought into this,
IMO LXC badly needs a universal tool with the following features

- A single script should be used to run on <any> HostOS, creating
<any> supported Container OS. Although this would make the script
extremely large, IMO it would actually be easier to maintain in the
long run. Unknown at this point is how long it would take to load, but
once loaded I would expect the script to run very fast.

- Flexible enough to support any packaging system, and perhaps even
non-package systems if someone should present a strong case or is
willing to put in the work

- Use the available HostOS distro packages whenever possible. Do not
require packages from other distros or cross-platform packages. IMO
this means less reliance on supporting non-mainline packages, keeps
package and functionality support simple, understandable and
responsibility clear.

- The script should be clearly modular, with sections clearly marked
for the functionality in that section.

- The script as currently envisioned should be a single file to reduce
missing "script dependencies." Any calls should generally be only to
internal functions or to mainstream packages provided by the distro.
Separate custom scripts should be avoided because otherwise the
dependency script(s) may be hard to locate.

To this end,
I've done the intial baby steps towards architecting a new universal
lxc-create template script that should have all the above features and
likely within a week or so post an early alpha on my github for
anyonne to criticize/contribute/modify.

In the meantime, I would be interested to know if anyone is
successfully doing what the title of this message thread describes...
Creating a Container with a different GuestOS than the HostOS, and if
you could either provide a link or description to where the template
script can be found (plus, as  Nathaniel Copa described anything
special and extraordinary you had to do).

It would be done a lot faster except that this is being done in my spare time.
Now, if someone who deals with LXC a lot wanted to hire me to do this
and maybe more... :)

Tony



On Wed, Sep 4, 2013 at 10:52 AM, Natanael Copa <ncopa at alpinelinux.org> wrote:
> On Wed, 04 Sep 2013 09:40:49 -0400
> "Michael H. Warfield" <mhw at WittsEnd.com> wrote:
>
>> I do think it is an issue with the whole "distribution agnostic
>> template" problem that may require some help from the distros or some
>> innovative ideas of how we can bootstrap distros using distro agnostic
>> tools (like stone knives and bear skins style install of the rootfs
>> using nothing more than tar, gzip, gpg, and curl or wget).
>
> This would be very nice. I have not had success with any templates
> except the debian on Alpine Linux. Debian works because we build a
> debootstrap package. Ubuntu template did not work because it uses
> 'arch' command which we don't have. (ok, should be trivial to implement
> if we want it bad enough - and I haven't tested current git templates)
>
> However, the alpine template in current git should work on any distro.
>
> Here is what we do:
> * download static apk-tools (package manager) and the package with the
>   public keys used for package signature checking.
>
> * unpack the the package manager and public keys package with tar.  The
>   package format is basically .tar.gz with some files in the beginning
>   with metadata, so the .apk files can be extracted with tar -zx.
>
> * verify that the public keys are unmodified against a sha256 sum that
>   is embedded in the template script.
>
> * verify that the static binary is unmodified using the public key and
>   openssl. The apk-tools-static package includes a signature for the
>   static binary.
>
> * use the verified static package manager to install a rootfs. The
>   package manager will use the previously downloaded pub keys.
>
> This should work on any x86/x86_64 distro with tar, gzip, openssl and
> wget.
>
>
> -nc




More information about the lxc-users mailing list