Differences

This shows you the differences between two versions of the page.

--- linux:vscode [2023/10/12 07:49] – jansen
+++ linux:vscode [2025/01/07 08:36] (current) – [Some common pitfalls:] jansen
@@ Line 17: / Line 17: @@
 ===== The ssh plugin =====
-Instructions for installing the vscode ssh plugin can be found [[https://code.visualstudio.com/docs/remote/ssh|here]].
+So, you read the previous part, and decided to go for ssh from within vscode anyway?
+Instructions for installing the vscode ssh plugin can be found [[https://code.visualstudio.com/docs/remote/ssh|here]].
 The page also has information about setting up a local ssh client, if you don't have one yet (Windows; putty is not supported, you need the commandline ssh client here, which is already present on Linux and Mac OS)
-Next, set up [[:ssh|key-based ssh]], so you don't have to type a password a couple of times when you open your remote vscode. Some functionality will not even work with password-based logins anyway. Take care of the secrecy of your **private** key. It's called private for a very obvious and very impoirtant reason. If you loose that key or if others get their hand on it, your account is compromised and you should immediately contact the helpdesk for removing the key and resetting all login related settings.
+Next, set up [[:ssh|key-based ssh]], so you don't have to type a password a couple of times when you open your remote vscode. Some functionality will not even work with password-based logins anyway. Take care of the secrecy of your **private** key. It's called private for a very obvious and very important reason. If you loose that key or if others get their hand on it, your account is compromised and you should immediately contact the helpdesk for removing the key and resetting all login related settings.
+The vscode documentation has some more [[https://code.visualstudio.com/docs/remote/troubleshooting|tips and tricks]] that may come in handy.
 ==== Some common pitfalls: ====
   * Setup ssh to go directly to your target host. Sterrewacht desktops are directly reachable over the internet, no setup needed. But if you want to run on a Sterrewacht compute node, the ALICE cluster or a Institute Lorentz machine, you will need a proxy setup to go through the appropriate gateway. See [[ssh:tipsandtricks|SSH tips and tricks]], especially example 3 at the bottom.
   * In the context of vscode, setting up a Proxy is NOT identical to logging in on the gateway, then loggin in to your target; if you configure vscode to go to the gateway only, vscode's file browser will be running on the gateway, and vscodes internal server code will be running there too. And since most ssh gateways are just gateways, and not powerful compute nodes, this will be very limiting. So do setup that proxy config!!
-  * vscode will automatically install some server code on the target to receive and handle your connections. This is conveniently done without any user interaction, but inconveniently, this code ends up in ''$HOME/.vscode-server'' and space in teh home disk is limited. If this fails, check your quota, move things around, get rid of the incomplete vscode directory and try again.
+  * vscode will automatically install some server code on the target to receive and handle your connections. This is conveniently done without any user interaction, but inconveniently, this code ends up in ''$HOME/.vscode-server'' and space in the home disk is limited. If this fails, check your quota, move things around, get rid of the incomplete vscode directory and try again.
-  * What usually works (NOT FULLY TESTED YET): first log in to your target server, create a directory .vscode-server on a local disk of that system, and make a symbolic link to that location in your home directory, e.g.
+  * What usually works: first log in to your target server, create a directory .vscode-server on a local disk of that system, and make a symbolic link to that location in your home directory, e.g.
   <code>  mkdir /data1/username/.vscode-server
   ln -s /data1/username/.vscode-server $HOME </code>
@@ Line 68: / Line 71: @@
 Con: this requires quite some testing, and the setup will be entirely tailored for one specific purpose. E.g. if you manage to set this up for running AMUSE, and your other project requires running Tensorflow, you're out of luck and may have to turn to one of the other methods.\\
 Also, this method cannot work in combination with a queuing system, as required on clusters.
 ===== Special case: X11 forwarding (graphics) =====
-TO BE DOCUMENTED
+You need to have a local X11 server running. Default in Linux, but for Mac OS and Windows, you may have to install additional components.
+(TO DO: does WSL on Windows provide an X server by default??)
+In your .ssh/config, add for this host, or in general:
+  ForwardX11 yes
+  ForwardX11Trusted yes
 ===== Special case: remote jupyter notebooks =====
-TO BE DOCUMENTED
+VScode has a built-in viewer for jupyter notebooks. In the simplest setup, using the remote explorer to browse to the location of the notebook, and double-clicking it, will run the notebook and display in a vscode window.
+However, the same issues occur that also plague other jobs: you get no easy way to specify the execution environment (eg: loading the AMUSE environment in order to run the notebooks from the AMUSE docs interactive tutorial). And if you load such an environment (the only method that can work here, is by editing .bashrc), you will also need to add a custom python kernel to jupyter before you can get the notebook to do anything useful (refer to the web and other docs on jupyter to figure this out).
+See also: [[https://saturncloud.io/blog/how-to-use-vscode-ssh-remote-to-run-jupyter-notebooks/]]

Computer Documentation Wiki

User Tools

Site Tools

Differences

Page Tools