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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Returning Values from Bash Functions
- Rogue Wave Software's Zend Server
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader 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