[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DDDing an Xwindows progam remotely
From: |
v4r4n |
Subject: |
Re: DDDing an Xwindows progam remotely |
Date: |
Tue, 22 Mar 2005 15:36:59 -0800 |
I would love to use ssh, but I'm working within a very old and
insecure environment. The two accounts I use don't even have
passwords, which is unacceptable for 'ssh'ing. [I also don't have
permission to give the accounts passwords]
"man xhost" hasn't helped since I'm not quite sure what is wrong... it
doesn't make much sense to me that DDD would use a different DISPLAY
variable when running GUI applications with itself.
'xhost +' does not solve the problem. I also don't think there is a
list of hosts for xhost to refer to [there is not /etc/X*.hosts file].
I'm now currently using an old win32 Xclient to log into the same
SUSE9 machine getting the exact same error the RedHat machine has
problems with.
When I log in, the default DISPLAY=:0.0 doesn't work so I set it to
192.168.xxx.xxx:0.0 or domain.name:0.0 and then I can open X-apps.
DDD opens fine, but any GUI app that DDD trys to open fails... is DDD
running this other application as a different user?
Thanks
On Thu, 02 Dec 2004 14:00:13 +0200, Andrew Gaylard <address@hidden> wrote:
> v4r4n wrote:
> > (gdb) run
> > Xlib: connection to ":0.0" refused by server
> > Xlib: No protocol specified
> >
> > Error: Can't open display: :0.0
> >
> > Program exited with code 01.
> > (gbd)
> >
> > Starting from the command line with DDD's -display option does not
> > seem to effect the problem, and only determines whether DDD itself
> > runs, not the application being debugged.
> >
> > Is this a possible DDD bug or are my X-windows environment variables
> > all messed up?
>
> Neither. This is a basic X access problem. Try "man xhost".
>
> Better still, use ssh with your ssh_config and sshd_config set up
> to forward X traffic over the ssh session.
>
> Andrew.
>
>
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: DDDing an Xwindows progam remotely,
v4r4n <=