I don’t know much about this history. Can you explain or give examples so I can have better understanding? Thanks.
I have in my mind various statements about iX regarding their preference for community support of (iirc) plugins in the old forum.
I’m sharing my research on an alternative approach to potentially integrate systemd-nspawn
in SCALE. Why? By developing jailmaker
I’ve learned a lot about systemd-nspawn
. And although I’ll go on a summer break and stop maintaining jailmaker
in October, I don’t want the ideas I currently still have go to waste. I wish SCALE will eventually have a fully fledged Sandboxes solution with web interface integration. Hopefully jailmaker
and my research will help make this happen.
To piggy back here.
Regardless of the end-solution that’s chosen for the BACK-END, it’s worth stating out-loud that Jail-Maker can currently, today, use many LXC compatible containers. To quote from @Jip-Hop 's github:
Incompatible Distros
The rootfs image jlmkr.py
downloads comes from the Linux Containers Image server. These images are made for LXC. We can use them with systemd-nspawn too, although not all of them work properly. For example, the alpine
image doesn’t work well. If you stick with common systemd based distros (Debian, Ubuntu, Arch Linux…) you should be fine.
From an end-user perpective, systemd-nspawn
/jailmaker
have an existing userbase thanks to @Jip-Hop and @Stux, so I’d be more inclined to support this proposal than the other. However, I don’t have enough skin in this game to actually vote for either. I’d rather just use VMs or native SCALE Docker.
Thanks for all the input and votes.
Container Support will be tracked here: [NAS-130251] - iXsystems TrueNAS Jira
Which technology to be used will be discussed between developers, either that being LXC/jailmaker/nspawn or something else.