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@xxxxxxxxxxxxxxxxx> 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.
--
fedora-legacy-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-legacy-list
