The Wynton HPC environment supports running a graphical user interface (GUI) on Wynton HPC while viewing and interacting with it on your local computer. More specifically, and in more technical terms, Wynton HPC supports NX and X11 Forwarding protocols.
Due to limitation in X2Go Client, it is not possible to connect to Wynton HPC when using SSH password(*). Instead, in order to connect to Wynton using the X2Go Client, you have to have a working SSH key pair set up and configured the X2Go Client.
If you are connecting to Wynton from off campus, you will also have to use Two Factor Authentication (2FA) for Wynton. This is not needed if you are connected via the UCSF VPN.
First, you will need to install the X2Go Client on your local computer. For instructions on how to do this, see Installing X2Go Client. When you first run x2goclient:
Wynton HPC
dev1
, dev2
, dev3
, or gpudev1
pdev1
or pgpudev1
alice
log1.wynton.ucsf.edu
or log2.wynton.ucsf.edu
plog1.wynton.ucsf.edu
MATE
With the above setup, the following instructions opens a remote desktop window on your local computer:
If you get a dialog saying ‘Error: Connection failed. bash: x2golistsessions: command not found’, then you have missed configuring a ‘Proxy server’ in Steps 7-8 of Section ‘Setup of the X2Go Client (once)’.
You can also use X11 forwarding over the SSH connection used to connect to Wynton HPC.
Note that, to do this, you will need to be running an X server on your local machine. You can check this by verifying that environment variable DISPLAY
is set on your local computer, e.g.
{local}$ echo "DISPLAY='$DISPLAY'"
DISPLAY=':0'
If DISPLAY
is empty, that is, you get:
{local}$ echo "DISPLAY='$DISPLAY'"
DISPLAY=''
then you don’t have a local X server set up and the below will not work. If you are on macOS, we recommend installing open-source XQuartz.
To setup the X11 forwarding when connecting to the cluster, add option -X
, or -Y
on macOS, to your SSH call. For performance reasons, we will also add option -C
to enable SSH compression. By using compression, the responsiveness and latency in GUIs will be much smaller - our benchmarks show a 5-7 times improvement when connected via the UCSF VPN (~60 Mbps download and ~5 Mbps upload). To login with X11 forwarding and compression enabled, do:
{local}$ ssh -X -C alice@log1.wynton.ucsf.edu
alice1@log1.wynton.ucsf.edu:s password:
[alice@log1 ~]$ echo "DISPLAY='$DISPLAY'"
DISPLAY='localhost:20.0'
[alice@log1 ~]$
By checking that DISPLAY
is set, we know that X11 forwarding is in place. If DISPLAY
is empty, then make sure you have specified -X
(or -Y
).
If you are on macOS, you need to use ssh -Y ...
instead of ssh -X ...
. This is because macOS does not trust remote X servers by default.
Now, since we should not run anything on the login nodes, the next step is to head over to one of the development nodes. When doing so, we have remember to keep using X11 forward, that is, we need to use -X
also here;
[alice@log1 ~]$ ssh -X dev1.wynton.ucsf.edu
alice1@dev1:s password:
[alice@dev1 ~]$ echo "DISPLAY='$DISPLAY'"
DISPLAY='localhost:14.0'
[alice@dev1 ~]$
Comment: There is no need to use SSH compression in this second step. If used, it might even have a negative effect on the X11 latency.
Now we have an X11 forward setup that runs all the way back to our local computer. This will allow us to open, for instance, an XTerm window that runs on dev1.wynton.ucsf.edu but can be interacted with on the local computer;
[alice@dev1 ~]$ xterm
[ ... an XTerm window is opened up ... ]
If you get an error here, make sure that DISPLAY
is set and non-empty.
Tips: You can login into a development node in a single call by “jumping” (-J
) via the login node, e.g.
{local}$ ssh -X -C -J alice@log1.wynton.ucsf.edu alice@dev1.wynton.ucsf.edu
[alice@dev1 ~]$