Bug 6233 - Forwarding of local X11 display
Summary: Forwarding of local X11 display
Status: RESOLVED INFOGIVEN
Alias: None
Product: Slurm
Classification: Unclassified
Component: User Commands (show other bugs)
Version: 18.08.3
Hardware: Linux Linux
: --- 4 - Minor Issue
Assignee: Jason Booth
QA Contact:
URL:
Depends on:
Blocks:
 
Reported: 2018-12-13 10:41 MST by Michael Gutteridge
Modified: 2018-12-13 11:59 MST (History)
0 users

See Also:
Site: FHCRC - Fred Hutchinson Cancer Research Center
Alineos Sites: ---
Bull/Atos Sites: ---
Confidential Site: ---
Cray Sites: ---
HPCnow Sites: ---
HPE Sites: ---
IBM Sites: ---
NOAA SIte: ---
OCF Sites: ---
SFW Sites: ---
SNIC sites: ---
Linux Distro: ---
Machine Name:
CLE Version:
Version Fixed:
Target Release: ---
DevPrio: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Gutteridge 2018-12-13 10:41:07 MST
I've just set up X forwarding in our environment... however, I didn't realize that Slurm is unable to forward a local X display.  Unfortunately for us a good number of our users have local displays- it'd be nice to enable direct forwarding of that display without have to go through an intermediary (ssh -X to another host enables X forwarding and it all works as expected).

It may be something I can work around locally- though to figure that out I think I'd need to know why Slurm won't do that.  Are there security concerns?  Or is this perhaps just something requiring additional development to support?

Thanks much

Michael
Comment 1 Jason Booth 2018-12-13 10:55:01 MST
Hi Michael,

10.08.3 does support x11 forwarding. There are two methods which we currently support.

https://slurm.schedmd.com/faq.html#x11

You can use the X11 builtin feature starting at version 17.11. This plugin is based on libssh2 and it supports hostbased and pubkey authentication.
You just need to have libssh2 installed on compute nodes, libssh2 development package installed in the build host at build time and PrologFlags=x11 set in slurm.conf. You will need also user public/private keys available on compute nodes or otherwise a hostbased authentication setup in your ssh servers. Other X11 plugins must be deactivated. 

...


An alternative for older versions is to build and install an optional SPANK plugin for that functionality. 

We will be changing the builtin feature in 19.05 since there are some shortcomings with that implementation so until then I would suggest using the SPANK plugin.

-Jason
Comment 3 Michael Gutteridge 2018-12-13 11:07:35 MST
Sorry, I perhaps didn't make clear the exact problem.  X forwarding is working great in most cases.  I have one failure scenario- if I am on a local display (e.g. a Linux desktop running X) and attempt to forward that display, I get an error message:

    sp[~]: echo $DISPLAY
    :1020.0
    sp[~]: srun --x11 xeyes
    srun: error: Cannot forward to local display. Can only use 
    X11 forwarding with network displays.

In src/common/x11_util.c, lines 92-96:

	if (display[0] == ':') {
		error("Cannot forward to local display. "
		      "Can only use X11 forwarding with network displays.");
		exit(-1);
	}

I'm hoping for some guidance on how I can get this working or perhaps why this is a bad idea.

Thanks

Michael
Comment 4 Jason Booth 2018-12-13 11:31:56 MST
Hi Michael,

Thank you for the additional information.

> It may be something I can work around locally- though to figure that out I think I'd need to know why Slurm won't do that.  Are there security concerns?  Or is this perhaps just something requiring additional development to support?

Our X11 forwarding implementation cannot connect to unix sockets at this time, this is something we may look at in a future release.

Two options:

- Use "ssh -X localhost", then run "srun --x11" within that SSH session. SSH itself will handle translation between a TCP socket that Slurm's implementation can use to the local unix socket.

- Disable our build-in integration, and use the SPANK X11 plugin instead. Due to differences in how it forwards traffic, it can accommodate use of a unix socket instead of a network socket.

-Jason
Comment 5 Michael Gutteridge 2018-12-13 11:58:39 MST
Ah, yes- that makes perfect sense.  Thanks for the workaround- it's a hop, but it'll get us by.

 - Michael
Comment 6 Jason Booth 2018-12-13 11:59:24 MST
Resolving this now as info given.