InDepth: Configuring xdm
Have you ever wanted to access your workstation's desktop remotely? How about accessing your desktop on a server machine? That's just the sort of problem I needed to solve recently. I was responsible for setting up and managing a group of Linux servers. By the fifth trip to the lab to access a GUI console for various reasons (badge access, key codes, flights of stairs, etc.), it was time to find a solution that would allow me to use my workstation to access X desktops on various server machines.
Some may think that the standard X tools used to handle remote sessions would be sufficient to solve my problem—something like:
telnet host1 export DISPLAY=mywkstn:0 gnome-session
(or some other session manager).
However, the solution I was looking for needed to provide more than just basic functionality. It needed to be more administrable, appear more automatic and be easier to use for developers new to Linux. There are pitfalls associated with authentication, session management, etc., that require some knowledge of the way X works. For example, I often forget to type xhost +host1 when using remote X clients. I also have been on the receiving end of a puzzled look when trying to explain the xhost authentication scheme to a Linux newbie. Since this development project was not the time to teach developers the basics of X, I was looking for a solution that fulfilled all of these requirements.
A couple of solutions would allow me to manage the X sessions more easily. The solution I chose for this project was the X display manager, or xdm, although another popular solution is vnc. I chose xdm over vnc for two reasons. First, vnc has a server-side requirement to have a dæmon running for each shared desktop. Second, I already had X server software installed on all of the workstations and didn't see the need to install additional client software. Other choices are kdm and gdm, part of the KDE and GNOME packages, respectively.
X is the graphical support system used in most UNIX environments. If you are using GNOME or KDE on your Linux desktop, then you are making use of the X Window System. It is defined and maintained by the X Consortium (www.X.org). Most Linux users use an implementation of the X Window System offered by the XFree86 Project (www.xfree86.org). xdm is a display manager that enables flexible session management functionality. While xdm is usually thought of as “that GUI logon screen that auto-starts my X stuff”, it is actually much more powerful, as we will see.
In the X world, the terms client and server can get a little confusing. Specifically, an X server is the application that controls the keyboard, mouse and display resources. A client is an application that makes requests for the server to perform actions on its behalf (i.e., display a window with some set of specified characteristics). This is a little different for those of us used to thinking of applications running on our workstations as clients.
xdm uses the X Consortium's X display manager control protocol, XDMCP, to communicate with the X servers. This allows X servers to obtain session services from servers running xdm. Three types of queries can be sent by X servers:
Direct—asks the named host directly to display a login screen.
Broadcast—broadcasts a message to all hosts on the network, and the first to answer offers the login-processing services.
Indirect—contacts a named host running xdm and asks it about known hosts with which it may communicate. The xdm server will present a list of available servers willing to manage an X session. The X server will eventually end up communicating directly with the selected host to obtain login-processing services.
One of the initial reasons xdm was created was to allow for management of X terminals. These devices are basically a display, keyboard and mouse with embedded X server software; all intelligence is located on a server in the network. xdm was used to push login screens and manage sessions for these devices. Several years ago these devices were popular because access to UNIX workstations was limited. Users who wanted to access graphical desktops at their desks were either lucky enough to have a UNIX workstation at their desk or required one of these devices. Lately these devices have become less popular and are being replaced by PCs running X server software, such as Linux and other Unices (Solaris x86, xBSD, etc.) or Windows (running Hummingbird Exceed or the like).
When using xdm to manage these X sessions there are some configuration gotchas. At first glance, it may appear that if you configure xdm (in order to take advantage of XDMCP), you get either a local X server started (i.e., the console goes into graphical mode when xdm starts) or, if you disable the local display in xdm and use startx, it doesn't give you access to the chooser. The configuration described here allows any XDMCP client to access the Linux server desktops (subject to X security provisions, of course). It also demonstrates one way to configure xdm in order to get both a local X desktop and access to other server desktops from the workstation.
Security and access control are managed by xdm but are beyond the scope of this article. xdm should only be used in controlled environments. In addition, incoming port 177 should be blocked on all firewalls. If you're interested in X security issues, the following man pages are a good place to start: xdm(1), xauth(1), Xsecurity(7), lbxproxy(1)--Low Bandwidth X proxy, xfwp(1)--X Firewall Proxy, and ssh(1) and sshd(8) man pages, specifically regarding X11 port forwarding.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- RSS Feeds
- Readers' Choice Awards
- Tech Tip: Really Simple HTTP Server with Python
2 hours 56 min ago
- Reply to comment | Linux Journal
3 hours 29 min ago
- All the articles you talked
5 hours 52 min ago
- All the articles you talked
5 hours 55 min ago
- All the articles you talked
5 hours 57 min ago
10 hours 21 min ago
- Keeping track of IP address
12 hours 12 min ago
- Roll your own dynamic dns
17 hours 26 min ago
- Please correct the URL for Salt Stack's web site
20 hours 37 min ago
- Android is Linux -- why no better inter-operation
22 hours 53 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?