LPI Linux Certification in a Nutshell (50 page)

Read LPI Linux Certification in a Nutshell Online

Authors: Adam Haeder; Stephen Addison Schneiter; Bruno Gomes Pessanha; James Stanger

Tags: #Reference:Computers

BOOK: LPI Linux Certification in a Nutshell
12.2Mb size Format: txt, pdf, ePub
Configuring GDM

GDM
is the window manager for the
GNOME desktop environment. GNOME is the default graphical
desktop environment for Fedora and Ubuntu. The
GDM
window manager will be loaded automatically during the graphical
installation of these operating systems. If you need to install the
GNOME environment and the
GDM
manager, you can use
the package manager by issuing a command similar to:

#
yum groupinstall "GNOME Desktop Environment"

The main configuration file for
GDM
is either
gdm.conf
or
custom.conf
, depending on the distribution of
Linux. The configuration file will be located in
etc/gdm/gdm.conf
. This file contains sections for
configuring the way the login process operates, the session
environments, and the look and feel of the manager or “greeter” that the
user is presented with at the initial login screen. The file is heavily
commented for each section of the sections. The following is an example
of this configuration file’s contents:

# For full reference documentation see the GNOME help browser under
# GNOME|System category. You can also find the docs in HTML form on
# http://www.gnome.org/projects/gdm/
#
# NOTE: Some values are commented out, but show their default values. Lines
# that begin with "#" are considered comments.
#
# Have fun!
[daemon]
# Automatic login, if true the first local screen will automatically logged
# in as user as set with AutomaticLogin key.
AutomaticLoginEnable=false
AutomaticLogin=
# Timed login, useful for kiosks. Log in a certain user after a certain
# amount of time.
TimedLoginEnable=false
TimedLogin=
TimedLoginDelay=30
# The GDM configuration program that is run from the login screen, you
# should probably leave this alone.
#Configurator=/usr/sbin/gdmsetup --disable-sound --disable-crash-dialog
# The chooser program. Must output the chosen host on stdout, probably you
# should leave this alone.
#Chooser=/usr/lib/gdm/gdmchooser
# The greeter for local (non-xdmcp) logins. Change gdmlogin to gdmgreeter
# to get the new graphical greeter.
Greeter=/usr/lib/gdm/gdmgreeter
# The greeter for xdmcp logins, usually you want a less graphically
# intensive greeter here so it's better to leave this with gdmlogin
#RemoteGreeter=/usr/lib/gdm/gdmlogin
Switching display managers

More than one desktop environment may be run on the
Linux system at any time. If both the KDE and GNOME environments are
installed, you may switch between them during the graphical login by
selecting the environment from the session menu. Both the
KDM
and
GDM
managers will
have the session menu available at startup. It is possible to run only
one of the display managers, but you can change which display manager
is presented during startup. In order to change from the default
GDM
manager, you will need to update the
/etc/sysconfig/desktop
file by
editing the following:

desktop= "kde"
displaymanager= "kdm"

Another way to switch between the
KDM
and
GDM
managers is to
install the
switchdesk
tool using a package
manager and then execute the application.
switchdesk
allows users to simply switch between
various desktop environments installed on the system. Not all display
managers are supported; however, it does support KDE and GNOME:

$
switchdesk kde
Red Hat Linux switchdesk 4.0
Copyright (C) 1999-2004 Red Hat, Inc
Redistributable under the terms of the GNU General Public License
Desktop now set up to run KDE.

On the Exam

Remember that you may run more than one desktop environment at
a time with Linux. You will need to know how you can switch
environments and possibly make either the KDM or GDM the default
window manager.

Objective 3: Accessibility

There are a wide range of physical disabilities that can
impair a user’s ability to interact with computers and applications. Most
of the Linux distributions come with some assistive technology tools built
in for visually and physically challenged users. One of the earliest tools
was
Emacspeak (currently at version 31), a free screen reader
that allows users to interact independently with the computer. It is
available for most versions of Linux. The Emacspeak desktop works with a
variety of applications, including browsers.

Screen readers are software applications that provide
translation of the information on the computer screen to an audio output
format. The translation is passed to the speech synthesizer, and the words
are spoken out loud. Currently, fully functional screen readers are
available for Linux only in console mode. The following are some of the
most common screen readers:

