nspawn and rocket.
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
A message that is not in the archive (sent off-list or not yet received): 55EDE3C8.2030704-VoJi6FS/[email protected]
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).
Quoted 26 lines · 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
_______________________________________________
Containers mailing list Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
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
Quoted 32 lines · 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).
Quoted 26 lines · 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
_______________________________________________
Containers mailing list Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/containers