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

---

In my previous post I described how to get GDM acting as an XDMCP server by creating a suitable configuration file and restarting GDM. I also mentioned a workaround to let you connect to an XDMCP server even from a Live CD with no internet connection. Hopefully that was enough to get you out of a bind if you were desperately looking for a solution to Gnome’s removal of the XDMCP login option from GDM.

In this post I’m going to describe some other methods for connecting to an XDMCP server, though they all have the disadvantage of requiring additional software to be downloaded. I’ll also mention a workaround for the lack of the host chooser that used to appear when using GDM to start an XDMCP session. I’ll start with reiterating the no-download method of making a connection though – although it’s covered in my previous post, it doesn’t hurt to have all the client options on a single page.

xinit

This is the only option here that doesn’t require additional software to be installed, and as such it’s useful when you want to use a Live CD to create a temporary thin client. From within a terminal, type:

sudo xinit -- :1 -broadcast

If there is more than one XDMCP server on your network, replace “-broadcast” with “-query” followed by the IP address of the server – so you end up with something like this:

sudo xinit -- :1 -query 192.168.0.100

This should start a new X server and present you with a login screen on the remote server. You can switch back to the local X server using CTRL-ALT-F7, then back to the new one using CTRL-ALT-F8 (or F9 or something similar).

When you log out the server will spawn a new login screen – which is great if your temporary thin terminal might be used by several people. If you just want the X server to stop when you log out, append “-once” to the end of the command line.

Xnest

The most common “workaround” for the loss of the XDMCP login option that I’ve seen suggested is to “install Xnest and use tsclient”, so I’ll deal with this approach next.

Xnest is a “nested X server”. What does that mean? It means that it’s an X server, but it’s also an X client. It runs as a client application in one X server (your normal desktop), but it acts as an X server itself. It’s one X server nested inside another. In real terms it means that you can run an XDMCP session to another machine within a window on your normal dekstop.

It doesn’t ship on the Ubuntu desktop CD, so you need to install it using Synaptic, apt, aptitude or whatever other package manager you prefer. The package name is “xnest”, and if you’re reading this using Firefox on the Karmic machine you want to use, you should be able to install it by clicking on the link below and letting it open with “apturl” (which should be the default option anyway):

apt://xnest

I’m going to discuss two ways to run Xnest – from the command line, or via the Terminal Services Client. The latter actually just provides a GUI for the former, but if you prefer point-and-click, have trouble remembering command line options, or want to store your settings for later use, it can be handy.

The basic command line syntax for Xnest is very similar to that of the “xinit” solution above. To connect to a specified server, killing Xnest when you log out, you can get away with the following:

Xnest :1 -query 192.168.0.100 -once

“-broadcast” also works, as does omitting “-once” for a persistent login screen. By default Xnest will open a window that is 3/4 of the size of your desktop. Often this is good enough, and there’s no need to specify the Xnest window size any further, but if you need to specify the window size you can add “-geometry 1024×768” (swapping the numbers for whatever width and height you want). There is no full-screen option.

Once Xnest is installed it automatically becomes available as an option in the Terminal Services Client. There is a Gnome panel applet for accessing this – but it crashes every time I try to add it to the panel in my Karmic virtual machine or via a Live CD. Otherwise you can run it from a terminal, or by pressing ALT-F2 then typing:

tsclient

However you launch it, you should end up with a screen similar to the one below. Simply select “XDMCP” from the “Protocol:” dropdown, and enter the address of your server in the “Computer:” text box. You can leave the other fields blank, and optionally change the settings on the other tabs. Note that not all the settings will have an effect – for example, although you can select the screen size on the “Display” tab, the full screen option doesn’t work. Once you’ve set the parameters the way you want them, use the buttons at the bottom to save (or load) them for future use – or just click the “Connect” button to get going immediately:

One thing to note is that Xnest is an old application, and the X server it exposes doesn’t support many of the newer X extensions. For most applications this isn’t a problem, but some may run slowly as they fall back to alternative code, and some may not work at all if they require things like 3D compositing. As noted in my previous post, the Netbook Launcher on the Ubuntu Netbook Remix falls into this category.

