Read LPI Linux Certification in a Nutshell Online
Authors: Adam Haeder; Stephen Addison Schneiter; Bruno Gomes Pessanha; James Stanger
Tags: #Reference:Computers
X.Org is distributed with a collection of fonts for most
basic purposes, including text displays in terminal windows and
browsers. For many users, the default fonts are adequate, but others may
prefer to add additional fonts to their system. A variety of fonts are
available, both free and commercially, from many sources, such as Adobe.
Some very creative fonts are created by individuals and distributed on
the Internet (a search should return some useful links to a query such
as “
X.org
fonts”).
X.Org makes fonts that it finds in the
font
path
available to client programs. A basic font path is
compiled into the X server, but you can specify your own font path using
theFontPath
directive in
theFiles
section of
xorg.conf
. The simple syntax is:
FontPath "path"
For example:
Section "Files"
FontPath "/usr/share/X11/fonts/misc"
FontPath "/usr/share/X11/fonts/cyrillic"
FontPath "/usr/share/X11/fonts/100dpi/:unscaled"
FontPath "/usr/share/X11/fonts/75dpi/:unscaled"
FontPath "/usr/share/X11/fonts/Type1"
FontPath "/usr/share/X11/fonts/100dpi"
FontPath "/usr/share/X11/fonts/75dpi"
FontPath "/usr/share/fonts/X11/misc"
# path to defoma fonts
FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
EndSection
This group ofFontPath
directives creates a font path consisting of eight directories, all
under
/usr/share/X11/fonts
. When X starts, it
parses these font directories and includes their contents in the list of
fonts available during the X session.
Adding new fonts is straightforward. (For this brief
discussion, we assume that we’re working with Type 1 fonts. Other
types, such as TrueType fonts, may require additional configuration,
depending on your version of
XFree86.) First, a suitable directory should be created
for the new fonts, such as
/usr/share/X11/fonts/local
or
/usr
/local/fonts
. You may
wish to separate your own fonts from the default X.Org directories to
protect them during upgrades. After the fonts are installed in the new
directory, the
mkfontdir
utility is run to
catalog the new fonts in the new directory. New entries are added to
the
xorg.conf
file to include the path for new
fonts. For example:
FontPath "/usr/local/fonts"
At this point, the X server can be restarted to recognize the
new fonts, or the fonts can be dynamically added using the
xset
command:
#xset fp+ /usr/local/fonts
xset
is beyond the scope of the LPIC Level
1 exams.
On the Exam
Be sure you understand how the X font path is created and how
to extend it to include additional directories. Knowledge of the
internal details of font files is not necessary.
On a network with multiple workstations, managing fonts manually
for each system can be time consuming. To simplify this problem, the
administrator can install all of the desired fonts on a single system
and then run
xfs
, the X fonts server, on that
system. On a local system,
xfs
off-loads the work
of rendering fonts from the X server, which means the X server can do
other tasks while fonts are being rendered. This is especially
noticeable on slower systems or systems without a Floating Point Unit
(FPU).
The X font server is a small daemon that sends fonts to clients
on both local and remote systems. Some Linux distributions use
xfs
exclusively, without a list of directories in
the manually created font path. To include
xfs
in
your system’s font path, add aFontPath
directive like this:
Section "Files"
RgbPath "/usr/share/X11/fonts/rgb"
FontPath "unix/:-1"
EndSection
If you install
xfs
from a package from your
distribution, it is probably automatically configured to start at boot
time and run continually, serving fonts to local and remote client
programs. To start
xfs
manually, simply enter the
xfs
command. For security purposes, you may wish
to run
xfs
as a nonroot user.
xfs
is configured using its configuration file,
/etc/X11/fs/config
.
On the Exam
Fonts are administered primarily through the local machine,
reducing network services that need to be enabled on the remote
server. Coverage here is for awareness that fonts may be
administered remotely via
xfs
.
The X Window System also has many built-in customization
features. Many X
applications
are
programmed with a variety of
resources
, which are
configuration settings that can be externally manipulated. Rather than
have a configuration utility built into each application, applications
can be written to examine the contents of a file in the user’s home
directory. The
.Xresources
file contains a line for
each configured resource in the following form:
program
*resource
:value
This line can be translated as follows:
program
is the name of a
configurable program, such asemacs
orxterm
.
resource
is one of the configurable
settings allowed by the program, such as colors.
value
is the setting to apply to
the resource.
For example, the following is an excerpt from
.Xresources
that configures colors for anxterm
:
xterm*background: Black
xterm*foreground: Wheat
xterm*cursorColor: Orchid
xterm*reverseVideo: false
On the Exam
You should be aware of X resources and the function of the
.Xresources
file. In particular, you should
understand that X applications will look in the
.Xresources
file
for settings. You should also be able to construct a resource setting
given a particular example, but you do not need to be able to generate
a configuration file from scratch.
The display manager is the tool to manage X sessions on
physical displays both locally and across the network. Part of its job is
to handle user authentication through a graphical login screen, which
replaces the familiar text-mode login. There are three primary display
managers implemented with Linux:
xdm
,
kdm
, and
gdm
.
The X display manager (
xdm
) is a
program that allows for a graphical session to begin on an X
server.
xdm
is distributed as part of X.Org and is
configured by a series of files located in
/etc/X11/xdm
. These
files include:
This file controls inbound requests from remote
hosts.
This file is similar to
.Xresources
, discussed earlier. It holds
configuration information for some
xdm
resources, including the graphical login screen. This file can be
edited to modify the appearance of the
xdm
login screen.
This file associates the X display names (:0
,:1
, ...) with either the local X server
software or a foreign display, such as an X terminal.
This file contains the script
xdm
launches after a successful login. It
usually looks for
.Xsession
in the user’s
home directory and executes the commands found there. If such a
file doesn’t exist,
Xsession
starts a default
window manager (or environment) and applications.
This file is a script started before the graphical
login screen. It often includes commands to set colors, display
graphics, or run other programs. This script is executed as
root
.
This file associates
xdm
configuration resources with the other files in this list. It
usually isn’t necessary to make changes in this file unless an
expert administrator plans to customize
xdm
configuration.
xdm
uses the X server to run on your local
display. Therefore, you must have a working X configuration prior to
using a display manager. Then, to start
xdm
,
simply enter it as
root
:
#xdm
xdm
launches the X server and displays the
graphical login, and you can log in as usual.
xdm
then starts your graphical environment. After you log out,
xdm
resets and again displays the login
screen.
Most Linux distributions enable
virtual consoles. You can switch among them using the
key combinations Ctrl-Alt-F1, Ctrl-Alt-F2, and so on. (The Ctrl is
required only when switching from an X console to a text or other X
console.) Typically, the first six consoles are set up as text-mode
screens, and X launches on console 7 (Ctrl-Alt-F7) or the first TTY
not running
mingetty
or some other
getty
process. This means that, as with
startx
, your original text-mode console remains
unchanged after you manually start
xdm
.
Therefore, you must log out of your text-mode console if you plan to
leave the system unattended with
xdm
running
manually.
If you want to stop
xdm
, you first must be
sure that all of the X sessions under its management are logged out.
Otherwise, they’ll die when
xdm
exits and you
could lose data. Simply stop the
xdm
process
using
kill
or
killall
from a
text console:
#killall xdm
Of course,
xdm
isn’t very useful for your
local system if you must always start it manually. That’s why most
Linux distributions include a boot-time option to start
xdm
for you, eliminating the text-mode login
completely.
For Linux systems using the System V–style initialization, a
runlevel is usually reserved for login under
xdm
.
This line at the bottom of
/etc/inittab
instructs
init
to start
xdm
for
runlevel 5:
# Run xdm in runlevel 5
x:5:respawn:/usr/X11R6/bin/xdm -nodaemon
Using this configuration, when the system enters runlevel 5,
xdm
starts and presents the graphical login as
before. See
Chapter 4
for more
information on runlevels.
It’s also possible to automatically start
xdm
simply by adding it to the end of an
initialization script, such as
rc.local
. This
method offers less control over
xdm
but may be
adequate for some situations and for Linux distributions that don’t
offer runlevels.
You may wish to personalize the look of
xdm
for your system. The look of the graphical login screen can be altered
by manipulating the resources in
/etc/X11/xdm/Xresources
. (Note that
Xresources
uses!
to start comments.) For example, the
following excerpt shows settings to control the greeting
(
Welcome to Linux on
smp-pc
), other prompts, and
colors:
! Xresources file
xlogin*borderWidth: 10
xlogin*greeting: Welcome to Linux on CLIENTHOST
xlogin*namePrompt: Login:\040
xlogin*fail: Login incorrect - try again!
xlogin*failColor: red
xlogin*Foreground: Yellow
xlogin*Background: MidnightBlue
You can also include command-line options to the X server in
/etc/X11/xdm/
Xservers
if you wish to
override those found in
/etc/X11/xorg.conf
. For
example, to change the default color depth, add the
-bpp
(bits per pixel) option for the local
display:
# Xservers file
:0 local /usr/X11R6/bin/X -bpp 24
To include additional X programs or settings on the graphical
login screen, put them in
/etc/X11/xdm/Xsetup_0
.
In this example, the background color of the X display is set to a
solid color (in hexadecimal form), and a clock is added at the
lower-righthand corner of the screen:
#!/bin/sh
# Xsetup
/usr/X11R6/bin/xsetroot -solid "#356390"
/usr/X11R6/bin/xclock -digital -update 1 -geometry -5-5 &
Note that in this example,
xsetroot
exits
immediately after it sets the color, allowing the
Xsetup_0
script to continue.
xclock
, however, does not exit and must be put
into the background using an&
at the end of the command line. If such commands are not placed into
the background, the
Xsetup_0
script hangs, and
the login display does not appear.
X terminals
are a breed of low-cost
display devices for X. They are usually diskless systems that implement
an X server and drive a monitor. Such devices can be configured to
access a remote host to find an
xdm
daemon or will
broadcast to the entire network looking for a “willing host” to offer
xdm
services. The selected system will run an X
session across the network with the X terminal as the target display.
With this setup, a large number of relatively inexpensive X terminals
can make use of a few high-powered host systems to run graphical
clients.
To use an X terminal with your host,
xdm
must first be running on the host machine. The host listens for
inbound connections from the X terminals using
XDMCP
, the
xdm
Control
Protocol (the default port for
xdmcp
is 177).
When a request is received,
xdm
responds with the
same graphical login screen that’s used on the local system. The
difference is that the X server is implemented in the X terminal
hardware, not in the XFree86 software on the
xdm
host, and all of the graphics information is transmitted over the
network.
On the Exam
You should be aware of the configuration files for
xdm
, how they are used, and where they are
located. In particular, remember that the
Xresources
file controls graphical login
properties. Also remember that
xdm
can be
started using a special runlevel and that
xdm
must be running for X terminals to connect via XDMCP.
You can configure access to your system’s
xdm
daemon in the
/etc/X11/xdm/
Xaccess
file. This file is a
simple list of hosts that are to be restricted or enabled. To enable a
host, simply enter its name. To restrict a host, enter its name with
an exclamation point (!
) before it.
The*
wildcard is also allowed to handle groups of
devices.
The following example allows access to all X terminals on the
local domain but prohibits access fromxterm1
on an outside domain:
*.example.com
!xterm1.anotherexample.com
KDM
is built off the XDM design and
is responsible for the graphical login screen that handles user
authentication to the system and starts a user session. The
KDM
is the display manager for the
KDE
desktop environment.
KDM
is distributed by KDE.org and is
configured by a series of files located in
/etc/X11/kdm
. To see the version that is available
for install, use the package manager to find this information and to
install the package:
#yum info kdm
Loaded plugins: refresh-packagekit
Available Packages
Name : kdm
Arch : i586
Version : 4.2.4
Release : 5.fc11
Size : 1.5 M
Repo : updates
Summary : The KDE login manager
URL : http://www.kde.org/
License : GPLv2
Description: KDM provides the graphical login screen, shown shortly after boot
: up, log out, and when user switching.
Use the
yum
package manager to install the
KDM
interface.# yum install kdm
Loaded plugins: refresh-packagekit
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package kdm.i586 0:4.2.4-5.fc11 set to be updated
--> Processing Dependency: kdelibs4(x86-32) >= 4.2.4 for package: \
kdm-4.2.4-5.fc11.i586
--> Processing Dependency: kde-settings-kdm for package: kdm-4.2.4-5.fc11.i586
--> Processing Dependency: libkdeui.so.5 for package: kdm-4.2.4-5.fc11.i586
--> Processing Dependency: libkio.so.5 for package: kdm-4.2.4-5.fc11.i586
--> Processing Dependency: libknewstuff2.so.4 for package: kdm-4.2.4-5.fc11.i586
--> Processing Dependency: libkde3support.so.4 for package: kdm-4.2.4-5.fc11.i586
--> Processing Dependency: libkdecore.so.5 for package: kdm-4.2.4-5.fc11.i586
--> Processing Dependency: libqimageblitz.so.4 for package: kdm-4.2.4-5.fc11.i586
--> Running transaction check
---> Package kde-settings-kdm.noarch 0:4.2-10.20090430svn.fc11 set to be updated
--> Processing Dependency: kde4-macros(api) = 2 for package: kde-settings-kdm-4.2-
10.20090430svn.fc11.noarch
--> Processing Dependency: leonidas-kde-theme for package: kde-settings-kdm-4.2-
10.20090430svn.fc11.noarch
--> Processing Dependency: xterm for package: \
kde-settings-kdm-4.2-10.20090430svn.fc11.noarch
--> Processing Dependency: xorg-x11-xdm for package: kde-settings-kdm-4.2-
10.20090430svn.fc11.noarch
---> Package kdelibs.i586 6:4.2.4-6.fc11 set to be updated
--> Processing Dependency: soprano(x86-32) >= 2.2 for package: \
6:kdelibs-4.2.4-6.fc11.i586
--> Processing Dependency: strigi-libs(x86-32) >= 0.6.3 for package: \
6:kdelibs-4.2.4-6.fc11.i586
--> Processing Dependency: libsoprano.so.4 for package: \
6:kdelibs-4.2.4-6.fc11.i586
--> Processing Dependency: kde-settings for package: \
6:kdelibs-4.2.4-6.fc11.i586
--> Processing Dependency: libsopranoclient.so.1 for package: \
6:kdelibs-4.2.4-6.fc11.i586
--> Processing Dependency: libstreams.so.0 for package: \
6:kdelibs-4.2.4-6.fc11.i586
--> Processing Dependency: kdelibs-common for package: \
6:kdelibs-4.2.4-6.fc11.i586
--> Processing Dependency: libstreamanalyzer.so.0 for package: \
6:kdelibs-4.2.4-6.fc11.i586
---> Package qimageblitz.i586 0:0.0.4-0.5.svn706674.fc11 set to be updated
--> Running transaction check
---> Package kde-filesystem.noarch 0:4-25.fc11 set to be updated
---> Package kde-settings.noarch 0:4.2-10.20090430svn.fc11 set to be updated
--> Processing Dependency: oxygen-icon-theme for package: kde-settings-4.2-
10.20090430svn.fc11.noarch
---> Package kdelibs-common.i586 6:4.2.4-6.fc11 set to be updated
---> Package leonidas-kde-theme.noarch 0:11.0.1-1.fc11 set to be updated
--> Processing Dependency: leonidas-backgrounds-kdm >= 11.0.0-1 \
for package: leonidas-kde-theme-11.0.1-1.fc11.noarch
---> Package soprano.i586 0:2.2.3-1.fc11 set to be updated
--> Processing Dependency: libclucene.so.0 for package: \
soprano-2.2.3-1.fc11.i586
---> Package strigi-libs.i586 0:0.6.5-2.fc11 set to be updated
--> Processing Dependency: libexiv2.so.5 for package: \
strigi-libs-0.6.5-2.fc11.i586
---> Package xorg-x11-xdm.i586 1:1.1.6-10.fc11 set to be updated
---> Package xterm.i586 0:242-3.fc11 set to be updated
--> Running transaction check
---> Package clucene-core.i586 0:0.9.21-3.fc11 set to be updated
---> Package exiv2-libs.i586 0:0.18.2-2.fc11 set to be updated
---> Package leonidas-backgrounds-kdm.noarch 0:11.0.0-1.fc11 \
set to be updated
---> Package oxygen-icon-theme.noarch 0:4.2.2-1.fc11 set to be updated
--> Finished Dependency Resolution
Dependencies Resolved
===============================================================================
Package Arch Version Repository Size
===============================================================================
Installing:
kdm i586 4.2.4-5.fc11 updates 1.5 M
Installing for dependencies:
clucene-core i586 0.9.21-3.fc11 fedora 350 k
exiv2-libs i586 0.18.2-2.fc11 updates 889 k
kde-filesystem noarch 4-25.fc11 fedora 22 k
kde-settings noarch 4.2-10.20090430svn.fc11 fedora 38 k
kde-settings-kdm noarch 4.2-10.20090430svn.fc11 fedora 25 k
kdelibs i586 6:4.2.4-6.fc11 updates 14 M
kdelibs-common i586 6:4.2.4-6.fc11 updates 367 k
leonidas-backgrounds-kdm noarch 11.0.0-1.fc11 fedora 4.6 M
leonidas-kde-theme noarch 11.0.1-1.fc11 fedora 1.1 M
oxygen-icon-theme noarch 4.2.2-1.fc11 fedora 15 M
qimageblitz i586 0.0.4-0.5.svn706674.fc11 fedora 59 k
soprano i586 2.2.3-1.fc11 fedora 692 k
strigi-libs i586 0.6.5-2.fc11 updates 476 k
xorg-x11-xdm i586 1:1.1.6-10.fc11 updates 139 k
xterm i586 242-3.fc11 fedora 368 k
Transaction Summary
===============================================================================
Install 16 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 39 M
Is this ok [y/N]:
This installation will also install the
KDE
window manager. Once this has been installed, you can select the session
you wish to boot into at startup using the session menu. The main
configuration file to control the way the
KDM
operates is called
kdmrc
, which is
located in
/etc/kde/kdm
. The following is an
example of the contents of this file:
# KDM master configuration file
#
# Definition: the greeter is the login dialog, i.e., the part of KDM
# which the user sees.
#
# You can configure every X-display individually.
# Every display has a display name, which consists of a host name
# (which is empty for local displays specified in {Static|Reserve}Servers),
# a colon, and a display number. Additionally, a display belongs to a
# display class (which can be ignored in most cases; the control center
# does not support this feature at all).
# Sections with display-specific settings have the formal syntax
# "[X-" host [":" number [ "_" class ]] "-" sub-section "]"
# You can use the "*" wildcard for host, number, and class. You may omit
# trailing components; they are assumed to be "*" then.
# The host part may be a domain specification like ".inf.tu-dresden.de".
# It may also be "+", which means non-empty, i.e. remote displays only.
# From which section a setting is actually taken is determined by these
# rules: