Friday, February 03, 2006

Exporting X Sessions

This is one of those tasks that I want to remember for the future, because I can imagine encountering the same problem again. When I build servers with FreeBSD, I usually do not include packages for X.org. I access my servers using OpenSSH so I don't need any graphics support.

Recently I needed a platform to QEMU. It turns out that QEMU opens an X session. The system where I wanted to run QEMU was a remote server (janney), so I needed to add X support. I figured "If I can export an xterm, I can export QEMU." So, I added the xterm package. Here are Xterm's dependencies as reported by pkg_tree:

janney:/home/richard$ pkg_tree xterm
xterm-203
|\__ pkgconfig-0.17.2
|\__ freetype2-2.1.10_1
|\__ expat-1.95.8_3
|\__ fontconfig-2.2.3,1
|\__ xorg-libraries-6.8.2
\__ libXft-2.1.7

So, you can see that installing Xterm added the following X.org package:

xorg-libraries-6.8.2 X11 libraries and headers from X.Org

So, I ssh to janney, using the -X option to enable X forwarding, and I get this error.

orr:/home/richard$ ssh -X janney -v
OpenSSH_4.2p1 FreeBSD-20050903, OpenSSL 0.9.7e-p1 25 Oct 2004
...edited...
debug1: Next authentication method: keyboard-interactive
Password:
debug1: Authentication succeeded (keyboard-interactive).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
Warning: No xauth data; using fake authentication data for X11 forwarding.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Remote: No xauth program; cannot forward with spoofing.

That doesn't look good. Here's what happened when I tried to export an xterm.

janney:/home/richard$ xterm
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from ::1 59764
connect 127.0.0.1 port 6000: Connection refused
debug1: failure x11
X connection to localhost:10.0 broken (explicit kill or server shutdown).

Notice the connection attempt to port 6000 TCP. I knew that wasn't right, either. When forwarding X connections, OpenSSH connects to port 6010 TCP.

I figured I needed to add xauth, and that auth was part of the xorg-clients package. I added xuath as a package, and saw this pass by on the screen:

janney:/root# pkg_add -vr xorg-clients
...edited...
x bin/xauth
...truncated...

The next time I tried connecting to janney using ssh -X, I got these results:

orr:/home/richard$ ssh -X janney -v
...edited...
debug1: Entering interactive session.
Warning: No xauth data; using fake authentication data for X11 forwarding.
debug1: Requesting X11 forwarding with authentication spoofing.

That's better. Now I can see port 6010 TCP listening, and I can export an Xterm, too:

janney:/home/richard$ sockstat -4 | grep sshd
richard sshd 19911 3 tcp4 192.168.2.7:22 192.168.2.5:51330
richard sshd 19911 8 tcp4 127.0.0.1:6010 *:*
root sshd 19908 3 tcp4 192.168.2.7:22 192.168.2.5:51330
root sshd 19858 4 tcp4 *:22 *:*

janney:/home/richard$ xterm
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from ::1 49825
debug1: channel 1: new [x11]
debug1: confirm x11

You'll remember I wanted to export a QEMU window. I tried doing so:

janney:/home/richard$ qemu -hda freedos.dsk -boot c
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from ::1 57479
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: channel 1: FORCE input drain
debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384
debug1: client_request_x11: request from ::1 57480
debug1: channel 2: new [x11]
debug1: confirm x11
debug1: channel 1: free: x11, nchannels 3
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from ::1 57481
debug1: channel 1: new [x11]
debug1: confirm x11
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 25 (X_SendEvent)
Resource id in failed request: 0x40
Serial number of failed request: 12
Current serial number in output stream: 17
debug1: channel 1: FORCE input drain
debug1: channel 2: FORCE input drain
debug1: channel 1: free: x11, nchannels 3
debug1: channel 2: free: x11, nchannels 2

And nothing happens. That is lousy. It turns out I needed to use the -Y switch instead of -X. -Y "Enables trusted X11 forwarding," which I found using the ssh man page. I figured I would try it.

orr:/home/richard$ ssh -Y janney -v
...connects to janney...
janney:/home/richard$ qemu -hda freedos.dsk -boot c
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from ::1 57482
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: channel 1: FORCE input drain
debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384
debug1: client_request_x11: request from ::1 57483
debug1: channel 2: new [x11]
debug1: confirm x11
debug1: channel 1: free: x11, nchannels 3
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from ::1 57484
debug1: channel 1: new [x11]
debug1: confirm x11

And it works.

The bottom line is that exporting X sessions needs the xorg-libraries and xorg-clients packages. Sometimes you have to use -Y instead of -X.

3 comments:

Jeff Cross said...

Hey, Richard.

Something similar you may want to check out (if you haven't already) is FreeNX. FreeNX will export your whole X Windows session, not just X applications, to a remote client (currently only Windows, Mac OSX, Linux and Solaris, but I am very close to getting the Linux client installed on FreeBSD... or so it seems). There is a FreeNX port for FreeBSD so it is pretty easy to install and configure.

The sessions are extremely fast and responsive. It's almost like using Remote Desktop connections (RDP) between Windows clients and servers.

I blogged about it yesterday and you can read the post here if you're interested. I don't think you'll really gain anything over what you're doing already, other than the ability to have a whole separate remote X Windows session going instead of a single application, but it may be worth a look.

Jeff

Anonymous said...

The port (probably the package too) xorg-clients is now xorg-apps

█▓▒░ H3g3m0n ░▒▓█ said...

qemu has built in support for the VNC protocol, that allows you to just start qemu on the remote system and then connect to it using a vncviewer. Just ass -vnc # to your qemu commandline then use vncviewer :#. You need access to port 590#.

You can also keep it running by starting it using nohup or within a screen session so when you close the client side of things the server side keeps running.