X Window System Administration
The xlogin program identifies and authorizes the user by accepting the user name and password. These are entered at the prompts in the xlogin window. If you want to change the xlogin display, take a look at the file pointed to by DisplayManager*resources, which on my system is called /etc/X11/xdm/Xresources. That file contains resource definitions for the xlogin and other programs started by xdm before the user's X session begins. Rather than having xlogin display the host name of my system, I prefer the message “Welcome to Linux” colored blue. To do this, I define the xlogin*greeting and xlogin*greetColor resources as shown in Listing 4.
A security consultant might wince at seeing a system that is configured to say “Welcome” to any user who happens to pass by and “Try Again” if they don't guess the right user name/password combination. I do this only on my home system. If you're working in an academic or corporate environment, you might want to use something like:
xlogin*greeting: CLIENTHOST xlogin*fail: Authorized Users ONLY!
In the above example, most of the colors are specified as RGB triplets in the form of #rrggbb. You can use 1 to 4 hexadecimal digits for each primary color, so to specify a not-totally-bright red, #c00, #c00000 and #c00000000000 are all equivalent. You can use color names like white (equivalent to #ffffff) or black (equivalent to #000), as in the above example. To get a list of color names X knows about, use the showrgb command. These two methods have been available in the X system since its first public release and are somewhat limited.
In release 5 of X11, new methods were added. One of the main problems with the older method is that a color specified in the 3-digit format, which provides only 4 bits for each primary color, may work fine for a display with an 8-bit color depth, but on a 16-bit or 24-bit display it will not look right. For example, #fff will display as bright white on an 8-bit display, but will be an off-white (#f0f0f0) on displays with 16- or 24-bits/pixel. You can get around this as I did above by always using at least 6-digit color specifications or using the new Xcms RGB method,
which automatically expands to #ffffff for displays of more than 8-bits/pixel. As with the original method, 1 to 4 hexadecimal digits are specified for each color. But with the new method, you can use a different number of digits for each. Instead of being taken as absolute numbers, the digits are used as scaling factors. For example, a single digit 9 represents 9/15, and 09 represents 9/255.
If you don't like using hexadecimal digits, you can use the RGBi (RGB intensity) format, like this:
That will also produce a bright white. The values for red, green and blue are specified as floating point numbers between 0.0 and 1.0, inclusive. There are also other, much more complex color spaces such as TekHVC (hue, value, chroma) and several CIE formats.
By now, you should have a very good idea of how to configure xdm, so I want to tie up a few loose ends before covering how to start xdm automatically.
One file you might want to take a look at is one named by the DisplayManager*session resource in xdm-config. This file (Xsession) is yet another script. It is run by xdm to create the user's X session. Typically, it defines the file .xsession-errors in the user's home directory to be the error log file for X programs (the “clients” of the client-server architecture). The .xsession-errors file is truncated to avoid confusion with errors that happened in the previous session, then both standard output and standard error output is redirected to it. In addition to your xdm error file, the .xsession-errors file is a good place to check for clues if your X session is not starting properly.
Next, the file .xsession in the user's home directory is executed. From the user's perspective, xdm uses the .xsession file in the same way startx uses .xinitrc. However, there are a couple of differences. First, .xinitrc must be a shell script, but .xsession can be any executable program (and must have its execute bit set). This allows for additional flexibility, although .xsession will usually be a shell script that is very similar (and possibly identical) to .xinitrc. It is possible to make one a symbolic link to the other to simplify management and to ensure that startx and xdm both create the same working environment.
Second, when the X session is started by xdm, the user has not yet started a login shell, and the shell's startup scripts (e.g., .bash_profile and .bashrc) have not been run. Because of this, it is necessary to set (in .xsession) those environment variables, such as PATH, that must be available for any programs run from .xsession or any window manager or other program started from that script.
I've just briefly described the default behavior of the /etc/xdm/Xsession script. Usually it is left alone, and customization on a per-user basis is done with the .xsession program in the user's home directory. However, it is also possible to create system-wide customizations by modifying Xsession.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Client-Side Performance
- Tibbo Technology's Tibbo Project System
- Sony Settles in Linux Battle
- Peppermint 7 Released
- Libarchive Security Flaw Discovered
- Maru OS Brings Debian to Your Phone
- The Giant Zero, Part 0.x
- Profiles and RC Files
- Git 2.9 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide