On Wed, Mar 30, 2011 at 7:39 AM, ken <gebser at mousecar.com> wrote: > On 03/29/2011 05:45 AM John Hodrien wrote: >> On Mon, 28 Mar 2011, ken wrote: >> >>> Like the error says, you need to specify the display. I.e., on the >>> remote machine you must set the environmental variable "DISPLAY"... >>> something like >>> >>> (export DISPLAY=192.168.1.42:0.0 & firefox) >>> >>> Though this may work, this may well reveal another, different error, one >>> having to do generally with permissions. But we'll take them one at a time. >> >> Do *not* follow this advice. It's bad practice, insecure, and actually more >> work than being secure, and more likely not to work. Plenty of X servers are >> configured to not listen on your network interface for example. >> >> ssh -X / -Y is your friend, as others have suggested. >> >> jh > > John, > > Whether or not it's "more work" is highly subjective. And it's not > inherently insecure; people often *make* it insecure by lazily setting > permissions to allow *any* server to have access. Even ssh can be > insecure if it's not configured properly. The lack of encryption is automatically insecure, and anyone who can start an X program with the 'DISPLAY' set on the remote server can access the X session. I've used this to run 'xroach' on people's systems who refused to secure their X sessions properly. I actually got in trouble for all the screaming. It's also hideous practice to hardcode that X server in the .bashrc, because logins from home or another system will push the X sessions to that hardcoded X server. Really, it's a bad practice from 20 years ago by people who didn't understand X and who just wanted things to work now. It should *never* be replicated these days, except under the most deranged of circumstances (such as wanting everybody's X programs to pop up on a single, shared X server for public display.)