Emacspeak

This tool is classified as a screen reader, but the creator
calls it an “audio desktop.” It is an excellent nongraphical,
text-based interface for users who are visually impaired. This
application can be used as a screen reader in conjunction with a
hardware synthesizer or IBM ViaVoice® Run-time text-to-speech
application
.

Jupiter Speech System

An older screen reader for Linux in console mode. This
package also includes the ability to read logfiles of an interactive
session and contains customizable speech commands.

Speakup

A screen review package for the Linux operating
system. It requires a hardware speech synthesizer such as the
DecTalk Express. It allows computer interaction by verbal commands,
in addition to synthesized voice feedback from the
console
.

Orca

A screen reader designed to work with applications and
toolkits that support the assistive technology service provider
interface (AT-SPI). This includes the GNOME desktop and its
applications, OpenOffice, Firefox, and the Java platform. Orca may
be enabled under the system/preferences menu from the GNOME
environment. Orca includes support for assistive tools for speech,
Braille, and screen magnification.

Here are some other products that serve as screen magnifiers, which
enable users who are partially blind to view selected areas of the screen,
similar to using a magnifying glass:

SVGATextmode

This product enlarges or reduces the font size for
users who prefer to work in console mode. The normal text screen
that Linux provides is 80 characters across and 25 vertically. After
SVGATextmode is installed, the text can be displayed much larger,
for example, 50 characters across and 15 vertically. The program
does not offer the ability to zoom in and out, but the user can
resize when necessary. Do not run try to run SVGATextmode from an X
Windows terminal; you must be in console mode for the display to
function properly.

Xzoom

A screen magnifier that allows the user to magnify,
rotate, or mirror a portion of the screen.

Some additional applications that may be used to support Braille
devices in conjunction with the computer include:

BrLTTY

Supports parallel port and USB Braille displays and
provides access to the Linux console. It drives the terminal and
provides complete screen review capabilities. It is available at
http://dave.mielke.cc/brltty/
.

Blind + Linux = BLINUX

Provides documentation, downloads, and a mailing list
that focus on users who are blind. Information and software packages
are available at
http://leb.net/blinux
.

The Linux operating system also has built-in features that allow for
additional keyboard configuration. In some of the X Windows desktops,
these settings can be changed from the preferences menu. An application
developed for X Windows called AccessX provides a graphical user interface
for configuring all of the following AccessX
keyboard settings:

StickyKeys

Enables the user to lock modifier keys (for example,
Ctrl and Shift), allowing single-finger operations in place of
multiple key combinations.

MouseKeys

Provides alternative keyboard sequences for cursor
movement and mouse button operations.

SlowKeys

This setting requires the user to hold the key down
for a specified period of time before the keystroke is accepted.
This prevents keystrokes that are pressed accidentally from being
sent.

ToggleKeys

Sounds an audio alert that warns the user that a
keystroke created a locking state for keys, such as Caps Lock and
Num Lock.

RepeatKeys

Allows a user with limited coordination additional
time to release keys before multiple key sequences are sent to the
application.

BounceKeys or Delay Keys

These settings have a delay between keystrokes. This
function can help prevent the system from accepting unintentional
keystrokes.

Onscreen keyboards enable a user to select keys using a pointing
device, such as a mouse, trackball, or touch pad, and can be used in place
of a standard keyboard.

GTkeyboard

An onscreen, graphical keyboard that can be downloaded
at
http://opop.nols.com/gtkeyboard.html
.

GNOME Onscreen Keyboard (GOK)

An onscreen, graphical keyboard that enables users to
control their computers without relying on a standard keyboard or
mouse. More information is available at
http://www.gok.ca
.

Remember that most Linux distributions will have some form of
assistive technology built into the GUI, accessible through system
settings or preferences. Most of these include at least the ability to
modify mouse and keyboard actions and to add a screen reader or
magnification. Some, as with GNOME and the Orca project, will have more
support, including the ability to add an onscreen keyboard.

On the Exam

You should be aware of the various assistive technology tools that
are available for use in Linux. Many of the tools may be installed
already in the operating system and just need to be enabled from the
system settings or preferences menu. More information about assistive
technology for Linux users may be found at
Ability Net
Gate
.

