exporting displays question

[Gene Heskett]

On Friday 09 December 2005 17:42, David Eisenstein wrote:
>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?

Yes, at least till the hd upchucked all over itself yesterday.

>> 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.

This is all trusted, no internal firewalls of any kind on the 
coyote.den domain.
>
>   -------------(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):

I don't believe such an option is set here.  Would that show in the 
xorg.0.log?

>   Config file-  /etc/X11/gdm/gdm.conf
>
>   Change line:
>     #DisallowTCP=true
>   to:
>     DisallowTCP=false

I'll try this, and I just set the RemoteLoginAllowed=true also.  Or is 
that not needed.

>(I don't boot up in X; I start the X server with my own startx
> command, thereby controlling the X startup options myself.)

Ditto.

>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:

Nope, no iptables running on either box, just an 8 port 100baseT switch 
between them, and about 100 feet of cat5.

>-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

I'll find out after I've resuscitated that box, the hd's got funkity in 
the cold and trashed themselves yesterday.  So I've got to start with 
a fresh install after I lug it all into the comfort zone here.  I'll 
do that after I locate some thermo controlled fans so it will keep 
warm if I leave it on, but not overheat in the summertime.

-- 
Cheers, Gene
People having trouble with vz bouncing email to me should use this
address: <gene.heskett at verizononline.net> which bypasses vz's
stupid bounce rules.  I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.