Finally found it. It was a problem with the make file.
On Wed, Jun 26, 2013 at 1:09 PM, Mark Pace <[email protected]> wrote: > I've had some to time to go back and make this work properly through X11 > forwarding. I've followed the Ported Tools guide to setup X11 forwarding, > which included compling the xauth program and changing some parameters in > the sshd_config. But when I connect via PuTTY with X11 forwarding turned > on I receive these messages. Each time I see it creating a new .Xauthority > file, yet I never see that file being created. Also I receive some errors > about bad display names. And lastly I receive erros trying to run the X > application. No amount of googleing has had an answer to the bad display > name, which I assume also has something to do with the errors running the > app. Anyone with experience with X11 on z/OS have an idea what I am doing > wrong? > > login as: marpace > [email protected]'s password: > /usr/lpp/tcpip/X11R6/lib/xauth: creating new authority file > /u/home/MARPACE/.Xauthority > /usr/lpp/tcpip/X11R6/lib/xauth: (stdin):1: bad display name "unix:10.0" > in "remove" command > /usr/lpp/tcpip/X11R6/lib/xauth: (stdin):2: bad display name "unix:10.0" > in "add" command > MARPACE: >ls -al > total 176 > drwxr-xr-x 4 KBURTON TCPIP 8192 Jun 26 13:00 . > drwxr-xr-x 9 DRVUSER AOPADMIN 8192 Jun 7 08:49 .. > -rw------- 1 DRVUSER TCPIP 2770 Jun 26 12:59 .history > -rwxr-xr-x 1 DRVUSER TCPIP 992 Jun 6 10:56 .profile > -rw------- 1 DRVUSER TCPIP 2336 Jun 26 13:00 .sh_history > drwx------ 2 DRVUSER TCPIP 8192 Jun 5 10:46 .ssh > -rwxr--r-- 1 DRVUSER TCPIP 6004 Jun 10 15:31 .tcshrc > -rw-rw-rw- 1 DRVUSER TCPIP 499 Jun 7 09:01 EmptyFrame1$1.class > -rw-rw-rw- 1 DRVUSER TCPIP 640 Jun 7 09:01 EmptyFrame1.class > -rw-rw-rw- 1 DRVUSER TCPIP 642 Jun 7 09:00 EmptyFrame1.java > drwxrwxrwx 3 DRVUSER TCPIP 8192 Jun 26 11:15 XauthBuild > MARPACE: >/usr/lpp/java/J6.0/bin/java EmptyFrame1 > EZYXW01E Xlib: connection to "localhost:10.0" refused by server > PuTTY X11 proxy: wrong authentication protocol attempted > Exception in thread "main" java.lang.InternalError: Can't connect to X11 > window server using 'localhost:10.0' as the value of the DISPLAY variable. > at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) > at > sun.awt.X11GraphicsEnvironment.access$100(X11GraphicsEnvironment.java:52) > at > sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:155) > at > java.security.AccessController.doPrivileged(AccessController.java:202) > at > sun.awt.X11GraphicsEnvironment.<clinit>(X11GraphicsEnvironment.java:131) > at java.lang.J9VMInternals.initializeImpl(Native Method) > at java.lang.J9VMInternals.initialize(J9VMInternals.java:200) > at java.lang.Class.forNameImpl(Native Method) > at java.lang.Class.forName(Class.java:136) > at > java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:68) > at java.awt.Window.init(Window.java:380) > at java.awt.Window.<init>(Window.java:432) > at java.awt.Frame.<init>(Frame.java:415) > at java.awt.Frame.<init>(Frame.java:380) > at javax.swing.JFrame.<init>(JFrame.java:175) > at EmptyFrame1.<init>(EmptyFrame1.java:9) > at EmptyFrame1.main(EmptyFrame1.java:23) > > > > > On Mon, Jun 10, 2013 at 8:10 AM, Mark Pace <[email protected]> wrote: > >> True - that was my stated objective. But it was out of ignorance, I >> thought all X went through SSH. Since this test is over a VPN, I don't >> care how it works, as long as it does. >> >> >> On Fri, Jun 7, 2013 at 5:09 PM, Paul Gilmartin <[email protected]>wrote: >> >>> On Fri, 7 Jun 2013 13:53:38 -0400, Mark Pace wrote: >>> >>> >I appreciate the heads-up, Mark. But this traffic is going through a >>> VPN, >>> >so I'm not concerned about it. I will make note of this if I ever have >>> to >>> >do this in the clear. >>> > >>> Your initial stated objective was to get X11 forwarding working and >>> verified. >>> But now that it isn't but something else is working, you seem satisfied. >>> >>> >>> >On Fri, Jun 7, 2013 at 1:31 PM, Mark Post wrote: >>> > >>> >> > In this case the export DISPLAY IP is my desktop running the X >>> server. >>> >> >>> >> Well, what is working is _not_ tunneling X over SSH. You're sending X >>> >> traffic back to your desktop over an entirely different port, with no >>> >> encryption. If anyone decides to close off traffic on ports 6000+ >>> you're >>> >> going to be out of luck. >>> >> >>> A common pitfall is that programmers accustomed to other techniques code >>> in their .profile, $ENV, .login, .cshrc, .bashrc, ... code to set and >>> export >>> DISPLAY, often based on parsing the output of a command such as "who am >>> i". >>> This code must be made conditional wherever it occurs (often in several >>> places) with a conditional construct such as: >>> >>> DISPLAY=${DISPLAY-`find-value-of-display`} export DISPLAY >>> >>> in order not to override the value correctly set by sshd. >>> >>> -- gil >>> >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to [email protected] with the message: INFO IBM-MAIN >>> >> >> >> >> -- >> The postings on this site are my own and don’t necessarily represent >> Mainline’s positions or opinions >> >> Mark D Pace >> Senior Systems Engineer >> Mainline Information Systems >> >> >> >> > > > -- > The postings on this site are my own and don’t necessarily represent > Mainline’s positions or opinions > > Mark D Pace > Senior Systems Engineer > Mainline Information Systems > > > > -- The postings on this site are my own and don’t necessarily represent Mainline’s positions or opinions Mark D Pace Senior Systems Engineer Mainline Information Systems ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