Chapter 15. Administrative
Tasks (Topic 107)

As a system administrator in a multiuser environment, much of
your activity is
related
to users and
their system accounts, the automation of routine tasks, and
internationalization. This chapter covers these administrative aspects of
Linux as required for Exam 102. This chapter has three Objectives:

Objective 1: Manage User and Group Accounts and Related
System Files

Candidates should be able to add, remove, suspend, and change
user accounts. Tasks to adding and removing groups, and changing
user/group info in password/group databases. This Objective also
includes creating special-purpose and limited accounts. Weight:
5.

Objective 2: Automate System Administration Tasks by
Scheduling Jobs

Candidates should be able to use
cron
or
anacron
to run jobs at regular
intervals and to use
at
to run jobs at a specific
time. Tasks include managing
cron
and
at
jobs and configuring user access to
cron
and
at
services.
Weight. 4.

Objective 3: Localization and
Internationalization

Candidates should be able to localize a system in a language
other than English. Additionally, candidates should understand why
LANG=C is useful when scripting. Weight: 3.

Objective 1: Manage User and Group Accounts and Related System
Files

Whether on a corporate server or personal desktop machine,
managing user accounts is an important aspect of running a Linux system.
The
root
, or
superuser, account is established when you first install
Linux. Unlike single-user systems (such as MS-DOS),
multiuser systems require the notion of an
owner
for files, processes, and other
system objects. An owner may be a human system user or a system service,
such as a web server. Each of these owners is differentiated from others
by a unique
user account
, which is assigned to it
by the system administrator.

User Accounts and the Password File

When a new user account is added to a Linux system, an entry is
added to a list of users in the
password file
, which is stored in
/etc/passwd
. This file gets its name from its
original use, which was to store user information, including an
encrypted form of the user’s password. The password file is in plain
text and is readable by everyone on the system. Each line in the
password file contains information for a single user account, with
fields separated by colons, as illustrated in
Figure 15-1
.

Figure 15-1. Sample lines from a password file

Each line in the file contains information for a single system
account and includes the following pieces of information in
colon-separated fields:

Username

The first field on a line is a unique
username
for the person or service using the
account.

Password

Each username has an associated
password
. The password stored in this field
is in a hashed (unreadable and unrecoverable) form. Despite the
hash, for security reasons, most systems now store user passwords
in a separate
/etc/shadow
file that has
restricted permissions. If the password is not included, its field
is filled by the letter
x
,
which indicates that the shadow password system is in use.

User ID

Each username requires a unique
user
identifier
, or UID. The UID is simply a nonnegative
integer. The
root
account is assigned the UID
of 0, which gives it global privilege on the system. By
convention, the UID values from 0 to 99 are reserved for
administrative use; those over 99 are for regular system users.
It’s not unusual for new system accounts to start at 500.

Group ID

Each username has a default
group
identifier
, or GID. The GID is also a nonnegative
integer. Groups are a way of allowing users to share files through
mutual
group membership.
Group numbers and their associated names are specified in the
/etc/group
file. The GID stored for each user
in
/etc/passwd
is its default group ID,
though a user may belong to many groups.

Full name (or other comment)

The user’s full name or other information is stored as plain
text. This field may contain spaces.

Home directory

The
home directory
is the default
directory in the filesystem for the user’s account. If a new
account is meant for a person, a home directory will probably be
created in the filesystem with standard configuration files that
the user may then personalize. The full path to that home
directory is listed here.

Default shell

This field specifies the default shell for the user
or service, which is the shell that runs when the user logs in or
opens a shell window. In most cases, the shell will be
/bin/bash
, but it can be any shell, or even
another executable program. (Nonshell entries may be seen in the
case of some services that should own files but never log in
interactively. You may see the shell field filled with
/bin/false
, a small program that does nothing
but yield an error and terminate. This ensures that a service
account is secured from login.)

Looking back at
Figure 15-1
, the first line shows the
definition of the
root
account with UID and GID of
0, a name of
root
, a home directory of
/root
, and a default shell of
/bin/bash
. The second line shows a standard user
account for Jeff Dean, with UID and GID of 500. The home directory is
/home/jdean
, and the default shell is
/bin/tcsh
.

More detailed information about
/etc/passwd
can be found in
Chapter 22
.

