Any chance of LXD support?

[EzequielBruni]

I for one am okay with Podman, I suppose, but do not have much love for docker. None of this is an impediment to me using this app because frankly it looks amazing and will help me greatly, but I wonder if it might be possible to use LXD privileged containers in the future.

Any thoughts?

[89luca89]

Hi @EzequielBruni technically nothing against any other container manager solutions, more diversity in this aspect is a good thing

But for simplicity thing, it would be preferred to have command-compatibility with podman/docker. Right now there are only 2 (or 3? :shrug: ) flags in distrobox that are specific to a container manager (podman, which are additional flags) so it is easy to support multiple container managers just changing a variable. Same thing with #23 for Nerdctl, it is kept in consideration because it has this type of compatibility.

Also a big plus (of podman in this case) is that by default we can run in rootless mode, so better security and less headaches in general

[EzequielBruni]

Fair enough. So far as I know, no one has created a command compatibility layer or CLI to translate docker commands to LXD commands.

Though I just figured out that what we'd actually want is "unprivileged" containers. Sorry, still kinda new to the whole sysadmin thing. Unprivileged is the default, actually.

Honestly... if I knew how to "export" apps from LXD containers to the host, I could probably make a terrible, hacky script that approximates what this project does. Maybe I'll look into it one day. Get my if/else on.

[89luca89]

Give it a shot why not :smile: Probably if you manage to share $HOME between host and lxc, you can just readapt distrobox-export

[EzequielBruni]

That... honestly might not be so hard.

[89luca89]

Go for it :smile:

[EzequielBruni]

Ugh, I've already identified the steps needed... and privileged containers might actually be necessary.

1. LXD would need to be pre-installed for convenience, with a more or less default configuration.
   • ie. I have no idea how to automate that process on non-Ubuntu OSes. You actually need to reboot somewhere along the way. Complicates things.
2. The container creation script would need to automatically apply an LXD profile that does the following:
   • Mount the home folder.
   • Mount the root FS? Did I get that right from looking at your scripts?
   • Enable X, Wayland, and probably XWayland as "Unix devices"
   • Enable Nvidia and AMD passthrough (thank God other people figured that out already).
   • Mount a folder with the "lxdistrobox-export" (sorry) script, and symlink/move that ish to /usr/bin.
   • Probably some other stuff I forgot.
3. The "lxdistrobox-export" script could be a drastically simplified viersion (I think) that mostly just makes the .desktop file.

Or... I could be entirely wrong. I'm going to ask some smarter people. Thanks for the idea. Now to see if I can ever make it work.

[89luca89]

So let's take it step by step:

0 - your UID inside the container should be the same UID you have on the host (example 1000) 1 - mount the home folder 2 - share the same network 3 - share the environment from host to container (I use a little for loop to create a lot of --env flags for podman, don't know how it is on lxc) 4 - pass the export script to the guest 5 - the export script works with ~/.local/share/{applications,icons} to export the app with its icon, it uses ~/.config/systemd/user to export systemd services, and you can specify a path of your liking when you export binaries

In case of app and services it simply prepends the Exec command with distrobox enter .... while the bin exporting creates just a little wrapper for that So you probably will need to use something like lxc run something something :shrug:

If you have other questions you can hit me up via mail :+1:

[EzequielBruni]

lxc exec is pretty much the same as it is for other container solutions.

All the folder mounting, network sharing, and evironment sharing can be handled by the "profile" on container creation. The same profile could literally be applied to every container on creation, no need for an --env loop. The devil is in all the details that I don't know. But I think this is possible. Thanks for the advice.

[89luca89]

Cool, feel free to ask if you need :+1:

[almereyda]

Can we reopen this, to indicate that it is still up for grabs, and also even specified for the largest parts?