Vscode-remote-release: Choose different remote installation directory for SSH

Created on 28 May 2019  路  32Comments  路  Source: microsoft/vscode-remote-release

By default, VSCode Remote SSH "mounts" itself at ~/.vscode-remote. I have two different servers that share the same home directory that's network shared, so I can't connect to both instances at once without some weird things happening (e.g. if I edit a file in one instance, the other instance disconnects - I imagine they're overwriting each other and clashing somehow).

It would be great if it was possible to specify in some config file where we want VSCode to install itself on the remote machine.

Version of VSCode: 1.35.0
Remote connection type: SSH
OS: Win10
Remote OS: Ubuntu 14.04 on both servers
Extensions: just the Python one, but I imagine this is irrelevant
Reproducible steps:
1) get two different servers that share the same home directory
2) try to connect to both at the same time
3) do various things (R/W operations) on one machine and the other machine's connection will be interrupted/closed
Expectation: be able to work on two machines at once that share the same home directory by being able to change where VSCode Remote installs

Thanks!

feature-request plan-review ssh

Most helpful comment

Is this request being worked on?

All 32 comments

i'm also with a shared home directory and it has a very limited quota. i'd rather not keep binaries on it. i need to have per-host configuration of where .vscode-remote is placed, or even better if the location is controlled by some environment variable from the remote system.

I am running into exactly the same problem. I connect to a bunch of remote servers that share the same home directory (nfs). The problem is not just that the sessions can't exist simultaneously, it's worse- only the session from the last connected server will work. Trying to connect to a server/session that was used earlier fails. Only solution at that point is to delete the .code-server directory.

Same issue here when running on a managed VPS from someone like cloud ways - You can't create new folders in the home directory.

Seems logical that you should be able to specify a different location for the folder to live.

I also have the same problem... Is there any solution for that?

I guess no solutions yet? I was trying to find the source code of the extension itself. Is it publicly available? I mean, this sounds like a pretty easy thing to customize the server directory for different hosts.

I'd need this too. Remote server does not grant wrtite permissions to home directory itself, only subdirectories :(

Another use case - many ec2 instances where the only configured user is ec2-user.

One possible solution here is to look at the SSH_CLIENT env variable:
SSH_CLIENT=10.1.17.246 34712 22

This is unique for each login source, so everyone that may be using one of these systems uses a unique and consistent SSH_CLIENT variable.

If one could specify a script to run on the target to generate the .vscode-server dir name to use.

eg:
$> ~/bin/gen-vscode-server-dir.sh
~/ec2-user/.10.1.17.246.vscode-server <- returns dir name to use

This should work for all of the above use cases.

Perhaps another option is to have a fallback/flexibility is for a local script to run first with the hostname as a parameter. This way, if the remote script doesn't, the local script could upload it, then retry the process.

eg: run locally:
~/bin/upload-gen-vscode-server-dir.sh <- uploads gen-vscode-server-dir.sh to ~/bin

run remote:
$> ~/bin/gen-vscode-server-dir.sh
~/ec2-user/.10.1.17.246.vscode-server <- returns dir name to use

I managed to workaround this issue for the scenario with several machine with the same network home by creating symlink to the local dir:

cd /users/my_user
mkdir .vscode-server
ln -s /users/my_user/.vscode-server ~/.vscode-server

You need to create /users/my_user/.vscode-server on every machine that you are going to use, of course.

not completely on-topic, but i noticed that the cpptools extension also stores a lot of data in home, under ~/.cache/vscode-cpptools .

not completely on-topic, but i noticed that the cpptools extension also stores a lot of data in home, under ~/.cache/vscode-cpptools .

There is a settings options for that called C_Cpp.intelliSenseCachePath which lets you choose a custom path for the precompiled headers that it is storing in the .cache folder

I am noticing that this issue seems to have stalled as it has been open for nearly a year. Is it still being considered for development? Setting an initial directory upon connect is usually a simple process. Since this is SO important for the vast majority of us, I am concerned it is not being triaged properly.

