Task 2.9: Manage X Logins
Your workplace has purchased a powerful Linux computer (called gandalf) and installed an expensive commercial software package on this computer. In order to enable users on other systems to use this software, you want to enable remote XDMCP logins; once the system is so configured, users will be able to log into gandalffrom their own workstations in order to run this software.
Methods of remote access other than XDMCP exist and are often preferable to XDMCP. Remote XDMCP logins are particularly desirable when a network has X terminals—low-powered computers that consist of a keyboard, a mouse, a monitor, and enough hardware and software to run an X server but not much else. X terminals can provide multiple users with access to a computer running an XDMCP server at minimal cost.
Scope of Task
This task involves adjusting your XDMCP configuration to permit remote X-based logins. Doing so can be tricky in some ways, so you must pay careful attention to the details of this task.
This task should take about an hour to complete. If you were to reconfigure multiple computers along these lines, each one would take just a few minutes once you're familiar with the procedure.
Boot the Linux computer you're configuring (and that I'll refer to as gandalf). Log in and acquire rootprivileges; like most system configuration tasks, this one requires superuser privileges.
To fully test this configuration, you'll need access to a second computer with an X server. This computer may be, but does not need to be, a Linux system. If you're using a Linux computer for this task, the best approach is to shut down its own XDMCP server; you can then launch X with appropriate options to connect to gandalf's XDMCP server.
As usual, working as root poses certain risks. You should back up configuration files before making changes to them so that you can recover from typos or other errors.
Configuring an XDMCP server as described in this task poses security risks because it provides a server through which outsiders might be able to access your computer. This risk is worth taking if you need the functionality and if your network is properly protected by firewalls that block X and XDMCP access; however, if you simply want to learn how to configure an XDMCP server but don't really need the functionality yourself, you should undo your changes once you've tested them.
Unfortunately, the fact that there are three major XDMCP servers for Linux means that configuration of your XDMCP server will vary substantially depending on your existing setup. Before configuring your XDMCP server, you must first figure out which one your system is using. If you're not currently running one, you must choose one to run. Only then can you reconfigure the server to accept remote logins. Once this is done, you can test the configuration using a remote system.
Identifying Your XDMCP Server
If your computer already boots into GUI mode, it's already running an XDMCP server. To find out which one it's using, type the following command:
$ ps ax | grep [gkx]dm
The result should be a list of any of the standard XDMCP server processes that are running—gdm, kdm, xdm, or a variant of one of these. (This command may also turn up a few hits on unrelated programs, but these should be obvious.) In most cases, the easiest course of action is to modify the configuration of your default XDMCP server. If necessary, though, you can change which server your system uses. First, of course, you must ensure that it's installed. Search for the files involved, and if you can't find them, install the relevant package for your distribution. How you proceed thereafter depends on your distribution:
Debian Edit the /etc/X11/default-display-managerfile, which contains the full path to the XDMCP server you want to run. For instance, enter /usr/bin/X11/xdmin this file to use XDM. This path must match one in the DAEMON variable in the SysV startup script for the server in question.
Gentoo Edit the /etc/rc.conf file. Locate the line that sets the DISPLAYMANAGER environment variable and set it to xdm, gdm, or kdm.
Mandriva Edit the /etc/sysconfig/desktop file, which holds variable assignments. Locate the DISPLAYMANAGER variable and set it to the name of the XDMCP server you want to use, such as gdm to run GDM. Mandriva supports two versions of KDM. Setting DISPLAYMANAGER to KDE uses the mdkkdm XDMCP server, while setting DISPLAYMANAGER to KDM uses the kdm XDMCP server. The mdkkdm server provides a stripped-down appearance compared to the regular kdm server.
Red Hat and Fedora Core Edit the /etc/sysconfig/desktop file, which holds variable assignments. Locate the DISPLAYMANAGER variable and set it to the name of the environment that's associated with the XDMCP server you want to use, such as "GNOME"to use GDM. Use "XDM" to launch XDM.
Slackware The /etc/rc.d/rc.4 file controls starting X, including launching an XDMCP server. This file tests for the presence of the three major servers and launches the first one in the list it finds, using the sequence GDM, KDM, and then XDM. You must remove higher-ranking servers, remove their execute bits, or edit the startup script file to change which one launches.
OpenSUSE The /etc/sysconfig/displaymanager file sets several variables related to XDMCP operation, including the DISPLAYMANAGER variable, which specifies which server to use. Set this variable to the appropriate name, such as "kdm" to use KDM.
In practice, XDM is the simplest of the display managers; it provides only a login prompt. KDM and GDM both support additional user options, such as a choice of which desktop environment to run. They may also provide shutdown options and the like, although these are usually disabled for all but local users. KDM configuration is basically a superset of XDM configuration, but GDM uses its own unique configuration files. GDM lacks a few of XDM's and KDM's IP-based auditing features, so if you use GDM, you should be particularly diligent about setting up your firewall to prevent outside computers from reaching the XDMCP port (UDP port 177).
In some cases, particular servers may be very finicky on certain systems or distributions. If you have problems getting one server to work, try another. It may prove more amenable to modification to accept remote logins than the default server.
In all cases, you must restart the server after you change your XDMCP configuration. In theory, passing a SIGHUPsignal to the process should do the job, but in practice this sometimes doesn't work. (Phase 3 describes passing signals to processes via the kill utility.) You may need to log out, switch to a text-mode runlevel (typing telinit 3should do this on most distributions; Debian and Gentoo are two exceptions), and then return to the GUI login runlevel (5 for most distributions, but 4 for Slackware). On some distributions, such as Gentoo and Debian, you can restart the XDMCP server via its SysV initialization script, as in /etc/ init.d/xdm stop followed by /etc/init.d/xdm start. This action will terminate your X session, so shut down all your programs before doing this.
In all cases, XDMCP normally runs only when the system is configured to start X and present a GUI login screen on the console. If you want to configure the system to accept XDMCP logins from remote users but not run X locally, you can do so; however, you must alter the XDMCP configuration, as described in the following sections.
Configuring XDM to accept remote logins begins with the /etc/X11/xdm/xdm-config file. The key change is in the following line, which usually appears near the end of the file:
This line tells XDMCP not to listen on its usual port. Such a configuration is common on workstations, which normally manage their local X servers more directly. Change the 0in this line to 177or comment out the line by placing a hash mark (#) or exclamation mark (!) at the start of the line.
In addition to xdm-config, you must edit the /etc/X11/xdm/Xaccessfile, which controls what XDMCP clients may access the XDMCP server. This file is likely to contain lines such as the following, but they'll probably be commented out:
* CHOOSER BROADCAST
These lines tell the system to accept logins from any host and to provide a chooser (a list of available XDMCP servers on the local network) to any client that asks for one. The default commented-out configuration denies access to all computers, so uncommenting the lines enables access. Instead of using an asterisk (*), though, you may want to specify computers by name. An asterisk can stand in for part of a name. For instance, *.luna.edu grants access to any computer in the luna.edu domain.
The /etc/X11/xdm/Xservers file lists the displays that XDM should manage. A typical configuration includes a line like the following:
:0 local /bin/nice -n -10 /usr/X11R6/bin/X -deferglyphs 16
This line tells XDM to run /usr/X11R6/bin/X and to display an XDMCP login prompt on this server whenever the XDMCP server itself runs. If you don't want to start X locally but you do want to accept remote XDMCP logins, comment this line out. When you restart runlevel 5, the system should not start X, but it should accept remote XDMCP logins.
KDM's configuration files are the same as those used by XDM, except that some KDM configurations place those files in new locations and under new names. Specifically, kde-config may replace xdm-config, and it may reside in /opt/kde/bin/ or /usr/bin. Xaccess and Xserversmay reside in /opt/kde/share/config/kdm, /etc/kde/kdm, /etc/kde3/kdm, or some other directory. If you can't find these files, try using your package manager's tools to locate the package from which KDM was installed and then review the package contents. For instance, on a Red Hat or Fedora Core system, you might type the following commands:
$ whereis kdm kdm: /usr/bin/kdm $ rpm -qlf /usr/bin/kdm | grep Xaccess /etc/kde/kdm/Xaccess
In addition to these configuration files, which you can adjust much as you would XDM's configuration files, KDM provides KDM-specific configuration files. The most important of these files is kdmrc, which may be stored in /etc/kde/kdm, /etc/kde3/kdm, /etc/X11/xdm, or some other location. This file points to other configuration files—possibly including, directly or via links, XDM configuration files. The file also includes a section called [Xdmcp] in which various XDMCP options are set. Be sure that the following lines exist in this file:
GDM uses an entirely unique configuration system. The GDM configuration files usually reside in /etc/X11/gdm, so check that directory first. If you can't find the files there, use your package manager to try to locate them, as described for KDM in the previous section. The main GDM configuration file is called gdm.conf, and the section that's most relevant to XDMCP server operation is called [xdmcp]. To enable remote logins, be sure that this section includes the following lines:
If you want to accept remote XDMCP logins without starting X locally, locate the [servers] section of gdm.conf. This section normally contains a line such as the following:
Comment out this line by adding a hash mark (#) to the start of the line and GDM won't start X on the local system when it's restarted. (You may need to switch to runlevel 3 and then back to runlevel 5 to restart GDM without X.)
Instead of editing the configuration file in a text editor, you can use a GUI tool. Type gdmsetup in an xterm window or select the option for the GDM configuration tool, often called Login Screen, GDM Configurator, or something similar, from a desktop environment menu. The result is the GDM Setup window, shown in Figure 2.6. The XDMCP tab includes several XDMCP options, but the most important XDMCP option is the Enable XDMCP check box on the Security tab. Be sure the program is set to listen on UDP port 177 (set on the XDMCP tab), as well.
Using an XDMCP Client
Once you've reconfigured and restarted the XDMCP server, it's time to try it with an XDMCP client—that is, an X server. X servers are available for many OSs, not just Linux. For instance, you could use Cygwin/X (http://x.cygwin.com) or XManager (http://www.netsarang .com/products/xmg_detail.html) for Windows if you wanted to access gandalf from Windows clients.
FIGURE 2.6 GDM provides a GUI configuration tool in which you can activate XDMCP options.
For purposes of this exercise, though, I'll assume you have access to a computer that can run XFree86 or X.org-X11, such as another Linux computer. The trick to using such a system to access another via XDMCP is to not start X in the normal way, which launches a local window manager and may present the system's own XDMCP login prompt. Instead, you launch X from a text-mode login or custom startup script and pass it the -query host.name, -broadcast, or -indirect host.name option, which causes X to try to find and use an XDMCP server in various ways
Query The -query host.name option tells the server to connect directly to the specified XDMCP server. If all works well, you'll see the XDMCP login prompt and be able to access the system.
Broadcast The -broadcast option tells the local X server to broadcast a query for available XDMCP servers. X connects to the first available server. (Some X servers present a list of XDMCP servers, though, enabling you to select which one you want to use.)
Indirect The -indirect host.name option asks the host you specify to display a list of available XDMCP servers on its local network segment. This option is most useful if you're trying to select from machines that reside behind a firewall that blocks broadcasts but not XDMCP logins or other X-related activity. For instance, with X not running, you might type the following command at a text-mode prompt:
$ /usr/X11R6/bin/X -query gandalf.luna.edu
This command starts X, but rather than launch your local display manager and other software, X connects to gandalf.luna.eduto present a login prompt on that system. When you log in, you'll be using gandalf via the keyboard and display of your local computer.
Criteria for Completion
To complete this task, you should have successfully reconfigured your XDM, KDM, or GDM software to accept remote logins via XDMCP. You can test for successful completion of this task by using another Linux computer or even a non-Linux system with an X server package installed.
For security reasons, you should reverse your changes after you've tested them, unless you want to use the remote-access features of an XDMCP server. If this is the case, you should review your network security features and employ firewall rules to prevent outside access to your XDMCP server (on UDP port 177) and to the X server (on TCP port 6000).
Use the following table of contents to navigate to chapter excerpts, or click here to view Chapter 2 in its entirety.
Managing Linux hardware and the kernel
Part 1: Set BIOS Options for Linux: task 2.1
Part 2: Know the hardware in your computer, task 2.2
Part 3: Resolve hardware conflicts, task. 2.3
Part 4: Configure USB devices to Linux, task. 2.4
Part 5: Configure Linux Disk Drive, task 2.5
Part 6: Configure and compile a kernel for Linux, task 2.6
Part 7: Use Linux power management features, task 2.7
Part 8: Configure X options for Linux, task 2.8
Part 9: Manage X logins for Linux, task 2.9
Part 10: Use X for day-to-day operations, task 10
|ABOUT THE BOOK:|
|Hit the ground running with the street-smart training you'll find in Linux Administrator Street Smarts: A Real World Guide to Linux Certification Skills. Using a "year in the life" approach, it gives you an inside look at Linux administration, with key information organized around the actual day-to-day tasks, scenarios, and challenges you'll face in the field. This valuable training tool is loaded with hands-on, step-by-step exercises covering all phases of Linux administration. Purchase the book from Wiley Publishing|
|ABOUT THE AUTHOR:|
|Roderick W. Smith left a career in academia to pursue his passion for computers. He is particularly interested in Linux and Open Source Software, and has written several books.|
This was first published in February 2007