Section 7.4. Objective 4: Install and Customize a Window Manager Environment | LPI Linux Certification in a Nutshell (In a Nutshell (OReilly))

7.4. Objective 4: Install and Customize a Window Manager Environment

The selection of a desktop environment for X is a personal decision. At a minimum, you need a window manager such as twm to provide basic window frames, menus, and controls. On the more elaborate side, an integrated working environment such as KDE or GNOME offers a rich set of applications. Regardless of how you configure your desktop, it's important to understand some basic customization techniques.

7.4.1. Starting X and a Default Window Manager

Starting XFree86 can be as simple as issuing the X command as root. However, X alone doesn't give you a working environment. At the very least, you also need to start a window manager and an application and set up basic X access authority. (X authority configuration is beyond the scope of the LPIC Level 1 certification and is not covered in this book.) You may also wish to choose from among multiple desktop environments and window managers installed on your system.

7.4.1.1. The XFree86 start up process

Assuming for the moment that we're not using xdm, the process of starting X goes like this:

The user issues the startx command. This is a script provided by XFree86 and often modified by distributors and administrators. startx is intended as a frontend to xinit.
startx calls xinit with two main arguments:
1. An Xinitrc script, which contains X programs to run. This script could be .xinitrc from the user's home directory, or if that doesn't exist, a systemwide default found in /etc/X11/xinit/xinitrc.
2. Server options, such as X authority information.
xinit launches XFree86 and the chosen Xinitrc script.
XFree86 starts. Note that X itself does not provide any applications. They appear only as the result of the commands found in the Xinitrc script.
Client programs and a window manager found in the Xinitrc script start.

The contents of startx and the system default /etc/X11/xinit/xinitrc can vary from distribution to distribution and can be changed by administrators to suit local needs. They may also reference additional files, such as /etc/X11/xinit/Xclients, to determine which programs and window manager to run. Example 7-4 shows the contents of /etc/X11/xinit/xinitrc, a modified version of the original distributed with XFree86.

Example 7-4. A System default xinitrc

 #!/bin/sh # $XConsortium: xinitrc.cpp,v 1.4 91/08/22 rws Exp $ userresources=$HOME/.Xresources usermodmap=$HOME/.Xmodmap sysresources=/usr/X11R6/lib/X11/xinit/.Xresources sysmodmap=/usr/X11R6/lib/X11/xinit/.Xmodmap # merge in defaults and keymaps if [ -f $sysresources ]; then     xrdb -merge $sysresources fi if [ -f $sysmodmap ]; then     xmodmap $sysmodmap fi if [ -f $userresources ]; then     xrdb -merge $userresources fi if [ -f $usermodmap ]; then     xmodmap $usermodmap fi # start some nice programs (sleep 1; xclock -geometry 50x50-1+1) & (sleep 1; xterm   -geometry 80x50+494+51) & (sleep 1; xterm -geometry 80x20+494-0) & exec twm

In this example, resource and keyboard mappings are set, a few applications are launched, and the twm window manager is started. twm is installed as a basic default window manager on most distributions.

7.4.2. xterm et al.

One of the most important applications available to a system administrator working in a graphical environment is a terminal emulator. The standard terminal emulator distributed with X is xterm, which understands DEC VT and Tektronix graphics terminal protocols. The VT behavior that is emulated includes cursor positioning, character effects, and reverse video, among others. In essence, an xterm is a direct replacement for a hardware terminal.

xterm has a large resource configuration file located in /usr/lib/X11/app-defaults/XTerm that contains configurable menus, fonts, colors, and actions. You may customize this file to alter the default behavior of xterm on your system. These settings can also be overridden by resource settings contained in your own . Xdefaults file, located in your home directory.

There are numerous xterm replacements, such as rxvt, aterm, eterm, gnome-terminal, and konsole. Configuring these programs is well beyond the scope of the LPI Level 1 Objectives. See the documentation packages for more information.

On the Exam

You should be familiar with at least one of the popular X terminal programs available on your Linux system. Remember that some programs have system-wide configuration files that can be used to fine-tune their behavior and appearance.

7.4.3. X Libraries

Just as many executable programs are dependent on shared system libraries for their execution, most X applications require a number of X-specific libraries. XFree86 comes bundled with the necessary set of libraries for traditional X applications. However, many graphical programming projects are created using toolkits whose libraries are not included in the XFree86 distribution. In these cases, you need to install the required libraries before programs requiring them will compile or execute.

