Noctua 1

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 noctua-jumphost
  Hostname fe.noctua1.pc2.uni-paderborn.de
  User [USERNAME]
  IdentityFile [PATH TO PRIVATE KEY]
  IdentitiesOnly yes

Host noctua-ln1
  Hostname ln-0001
  User [USERNAME]
  ProxyJump noctua-jumphost
  IdentityFile [PATH TO PRIVATE KEY]
  IdentitiesOnly yes

Host noctua-ln2
  Hostname ln-0002
  User [USERNAME]
  ProxyJump noctua-jumphost
  IdentityFile [PATH TO PRIVATE KEY]
  IdentitiesOnly yes

This will instruct ssh to use the host noctua-jumphost as a proxy when trying to connect to one of the frontends noctua-ln1 or noctua-ln2. We recommend to explicitly choose a frontend here 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 noctua-ln1 or noctua-ln2 to connect to. Please don't use this way for interactive sessions.

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.

VS Code on 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 1 and 2 based on wildcards (the jump hosts are defined here):
- ```
# Noctua 2
Host n2cn* n2lcn* n2gpu* n2fpga*
    HostName %h
    ProxyJump n2-jumphost
    User [USERNAME]
    IdentityFile [PATH TO PRIVATE KEY]
    IdentitiesOnly yes
    
# Noctua 1
Host cn-* gpu-*
    HostName %h
    ProxyJump noctua-jumphost
    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

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