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.
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.
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):
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:
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 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:
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.
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.
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.
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 🙂
I run support for a small company, most people work out of the office. From time to time they come in and can sit at a spare desk, use the Login via remote XDMCP and access a linux box where they do have an login account. So very disappointed at this regression. I have found the following:
– the host chooser does exist in Karmic and works (but you need to be logged in to get at it)
– I also found a reference in the gnome docs to chooser_button, but cant find the specific reference now. This appeared to be referred to in theme definition to enable the ‘Remote Login via XDMCP’. It needed to be included in an XML file that baffled me, I tried to compare the Hardy version to the Karmic one..
so I went back to google and found you. Thanks for you input on this.. it would be great to get that login option back.
I’m actually in the process of writing a third part to this series about the host chooser. In short, yes it is still there, so if all you need to do is scan the network to find serving hosts then running that will present you with a list from which you can get the IP of the server you want. You can then use that IP with a -query option to xinit, Xnest or Xephyr. Look out for the new post in a day or two – it’s got more information and a couple of other options you might want to consider.
Note that one of the regressions with the new GDM is that it no longer supports themeing via XML files, so the reference to a chooser_button probably isn’t worth pursuing any further, unfortunately.
I tried 3 approaches of the above.
xinit — :2 -query x.x.x.x
Xnest — :2 -query x.x.x.x
The first 2 options suite me from convenience point of view, but I cant use them because the client crashes after a few minutes because of some logging incompatability.
the kdm client doesnt crash, but i cant use it, seems like only one session can be logged in. is there a way to make KDM work in parallel, say local machine on tty7 and remote on tty9 like it was in 9.04?
the fact that they removed xdmcp support by default is really upsetting… it was a really great feature… even though insecure it was one of the fastest remote desktops. all they need to do is tunnel it through ssl (optionally) but they should really keep it as a feature!
I’ve not had any problems with xinit or Xnest myself, but perhaps I’ve just been lucky. I will point out that you don’t need the double hyphen in the Xnest command though: the double hyphen is used in X wrapper scripts to specify that the parameters to the wrapper have stopped, and any further parameters need to be passed down to the underlying X server. In this case Xnest is the underlying X server, so it gets all the parameters anyway. I doubt that’s the cause of your problems, but it might be worth trying it again just in case.
As for KDM, I’ve removed it from my machine now so can’t test this, but as far as I know you should be able to get a local and a remote session going at once as follows:
1) Use KDM to start the remote session on CTRL-ALT-F7
2) Press CTRL-ALT-F1 to get to a console screen and log in
3) Type “startx — :1” to launch a new local session on CTRL-ALT-F9
I wish I was as lucky to have xinit work fine… it would work best as a temporary fix. Xnest is abit slower. But both in a few minutes generate errors. Some encoding issues, or logging, can’t quite get it. I use russian keyboard layouts, but the crash happens without having to press any buttons.
as for kdm, i have already tried startx 😉 it will only run as root, and it doesn’t present a login screen – just logs me in right away as root into X, and there is no “Lock Screen” or “Swich User” options to jump from there to login manager.
I’ve done some further testing between a fresh installation of Ubuntu 9.10 on a desktop machine and UNR 9.10 on a Dell Mini 9, and found the following results:
1) With UNR as the server, Ubuntu as the client
* xinit – Fails after a few minutes. /var/log/syslog on UNR seems to indicate that the problem is with the Netbook Launcher and one of the openGL libs
* Xnest – Fails immediately after logging in
* Xephyr – Works perfectly
2) With Ubuntu as the server, UNR as the client
* xinit – Logs in and appears to work, except that the UI is inverted. It’s rather odd – the menus, text, even the desktop image, are all upside-down, but they respond to clicks as though they are in their normal positions and orientation. I need to investigate this further, to see if it occurs when connecting from a “proper” Ubuntu installation, rather than UNR on a small display
* Xnest – Works perfectly, but doesn’t display the Netbook Launcher. ALT-F2 can be used to launch apps
* Xephyr – Works perfectly. It’s slow to display the fading transitions in the Netbook Launcher, but is otherwise quite usable
So it looks like Xephyr is probably the best client option right now (plus it can be run in a real fullscreen mode, which Xnest can’t). Your xinit/Xnest problems could simply be down to the apps that you’re running on the server – neither of these approaches offers modern X extensions like compositing or 3D. In my tests the compositing needed by the Netbook Launcher was enough to cause problems – perhaps you’re running something similar. Note that most of the dock-style launchers need compositing enabled, so it could be as simple as a little utility like that which you don’t really think twice about usually.
thanks for the investigation.. My Experience is the same as your test 1. Except that Xephyr wouldn’t want to start either… gives me one of these:
Fatal server error:
Could not create server lock file: /tmp/.X1-lock
Xephyr cannot open host display. Is DISPLAY set?
when i run DISPLAY=:0 Xephyr :1 -query x.x.x.x
No protocol specified.
Xephyr cannot open host display. Is DISPLAY set?
So no luck with Xephyr either.
And the xnest is crushing due to this bug:
as for startx … today, after updates on remote karmic it works without crashing. but works in a weird way, i can see remote toolbar on top of local one, or vice versa… it blinks 😉 but at least it doesn’t crash 🙂
Following these instructions I got it working on 10.04, but there are some issues. For one, after about three minutes gdm crashes and the machine hangs. Also, I was hoping to have a client logged in as the same user who is logged into the server, essentially adding more displays, but of course, that means the user’s settings, startup scripts, etc get run twice, resulting in two instances of everything, the same desktop on both machines, etc.
Unfortunately I haven’t had the time to try XDMCP in 10.04 yet. Since switching my work machine from Windows to Ubuntu I don’t really have as much need for XDMCP as I once did.
For what you want to do, VNC might be a better solution. If you want to log in to an existing session (i.e. “mirroring” the display) then the VNC-driven remote desktop support built into Gnome should do the trick. For non-Gnome sessions something like x11vnc will do the job (it’s in the Ubuntu repos). If you want to use a phsically proximate machine to effectively create a multi-monitor setup then have a look at Synergy2 (in the repos as “synergy”).
Thanks for so well documenting this gdm/xdmcp snafu in 9.10+. I first encountered it on a fresh new 10.10 install. Much googling was unproductive until I hit your site. I need to read your information in more detail before I decide what to do but I did bump the count on the launchpad bugs.
Comments are closed.