Gratuitous Window Dressing, Part 2

Hello, everyone, and welcome back to the sunniest corner on Linux street, the "SysAdmin's Corner", where all find pleasure in the exploration of their Linux system. That means you. Last time around, we decided to visit one of the more controversial areas of the Linux experience, the desktop. Love 'em or hate 'em, desktops and window managers are integral parts of the Linux experience (and a necess

The command line rules!

There. I feel much better. On to today's column.

If you have run the X Window System in any way shape or form,
you'll have accumulated a number of interesting files in your home
directory. They have names like ".Xclients", ".Xauthority", and
".xinitrc" to name a few. What are these mysterious (dare I say it
again) ".X" files? Well, before I
go into that, let's start by looking at the program that invariably
makes use of these files, a little something called
xinit.

xinit is the master program
for starting your graphical desktop. Using various ".X" files,
xinit will create, build and otherwise start up your X session. But
wait? Isn't that the idea behind
startx? Well, in a sense,
yes...and no. You see, the problem with using xinit to start your X
session is that it is so darn complicated (or at the very least,
wordy).

startx is actually just a
Bourne shell front end to xinit. In fact, if you take a look
through the file more /path_to/startx, you'll
find that after setting a number of variable, paths and so on,
xinit is finally called to start X. That path, by the way, is
pretty much always one of the following.

/usr/X11R6/bin
/usr/bin/X11

Remember that really boring X terminal that I had you start
in the first article of this series? What you did was create an
empty ".xinitrc" file with nothing but a single line that read
"xterm" in it. Then, I had you type startx to
bring up the X Window System. What you wound up with was a plain X
terminal that you could not move, resize or modify in any way.
About the only interesting thing that I can think of doing in that
environment is to type something like wmaker to
bring up a desktop manager so you can actually do work. But that's
a pretty weird way of doing things, and I digress.

You could have used the xinit command to start that xterm as
well. From a console screen, you would type this command:

xinit /usr/X11R6/bin/xterm

Similarly, you can start your desktop system from the command
line in the same way. For instance, I could start KDE with:

xinit /usr/bin/startkde

Here is what happens when you type startx.
The shell script checks for the existence of a local ".xinitrc"
file. In its absence, it then looks for the system wide version.
This is called simply "xinitrc" (no dot at the beginning) and is
usually found at /etc/X11/xinit/xinitrc. Your
personal xinitrc file, the one that begins with a dot, can be quite
simple, as in the case of the one line that said "exec
xterm". The system-wide version is a bit more complex and
checks for the existence of other .X files to pull into your
configuration. For those of you running Red Hat, things are a tiny
bit different. Your system-wide xinitrc file checks for the
existence of something called "Xclients" or, its local version,
".Xclients".

In a sense, .xinitrc and .Xclients serve pretty much the same
purpose. On a Red Hat system, you'll notice that in the absence of
a local .Xclients file, it looks to the Xclients file (sitting at
/etc/X11/xinit/Xclients). If you don't have an
.Xclients file, Red Hat starts GNOME by default. That's a global
setting. You can alter this behaviour (particularly if you have
several users logging in to one workstation) by modifying the
global Xclients file. Look for the line near the top of
/etc/X11/xinit/Xclients that says
"PREFERRED=". That variable is set to null right
now. Change it to whatever you would prefer as the default desktop.
If you wanted KDE, then that line would read as follows.

PREFERRED=startkde

For the GNOME crowd, replace starkde with
gnome-session. You rebels
out there running ICE or WindowMaker...we'll get to you soon
enough...in a follow-up article. Before I move on to something
else, I want to mention one other X file. This one is ".wm_style"
and, if you follow your global Xclients file, you'll see that it
looks to something called .wm_style. This is the
local user preference window manager. Just to make things extremely
complicated, this is another alternative to .Xclients that allows
for some free form expression. The global Xclients file looks for
several variations of the window manager names. For instance, if
you wanted to run WindowMaker, you could type
WindowMaker, Windowmaker,
WMaker or wmaker. Scan
through the /etc/X11/xinit/Xclients file and
you'll find the valid choices.

So, what other .X files do we have?
.xserverrc defines the X server
that you wish to run and is almost never used. The reason for this
is that, by default, you run one and only one X server, whether it
be your SVGA server, accelerated S3 server or a straight frame
buffer server -- namely the one that works for your specific video
card. If you don't set anything here, the system will run whatever
/etc/X11/X is linked to. For instance, on the
system I am using to write this article, X is linked to
/usr/X11R6/bin/XF86_Mach64.

For the most part, people don't generally muck about with
their X configurations once things work (more or less) pretty well
-- unless, of course, they are the type of people who hang out on
this corner. Nevertheless, those little
.x_something or .X_something
files that reside in your home directory do give you some amount of
control as to just how your X environment behaves. Additionally,
the .xinitrc file we talked about last week lets
you make other changes even after you have finished configuring the
X server with xf86config (or through the graphical install
process). For example, one of the great annoyances that people run
into is the misconfigured backspace key. You
know...you wind up never backspacing because it adds some strange
character you just can't shake.

Here's how you solve this annoyance. The easy fix is to
define a new key with xmodmap, a
utility designed specifically to remap keys for use under X. Let's
pretend that you have a terminal session open and that your
backspace key does not work. (If something is set up wrong, this is
often the case.) Type the following:

xmodmap -e 'keycode 22=BackSpace'

You can also use the command to modify the behavior of your
mouse. Let's say that you have a 3 button right-handed mouse, but
you are left-handed. It would be really nice if you could reverse
the order of the buttons. No problem. Try this.

xmodmap -e 'pointer = 3 2 1'

Suddenly, all of us right-handed people
get to feel what it's like for our left-handed
friends in a primarily right-handed world. If you want to put it
back to what it was, change the sequence "3 2 1" back to "1 2 3",
and everything will be as it was. Of course, this is not what we
want to do each and every time we restart X. To make the changes
permanent, add the command to your .xinitrc file just before the
exec window_manager command (as
discussed earlier).

We'll look at other ".X" files next time around and answer
the question "what do you do when one desktop isn't enough?" We'll
also start looking at different window managers and desktops and
talk about their impact on the way you work and your system's
limited resources. Then, I'll tell you how to override those nice
defaults to make your system look like your system and yours
alone.

Well, that should be enough to keep us all busy until next
time. Take care everyone, and remember that a little gratuitous
window dressing never hurt anyone. X needs no warning
labels.

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.