Xephyr

Xephyr is also a nested X server, much like Xnest. Xephyr, however, is a much more recent development, and supports most modern X extensions. Note that “supports” means “it runs”, not necessarily “it runs well”. Although it might let you run software which otherwise wouldn’t work at all via Xnest, you may find that the performance is so bad as to render that benefit moot. Give it a try, though – sometimes it’s a better choice than Xnest if only because of the broader range of command line options it supports.

Xephyr is in the Ubuntu repositories as “xserver-xephyr”, or you can click on the link below:

apt://xserver-xephyr

At the simplest level launching Xephyr is almost identical to launching Xnest:

Xephyr :1 -query 192.168.0.100 -once

Again “-broadcast” also works. Unfortunately the default screen size for Xephyr is somewhat on the small side, so you’ll probably want to add the “-screen 1024×768” parameter (replace with your preferred width and height, note that although the syntax is the same, Xephyr uses “-screen” to Xnest’s “-geometry”). Xephyr also has a full screen option, using the “-fullscreen” parameter.

That should be enough to get you going with Xephyr, but if you do want to tweak or adjust it further check the man page (“man Xephyr”) – there are far more options than are available with Xnest.

KDM

One suggestion made in the comments to my previous post was to install KDM as a login manager, as it still has support for XDMCP logins. If you really want to be able to connect to an XDMCP server from the login screen, then this might be a viable option. Note, however, that installing KDM on a vanilla Ubuntu installation will also drag along with it 50 other packages totalling about 60MB to download and nearly 190MB when decompressed. That’s a lot of baggage just to regain one option on the login screen!

If you decide to go down this route then you’ll find the option on the power menu. The item you want is “Remote Login”, or just press ALT-R (ALT-L will return you to the local login screen). Don’t get tempted by the “Secure Remote Connection” in the session menu – that’s won’t get you an XDMCP connection. You can see the power menu in this screenshot, using the default theme that KDM installs with:

When you do want to login locally, make sure you choose something in the session menu (you probably want GNOME if you’ve just installed KDM on a stock Ubuntu machine), otherwise you can end up with a minimal X session which probably isn’t what you want (if you do end up there, just log out of the terminal by pressing CTRL-D or typing “logout”).

Unlike the other options here, KDM does display a host chooser, much like the old GDM did. If you frequently have to connect to several different XDMCP servers, this feature alone might swing your choice.

GDM 2.20

It seems like an obvious option: The features we want were present in GDM 2.20; GDM 2.20 is in the Ubuntu repositories; surely it’s a no-brainer – just install GDM 2.20 and all our problems will go away.

Unfortunately life’s rarely that simple. Installing GDM 2.20 resulted in my machine becoming unable to start X at all. I suspect that it was the lack of a suitable config file that was to blame, but that would have taken more than five minutes to fix. Given that there are other solutions here that can be made to work in less than five minutes, diagnosing issues on a legacy version of GDM didn’t seem like a great use of my time.

And even if it had worked first time, there’s still that word “legacy”. Sure, I may not like the removal of some useful features from GDM, but reverting back to an older version doesn’t strike me as a practical answer to the solution either. With each new release my installation would become increasingly anachronistic. No, better to work with what solutions I do have available, rather than stick my head in the sand and pretend that nothing’s changed.

Of course, if you want to try playing with GDM 2.20, I’d be more than happy for you to comment about your experiences here. If you do go off experimenting and get stuck at a command line, unable to start X, “sudo aptitude install gdm” (or kdm) will probably get you going again. Unless you’ve really screwed things up, in which case you’re on your own, kid.

Conclusion

There you have it, four different ways of making an XDMCP connection, and one way that sounds like it should work, but doesn’t (or at least not trivially). Which approach you choose will depend on what your particular requirements are, but there’s nothing to stop you trying any or all of them – it’s not like you’re being charged for the privilege 🙂