I added quite a bit more, on VNC; I think it's worth reposting.
Apologies to anybody inconvenienced by the duplication.
: I am trying to export the display of a host on a private subnet to a
: Win2000 machine running Hummingbird Exceed on a public network, via a
: dual-homed host.
So we must conclude (since you are exporting its display) that you
are intending to sit in front of the host on the private subnet
to interact with some app running on the Win2000 machine.
: I was told it's possible but can't seem to get it working. I get the
: dual-homed display exported to the Win2000,
OK, so for this intermediate step you are sitting in front of the
dual-homed machine, and you export it's display (ie, you arrange
for port 6000 on some IP of that machine to be reachable
by the windows machine).
: and from there I run a shell session and xhost + the private address.
So, a process with command line "xhost +" runs ... somewhere, I'll
guess it ru ns on the dual-homed machine since that the "from there"
in the previous context, and... what does it mean to "xhost +" a
"private address"? The xhost command is applied to a display,
not an address. So which display did it get applied to?
Possibly the xhost + got run on and against the display of
the machine on the private subnet. Why that'd be interesting
is unknown.
: I then ssh to that host and set my display to the intermediate host's
: private IP:0.0; XDM is always running;
You ssh to what host from what host? You're confusing me.
But you seem to be saying that you run an ssh client on the dual-homed
host, talking to an ssh server on the private host. Then, you set
the display of this shell, which is running on the private host,
so that X apps started there will display on the private host.
While you are sitting somewhere else.
Curiouser and curiouser.
: Now when I attempt to run a GUI program, it sits just there.
Are you sure it isn't just displaying on the display you told
it to display on, namely, on the host on the private network?
: I did get the display exported on the private subnet as well, but
: wanted this extra hop setup for short-term access for demo purposes.
So, if you are running some process on some second host on the private
network, you can start an X app which displays on the oringinal host on
the private network. Sitting, I presume, in front of the original host.
Whew.
Let's call the hosts W, D, and P, OK? For the windows machine (which is
going to run the X app), the dual-hosted machine (which has NICs on both
the private net, and on some net reachable by W, and the machine on the
private network (which D can reach, but W cannot).
So. You are sitting in front of P, typing to an xterm running on P's X
display. You type "ssh -X D". This starts a shell on D which will have
DISPLAY set to a display served from D, which is proxied to the display
on P. Which means, apps started there will display on P's display. Now
type the "xhost W". This tells the ssh server to allow connections from
apps running on W to that proxy display, the windows of which apps in
turn will appear on P's display. Now you're home free; you start your X
app on the windows machine, arranging for it to display to D:10.0 (or
whatever ssh assigned to the DISPLAY variable on D).
Should work. I've done things much like it before.
Now, on the off chance (since you said "for demo purposes") that you are
in fact sitting in front of W and you want the app to run on P (which
contradicts the bit about exporting P's display, but still). In that
case, you must either run the ssh session from W to D (using putty or
some such). Or, use port forwarding instead of implicit X proxying.
That is, to a shell running on P, you type "ssh -L 6001:W:6000 D", and
then start your app by "env DISPLAY=localhost:1 app", and the app should
now appear on the X server running on W. That server will have to have
done the equivalent of xhost D (or xhost +).
I've done things like this before also, though while it works,
ssh's X proxying tends to do a better job.
----------
That said, you are probably better off using VNC. The VNC client on W
is very lightweight, and can reconnect after an outage or other network
difficulty. One way would be to install VNC on D, and a VNC client on
W. Then on D you type "vncserver -geometry 1024x768 -depth 24 :1", and
on W you simply use the VNC client to connect to D:1. You should see an
xterm there. Type "ssh -X P", and start you app. Note: this assumes X
is installed on D; if not, you will want to install VNC on P, issue the
vncserver comand on P, and on D type "ssh -g -L 5901:localhost:5901";
then connect from W as before.
This way, you could run your demo from any machine you want,
and it wouldn't have to have Exceed. You could go up to some
random machine and download the VNC client and you're off to
the races. You could even arrange to give your demo on your palm,
or pocket pc (given that they have internet access). Or on
mac machines, or just about anything; VNC clients are nigh-ubiquitous.
So. Bottom line, for remote demos, I recommend VNC.
The protocol is less tricky, and it supports many more
combinations of demo and display machine types.
by