Linux-Based X Terminals with XDMCP
Want to get some use out of your early 90s vintage PC, the one barely powerful enough to run Windows 3.1? Need to outfit a group of users with workstations on a budget? Tired of administering a homogeneous workgroup from afar? Want to introduce Linux to a group of Windows or Mac users with the least amount of resistance? Can't stop tinkering with the oodles of options Linux offers? XDMCP may be for you, even if you answered yes to even one of these questions.
The X display manager control protocol (XDMCP for short) provides a means for a user sitting at one (client) computer running X to communicate with another (server) computer running an X display manager. Once a connection is established, the user can log in and run programs as if the user were sitting at the remote computer. The station where the user sits often is referred to as an X terminal, which essentially is a window into the server. All of the software resides on the server, all of the processing is done on the server's CPU, and all of the files to be accessed reside on the server.
So, for those of you trying to reduce administration hassles, this means you have to administer only the servers. The clients' software remains the same. For those trying to get some use out of old equipment, the speed of the client computers and the size of their hard drives is nearly irrelevant. Even my old Pentium 120 with a CPU upgrade to 180 MHz, 32MB of RAM and a 1GB hard disk provides more than enough muscle to be an X terminal. And, for those trying to outfit a workgroup on a budget, as many as five or six cheap computers can be configured as X terminals for every expensive workstation configured as a server. This would require a fast local network, however. Finally, for those trying to introduce Linux to Windows and Mac users, the only necessary intrusion into their machines is the installation of an X server, and free ones exist.
XDMCP is a communication protocol with the power to deliver all the items listed above. A word of caution is in order, however. XDMCP is an inherently insecure protocol. Although technologically nothing is standing in the way of running XDMCP between two computers on the Internet or on an untrusted network, it should never be done. It is too easy for hackers to snoop and grab such critical information as usernames and passwords transmitted over the connection without encryption. XDMCP should be run across only a trusted network. If you need to provide an X terminal across an untrusted network, a slower, slightly less convenient way to do this is mentioned in the security section.
Assuming you have not been scared off, to begin configuring XDMCP, be sure the computer to become the X terminal and the one to become the server are connected over your network. The simplest way to check this is to ping one from the other. If you can ping in both directions, you are ready to begin the configuration.
If you are trying to get some use out of old hardware or trying to outfit a workgroup or lab on a budget, the most powerful machine(s) is your server(s). In the case of bringing the power of Linux to Windows or Mac users, the Linux machine(s) is your server(s). For now, I assume you are configuring only one server. Multiple server set up is discussed later.
The server must be running some display manager, the standard being xdm. Both gdm and kdm, respectively the GNOME and KDE replacements for xdm, are shipped with many distributions and offer preconfigured interfaces that are likely to be sexier than what is offered by xdm. Operationally, they all are capable of providing X terminal services. In fact, if your server boots into a graphical login screen, you already are running a display manager. To find out which one, login and issue the command ps -A | grep dm. The results should be something like
634 ? 00:00:00 cardmgr 857 ? 00:00:00 gdm-binary 889 ? 00:00:00 gdm-binary
which means you are running gdm. If your computer boots into a text login screen, you either can reconfigure it to boot into a graphical login or run a display manager from the command line after logging in as root. This second option is useful only as a temporary solution while you are experimenting, however.
If you intend to use the machine as an XDMCP server, it's best to configure it to run a display manager upon booting. This is done by modifying /etc/inittab. The default run level is set in the line containing initdefault. It should read
Once you have made this change, you may reboot or issue the command telinit 5 to get a graphical login. Be sure X is set up with a resolution less than or equal to the resolution to be used on the X terminals.
At this point, the impatient may skip the rest of this section and configure an X terminal. If your distribution shipped with XDMCP enabled and configured to serve fonts and no firewall gets in your way, you should have a fully functional XDMCP server. For the patient, simply continue reading and reconfiguring or verifying that XDMCP is configured correctly.
At this point, I assume you are patient or you're back here because your attempt to connect an X terminal failed. One likely reason for a failed connection is the firewall on the server or, worse, somewhere else in your network. To temporarily disable the firewall on the server while you attempt to configure XDMCP, issue the command ipchains -F (or iptables -F) on the server. This eliminates the firewall altogether. To be more selective about your firewall policies, you may try the ipchains (or similar iptables) command
ipchains -A input -p udp -i $extint --dport 177 -j ACCEPT
In addition, make the following changes (if necessary) to the following xdm configuration files. In /etc/X11/xdm/xdm-config, change the line DisplayManager.requestPort: 0 to !DisplayManager.requestPort: 0 (that is, comment it out) so that the server can listen for XDMCP connections. In /etc/X11/xdm/Xaccess, change the line #* # any host can get a login window to * # any host can get a login window so others can access xdm. If you are not using kdm or gdm as your display manager, you are done with this part. However, if you are using kdm, you must edit kdmrc as well. Under Red Hat, this file is located in /etc/X11/xdm. In the [Xdmcp] section, set Enable=true and uncomment the line Port=177. If you are using gdm, you must make the same modifications to gdm.conf, which is located in /etc/X11/gdm under Red Hat.
Configuring an X terminal simply amounts to installing an X server and running an X query. No window manager or desktop environment are necessary. This is why the X terminal's hardware is relatively unimportant, except perhaps the network interface card. There are at least three ways to configure an X terminal to utilize XDMCP. One way is to setup a dummy terminal to run X with no window manager and no applications and then have the XDMCP server push a login screen onto the terminal. This is covered in this useful mini how-to.
I, however, will stick to configuring a not-quite-so-dumb X terminal. This means the X terminal must have some operating system with a configured X server installed. In case of Linux, Windows or Macintosh, an implementation of XFree86 is available free of charge. For Linux, installing XWindows is an option that should be chosen when the OS is installed. For Windows, consider installing Cygwin with the (optional) XFree86base package and dependencies installed. For Mac, consider installing XDarwin, an implementation of the XFree86 server. X servers are available for many other platforms as well, and any one is sufficient to run an X terminal.
Once you have an X server installed, all you need to do is run it with a query option. Three types of queries are available. If you are running only one XDMCP server, it is best to use a direct query. This is done from a non-X shell, not an xterm. If you are running Linux or UNIX, you should configure the machine to boot to a text login. If this already is the case, you are all set. If not, this is done, under Linux, by modifying the default run level in /etc/inittab. The default run level is set on the line containing initdefault. It should read
Once you have made this change, you may reboot or issue the command telinit 3 to get a text login. Log in as any user and issue the command X -query my.XDMCP.server, where my.XDMCP.server is either the name or IP address of the XDMCP server. If you are running windows and have installed Cygwin, from the Cygwin bash shell, issue the command XWin.exe -query my.XDMCP.server. If you are running Mac OS and have installed XDarwin, from a terminal issue the same command as used under Linux/UNIX. You should see the graphical login window of your XDMCP server. If you are having font issues, consult this excellent how-to to find the necessary server configurations to resolve the issue.
- The Tiny Internet Project, Part I
- Machine Learning with Python
- SUSECON 2016: Where Technology Reigns Supreme
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Free Today: September Issue of Linux Journal (Retail value: $5.99)
- Bitcoin on Amazon! Sort of...
- Android Browser Security--What You Haven't Been Told
- Securing the Programmer
- The Many Paths to a Solution
Pick up any e-commerce web or mobile app today, and you’ll be holding a mashup of interconnected applications and services from a variety of different providers. For instance, when you connect to Amazon’s e-commerce app, cookies, tags and pixels that are monitored by solutions like Exact Target, BazaarVoice, Bing, Shopzilla, Liveramp and Google Tag Manager track every action you take. You’re presented with special offers and coupons based on your viewing and buying patterns. If you find something you want for your birthday, a third party manages your wish list, which you can share through multiple social- media outlets or email to a friend. When you select something to buy, you find yourself presented with similar items as kind suggestions. And when you finally check out, you’re offered the ability to pay with promo codes, gifts cards, PayPal or a variety of credit cards.Get the Guide