We have an additional rub from this issue in that we have home directories mapped to multiple systems with different architectures (x86, arm, and powerpc). Unfortunately, you can't have multiple installs of the server, and so when connecting to the ARM after installing on x86, you get an error due to the invalid binary format.

@dbabokin I was just wondering if symlink is the right solution for this. My home directory is on NFS and quite slow, really. Will there be noticeable speed differences if I move my ~/.vscode-server directory to an SSD and symlink it?

@dufferzafar First use of the machine and installing new extensions is slow, but other than that it works pretty well for me. But it's just a workaround for the problem.

@dbabokin Why is first use and extension install slow? That seems counter intuitive. If we're moving things off NFS and onto SSD then shouldn't it be faster?

But I do agree that this is just a workaround. It'd be great to have this supported by the extension itself.

@dufferzafar good point, I haven't compared it with NFS location, just noticed that it's slow. Probably it's just due to download speed. Hosting the folder on NFS location is not an options for me at all - due to size limits for the home folder.

My HACK:


First I need the server know the SSH session is from VSCode, I don't have a "good" way.

  1. ## Change VSCode settings
{ "remote.SSH.configFile": "C:/Users/GongT/.ssh/config-vscode" }
  1. ## Create file C:/Users/GongT/.ssh/config-vscode
SendEnv USERNAME
Include ~/.ssh/config
  1. ## Add server sshd config: (/etc/ssh/sshd_config)
AcceptEnv USERNAME
  1. Restart sshd service


Then I need a monkey patch.
Place this file at /dev/profile.d/vscode.sh

case "$0" in
*bash*)
    ;;
*)
    return # not BASH
esac

case "$-" in
*i*)
    return # is interactive
esac

if [[ "$USERNAME" ]]; then
    echo "Detected VSCode session; USERNAME=$USERNAME; SSH process PID is $$" >&2
    unset USERNAME

    if [[ "$PROXY" ]]; then
        export http_proxy="$PROXY" https_proxy="$PROXY"
        echo "Using proxy for download VSCode server: $PROXY" >&2
    fi

    declare -xr VSCODE_SERVER_HACK_ROOT=/data/AppData/VSCodeRemote

    function ns_exec() {
        set -x
        unshare --pid --fork --kill-child --mount-proc --propagation=unchanged "$@"
    }

    function bash() {
        sed "s|export VSCODE_AGENT_FOLDER=|export VSCODE_AGENT_FOLDER=$VSCODE_SERVER_HACK_ROOT # |g" \
            | ns_exec /usr/bin/bash "$@"
    }
fi


馃挦馃挦馃挦

  1. Move .vscode-server(-insiders) away
  2. Download server release with proxy
  3. Move VSCode server in new PID namespace

Is this request being worked on?

I too would like to see this feature in VS code. Is there any update?

When will this be completed? Our home directories are stored remotely and as such this is adding latency. Do I need to symlink them?

I also need this. I having the same issue since VSCode Remote was released. Multiple servers with a shared home. I had to create multiple local users like: username-vscode, but it is by far not the best solution.

Another vote for this -- ideally it could read an environment variable upon installation and install it wherever it is pointed.

+1 for this feature request.

I would like to point out that in some environments you have no say in how the remote system is setup. You don't get a personal user account on the remote host but are forced to share a "group account" with multiple people. Being able to specify the directory on the remote would allow using the extension without messing up other peoples environment.

+1 for my managed where i have no permissions on the root

+1. No permission on root and this extension is not usable.

This is a really helpful feature. In my case, I need to share home dir but I don't want others to share my extensions.

+1 for the feature is needed. Limited quota on disk and the storage is shared across the cluster. Currently doing the hack of symlinks on every machine (+50). Would be much better if the location of vscode-server is configurable.

+1 for this feature request. Would be much better if the location of vscode-server is configurable.

Unusable on cloudways for this reason.

+1 for this feature request. All my remote machines shares the same shared home directory and sometime it fails connecting to one of the remote server

+1 for this feature request.

Was this page helpful?
0 / 5 - 0 ratings