nspawn and rocket.

nspawn and rocket.

[Rob Landley]

I'm poking at adding the third layer of container support to toybox, by
which I mean I have unshare and nsenter, but need something to act as
the init process in the container to do the early I/O setup (filesystem
mounts, device import/export, network device setup, etc) that requires
interacting with the host.

At the plumber's container BOF I got pointed at systemd-nspawn, which is
apparently what Rocket is built on top of? As in rocket provides a bunch
of host-side plumbing, but the non-distro code that runs inside the
container for early bringup is essentially nspawn?

The nspawn webpage says that it's "just for testing" and that there's a
lot of other stuff you have to do to make it actually secure. Has
anybody documented what that stuff _is_? (Presumably rocket is layering
that on top of nspawn, and I want to implement something that rocket can
use but otherwise stays out of its way. I'd _really_ like it if I can
avoid having parse json.)

Does it sound like I'm on the right track here? Or should I just fluff
out nsenter a bit, implement tunctl, and not worry about nspawn?

Rob

Re: nspawn and rocket.

[Serge Hallyn]

For what you want you could do worse than to base a simple program
based on https://github.com/xemul/libct .  It has helpers for some
of the things you want to do (network device and mounts setup).

Quoting Rob Landley (rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org):
> I'm poking at adding the third layer of container support to toybox, by
> which I mean I have unshare and nsenter, but need something to act as
> the init process in the container to do the early I/O setup (filesystem
> mounts, device import/export, network device setup, etc) that requires
> interacting with the host.
> 
> At the plumber's container BOF I got pointed at systemd-nspawn, which is
> apparently what Rocket is built on top of? As in rocket provides a bunch
> of host-side plumbing, but the non-distro code that runs inside the
> container for early bringup is essentially nspawn?
> 
> The nspawn webpage says that it's "just for testing" and that there's a
> lot of other stuff you have to do to make it actually secure. Has
> anybody documented what that stuff _is_? (Presumably rocket is layering
> that on top of nspawn, and I want to implement something that rocket can
> use but otherwise stays out of its way. I'd _really_ like it if I can
> avoid having parse json.)
> 
> Does it sound like I'm on the right track here? Or should I just fluff
> out nsenter a bit, implement tunctl, and not worry about nspawn?
> 
> Rob
> _______________________________________________
> Containers mailing list
> Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: nspawn and rocket.

[Rob Landley]

Yeah, but toybox (like busybox) tries to keep its external dependencies
to a minimum.

If the only way to have container support was to link to an external
library, that would put container support out of scope for toybox. (I
note that https support was out of scope until we found the command line
"openssl s_client -quiet connect" stuff, despite http without it being
essentially deprecated.)

That said, I've cloned the repo and am reading the Documentation file. :)

Thanks,

Rob

On 09/14/2015 12:11 PM, Serge Hallyn wrote:
> For what you want you could do worse than to base a simple program
> based on https://github.com/xemul/libct .  It has helpers for some
> of the things you want to do (network device and mounts setup).
> 
> Quoting Rob Landley (rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org):
>> I'm poking at adding the third layer of container support to toybox, by
>> which I mean I have unshare and nsenter, but need something to act as
>> the init process in the container to do the early I/O setup (filesystem
>> mounts, device import/export, network device setup, etc) that requires
>> interacting with the host.
>>
>> At the plumber's container BOF I got pointed at systemd-nspawn, which is
>> apparently what Rocket is built on top of? As in rocket provides a bunch
>> of host-side plumbing, but the non-distro code that runs inside the
>> container for early bringup is essentially nspawn?
>>
>> The nspawn webpage says that it's "just for testing" and that there's a
>> lot of other stuff you have to do to make it actually secure. Has
>> anybody documented what that stuff _is_? (Presumably rocket is layering
>> that on top of nspawn, and I want to implement something that rocket can
>> use but otherwise stays out of its way. I'd _really_ like it if I can
>> avoid having parse json.)
>>
>> Does it sound like I'm on the right track here? Or should I just fluff
>> out nsenter a bit, implement tunctl, and not worry about nspawn?
>>
>> Rob
>> _______________________________________________
>> Containers mailing list
>> Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
>> https://lists.linuxfoundation.org/mailman/listinfo/containers
>