Groups and the Group File

In addition to ownership by individual system users, filesystem
objects have separate ownership settings for groups of users. This
group ownership
allows an additional level of
user-specific access control beyond that of a file’s individual owner.
Groups are similar to users in their administration and are defined in
the file
/etc/group
. Like the
passwd
file, the
group
file
contains colon-separated fields:

Group name

Each group must have a unique name.

Group password

Just as user accounts have passwords, groups can have
passwords for their membership. If the password field is empty,
the group does not require a
password
.

Group ID

Each group requires a unique GID. Like a UID, a GID is a
nonnegative integer.

Group member list

The last field is a list of group members by username,
separated by commas.

Together, these pieces of information define a group; colons
separate the fields. Here are a few sample lines from a group
file:

root:x:0:root
pppusers:x:230:jdean,jdoe
finance:x:300:jdean,jdoe,bsmith
jdean:x:500:
jdoe:x:501:
bsmith:x:502:

In this example, both
jdean
and
jdoe
are members of the
pppusers
group (GID 230), and
jdean
,
jdoe
, and
bsmith
are all members of the
finance
group (GID 300). The remaining groups,
root
,
jdean
,
jdoe
, and
bsmith
, are
single-user groups. These groups are not intended for multiple users and
do not contain additional members. For security purposes, it is common
to create new users with their own personal single-user group. Doing
this enhances security because new files and directories will not have
group privileges for other users. (Although the GID of these single-user
groups may match the UID of the user for which they’re created, there is
no direct relationship between the UID and GID.)

The Shadow Password and Shadow Group Systems

Encrypted passwords must be secure from all users on the
system, while leaving the remainder of the information in
/etc/passwd
world-readable. To do this, the
encrypted password is moved to a new file that
shadows
the password file line for line. The file
is aptly called
/etc/shadow
and is generally said
to contain
shadow passwords
. Here are a couple of
example lines from a shadow file:

root:$1$oxEaSzzdXZESTGTU:10927:0:99999:7:-1:-1:134538444
jdean:$1$IviLopPn461z47J:10927:0:99999:7::11688:134538412

The first two fields contain the username and the encrypted
passwords. The remaining fields contain optional additional information
on password aging
information
.

Group passwords and shadow groups

Just as user accounts listed in
/etc/passwd
are protected by encrypted passwords, groups listed in
/etc/group
can also be protected by passwords. A
group password can be used to allow access to a group by a user
account that is not actually a member of the group. Account users can
use the
newgrp
command to change their default
group and enter the group password. If the password is correct, the
account is
granted
the group
privileges, just as a group member would be.

The group definition file, like the password file, is readable
by everyone on the system. If group passwords are stored there, a
dictionary attack could be made against them. To protect against such
attacks, passwords in
/etc/group
can be shadowed.
The protected passwords are stored in
/etc/gshadow
, which is readable only by
root
. Here are a few sample lines from a
gshadow
file:

root:::root
pppusers:!::
finance:0cf7ipLtpSBGg::
jdean:!::
jdoe:!::
bsmith:!::

In this example, the groups
pppusers
,
jdean
,
jdoe
, and
bsmith
do not have group passwords, as indicated
by the
!
in the password field. The
finance
group is the only one with a password,
which is hashed.

More detailed information about shadow passwords can be found in
Chapter 22
.

On the Exam

A major contrast between
passwd/group
and
shadow/gshadow
is the permissions on the files.
The standard files are readable by everyone on the system, but the
shadow files are readable only by
root
, which
protects encrypted passwords from theft and possible
cracking.

User and Group Management Commands

Although possible, it is rarely necessary (or advised) to
manipulate the account and group definition files manually with a text
editor. Instead, a family of convenient administrative commands is
available for managing accounts, groups, password shadowing, group
shadowing, and password aging. Password aging (rules governing change
intervals and automated expiration of passwords) is not an explicit
Objective for the LPIC Level 1 Exams.

Other books

Most Precious Blood by Susan Beth Pfeffer
The New Yorker Stories by Ann Beattie
John Lennon: The Life by Philip Norman
Título by Autor
Wren Journeymage by Sherwood Smith
Sword Play by Emery, Clayton
United We Stand by Eric Walters