jam <[EMAIL PROTECTED]> writes:
> On Tuesday 18 November 2008 10:00:09 [EMAIL PROTECTED] wrote:
>> > On Monday 17 November 2008 10:00:07 [EMAIL PROTECTED] wrote:
>> > > am <[EMAIL PROTECTED]> writes:
>>
>> [snip]
>>
>> > Not a trivial question :-) and not as simple as -X ....
>> >
>> > I'm sitting in front of THIS machine, and logged in
>> > I run a program on this machine, say xeyes or xmsg
>> > I want the display of that program on THAT machine
>>
>> x programs look at the current environment to find out the X display to
>> display to, set DISPLAY=<host>:<MajourScreen#>.<MinorScreen#> - you will
>> have to get around firewalls and Xauth as well.
>
> Thanks Alex
>
> nope ! this is *really* a non trivial question.
>
> the DISPLAY=THAT works only if TCP/IP forwarding is enabled, which it
> is NOT on modern distros [<quote> It is unlikely that something as
> complicated as xorg does not have exploits </quote>}
>
> What I'm trying to achieve is the above using ssh which can be done
> [see LTSP's LDM] but zot-in-hell I cannot fathom out what and how they
> do it!
LTSP boot their display manager, make a connection from the X server
(where the display is) to the application server (where the session
runs) over a secure channel, then use normal X over that channel.
This is, more or less, the double-ssh method I mentioned earlier.
Most people don't have that trouble, though, because they are sitting in
front of the graphical display rather than trying to run an application
on the local system to another, remote, graphical display they are not
physically located in front of.
> Using TCP/IP then discovering that in a year or two that this has been
> removed is the reason for me not doing it.
TCP/IP support hasn't actually been removed[1], just disabled by
default, normally by the display manager (gdm, kdm) passing the
arguments '-nolisten tcp' to the X server.
By removing that option you should be able to enable TCP connections
again, at which point things can go on as they did -- but, obviously,
you take responsibility for the security risks implied.
Regards,
Daniel
For a trusted local LAN they are probably not that great, but on an
untrusted network you would have to be crazy.
Footnotes:
[1] Caveat: I only checked Debian and Ubuntu, so /perhaps/ some other
distribution went plum-crazy here.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html