Customizing the XDM Login Screen
“What's an XDM screen? Is this more cryptic Linux geek speak?” Well, yes, but I'm going to make it easy to understand, so you too can speak more like a Linux geek. If you are running the X Window System and have your system set up to boot straight into X and display the box asking for your login name and password, you are already running XDM. If you are running X using the startx command from a shell prompt, you aren't running XDM now—but you will soon be.
XDM has features other than the ones relating to the xlogin box. These other features are useful only if you are running X on multiple screens or machines. If you are interested, read the xdm man page. In this article, I will focus on basic cosmetic changes like the background image, programs to be displayed while waiting for a login, colors and fonts used in the login box and the size and position of the login box.
I will assume you have X set up and running correctly. If you don't have X working, please consult the documentation that came with your Linux distribution.
If you already have XDM up and running, you can skip ahead to the section on customizing XDM.
Setting up XDM requires you to change the run level of your system. The run level controls which mode the system is running in when it is rebooted. It can run in single user mode, multiuser mode without networking, multiuser mode with networking and multiuser mode with XDM running. My system is Red Hat 5.1 and it uses run level 3 for normal multiuser operation and run level 5 for XDM operation (multiuser, plus starting X at boot time). Edit your /etc/inittab file as the root user to change the run level of the system. First, make sure the XDM run level exists in /etc/inittab. It should look something like this and is usually located near the end of the file:
# Run XDM in run level 5 x:5:respawn:/usr/bin/X11/xdm -nodaemon
This is the entry from Red Hat 5.1. Slackware, Debian, SuSE and other Linux distributions with X should be similar. The run level number is 5 in this case, but may be different in your distribution.
You can test the XDM run level by typing init 5. If the login box appears and everything looks okay, you can change the default initlevel for bootup or experiment with the XDM changes without rebooting your system. If you don't want XDM to start at boot time, skip ahead to the next section.
Make a backup copy of the /etc/inittab file before you change anything. Rename it to something like inittab.bak.1, then look for the initdefault line, which is usually near the start of the /etc/inittab file. Since you are not yet running XDM, yours probably looks something like this:
To make your system start XDM at boot time, you change the 3 in this line to equal the number in the XDM run level line. In my case, I changed the 3 to a 5. Reboot your system, and a gray screen with a box in the middle asking for a user name and password will appear. You can log in and make sure everything is running okay, but that isn't necessary to complete this tutorial.
Now that XDM is up and running, we can start making changes. We will be switching between a text-mode login and the XDM screen. To get to the text mode console, press <H>ctrl<H>-<H>alt<H>-F1; to get back to the XDM screen, press <H>ctrl<H>-<H>alt<H>-F7. With some distributions, you may have to use <H>ctrl<H>-<H>alt<H>-F6 for the XDM screen.
Change to text mode and log in as root. Change directories to /usr/lib/X11/xdm and look at the files present in this directory. These files control the behavior of your system when XDM is started and a user logs in using XDM. The files we are concerned with are:
Xsetup (or Xsetup_0), which sets up the XDM screen
Xresources, which controls the behavior of the xlogin widget
Let's start by changing the background color to something other than gray. You can use any program which can display an image or color on the background, which is sometimes called the root window. One program included with the X distribution is xsetroot. Edit the Xsetup file and comment out any programs that may already be setting the background image, like xbanner, xv or xsetroot. Add the following line:
/usr/X11R6/bin/xsetroot -solid steelblue
Color names like steelblue are defined in the /usr/lib/X11/rgb.txt file. This maps color names to the actual Red/Green/Blue color settings, making things more readable. If you use a color name that has spaces in it, you need to enclose them in quotes, e.g., "navy blue".
Save the Xsetup file and switch back to the XDM display by using <H>ctrl<H>-<H>alt<H>-F7 (or F6, depending on which virtual console the X server is using for its display). Then restart XDM by pressing <H>ctrl<H>-<H>alt<H>-<H>backspace<H>. Note: do not use the <H>del<H> key. It will reboot the whole system instead of just restarting XDM.
You should now have a nice, solid steel-blue background. You can experiment with different colors until you find one that you like.
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
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SourceClear Open
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