You also need to go into Xming's directory ( C:\Program Files\Xming on my
machine ), bring up X0.hosts in notepad, and add the hosts that will be
permitted to connect to your desktop ( I prefer using IP addresses rather
than names - a dns/internal political issue )
David Boyes
<dbo...@sinenomin
e.net> To
Sent by: Linux on [email protected]
390 Port cc
<[email protected]
IST.EDU> Subject
Re: Windows emulation
10/06/2009 07:19
AM
Please respond to
Linux on 390 Port
<[email protected]
IST.EDU>
On 10/5/09 11:00 PM, "Bernie VK2KAD" <[email protected]> wrote:
> I am running a windows desktop so I downloaded Xming to use as the
Xserver -
> It installed OK - I then ran Xlaunch to get it going - xming.exe appears
as
> a running process in Task Manager - to configure I selected display
number 0
> (zero) and accepted all other defaults.
So far, so good.
> On my Zlinux I issued
> -bash-4.0# set DISPLAY=20.250.180.96:0,0;export DISPLAY
That should be a period (.) between the last pair of 0s, eg
set DISPLAY=foo.bar.baz:0.0;export DISPLAY
You're specifying video-adapter.display attached to adapter with that :0.0.
The comma is a syntax error.
> Then to test I issued
> -bash-4.0# xeyes
> Error: Can't open display:
>
> I can ping 20.250.180.96 from zLinux and in a Putty SSH session so I know
I
> have IP connectivity.
There's one more step...
> I'm not sure what " make sure you have run 'xhost +remote.linux.system'
on
> the desktop system" means in the context of the above config.
On top of connectivity between client and server, X also has a crude
permission scheme that controls what hosts are allowed to project client
windows onto your screen. The whole X protocol is a series of transactions
between the client application and the X server -- the X server is
basically
a rendering engine for a set of standard primitives supplied by the client,
and sends mouse movements and key presses back to the client as
standardized
event structures.
The xhost application is the key to authorizing a host to project events
onto your X server and/or receive events back -- if you haven't told the X
server on your Windows machine that clients on "remote.linux.system" are
allowed to project things, you get the Can't open display error (although
in
your case, I think the comma in the DISPLAY spec is what's messing you up).
You can get there, but the host doesn't have permission to use that
display.
Running 'xhost +remote.linux.system' allows the remote.linux.system host to
use the display currently pointed to by the DISPLAY environment variable.
You could just do "xhost +" (which allows the whole world to connect), but
that also allows ANYONE to inject ANY X event into your X server -- or grab
any event coming FROM your X server, like typing your password.
You typically need to do this on the local system running the X server
(there's a chicken/egg problem here in that you need to authorize the
remote
system to connect and do things, but you can't do that until you authorize
the remote system....), so there's some special case code in xhost and the
X
server to check if they're on the same system and let the request through.
Most non-Unix PC implementations finesse this by just automatically
authorizing everyone, but they really shouldn't.
> I used xeyes
> as a test because I don't have xterm (my Zlinux is Fedora11 and xterm
> doesn't appear when I enter z + TAB in bash.
Ouch. Xeyes will work, but realize that it processes EVERY mouse movement
you make as a stream of events, which will burn CPU like crazy.
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