For example, the GIMP Toolkit (GTK) is used to build much of the GNOME desktop environment. This means that GTK must be installed on the system in order to run GNOME applications, including The GIMP (http://www.gimp.org).

Library dependency issues typically occur when you try new software. Either the compiler fails as you attempt to build the program, or the loader fails when you try to run a precompiled dynamic binary. In either case, you need to locate the correct version of the libraries and install them. It should be relatively easy to find recent versions of the popular libraries in your distribution's package format by visiting web sites of the library distributor or your Linux distribution.

To manually check for library dependencies , you may use the ldd utility, described fully in Chapter 4.

7.4.4. Remote X Clients

One of the fundamental design elements of the X Window System is that it is a network protocol, which allows for displays to occur remotely across a network. Many sites employ high-powered systems for computation and use desktop X servers (X terminals or Linux systems, for example) for display rendering.

To send the output from an X application to a remote machine, you need to set the DISPLAY environment variable. (Many X programs also include a command-line option to select the display.) This variable contains a description of the output destination and has three components:

 [host]:display[.screen]

host: This part of the description specifies the remote hostname on the network. It can be any valid hostname, fully qualified domain name, or IP address. host is optional; the local system is used if the host is not specified.
display: This specifies which display the output should be directed toward. A single system can manage many displays. Note that the colon is required even if the host is omitted.
screen: This optional parameter is used for multiheaded systems (i.e., systems with more than one monitor) and specifies on which output screen the application will appear.

Setting DISPLAY to "point to" a remote host display causes all subsequent X applications to be displayed there. For example:

 # export DISPLAY= yourhost :0.0  # xterm

In this example, the xterm is displayed on the first display on yourhost. (This example ignores X authentication issues.)

7.4.4.1. Examples

The default display on the local host:

:0

The default display on a remote host:

 yourhost:0

Display programs on the first screen of the second display found on the machine located at 192.168.1.2:

 192.168.1.2:1.0

Display programs on the first screen of the third display on yourhost:

 yourhost:2.0

On the Exam

You must be familiar with the DISPLAY environment variable and how to use it to direct X client applications to remote X servers.

7.4.5. X Security

Allowing untrusted applications to connect to your X display is a very bad idea. Rogue applications can snoop traffic between X applications and the X server (capturing keystrokes, for example), crash the X server, and do other bad things. There are two commonly-used ways to control access to the X server on Linux systems, host-based access control and MIT-MAGIC-COOKIE-1 authentication.

7.4.5.1. Host access control

When using host-based access control, the X server will allow connections only from hosts in the list. When this is the only form of access control in use, connections are typically allowed from localhost. Unfortunately, allowing connections from localhost means allowing connections from any user on the local system.

Hosts can be added to the list of allowed hosts by adding them to the file /etc/Xn.hosts (although this file is only scanned when the X server starts) or by using the xhost command.

Syntax

 xhost [[+-]hostname] [...]

Description

xhost is used to add hosts to or remove hosts from the X server's list of hosts that are allowed to connect.

xhost lists the current state of the host access control list when run with no options.

Frequently used options

+: Turn off access control. Access is granted to all hosts whether they are on the list or not.
-: Turn on access control. Access is granted only to hosts on the list.
[+]hostname: Add hostname to the list of hosts allowed to connect to the X server. (The + is optional.)
-hostname: Remove hostname from the list of hosts allowed to connect to the X server.

7.4.5.2. MIT-MAGIC-COOKIE-1 Authentication

The MIT-MAGIC-COOKIE-1 form of authentication is much more secure than host-based access control. In this authentication scheme, xdm creates a 128-bit key, or cookie, which is stored in the user's home directory in the file .Xauthority at login. When a client connects to the X server, it has to pass the cookie to be allowed to connect.

Since connections to the X server are not encrypted, this authentication method is most secure when used on local connections. Non-local connections should be tunnelled over ssh if they are not made over a secure (IPsec or other VPN) connection.

This is the most commonly used method of controlling access to the X server on modern Linux systems, but it is not covered in the LPI Level 1 Objectives.

Tip: This Topic is discussed in-depth in the Xsecurity manpage.