ssh -Y -l user etc,etc

[Eirik Byrkjeflot Anonsen]

gene heskett <gheskett at wdtv.com> writes:

> On Thursday, February 24, 2011 10:23:08 pm Glynn Clements did opine:
>
>> gene heskett wrote:
>> > So that probably explains where the 10.0 is coming from, but not where
>> > I might change it?  That seems to be the $64k question...
>> 
>> Why do you need to change it? 
>
> Because its not working? :)

I think we're getting to the root of the problem here :)

So, you want to run emc on the machine called 'shop', and you want it to
display its UI on the machine called 'coyote'.

Using 'ssh -Y shop' (on coyote) will make ssh create a proxy X server on
'localhost:10.0' on 'shop' (by default).  This X server will only
forward all requests to the real X server on 'coyote'.  That's why you
would want the DISPLAY variable to say 'localhost:10.0'.

In principle, you could set DISPLAY to 'shop:10.0' and connect to the
same X server (the proxy created by ssh), but that requires setting
X11UseLocalhost to no.  And it probably won't help, unless emc is doing
something very strange when it tries to connect to X.

To connect directly to the real X server, you'd have to set DISPLAY to
'coyote:0.0' (assuming the X server on coyote is using the default
setting).  However, that will only work if:

1. The X server on coyote is set up to listen to tcp.
2. You have set up the proper credentials to allow connections to it.

For 1, most current systems turn off tcp support when starting X as it
is not particularly useful (for most people) and an obvious security
issue.  I assume this is still done by passing the '-nolisten' option on
startup of the X server.

For 2, you have to wrestle with xauth or xhost to get things set up
correctly.

However, I suspect this isn't really what you want anyway.  None of this
should be necessary.  'ssh -Y' should be plenty of good enough.


It is probably best to split up debugging into two stages: first make
sure the X setup works, and then figure out why emc fails to use it.  If
a "simple" X application (e.g. xterm) can successfully start up on
'shop' and display its window on 'coyote', then the X setup is working
and you shouldn't need to fiddle with DISPLAY or X11UseLocalhost.

If xterm works correctly, then it is most likely emc that has a bug of
some sort.  It could be useful to try setting X11UseLocalhost to no,
just to check that it doesn't make a difference.  (If that actually
makes emc work, it is probably about time to make a bug report to
emc...)

[...]
> X11UseLocalHost is
> #X11UseLocalhost yes in /etc/ssh/sshd_config
> commented out.  Does changing that need a reboot?

You'd probably need to restart the ssh daemon, but that should be
sufficient.  Though I don't think changing this setting will help.


gene heskett <gheskett at wdtv.com> writes:

> On Thursday, February 24, 2011 12:41:00 pm Eirik Byrkjeflot Anonsen did 
> opine:
>
>> gene heskett <gheskett at wdtv.com> writes:
[...]
>> > Now, the fix that did make it work before is still there:
>> > 
>> > gene at shop:~/emc2/configs/genes-mill$ echo $DISPLAY
>> > localhost:10.0
>> 
>> I assume you haven't set that yourself, but that it gets automatically
>> set by ssh?
>
> No, but I forget where I put it, so a "grep -R 'DISPLAY=localhost:10.0' /" 
> is pounding the 'shop' machines drive looking for it now.

Then it is probably set by ssh when it starts up.  Which is the way it
should be.

[...]
> In fact, both machines are running X.

Hmm, then it would be interesting to test if emc can run correctly
locally on 'shop'.  Just to make sure that it is in fact something about
the remote X setup that fails.

eirik