Peter's Blog

My previous dabbling with xming gave me a way to run remote X applications and have them open windows on my vista desktop. It worked for simple stuff like xterm but for more advanced things like krusader it crashed and burned. So how about having a complete remote desktop open on my vista box, something like vnc but faster? X is supposed to be about this kind of thing, the graphical display being a terminal.

xming supports something called the XDMCP protocol for connecting to remote X servers (my terminology may be all wrong) so how to get that going?

The steps below are for kde, using kdm as a login manager and work with kubuntu.

Firstly, enable XDMCP in /etc/kde3/kdm/kdmrc:

[Xdmcp]
# Whether KDM should listen to incoming XDMCP requests.
# Default is true
# pcw
Enable=true

Next make sure the following line in /etc/kde3/kdm/kdmrc is commented out:

#ServerArgsLocal=-nolisten tcp

Next, go into /etc/kde3/kdm/Xaccess and make sure it has something like this in it:

*                                       #any host can get a login window

#pcw: this stops it listening on ipv6 (?)
LISTEN 0.0.0.0

The ipv6 thing is an old bug. If kdm is listening on ipv6 instead of ipv4 then the following command will give the output shown:

sudo netstat -apn | grep ":177 "
udp6 0 0 :::177 :::* 5636/kdm

Next I had to add an entry into /etc/hosts to allow the pc I was connecting from to pass a reverse dns lookup or kdm wouldn't let it in:

192.168.0.32    any-bleeding-thing-will-do

Finally I had to uninstall andlinux from my desktop because the tap/tun driver that it installed was causing xming to ask the remote linux box to connect to the display 192.168.11.1:0 which did not exist on the network, only virtually inside my desktop. This was evinced by the following in the syslog of the remote box:

Jul 31 10:21:10 mybox kdm[5088]: Display 192.168.11.1:0 cannot be opened

After this the xming xlanuch utility can be used to open the desktop with default options apart from:

• use 'One Window'
• 'Open session via XDMCP
• Connect to host = ip address/name of server

This should open a nice big window, as big as your screen with its own kde login prompt. It runs kde4.1 fine, including the kidney in the top right corner. The screen doesn't 'capture' the mouse and I can copy and paste stuff between it and windows.

All this took far too long to figure out (wireshark is my new friend) and by all accounts it is too insecure to trust without a firewall between you and the real world but it is giving me a kde4 desktop that is just as snappy as if I went to the effort of wheeling my chair across to the other side of the room.

It took me some time to learn to spell xdmcp in all my googling until I realised that it can be broken down into xdm-cp and xdm is a more primitive form of kdm/gdm. Googling for xdcmp gives a surprising number of relevant hits.

One remaining oddity: firefox doesn't run. Konqueror does.

UPDATE: it's alarming that an hour after writing this it is coming up in the google results for "xdmcp firefox" so I'd better keep it updated. Firefox does start, it just takes two or three minutes to come up! Coffee time. Netbeans gives a blank white screen. This whole business is a can of worms.

UPDATE2: disabling the vista firewall allows firefox to run nicely. Enabling the firewall and opening ports 177 (udp) and 6000 (tcp) does not work. Running wireshark on a successful session does not reveal any other ports being used. Stumped and NOT running vista without a firewall (ffs). Netbeans still doesn't run. I'd give up only when it is running it runs sooo nicely, much better than vnc. Dragging a window seems to be done in a local terminal rather than downloading bits of screen to redraw over the wire. When it's running, scrolling a firefox page is seamless, you wouldn't know it wasn't running locally. There's gold in them thar hils but they're a long way away.

UPDATE3: after MUCH net tracing, firewall logging and messing about, the Firefox problem is definitely due to the sound activity on port 16001. Unblocking the port for TCP or UDP makes no difference, in fact unblocking ALL ports from a specific IP address doesn't work, there is something in the firewall that is straight broken. However, I found a workaround which is to put this in /etc/profile on the linux end:

declare -x ESPEAKER="127.0.0.1:16001"

it seems to force sounds to stay on the local server.

Xming is an X server for Windows. With it one can run linux applications on a remote linux box with the X user interface windows appearing on ones Windows desktop:

xming demo

Internet Explorer, xeyes and xterm in perfect harmony.

How to do this wonderous thing?

• install xming
• run xlaunch to fire up xming as your windows X server (should be added to quick launch), selecting the following options:
  • Multiple Windows (each app gets its own windows window)
  • Display Number 0
  • Start no Client (client is the program that runs)
  • No Access Control (I'm a trusting soul)
• you now have an X server on your windows box as display :0. An X server is something that displays the user interface for X client programs (X keeps you on your toes by using counter-intuitive terminology).
• open putty at the configuration of your favourite linux box.
• enable the X forwarding option:
  
  

  X forwarding in Putty

  the 127.0.0.1:0 means remote X clients will display on your new windows X server (:0) running on your pc (127.0.0.1)
• open the ssh connection in putty and enter a command such as xterm. Amazingly, an xterm window should open on your local pc! It's wonderous, xterm is running on the remote pc but the user interface is on your windows box.

Interestingly, the ssh session you open has a DISPLAY environment variable open that tells the X clients you launch from it where to stick their displays.

peter@server:~$ echo $DISPLAY
localhost:10.0
peter@server:~$

Through the miracle of ssh this is routed back to xming on the Windows box.

Now, how about if beyond your gateway ssh server is another ssh server and you want to run your X client applications on that? The answer is amazingly simple. Open the session on the gateway server as described above and then use the command:

ssh -X name-of-other-server

you now have a command prompt on the remote remote server and if you now run

xterm

then again you get a xterm display coming up on your local windows pc but this time from the remote^2 box.

UPDATE: troubleshooting

• may need this in /etc/ssh/sshd_config

  X11UseLocalhost yes
  

• may need to

  sudo apt-get install xauth
  

  I needed this on a previously x-less box where I had installed gitk to do some git study on a headless server box