InDepth: Configuring xdm
xdm is highly configurable; the following is only one way to configure it in order to accomplish a specific goal.
On my Red Hat 7 system, xdm lives in /etc/X11/xdm. Its main configuration file is xdm-config (see Listing 1).
xdm's configuration files are in X resource format. There are resources for the configuration of the locations of various files. We are interested in the files pointed to by the resources servers, accessFile and resources. The adventurous will be interested in the session and DisplayManager._X.setup, where X is the display number.
Notice that DisplayManager.requestPort:0 is commented out. This resource specifies which UDP port to use to listen for XDMCP requests. If it is set to 0 (as is the default), then XDMCP requests are ignored, and xdm only manages local displays (see Xservers file). We comment it out so that xdm will listen on the default port (USP port 177).
My Xservers file looks like this:
#:0 local /usr/X11R6/bin/X
If this line were not commented out, then I would get a graphical login screen every time I started xdm. That is, it would start and manage a local X server on display 0 by running the command /usr/X11R6/bin/X. What we want to be able to do is select the host that we will connect to. We accomplish this using the Xaccess file:
#any indirect host can get a chooser * CHOOSER BROADCAST # # If you'd prefer to configure the set of # hosts each terminal sees, # then just uncomment these lines # (and comment out the CHOOSER line above) # and edit the %hostlist line as appropriate # #%hostlist host-a host-b #* CHOOSER %hostlist #Although the Xaccess file is a very flexible tool, we will only be using it to launch the chooser (indirect mode). The chooser is a little X application that displays a list of available hosts on the network, allowing us to select the one to which we would like to connect. I like to use the BROADCAST option because new hosts show up in the list automatically. Some may prefer to name the hosts specifically, as shown using the %hostlist macro. This method is sometimes required, especially in larger networks where the broadcast doesn't reach all desired hosts.
If you are interested in a finer level of control, you can use a list of servers instead of BROADCAST. This will allow you to specify the list of available hosts directly.
If you want to configure xdm to handle requests from different X servers in different ways, you can specify a hostname or host list instead of *. Examples of this follow.
The following lines tell xdm to handle all queries from either host-a, host-b or host-c itself (Direct mode):
host-a host-b host-c
To tell xdm to send indirect queries from host-a to server-a or server-b, type
host-a server-a server-bIt could also be written
%hostlist server-a server-b host-a %hostlistYou can set up xdm to handle indirect queries using the chooser (our preferred method). In our next example, host-a gets a chooser window containing a list of all hosts that answer the BROADCAST, while everyone else gets only the list specified by %hostlist:
%hostlist server-a server-b host-a CHOOSER BROADCAST * CHOOSER %hostlist.Finally, to finish up the basic functionality, we can look at the Xresources file. I left mine with the defaults, but some might want to customize the look and feel a bit. In this file you can change colors, fonts and other style options. I've found the Chooser*geometry resource to be the most useful because it allows you to set the size of the chooser application window.
You can configure some administrative functions in xdm-config as well. Things like DisplayManager.errorLogFilelogfile will set the location of the log file. This log file contains the stderr output of xdm, Xsetup, Xstartup, Xsession and Xreset scripts.
Upon successful logon-process completion, xdm launches the script file specified in the session resource. This allows users to customize the behavior of the X sessions. Administrators will most likely want to check out the Xsession script. Users will want to create a $HOME/.xsession or $HOME/.Xclients file to customize the behavior of the session manager (i.e., start a window manager, a clock, etc.).
In order to test our configuration, we need to find X (which X). On my system, it's in /usr/X11R6/bin/X. In any case, you should end up seeing a logon screen. To test direct mode you would type
/usr/X11R6/bin/X -query remotexdmhost
For indirect broadcast mode type
/usr/X11R6/bin/X -broadcastAnd for indirect mode using the chooser, type
/usr/X11R6/bin/X -indirect remotexdmhostOnce these were working, I created the /etc/rc.d/init.d script to auto-start and auto-stop the xdm service. See the article on using the chkconfig utility in the April 2001 Linux Journal for more information.
Then, I created the following scripts to make life simple for my users. On their workstations, I create a file named /usr/bin/X11/startx.xdmcp. If the host is called “wkstn1”, then the file contains
#!/bin/sh /usr/X11R6/bin/X -indirect wkstn1
where hostname is the name of the xdm server (in my case the workstations are both an xdm server and an X server).
Next, I entered
mv /usr/bin/X11/startx /usr/bin/X11/startx.original chmod 755 /usr/bin/X11/startx.xdmcp ln -s /usr/bin/X11/startx.xdmcp /usr/bin/X11/startx
This allows any user who may be used to logging in to their workstation and typing startx to get a console, to instead receive a list of available hosts to log in to (including their own workstation).
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Introduction to MapReduce with Hadoop on Linux
- RSS Feeds
- Weechat, Irssi's Little Brother
- New Products
- Tech Tip: Really Simple HTTP Server with Python
- Reply to comment | Linux Journal
41 min 6 sec ago
- Didn't read
51 min 26 sec ago
- Reply to comment | Linux Journal
56 min 26 sec ago
- Poul-Henning Kamp: welcome to
3 hours 6 min ago
- This has already been done
3 hours 7 min ago
- Reply to comment | Linux Journal
3 hours 52 min ago
- Welcome to 1998
4 hours 41 min ago
- notifier shortcomings
5 hours 4 min ago
6 hours 41 min ago
- Android User
6 hours 43 min ago
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?