From: Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org>
To: Serge Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>
Cc: Containers
<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
Subject: Re: nspawn and rocket.
Date: Mon, 14 Sep 2015 22:35:38 -0500 [thread overview]
Message-ID: <55F7920A.9080009@landley.net> (raw)
In-Reply-To: <20150914171143.GU16923@ubuntumail>
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
>
prev parent reply other threads:[~2015-09-15 3:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-07 19:21 nspawn and rocket Rob Landley
[not found] ` <55EDE3C8.2030704-VoJi6FS/r0vR7s880joybQ@public.gmane.org>
2015-09-14 17:11 ` Serge Hallyn
2015-09-15 3:35 ` Rob Landley [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55F7920A.9080009@landley.net \
--to=rob-voji6fs/r0vr7s880joybq@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox