Support Toolbox (a.k.a. Fedora Toolbox) #3345
Comments
|
Since it is a wrapper: Can the podman CLI be used to access it? If so, it should already be possible to connect to it with Remote-Containers. |
Yes, you can access it just like any regular container. I'm not the issue submitter, but I can share some of what I encounter when trying to connect to an existing toolbox. Some basic info for my setup: Logs from attempting to connect to a Fedora 32 toolbox named When I manually go into the toolbox and attempt to run the It is worthy of note that the IP address shown is the address of the host despite running within a container; the user's home directory is mounted in a toolbox and the container appears to be running in host networking mode (?). I'm not 100% sure of what else |
|
@debarshiray, could you give us any useful info about Toolbox here? |
|
Very excited to see the interest in Toolbox here! Toolbox containers are just OCI containers created, managed and run by Podman under the hood. Toolbox is a thin wrapper around Podman to set up the containers in a way that makes it easy to use them as pet development environments without being burdened by the cognitive load of being inside a container. Assuming that you have already created a container (with
I hope that this gives you some idea about what happens underneath the I am happy to answer more specific questions. |
|
I have a PR for toolbox to make it work: containers/toolbox#587. With the patch, on your local machine, you only need an alias in |
|
To clarify, my approach is different to the workaround mentioned in the top. The workaround starts an openssh server inside the toolbox, while my approach doesn't rely on any service running inside the toolbox. |
@chrmarti , can these steps (specially the first one) be performed with current Remote Containers implementation, or there's some lacking piece? |
|
@lbssousa There is |
|
@chrmarti, I was able to attach to my Toolbox container with the following minimal devcontainer.json: {
"name": "Toolbox",
"image": "registry.fedoraproject.org/f33/fedora-toolbox:33",
"initializeCommand": "gdbus call --session --dest org.freedesktop.Flatpak --object-path /org/freedesktop/Flatpak/SessionHelper --method org.freedesktop.Flatpak.SessionHelper.RequestSession"
"overrideCommand": false // I see no difference in setting this option or not
}However, VSCode always connect to that container as root ( @debarshiray, is there something else I need to do? What shoud I do with the output of EDIT: My mistake. With the approach above, I'm not attaching to the same container created by |
Note that this isn't necessary any more for Toolbox containers created with current It's possible to detect whether it's necessary or not by running The overall idea was to somehow keep the time zone configuration of the container synchronized with the host. So far, Toolbox made use of the Most of this is done as part of the |
This could be Podman territory, but we need some more information to be sure. Which is the exact command that's failing? I don't know very well how All Toolbox containers have their entry points set to
Note that the Would it somehow be possible to just use |
|
We are trying to stay out of adaptions specific to one CLI or runtime. Podman-support comes from Podman's CLI being compatible with the Docker CLI, so we didn't have to change much (except for the version check). |
|
@debarshiray , I'll keep investigating the Remote-Containers's approach here. For now, it seems @likan999 's PR approach is the easiest one. |
|
I finally realized that, although Toolbox environment are simple OCI containers instantiated by Podman under the hood, they are not expected to be handled the same way a typical application container is, but, instead, more like a WSL distro. Thus, VSCode's Remote-Containers extension may not be the best way to attach to Toolbox containers - we may need another Remote-Toolbox one, similar to Remote-WSL. I'm not sure, however, if such an extension should be developed by Microsoft itself, or if can be developed by the community, since VSCode's Remote Development infrastructure seems to be closed-source. @chrmarti In the case such an extension to be created, it should be interesting, in Toolbox side, if folder |
Indeed. Toolbox containers are meant to be long-lived so-called pet containers.
You mean some location on the host OS that's outside |
|
Hi! I'm working on Toolbox together with @debarshiray. I just spent a little while debugging this and came up with a few points:
I managed to reproduce this error with the following command: The While playing with it, I discovered that the problem can be solved by passing the |
|
@HarryMichal @chrmarti it seems not to be just a matter of attaching to a running (Toolbox) container. It may be needed to pass additional command-line arguments when attaching to that container. I'm not sure if VSCode's Remote-Containers extension currently supports such a feature (e.g. attach-only devcontainer.json file). |
|
I'm no expert when it comes to the Remote-Containers extensions as I never got it to work on my system. My use process was based on (from my point of view) the expected workflow:
And yes, it seems it is needed to extend the extension code for the options I mentioned to get toolboxes running. That is completely up to the devs if they see fit to add them, unless somebody else comes up with a different solution (plus maybe a different cause of the problem). |
|
I don't see why |
|
@chrmarti is it currently possible to attach to a running container from its container name (not previously built from a Dockerfile or docker-compose.yml) as a non-root user, like we do for application containers setting Remote-Containers' documentation says:
but I'm unable to find this option. Instead, I'm only finding Remote-Containers: Open Attached Container Configuration File... |
|
@chrmarti @Chuxel @egamma Note: Is it possible to reproduce such command-line arguments with Remote-Containers extension when attaching to a running container? @debarshiray
Nevermind, it was just an empty string missing as argument to option |
|
You get The files are in We user |
|
So, in order to Remote-Containers to mimic {
"remoteUser": "${localEnv:USER}",
"workspaceFolder": "${localEnv:HOME}",
"remoteEnv": {
"TOOLBOX_PATH": "/usr/bin/toolbox",
"COLORTERM": "${localEnv:COLORTERM}",
"DBUS_SESSION_BUS_ADDRESS": "${localEnv:DBUS_SESSION_BUS_ADDRESS}",
"DESKTOP_SESSION": "${localEnv:DESKTOP_SESSION}",
"DISPLAY": "${localEnv:DISPLAY}",
"LANG": "${localEnv:LANG}",
"SHELL": "${localEnv:SHELL}",
"SSH_AUTH_SOCK": "${localEnv:SSH_AUTH_SOCK}",
"TERM": "${localEnv:TERM}",
"VTE_VERSION": "${localEnv:VTE_VERSION}",
"XDG_CURRENT_DESKTOP": "${localEnv:XDG_CURRENT_DESKTOP}",
"XDG_DATA_DIRS": "${localEnv:XDG_DATA_DIRS}",
"XDG_MENU_PREFIX": "${localEnv:XDG_MENU_PREFIX}",
"XDG_RUNTIME_DIR": "${localEnv:XDG_RUNTIME_DIR}",
"XDG_SESSION_DESKTOP": "${localEnv:XDG_SESSION_DESKTOP}",
"XDG_SESSION_TYPE": "${localEnv:XDG_SESSION_TYPE}",
},
"execArgs": [
"capsh",
"--caps=",
"--",
"-c 'exec \"$@\"'",
"/bin/sh",
"${localEnv:SHELL}",
"-l"
]
}(UPDATE 2020-11-12: There's no need to set Moreover, it should spawn
When I try to attach to my Toolbox container with such a configuration (setting explicitly my username in The problem here is that Remote-Containers is trying to install Remote VSCode server at |
|
It looks up HOME first on the container's environment variables (using
We don't have |
|
In fact, after running I've verified that I was still unable to pass arguments In short, there seems some missing pieces in Remote-Containers extension to make my life easier when attaching to a Toolbox container:
|
|
You could unset HOME with: in the devcontainer.json. |
|
Unsetting About those One more suggestion to make my life easier is allowing access to command |
|
Did you rebuild the container after changing |
|
No, I didn't rebuilt my container after setting "containerEnv". I tried both empty string and my home folder path, but none of tem has worked. TBH, I'm not worried about this anymore: keeping .vscode-server under /root folder within the container allows me not leaking it to my host system's home folder. |
|
There's one last thing that still makes me unconfortable with this solution: since Toolbox is a very special case of container-based development, in which host system's user home folder is directly bound to the container, Remote-Containers extension ends up overwriting my |
|
There is a Remote-Containers setting to turn this off. |
|
Oh, I've just found it here. Thanks! For anyone interested, I've summarized my configuration to make Remote-Containers work with my Toolbox container here. |
|
It's really amazing that you have managed to get this far! The part about Is Visual Studio Code going by the |
|
@debarshiray Yes, we first look at |
|
Does Remote-Containers extension currently support property If not, could you amend it to issue #4013? |
|
I guess we have now all the needed information for an eventual solution on the Toolbox side (auto-generating the needed configuration for Remote-Containers). I've opened an issue there. If @debarshiray has no other questions, I believe this issue can be closed now. |
|
Sorry for the ping, but I'm seeing a lot of issues here and I'm having trouble making sense of what works and what doesn't. Is there an updated guide/text on what works and how to set that up? |
|
@alvarlagerlof The most up-to-date solution about this issue is a third-party project: https://github.com/owtaylor/toolbox-vscode |
That does not work anymore. Any alternatives? |
|
This might finally get me to switch to |
|
Almost 3 years after this issue was originally created I ran into problems trying to use Toolbox containers and VScode together. https://github.com/owtaylor/toolbox-vscode doesn't seem to be working and other articles on the topic caused other (permission) issues for me. I decided to write an updated script that works well enough for me. |
Since Remote Containers extension actually supports Podman container runtime, I would like to go a step further and support container environments provided by Toolbox (do not confuse with Docker Toolbox).
Toolbox is a wrapper tool for Podman that allows creating and entering mutable containerized environments. I seems something like WSL approach, but for OCI containers via Podman.
There's already a way to connect VSCode to a Toolbox environment via Remote SSH extension, using this workaround, but I want to do the same directly via Remote Containers extension (or maybe a new Remote Toolbox one)
Maybe @debarshiray could provide more info about what's needed to add Toolbox support to VSCode Remote Development extensions.
The text was updated successfully, but these errors were encountered: