Open kevin-hanselman opened 11 months ago
@kevin-hanselman Thanks for opening this issue. We'll discuss and decide if we will prioritize this issue.
In the past I've worked around such limitations by creating my own image and modifying the needed file permissions, but that's not very convenient.
I think the current assumption is that /usr/local/bin
will be on the $PATH
for the majority of containers, so changing this location may lead to issues. It'll take some extensive testing to see how heavily things depend on that assumption.
Hope to have an answer on whether we'll work on this soon.
@kevin-hanselman Could you provide more details on the DevSpace features you're using with these Jupyter images? I'm wondering if disabling the features that need SSH and the devspacehelper
would be a sensible workaround.
@kevin-hanselman Could you provide more details on the DevSpace features you're using with these Jupyter images? I'm wondering if disabling the features that need SSH and the
devspacehelper
would be a sensible workaround.
@lizardruss Unfortunately my main interest in DevSpace is to use the SSH and command proxy features.
Is your feature request related to a problem?
Due to a combination of container user and filesystem permissions,
/usr/local/bin
and/or/tmp
may not be writable, and the devspace SSH key may not be readable by the container user.For example, take any image from the Jupyter Docker Stacks project: It expects to own both
/usr/local/bin
and/tmp
. The images support running as bothroot
and a non-privileged user, but both cases don't work with devspace:/usr/local/bin
because it is owned by root. This isn't limited to just the Jupyter images. For example, the base Ubuntu image restricts access to/usr/local/bin
as well./usr/local/bin
, but the SSH key it creates for the proxy commands cannot be opened by the non-privileged user that runs the Jupyter UI (where a developer could work).One could argue two things:
But I think adding the ability to configuring these locations is a sensible solution that doesn't harm the default UX of devspace.
Which solution do you suggest?
Add one or more configuration options to control where the proxy commands and SSH key get installed. For example, one could configure devspace to use
~/.local/bin
for proxy commands and~/.cache
for the SSH key.Which alternative solutions exist?
Add a configuration option to set the permissions and owner of the files devspace wants to create. At face value, this seems a bit more brute force than configuring the locations of the files, but maybe I'm missing something.