<div dir="ltr"><div>I posted about the local display issue a while back (<span class="gmail-F0XO1GC-mb-Y" id="gmail-t-t">"Built in X11 forwarding in 17.11 won't work on local displays"). <br></span></div><div><span class="gmail-F0XO1GC-mb-Y" id="gmail-t-t"><br></span></div><div><span class="gmail-F0XO1GC-mb-Y" id="gmail-t-t">I agree that having some local managed workstations that can also act as submit nodes is not so uncommon. However we also ran into this on our official "login nodes" because we use X2Go (open source fork of NoMachine) as our main access method, which gives you a "local" display.  There are a number of advantages to using X2Go (or other NoMachine/FreeNX derivatives) over plain SSH X11 forwarding. <span class="gmail-F0XO1GC-mb-Y" id="gmail-t-t">Over 90% of our users 
are using Windows workstations and many aren't very familiar with Linux.
 They need something more than PuTTY for GUI access anyway, and 
providing a remote desktop solution helps smooth out the learning curve. </span>The performance for many GUI applications is much better, and we can integrate VirtualGL so that users can easily run light visualization tasks utilizing the GPU on the login nodes or request a GPU node with srun for larger visualization tasks. I haven't tried yet, but using the "ssh -X localhost" workaround would likely break my VirtualGL setup (or at least slow it down). If nothing else, requiring "ssh -X localhost" (in each terminal they want run interactive jobs from!) is confusing.<br></span></div><div><span class="gmail-F0XO1GC-mb-Y" id="gmail-t-t"><br></span></div><div><span class="gmail-F0XO1GC-mb-Y" id="gmail-t-t">For now we compile our own packages with built-in X11 support disabled and continue to use the spank plugin.<br> </span></div><div><span class="gmail-F0XO1GC-mb-Y" id="gmail-t-t"></span></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 26, 2018 at 1:41 AM Marcus Wagner <<a href="mailto:wagner@itc.rwth-aachen.de">wagner@itc.rwth-aachen.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Chris,<br>
<br>
I really think, it is not that uncommon. But in another way like Tina <br>
explained.<br>
<br>
We HAVE special loginnodes to the cluster, no institute can submit from <br>
their workstations, they have to login to our loginnodes.<br>
BUT, they can do it not only by logging in per ssh, but also per FastX, <br>
which provides a full desktop to the user, in our case the user can <br>
choose between MATE and XFCE.<br>
The DISPLAY variable after login is set e.g. to ":104", since there are <br>
many users on the nodes. So, to use X11 forwarding with native SLURM, <br>
the user needs to login to another host with "ssh -X", which is at least <br>
inconvenient, if not even confusing for the user.<br>
<br>
This might be ok, if you have a small group of users, which can be <br>
trained before they use the cluster. But we have about 40.000 students <br>
which at least theoretically could use the cluster. We see over one year <br>
about 2600 different users on the cluster, only 400 or so are constant <br>
users.<br>
<br>
@Mahmood:<br>
Sorry, if you misunderstood me. I did not mean to login to one of the <br>
computenodes, but slurm does not accept a socket in the DISPLAY <br>
variable, this is why you have to login somewhere else with X11 <br>
forwarding, or like Tina explained at least to localhost again with X11 <br>
forwarding.<br>
<br>
<br>
Best<br>
Marcus<br>
<br>
<br>
On 11/22/2018 12:05 PM, Chris Samuel wrote:<br>
> On Thursday, 22 November 2018 9:24:50 PM AEDT Tina Friedrich wrote:<br>
><br>
>> I really don't want to start a flaming discussion on this - but I don't<br>
>> think it's an unusual situation.<br>
> Oops sorry, I wasn't intending to imply it wasn't a valid way to do it, it's<br>
> just that across the many organisations I've helped with HPC systems down here<br>
> it's not something I'd come across before.   Even the couple that had common<br>
> authN/authZ configs between user workstations and clusters had the management<br>
> nodes firewalled off so the only access to the batch system was by ssh into<br>
> the login nodes of the cluster.<br>
><br>
> I think it's good to hear from sites where this is the case because we can<br>
> easily get stuck in our own little bubbles until something comes and trips us<br>
> up like that.<br>
><br>
> All the best!<br>
> Chris<br>
<br>
-- <br>
Marcus Wagner, Dipl.-Inf.<br>
<br>
IT Center<br>
Abteilung: Systeme und Betrieb<br>
RWTH Aachen University<br>
Seffenter Weg 23<br>
52074 Aachen<br>
Tel: +49 241 80-24383<br>
Fax: +49 241 80-624383<br>
<a href="mailto:wagner@itc.rwth-aachen.de" target="_blank">wagner@itc.rwth-aachen.de</a><br>
<a href="http://www.itc.rwth-aachen.de" rel="noreferrer" target="_blank">www.itc.rwth-aachen.de</a><br>
<br>
<br>
</blockquote></div></div>