Other posts in this series:
- Pt. I – Enabling GDM as an XDMCP server
- Pt. II – Four XDMCP client options for Ubuntu 9.10
- Pt. III – Three ways to use the host chooser
- Pt. IV – Alternatives to XDMCP
If you’re affected by this issue, please also take a look at this post:
XDMCP support in Ubuntu: make your voice heard
Okay, that’s enough about how to get XDMCP working in Karmic. If you really, really, specifically, definitely want XDMCP support, then have a read of the previous posts. If, however, you just want a remote connection between two Ubuntu machines, then there are alternative solutions that you might want to consider.
Before abandoning XDMCP entirely, let’s just have a quick look at the pros and cons of the protocol – as it was implemented in Jaunty (i.e. back when it worked and everyone was happy). That will make it easier to compare with the other systems I’ll be describing below.
Pros
- Already built into the X server – no need to install anything, even on a live CD
- Easy to enable the server end via the GUI
- Easy to connect from the client end, even without a local login on the client machine
Cons
- High bandwidth required
- Security is poor
- Only cross-platform in one direction (Windows or MacOS can only be clients, not servers)
When it comes to remote access there are loads of alternatives available. I’m only going to consider a few of them. If none of these seem to suit your needs, please keep looking because there might be something else that does. With that, let’s start with that king of remote connections, OpenSSH.
OpenSSH
OpenSSH is a veritable toolkit of remote connectivity. In its simplest incarnation (ssh username@host) you get a command line running on the remote machine, and it can also be used to transfer files (scp and sftp). Those features alone can often be a viable replacement for a full remote desktop, if you know how to drive the command line. But it’s the transparent tunnelling of X data that interests us here.
Add the -X option to your ssh command and, assuming your server allows it, you can now run a graphical application from your ssh shell and have it displayed on your local machine. Note that it’s a capital X, a lower case x disables the option, and the default configuration of the OpenSSH server in Ubuntu will allow X forwarding. Ubuntu comes with the OpenSSH client by default, but you’ll need to install the server using your package manger of choice (it’s called “openssh-server”).
So, we’ve got our OpenSSH server installed on a machine called “karmic.localdomain”, and we want to run an application on that machine, but displaying on the local machine. If it’s just a one-shot command, you can do something like this:
ssh -X johndoe@karmic.localdomain xclock
As if by magic, Xclock appears on your local display, and when you close it your ssh connection is closed as well. I suppose Xclock might be handy if the server’s in a different timezone, but in practice you’re more likely to want something useful launched – perhaps Nautilus:
ssh -X johndoe@karmic.localdomain "nautilus --no-desktop"
It’s still some way from an XDMCP replacement though. It would be better if you could launch multiple applications, right? Well, just connect without specifying an application to run, then run it from the command line:
ssh -X johndoe@karmic.localdomain
karmic> nautilus --no-desktop &
karmic> xclock &
karmic>
Note the trailing ampersands – that’s standard command line usage from way back when, which causes the process to run in the background, so you get a prompt back and can launch something else. If you forget an ampersand (or want to see the console output during the application’s startup), you can press CTRL-Z to suspend the process, then run “bg” to resume it in the background. A basic grounding in Unix command-line job control is worthwhile if you use ssh a lot. I also recommend running “screen” as your first application, if it’s installed – a worthwhile addition to any command line junkie’s toolkit, but not something I will be going into any more detail about here.
The ability to launch individual GUI apps might make SSH a viable alternative to XDMCP in some situations, but often you just can’t get away from the fact that a full desktop is easier to use. You might be tempted to run “gnome-session” from your SSH command line, but that way madness lies. Trying to run a full desktop like that will work to a degree, but will also clash with your local desktop and can really screw it up when you log out of the remote session.
If you really need a full desktop connection, and really want to run it over SSH yourself, you can use OpenSSH’s ability to tunnel arbitrary TCP data to forward a VNC connection. You can’t do the same with an XDMCP connection, as that uses UDP not TCP, and OpenSSH can’t forward that in the same way. It is possible to set up a full VPN via SSH which will work, but is usually more hassle than it’s worth. A sneaky workaround is just to SSH into your remote machine, then run Xnest or Xephyr at the remote command line. Because these are both X clients, they will appear on your local desktop just like Xclock did. But they’re also X servers, so you can use them to make a connection to an XDMCP server that would otherwise be out of reach.
VNC
When talking about remote desktop connections, VNC is the first thing that will spring to the mind of many computer veterans. VNC was originally written to allow a user to make a remote connection to a Unix desktop. In that sense it is similar to XDMCP, but with one significant difference: disconnecting from an XDMCP session would kill the desktop and any applications running in it, whereas disconnecting from a VNC session would simply close the viewing application while leaving the desktop running “headless” on the server. This meant that it was possible to disconnect a VNC session on one machine then re-connect to it later, or from a different machine.
Some time later VNC was ported to Windows. Because most versions of Windows don’t support multiple users being logged-in and using a machine simultaneously, the Windows implementation of VNC shares the currently logged-in desktop with the viewer, rather than creating a new desktop. It quickly became clear that for some purposes this was actually better than the Unix approach – especially if you want to share someone’s desktop for support or training purposes.
Because of the advantages of being able to connect to a currently logged-in desktop, it wasn’t long before this same functionality was ported back across to Linux – in addition to the original Unix VNC server that could be used. Meanwhile extensions were made to the VNC protocol to support better compression algorithms or additional features, with the result that there are now a variety of different VNC servers and clients across all the major (and several minor) operating systems. I’m going to describe a few of them below, but there are many others, each with their own advantages and disadvantages, so if you don’t find one that suits you below try googling or searching in your package manager to see what other options are available.
Vino
If you want the Windows-style of VNC server, whereby the currently logged in desktop is shared over the network, then you’ll be pleased to know that it’s built into GNOME (and hence into a stock Ubuntu installation) by default. The server is called “Vino”, but in practice the name is irrelevant as you can just enable or disable it via System=>Preferences=>Remote Desktop.
There’s a counterpart to Vino, and that’s a VNC viewer called “Vinaigre” – though again, in practice, the name is irrelevant as you access it via Applications=>Internet=>Remote Desktop Viewer. Vinaigre isn’t tied specifically to Vino – it’s a general purpose VNC viewer which can be used with just about any VNC server, so it’s worth knowing about if you need to share a Windows or MacOS desktop and view it on a Ubuntu box. And it’s a whole lot more modern-looking than the old “vncviewer” application.
vnc4server
What if you don’t want to share a logged-in desktop, but want a completely different session to be available over VNC? That’s where “vnc4server” comes in. You’ll need to install it using the package manager of your choosing as a starting point. What you do with it next depends on your needs, but in any case it will involve running it on the remote machine as the user of your choice. For this example we’re going to pretend that there is a remote machine with an IP of 192.168.0.2, and your local machine with an IP of 192.168.0.3.
1) At the remote machine make sure you are not logged into the GNOME desktop. Press CTRL-ALT-F1 to get to a console, and log in. In practice you might find it easier to ssh into the remote machine instead, depending on how remote “remote” actually is.
2) At the console, run “vnc4server”. You will be prompted to create a password the first time you run it, which you can subsequently change using “vnc4passwd” if you need to.
3) You should get a few lines printed on the screen, amongst which is the address of the new VNC connection you’ve just started – in our case it will say something like “your-machine-name:1″, but I prefer to use IP addresses to avoid any name resolution issues, so we’ll access it as “192.168.0.2:1″.
4) On the local machine, launch a VNC viewer. Because it’s already installed on a stock Ubuntu system, I would use Vinaigre (Applications=>Internet=>Remote Desktop Viewer) as a starting point. Create a new connection, and put in the VNC server’s address (192.168.0.2:1 in our case). The :1 refers to the first VNC server running on the machine, which operates on port 5901 by default.
5) Enter your VNC password when prompted
6) Sigh with disappointment as you see this screen:
The default vnc4server desktop. Hmm...
Not great, eh? Let’s try to improve matters by getting to an actual working GNOME desktop…
1) Close your local VNC viewer. On the remote machine we want to stop the vnc4server that’s running, so issue the following command
vnc4server -kill :1
2) The problem is that vnc4server starts the applications specified in the ~/.vnc/xstartup file – and because this file didn’t exist the first time you ran the server, it created it and populated it with some pretty useless defaults. Let’s take a look at this file:
#!/bin/sh
# Uncomment the following two lines for normal desktop:
# unset SESSION_MANAGER
# exec /etc/X11/xinit/xinitrc
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
twm &
You might be tempted by the section that says “Uncomment the following two lines for normal desktop”… but you probably won’t end up with the “normal desktop” you were expecting:
This is not the desktop you were looking for...
Instead try editing the file to look like this (hint: as you’re at the command line, use “nano -w .vnc/xstartup” if you’re not already a vi or emacs fiend):
#!/bin/sh
unset SESSION_MANAGER
exec gnome-session &
3) Now start the VNC server again (“vnc4server”), and connect using your VNC client:
At last, a real desktop
Okay, time for the bad news. First, this doesn’t play nicely with an already logged-in GNOME desktop, so whilst it’s good for headless servers or a machine on which you’re the sole user, it’s not so good for multiple users on a desktop machine which might have a user logged in directly on it. Second, don’t log out of your GNOME session if you want to come back to it later – just quit the VNC viewer. If you log out, it doesn’t respawn, and you’ll need to kill then restart the VNC server.
Now for the good news. You can run more than one VNC server on a machine – they’ll end up as screen :1, :2 and so on. Useful if you want to share a single server with multiple users. You can also run the server from a startup script if you don’t want to ssh in to start the server all the time – but I’ll leave that as an exercise for the reader (hint: this article is a good starting point).
Gitso
While I’m on the subject of VNC and its use, Windows-style, as a support tool it would be remiss of me not to mention Gitso (an awful recursive acronym for “Gitso Is To Support Others”!).
It’s a VNC server/viewer packaged up via a simple UI and preconfigured to make a reverse VNC connection from the server to the viewer. What this means, in practice, is that a non-techie user seeking support can run the application and type in an address given to them by the person offering support. The support person runs the application, and a VNC connection is set up such that they can see and control the user’s desktop.
There is some firewall configuration that will generally be needed, but by using a reverse VNC connection all of that is pushed off to the techie end of the line where, hopefully, the support person will know what they’re doing and be able to forward the necessary port.
Because it uses VNC it’s cross-platform, allowing you to support (and be supported) on Linux, Windows or MacOS. It’s not in the standard Ubuntu repositories, but you can download a suitable .deb package file from their website:
http://code.google.com/p/gitso/
Empathy. Or not. Or perhaps maybe.
One of the biggest issues with providing some sort of remote desktop access for support purposes is actually getting a safe connection from one machine to another. Typically most users are behind some sort of firewall or NAT, even if they don’t realise it, meaning that tunnelling a remote desktop connection becomes an exercise in port-forwarding and TCP/IP. There are numerous commercial operations who make a lot of money out of making remote desktop access easy without having to change firewall settings by having relay servers which are accessible to both ends of the connection.
As an example of this issue, Gitso (described above) requires the “techie” user to open port 5500 so that the supported user doesn’t have to. But what if there was already a near-instant communication channel between the two endpoints? Wouldn’t it be possible to use that as a tunnel for the data, with no need to go poking around in router settings? How about this Empathy instant-messaging software I’ve already got? Wouldn’t that do the trick?
The answer, in theory, is “yes”. Throughout a large period of the Karmic beta test the answer was, in practice, “yes”. Then Karmic was released… and the answer was “no”.
According to one of the comments in this bug report, the problem was a change in the terminology used to identify the remote desktop protocol, which put Empathy out of synch with Vinagre. That bug report also suggests that the problem is now solved… so I tried it, using a netbook running Karmic UNR and a desktop machine running a full version of Karmic. Both had all updates applied, and the two instances of Empathy were working fine when sending instant messages between the two GTalk accounts I was using for this test. But no matter what I tried, I couldn’t get the “Share my desktop” option to work.
Hence the title of this section. It apparently did work. Then it definitely stopped working. Then it apparently worked again, but not for me. If you need to provide remote support to another Ubuntu user, it might be worth a try – but if it’s important you should probably set up Gitso as well, just in case.
NX, and any others I’ve missed
This post is already way overdue, so I’m going to stop my experiments now and actually post the damned thing. One technology that I had planned to cover, and haven’t got round to trying, is “NX”, so I’ll give it a brief honourable mention in case you want to investigate it on your own, or have any experience with it that you want to share in the comments.
NX is a technology that takes the best bits of the X protocol, thins it out to reduce bandwidth, tunnels it over an SSH connection, and caches it heavily at the client end to reduce bandwidth even further. It’s not as cross-platform as VNC, nor as secure as SSH alone (due to its default use of well-known encryption keys), but as an alternative to XDMCP – especially over a slow internet connection – it’s well worth considering. You can find out more about it from the Wikipedia page about the technology itself, and from this Ubuntu Wiki page about installing it on Karmic.
There are other approaches and technologies that I haven’t even mentioned here, so if you’ve got any experience, good or bad, with any other remote desktop software please leave a comment for the benefit of everyone else. Personally I’m going to muddle along with XDMCP and Xephyr for intranet connections, and Gitso for remote support, whilst hoping that the built-in XDMCP support returns in Lucid, or that something comes along to fill its space that doesn’t need additional software installing on a Live CD.
Other posts in this series:
Pt. I - Enabling GDM as an XDMCP server
Pt. II - Four XDMCP client options for Ubuntu 9.10
Pt. III - Three ways to use the host chooser
Pt. IV - Alternatives to XDMCP
If you're affected by this issue, please also take a look at this post:
XDMCP support in Ubuntu: make your voice heard
Okay, that's enough about how to get XDMCP working in Karmic. If you really, really, specifically, definitely want XDMCP support, then have a read of the previous posts. If, however, you just want a remote connection between two Ubuntu machines, then there are alternative solutions that you might want to consider.
Before abandoning XDMCP entirely, let's just have a quick look at the pros and cons of the protocol - as it was implemented in Jaunty (i.e. back when it worked and everyone was happy). That will make it easier to compare with the other systems I'll be describing below.
Pros
Already built into the X server - no need to install anything, even on a live CD
Eas
