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
As promised a couple of days ago, here’s how to enable XDMCP on Ubuntu 9.10, Karmic Koala. Note that none of these instructions are as simple as the point-and-click methods of earlier releases, but they’re not too bad either. I’ve used “gksudo gedit” for people trying to do this in a GUI – if you’ve used CTRL-ALT-F1 to get to a console screen, then replace those with “sudo nano -w” – but if you know enough to have got to a console screen then you could probably have worked that out anyway (and may want to replace nano with the editor of your choice).
Enabling the XDMCP server
With Karmic the GDM config screen has been stripped to the point of excess, as discussed in my previous post. So whereas earlier releases let you enable an XDMCP server with a few mouse clicks, Karmic requires you to edit the GDM configuration file on the disk. There is a slight problem in that the GDM configuration file doesn’t actually exist, but there is a copy hanging around in the GDM documentation on your machine, so we can use that as a starting point:
- Open a terminal (Applications=>Accessories=>Terminal), or switch to a virtual console if you prefer
- Copy /usr/share/doc/gdm/examples/custom.conf to /etc/gdm/ – the command line below will do the job for you:
gksudo cp /usr/share/doc/gdm/examples/custom.conf /etc/gdm/
- Open the file for editing:
gksudo gedit /etc/gdm/custom.conf
- Add the line “Enable=true” after the “[xdmcp]” line (to enable the XDMCP server)
- Also add “DisplaysPerHost=2” on the line after that (avoids a problem with the server locking you out – see the comments for more details)
- Save the file. It should look something like this:
# GDM configuration storage [xdmcp] Enable=true DisplaysPerHost=2 [chooser] [security] [debug]
- Restart GDM with the following command (note that this will kill your current X session, so please make sure you’ve saved anything important first):
gksudo restart gdm
[EDIT: Updated the above to include DisplaysPerHost=2 as described in the comments below]
And that’s it, XDMCP enabled. The usual caveats apply – XDMCP is an inherently insecure protocol, please do not enable it on an internet-facing machine or the laptop you take to the coffee shop. The chances are that if you’ve come here looking for XDMCP information then you already know enough about it to determine whether it’s safe for you, but it never hurts to have a reminder.
If you want to disable XDMCP then edit the file to read “Enable=false” and restart GDM (or your whole machine).
If you just want to enable Karmic for use with my article about Rootless Linux on a Windows Machine, that could well be all you need to do.
There are other settings that you can add to the [xdmcp] section, but this should be enough to get you started. In particular the MaxSessions option may be useful if you need multiple XDMCP users connected at once, or as a workaround if you find that stale connections are preventing you from getting a login screen. [Edit: It appears to be DisplaysPerHost=2 that is the workaround for this problem]
UNR Problems
One of my favourite uses for XDMCP on Jaunty was with Ubuntu Netbook Remix. You could switch from the netbook launcher screen to the full desktop mode, connect it to the network, enable XDMCP, then easily log in from your Ubuntu desktop machine to use the netbook with a full-sized keyboard and screen. With Karmic they’ve screwed up this approach in just about every way possible:
- You can’t easily enable XDMCP on the Netbook via the GUI (so you have to use the steps above)
- You can’t switch between the netbook launcher and full desktop, which leaves you with a netbook UI on a screen which is more suited to a full desktop
- The netbook launcher is a lovely translucent thing, which uses compositing to give it its bling. That means it doesn’t display anything via a normal XDMCP connection*, making it a bit more tricky to launch applications
(*It works, albeit slowly, if you use Xephyr – which is something I”ve covered in the next thrilling instalment)
There are a few workarounds which will at least let you launch other applications. You can launch them by pressing ALT-F2 to open the “Run Application” dialogue. You can add launchers for your most commonly used applications to the Gnome panel. Or you can add a “Main Menu” applet to the panel. The latter is the most obvious and user-friendly solution, but the obvious and user-friendly place to put it (in the top left) already features a near-identical looking icon for the UNR go-to-the-launcher functionality. So yes you can have a full menu to launch apps from, but prepare to get confused if you also want the UNR functionality.
I suggest that moving the UNR icon to the right of the panel, just before the system tray icons, makes most sense. That way you have a full menu at the top left, and the go-home functionality to the right of the window title.
Connecting to an XDMCP server
As my previous post mentioned, the option to make an XDMCP connection has been removed from GDM – and therefore from the Karmic login screen. From the Gnome GDM documentation:
GDM 2.20 and earlier supported the ability to manage multiple displays with separate graphics cards, such as used in terminal server environments, login in a window via a program like Xnest or Xephyr, the gdmsetup program, XML-based greeter themes, and the ability to run the XDMCP chooser from the login screen. These features were not added back during the 2.22 rewrite.
It’s that last feature – the ability to run the XDMCP chooser from the login screen – which is the omission I’m dealing with here. The wording of the text above is a bit ambiguous in that it’s not clear whether it means “these features were not added, but will be at some point”, or whether it means “these features were not added and never will be”. I hope it’s the former.
The text above mentions Xnest and Xephyr, which are both X-servers that are also X-clients and allow you to do fancy things like run an XDMCP connection to another machine in a window on your normal desktop. In fact one of the most common comments I’ve seen about the removal of the XDMCP Chooser option from GDM was that you can “just” install Xnest and use the terminal services client if you need to connect via XDMCP. Although this will work in many cases it’s not equivalent to having it built into the login screen for several reasons:
- It assumes you actually do have the ability to log in to the local machine, which may not be the case
- It doesn’t run an XDMCP chooser, so you need to know the IP of the machine you’re connecting to
- It requires the installation of Xnest, so won’t work from a Live CD with no internet connection
- At least on the virtual machine I’m currently running Karmic on, the Terminal Services Gnome Applet dies every time I try to add it to the panel
So here’s a workaround for use with a Live CD, and which doesn’t require you to have an internet connection. It doesn’t use the XDMCP Chooser, however, so you will either need to know the IP of the machine you’re connecting to (if you use the -query option), or only have one XDMCP server on your network (if you use the -broadcast option):
- From within the Live desktop environment open a terminal (Applications=>Accessories=>Terminal)
- Enter the following command if you only have one XDMCP server on your network:
sudo xinit -- :2 -broadcast
- Alternatively if you wish to specify the IP of the machine you’re connecting to, use the -query option like this (replacing 123.456.789.0 with the IP of the server):
sudo xinit -- :2 -query 123.456.789.0
This will start a second X server and should give you a login screen for the XDMCP host. Because you now have two X servers running, you can switch between them if you want to – the default will be on CTRL-ALT-F7 and the XDMCP desktop will be on some higher number (CTRL-ALT-F8 seems like it should be the most likely candidate, but mine was on CTRL-ALT-F9 when I tried it).
This should be sufficient for many of the use-cases of XDMCP on a live CD. For full installations, or when you want to run your XDMCP connection in a window, you might find Xnest or Xephyr to be more useful, so I’ll discuss those next time.
Finally, a plug
Based on the stats I see for other XDMCP-related posts on this site, I suspect that this page will rapidly become one of my most popular. It would be remiss of me not to take that as an opportunity to plug “The Greys”, the humourous, sci-fi based webcomic that I’m involved in. If that sounds like the sort of thing that might interest you, please take a look.
What would be a more secure alternative to accessing an Ubuntu server remotely? I keep my server downstairs and my workstation is upstairs. Is there a secure way I remotely log in to the GUI on my server without having to log in on physically on the server?
It’s more down to the security of your network. XDMCP is an insecure protocol in that usernames, passwords and other data are passed around unencrypted, so anyone who can sniff the data packets on your network could, in theory, capture all that information. If you have a wired connection between your machines and you’re behind a firewall or router which blocks access from the internet, then you should be fine (that’s how I run it). If your connection is wireless then you’re relying on the encryption in the wifi protocols to protect your otherwise exposed data – but that’s also the case with any other unencrypted data on your network. The real issue is that it’s not safe to use XDMCP over the internet without tunnelling through a VPN of some sort.
As for alternatives, there are four that spring to mind:
* SSH – Doesn’t easily give you a full GUI, but you can log in and launch X apps from the command line. Of course you could always launch some other app launcher or dock as your first application, and then launch everything else from there.
* NX – A semi-proprietary protocol that runs over SSH for its encryption. There are open source servers and clients available, but not in the standard Ubuntu repositories. See http://en.wikipedia.org/wiki/NX_technology and https://help.ubuntu.com/community/FreeNX
* VNC – Often seen as a way to share a logged-in desktop (it’s used by the Gnome Remote Desktop app), but the original Unix version actually gave you a separate login session independent of any already logged-in users. There are still plenty of VNC servers which can do this, plus it has the advantage of a wealth of clients across most operating systems
* XDMCP over a VPN – You could set up a fully-fledged VPN which will route the UDP packets required for an XDMCP login to work. SSH has an option for this now, but like any VPN it does require some knowledge and configuration, which probably makes it the most complex of these options
In your situation I would consider whether or not you feel the connection between the machines is secure. If it is then XDMCP will do the job. If not, I would look at NX or VNC.
Hi,
I’m no stranger to linux, Debian in particular, but this was my first attempt at making at HTPC, (to be honest its the first time i’ve seriously considered using a gui with linux, the command line has always done alright by me). Your post for enabling xdmcp filled me with such confidence but unfortunately your solution does not work for me, I have a stock standard (bar partitioning) install of Ubuntu 9.10 and have followed your instructions to the copied and pasted letter but I just can’t get it to work… I should mention that I am connecting via RealVNC in W$7 but I had a previous incarnation of the HTPC a day ago with a debian install and it worked fine once I had enabled xdmcp from the login screen. Is there a log file I can look at?
… sorry I should add that yes I can VNC in after I have logged in manually…
Pete,
The first thing to confirm is that you restarted GDM (or rebooted the computer) after adding the /etc/gdm/custom.conf file – that’s probably the most common cause of this not working. Although “restart gdm” should do the trick, in older versions of Ubuntu I did occasionally find that the old settings would stick – in which case a full reboot would always do the job.
The log files live in /var/log/gdm/ though they’re not particularly helpful to mere mortals. If you try to make a connection from the remote machine, you should see several of the files get their timestamps updated, and you should see some files named after the IP or name of the machine you’re connecting from. If you’re not seeing these then the connection isn’t getting very far at all.
Check the config file again. It should be “Enable=” not “Enabled=” (I’ve made that mistake myself). I don’t know if case is important, but the docs show it with a capital “E”, so I’ve stuck with that.
Finally firewalls are another common cause of XDMCP problems. Start by temporarily disabling your firewall if you have one, and if you can make a connection then you know that’s to blame. Running a packet sniffer like Wireshark can also help to determine if the problem is at the client or the server.
Thank you; that is so useful.
When I’ve logged out of my remote session, and used Ctl-Alt-F7 to go back to my default X server, how do I close the second X server? I’ve been closing the terminal window from which I ran the xinit command; is that sufficient?
The easiest approach is probably to append the “-once” option to your xinit line. That will terminate the XDMCP connection when you log out, rather than spawning a new login screen. You then just log out from the second session when you’ve finished – that should drop you back to the normal session anyway, but if not just use CTRL-ALT-F7.
Closing the terminal should do the job – try CTRL-ALT-F8/9/10 to confirm that the X session has gone. Killing X like that probably isn’t the most elegant way to terminate it, but it’s not likely to cause any problems either, so will do the job if you forget to add the “-once”.
I think there is a bug in version 9.10. I enabled XDMCP login in /etc/gdm/custom.conf and restarted gdm. The first time I can connect to the Ubuntu box. However, after I log out and try to connect again, the connection is being reset.
I am using Xming as an X server on my Windows machine. I have tried with other X servers for Windows, with the same result.
It seems that the only solution is to stop and start gdm on the Ubuntu box. The same problem is present on two different Ubuntu 9.10 boxes (one 32-bit, the other 64-bit).
I’ve seen this behaviour as well, but haven’t had a chance to investigate much further. It’s the reason that I wrote “…the MaxSessions option may be useful if you need multiple XDMCP users connected at once, or as a workaround if you find that stale connections are preventing you from getting a login screen”. Have you tried that setting in your custom.conf? It’s not a solution to the problem, but might let you work around the issue in the short term so that you require fewer gdm restarts.
Thank you very much for the comprehensive explanation!
I have exactly the same problem as Fedon describes above. Logging into Ubuntu Studio 9.10 with a Windows X Server (I happen to be using Xming as well) works great the first time but, after I log out once, I can’t get a login screen without restarting gdm. This is my first experience with Ubuntu and is very frustrating. I’ve never had this problem with any other version of Linux combined with a Window X server going back to Yggdrasil/Reflection X 15 years ago and every combination I’ve tried since. Has anyone found a workaround? This is frustrating as hell. I really like Ubuntu but am ready to go back to Suse if there’s no way to fix this.
Have you tried setting the MaxSessions option in /etc/gdm/custom.conf, as I suggested to Fedon? It’s not a solution to the problem, but depending on how often the server machine gets rebooted it might suppress the issue enough that you rarely or never see it.
Having explored this issue a bit further, it seems that MaxSessions isn’t the cause of the problem. Adding “DisplaysPerHost=2” (without the quotes) to the [xdmcp] section of the config file, then restarting gdm, does seem to solve the problem. I’m writing this post via a Xephyr connection to a UNR installation that I’ve logged in and out of six times now.
Mark – I’m currently traveling and don’t have access to my Ubuntu box but I was going to posit that I don’t think changing MaxSession will help given that the default value is already 16. I see from your comment that you’ve now ruled that out.
I can not get xdmcp to work on 9.10. Giving up.
It is a pain compared with previous versions of Ubuntu, and I really hope they fix it for Lucid. Are you really giving up, or is your post really a disguised cry for help – in which case a bit more detail would be useful. Are you struggling with the server end, the client end, or both? Which clients have you tried? Have you got it working and experienced instability, or just not got it working at all?
And if you have really given up on XDMCP, but still want a remote desktop connection of some sort, perhaps this post will help you instead:
https://www.peppertop.com/blog/?p=744
I already had xdmcp working when I upgraded to 9.10 so I didn’t know there were all these problems.
I have a new one of my own though. In previous versions you couldn’t do anything in the “users & groups” box because it said “you are not authorized to make changes”
But now, I can’t even mount drives in a remote x-session! It works fine in the exact same user account when I log into the local console but it tells me I’m not authorized when I try from a remote session. Any ideas?
I think this is something that is configured via PolicyKit. In earlier releases there was a UI to manage it in System=>Administration=>Authorizations which was a bit unwieldy but did the job. With Karmic they’ve switched from PolicyKit to PolicyKit-1, which apparently doesn’t have such a UI. So if you really need to fix this, I think you’ll have to wade through the PolicyKit-1 documentation and craft yourself a suitable config file. Good luck!
Hi
I cannot get this to work. I have a network behind a NAT router and want to access a Karmic HTPC via xdmcp from a Jaunty laptop.
When trying to log in from the laptops gdm welcome screen, no hosts show up, and when I try to connect to the HTPC directly through its ip number it times out.
I believe there is some network error but I have no firewalls enabled. Can you help me to troubleshoot this? I have searched the net for a solution with no luck…
Cheers,
Magnus
Assuming you’ve created a suitable /etc/gdm/custom.config and restarted GDM (or rebooted the machine), the next step will be to check the htpc’s GDM logs in /var/log/gdm/ for evidence of a connection attempt from the laptop. A log file is created for each XDMCP client that makes a connection, so if there’s no log file with the laptop’s name or IP address then the connection request isn’t even getting as far as the htpc (which generally implies either a firewall, or more fundamental network issues). If you do have a log file for your laptop then at least you know that the connection attempt got to the server. Check the log file, and the other logs in the folder, to see if that sheds any light on the problem.
Hi,
many thanks for the help. I have double checked the config settings and I have rebooted the computer. There are no updates to the files in /var/log/gdm when I try to connect so there is probably a general network error. But I just cannot find out what… I can ssh to the htpc and ping it. Do you know of a way to troubleshoot the network a la xdmcp?
/Magnus
If you can ssh and ping then obviously the basics are all okay, so the next step is probably to install Wireshark (sudo aptitude install wireshark) or some other packet sniffer and try to identify exactly what packets are being sent, and what response, if any, is coming back for them. Although I’ve used Wireshark for this in the past, a description of what to do is way outside my realm of competence, so I’d suggest a bit of Googling or looking round the Wireshark documentation as a starting point.
I would also try a different XDMCP client – I’ve documented Xephyr and XNest on this site – to see if you have any more luck with one of those. I’ve had most success with Xephyr under Karmic. Of course if the problem really is a more general network issue, this won’t help.
Finally I would try connecting the laptop directly to the htpc with a crossover cable, or via a dumb hub, to get to as minimal a network as possible. You could also try running either end (or both ends) from a Live CD. Basically it’s the usual approach of trying to swap out bits of the system until you can identify which one is causing the problem.
If all else fails, you could just give up on XDMCP and try an alternative instead. I detail a few of those in my fourth article on this subject.
Thanks.
It does seem that they screw with Ubuntu with every release. I especially don’t like the way that bash handles ‘set -o vi’ differently in each version.
Is there any way to make a remote x-session to a server and still have access to local cdrom device and usb memory sticks etc on the client ?
If you mean that you want to access your local storage devices from within the remote session, then this amounts to the same issue as accessing them from the server itself. If you just need to access the files on the storage then using something like sshfs might do the trick – or even just using ssh/scp to copy the files to the server and back as needed. If you’re accessing a recent GNOME desktop on the server (e.g. a recent Ubuntu installation), then I’ve found the “Connect to server…” option in the Places menu works well for this, and even makes the mounted location available to the command line via the .gvfs directory.
If, however, you want to access the underlying block device itself – to (un)mount the CD-ROM drive or USB stick on the server’s desktop, for example – you might need to look into something like the Network Block Device driver. I’ve never had cause to use it myself, though, so I don’t know whether or not that will suit your requirements.
I see they’ve removed the –no-console option from gdm for Karmic! I have a headless AMD64 box in the cellar
which I sometimes use for development work. I previously had no Xserver configured, and ran gdm with the –no-console option so it wouldn’t attempt to start one. Can’t do that now. Anybody tried xdm ?
For most things I’m ok with ssh and x-forwarding etc,
but it’s a cool demo to have a full session running in an xnest on my desktop.
In Ubuntu 9.10, I just needed to edit /etc/gdm/gdm.schemas and set the following entries:
————————————-
<key>security/DisallowTCP</key>
<signature>b</signature>
<default>false</default>
<key>xdmcp/Enable</key>
<signature>b</signature>
<default>true</default>
———————————————
I did not need to add a custom.conf but if you do it will work as well.
Running GDM on OpenVZ was another matter as the new GDM has not implemented the –no-console option that is required for headless setups (like for OpenVZ clients). A patch to GDM, however, is available from: https://bugzilla.gnome.org/show_bug.cgi?id=567522
HH
I recommended creating custom.conf as it won’t (well, shouldn’t) be affected by any future updates, whereas gdm.schemas might be – but thanks for the info, as it’s always useful to provide more options to other readers.
ARGH! I’m trying to get this working in 10.4. I repeated the steps, gksudo gdm restart, and voila it worked. I wanted to change XMing from Window to Fullscreen mode, so I restarted XLaunch … and no greeter. So I restarted GDM and XLaunch. No greeter. I restarted the Ubuntu machine and XLaunch. No greeter.
*$@*$&$*!
However – I do appear to have found a likely cause.
netstat -an | grep 177 shows only an ipv6 listener. ARGH.
I’m trying to figure out how to coerce GDM into listening for IPv4 also.
Thank god!! saved me after a year of figuring out why i had to restart gdm to connect to my box every time.
DisplaysPerHost=2
This morning, a virtual server running Ubuntu 10.04-LTS that I’d built 2 days ago was dropping VNC connections upon every connection attempt. Now, I had been building multi-session VNC based terminal servers for a few years and that’s the standard on my network for remote desktop access to my linux servers, but this problem was confounding because my logs didn’t really reflect the actual cause.
After a bit of searching Google, I found this blog-post, tried the suggestion (DisplaysPerHost=2) and found that it fixed the problem.
Many thanks!
I’ll be updating the documentation I’ve published, to include that addition to the file /etc/gdm/custom.conf, over the next day or so. As time allows, I’m building up a documentation set that will cover this type of VNC+XDMCP configuration on many platforms… at least enough platforms that someone can work out the differences on their own for platforms that I won’t be covering. It goes without saying that my fave distro is Ubuntu. I just hope that this technique can be made to work with all of the Ubuntu releases, post 10.10. I’ve been able to make a working solution using XDM, vnc4server, xinetd, and Gnome, but that was before I found the work around to kill ipv6 out of the equation. Now that Unity is the primary desktop in new Ubuntu releases, I’ll begin working on a solution for that as well, so that I have a solution ready for deployment when Ubuntu 12.04 releases in April 2012.