1 SSH Configuration
- 1.1 Noctua 2
- 1.2 Otus
2 Compute nodes
3 VS Code server location
4 VS Code shell environment
5 Alternatives
- 5.1 Remote tunnels
- 5.2 Code-server

SSH Configuration

Noctua 2

For programs like Visual Studio Code that support remote development via ssh, you need a different ssh-config to deal with the load-balancer. You can add the following blocks to your ssh-config:

Host n2-jumphost
  Hostname fe.noctua2.pc2.uni-paderborn.de
  User [USERNAME]
  IdentityFile [PATH TO PRIVATE KEY]
  IdentitiesOnly yes

Host n2login1
  Hostname n2login1.ab2021.pc2.uni-paderborn.de
  User [USERNAME]
  ProxyJump n2-jumphost
  IdentityFile [PATH TO PRIVATE KEY]
  IdentitiesOnly yes

Host n2login2 
  Hostname n2login2.ab2021.pc2.uni-paderborn.de 
  User [USERNAME]
  ProxyJump n2-jumphost
  IdentityFile [PATH TO PRIVATE KEY]
  IdentitiesOnly yes

This will instruct ssh to use the host n2-jumphost as a proxy when trying to connect to one of the frontends n2login1 or n2login2. We recommend to explicitly choose a frontend in this case because programs like Visual Studio Code run a daemon on the remote host and by explicitly choosing a frontend you avoid issues if you want to use multiple program instances. In programs like Visual Studio Code you can then simply select to ssh configuration n2login1 or n2login2 to connect to. Please don't use this way for interactive sessions. Noctua 2 has up to six login nodes. You might want to configure all of them to choose the login node with the lowest load.

Otus

Using VS Code on otus is quite similar to Noctua 2:

Host otus-jumphost
  Hostname fe.otus.pc2.uni-paderborn.de
  User [USERNAME]
  IdentityFile [PATH TO PRIVATE KEY]
  IdentitiesOnly yes

Host login1
  Hostname login1.ln2025.pc2.uni-paderborn.de
  User [USERNAME]
  ProxyJump otus-jumphost
  IdentityFile [PATH TO PRIVATE KEY]
  IdentitiesOnly yes

Host login2
  Hostname login2.ln2025.pc2.uni-paderborn.de
  User [USERNAME]
  ProxyJump otus-jumphost
  IdentityFile [PATH TO PRIVATE KEY]
  IdentitiesOnly yes

You can configure all 6 login nodes to choose that one, which has the lowest load.

For Windows users:

If you have space characters in your path, put the path in “quotation marks”.
More details about SSH usage on Windows you can find in the following external Windows article: Key-based authentication in OpenSSH for Windows

Compute nodes

We recommend the following two-step process

First, open a terminal, login to the cluster and request an interactive session on one of the compute nodes.
- Remember the name of the compute node that was assigned to you, e.g. n2cn1234.
- Keep the terminal open until you’re done with your work.
Second, use VS Code’s remote extension to connect to the compute node via SSH.
- For this to work, you need to be able to directly ssh n2cn1234 to the compute node. To avoid many entires in your ~/.ssh/config (one for each compute node) you can use the following entries for Noctua 2 based on wildcards (the jump hosts are defined here):
- # Noctua 2 Host n2cn* n2lcn* n2gpu* n2fpga* n2dgx* n2hcn* n2hacc* HostName %h ProxyJump n2login2 User [USERNAME] IdentityFile [PATH TO PRIVATE KEY] IdentitiesOnly yes

VS Code server location

By default, VS Code will install its server instance under in home directory, that is, into ~/.vscode-server. We recommend to redirect this installation to your scratch space instead. This can be achieved with the following steps:

Create an empty folder, say, /scratch/hpc-prf-mypr/username/.vscode-server.
Create a symbolic link .vscode-server in your home directory that points to this empty folder: ln -s /scratch/hpc-prf-mypr/username/.vscode-server ~/.vscode-server

VS Code shell environment

VS Code extensions might not find programs that need to be loaded via modules. The environment is evaluated by VS Code once at the moment of the first setup on the remote host. VS Code launches a login shell and checks the environment.
It might be that the VS Code extension has a setting to specify the path to the necessary binary.
Alternatively, you can load the module during startup of the VS Code remote server. For this you need to do the following steps:

Add the following snippet in your ~/.bash_profile to let it load your modules. Replace SOMETHING with your modules. More information.

if [ "$VSCODE_RESOLVING_ENVIRONMENT" = 1 ]; then
    module load SOMETHING
fi

Disconnect your remote VS Code session and stop the remote VS Code server with the VS Code command Remote-SSH: Kill VS Code Server on Host and selecting the remote host. You can check the success with htop -u via an SSH session; it should not show nodeprocesses.
Now start a new remote session with VS Code on the remote host.
You can open a terminal in VS Code to check if the modules are loaded.

Downside: the modules will also be loaded in every terminal in your remote VS Code session!

Alternatives

Remote tunnels

Note: Most likely, you’ll need a GitHub account to use remote tunnels.

One time setup/preparation:

Download the VS Code CLI for Linux under https://code.visualstudio.com/download.
- Direct link (as of April 2023): https://code.visualstudio.com/sha/download?build=stable&os=cli-alpine-x64
On Noctua 2, extract the archive and place the single binary code into ~/.local/bin (create the folder if it doesn’t exist).
Make sure that ~/.local/bin is on PATH. To be safe, put export PATH=$HOME/.local/bin:$PATH into your .bashrc.

Creating a tunnel (server):

On the login/compute node that you want to run your computations on (e.g. allocated via SLURM), run code tunnel --verbose and, if you do this for the first time, follow the steps in the terminal.
Afterwards, open VS Code on you local machine (client) and install the extension “Remote - Tunnels”.
Execute Remote Tunnels: Connect to Tunnel... and select the tunnel that you want to use.
- If you do this for the very first time, you need to authenticate yourself via GitHub.

Note: Similar to “VS Code server location” above, it is recommended to create a symbolic link at ~/.vscode-cli that points to a folder on the parallel file system, e.g. /scratch/hpc-prf-mypr/username/.vscode-cli.

Code-server

The idea is to run a server on a (compute) node and access it (via port forwarding) in your local webbrowser. Steps:

Log in to the node you want to run your computations on (e.g. a node that you’ve allocated via SLURM).
Load the code-server module: module load tools code-server
Start the server with PASSWORD=<YOURPASSWORD> code-server --bind-addr 0.0.0.0:<PORT> --auth password, where <YOURPASSWORD> is a password of your liking and <PORT> is a port number above 1024 (e.g. 8081).
Open a local terminal to establish port forwarding: ssh -L <PORT>:<NODENAME>:<PORT> <YOURACCOUNT>@noctua2.
Finally, open http://127.0.0.1:8081/ to see the VS Code interface, running on the node, in your local browser.

Access for Applications like Visual Studio Code