Ativando o servidor XDMCP Ubuntu 9.10

Enabling XDMCP on Karmic Koala

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:

  1. Open a terminal (Applications=>Accessories=>Terminal), or switch to a virtual console if you prefer
  2. 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/
  3. Edit the file to add the line “Enable=true” after the “[xdmcp]” line (don’t forget to save it):
    gksudo gedit /etc/gdm/custom.conf
  4. The file should look something like this:
    # GDM configuration storage
  5. 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

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. 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.

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):

  1. From within the Live desktop environment open a terminal (Applications=>Accessories=>Terminal)
  2. Enter the following command if you only have one XDMCP server on your network:
    sudo xinit -- :2 -broadcast
  3. 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.

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

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 -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 -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.

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.


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

Older versions of Ubuntu – or more specifically, older versions of GDM – had an option to remotely log into another server using XDMCP right from the main login screen. Selecting that option brought up a host chooser which scoured your local network for any XDMCP serving hosts, and then presented you with a list from which to choose a machine to log into. On a network with several serving hosts (such as the virtual machines we have running where I work) this was far more convenient than actually having to memorise the name or IP of the machine you want to connect to.

Of the four XDMCP client options I presented in my previous post, only one provided this host chooser functionality. Unfortunately that one was to replace GDM with KDM, which also implies adding a whole load of KDE libraries to your system.

This post will tell you a couple of ways to work around the loss of the host chooser from the login screen. Neither approach is perfect, but if you don’t want to replace your GDM login with KDM or something else, then they’re about the only choice you’ve got. They’re also useful if you want to make an XDMCP connection from within a running desktop environment, using Xnest or Xephyr, as described in the previous post.

Option 1: Run gdm-host-chooser and copy the IP

You may not be able to get to the host chooser from the GDM login screen, but that doesn’t mean it’s gone away altogether. It’s still hanging around in the depths of your machine, and you can launch it by typing the following line into a terminal or the ALT-F2 “Run Application” dialogue:


(Note that on 9.04, Jaunty Jackalope, and earlier releases, it was “/usr/lib/gdmchooser”)

The first thing to note is that it’s not as easy on the eye as the old version. Previously it was possible to provide custom icons for each host by putting images into /usr/share/hosts/ with suitable names. If no host image was found, the image at /usr/share/pixmaps/nohost.png was used by default. With Karmic Koala this latter image still exists, but isn’t displayed in the chooser. Neither are any images in the hosts icon directory.

Host choosers: Jaunty and KarmicHost choosers: Jaunty and Karmic

In the image above you can see the Jaunty chooser on the left, complete with several default host icons, and one quickly thrown together custom icon at the bottom. On the right is the icon-less Karmic chooser, which is also much larger than the Jaunty chooser, making it too tall for many netbook screens. The image shows the smallest size that each dialogue will scale to – they can be made larger if necessary.

What’s interesting is that the Jaunty chooser shows the host name of the Karmic box in a fairly readable way (”markc-desktop.local (”) whereas the Karmic chooser shows only its IPv6 address, with no host name. What you can discern from the chooser, however, is the IP address of each of the XDMCP serving hosts on your network. With that information you can use the “-query” option to xinit, Xnest or Xephyr in order to log into the machine of your choice. If you really, really want to log into a machine by selecting it from this list, rather than copying the IP, take a look at the other options below.

Option 2: Use -indirect, with an older server

Cast your mind back through the mists of time, way back to when XDMCP was invented and dumb X terminals were connecting to Unix mainframes in universities the world over. Particularly well funded universities might even have more than one Unix server – and hence the need for a host chooser – but if the dumb X terminals had to become intelligent enough to go scouring the network for willing servers and present their own local chooser… well, that would likely push their already exorbitant prices even further skyward. So “-indirect” was born.

This option is used in place of “-query” or “-broadcast” when starting an X server. In the case of Ubuntu you might specify it when using xinit, Xnest or Xephyr, as described in the previous post. It has one parameter, the IP of a server which will serve up a host chooser. So back in our university scenario, each dumb terminal could still remain dumb, provided it knew how to connect to a single specified server. That server then took on the responsibility of displaying a host chooser to the user. Once the user selected a host, the dumb terminal would reconnect to the selected machine, and everyone was happy.

Up until Jaunty you could also use this approach with Ubuntu. If you had a Ubuntu machine on your network with a known IP or name, you could use -indirect to bring up that machine’s chooser in order to see any other XDMCP servers on your network. In a complex environment with several such servers it meant that you could get away with only remembering the address of one of them.

This still works from the client end in Karmic, but not from the server end. The changes to GDM mean that it will no longer serve up a host chooser to any wandering clients that may request one. You can, however, still get a chooser up from another machine that’s not yet been upgraded to Karmic. So if you’ve got a lot of machines to connect to it might be worth leaving at least one of them running an older version of Ubuntu for the time being, so that you can use it as the source of a host chooser with the -indirect option.

Option 3: Use gdm-host-chooser in a subshell

If you tried running gdm-host-chooser using the command above from within a terminal, you may have noticed a load of text spewed out into your command line. If you subsequently selected an entry in the host chooser and clicked the “Connect” button, you may have noticed some more text being spewed out. If you were really observant you may have noticed that, amongst the text being spewed, was the word “hostname:” followed by a space, then the name (or more probably the IP) of the machine you selected. We can use this particular bit of textual spew to our advantage.

Instead of simply executing /usr/lib/gdm/gdm-host-chooser we can pipe its output through some other command line tools so that all we get out is the selected host IP. I’ve used “grep” to isolate the line in question, and “cut” to separate out the IP, but there are many other ways to do this (feel free to post if you’ve got a better approach):

/usr/lib/gdm/gdm-host-chooser | grep "hostname:" |cut -d' ' -f2

Now if you select a server in the chooser and click the “Connect” button, you should see the IP address appear on the command line without the “hostname: ” prefix. Using this mechanism it’s possible to insert the selected IP directly into the command line when using the “-query” option to xinit, Xnest or Xephyr by putting the whole of that line into a subshell:

xinit -- :1 -once -query $(/usr/lib/gdm/gdm-host-chooser | grep "hostname:" |cut -d' ' -f2)

Xnest :1 -once -query $(/usr/lib/gdm/gdm-host-chooser | grep "hostname:" |cut -d' ' -f2)

Xephyr :1 -once -query $(/usr/lib/gdm/gdm-host-chooser | grep "hostname:" |cut -d' ' -f2)

Pick one of those lines, depending on which type of X server you want to run. They’re all a little unwieldy for day-to-day use, so you might prefer to create a small shell script containing the appropriate line. That way you can launch your chooser and X server from a single command, or even assign it to a launcher on your panel.

I should note that the performance of the host chooser on my test machine was less than stellar, taking several seconds for clicks to register, so if you do use this approach you might need to be a bit patient.

Fonte: Link

~ por 3c0linux em dezembro 15, 2009.

%d blogueiros gostam disto: