Hello
i have a problem on CentOS 4 with starting remote x application on remote CentOS 3 od Solaris 9 boxes.
The problem is: When I run it from CentOS 3 it's OK form CentOS 4 I cannot find a bad word in logs ...
My local machine
stoping firewall [root@klima-pc ~]# service iptables stop [root@klima-pc ~]# iptables-save [root@klima-pc ~]#
SELinux is OFF
I am connecting by ssh with Xforwarding enabled to - Centos 3 box
[09:32 root@tux:root]# gvim --sync The program 'gvim' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAtom (invalid Atom parameter)'. (Details: serial 287 error_code 5 request_code 20 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) [09:33 root@tux:root]#
-Solaris 9 box root@sun bin# gvim --sync Gdk-ERROR **: BadAtom (invalid Atom parameter) serial 364 error_code 5 request_code 20 minor_code 0 Gdk-ERROR **: BadAccess (attempt to access private resource denied) serial 365 error_code 10 request_code 102 minor_code 0 root@sun bin#
On Tue, 2005-05-03 at 11:05 +0200, Petr Klíma wrote:
Hello
i have a problem on CentOS 4 with starting remote x application on remote CentOS 3 od Solaris 9 boxes.
The problem is: When I run it from CentOS 3 it's OK form CentOS 4 I cannot find a bad word in logs ...
My local machine
stoping firewall [root@klima-pc ~]# service iptables stop [root@klima-pc ~]# iptables-save [root@klima-pc ~]#
SELinux is OFF
I am connecting by ssh with Xforwarding enabled to
- Centos 3 box
[09:32 root@tux:root]# gvim --sync The program 'gvim' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAtom (invalid Atom parameter)'. (Details: serial 287 error_code 5 request_code 20 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) [09:33 root@tux:root]#
-Solaris 9 box root@sun bin# gvim --sync Gdk-ERROR **: BadAtom (invalid Atom parameter) serial 364 error_code 5 request_code 20 minor_code 0 Gdk-ERROR **: BadAccess (attempt to access private resource denied) serial 365 error_code 10 request_code 102 minor_code 0 root@sun bin#
It is a feature ... really, it is (according to RH) :). Here is a quote from the RH mailing list:
--------------------- I think by default X11Forwading is now disabled in SSH. You can either use 'ssh -X' or change it in your /etc/ssh/ssh_config. I have the following in mine:
ForwardX11 yes ForwardX11Trusted yes --------------------
That should make it work the way you expect.
It is a feature ... really, it is (according to RH) :). Here is a quote from the RH mailing list:
I think by default X11Forwading is now disabled in SSH. You can either use 'ssh -X' or change it in your /etc/ssh/ssh_config. I have the following in mine:
ForwardX11 yes ForwardX11Trusted yes
That should make it work the way you expect.
YES YES YES
by default ForwardX11 yes ForwardAgent yes ForwardX11Trusted no
so you have to change to ForwardX11Trusted yes
and voila it works
Thank you
Petr Klíma
JIHOMILK a.s. Rudolfovská 246/83 370 50 České Budějovice Czech Rpublic
phone: +420 389 136 209 e-mail: petr.klima@jihomilk.cz
On Tuesday 03 May 2005 06:28, Johnny Hughes wrote:
On Tue, 2005-05-03 at 11:05 +0200, Petr Klíma wrote:
i have a problem on CentOS 4 with starting remote x application on remote CentOS 3 od Solaris 9 boxes.
The problem is: When I run it from CentOS 3 it's OK form CentOS 4 I cannot find a bad word in logs ...
I think by default X11Forwading is now disabled in SSH. You can either use 'ssh -X' or change it in your /etc/ssh/ssh_config. I have the following in mine:
ForwardX11 yes ForwardX11Trusted yes
That should make it work the way you expect.
Or use ssh -Y. Recent Cygwin is the same; in fact, any recent SSH; it's not Red Hat's fault, it's upstream.