Starting X11 program from program, back on the original machine - SSH

An X11 application "xapp" is run on machine M2 and displayed on machine
M1's display:

M1$ ssh -X M2 xapp

Now, "xapp" wants to run a resource hungry and graphics intensive X11
program "xburnin" on the machine from which it was started remotely (i.e.
M1 in this case). The output of "xburnin" should be displayed on the
machine that it is running on (again this is M1 in this case). There are
at least two ways to start "xburnin" from "xapp":

A) Command: ssh -X M1 xapp

Disadvantages:

- This appears to be inefficient since X data is transmitted from M1 to
M2 and back. This is essentially the same as running the following
command:

M1$ ssh -X M2 ssh -X M1 xburnin

- "xapp" needs to find out the IP or the host name of the machine from
which it was started remotely. Surely, this can be done using the
variable "$CONNECT".

B) Command: ssh M1 "xburnin -display :0.0"

Advantage:

- The X11 data does not cause traffic on the network that connects M1
and M2.

Disadvantage:

- "xapp" needs to find out the IP or the host name of the machine from
which it was started remotely. Also "xapp" needs to find out the
number of M1's display. In most cases this number is ":0.0", but not
in all cases.

What do you recommend? Is there a third way? Maybe there's a very simple
solution.

--
Felix E. Klee

"Felix E. Klee" writes:

> What do you recommend? Is there a third way? Maybe there's a very simple
> solution.

Are you trying to code for all possible cases?

I'd be tempted to test
$ ssh -x xapp

Little X to specifically disable X11 forwarding, then remote dispaly
is taken out of the realm of possibility. You'd be at the mercy,
however, of any silly DISPLAY variable settings that might be hard
coded into a users profile. So coding this for all possible
situations is going to be difficult. A display of 127.0.0.1:0.0 is a
pretty safe bet as a default though, I'd say.

Unfortuantely I don't have a box up handy right now to test this.

THe other thing you have to worry about are xhost settings. If the
person on the console isn't allowing connections from others, yer out
of luck in something that will work all the time unless you can issue
commands as root on the remote box.

Best Regards,
--
Todd H.
http://www.toddh.net/

In article "Felix E. Klee"
writes:
>
>B) Command: ssh M1 "xburnin -display :0.0"
>
> Advantage:
>
> - The X11 data does not cause traffic on the network that connects M1
> and M2.
>
> Disadvantage:
>
> - "xapp" needs to find out the IP or the host name of the machine from
> which it was started remotely. Also "xapp" needs to find out the
> number of M1's display. In most cases this number is ":0.0", but not
> in all cases.

If you have control over "xapp" (and if not the questions would seem
academic:-), why not have it take those parameters as arguments?
I.e. original invocation something like

M1$ ssh -X M2 xapp --xburnin-host `hostname` --xburnin-display $DISPLAY

- though using the $SSH_CLIENT env.variable for the host/IPaddr may
actually be preferable, programmatically finding out what a remote host
should best use to connect back to you is actually non-trivial (e.g. in
the above case `hostname` isn't necessarily something that M2 can
resolve to a working IP address).

There's another (not SSH-related) issue with this method though, namely
X authentication - it more or less requires that "xapp" can connect back
as the same user that did the original invocation, or "xburnin" won't
know, or won't be allowed, to use the $HOME/.Xauthority file on M1.

--Per Hedeland
per@hedeland.org