Cloudron Forum

@esawtooth, @murgero, @atrilahiji ...

As @robi mentioned, this is one of the features at the top of our to-do-list, so please stay tuned.

Now, most of the functionality required to make this setup work should be already there. Actually, i did a prototype of this a few months ago and don't remember seeing any blockers. I installed Guacamole on the host (through their containerized approach), and then installed xfce4 and tightvncserver within a sysbox container. That's pretty much it. Users would then interact with the Guacamole server (web-based), and reach their sysbox-based environments through the Guacamole interface.

The work that is pending is mainly on the hw-acceleration area, so that we allow GUI apps seating in nested containers (levels > 1), to talk to the hosts' GPUs; apps running at the sysbox container level (level == 1) should be already able to talk to the GPUs.

Please ping me if any of you is interested in trying / documenting this setup, i'd be happy to help.

@girish, right, this 'hitless' scenario is supported by the installer as long as the expected attributes (e.g. bip, address-pools) are already configured in the docker config file. If they are not present and digested by dockerd, then the installer will restart docker.

I understand that you may need more flexibility for Cloudron's specific setup. Can we talk to have these installation details fully understood? (rmolina@nestybox.com).

@girish said in Sysbox integration in progress..:

And is a new release planned soon with the readonly fixes? Would be great if we can also download binaries instead of deb packages.

Forgot to answer this one. Yes, we are about to start working on the next release (ETA ~ 2 weeks). Not sure about the binaries though, will get back to you later on this.

@girish @mehdi, you can definitely run Sysbox side-by-side along other runtimes such as runc.

Sysbox will exclusively interact with its own containers. You just need to program your orchestrator to make use of Sysbox for those containers for which you want enhanced security or extra functionality.

Ping me if any question.

https://github.com/nestybox/sysbox#using-sysbox

---
Note that if you omit the --runtime option, Docker will use its default runc runtime to launch regular containers (rather than system containers). It's perfectly fine to run system containers launched with Docker + Sysbox alongside regular Docker containers; they won't conflict and can co-exist side-by-side.
---

@girish That's right. Sysbox can cohabit with other runtimes; you just rely on the "--runtime" flag to pick one or the other. And right, you won't need a docker-proxy with Sysbox runtime, which will also save you a few headaches due to the fact that the code/dockerfile that you are trying to build is typically in a different context than the docker instance building the image.

Btw, I fully agree with your approach: no user-facing app should have root-level access to the host.

@robi just helped me realize that /run is already bind-mounted as RW, i had missed that. There may be other paths for which RW access is expected though, but i guess that's something that can be evaluated on a per-app basis.

@girish Question ...

Have you guys considered the option of removing RO requirement for specific applications? I'm talking about system apps such as docker, systemd, k8s, podman, ci/cd tools, legacy-apps, etc. All that (and more) can be potentially offered to Cloudron users. But as you know, this software needs RW access to diverse sections of the rootfs (such as /run) to create pipes/sockets/dirs, etc.

The system container running these special apps is fairly secure by virtue of running within dedicated user-namespaces. Also, it's self-contained, in the sense that when you do a docker-commit you are not only capturing the outer sys-container image, but also the inner docker images; that's to say that you can customize these system-apps to your liking, and reduce instantiation latency to the minimum (no i/o needed to fetch inner images).

Please let me know when have a chance.

Thanks.

@atrilahiji you may find this one interesting for your use-case. Let me know if any question.

@robi thanks for your kind words and for your time answering all my Cloudron questions.

The fix for this issue is in code-review at the moment, should be merged soon.