-
Notifications
You must be signed in to change notification settings - Fork 292
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable custom shell initialization script on the remote #141
Comments
This might also be useful for ROS development, as running |
Can you explain some more about what you are looking for? Is this about running the rc file for some non-bash shell? If so that should work now. Or running a custom arbitrary script which would not normally be run for an ssh session? |
It would be more the second thing, "running a custom arbitrary script which would not normally be run for an ssh session". In ROS there is this concept of workspace overlay that is used to extend the set of ROS packages available at build time and at runtime. The base workspace corresponds to your ROS installation, usually in But even if you only have a single ROS distribution installed in your workstation, you'll probably have several ROS workspaces. A ROS workspace is a project folder where you develop several ROS packages. There is a standard directory layout in a workspace, where a cd ~/myworkspace
# activate a ROS distro
source /opt/ros/kinetic/setup.bash
# run build commands: this creates the `install` directory
colcon build
# run unit tests
colcon test
# activate local workspace
source install/setup.bash
# launch a program "bar" installed in the package "foo"
roslaunch foo bar When I have used vscode to develop C++ packages in ROS, which are based on CMake, I usually do |
@juanrh describes the situation very well. The key issue is that when running Code in the traditional local mode, you always have the option of launching it from a shell where you've prepared the environment for the various plugins, but this possibility is lost in remote mode. (In my case, the installer won't even run unless I modify my The only workaround that I can think of, modifying my |
Ok, thanks I think I understand. I will have to think about this. One solution could be an extension that runs the script on startup and modifies the extension host environment. |
Would an extension be capable of modifying the environment required to install the extension host in the first place? Does it have to be an extension instead of a step in the launch script for the extension host (assuming that it is a |
An extension can only modify the extension host's environment after it is already running, which may or may not work for whatever CMake Tools is doing. |
If the environment is specified by a shell script, would the extension realistically be able to modify the environment of the running Node process short of coming up with some in-process |
and the extension can read that and write It can even invoke node to JSON.stringify the environment, read that output, parse it, and copy it into the extension hosts' process.env. We do something that like that here: But yeah this would take some extra effort to set up but it might be something that can unblock you. It's hard to think about how this would work as a builtin feature because we avoid features that tell vscode to run an arbitrary script just by opening a folder. Like if this existed, it would be disabled by default and something that you have to clearly opt in to per-workspace. |
Oh and another solution, we should get this to work if you
@Tyriar tldr: |
@roblourens there are issues around this in the vscode repo:
I don't think the remote stuff should differ from local until microsoft/vscode#15452 is actioned. |
Oh ok. 15452 makes sense but then I don't know how it will work for the use case above. Probably the extension just needs to set up its environment for itself. |
I wouldn't mind a solution that required some manual step to have the proper initialization run, because this is already the case when I "source my dev environment" before launching the IDE. However, if it involves modifying the environment after the server has launched, it won't work. For instance, after successfully getting a large corporation to change their SSH security settings to allow VS Code port forwarding (I can tell you the remote extension is making waves here), I'm now stuck because of #103. I need a newer GLIBCXX, but modifying LD_LIBRARY_PATH in my I understand why you want to avoid running any code automatically by simply opening a folder, so this shouldn't simply be a workspace setting. Would it be possible to pass options from the local Code instance to the server? Or, could the SSH session used to launch the server optionally be started in interactive mode attached to a terminal, so I can do whatever setup is needed and then launch the server process by running |
FYI for anyone trying to use the CMake Tools extension within a window spawned from this extension, there's an open feature request to allow CMake Tools to source a setup script before running. |
I made a workaround script. Use at your own risk. |
+1 My use case is to enable conda's (or other package or container management) build environment for a vscode project |
+1 must have feature for ssh-remote to work with ROS Right now default build won't work since for some reason catkin_make showing "no such file or directory" |
+1 also in high energy physics the most common workflow would be to delegate the environment setup to a single bash script, and this issue is a blocker for remote working with vscode |
To be clear, you can still use |
It is also very difficult to use vs code without this feature with clusters, since everything will be running on the login node (see #2808). |
Yes, but as far as I understand code in .bashrc cannot distinguish between normal interactive run and connection via vs code If the remote extension would set some environment variable, that would already help in majority of the use-cases, I believe. E.g., using something similar to |
As a workaround for building I set up my build environment manually in a |
Has there been any work-around for this? I need the VSCode remote extension to run as a different to the user that is logged in. |
In case it helps anyone else,
Find www-data in the list, at the end of the line for www-data you will see something like /var/www:/usr/sbin/nologin which is in the format HOME_DIR:SHELL.
Paste your OpenSSH RSA public on a new line nas save and close.
And for VSCode:
|
Worked for me. Thanks @leon-v |
Anyway to su another user after ssh ? |
Agree. Seems the remote-ssh honors |
I have been re-visiting this issue lately, and i see no progress in getting the server to run as a different user, even with sudo. Ill be following this thread for updates: |
RemoteCommand was enabled with the setting Let me know if it solves what you all are looking for? |
This option sounds great @tanhakabir ! Unfortunately running into errors using it on Windows 10. I followed @rzhao271 's latest comment here #6221 but the connection ends up crashing / I'm unable to connect. Thanks! Here's the crash log. |
@daniel-zeng from your logs I'm seeing just "Permissions denied" error so I'm assuming there's some issue authenticating? https://gist.github.com/daniel-zeng/74f11926653140f20fd48dd5b0cd892c#file-gistfile1-txt-L15 If you're unsure why you're seeing an authentication error or want to discuss more, could you please create another issue and we can debug there? Thanks! |
I used this option successful until today. But now, I have a problem, that my remote Linux system is detected as Windows system and |
After some trouble with # normal login
Host dev-system
Hostname dev-system
User user
IdentityFile ~/.ssh/dev-system
# special login for vsc for the alpaka project
Host vsc-dev-alpaka
Hostname dev-system
User user
IdentityFile ~/.ssh/dev-system
SetEnv MY_CONDA_ENV=alpaka-dev
# special login for vsc for the vikunja project
Host vsc-dev-vikunja
Hostname dev-system
User user
IdentityFile ~/.ssh/dev-system
SetEnv MY_CONDA_ENV=vikunja-dev On the if [ ${MY_CONDA_ENV:+x} ]; then
conda activate ${MY_CONDA_ENV}
fi Caution: The environment variable must be set in the |
Small trick:
And if you don't have permission to change the sshd config, just hack it: use |
@SimeonEhrig but just to clarify your specific use case (conda), is there any reason why the "Environments" feature of the Python extension does not work for your use case ? It would seem simpler than adding an SSH config for each of your projects... |
Yes, I use the conda environment mainly for C++ development. Therefore the cmake-tools extension needs to use the correct environment and I didn't found a working solution for this, except starting vsc in the correct conda environment. |
Have the same need for my work. I need to source a complex script to setup my environment, specific to the project. When using VSCode remote, I don't have any way to source the script. |
I read this blog post in the morning: https://code.visualstudio.com/blogs/2022/07/07/vscode-server |
For those of you using clusters, the ssh proxying solution may help, though it didn't benefit me in my case, since I am not authorized to connect a specific interactive compute node directly (w/o knowing its local password). |
I have this problem as well. When I log into a remote box I often need to run a configuration script to set up the development environment. This involves loading various versions of tools and setting various configuration options. All I need is the ability to run a single arbitrary shell command after the ssh session is connected and operational. The above suggestion to "put it in your |
My use case or need is close to this Issue's topic but I'm unsure. Would be great if anyone can help clarify. Relatively VS Code newbie. Previously used PuTTY for all commands on the remote server ( On the remote (Ubuntu) server, I customized various configuration files to get The separate SFTP-supporting text editor and PuTTY functionality is seemingly all rolled into VS Code (albeit via a local machine installation of OpenSSH?) in one app / window. This is outstandingly helpful and I'm 98% close to the ideal setup. However, when I open a terminal in VS Code, I get a nicely-enough coloured prompt but basically the configuration files I previously used, to get the environment I like via PuTTY, do not run. I can run the configuration files manually via Happy to provide more details of the "configuration files" I refer to, and what they do, if that helps. How can I run remote configuration files automatically every time a VS Code ("Remote - SSH" enabled / connected) Terminal is opened / connected to the remote server? |
I have the same requirement. To setup my project specific environment I need to run something like |
Per workspace should be much more complicated than per instance. VSC has no built-in environment management, which means ether vsc has to see all application/dependencies at start up or an extension can handle changing dependencies at runtime. For example, the C++ extension can easily detect new compiler on runtime, but if you need another version of a library (e.g. boost), you need to change the library paths and restart vsc. By the way. Now I use visual studio code server, which allows me easily to start a vsc instance in a specific instance on the remote system. I have only trouble with the limit of 10 registered instance at the same point. We have 3 workstations, so I have can only us about 3 different environment per system without workaround. |
The system where I would use the Remote SSH feature has a quite "vintage" tool setup by default, which causes installation of the extension to fail. By modifying my
.bashrc
I am able to work around this with generous use ofmodule add
, but now my whole environment is "non-standard", and build tools ding me for this, even if I'm not using Code. I'm sure that at some point I will spend days looking for a bug caused by me swapping out the core GNU tooling for a different version.I suggest adding the possibility to specify a script that is sourced on the remote before executing the installation and launching the extension server. It doesn't have to be a setting, just a script with a known name. This would put the remote tools on equal footing with the IDE itself, where i am able to run
code
inside a custom environment by sourcing a setup script first, without having to "pollute" my.bashrc
.This request might be slightly related to #83.
The text was updated successfully, but these errors were encountered: