Exporting my xsession is this close to working out.

March 6, 2008 8:37 AM

I'm wondering if anyone knows how I might resolve an issue with exporting my X session to a Windows box over SSH. It . . . sort of works, but the vital parts of this particular GUI aren't visible, and I think I've tried every Windows X server known to man.

I'm trying to get a new backup system, BakBone NetVault, production-ready. I like everything about it except for the fact that there isn't a locally-installable management client. In order to manage the server, you have to either use the CLI or invoke the GUI, so if you are remotely accessing the server via an ssh session and have ssh set to ForwardX11, you do an 'nvgui&' and your management window pops up and everything is lovely--at least when I'm accessing the server (which is running RHEL 5) from another Linux box (my workstation is Ubuntu, but it seems to work with most distributions I've tried).

However, if I try to do the same thing from a Windows box running an X server, there is no happiness. I've tried MKS X Server, Hummingbird Exceed, Xming, and Xming-mesa, and in every case the core application windows will come up successfully, but sub-windows where detail would normally appear remain totally unpopulated--I bring up the Media Management tools, for example, and the proper window appears, but there's no list of media. There are some screenshots on this page that might give a clearer idea of what the window should look like. Basically everything in the white areas in those screenshots is absent no matter what X server I'm running on my remote Windows machine.

It wouldn't be a big issue, but I know that some of the admins who will be maintaining this installation once it goes fully into production run Windows exclusively. In addition, I can't take full advantage of NetVault's support when they offer WebEx sessions for troubleshooting given WebEx/Ubuntu/Firefox/IEs4Linux problems . . . which is another question for another day, but means I will occasionally need to access the application from a Windows machine. I already run VMWare (and have coLinux downloaded and ready to go as another option) but would prefer a simpler solution such as Xming-PuTTY because I don't feel good about expecting the other admins to jump through that many hoops just to administer one little thing out of many.

I'm not really so hopeful as to think anyone here has tackled this exact problem with this particular application. But does anyone have experience with exporting X sessions who might know what would cause these or similar symptoms? Is there another work-around I haven't considered? I'm open to trying other ways of doing this.

Thanks for your help if you've managed to hang in there this long. :) If I need to provide more information just let me know.

posted by littlegreenlights to computers & internet (11 comments total)

Do you need to forward X, or can you use VNC? tunneling VNC over SSH works pretty well for me, but I'm just one guy using it to manage one machine at home.
posted by ArgentCorvid at 8:51 AM on March 6, 2008

Well, I've tried NoMachine, and it would be ideal because everyone already has it and it's easy to tie down security-wise, but for some reason the NetVault GUI won't appear at all when I'm NoMachine'd in to the server--there's a flicker in the corner of the screen and that's it. No error messages appear in the terminal, and the processes are still running, but no eye candy.
posted by littlegreenlights at 9:10 AM on March 6, 2008

The ssh client has two options for X11 forwarding:

-X = Enable X11 forwarding
-Y = Enable trusted X11 forwarding

Have you tried -Y instead of -X? This has fixed problems for me in the past.
posted by qxntpqbbbqxl at 9:32 AM on March 6, 2008

Good suggestions so far. Your list of X servers doesn't include cygwin which is worth a shot. You might also try andLinux which is more of a pile driver solution but I think that relies on xming so it might not be any different.

As it's windows, it might be wise to update the video drivers and try different screen depths. While I'm reaching at straws, that's how I usually fix Windows problems.
posted by chairface at 9:47 AM on March 6, 2008

also, a last resort -- connect via Linux on a virtual machine. This is possibly not as bad as it sounds; maybe there's an existing VMware appliance that will do the job?
posted by qxntpqbbbqxl at 10:06 AM on March 6, 2008

Seconding the use of VNC.
posted by zsazsa at 10:21 AM on March 6, 2008

Wow, you guys have given me a lot of suggestions to work with. :) I'm busy trying things out but should be able to update in a little bit. I should have mentioned that I'd tried Cygwin/X with similar results, so that one's out, but the trusted X11 forwarding definitely looks like it's worth a try.

Does anyone know of a Windows ssh client that has an option for trusted X11 forwarding? PuTTY doesn't seem to be capable of it, and it doesn't seem as though SecureCRT is, either, though I could be wrong as I didn't go through with a trial download of the software. I'll also give VNC a shot (we used to use VNC a lot but kind of tapered off when a vulnerability made us mostly switch over to NoMachine) and look into chairface's suggestion of andLinux.

I do have a ticket in with BakBone's TAC, and they've suggested I change a shared memory setting that supposedly has been known to futz with GUI performance, so I'll also be trying that to see if it works . . . though I admit I'm skeptical. :)

Thanks for all the help so far!
posted by littlegreenlights at 11:58 AM on March 6, 2008

Does anyone know of a Windows ssh client that has an option for trusted X11 forwarding?

Well Cygwin OpenSSH does. But if your client has no option for trusted, it probably is all trusted (which is bad).

You have been doing all of this testing of different X servers, but keeping the SSH part the same, so you might try changing that now.

we used to use VNC a lot but kind of tapered off when a vulnerability made us mostly switch

You probably already know this, but you should not consider VNC to be secure. Only run it through a secure tunnel.
posted by grouse at 12:26 PM on March 6, 2008

Well, this kind of stinks. Changing the shared memory settings didn't change anything. I set up VNC over ssh (vnc-server package for RHEL5 on the server plus RealVNC on the Windows viewer) but am still seeing the same strange mixed results.

I missed chairface's Windows video settings/driver suggestion, so I'm going to give that a try, and I still haven't tried andLinux.

I'm thinking grouse might be on to something in thinking that I need to change the SSH part. I'm getting the same results from Cygwin/X and PuTTY, but I'm sure there are some other clients I can try.

If anyone else has any ideas, feel free to throw them out there--I was flummoxed when VNC didn't do the trick. I tried running straces in working and non-working scenarios to see what might be different, but nothing stands out. I'm no guru, though, so I could easily have missed something. Is there any other diagnostic that might be worthwhile?

Thanks again for all your help!
posted by littlegreenlights at 2:35 PM on March 6, 2008

If you get identical bad results on VNC, then the problem basically can't be because of anything you have set up on Windows. There must be some configuration change on the Linux box when you log in remotely.

Do you use GNOME? Set up Vino and leave yourself logged in on the workstation, then VNC over from the Windows box. It's hard to see how that wouldn't work.

There may be a change in your environment. Try using set > config-local from your workstation and set > config-remote from remote. Then diff -u config-{local,remote}. If you can't figure it out, post the results here (or use Pastebin to paste them).
posted by grouse at 3:02 PM on March 6, 2008

Rather than vnc-server, try x11vnc. x11vnc lets you control the active X11 session, rather than creating a new X server for VNC use. If you wanted to, you could even use x11vnc on your ubuntu workstation, since you know it works there.
posted by fengshui at 4:33 PM on March 6, 2008