On Thu, 8 Dec 2005, Gene Heskett wrote:
> Hi all;
>
> I'm trying to export the x display on a more or less debian/morphix (the bdi
> install of emc-4.30 TBE) box in my workshop, current temps in the teens,
> which I believe uses the XFree86 stuff, to my main box here in a nice warm
> room, and failing miserably.
>
> Here I've done an 'xhost +' which supposely lets everyone in according to the
> message it returned when I ran it.
It should, but there may be more to do.
> There I've set the DISPLAY=thisbox:0 and exported it.
>
> An ssh -X eventually works but I am still lookng at the local konsole I used
> to log into the remote box when its done.
>
> An attempt to run an xterm while ssh -X'd into that box fails in about 2
> minutes, saying it can't open the display 192.168.xx.x:0, which is this box.
So it's in the ssh terminal session running on thatbox that you've
exported DISPLAY=thisbox:0, right?
> This box is a rather hacked FC2 and is reasonably uptodate, but its not
> running XFree86, its running x.org-6.8.1-901 and running it very well
> since a couple of days after it was announced, what, a year ago?
>
> So whats the next thing to do to make this work? Any and all clues
> cheerfully accepted at this point.
There are two methods of going about this. One way is to allow the ssh
program to forward X connections. Typically it does so by the sshd daemon on
the remote box that opens the terminal connection there already setting you
up with a DISPLAY exported variable (typically, with DISPLAY=localhost:10.0),
so you don't have to set one up yourself. (Your ssh -X should create the
TCP/IP and socket plumbing to do this automagically, so you shouldn't define
a DISPLAY environment variable there to use this method.) The X connection
is then forwarded through the ssh session to your thisbox X server when you
start a client program on that box, like say, xclock or xterm.
This way of doing it, however, incurs the overhead of having all the
data over the wire be encrypted by the client (thatbox) machine to be
decrypted by your X server (thisbox) machine and vice-versa, since all the X
traffic runs through the ssh connection. This is a great method to use if
you're using an untrusted network.
-------------(thatbox localhost)--------------------(thatbox) ------encrypted data------ ------------------------(thisbox)-------------------
xclock -> [DISPLAY :10.0 (TCP port 6010)] -> sshd -> [SSH port 22] -> [ethernet TCP/IP] -> [SSH client port] -> ssh -> [unix domain socket] -> X server
___________________________________
The second method, using the DISPLAY=thisbox:0, is a bit more complicated
but is more efficient since there's no encryption over the wire.
(Disclaimer: Bear in mind the below advice is what I'd do in FC1; things
may or may not be the same in FC2.)
First thing is to make sure that your X server is not running with the
"-nolisten tcp" option. If X is running with that option, then it will
accept client connections only over UNIX domain sockets, not over TCP/IP.
(You can tell by doing a $ ps ax and looking at the command arguments for X
on thisbox).
If you're booting up in X on your comfy computer, running Gnome and the Gnome
Display Manager (gdm), my understanding is that you can change a setting in
its configuration file that will start the X server without the "-nolisten
tcp" option (I haven't tried this myself):
Config file- /etc/X11/gdm/gdm.conf
Change line:
#DisallowTCP=true
to:
DisallowTCP=false
(I don't boot up in X; I start the X server with my own startx command,
thereby controlling the X startup options myself.)
Second thing is to make sure you don't have TCP port 6000 (the port for X
display :0) blocked by an iptables firewall running on your FC2 thisbox. If
necessary, you can edit /etc/sysconfig/iptables to add a line like this:
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 192.168.yy.y --dport 6000 -j ACCEPT
where '192.168.yy.y' is the IP address of your ice-cold workshop computer
(thatbox). Then restart the firewall. (Bear in mind that when you manually
edit the iptables config file, you risk losing that manual configuration if
you run Red Hat's (or Fedora's) {redhat,system}-config-securitylevel program
unless you back up your manual changes somewhere and put them back after
running that program.)
Hope this helped. -David
--
fedora-legacy-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-legacy-list
