Problem/Justification
After losing the TrueCharts catalog users have now lost the maintained of the amazing jailmaker script that allowed them to run docker on Scale before Electric Eel. Unless jails get maintained in the future, users will have to migrate again.
Impact
Among other things, jails allow more control of the docker environment that the built in apps probably will. It allows separation of docker networks for separate app groups and you can run docker rootless for added security.
Users who need those features might be forced to move their apps off Scale if they are no longer supported.
User Story
As a user I would like to create jails on the web UI. It should support the same options as the jailmaker script: selecting a base image, configuring the network, user, etc.
…or it might be upgraded to taking jailmaker itself into iX custody as well.
I do not really expect this to happen, but if so-called “sandboxes” are to stay, as a lighter option than a full-featured VM to deploy self-standing applications (e.g. k3s/k8s), this might be an option.
I’m voting for this, but to be clear the ask from me is “Native systemd-nspawn support”.
So not necessarily the integration of the jailmaker script, just the ability to create and spawn jails via the same systemd-nspawn methods that the jailmaker script uses.
Ideally, there’d be some templates similar to how jailmaker does it for things like docker support but I’ll take what I can get.
I am not surprised at all, as some of you know from comments I made a month ago. But I do agree a UI interface is needed to make things simpler and am voting for it.
You might want to switch your votes to LXC/Incus support in TrueNAS Scale which seems far more interesting IMHO, especially after jailmaker maintainer declaring it EOL.
Two days ago LXC was expressly NOT on the roadmap. Has this changed? Because I do not see the point of voting for a moonshot over further GUI integration of nspawn, which is already there.
What’s the business case for LXC? What are the tangible benefits for users over nspawn? (As opposed to vaguely handwaving LXC as being “more popular”.)
LXC/Incus is not a moonshot. It’s perfectly usable solution. If you want to see benefits, you can read them here: LXC/Incus support in TrueNAS Scale
Also you misunderstood what “not on roadmap” means. It just means it’s not currently planned because focus is elsewhere. It doesnt mean that it will not be ever included if there is demand. That’s why it is in feature requests, to request putting it in roadmap.
Systemd-nspawn is pretty low-level, without many features and you also have to maintain wrapper so it’s actually user friendly.
With Incus you can depend on already user-friendly solution with big user base and active development.
Incus would offer more features and would be easier for iX dev team.
Well, being much more popular carries with it a much greater likelihood that it’ll continue to be maintained, rather than the one guy who maintains it deciding that it’s served its purpose (apparently Jailmaker was all, and only, about Docker, at least as far as its dev was concerned). And while that may not be a tangible benefit for users, it surely is for iX–see what happened with SCALE’s clustering abilities.
For users, what comes to mind is the large library of LXC templates with various software preinstalled–everything from Gitlab to a PBX to PrestaShop. Particularly if they don’t like Docker–and we’ve seen some here[1] with what I’d characterize as a pathological hatred for Docker.
I don’t really have a preference either way, though I’m a little more familiar with LXCs as I use them in Proxmox. But I do want something in SCALE, fully supported, that acts like a jail did in CORE.
The “moonshot” I was referring to was not LXC itself but the idea of having it integrated in SCALE. Lest you forgot, the request is addressed to a company which could not be bothered for years to fix a broken terminal emulator for the web shell in CORE where it had both (1) better code in another part of the CORE GUI to display a list of processes, and (2) better code in the SCALE GUI, and which also make a mountain out the molehill of supporting SMART testing for NVMe drives where it has all the code and GUI hooks for SMART testing of SAS/SATA drives.
SCALE uses a systemd distribution, so systemd-nspawn is already there. LXC is not installed. That’s a 1-0 victory for nspawn right now.
As for the other thread, so far you have not illustrated any tangible benefit for the user.
For instance, how would LXC make sandbox networking safer than it is with nspawn? Or easier to manage?
“More popular” or “more commits” count for zero in my book, sorry.
Wrong target. The jail-like infrastructure is provided by nspawn, jailmaker is a convenient tool to facilitate deployment by nspawn. I assume that systemd and nspawn are being actively maintained. There have been two replies pointing that this feature request is actually about enabling nspan calls from the UI:
which is actually in line with the original description
So not so much about maintaing jailmaker itself than integrating (the equivalent of) jailmaker functionality into the GUI. Regardless whether the middleware would invoke jailmaker (which would then need a new maintainer) under the hood, or would invoke nspawn directly.
Maybe we should edit the title of the thread, and wording of the request, accordingly?
Thanks. This looks like the begining of one possible answer about the user side of things. Now the sub-question: What would the deployment of jails templates look like with LXC/Incus? From CLI, possibly with jailmaker-like scrip to be developped, or from GUI[1].
Amen. We happen to already have something like this, with nspawn being the equivalent of FreeBSD jail(8) and jailmaker being the equivalent of iocage (and with both soon sharing the condition of not being actively developped). What looks lilke the best strategy to retain it? To ask for nspawn to remain and get a GUI? Or to ask for nspawn to be dropped and replaced by LXC?
Because the risk is that iX be happy with providing docker-compose for quick deployment of pre-built images and full-blown VMs with KVM for more demanding applications, but drops the intermediate jail-like equivalent to save on development.
You are afraid that we will end up with nothing, so we should focus on nspawn because thats something at least.
I didnt really focus on this, because I dont think solution is inherently better just because it’s bundled with systemd.
I am not able to answer the question about security. But I think Incus is easier to use and manage than nspawn.
You want to create ubuntu container container named first? incus launch images:ubuntu/20.04 first
Wanna go into this container using bash? incus exec first -- bash
It’s extremely easy and user friendly. To get this level user friendliness with nspawn you need to maintain wrapper like Jailmaker. Otherwise it’s more pain to set up.
Incus basically is like Jailmaker. It’s manager for LXC. But it has a lot more features and is maintained by someone else so iX team doesnt have to do it.
I thought that it would be easier even for iX devs to rely on Incus.
And you say that iX team may just provide Docker and VMs and drop system containers.
This is another benefit of Incus. It is also manager for VMs (through QEMU). So iX can manage both system containers and VMs with single tool.
It can recently even manage Docker containers. So people unhappy with native Docker implementation in Truenas SCALE would have alternative option.
I understand what you are saying. I just think that in long-term Incus would be more user-friendly and less work for iX devs.
PS: I forgot to add, that I know I can be wrong and maybe nspawn really would be better. I hope that if iX really decide to implement system containers they will test both nspawn and LXC/Incus and choose what makes most sense to them.
And if they choose nspawn? I promise I will not look a gift horse in the mouth.
I’d say Jailmaker is in transition to new management; it’s not actually EOL. In fact Jip-Hop had already been laying the groundwork to improve testing and modularity for smooth hand-off to a broader team. All credit to his graceful handling of a difficult announcement.
Personally, I think Jailmaker is on a glide path to becoming that equivalent of FreeBSD jails that many of us are seeking. Maybe not iocage, depending on if declarative templates gets picked back up. (NB: Core’s plugins taught important do’s and don’ts.)
But there’s absolutely the energy to take it beyond hosting a single Docker environment. And to align with iX’s middleware principles, to make it as attractive as possible for potential inclusion.
It sounds as if Incus might already be that large, diverse, and growing declarative library that I’d envisioned in issue #228? Way cool! I should get up to speed on that. But I do see exciting developments on the way for Jailmaker. Especially for those of us invested in FreeBSD jails.
This was meant more for iX devs, sorry for being unclear
If they decide to integrate Jailmaker they will have to maintain it and keep developing it. Adding features and so on.
I just thought it would be easier for them to just use already developed and maintained solution like Incus.
Since iX devs have much work already I tried to think what solution would require less work for them in long term.
PS: Of course Jip-Hop did great work with Jailmaker. I dont want to disregard that.
Yeah, thats true.
You always have to choose. Either you make solution yourself, have full control but also all the work is yours to do. Or you can take third-party solution, there is some risk but you have less work.
With open-source even if third-party stops maintaining the software, you can fork it yourself.
For containers there is no reason for iX to develop the main runtime themselves. So at the very least they will use systemd-nspawn or LXC. So they have to hope this projects will continue. But I think it’s a safe bet they will.
Only thing I would say is that nspawn seems less developed than LXC. I guess that’s because it’s only one part of the behemoth systemd become and devs just cant give it that much attention.
On the other hand LXC only focus is system containers.
So the question is if iX wants to develop it’s own wrapper/manager like Jailmaker or they will rely on third-party Incus.
But this is hard to answer. Does iX have enough manpower to maintain something like Jailmaker? Would they rather use existing solution or do they like more to do things in-house? This is something only iX management can answer.
