Linux System Administration Lx03

V1.2.2.
over
Linux System Administration
(Course Code LX03)
Student Notebook
ERC 2.0
IBM Learning Services

Worldwide Certified Material
Student Notebook
Trademarks
IBM® is a registered trademark of International Business Machines Corporation.
The following are trademarks of International Business Machines Corporation in the United
States, or other countries, or both:
AIX Hummingbird IBM
Perform XT 400
Intel and Pentium are trademarks of Intel Corporation in the United States, other countries,
or both.
Linux is a registered trademark of Linus Torvalds in the United States and other countries.
Windows is a trademark of Microsoft Corporation in the United States, other countries, or
both.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Other company, product, and service names may be trademarks or service marks of
others.
June 2002 Edition
The information contained in this document has not been submitted to any formal IBM test and is distributed on an “as is” basis without
any warranty either express or implied. The use of this information or the implementation of any of these techniques is a customer
responsibility and depends on the customer’s ability to evaluate and integrate them into the customer’s operational environment. While
each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will
result elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk. The original
repository material for this course has been certified as being Year 2000 compliant.
© Copyright International Business Machines Corporation 2001, 2002. All rights reserved.
This document may not be reproduced in whole or in part without the prior written permission of IBM.
Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is subject to restrictions
set forth in GSA ADP Schedule Contract with IBM Corp.
V1.2.2
Student Notebook
TOC Contents
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Course Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Unit 1. Physical Planning and Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Issues in Physical Planning and Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Computer Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Rack Mounted vs. Lots of Boxes on Shelves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Power Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Air Conditioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
Fire Detection and Suppression System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
Unit 2. Advanced Linux Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
Network Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Network Install Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Red Hat "Kickstart" Installs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
SuSE "autoinstall" Installs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
Unit 3. Startup and Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Linux Startup Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
Basic Input Output System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4
Master Boot Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
The Linux Loader (LILO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
/etc/lilo.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
GRand Unified Bootloader (GRUB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11
/boot/grub/grub.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Kernel Booting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15
System initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17
/etc/inittab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18
Starting Services (System V init style) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20
Configuring Services per Runlevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22
Starting and Stopping Services Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23
Booting Linux in Single-User Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24
Shutting Down a Linux System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25
© Copyright IBM Corp. 2001, 2002 Contents iii

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Student Notebook
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-26
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-27
Unit 4. System Administration Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2
System Administration Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3
Red Hat "setup" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5
SuSE "YaST", "YaST2" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6
Caldera "LISA" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-7
Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8
Webmin Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9
Webmin Screenshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-10
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-11
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-12
Unit 5. Packaging Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2
Red Hat Package Manager (RPM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3
RPM Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4
RPM Installing, Freshening and Upgrading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6
RPM Uninstalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-8
RPM Querying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9
rpmdb Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11
RPM Verifying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-12
RPM Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-14
Creating RPMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-15
Example Scenario: Hello, World! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-17
hello.spec Preamble Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-18
Visual Caption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-19
Visual Caption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-20
After RPM Build Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-21
GnoRPM and kpackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-22
up2date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-23
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-24
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-25
Unit 6. X Window System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2
X Window System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3
In the beginning... there was the batch system . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4
Later... the interactive typewriter system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-5
Later yet... a graphic terminal on a network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6
Client/Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-7
Examples of X Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-9
X Servers in Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-10
XFree86 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-11
XFree86 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-12
Sample /etc/X11/XF86Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-13
iv Linux System Administration © Copyright IBM Corp. 2001, 2002

V1.2.2
Student Notebook
TOC Sample /etc/X11/XF86Config-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16

Starting X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17
Stopping X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19
Session Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20
X Networked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-21
X Applications Networked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22
Applications over TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-23
X Sessions Networked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25
X Sessions over TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26
Chooser Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-28
Font Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-31
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-32
Unit 7. Block Devices, RAID and LVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Block Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Block Device Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4
Floppy Disks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5
Hard Disks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6
Hard Disk Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8
Partitioning Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10
RAM Disks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11
The "loop" Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13
Logical Volume Management (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14
Logical Volume Management (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16
LVM Implementation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17
Physical Volume Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-18
Volume Group Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19
Logical Volume Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-21
Additional LVM Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22
RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-24
RAID Levels (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-25
RAID Levels (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-27
Linux RAID Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-28
Linux Software RAID Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-29
Additional RAID Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-30
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-32
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-33
Unit 8. Filesystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
What is a File? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
What is a Filesystem? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4
Filesystems Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5
A Typical UNIX Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6
Superblock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7
Inodes (Index Nodes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8
© Copyright IBM Corp. 2001, 2002 Contents v

Student Notebook
Data Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-10

So... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-11
Other Filesystem Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-13
Creating a Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-15
Mounting a Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-16
Mounting Filesystems at System Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-17
Mount Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-19
Unmounting Filesystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-21
Checking a Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-22
ext2/ext3 Specific Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-24
ReiserFS Specific Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-26
JFS Specific Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-27
Quota Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-28
Quota Implementation on Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-29
Enabling Quota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-30
Configuring Quota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-31
Quota Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-32
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-33
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-34
Unit 9. Kernel Compilation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-2
Why Kernel Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-3
Compilation Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4
Installing Kernel Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5
Configuring the Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6
Kernel Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8
Compiling the Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-10
Installing the Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-12
Configuring Lilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-13
Configuring GRUB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-15
Reboot System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-16
Configuring Kernel at Run Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-17
Loading Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-18
Configuring Modules at Load Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-20
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-22
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-23
Unit 10. Memory Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2
Linux Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3
Example: Lightly Loaded System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-5
Example: Heavily Loaded System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-6
Creating Paging Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-7
Useful Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-9
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-10
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-11
vi Linux System Administration © Copyright IBM Corp. 2001, 2002

V1.2.2
Student Notebook
TOC Unit 11. Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3
Vixie Cron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4
User Crontab Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5
crontab Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7
System crontab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-9
Anacron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-10
/etc/anacrontab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-11
at . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12
batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-14
Controlling at Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-15
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-16
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-17
Unit 12. Backup and Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2
Why Back Up? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3
Devising a Backup Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4
Backup Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5
Sample Backup Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6
Backup Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-8
Default Backup Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-10
tar Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-11
cpio Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-13
dump Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-15
Other Backup Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-16
Document Backup Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-17
Additional Backup Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-19
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-20
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-21
Unit 13. User Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2
Security Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-3
User Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-4
Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-5
Command Line User Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-7
/etc/skel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-8
Command Line Group Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-9
Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-10
/etc/passwd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-11
/etc/shadow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-12
/etc/group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-14
/etc/issue and /etc/issue.net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-15
Message of the Day . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-16
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-17
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-18
© Copyright IBM Corp. 2001, 2002 Contents vii

Student Notebook
Unit 14. User-Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-2
User-Level Security Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-3
Pluggable Authentication Module (PAM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-4
Authentication before PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-5
Authentication with PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-6
PAM configuration files example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-8
Common PAM Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-10
Principles of Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-11
File Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-13
Changing Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-15
umask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-16
Example: Creating a Team Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-17
Root Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-18
su . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-19
sudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-20
Security Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-22
Useful Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-24
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-25
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-26
Unit 15. Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-2
Logging Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-3
Facilities, Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-5
/etc/syslog.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-7
logger Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-9
logrotate Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-10
Sample /etc/logrotate.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-12
Analyzing Logfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-13
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-15
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-16
Unit 16. Printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-2
Users, Printer Queues, Printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-3
Printing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-4
Common Printing Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-6
BSD Printing Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-8
LPR Next Generation (LPRng) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-10
Common UNIX Printing System (CUPS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-12
Configuring Linux Printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-14
Creating Printer Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-16
BSD User Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-18
Configuring LPRng Printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-20
Configuring CUPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-21
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-22
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16-23
viii Linux System Administration © Copyright IBM Corp. 2001, 2002

V1.2.2
Student Notebook
TOC Unit 17. Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-2
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-3
Identifying the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-5
strace, ltrace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-7
Fixing the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-8
Rescue Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-10
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-12
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-13
Unit 18. Policies and Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-2
About Your Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-3
The Dilemma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-4
Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-5
User Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-6
Administrator Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-8
Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-10
Procedure Handbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-11
Management of System Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-12
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-14
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-15
Appendix A. Checkpoint Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
© Copyright IBM Corp. 2001, 2002 Contents ix

Student Notebook
x Linux System Administration © Copyright IBM Corp. 2001, 2002

V1.2.2
Student Notebook
TMK Trademarks
The reader should recognize that the following terms, which appear in the content of this
training document, are official trademarks of IBM or other companies:
IBM® is a registered trademark of International Business Machines Corporation.
The following are trademarks of International Business Machines Corporation in the United
States, or other countries, or both:
AIX Hummingbird IBM
Perform XT 400
Intel and Pentium are trademarks of Intel Corporation in the United States, other countries,
or both.
Linux is a registered trademark of Linus Torvalds in the United States and other countries.
Windows is a trademark of Microsoft Corporation in the United States, other countries, or
both.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Other company, product, and service names may be trademarks or service marks of
others.
© Copyright IBM Corp. 2001, 2002 Trademarks xi

Student Notebook
xii Linux System Administration © Copyright IBM Corp. 2001, 2002

V1.2.2
Student Notebook
ref Course Description

Linux System Administration
Duration: 5 days
Purpose
The purpose of this course is teach experienced Linux users the
techniques, methods and policies used in Linux System
Administration.
Audience
The intended audience for this course are experienced Linux users
who want to become the administrator of one or more Linux servers.
Prerequisites
• IBM Linux course LX02 (Linux Power User)
• Practical experience in running Linux as a user
Objectives
After completing this course, you should be able to:
• Physically plan and manage the system and its environment
• Install Linux from a network install server
• Manage system startup and shutdown
• Select and use system administration tools when appropriate
• Use packaging tools to create, install and deinstall packages
• Configure and manage the X Window System
• Manage hard disks, partitions, RAID and LVM
• Create and manage filesystems
• Recompile the Linux kernel
• Perform memory management
• Use scheduling tools
• Create and restore backups
• Perform user administration
© Copyright IBM Corp. 2001, 2002 Course Description xiii

Student Notebook
• Apply user-level security

• Manage logging
• Configure and manage printers
• Troubleshoot Linux problems
• Discuss policies and procedures
Contents
• Physical system management and planning
• Advanced Linux installation
• System startup and shutdown
• System Administration tools
• Packaging tools
• X Window System
• Managing hard disks, partitions, LVM and RAID
• Filesystems
• Kernel compilation
• Memory management
• Scheduling
• Backup and restore
• User administration
• User-level security
• Logging
• Printers
• Troubleshooting
• Policies and procedures
xiv Linux System Administration © Copyright IBM Corp. 2001, 2002

V1.2.2
Student Notebook
ref Agenda
Day 1
Unit 1 - Physical Planning and Maintenance
Exercise 1- Physical Planning and Maintenance
Unit 2 - Advanced Linux installation
Exercise 2 - Advanced Linux installation
Unit 3 - Startup and Shutdown
Exercise 3 - Startup and Shutdown
Unit 4 - System Administration Tools
Exercise 4 - System Administration Tools
Day 2
Unit 5 - Packaging Tools
Exercise 5 - Packaging Tools
Unit 6 - X Window System
Exercise 6 - X Window System
Unit 7 - Block Devices, RAID and LVM
Exercise 7 - Block Devices, RAID and LVM
Unit 8 - Filesystems
Exercise 8 - Filesystems
Day 3
Unit 9 - Kernel Compilation
Exercise 9 - Kernel Compilation
Unit 10 - Memory management
Exercise 10 - Memory management
Unit 11 - Scheduling
Exercise 11 - Scheduling
Day 4
Unit 12 - Backup and Restore
Exercise 12 - Backup and Restore
Unit 13 - User Administration
Exercise 13 - User Administration
Unit 14 - User level security
Exercise 14 - User level security
© Copyright IBM Corp. 2001, 2002 Agenda xv

Student Notebook
Day 5
Unit 15 - Logging
Exercise 15 - Logging
Unit 16 - Printers
Exercise 16 - Printers
Unit 17 - Troubleshooting
Exercise 17 - Troubleshooting
Unit 18 - Policies and procedures
xvi Linux System Administration © Copyright IBM Corp. 2001, 2002

V1.2.2 BKM2MIF
Student Notebook
Uempty Unit 1. Physical Planning and Maintenance
What This Unit Is About

This unit discusses various subjects that have to do with physically
planning and managing your Linux systems.
What You Should Be Able to Do

After completing this unit, you should be able to:
• Discuss issues to be considered when planning the physical
installation of the system
• List best practices for physical maintenance
How You Will Check Your Progress

Accountability:
• Checkpoint questions
© Copyright IBM Corp. 2001, 2002 Unit 1. Physical Planning and Maintenance 1-1
Student Notebook

Figure 1-1. Objectives LX032.0
Notes:
1-2 Linux System Administration © Copyright IBM Corp. 2001, 2002

V1.2.2 BKM2MIF
Student Notebook
Uempty

!
Figure 1-2. Issues in Physical Planning and Maintenance LX032.0
Notes:
When planning for the physical installation, several issues will have to be considered.
These will be covered in the subsequent visuals.
Student Notebook

" #

#
$ %%

#
&

#

Figure 1-3. Computer Room LX032.0
Notes:
In most cases, servers will be placed in separate computer rooms. This might be a simple
basement closet, or a high-tech computer room with so much glamour that your CEO is
giving all customers a tour around it.
Placing servers in a separate room has distinct advantages:
• Computer rooms will typically have raised floors, overhead cable racks or other features
that make it easy to keep the spaghetti of network, power and other cables organized
and out of the way, while still keeping them easily accessible if needed.
• Having a separate computer room allows you to customize your settings for the air
conditioning to the optimum settings for your computer equipment. This is not
necessarily the optimum settings for human beings.
• Computer rooms typically only have a few access points, which can be equipped with
additional access control systems (ranging from simple locks on doors to sophisticated
biometric devices). This helps keeping unauthorized people out. This is important since

V1.2.2 BKM2MIF
Student Notebook
Uempty having physical access to the system almost always means that you can tamper with it.
Not to mention the accidental coffee spill...
Of course, there is a distinct disadvantage to placing computers in computer rooms as well:
If console access is needed for some reason (changing backup tapes, rebooting a "hung"
system), then these systems are generally less accessible than if they were standing under
your desk.
Student Notebook
! "
" '()*+% #

",
##
-%.

/ %01/
2
#

3

3%

%
#
$%, .
4
#
#
%
Figure 1-4. Rack Mounted vs. Lots of Boxes on Shelves LX032.0
Notes:
Most computer-related equipment on the market today can be bought in two variants:
rack-mounted and stand-alone.
Rack-mounted means that the physical dimensions and external fittings are optimized so
that the system can fit in an industry-standard, 19 inch wide rack. These racks are typically
mounted in an enclosure which also contains rails for convenient mounting of various
cables, and contain power strips. Most racks also come with front and back doors (glass or
perforated steel) with locks to make console access to systems harder.
A variety of hardware is currently available in rack-mounted form: servers, server blade
enclosures, network equipment, monitors, keyboards, mice, KVM (keyboard video mouse)
switches, UPS equipment etc. There are even manufacturers who have combined a KVM
switch, an LCD monitor, a mouse and a keyboard in a 19 inch wide, 1 inch high drawer.
When pulled out of the rack, the LCD panel pops up to a vertical position. This saves you a
lot of space in (or next to) your rack, while still allowing console access to a system.

V1.2.2 BKM2MIF
Student Notebook
Uempty The advantages of rack-mounting all your equipment is obvious:

• Rack-mounting equipment saves a lot of floor space. The footprint of a typical rack is
about 1 m2 , and a typical rack is nearly 2 m tall. This means that a typical rack can
house 10-40 servers, depending on the height of each server. Server blade enclosures
(boxes 3 inches high containing 18 blades, each blade being a full server) even allow
you to put 400 or more servers in one rack. Having to store the same amount of servers
on the floor or on tables would require far more floor space.
• Since racks typically come with lockable front and back doors, it is easier to limit
physical access to the systems. This is especially useful in large organizations where
one computer floor might be used by several departments.
• Since racks typically come with power strips and fixtures for network cables, it is far
easier to keep them tidy and organized. Plus, racks typically have an open bottom
which allows you lead cabling straight under the raised floor, instead of having to string
it out the back of a standalone server through a hole in the floor.
• Last but no less important: Having a whole computer room full of rack-mounted
equipment looks far better than having a computer room full of different sized and
colored standalone servers.
But there are several disadvantages as well:
• Rack-mounted equipment, especially servers, are generally a little more expensive than
comparable stand-alone servers. The reason for this is economics of scale: Most
servers sold are still stand-alone servers, which therefore benefit of bulk production
optimization.
• Physical access to systems in a rack is usually less convenient. This is especially
apparent when having to replace hardware in the systems. Instead of just pulling a
stand-alone server forward, you typically need to first take the whole server out of the
rack, before you can do any hardware maintenance on it.
• The last disadvantage is usually forgotten, but is really important to consider: A rack full
with computer equipment might need floor reinforcement.
A typical building floor is designed and constructed to be able to carry about 300 kg/m2 .
A full rack, which has a footprint of about 1 m2 can easily weigh more than 500 kg. If you
plan on dense-packing your racks, make sure to consult a building engineer first to
verify that your floor is strong enough to carry the load.
Student Notebook
#
5

#
** 416

2
(78167897:88
3

7:816(;9<=:8
!

%
>
! 2

'2 +

%# %
%
2,

0

(8,<8
? #

Figure 1-5. Power Considerations LX032.0
Notes:
Just about every device used in the IT world consumes electric power to a certain extent.
The amount of power that is consumed by a devices is measured in "Watt". Obviously, the
total amount of power consumed should not be more than the amount of power that the
power grid can handle.
Power usually comes into your building through a high-capacity cable. To limit the damage
that a short-circuit in your building might cause, you do not connect your devices directly to
this cable, but shield them with fuses or circuit breakers. A "circuit" is simply all electric
cabling that is protected by the same fuse or circuit breaker.
Fuses and circuit breakers come in various shapes and sizes, but also in various current
levels ("Amps") at which they will pop or blow.
In the US, the end user power grid operates at 120 Volt and is typically protected by 20A
fuses or breakers. This means that the total power consumption of all devices in a circuit
may not exceed 2400 Watt.

V1.2.2 BKM2MIF
Student Notebook
Uempty In Europe, the end user power grid operates at 220-240 Volt and is typically protected by 16
A fuses. This means that the total power consumption of all devices in a circuit may not
exceed 3840 Watt.
Note that the power rating of a device (measured in Watt) is the maximum amount of power
drawn. A typical device (except, perhaps, a light bulb) will in normal operation use less than
the amount indicated. Despite this, it is not a good idea to let the total amount of power (as
listed on the devices) exceed the power rating for the circuit. The reason is simple: After a
power failure, all devices are typically turned on at the same time. And for the first few
seconds, a lot of devices will actually use their maximum power consumption, to spin up
disk drives and so forth.
Power companies will always try to give you a clear, alternating current power feed. Various
influences beyond their control, such as lightning, may alter the clear sine wave that you
expect to receive. This might damage your equipment, or wear it out more quickly. To
protect against this, you might consider using Surge Arresters and/or Uninterruptible Power
Supplies.
A Surge Arrester will protect you from sudden surges (such as these caused by lightning) in
the power feed, but will not keep your equipment powered if the power supply fails
altogether.
A UPS contains a battery which will keep your equipment powered for something like 10-30
minutes in case of a power failure. It is usually connected to your equipment with a serial or
USB cable as well, so that it is able to trigger a clean shutdown in case of a prolonged
power outage. UPS devices typically contain Surge Arresters as well.
Large installations might benefit from diesel generators, where the UPS is only used to
power your equipment from the time that the power fails to the time where the diesel
generator is running and able to power your devices. (Some diesel generators can start
automatically in less than a second.)
Student Notebook
$
/

"
(@,78!';:,;=+
2

4
A

#

" :8B,;8B

A!
*52** *
? **

<>:(752

? * *.(788852
Figure 1-6. Air Conditioning LX032.0
Notes:
Most computer rooms will need to be equipped with an air conditioner. This air conditioner
is needed for two things, basically:
• Maintaining a stable temperature.
• Maintaining a constant humidity.
It is important that computer equipment is kept at a constant temperature, typically 17-20
degrees Celsius (64-68 degrees Fahrenheit), because fluctuating temperatures might
cause damage from expansion/contraction of components, and high temperatures might
lead to overheating of internal components. (Note that the interior of a computer is typically
a few to ten degrees higher than the exterior.)
It is equally important that the humidity in your computer room is kept between about 40 to
60%. If the humidity is too low, then static electricity might build up and cause damage. If
the humidity is too high, then condensation might occur, which might lead to short-circuiting
of equipment.

V1.2.2 BKM2MIF
Student Notebook
Uempty Air conditioning capacity is expressed in "BTU" (British Thermal Units), which is a standard
unit for measuring heat. To cool one Watt of power converted into heat, you need 3.412
BTU. For reference, a human being produces about 300 BTU of heat when performing
regular office work.
Air conditioning capacity is sometimes also expressed in "tons". This relates to the capacity
needed to melt a ton of ice in one hour. One ton equals 12,000 BTUH.
Student Notebook
%& " "
/%

% 4

#

!

C!?7C" C
!

!

Figure 1-7. Fire Detection and Suppression System LX032.0
Notes:
Your computer room will almost certainly need to be equipped with a fire detection and
suppression system. This system usually consists of two parts.
The first part of the system is aimed at detecting smoke and fire. Smoke detectors typically
are able to detect small particles of pure carbon in the air, while carbon monoxide detectors
are able to detect carbon monoxide molecules. Both are a product of fire. If you have a
raised floor and/or lowered ceilings, don't forget to place detectors in these spaces too, and
test them regularly.
The second part of the system is aimed at suppressing a fire. How this is done depends a
lot on the type of equipment installed in your computer room, local regulations and financial
considerations. It is best to consult your local fire department for the best solution.
Since most of the fires in computer rooms are caused by electricity, it is a good idea install
a master switch somewhere at an accessible place which terminates the power to the
whole computer room at once. This might kill an electrical fire instantly, and might prevent a
non-electrical fire into becoming one.

V1.2.2 BKM2MIF
Student Notebook
Uempty

5

D

A

,
#
! ,
,
2
& AA

.

!%

0
4
Figure 1-8. Best Practices LX032.0
Notes:
When physically maintaining your equipment, there are a few things to keep in mind.
The first thing you need to remember is that static electricity might cause damage. Memory
chips are especially vulnerable to this, but other components are not totally immune too. A
few simple guidelines can help you prevent damage from static electricity though:
• Make sure that all components are properly grounded.
• Before putting your hands inside a box to replace components there, make sure that
you yourself are discharged. This can simply be done by touching the outer case or a
grounded connector for a second or so. Do not move or shuffle your feet afterwards
though.
• Almost all replacement computer components come in anti-static bags. Leave
components in these bags for as long as possible. Before opening the bags, make sure
they are discharged as well, for instance by laying them on the (grounded) metal case
of your server, or by holding them in your hand while touching something else that is
grounded.
Student Notebook
• When handling components, avoid touching their electric circuits. Only touch the edges
of circuit boards, or the casing of hard disks.
• Consider using grounded wrist-straps and/or anti-static mats. These come in handy
combinations with a clip that attaches to the (grounded) metal case of your computer.
When cleaning equipment, use only specialized tools/materials and companies.
Check air fans regularly for proper operation. Fans can be blocked by dust, paper and even
chewing gum, which might lead to overheating of internal components.
Keep a toolbox handy with an assortment of tools that are required for (emergency)
maintenance. This toolbox need to contain at least:
• Various shapes and sizes screwdrivers
• Knife
• Scissors
• Pliers
• Tweezers
• Flashlight
• Electrical tape
• List of emergency maintenance contacts and support staff

V1.2.2 BKM2MIF
Student Notebook
Uempty

1) T/F Rack-mounted equipment is generally a little more expensive

than regular, non-rackmounted equipment.
2) You have 25 servers, each rated at 450 watt. How many tons
of air conditioning do you need for this?
a. 38,385
b. 3.20
c. 11,250
d. None of the above
3) What different methods do you use to limit the risk of static

electricity damage to a minimum?
______________________________________________
______________________________________________
______________________________________________
Figure 1-9. Checkpoint LX032.0
Notes:
Write down your answers here:
1.
2.
3.
Student Notebook
' "
/ #

%,
.

4

4

.

%

E
#
Figure 1-10. Unit Summary LX032.0
Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty Unit 2. Advanced Linux Installation

This unit will teach you how to perform advanced (non-CD)
installations.

• Perform a network installation
• Discuss network install servers
• Discuss kickstart installs

Accountability:
• Machine exercises
© Copyright IBM Corp. 2001, 2002 Unit 2. Advanced Linux Installation 2-1
Student Notebook

%
% #
%%
Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty
(#

" $/

%
-%

-

/5
$. % #
2.
%, %
" %

% % %

Figure 2-2. Network Installations LX032.0
Notes:
Most Linux systems are installed from the distribution CD-ROMs (or DVDs). This is a
convenient method if you only need to install one or a few systems, but quickly becomes
tedious if you need to install 10 or more systems, especially if each system has to be
installed with the same settings.
More advanced installation methods exist which are convenient for these situations, and in
all but a few cases, this comes down to network installations, where the RPMs to be
installed are downloaded from the network.
Various network protocols exist to retrieve the installation RPMs, and the protocols that are
supported depends on your distribution. Support might be included for NFS, FTP, HTTP
and SMB.
An obvious requirement for a network-based install is that somewhere on the network you
need to configure a network install server, which holds all the RPMs for your distributions.
Another requirement is that your systems to be installed are equipped with a network
adapter, which is supported by your network boot diskette. If your network adapter is not
Student Notebook
supported by the boot diskette, you might also need an additional diskette which contains
the device support in the form of Linux kernel modules.
A Red Hat system requires a special "bootnet.img" diskette to perform a network install,
while a SuSE system can use the regular "bootdisk" for both CD-ROM and network installs.

V1.2.2 BKM2MIF
Student Notebook
Uempty
(#
"
4A2-"F#
! # !
%
2

# A 4

>>A4
A@8A4
A@(A4
A@7

- ' + /5
5- #>7#>#><
G
A#A
A
$
$A A

3
A%A > 6

Figure 2-3. Network Install Server LX032.0
Notes:
A Network Install Server is typically a Linux/UNIX server, although Windows NT/2000
servers can sometimes also be used. The content of all relevant CDs is copied to disk and
made available. It is a good idea to use a naming scheme that allows multiple versions of
multiple distributions to be copied to disk.
Almost all network install servers export the CDs via NFS, but (anonymous) FTP, HTTP and
SMB may also be used.
If you decide to use NFS, be aware of the fact that the newer distributions typically use NFS
version 3, while older distributions typically use NFS version 2. This might lead to
compatibility problems, which can be solved easily by forcing the NFS server to always use
version 2.
If you decide to offer anonymous FTP installs, then you need to create your directory
structure somewhere in the /var/ftp directory, since the ftp daemon will perform a chroot to
this directory when anonymous FTP is requested.
Student Notebook
If you decide to offer HTTP installs, you can simply create a symbolic link from your
document_root directory to the directory where your CDs are copied into, as long as
"FollowSymLinks" is set in your web server configuration.
After creating the installation directory, you need to copy the contents of the relevant CDs to
that directory. This needs to be done with all preservations of permissions, users and so
forth intact, and can best be done with the cp -a command.
For a Red Hat distribution, make sure you copy at least the RedHat/ and images/
directories. For a SuSE distribution, make sure you copy at least the suse/ and disks/
directories and all .S* files.

V1.2.2 BKM2MIF
Student Notebook
Uempty
)*+ *
$

" ##*%>*
" .

B
%
%A
%

B
B

,
4
%>
>
-
#
- .!#
0% ! ! ,
4,

3 4>
Figure 2-4. Red Hat "Kickstart" Installs LX032.0
Notes:
"Kickstart" is Red Hats method of automating installations. It involves creating a ks.cfg file,
which contains three sections:
• The first section, which starts at the top of the file, contains the answers to all questions
of the installation process. For instance, if the statement lang en_US is present in the
kickstart file, the question "What language do you want to use during the installation
process?" will not be asked, but US English is used.
• The second section starts with the %packages identifier. It contains a list of all packages
(RPMs) to be installed. Just as with the install process itself, it can also use the package
groups that are defined in the RedHat/base/comps file. These package groups are
identified with an ampersand, for instance "@ Networked Workstation".
• The third section starts with the %post identifier. It contains a series of shell commands
that are executed once the installation has finished. These commands are executed on
the newly installed system, with all paths, networking and so forth intact. This means
that virtually anything is possible, including mounting remote filesystems, creating user
accounts, and so forth.
Student Notebook
It is also possible to create a %pre section, which is executed before the installation starts.
This is generally used only to implement custom partition schemes.
An example kickstart file will look like this:
install
nfs --server 10.0.0.1 --dir /export/rh73
lang en_US
langsupport --default en_US.iso885915 en_US.iso885915
keyboard us
mouse generic3ps/2 --device psaux
skipx
network --device eth0 --bootproto dhcp
rootpw ibmlnx
firewall --disabled
authconfig --enableshadow --enablemd5
timezone Europe/Amsterdam
bootloader
clearpart --all
part /boot --fstype ext3 --size=32
part /usr --fstype ext3 --size=2000
part / --fstype ext3 --size=150
part /var --fstype ext3 --size=150
part /home --fstype ext3 --size=50
part /tmp --fstype ext3 --size=100
part swap --size=64
%packages
@ Network Support
@ Printing Support
@ Classic X Window System
@ X Window System
@ GNOME
@ KDE
@ Software Development
@ Kernel Development
@ Network Server
%post
adduser tux1
echo tux1 | passwd --stdin tux1
adduser tux2
echo tux2 | passwd --stdin tux2

V1.2.2 BKM2MIF
Student Notebook
Uempty The kickstart configuration file can be stored on the bootnet.img diskette, or can be stored
on an NFS server. Kickstart installs are then started by typing linux ks (when ks.cfg is
located on an NFS server) or linux ks=floppy (when ks.cfg is located on floppy).
When your ks.cfg file is located on an NFS server, then you also need to have a DHCP
server to supply the system to install with its IP address. The DHCP server may also need
to supply the system to install with two other bits of information:
• The NFS server where the kickstart file is located. This should be included in the
"next-server" DHCP option. If no next-server is given, then it is assumed that the DHCP
server is the NFS server too.
• The NFS exported directory where the kickstart file is located. This should be included in
the "filename" DHCP option. If this filename ends with a forward slash (/), then it is
assumed to be a directory in which the file <IP>-kickstart is located. This makes it
possible to create different kickstart files for individual systems. If no filename is given,
then it is assumed that "/kickstart/" is used.
To fully automate kickstart installations, modify the syslinux.cfg file on your bootnet.img
disk, and make kickstart the default. You might also turn off the delay. The top of this file will
then look like this:
default linux ks
prompt 0
Kickstart files are usually updated by hand. Red Hat has released a tool which may help
you generate initial kickstart files: ksconfig. This tool is available on the distribution CDs in
the ksconfig RPM. As an added bonus, the Red Hat installer, Anaconda, generates a
kickstart file for you based on the choices made during the installation process itself. This
file is called /root/anaconda-ks.cfg.
Student Notebook
""-* *

3

!$?/ -

" ## * * %
D %>

,

%
- #
,

%
- #
4

. 4>
Figure 2-5. SuSE "autoinstall" Installs LX032.0
Notes:
SuSE also supports autoinstallations via CD-ROM and NFS. To configure a SuSE
autoinstallation, create an "info" file on the bootdisk, with general settings regarding
keyboard and so forth. This file may also include pointer to pre- and post install scripts. An
example file looks like this:
Language: english
Display: color
Keytable: us
Bootmode: Net
IP: 10.0.0.2
Netmask: 255.255.255.0
Gateway: 10.0.0.1
Netdevice: eth0
Server: 10.0.0.1
Serverdir: /export/suse71
AUTO_FDISK 2

V1.2.2 BKM2MIF
Student Notebook
Uempty AUTO_FDISK_DISK /dev/hda

FAST_INSTALL 2
AUTO_LILO 2
AUTO_NET 1
AUTO_NAME 1
AUTO_NAMESERVER 1
AUTO_SERVICES 1
AUTO_INSTALL $I:/suse/setup/descr/Minimal.sel
INSTALL_WAIT 0
CDROM_DEVICE /dev/hdb
NO_ASK_SWAP 1
END_MESSAGE 0
END_STARTUP 0
CHECK_DEPENDENCY 0
NEVER_STOP 1
You also need to create a file named part_NNNNN on your NFS server, in the directory
suse/setup/descr. This file contains the partitioning scheme for any disk of size NNNNN MB
and higher. Such a file might look like this:
/boot size=10
swap size=64
/ size=0
Then, modify your syslinux.cfg file on the boot disk so that it looks like this:
default linux
label linux
kernel linux
append initrd=initrd rw ramdisk_size=65536 linuxrc=auto
timeout 1
Then, insert the boot disk into the system to be installed and switch it on.
Student Notebook

1) T/F A network installs server needs to be a Linux system.

2) Which of the following install methods does not require a
network server?
a. NFS
b. SMB
c. FTP
d. CD-ROM
3) What are the two possible locations where a Red Hat Kickstart
file can be stored?
______________________________________________
______________________________________________
Notes:
1.
2.
3.

V1.2.2 BKM2MIF
Student Notebook
Uempty
' "
-% # #

% #
4

#
#-

%

% %

$*%%* 3* *

Notes:
Student Notebook

V1.2.2 BKM2MIF
Student Notebook
Uempty Unit 3. Startup and Shutdown

This unit will teach you how the startup process of a Linux system
actually works, and how to shut a Linux system down properly.

• Describe the Linux startup flow
• Configure the boot loader
• Configure the kernel
• Configure init
• Configure autostarting services
• Boot Linux in single-user mode
• Perform a shutdown of a Linux system

Accountability:
• Exercises
© Copyright IBM Corp. 2001, 2002 Unit 3. Startup and Shutdown 3-1
Student Notebook

4

!
! %
!
! #
5 4 ,
4
Figure 3-1. Unit Objectives LX032.0
Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty
!"%#

5"?

4%

Figure 3-2. Linux Startup Flow LX032.0
Notes:
This visual gives an overview of the Linux startup flow. In the subsequent visuals we will
cover the details of each step.
Student Notebook

"
!%

,#
/
?#
!%#

%
!,$?/
%
/5$# 4

Figure 3-3. Basic Input Output System LX032.0
Notes:
Every Intel PC has a Basic Input Output System, or BIOS for short. This is a little program
which is stored in an EEPROM (Electrical Erasable Programmable Read Only Memory,
sometimes also called non-volatile memory) on your motherboard. It is the first program
that runs once the power is switched on. It does a number of basic tasks:
• It checks the memory
• It loads various options from non-volatile memory, for instance memory timing
parameters and the order of boot devices. These options can be set by the user when
pressing Del, F1, F2 or some other key while the memory is being tested.
• It checks for the availability of boot devices, and
• Loads the Master Boot Record of the first available boot device. This first sector is stored
in memory and executed.

V1.2.2 BKM2MIF
Student Notebook
Uempty

#
! **

1

! H .
5*#*

4/5$
"?
4
4%
!

- 4 D$25
"?
D$ 2 5
$4 4>>>

* *

Figure 3-4. Master Boot Record LX032.0
Notes:
The Master Boot Record or MBR is the first sector (512 bytes) of the boot device. It
contains two things:
• A boot loader program: Software to bootstrap the operating system.
• The partition table: A table which describes how the rest of the disk is split up into
partitions.
On systems fresh out of the shop, the bootloader is a very simple program which was
configured with the MS-DOS command fdisk /mbr. This program goes through the
partition table and looks for a partition that is marked "active". The program then loads the
first sector of this partition and starts it. This concept is known as chain-loading.
When using Linux, the MBR is traditionally set up by the Linux Loader (LILO). It is a little
more elaborate than the usual MBR, in that it can prompt the user for the operating system
to load, and any options to pass to that operating system. Then, it loads the selected
operating system, passing the options as it starts it.
Student Notebook
Newer Linux distributions may use GRUB instead of LILO. GRUB is far more flexible than
LILO, since it allows you to alter the configuration from the boot prompt. It is also versatile
enough to boot other UNIX operating systems that can run on PC hardware, such as
GNU/Hurd, *BSD and so forth. It also supports chain-loading of Windows operating
systems, and supports hiding partitions, so that you can have multiple Windows operating
systems on one disk simultaneously.

V1.2.2 BKM2MIF
Student Notebook
Uempty
/ !0
1

/5$
4 ! "#"
,# #
,#,# ##
,! I AA>
,
$
!%#
! /5$
Figure 3-5. The Linux Loader (LILO) LX032.0
Notes:
The Linux Loader (LILO) is the program that configures the MBR. It must be run as root
with the lilo command. It parses the command line options, reads and checks the
configuration file, and configures the MBR accordingly. The default configuration file is
/etc/lilo.conf, but this can be overridden with the -C option. Other important options include:
-v Gives a verbose output.
-v -v Gives a very verbose output. In fact, you can have a total number of eight
'-v's, giving you more and more output, until you literally drown in debug
output.
-t Only tests the validity of the config file; does not actually write to the MBR.
-u, -U With this option, lilo restores an older backup copy of the MBR to the MBR
on disk. This backup was made the first time lilo was run and is called
/boot/boot.0300 or /boot/boot.0800.1
1
The numbers are the major and minor numbers of the device. 0300 is your first IDE disk, 0800 is your first SCSI disk.
Student Notebook
It can be used to recover from a mangled MBR for instance, and

can be used for a complete deinstall of Linux.2
For more details, refer to the lilo manual page (man lilo)
2
Note that to clean up the MBR, you can also run the fdisk /mbr command from MS-DOS or Windows. This undocumented feature
restores the MBR to a pristine state.

V1.2.2 BKM2MIF
Student Notebook
Uempty
..
$ % '/5$+

%$
%

%$ $ $ 7
%$

%?
%&' '(A(8+
%$ ( ? 4 %
$% AA# &

A#AJ
%& ,

%)%*+) * 9(7=/*

%
,
% , 4

**
$%
"?

>
$%
Figure 3-6. /etc/lilo.conf LX032.0
Notes:
The /etc/lilo.conf contains a number of general options, followed by specific information for
each operating system which lilo should be able to boot. The complete list of options is
described in the lilo.conf manual page, but here's the shortlist:
boot The place where lilo should write the information to. /dev/hda means the
MBR of the first hard disk.
map The map file to use. This map contains the layout of the current kernel and
is used to trace back kernel problems/panics.
install Which second stage boot loader to install. There are several, but boot.b is
the most commonly used.
message A file which may contain a short message. This message is then displayed
before the boot:-prompt.
prompt Do not boot straight into the first OS, but give the user the possibility to
choose an OS.
Student Notebook
default Identifies the image that will be the default (if the user just hits Enter). If no
default image is specified, the first image will be the default image.
timeout The timeout to wait for a user response, measured in deciseconds (1/10th
of a second).
image The Linux kernel image to use
label The label given to this operating system. This is the text the user has to
type when he or she wants to boot this OS.
root The root filesystem to be used for this OS.
append Default options to pass to the kernel when it boots, for instance the amount
of memory in your system when Linux is not able to detect this correctly.
read-only Mount the root filesystem read-only, so that a proper fsck is possible. fsck
will be covered later.
other The partition where another (non-Linux) operating system resides.
table The partition table to use for this operating system.
linear Use linear block addressing (LBA) mode instead of Cylinder/Head/Sector.
This is typically needed for large disk drives.
lba32 Use linear block addressing (LBA) mode instead of Cylinder/Head/Sector,
and use int32 BIOS calls. This allows lilo to overcome the 1024 cylinder/8
GB limit which is present in the original BIOS specification.
linear and lba32 are mutually exclusive.
password The (unencrypted) password a user has to enter before this image will
boot. Obviously, since the password is plain text in /etc/lilo.conf, you will
have to change the permissions to 600 or 400 so that no user can read this
file. Some people even go as far as to change the /etc/lilo.conf file to
include the password, then run lilo and then change /etc/lilo.conf again,
removing the password.
restricted Only ask for a password if the user supplied any options - do not ask for a
password for a straight, normal boot.
Certain distributions also use the initrd option. This option specifies the name of a
compressed image of an ext2 filesystem which holds some kernel modules. This is needed
for instance when booting from a SCSI disk. SCSI support is usually modularized in the
kernel, meaning that before a SCSI disk can be accessed, the SCSI modules will have to
be loaded - from that SCSI disk... To prevent this chicken-and-egg problem, a very small
filesystem, with the SCSI modules on it, is loaded into memory by Lilo when the kernel
boots. Initially, this filesystem is mounted as root, the SCSI modules are loaded, and only
then will the real root filesystem be mounted. (Initrd = INITial Root Disk.) If for some reason
you need to change this Initial Root Disk, use the mkinitrd command and read the mkinitrd
manual page for details. Obviously this initial root disk needs to reside in /boot too.

V1.2.2 BKM2MIF
Student Notebook
Uempty
2 ' 02' 1
/5$'+ AA

'(>J +
2
- # "?
! AAA>
" /5$3

?
2 ,
?
!

D$25
/J

A2

-%
Figure 3-7. GRand Unified Bootloader (GRUB) LX032.0
Notes:
GRUB, as LILO, consists of a number of separate stages:
• The first stage, called stage1 on disk, is usually stored in your MBR.
• The 1.5th stage, called *_stage1_5 (e2fs_stage1_5, fat_stage1_5, minix_stage1_5,
reiserfs_stage1_5, ...) is stored on disk, typically in /boot/grub. Several 1.5th stage files
exist, each for a different filesystem.
This stage is used to add filesystem capabilities to GRUB, so that GRUB is able to use
regular filename references when loading configuration files, kernels and such, instead
of disk block locations.
Because of this stage, GRUB is able to read its configuration file directly, and does not
need to be configured beforehand, like LILO.
• The second stage, called stage2. This gives a menu interface which allows you to boot
your predefined operating systems, or enter commands to boot a non-predefined
operating system.
Student Notebook
If a "splashimage" was included in the GRUB configuration, then the second stage will
display the menu in a graphical mode, with the splash image as background.
The GRUB configuration file is typically stored in your /boot filesystem, in a separate GRUB
directory, and called grub.conf.3 On a regularly booted Linux system, this file is thus
referenced as /boot/grub/grub.conf. It contains all predefined operating systems and their
options and peculiarities.
To install GRUB, either use the shell script grub-install or start the grub program and use
GRUB commands to install GRUB manually.
GRUB has some additional features that make it far more useful than LILO:
• GRUB supports MD5-encrypted passwords to protect normal users from supplying
parameters and options to predefined operating system, or to define their own operating
system boot procedure.
• GRUB can perform hiding and unhiding of Windows partitions. This is a requirement for
running multiple Windows operating systems from the same disk.4
• If configured properly, GRUB can be used to boot from the network. This requires the
netboot package, and requires you to set up a DHCP and TFTP server though. Network
booting is outside the scope of this course.
3
On some distributions, a symbolic link "menu.lst" is created, which points to this file.
4
The problem lies in Windows 9x itself: When a Windows system boots, it goes through the partition table and assigns a drive letter to
every partition type it recognizes, starting with C:. Furthermore, Windows is only able to boot from the C:-drive. Thus, if you want multiple
Windows 9x operating systems on your partition, you need to "hide" all partitions that are not in use. This is done by changing the
partition type to something that Windows does not recognize.
Note that Windows NT and its descendants allow you to select another drive assignment order, and thus allow you to have multiple
operating systems on one disk.

V1.2.2 BKM2MIF
Student Notebook
Uempty
...
"%'
%'

%-'./$

(

0 &1121345678
!29$
:-;'/
-'./
(;' %&%+
;'
6 0<&
-'.'/
-'./
",-'.'/

=
6 0<*
-'./
-'.'/
",-'./

=
Figure 3-8. /boot/grub/grub.conf LX032.0
Notes:
The GRUB configuration file, /boot/grub/menu.lst, is nothing more than a predefined series
of commands that could just as well have been entered on the GRUB command line.
Storing these commands in a file though makes booting far more convenient...
The file starts with a few general configuration options:
default=0 This specifies the default operating system to be started.
GRUB also allows you to specify the fallback parameter, which specifies
the operating system to boot in case the default fails.
timeout=10 Timeout before starting the default operating system, in seconds.
splashimage=(hd0,2)/grub/splash.xpm.gz This specifies the image to use as
background for the GRUB boot screen. It is a compressed xpm image.
This line also introduces the way GRUB works with disks and partitions.
Since GRUB runs at boot time, before filesystems have been mounted, it
cannot use the filesystem path /boot/grub/splash.xpm.gz. It therefore has
Student Notebook
to identify the disk and partition that the filesystem is on, before the
filename itself can be referenced.
Both disks and partitions start counting at 0, and this can be confusing,
since /dev/hda3 is written down in GRUB as (hd0,2).5
password --md5 $1$U$JK7xFegdxWH6VuppCUSIb. This specifies the MD5-encrypted
password that is needed if users want to make real-time changes to the
configuration. It is created with the command md5crypt, which is part of
the grub program.
Passwords can also be specified in the operating system sections below, in
which case booting the operating system and making changes is not
allowed for that particular operating system.
When general options are all defined, specific operating systems need to be predefined.
For this, the following keywords may be needed:
title The title of the operating system, as it shows up in the GRUB boot screen.
root The root partition of the filesystem. All files that are referenced later on are
stored on this filesystem.
kernel The kernel image that is to be loaded, and all options that need to be
passed to the kernel.
initrd An initial root disk that needs to be loaded.
unhide Unhide the partition specified (i.e. change its type so that Windows
systems will recognize it).
hide Hide the partition specified (i.e. change its type so that Windows systems
will not recognize it).
rootnoverify The root of the operating system is the partition specified, but don't try to
verify and access this as GRUB does not support the filesystem type.
makeactive Mark this partition active in the partition table.
chainloader +1 To boot this operating system, invoke the chainloader, which needs to load
the first sector of the specified root partition.
5
There is a file, /boot/grub/devices.map, which is created automatically by GRUB, and which matches Linux device names to GRUB
device identifiers.

V1.2.2 BKM2MIF
Student Notebook
Uempty
+

%
"?D$25
?

%

$

%
,
%
?
% ! "
A$"
/

%

"(
/ % #

Figure 3-9. Kernel Booting LX032.0
Notes:
When the user selects a Linux operating system to boot at the lilo-prompt, lilo will load the
Linux kernel and, if specified, the initial root disk into memory, and will start the Linux
kernel.
Because of space constraints, the Linux kernel is compressed, but has an uncompress
program prepended to it. Actually, it looks like a self-decompressing ZIP file in DOS.
The uncompress program uncompresses the Linux kernel and puts it into memory. Then, it
starts that kernel proper.
The first thing the kernel does is try to detect all the hardware for which it has support built
in. This includes hard disks, serial devices, mice, graphical adapters, keyboards, network
adapters and the like. By far most of these adapters can indeed be autodetected, but some
can't. In that case, their configuration parameters (most notably, IRQ, I/O and DMA levels)
need to be passed to the kernel as boot options. If this is the case, consult the
Hardware-HOWTO for details.
Student Notebook
After the kernel has detected all hardware, it switches the processor to the so-called
"protected mode", which basically means that from that point on multitasking is possible in
a multiuser environment.
After this, if specified, it mounts the initial root disk. From this disk, it loads any modules it
needs to access the true root filesystem. Then it mounts the true root partition. This root
partition is one of the boot options that was passed to the kernel by the boot loader.
After the kernel is started properly, it starts the /sbin/init process with Process ID 1. This init
process will then continue the boot process. The kernel might also start a few additional
kernel support daemons.
While booting, the kernel generates a lot of messages which will scroll off the screen very
fast. And since no filesystem is available to store these messages on, they kind of vanish. If
you wish to retrieve these messages later however, you can run the dmesg command to
see them.

V1.2.2 BKM2MIF
Student Notebook
Uempty
" 4
AA

#
$ ##

> $
8
(
7 -
<
:
J

;

#
Figure 3-10. System initialization LX032.0
Notes:
When init is started, it reads the /etc/inittab configuration file. In this file the "runlevel" is
stored. This runlevel basically identifies the way the system is supposed to run (and thus,
what applications to start) at this time.
There are seven runlevels, but on most distributions only runlevel 3 and 5 are really
important for us. 3 means full multiuser mode with a text-based login (you'll need to start
X-Windows yourself), and 5 is the same, but with an X-Windows based login screen.
The default runlevel is specified in the /etc/inittab file itself, and also specified in this file is
what programs to run in each runlevel.
Student Notebook
..
K #
< #<
K & >

AA>A> AA>A>
88AA>A8 $ AA>A #

((AA>A(
77AA>A7
<<AA>A<
::AA>A:
JJAA>AJ
;;AA>A;
K # #>

A A

3
%
K
!$,,333
A A ,<,

,
K$ #
((7<:J
A A ( 4#
77<:J
A A 7 '1 #,(,;+
<7<:J
A A <
:7<:J
A A :
J7<:J
A A J
;7<:J
A A ;
K$ 4 #J

4J
AAF((A
,

'4 + #J
Figure 3-11. /etc/inittab LX032.0
Notes:
The most important lines of the /etc/inittab file are shown here.
The first line identifies the default runlevel, if no runlevel was specified somewhere else. In
this case, the default is three.
The second line tells init always to run the /etc/rc.d/rc.sysinit script. This script does a
number of important low-level tasks, such as:
• Activating swap spaces
• Setting the hostname
• Checking the root filesystem for errors, and remounting it read-write
• Turning on quota support
• Loading important kernel modules
• Checking all other filesystems and mounting them
• Deleting various lockfiles which may have been left over from a crash

V1.2.2 BKM2MIF
Student Notebook
Uempty • Enabling the clock

The third set of lines tells init to run the /etc/rc.d/rc in runlevels 0 through 6, with the
runlevel as parameter. We will look at this script in the next visual.
Then, the update daemon is started. This daemon ensures that cached write requests will
actually be written to disk. It basically does this by issuing a sync command every thirty
seconds or so.
After that, the trap for the Ctrl-Alt-Delete three-finger salute is set. This means that if you
press this key combination, the command shutdown -t3 -r now is executed, effectively
rebooting your system.
Then, six gettys are started on tty1 through tty6. This means that there will be six virtual
terminals configured, allowing you to log in as different users six times. These six virtual
terminals can be reached by pressing Alt-F1 through Alt-F6.
The last command, which is only run in runlevel 5, will start the xdm command. This will
present a graphical login screen.
Note that some commands have the prefix once, some have wait as prefix, and others
have respawn. This identifies what init should do after it has started the command:
• wait means that init should wait for the command to finish before it is allowed to go on
with the rest of the init sequence.
• once means that init is allowed to go on with the init process even before the command
has finished.
• respawn means that init should start this process, put it in the background, and monitor
its existence. Once the process dies, init should start a new one. This is commonly used
for login processes, because a new login screen will then automatically appear, even if
the user manages to kill off all its processes.
Student Notebook
" " 0" 5 1
AA>A>
AA AA>A< AA>A<>A06
A A ( AA>A<>A 6

>>>
A A ;
>?
000 +7@4'
A

000 +7@4'
A

000 +7@'&(A(
000 +7@'0 A0
000 +7@

A

000 +7@<< A
Figure 3-12. Starting Services (System V init style) LX032.0
Notes:
The /etc/rc.d/rc script is a very funny script. It is started somewhere after /etc/rc.d/rc.sysinit,
but before all the gettys are active. And it has the runlevel as parameter.
What this script basically does is the following:
• It changes to the directory /etc/rc.d/rc<runlevel>.d
• In this directory, it makes a list of all scripts that start with a K, sorts this list on the two
digits after the K, and executes these scripts with the stop parameter.6
• Then, it makes a list of all scripts that start with an S, sorts it, and executes them with the
start parameter.
These scripts are in fact not scripts at all, but are symbolic links to generic scripts in
/etc/rc.d/init.d or /etc/init.d.7 Every server program that is installed on a Linux system is
supposed to have a corresponding control script in this directory, with the same name as
6
Obviously, kill scripts are not relevant when booting straight into a runlevel. It is possible however to change runlevels in a live system
by running the command init <new runlevel>. In that case, it might be necessary to stop services, for instance when switching from a
multiuser to a single-user runlevel.
7
Depends on the distribution used.

V1.2.2 BKM2MIF
Student Notebook
Uempty that service. By making a symbolic link from /etc/rc.d/rc3.d to that particular script, the
administrator ensures that a particular service is started (or stopped) in a certain runlevel.
And by specifying a two-digit number after the S or K, he can even influence the order in
which services are started and stopped.
This scheme was first used in AT&T's system V (five) Unix. That's why it is called the
System V init style. It is used, among others, by Red Hat and SuSE. Other Linux
distributions may use other init styles. But for all distributions the principle holds: init reads
the /etc/inittab files and starts all the programs that are listed there. There is never a magic
or secret program or script being started. That means that it doesn't really matter which
distribution you use. Take a look at the /etc/inittab file and read the scripts that are listed
here. This will tell you how the system is started.
Student Notebook
"
K%#
#
K #
K%
K%#
K#
# 6 7 6 7
Figure 3-13. Configuring Services per Runlevel LX032.0
Notes:
The tksysv tool, its text brother ntsysv, its scriptable sister chkconfig and its competitors
ksysv and serviceconf all allow you to select which services to start and stop in a certain
runlevel.
The list of available services is in the left column, and is in fact just a list of scripts in
/etc/rc.d/init.d or /etc/init.d (depending on distribution and version). By adding these scripts
to one of the columns on the right, the link to that script is automatically created in the right
directory. Plus, the priorities are all set up correctly.
To change runlevels use init <runlevel> or telinit <runlevel>. telinit is a symbolic link to
init, so it really doesn't matter which one you choose.

V1.2.2 BKM2MIF
Student Notebook
Uempty
" " "

> A

#
? $

?
#
>,
0 @B4
0, @B4
, @B4
@B4
Figure 3-14. Starting and Stopping Services Manually LX032.0
Notes:
The scripts in the init.d directory can perfectly be used to start and stop individual services
manually, for instance after changing configuration files. All scripts will always accept the
status, start, stop and restart parameters. In addition to that, some scripts will also accept
other parameters, like reload (only reread the database without restarting the server).
You can call the script directly using its full pathname,8 but on a Red Hat system, you can
also use the service command. This does nothing more than calling the script for you, with
the parameters you specified. But it saves you from typing a lot of slashes and dots.
8
The init.d directory is not in your $PATH, and for good reason: The scripts sometimes have the same name as the daemon itself.
Student Notebook
! " 3'
,2/
- % ' %+
-#
-
%
1
"?* *

,

D$25

! #
# 3 #
Figure 3-15. Booting Linux in Single-User Mode LX032.0
Notes:
Sometimes it is necessary to have full control over your system, with no users or other
programs doing all kinds of unexpected things. This is possible in Linux, and is called
Single-User Mode.
For single-user mode, you will need to specify the single option to the kernel when your
system boots. The Linux kernel will then boot as normal, but init will only run
/etc/rc.d/rc.sysinit and then start a bash shell. It will not start all the normal services, so
users can't log in over the network, and it will not ask for a root password. (So it can be
used if you forgot your root password, to set a new one.)
Obviously, in single user mode the system is not very useful, except for you. So after your
system maintenance, you need to switch back to normal mode (runlevel 3 or 5). This can
be done by rebooting the system with shutdown -r now or by exit-ing the shell. In that
case, init will just continue its boot process, which may or may not be the correct thing to
do, depending on the actual changes you made.
Single-user mode may be protected by specifying restricted and passwords in /etc/lilo.conf.
Refer to the manual page of lilo.conf for details.

V1.2.2 BKM2MIF
Student Notebook
Uempty
" &# !"
?-?

2 # !,,

2

$
34

0 0$
0 0

/

Figure 3-16. Shutting Down a Linux System LX032.0
Notes:
If you need to shut down a Linux system, don't just pull the plug, but ensure that somehow
the shutdown command runs. We've in fact already seen how to do that: by pressing
Ctrl-Alt-Delete, which was trapped in /etc/inittab, or by entering the command itself on the
command line.
Some display managers allow the console user to perform a shutdown as well. This seems
like a security exposure, but think of this: the console user can just as easily yank the
power cord if he wants to do a shutdown. Allowing him to do a proper shutdown is probably
a better way of doing things.
Student Notebook

1) Name the four steps that form the startup order of a Linux
system:
______________________________________________
2)
How would you select a graphical login screen (xdm)?
______________________________________________
Notes:
1.
2.

V1.2.2 BKM2MIF
Student Notebook
Uempty
"
4

5"?
5"? /5$ 4
/5$ '"?D$25+
4%
%

5 "?

D$25

4
# !,,
Notes:
Student Notebook

V1.2.2 BKM2MIF
Student Notebook
Uempty Unit 4. System Administration Tools

This unit will give you an overview of the different integrated system
administration tools that might be available on your distribution.

• Discuss the main characteristics of system administration tools
• List some distribution-specific administration tools
• List some general-purpose administration tools

Accountability:
• Checkpoint Questions
• Exercises
© Copyright IBM Corp. 2001, 2002 Unit 4. System Administration Tools 4-1
Student Notebook

,

,

Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty
" $ /
"

%

/

4,
F,
,

.
,
C
?

C
! 4 C

4C
Figure 4-2. System Administration Tools LX032.0
Notes:
System Administration Tools are integrated tools for system management. This means that
these tools allow you to manage your whole system configuration from within that one tool.
System Administration Tools typically use one or more different interfaces, based on the
way you connect to them. Typical choices include:
• Text-based: The tool typically uses the curses library to present a menu-driven interface
in a text-based terminal. This is typically used when logged in via a text console or via a
telnet or ssh session.
• X-based: The tool typically uses some X library to present a graphical interface. This can
only be used in an X-based environment.
• Web-based: The tool typically listens on a TCP port for HTTP traffic. The menu screens
themselves are generated using HTML. This requires you to use a browser which
connects to the right port.
The landscape of system administration tools is constantly changing. There is a number of
reasons for this:
Student Notebook
• Writing a system administration tool is a good project for graduate students.

• Currently, there is no authoritative configuration framework on the market which allows
and encourages software developers to write their management tools using that
framework. That means that the tool developers have to write the menu screens that
allow you to manage various applications, such as Apache, Samba and so forth. This
costs a lot of effort and the past has shown that it virtually impossible to keep up with
changes in the applications if you are not part of the project yourself.
To understand this better, consider the man tool. This has become the de facto tool for
manual pages. Every software developer can write manual pages and have them
automatically included in the set of manual pages that already exist on a system (simply
by copying them to /usr/share/man). The developers of the man command themselves
therefore don't have to write the manual pages for all commands anymore, except the
manual page for the man command itself.
• When a distribution makes a change to for instance the way an IP address of an
interface is stored on disk, the tool needs to develop too.
Since distribution manufacturers will want the tools to be available when the distribution
is released, they typically will write their own tools that are able to perform base system
configuration on their distribution. These tools change from one version to the next,
tracking closely the configuration setup from the distribution.
All this means that the perfect tool does not yet exist. You therefore have to decide for
yourself whether to use these tools at all, or do all configuration by hand. And if you decide
to use a tool, you need to decide for which tasks you are going to use it, and what interface
you are going to use.
Another configuration in a large installation might be whether the tool is easily extendible,
so that menu screens which control your own, locally developed applications can be added
to the tool.

V1.2.2 BKM2MIF
Student Notebook
Uempty
)* *
/ , , #

4,

%

#

F
Figure 4-3. Red Hat "setup" LX032.0
Notes:
setup is Red Hat’s menu-based front-end for the various tools that are part of a text-based
installation. That means that using this front-end you can start the following tools:
• authconfig: Authentication configuration
• kbdconfig: Keyboard configuration
• mouseconfig: Mouse configuration
• ntsysv: Management of system-V init scripts
• sndconfig: Sound configuration
• timeconfig: Timezone configuration
• Xconfigurator: X Window configuration
All these tools can also be started directly from the command line.
Student Notebook
""-*8"/*9*8"/:*
L

L 4
L 7F

Figure 4-4. SuSE "YaST", "YaST2" LX032.0
Notes:
YaST and YaST2 are the preferred system administration tools on a SuSE system. They
were created by SuSE to work specifically with SuSE and do not work on any other
distribution. It cannot be easily extended but, within its limitations, is quite powerful and
works well.
Although the names are similar, YaST and YaST2 differ a lot in their functionality.

V1.2.2 BKM2MIF
Student Notebook
Uempty
*
"$*
4"

4
Figure 4-5. Caldera "LISA" LX032.0
Notes:
LISA is the system administration tool written for Caldera OpenLinux. Just as YaST, it is not
easily extendible but, within its limitations, it works well.
Student Notebook
;

AA> >
?
#

%
5 ?

2

/

M2 4# M 4

,
-
/
Figure 4-6. Webmin LX032.0
Notes:
Webmin is a fairly new tool. It is from the ground up designed as an open-source, cross
platform system administration framework. This means that it does not include the actual
administration tools itself, but is only a series of perl scripts that allow people to write
administration modules for various operating systems and administration tasks. The default
webmin distribution comes with a whole load of administration modules though.
Webmin is licensed according to the BSD Open Source license, but modules may be
licensed with other licenses, such as the GPL.

V1.2.2 BKM2MIF
Student Notebook
Uempty
;

,YHUVLRQ>>&

AA> >
. .
34!..# 34
# 3
.
.

(8888
Figure 4-7. Webmin Installation LX032.0
Notes:
Webmin installation is basically very simple. Untar the file you downloaded from
http://www.webmin.com and run the setup.sh script. This script will answer a series of
questions and will configure, setup and start webmin for you.
When this script is finished, you can access webmin immediately. This is done by launching
a web browser such as netscape or lynx, and connecting to port 10000. You need to login
with a username and password, and can then use any of the available modules to
configure your system.
Student Notebook
; "
Figure 4-8. Webmin Screenshot LX032.0
Notes:
This is an example screenshot of Webmin.

V1.2.2 BKM2MIF
Student Notebook
Uempty

1) Name some distribution specific tools.

______________________________________________
______________________________________________
______________________________________________
2) What are the steps to install Webmin?

______________________________________________
______________________________________________
______________________________________________
______________________________________________
______________________________________________
Notes:
1.
2.
Student Notebook
"
%

,

4F
/ 4 #

,

Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty Unit 5. Packaging Tools

This unit will teach you how to use the most common packaging tool
on a Linux system: RPM.

• Describe the basic principles of RPM
• Install RPM packages
• Describe the RPM build process
• Create simple SPEC files

Accountability:
• Checkpoint Questions
• Exercises
© Copyright IBM Corp. 2001, 2002 Unit 5. Packaging Tools 5-1

Student Notebook

$/
" $/
%
$/

!
3!
Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty
) 01
2
%
/
5

#
$ " DH
? 4 >>! 3
>
$
$/'A#AA
+

%
! DADD
% '#
+
Figure 5-2. Red Hat Package Manager (RPM) LX032.0
Notes:
The Red Hat Package Manager or RPM is a tool which was developed by Red Hat
Software, who still maintain it, but released under the Gnu General Public Licence (GPL)
and has proven to be so popular, that a lot of other distribution manufacturers use it as well.
RPM is a very versatile program which solves a lot of problems that a distributor of software
typically faces:
• Management of source files
• Management of the build process
• A distribution method and format for binary files, including pre- and postinstall scripts.
RPMs can be created by anyone, not only the manufacturer of your distribution.
When a certain system uses RPMs to install packages, a database of installed packages is
stored in /var/lib/rpm. The database itself is in rpm format too, so it cannot be read directly.
You will have to access the database using the rpm command.

Student Notebook

#

>>&
>>& 3!

>>

3

3 <=; 3 <)8
>
>

><=;>

><)8>

Figure 5-3. RPM Philosophy LX032.0
Notes:
The creators of RPM made an important observation: In the Linux world, the person or
organization writing the software would in most cases not be the person or organization
that would distribute the software. Because of this, RPM uses the philosophy of “pristine
sources”. This means that the software that was developed is contained into a “Source
RPM” file in a pristine state, exactly as it came from the developer. In this source RPM file
(normally identified with the extension .src.rpm), you will also typically find patches and
sample configuration files from the distributor, and most importantly, a SPEC file.
The SPEC file contains all the information to unpack the pristine source, to patch it and to
compile it on any architecture. It also contains information on what files are included in a
binary RPM.
With a correctly configured SPEC file, the only thing required to compile a package is the
rpm -bb (build binary) command on the target architecture. The binary RPM can then be
distributed to all users of the distribution on that architecture.

V1.2.2 BKM2MIF
Student Notebook
Uempty When a developer develops a new version of its software, the only thing the distributor
needs to do is rerun the rpm -bb command, and a new version can be distributed. (Well,
that’s the theory...)

Student Notebook

9% '
"

$/
$/
2
$/
5 4

"

5
"

2
"

?

,# #
,
J8 %
,,
H%

#
4 >
#
%
2$
Figure 5-4. RPM Installing, Freshening and Upgrading LX032.0
Notes:
Installing an RPM can only be done if it was not already installed. If the RPM was already
installed, you need to do an upgrade or a freshen. The difference between an upgrade and
a freshen is that an upgrade will always install an RPM, even when a previous version was
not installed. (It will act like a regular installation in that case.) A freshen only installs
packages that actually have been installed previously. A freshen therefore is very handy to
use if you downloaded a lot of patches from the Red Hat site, and you are not sure which
patches you actually need. You can then just freshen all the packages, and only the things
you need will actually be installed.
The basic syntax for installing, freshening and upgrading is respectively:
rpm -i package-filename.rpm
rpm -F package-filename.rpm
rpm -U package-filename.rpm

V1.2.2 BKM2MIF
Student Notebook
Uempty Note that there is a difference between the package name and the package filename. The
RPM file which contains the package foo would generally be called
foo-version-release.architecture.rpm.
There are a number of options which make life a little easier on you:
-v gives more information on what rpm is doing (verbose).
-h prints 50 hash marks while installing, so that you can track the progress. If you run
rpm from a script, you can use these hash marks to make your own progress bar.
--nodeps disables dependency checking.
Files in an RPM are marked as program, documentation or configuration files. When doing
an upgrade or freshen, all files which were marked as configuration file, will be saved with
the .rpmsave extension. You will then need to make all configuration changes to the old
configuration file to the new configuration file as well. The reason behind this is that
configuration files tend to undergo syntax changes between versions, and rpm is not
intelligent enough to incorporate the old configuration changes into the new configuration
format.
When installing, freshening or upgrading packages, you may also specify the Web address
of the package file instead of the package file itself. This allows you to do upgrades even on
systems which are very tight on disk space, but do have access to a network (for instance
the Internet). Just ensure that the RPM files can be reached, either through FTP or HTTP,
and you can do an upgrade. If you need to go through a proxy, there are options available
to specify this proxy as well. Look at the rpm manual page for details.

Student Notebook
'
2 $/

5 4

?

,,

%
Figure 5-5. RPM Uninstalling LX032.0
Notes:
Uninstalling is even more simple than installing an RPM. Just specify the package name
(note: not the package filename) and the package will be uninstalled. Unless of course,
when another package is dependent on the availability of this package.

V1.2.2 BKM2MIF
Student Notebook
Uempty
<
N $/

5 4

C

?

, .
%
,OP .
% >
,
O
%,P .
%,
,

%
,

%
,

,

,

Figure 5-6. RPM Querying LX032.0
Notes:
RPM Querying is the process of retrieving information about installed packages. The basic
syntax is rpm -q package-name, but that will only display the package name. It's the
options that make querying interesting:
-a queries all packages which are installed on the system.
-f <file> queries which package contains <file>.
-p <package-file> queries the (not yet installed) <package-file>.
-i displays all package information: name, version, release, install date, group, size,
summary, description, build information and so forth.
-l lists all files in the package.
-s displays the state of each file in the package. The state is either normal, not installed
or replaced.
-d displays all files that are listed as documentation.
-c displays all files that are listed as configuration files.

Student Notebook
With these options you can do a number of great things. Below are some examples:
• Do you want to know which package the nslookup program is in? Try rpm -q -f
`which nslookup` or rpm -q -i -f `which nslookup`
• Need to know what documentation is available for a specific command, and man -k
commandname does not work? Try rpm -q -d -f `which nslookup`
• Need a lot of data to test a network connection? Try rpm -q -i -l (Oh well, you can
always cat /dev/zero too...)
• Need to know which not yet installed RPM package file contains the program "pico"?
Sorry, you are out of luck here. RPM only queries one rpm package at a time, so you
need to do something like this:
for package in `ls *.rpm`
do
rpm -q -l -p $package | grep -q pico
if [ $? = 0 ]
then
echo $package
fi
done

V1.2.2 BKM2MIF
Student Notebook
Uempty
&

,# >

$/H
#
,,
#

>

$''''''*?'?*7

$
>
$ ;'??*7

@"
@

$,$ ;'?
>
C

;'
*'7
>
;'
*'7?*7

>
$ ;'??*7

$
Figure 5-7. rpmdb Database LX032.0
Notes:
The dependency information that is used by the RPM system is not based on actual
package names, but rather on capabilities. This is done because multiple packages might
actually offer the same capability. Suppose for instance that a certain package requires the
availability of a mail reader. Then it doesn't matter whether pine, elm, mail, mailx or
netscape messenger is installed, as long as at least one of these is present.
This makes it a little difficult to determine which packet to install if a certain capability is
missing though. For this, the rpmdb database is created. What basically happens is that,
when the distribution is created, all rpm files are queried for the capabilities they provide.
This is stored in the rpmdb database, which is an rpm file itself and can be installed like any
other rpm. When installed, this database can be queried using the --redhatprovides option.
See the example in the visual to determine how this works. Note that not all distributions
support this scheme.

Student Notebook
5
1 $/

&
/J%

5 4

8

?

,OP 1
, 1
%
,
O
%,P 1 $/
Figure 5-8. RPM Verifying LX032.0
Notes:
The verify option verifies all files that are supposed to be present in the RPM against the
files that are available on disk. This is a very easy way to check for any unauthorized
configuration changes.
The following checks are performed on each file in an RPM:
5 MD5 checksum. This is a very hard to fool checksum which verifies that the
contents of a file have not changed.
S File size. This verifies that the size of the file has not changed.
L Symbolic link. This verifies that a certain symlink has not changed.
t File modification time. This verifies that no one has altered the file.
d Device. This verifies that the major and minor numbers of a device are still
intact.
U User. Is the owner of the file still the same?
G Group. Is the group of the file still the same?

V1.2.2 BKM2MIF
Student Notebook
Uempty M Mode. Are permissions, SUID, SGID bits and the file type still the same?
If a file checks out ok, there will be no output. If there is a discrepancy however, the name
of the involved file will be listed, prepended by the discrepancy information. The output line
will then look like this:
# rpm -V sendmail
SM5....T c /etc/sendmail.cf
This means that a discrepancy was found in the file /etc/sendmail.cf. This is to be
expected, since this file is a configuration file (hence the "c" in the line. The discrepancy
information in this case is SM5....T, in which each letter denotes a certain discrepancy
from the list above. In this case the following discrepancies were found: size, mode, MD5
checksum, modification time.

Student Notebook
"
$/H

#
?
%
!,$?/
"

%%
1
%
>

D+EDE4FG
>

0'7;?*7

0'7;?*7&
B4
Figure 5-9. RPM Signatures LX032.0
Notes:
The RPM Package format also features the ability to include a digital signature of a
package, and most distribution builders actually make use of this feature as an effective
measure against trojan horses introduced in an RPM after release by the distribution
builder.
Verifying this signature is a two-step process. The first step is to obtain the public key of the
distribution builder. This key is stored in a text file which can usually be found on the
original CD-ROMs or on the distribution website. This public key needs to be added to your
"keyring", your database of public and secret keys in your home directory. This is done with
the following command: gpg --import /mnt/cdrom/RPM-GPG-KEY.
The second step is to verify each individual package. This is done with the command rpm
--checksig packagename. If the output is "gpg OK", then you can be sure that it was
indeed the distribution builder that built this individual package, and that no one has
tampered with it since.

V1.2.2 BKM2MIF
Student Notebook
Uempty

$/
# 3!
.
$/
=
"
%

5!
" !
"

4

% A
1

#
!

%
$/
2 $/
3!
$/
Figure 5-10. Creating RPMs LX032.0
Notes:
As said before, the SPEC file contains all the information to create a binary RPM from the
pristine sources. It is divided into eight sections:
• The preamble section contains information about the package in general. Here you will
find things like the name, the version number, a description, a summary, a list of source
files and other general information.
• The prep section contains all commands that are needed to prepare for the build
process. This includes unpacking the pristine source and applying patches, if needed
• The build section contains all commands that are needed to actually build the software.
• The install section contains all commands to install the software in its proper location
(on the build system).
• The install and uninstall scripts are scripts that are executed on the users system
before or after the software is installed or uninstalled. These scripts might for instance
add user accounts to the system, check for disk space, and so forth.
• The verify script can be used to verify whether the install was successful.

Student Notebook
• The clean script can be used to clean the build system after a built of the software.
• The file list is the list of files that are to be contained in the binary RPM.
Since the SPEC file lists both the source files (in the preamble section) and the binary files
(in the files section), it can be used to create both the source and binary RPMs. The SPEC
file is typically stored in the source RPM as well.

V1.2.2 BKM2MIF
Student Notebook
Uempty
-!" ?)9;@
K,&#,(>8>>&
,(>8A>
,(>8A/%
,(>8A$3/3
3=>.? 3=>.-$&-?
>H A -/9N+!
,''
-/ O

I ED:

"-) .6 JK)/L
M O

) .6 J) ,
O0,
3=>.? , ,

@ $
"
@ , J

O $.
,,

@ O .
,,

"
@

$
Figure 5-11. Example Scenario: Hello, World! LX032.0
Notes:
The visual introduces a simple scenario which we are going to use in the next few visuals.
Suppose you are the distributor of Useless Linux 1.0, and you want to include a program
“hello”, which prints the text “Hello, World!” on the screen. Instead of writing this program
yourself, you’ve searched around the internet and found such a program. The source file is
called hello-1.0.tar.gz and contains three files:
• A file called hello.c, which is the C source code for the program.
• A file called Makefile, which contains the information for make, which builds the binary.
• A file called README, which contains information about the program, including the
copyright statement, a short description of the program, and a description about the
build process.
It is your job to create the SPEC file so that this program can be integrated into your
distribution build process.

Student Notebook
"
>
>DF!"" 0

>
,@ .6

P@
8 @'
@
!
,@ED:
E
@Q
2
@ '(
R$ @2:'
8 @9N+:
D@6 :"H"S$ A
T

O

) .6 J) ,
O0, , ,

$ " ,
J
Figure 5-12. hello.spec Preamble Section LX032.0
Notes:
The first section of a SPEC file is always the preamble section. As you can see in the
visual, it contains a number of one-line statements, describing several parameters of the
package. It also contains a multi-line description.
Note the difference between the version and release numbers: The version number is
something that was decided upon by the developer, while the release number is assigned
by the distributor. This makes it possible to separate different trial SPEC files and their
output from each other.

V1.2.2 BKM2MIF
Student Notebook
Uempty
9 9
% "
T

"1 D+#N29:R#R9 '

("1 D+#B2 !F#R9 '(
T$
1 D+#N29:R#R9 '

T
1 D+#N29:R#R9 '

T"
T 1 D+#N29:R#R9 ' FQR+F
$
Figure 5-13. Visual Caption LX032.0
Notes:
The visual shows the contents of the next four sections: prep, build, install and files.
The prep, build and install sections contain the commands required to perform each of
these three steps. Note that we’re not using absolute pathnames here. This is a
requirement, since different distributions will use different directories for the source and
binary RPMs, and for the build directory. Instead, we’re using the shell variables
$RPM_SOURCE_DIR and $RPM_BUILD_DIR, which are automatically set by RPM.
The files section contains the files that need to be stored in the binary RPM. Some of
these files may be preceded by a special identifier, such as %doc. This means that the file
is a documentation file which needs to be relocated to the documentation directory, usually
/usr/share/doc/<packagename>.

Student Notebook

AAAA ?2$!3

3! AAAA 3!
$
,OPO
P

B

B

B
B

B B
B

BB $/
B

BB
$/

,,

,, #
#
,##
Figure 5-14. Visual Caption LX032.0
Notes:
In order to finally run the build process, we need to put all source files (hello-1.0.tar.gz) in
/usr/src/redhat/SOURCES1 and the SPEC file in /usr/src/redhat/SPECS. We can then run
the rpm -b command, which will execute the build process. The letter after the “b”
determines when the build process will stop.
1
Other distributions might use different directories here

V1.2.2 BKM2MIF
Student Notebook
Uempty
$
$/ AAAA $/

5 $/ AAAA$/ AOP
! $/ $/
>
C
D+?*7 '?*7

P@ @- $/
8 @'8 @9N+:
@NR@O
''

>
C
D+?*7 '?*7

$
'
' FQR+F
>
D+?*7 '?*7

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
.6 J
>

Figure 5-15. After RPM Build Process LX032.0
Notes:
When the build process is finished, the source RPM is located in /usr/src/redhat/SRPMS,
and the binary RPM is located in /usr/src/redhat/RPMS/<arch>. The binary RPM can then
be queried, installed and deinstalled as any other RPM.

Student Notebook
2
D
$/
Figure 5-16. GnoRPM and kpackage LX032.0
Notes:
GnoRPM is the graphical user interface to RPM management from the GNOME project. It
can do the same as the command line interface, but it is probably easier to learn.
An alternative to GnoRPM is kpackage, which is part of the KDE Desktop Environment.

V1.2.2 BKM2MIF
Student Notebook
Uempty
:
$
!%$H

$/H

"

#
Figure 5-17. up2date LX032.0
Notes:
up2date is a program that was developed together with RPM. It can be run out of crontab
and, if configured correctly, connects automatically to the site of the distribution builder to
download the latest RPMs.
These RPMs can then be installed automatically or after querying the system administrator.

Student Notebook

1) Which basic modes of operation does rpm have?

______________________________________________
2) Which command can I use to verify that the permissions of

/etc/sendmail.cf are still correct?
______________________________________________
Notes:
1.
2.

V1.2.2 BKM2MIF
Student Notebook
Uempty
"
$/#

%
$/ $/ $/
$/

%

3!
3!

$/

D $/ %
%

$/
Notes:

Student Notebook

V1.2.2 BKM2MIF
Student Notebook
Uempty Unit 6. X Window System

The unit will teach you how to use and configure the X Window
System.

• Describe the basic architecture of the X Window System
• Configure XFree86
• Start and stop X
• Describe the function of the window manager
• Use X over a network

Accountability:
• Exercises
© Copyright IBM Corp. 2001, 2002 Unit 6. X Window System 6-1

Student Notebook

F
! F=;

F

2F# %
Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty
A; #"
D
2" 2-"F
" #
/"
! F! " >
" 4

2 ,#
Figure 6-2. X Window System LX032.0
Notes:
The X Window System, X for short, is the graphical user interface of Linux. It is
implemented as a separate program that runs in user space and it uses a client/server
architecture.

Student Notebook

#
,(
,7
,<
,:
,J

2-"F
Figure 6-3. In the beginning... there was the batch system LX032.0
Notes:
In the beginning of UNIX, the only way a system could get any work done was by batch
processing. This meant that you handed your job to the system operator (typically on punch
cards or on tape), and the operator would load and execute your job when the system was
finished with other jobs.

V1.2.2 BKM2MIF
Student Notebook
Uempty
#
,(
,7
,< (
,:
8

,J

2-"F

Figure 6-4. Later... the interactive typewriter system LX032.0
Notes:
The next step in the development of servers was the interactive system, where you could
connect your own terminal to the server, typically via a serial port. The input for each
process would be read directly from the keyboard of the terminal, and the output would be
sent to the terminals output device (monitor or printer).

Student Notebook
#

4
,
=:
== =
=> :
4
,(
H B
G C
F D
E
4
,7
,< 4#

A
%
,:
,J

2-"F
Figure 6-5. Later yet... a graphic terminal on a network LX032.0
Notes:
Later yet a new type of terminal was introduced: one with a graphical output device which
could not only display individual characters, but individual dots (pixels) at any given
location. Such a terminal would have its own little control program running locally, and
would typically use a mouse. In order to make use of this terminal, programs had to be
written specifically for them. Programs that would not be capable of using the graphical
display would be run from an “xterm”, which emulated a regular typewriter terminal in a
graphical environment.

V1.2.2 BKM2MIF
Student Notebook
Uempty
A3% ."$
F
F #
! ,
( ! ,

,(
! ,
&
,&
Figure 6-6. Client/Server Architecture LX032.0
Notes:
The X Windows System uses a client/server architecture, which makes it very flexible. The
central piece of software is the X server, which runs on the X station. This server traps all
keyboard and mouse events, and sends them to the appropriate application. If an
application wants to put something on the screen, it sends that data to the server, which
then performs the necessary hardware calls to the graphical adapter.
Any application can connect to the X server, but there should always be one special
application active: the window manager. This window manager basically puts a border
around each application window, and allows you, for instance, to drag windows around the
screen. There are numerous window managers available, each with their own style.
Other applications also connect to the X server, and have their data displayed through it.
Common examples are:
• xterm, which emulates a terminal screen, allowing you to enter Linux commands
• xeyes, which displays a pair of eyes on your screen, looking at the mouse pointer
• xbanner, which displays a background image
• xcalc, a mathematical calculator

Student Notebook
• xedit, a GUI-based editor

and many, many more.
The connection between the X server and the X clients (including the Window manager) is
a TCP/IP connection. It is therefore possible to run the X client on another system.

V1.2.2 BKM2MIF
Student Notebook
Uempty
-! A"
F
F #
$?/
2-"FA 4
F #

F
/ ,
F #

D2"
F
>> F
2-"FA 4 F! F #

Figure 6-7. Examples of X Stations LX032.0
Notes:
There are several X stations possible:
• Real X stations are hardware devices which consist of a monitor, a keyboard, a mouse
and a ROM chip containing the X server program. These devices cannot do any local
processing and thus need to be connected to a network at all times.
• UNIX/Linux stations with a graphical display can run an X server as a separate
program. In most cases, the X server will grab the entire graphical screen.
• Several X servers exist that run under MS-Windows: Hummingbird eXceed, WRQ
Reflection X and many others. These programs typically open an MS-Windows window,
and run the X server inside it.
On most UNIX/Linux systems, the X clients and X server run on the same system,
communicating with each other via the TCP/IP loopback interface or via a UNIX socket1.
This makes it possible to use X as a standalone solution.
1 A special file (type s) in a UNIX/Linux filesystem which makes TCP/IP-like communications between two processes possible. Because
these sockets are limited to the local filesystem, they are generally more secure than TCP/IP connections. Furthermore, their overhead is
slightly less, thus increasing performance.

Student Notebook
A" !
F, # 4F=;

?

AA>4=;>
?F, ## 4
/,F
AA> %>
FD

AA>4>
Figure 6-8. X Servers in Linux LX032.0
Notes:
The X Server that is most often used with Linux is XFree86, an open source server which
is, just like Linux, developed as a joint effort of various programmers on the Internet. Their
web page is http://www.xfree86.org.
You don't have to use XFree86 though. Thanks to the modular design of both Linux and the
X Window System, you can basically plug in every X Server that is available on Linux.
Currently, there are two commercial X Servers available as well: Metro-X and Xi Graphics.
The advantage of commercial X-Servers (which are not really expensive by the way) is that
these commercial products in general support the newest adapters that become available
earlier and sometimes better. When buying a new computer you might be in the situation
that XFree86 does not support your graphical adapter, but Metro-X or Xi Graphics do.

V1.2.2 BKM2MIF
Student Notebook
Uempty
A%GE
F=;# <>4 #

F=;I/ '/
+
F=;I1D(;' (;,1D
+
F=;I 1D'
1D
+
F=;I <'
<
+
F=;I)888'
%)888
+
>>>
F=;# :>4?

Figure 6-9. XFree86 LX032.0
Notes:
About a year ago the XFree86 project released XFree86 version 4. Some distributions are
currently already using this version, and other distributions are holding off a little because
of some reported problems. That means that there are currently two different versions of
XFree86 in production use.
XFree86 version 3 has been used for a number of years and is considered stable. It
supports a large number of graphical adapters, and therein lies its biggest problem:
Because of the support for all these adapters, a single binary image would be too large.
That's why the XFree86 project releases multiple binaries, each with support for a number
of related adapters. You need to install the binary that has support for your adapter before
you can do anything.
This approach became more and more difficult to support. That's why the XFree86 project
decided to use another approach for version 4. In this version, XFree86 consists of a single
binary which is able to detect the adapter that is being used, and that can load the
modularized support for that adapter in real-time. This makes installation and configuration
easier.

Student Notebook
A%GE
!
L# F=;
D

/
/
0
AAF((AF=;! F=;! ,:
!
!GE ,4
A%GE"9!GE 4
,

A%GE3

A $
"A 3
!
! F

Figure 6-10. XFree86 Configuration LX032.0
Notes:
On every system which will run the XFree86 X-Windows server, the configuration file
/etc/X11/XF86Config (or /etc/X11/XF86Config-42) file will have to be created. This file
contains the hardware characteristics of the system running the server: graphical adapter
type and characteristics, monitor characteristics, mouse type and keyboard type and
language.
The correct setup of the configuration file is pretty complicated and very tricky, since
incorrect monitor settings may damage your monitor. Let's repeat that: Incorrect monitor
settings in /etc/X11/XF86Config or /etc/X11/XF86Config-4 may damage your monitor!
Don't say you weren't warned!3
It used to be that you had to set up this file all by yourself, but nowadays there are several
programs (SuperProbe, xf86config, XF86Setup, Xconfigurator, xvidtune and others)
available that can help you out in about 99% of the situations. Only exotic hardware,
specifically laptop screens, will pose a problem for these programs. And even then, there is
a lot of help and sample XF86Config files available on the Internet.
2
XF86Config-4 is only used if you are in a mixed version 3/4 environment and want to refer to the version 4 configuration file.
3
This is no joke. Multiple fellow students have had this happen to them.

V1.2.2 BKM2MIF
Student Notebook
Uempty
"..A==.A%GE

! "#
#$%%&#'#$%%#('
! "#
#$%%&#'#$%%# #)#
!
! "#
#$%%&#'#$%%# #*#
!
+
! "#
#$%%&#'#)

,
-'!
! !
.
! //
$0'-)!
,
0

#1
23#3#!

,
+
/
4 **/$5625%17/%/18
9 :!)+
+:!)4 **/$;%<=*>
?@ </5&A)

9 "/=/5*/=/
+ %17/%/18%%/%17/%<17%%1%*%1%/18%/1%/17%/8
/
,
23
4 **/$5$.
9 :!)+
!:!)4 **/$
!
, D

233(!
234 **/$5$.
+ 4 **/$5625%17/%/18
2!
62 "%&

' 2!
2 "7
#
+%17/%/18
9 //
9
!%17/%/18
,
' (7=84(87:7J;

' 2!
2 "%&
+%17/%/18
9 //
9
!%17/%/18
,
'
(7=84(87:;:0
,
Figure 6-11. Sample /etc/X11/XF86Config LX032.0
Notes:
The /etc/X11/XF86Config file is split up in a number of sections that each describe a
different part of the XFree86 configuration. The file is too complicated to cover here in full,
but we will look at some of the more important sections. The full documentation is available
on http://www.xfree86.org.
Section "Files"
RGBPath "/usr/X11R6/lib/X11/rgb"
FontPath "/usr/X11R6/lib/X11/fonts/misc/:unscaled"
FontPath "/usr/X11R6/lib/X11/fonts/75dpi/:unscaled"
ModulePath "/usr/X11R6/lib/modules"
EndSection
This section describes the locations of various files that are needed by XFree86.
Section "Keyboard"
Protocol"Standard"
AutoRepeat500 5
XkbKeymap "none"

Student Notebook
EndSection
Section "Pointer"
Protocol "PS/2"
Device "/dev/psaux"
EndSection
The two sections above describe your input devices: keyboard and mouse.
Section "Monitor"
Identifier "TP770X-LCD-1280x1024"
VendorName "IBM"
ModelName "TP770X (13.7)"
HorizSync30-65 # multisync
VertRefresh 50.0-70.0
Modeline "1280x1024" 110 1280 1328 1512 1712 1024 1025 1028 1054
EndSection
This section describes your monitor and the monitor capabilities. This section is by far the
hardest to set up. The first three lines are easy, since they are just ASCII strings describing
the hardware. The next two lines, HorizSync and VertRefresh describe the horizontal
synchronization and vertical refresh rate ranges of your monitor. In the example above the
monitor can handle horizontal synchronization rates ranging from 30 KHz to 65 KHz, and
can handle vertical refresh rates ranging from 50 Hz to 70 Hz.
The last line is the Modeline. This line describes the video timing parameters for a given
resolution. The line above describes the video timings for the resolution 1280x1024: The
driving frequency should be 110 MHz, the horizontal resolution is 1280 pixels and the
numbers 1328, 1512 and 1712 describe the timings used to wrap the light ray back from
the right to the left. The horizontal resolution is 1024 pixels, with three additional number
describing the timings with which the light ray cycles back to the top of the screen.
There should be a different Modeline for each of the resolutions that your monitor can
support. Information about calculating modelines can be found in
/usr/doc/HOWTO/XFree86-Video-Timings-HOWTO. If you start changing modelines by
hand, it is absolutely vital that you read this document and understand it. Numerous
people have damaged their monitor beyond repair by "overclocking" it.
Section "Device"
Identifier "TP770X-XGA"
VendorName "IBM"
BoardName "TP770X"
Option "accel"
EndSection
This section describes your video card.
Section "Screen"
Driver "svga"
Device "TP770X-XGA"

V1.2.2 BKM2MIF
Student Notebook
Uempty Monitor "TP770X-LCD-1280x1024"

DefaultColorDepth 16
Subsection "Display"
Depth 8
Modes "1280x1024"
ViewPort 0 0
Virtual 1280 1024
EndSubsection
Subsection "Display"
Depth 16
Modes "1280x1024"
ViewPort 0 0
Virtual 1280 1024
EndSubsection
EndSection
This section describes the actual resolutions and color depths that are to be used. The first
line "Driver" tells XFree86 which driver (XFree86 Server) to use. It then specifies which
device and monitor (see above) to use. It then specifies the default colordepth, which is the
number of bits per pixel. The more bits per pixel you allocate, the more different colors you
can display simultaneously, but also the more video memory is required.
The display subsections at last describe the different modes that are to be used give a
certain color depth. In the case above, both for the 8 and 16 bit colordepth, only the
resolution 1280x1024 is used. We could however specify more modes here, as long as
each of the modes also has a corresponding modeline in the monitor section. We could
then cycle through these modes with Ctrl-Alt-NumericPlus and Ctrl-Alt-NumericMinus.
There is one catch however: the actual resolution being displayed may be less than the
amount of memory allocated for this screen. In that case, the concept of virtual screens is
introduced. Virtual screens means that your virtual display (where applications display their
windows) is larger than the monitor can currently display. In this case, only part of the
virtual screen is displayed, but you can scroll simply by moving your mouse beyond the
borders of your actual screen. The "Virtual" keyword defines the actual size of the virtual
display, and the "ViewPort" keyword defines what part of the virtual screen is displayed
initially, and what parts fall beyond the border of your actual screen.
Just a last note: Most people have no need to edit or even understand this file directly. The
available tools (Xconfigurator, XF86Setup, xvidtune and xf86config) usually are good
enough to set up this file automatically.

Student Notebook
"..A==.A%GE 3C

* #* */ *
" *F=;! * " *"5/)J7J(JF(JFDQ(JF*
8* 8*88 1 - *2 % *
"
#*/8**! * /- *2 % *
"
#*08**!0* & <8,;:
3 1$J8,((8
** 3
* 4A@(88* *#*
3 " */1!*
*/* #*<#*
*D* 5- *2 % *
** 3
** * *
*4 * " * 8*
*4* #*/1!*
*
4J* / *"5/)J7J(JF(JFDQ(JF*
**
=
*4* *
*
*#:*
=
3 /*(87:4@;=*
*"
#* 3
" *08* 3
#*%* *$"*
?
*F%* ** 3
3
*"
#*
" */8*
#* *
?
*#**A#A *
?
*** A7*
?
*3 <5 ** *
?
*R4/
**:J*
3
Figure 6-12. Sample /etc/X11/XF86Config-4 LX032.0
Notes:
The visual shows a sample /etc/X11/XF86Config-4 file. You will notice roughly the same
sections and structure as the version 3 config file, but the syntax has changed slightly.

V1.2.2 BKM2MIF
Student Notebook
Uempty
" A
A
F=; #

2
F#A?=
F=; #
!
F=; #
'
@+
#
03'% +D-?/3'+

0
F !33?=
Figure 6-13. Starting X LX032.0
Notes:
XFree86 itself is started with the X command. This starts X on the first free virtual terminal
(usually number 7, so it can be selected with <Alt-F7> or <Ctrl-Alt-F7>) However, with only
XFree86 running you won't get anywhere: you will just get an empty, grey screen with a
mouse pointer. This is useful for debugging your XF86Config file, but in order to do
anything useful, you need to start a window manager too.
With the startx command this is exactly what is accomplished. First, XFree86 is started
and a few seconds later, your favorite window manager is started.
What your favorite window manager is, is determined by reading the configuration file
.xsession in your home directory. If you want to change your window manager, use the tool
switchdesk, which will store your preference in the .xsession file, will stop the currently
running window manager and start the one you selected.4
Since Linux has a large number of virtual terminals, there is nothing keeping you from
starting a second X session on another virtual terminal. This is accomplished by starting an
4
switchdesk is only available on Red Hat Linux. On SuSE, you need to change your WINDOWMANAGER shell variable in
$HOME/.bash_profile.

Student Notebook
X server on display ":1". When you start X via startx you need to make sure that startx
understands that this is an option not for itself, but for X, so the full startup line will become
startx -- :1.
Once you have started multiple X sessions, you can toggle between them with
<Ctrl-Alt-F7> and <Ctrl-Alt-F8>.

V1.2.2 BKM2MIF
Student Notebook
Uempty
" A
2

F=;
# %

!,,5%

F=;

! AAF((AF=;!
Figure 6-14. Stopping X LX032.0
Notes:
X can be stopped in two ways:
• The proper way, by using the appropriate button from your window manager. This will
gracefully stop all applications, and exit X.
• The quick and dirty way, by pressing Ctrl-Alt-Backspace. This will first stop the X server,
and then all applications will ungracefully die because their connection is lost.
Ctrl-Alt-Backspace can be disabled in /etc/X11/XF86Config.

Student Notebook
"
/ F,
F=;
?

H#

$F=;
?
4

4
!

2 #
Figure 6-15. Session Managers LX032.0
Notes:
A Session Manager is a program that manages X sessions. This means that it will start
XFree86 and display a graphical login prompt. If a user tries to log in, it will authenticate
this user and start the users favorite window manager. When the user logs out, it restarts
XFree86 and displays a login prompt for the next user, and so forth.
On a Linux system there are several different session managers available, because nearly
each window manager comes with its own session manager. The most common are xdm,
kdm and gdm.
On most distributions, the session manager is started from init in a certain runlevel, but we
can also start it manually from the command prompt.

V1.2.2 BKM2MIF
Student Notebook
Uempty
A(#
! F! F

#!A"
! #!A" %
#
" #

!
Figure 6-16. X Networked LX032.0
Notes:
All connections between the different X components (server, window manager,
applications) are TCP/IP connections. This means that we can run them over a network
too. And that opens up some interesting possibilities.
There are three levels of networking with X-Windows:
• The first level is by just running a single application over the network. This allows you to
run an application on another system, but redirect the display to your local screen. This
is very useful if that application is not supported or present on your local system.
• The next level is by running your whole X session over the network. In this case, all
applications and your window manager are all running on a remote system. This is
useful if you have disk- or dataless clients: clients that do not have any disk space to
store data on, or do not have any disk at all. All user data and programs can be stored
on a single server, and are run from this single server.
• The last level is by using a session chooser. In this case, before logging in, you get a list
of servers that are willing to manage your session. This is very useful if you have
multiple servers, and users need to be able to run their sessions from their local system
on each of these servers.

Student Notebook
A$ (#
4 F=;
/
F

!A"
' + ' 4 +
-%
Figure 6-17. X Applications Networked LX032.0
Notes:
The visual shows the first level of networking X-applications. Both the XFree86 server and
the window manager (and possibly other applications as well) are running on the local
system. Only a single application is running on the remote host (the application server).

V1.2.2 BKM2MIF
Student Notebook
Uempty
$ /.

? 'F +
1

,@''

1
R9D:QG%@''
1

! !
!2

1" @''
1"
! #
1 =
Figure 6-18. Applications over TCP/IP LX032.0
Notes:
If you want to run an application from another server, then the only thing you basically need
to do is start the application with a special option telling the application what X server to
use.
This can be done using two methods:
• First, every X application will accept the -display option.
• Second, every X application will look at the $DISPLAY environment variable if no
-display option is given, to determine the X server to contact.
The X server to contact is written as <hostname>:<servernumber>[.<displaynumber>], with
<hostname> being the IP address or hostname of the system where the X server is
running, <servernumber> the instance of the X server to contact5, and <displaynumber>
the screen to use.6
5
One system might be running multiple servers, although this is rare.
6
One X server may handle multiple screens simultaneously on so-called dual-headed systems.

Student Notebook
You can imagine that it is not desirable that the whole internet can redirect the graphical
output of their commands to your screen. Therefore, doing this is by default disabled but
can be enabled.
The first, safest method is by using the xauth mechanism. This works roughly as follows:
• When your X server is started, the startup scripts ensure that a random number, called
the "authorization record" is generated. These records are stored in the
$HOME/.Xauthority file.
• Any client who wants to connect to the X server needs to present this authorization
record. If no or an invalid authorization is presented, then access is disabled.
Since normally all applications are started by the same person who started the X server,
they all use the same .Xauthority file and present the right record.
• A client on a remote host obviously cannot access the .Xauthority file directly, so the
authorization record needs to be transferred manually to that other host. This is a
two-part process.
First, on the host where the X server is running, you need to extract the correct record
from the .Xauthority file and store it in a file. This is done with the following command:
xauth extract xauthfile client:0.0
This means that the authorization record to connect to client:0.0 needs to be stored in
the file xauthfile.
You then transfer the file to the other system (using FTP, scp, rcp or any other means),
and add it to the .Xauthority file there, with the following command:
xauth merge xauthfile
Any application started on this host, with the correct -display option or $DISPLAY
environment variable set will now use this authorization record to connect to the X
server.
Of course, smarter ways of doing this are also possible. How about, for instance:
xauth extract - client:0.0 | rsh host xauth merge -
rsh host xeyes -display client:0.0
The second method is less safe but more convenient. In this case, the user who has
already started the X server issues the xhost +<hostname> command. This command
allows all connections originating from <hostname> to succeed. This is obviously less
secure, since every user on that particular host is now able to make a connection, not just
the intended user. And this method is vulnerable to IP address spoofing and DNS
poisoning.
Note: If you log in to another system using telnet or ssh, then the telnet or ssh daemon will
typically set the $DISPLAY variable for you. ssh will even handle xauth authentication for
you, and will make sure that the communication between the X client and server is
encrypted.

V1.2.2 BKM2MIF
Student Notebook
Uempty
A" (#
4 F=;
/
!A" F

-%
Figure 6-19. X Sessions Networked LX032.0
Notes:
The visual shows the next level of networking X-Windows. In this case, both the
applications and the window manager are running on the remote system. Only the XFree86
Server is running locally.

Student Notebook
A" /.

? .

!
3AAF((A4 AF
AAF((A4 A4 ,

3AA%A% A% AA%A% AF

3AAF((A A >
? F
A3I6 7
Figure 6-20. X Sessions over TCP/IP LX032.0
Notes:
In order to run your X-session over a network, you need to set up your display manager so
that it accepts session requests over a network. How this is done depends on your session
manager.
For xdm, there are two things you need to do:
• You need to edit the /etc/X11/xdm/Xaccess file so that it allows any host to get a login
window. The line that specifies this is usually already there, but is commented out. So
you just need to uncomment this line.
• You also need to edit the /etc/X11/xdm/xdm-config file because most distributions have
set the XDMCP port to zero (meaning: invalid port) as a safety feature. This is usually
done at the last line of this file, so if you comment out this line (with an exclamation
mark), you've disabled this safety feature.

V1.2.2 BKM2MIF
Student Notebook
Uempty For kdm, there are again two things you need to do:
• You need to edit the /etc/kde/kdm/Xaccess file so that it allows any host to get a login
window. The line that specifies this is usually already there, but is commented out. So
you just need to uncomment this line.
• You need to edit the /etc/kde/kdm/kdmrc file and enable xdmcp direct and indirect
requests.
For gdm, the procedure is again different. Here, you only need to edit the file
/etc/X11/gdm/gdm.conf to enable xdmcp direct and indirect requests.
When you're done setting up your display manager, you need to restart it. Then you need
to start the X server on the client workstation. Since the only program running here is
XFree86, we can start it with the X command. We only need to tell it that it has to query the
display manager to get a login prompt and a session. So the complete command becomes
X -query <hostname>

Student Notebook
"

/ #

* *.
/

A3 6 7
Figure 6-21. Chooser Sessions LX032.0
Notes:
You can imagine having multiple display managers in your environment. In that case, it is
very useful to be able to choose the display manager you are going to use. This is done
using a chooser. Usually, this functionality is built into the session manager so we don't
need to configure a separate program. We just call the session manager a little differently.
If the session manager receives a so-called indirect query, it does a broadcast over the
network to discover all systems that are willing to manage displays, and displays a list of
these hosts. You can choose one of these hosts, and this host will then manage an
X-session for you.
To start X and receive a chooser, the command line is X -indirect <hostname>

V1.2.2 BKM2MIF
Student Notebook
Uempty
% "
#F#

%
#%
F=; % #
! ##
!
@(88
2-"F%A
A> , 4A@(88
! AAF((AA
#
F=;!
F=;! ,:
)5)
5 D)
@'')
5 D)@'')
F
Figure 6-22. Font Server LX032.0
Notes:
In general, X applications do not ask the X server (XFree86) to display individual pixels, but
ask it to display complex structures like rectangles, circles, lines and so on. Furthermore,
they can also ask the X server to display a certain character out of a fontset. This saves a
tremendous amount of bandwidth.
For this to work, the X server needs to have available all the fonts an application would
possibly use. Obviously this leads to a large management problem if multiple custom fonts
are installed and used beyond the basic set.
To cope with this problem you can use a font server. This is a central server which holds all
the fonts that are used in your organization. When XFree86 needs to display a font, it
downloads it in real-time from the font server. This saves you from needing a large set of
font files on each client workstation.
Most distributions come with a font server enabled by default, and the local XFree86
always uses the local font server. This font server is usually accessed through a so-called
Unix socket. The specification in /etc/X11/XF86Config will thus look like this:

Student Notebook
Section "Files"
FontPath "unix/:7100"
EndSection
In order to use a font server over the network, you specify it using the following syntax in
the /etc/X11/XF86Config file:
Section "Files"
FontPath "tcp/hostname:7100"
EndSection
Depending on your distribution, you also might need to enable the font server to serve
network requests. Some distributions disable this by default.

V1.2.2 BKM2MIF
Student Notebook
Uempty

1) What is the function of XFree86?

______________________________________________
2) What is the function of a window manager?

______________________________________________
3) How do you run an individual X application over a network?

______________________________________________
______________________________________________
Notes:
1.
2.
3.

Student Notebook
"
F

! F=;

F

2F# %
Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty Unit 7. Block Devices, RAID and LVM

This unit covers the most common block devices on a Linux system:
floppy disks, hard disks and RAM disks, and the two ways the limits of
these in terms of reliability, speed and size can be overcome: LVM and
RAID.

• Name the most important characteristic of a block device
• List various block devices
• List the device naming scheme for IDE and SCSI hard disks
• Partition a hard disk and list the device naming for partitions
• Use RAM disks
• Configure and use LVM
• Configure and use RAID

Accountability:
© Copyright IBM Corp. 2001, 2002 Unit 7. Block Devices, RAID and LVM 7-1
Student Notebook

-
%#
#%#
# "3 ! "
%
% #

2$/%
! 1/
! $"
Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty
&
*5%#* #* *

'*%*+
34

%
%

%
$/%
1/#
$"#

%#

**
$" A1/
Figure 7-2. Block Devices LX032.0
Notes:
A block device in the Linux world is any device which allows "random" access. This means
that it is possible to write something to location n, and then go backwards to read
something from location m. In other words: a block device is any device that supports the
"seek" command. Typical examples are hard disks, hard disk partitions, floppy disks, RAM
disks, LVM volumes, RAID volumes and files.
Examples of devices that are not block device are printers, consoles and network adapters.
And examples of devices that can be both are tape drives (can be used as block device, but
seeks are terribly slow), or CD-RW drives (reading is done as block device, writing as serial
device).
A block device can be used for different things, for example to hold a filesystem, as a swap
space, or "raw", for instance using tar. But as we will see in this lecture, it can also be used
for LVM and/or RAID.
Student Notebook
&(
%##

A#
>

$00 "
,.'Q;'''"'

$00 ?.'Q;'''

$00 *.'Q;'''

8(>>>
%' 4=+

>>>"3%' 4=+
>>> ! "%' 4(7=+
Figure 7-3. Block Device Naming LX032.0
Notes:
Block devices all have a special file representation in /dev.

V1.2.2 BKM2MIF
Student Notebook
Uempty
%&

#
#

% &

&
"" "';;'
%
M
Figure 7-4. Floppy Disks LX032.0
Notes:
Floppy disks are slow and have a fairly low capacity, but their biggest advantage is that they
are a true worldwide standard for removable devices.
If you have bought unformatted floppy disks, then you might need to low-level format them
first with the correct size information. This is done with the fdformat command, with a
special /dev entry that identifies the density and size of the disk.
Floppy disk drives typically have a mechanical eject. This means that the system cannot
detect or prevent that a user is ejecting the disk. That might be a problem if the disk
contains a filesystem, since Linux performs write caching on all filesystems, meaning that
write requests are not carried out immediately, but are only done when the disk has been
idle for some time. This is done to increase performance by optimizing cache usage.
However, if a user ejects a disk without first unmounting it (unmounting a disk will cause all
data to be written to disk), the data not yet written to disk will be lost. So you always need to
unmount a floppy disk and wait for the disk light to go off before ejecting.1
1
Some other architectures, such as the Sun Sparc, have a software eject, where the disk can only be ejected by running the eject
command. And this command only works if the disk is not mounted.
Student Notebook
)&
/ #

"3 ! "
"3'" #3 +
/47%' A#+
/47

/47

!,$?/'"+
# A#A>>>
! "' !
" +

,>>>
/4@(J% '

+
-
D 4
# "3

!,$?/
&
#>>>
# A#A>>>&>>>4
Figure 7-5. Hard Disks LX032.0
Notes:
Hard disks are the most common form of persistent storage on a typical Linux system. Two
types are most common on the Intel (and other) architectures: IDE and SCSI.
IDE and the newer variant, E-IDE allow a maximum of two disks to be attached to one "bus"
(ribbon cable). Only one of these disks can have its controller active, and is then said to be
"master" of the bus. The controller of the master controls the operation of the slave too.
A typical E-IDE adapter supports two buses, and there is a maximum of two E-IDE
adapters per system, yielding a total of eight E-IDE devices per system.
Most CD-ROM, CD-RW and DVD players for the home market are attached as if they were
IDE devices too. This is governed by the ATAPI standard.
SCSI is a technology which is technically superior to IDE, but generally more expensive. It
has various subtypes which each have their own performance characteristics and physical
connector size and types. Depending on the subtype, there is a maximum of 8 or 16
devices on each bus, one of which is the SCSI controller itself. This leads to a maximum of
7 or 15 disks on each bus. However, an adapter typically supports multiple buses, and

V1.2.2 BKM2MIF
Student Notebook
Uempty multiple SCSI adapters may be used simultaneously, as long as each adapter has its own
IRQ.
The SCSI standard also allows for CD, DVD, tape drives, Zip drives and other block devices
to be attached.
The Linux kernel supports a total of 128 SCSI disks by default. These devices are
numbered /dev/sda through /dev/sdz, then /dev/sdaa through /dev/sddx.
Student Notebook
)&
"3 ! "%

/4

?

4

4

' 4 4;<"3(( ! "+
% /5$

)J (

)J
7

4

J
4
4A
A
;
4
4A A
@
4

4
Figure 7-6. Hard Disk Partitions LX032.0
Notes:
All IDE and SCSI disks can be partitioned into smaller chunks, which can be used
independent of each other.
The partitioning scheme used on Intel machines dates back to the IBM XT Personal
Computer, when a 10 MB disk was extremely expensive and state-of the art.2
The partition table is stored in the last 64 bytes of the master boot record, and allows for a
total of 4 primary partitions to be defined. This used to be enough, but later on it became
apparent that more partitions were needed.
At that point in time, it was decided that one of these primary partitions could have a special
identification, which allowed it to be used as an extended partition, which could be split up
further into a number of logical partitions. Since the extended partition does not use a
fixed-size partition table but rather a linked list, the number of logical partitions is unlimited.
Linux by default supports a maximum number of 63 logical partitions on IDE disks, and a
maximum of 11 logical partitions on SCSI disks. The last has to do with SCSI subdevice
numbering: According to the SCSI standard, each device can be split up into 16
2
Most of the earliest IBM PCs came without a hard disk and only had one 5.25" floppy disk of 360 KB...

V1.2.2 BKM2MIF
Student Notebook
Uempty subdevices. One is used for the device itself, four for the primary partitions, which leaves 11
for the logical partitions.
Student Notebook
/
/
! ? A
N
! A&A #A

?
4
!
4

%
1#!? *%*

?
? A7 4>>>

DH 4
#> >
! A&A #A

%

4

Figure 7-7. Partitioning Tools LX032.0
Notes:
A large number of tools exist for partitioning your hard disk. The most important thing to
consider when choosing a tool is not whether it is able to generate a partition table (which
is only 64 bytes after all), but what it can do with the content of your partitions if you decide
to move or resize a partition.

V1.2.2 BKM2MIF
Student Notebook
Uempty
$&
$/%%#

&

4

(;$/%'7JJ 4+
$/%

"%( "%'$% %';*
$/%

"'
- G
' +
%

! **
Figure 7-8. RAM Disks LX032.0
Notes:
A RAM disk is a block device which is not stored on persistent media, but rather in the
memory of the system. It is not used often, but can sometimes be handy, especially if you
need a really fast hard disk, or if your system doesn't have any persistent media on board.
Linux supports a maximum of 16 RAM disks by default, but can be recompiled to support
up to 255 of them. They are automatically created when you start them, with a size
dependent of the amount of data that you write to it. And since they are stored in memory,
their contents vanish when you shut down your system.
RAM disks occupy memory and will keep doing that until you shutdown your system or
deallocate the RAM disk by hand with the freeramdisk command. Unfortunately, this
command is not included by default in all distributions.
One of the more common uses of a RAM disk is to help boot your system. Suppose for
instance that you have a system with SCSI disks, but you have compiled your support for
SCSI in the form of modules. In order for the Linux kernel to access the SCSI disks then, it
needs to load the SCSI modules first. But these modules are stored on the SCSI disk... To
solve this problem, you need to create an "initial root disk", which is a file containing a
Student Notebook
compressed ext2 filesystem with the SCSI modules in it. Such a file can be created using
mkinitrd. LILO loads this file into memory alongside the kernel, using the SCSI BIOS.
When Linux starts, it uncompresses this disk into a RAM disk and is thus able to load the
SCSI modules. Only then can it actually mount the true root filesystem from the SCSI disk.

V1.2.2 BKM2MIF
Student Notebook
Uempty
/**&
*
*#%#
4
4 (;
#
A#A
QQ
34

$ "
,

. ?
Figure 7-9. The "loop" Device LX032.0
Notes:
Files are block devices too. The most obvious example of this is a tar file, which is
essentially an image of a tape. In most cases, a file can be specified where a block device
is typically used, and vice versa.
There is one exception to this though: A file containing a filesystem cannot be mounted
directly. For this to succeed, the use of a special "loop" device is needed. Linux supports a
maximum of 16 of these devices by default, but this can be changed with a kernel
recompile. Linux will automatically invoke one of these devices if the -o loop option is
specified with the mount command, as shown in the visual. This allows you to mount, for
instance, floppy disk or ISO images.
Student Notebook
5 0=1
%
#
#
1
& #

& %&
1 / #
#
? 1 '%

+ 1 D
'1D+
1 '1+

34 '3+ &':/5+
3H 1D 1
'1+ % %#
1

%
& 13
&1D1
Figure 7-10. Logical Volume Management (1) LX032.0
Notes:
Logical Volume Management is a technique to overcome some limitations that are imposed
on the system with the traditional partitioning scheme:
• It is virtually impossible to resize or move a partitions since other partitions are always in
the way.
• The largest partition you can create is one that spans your whole disk, and thus the size
of any partition is limited by your disk size.
To overcome these limitations, LVM introduces some extra abstraction layers in this
scheme:
1. Every hard disk or hard disk partition is assigned to a Volume Group (VG). Each hard
disk or hard disk partition is then called a Physical Volume.
2. Each Physical Volume is split into Physical Extents of identical size. The default size of a
PE is 4 MB, but this can be changed when the VG is defined.

V1.2.2 BKM2MIF
Student Notebook
Uempty 3. PEs in a VG are then combined into Logical Volumes. Each logical volume is a block
device and can be used to hold a filesystem, for instance. Since an LV always consists of
1 or more PEs, its size will always be a multiple of 4 MB.
The PEs that are part of an LV do not have to be on the same physical disk or disk partition,
as long as they are all part of the same volume group. That means that a logical volume
can be larger than your physical disk size. Furthermore, the PEs that are part of an LV do
not have to be sequentially located on disk. This means that it is easy to extend an LV.
If a volume group becomes full, it can be extended by adding another PV (a hard disk or
hard disk partition).
Student Notebook
5 0:1

#
#
'%
+ '%
+
3 3 3 3 3 3
3 3 3 3 3 3
3 3 3 3 3 3
#
#
Figure 7-11. Logical Volume Management (2) LX032.0
Notes:
The visual shows a volume group that consists of two physical volumes. In this case, whole
disks are used as physical volumes, but we can use disk partitions too. Each PV is split into
a number of PEs (nine in this case), which are our building blocks for building LVs.
Four LVs have been created, with two spanning two PVs. One PE is still unallocated and
can be used to extend an already existing LV, or can be used to create a new LV.

V1.2.2 BKM2MIF
Student Notebook
Uempty
5
#
% A

'
=+
4 %
" &
# '%
+

$?
!#
*#88*
#
''$?
!# *#88* #
:&'+''''

! ..>>.>>%#
Figure 7-12. LVM Implementation Overview LX032.0
Notes:
Implementing LVM comes down to three tasks:
• First, you need to identify which physical volumes you are going to use, and format them
accordingly. This is done with the pvcreate command.
• Second, you need to create the volume group which is going to exist of the physical
volumes you created in the first step. This is done with the vgcreate command.
• Last, you need to create the logical volumes in the volume group. This is done with the
lvcreate command.
After this, you can use your logical volumes, now called /dev/<VGname>/<LVname>as
regular block devices.
Student Notebook
5
67
" &
#
J3 67K6 7J6 7K
/#3 1 1 #

67

1
Figure 7-13. Physical Volume Commands LX032.0
Notes:
Two commands allow you to manage your physical volumes:
pvcreate This command initializes a physical volume.
pvmove This command allows you to move all PEs on a PV to another PV within the
same volume group. This is useful if you want to take that PV out of the
volume group.
pvdisplay This command allows you to view information about a PV.

V1.2.2 BKM2MIF
Student Notebook
Uempty
52
J3 6 47K6 767J67K
!#
J67K

#
! 6767J67K

# #
6767J67K

$ #
# #
J K67

!
#
!67
34
#
' % #+
6767J67K
"
#
' %#+
67
#
Figure 7-14. Volume Group Commands LX032.0
Notes:
Several commands are available to let you work with volume groups:
vgcreate This command allows you to create a new volume group. As part of the
command, you need to specify the PE size that is going to be used in this
volume group. Furthermore, you always need to specify the name of at
least one physical volume.
vgdisplay This command displays information about a volume group.
vgextend This command adds a physical volume (which has already been initialized
with pvcreate) to a volume group.
vgreduce This command removes a physical volume (which has already been
emptied with pvmove) from the volume group.
vgchange This command changes attributes of a volume group.
The most important change is to deactivate a volume group with the
vgchange -a n <vg> command. This needs to be done before either
vgexport or vgremove can be executed.
Student Notebook
vgexport This command exports a volume group. In other words: it makes it inactive.
This needs to be done before you can remove the corresponding disks and
put them in another machine.
vgimport This command imports a volume group. In other words: it makes it active.
This needs to be done after you have added a disk or set of disks to your
system which already contain a volume group.
vgremove This command deletes a volume group.

V1.2.2 BKM2MIF
Student Notebook
Uempty
5
36 47J3 6 7K67J67K

!# #
67J67K

#
! 3JLK6 4767J67K
34 # &O&P
SO&P
3J3K6 4767
$&# &O&P
#,O&P
67J67K
$ ##
Figure 7-15. Logical Volume Commands LX032.0
Notes:
There are several commands that let you manage logical volumes too:
lvcreate This command creates a logical volume of the specified size, with an
optional name, in a certain volume group. You can also specify the physical
volumes to be used.
lvdisplay This command displays information about a logical volume.
lvextend This command extends a logical volume. In other words: It appends
physical extents at the end.
lvreduce This command reduces a logical volume. In other words: It removes
physical extents from the end.
lvremove This command removes a logical volume.
Student Notebook
$ 5
34 A$ #

4 A
# G
"
%

A

41/
*
*

! %

1/ ..
1/ .. .
2 %1/
41/

'C+
Figure 7-16. Additional LVM Considerations LX032.0
Notes:
There are several considerations when working with LVM:
First, understand that extending/reducing the size of a logical volume does not
automatically extend/reduce the filesystem in that logical volume. You need to
extend/reduce the filesystem manually after you extend, or before you reduce a logical
volume. The same is true for swap spaces.
When your volume group consists of multiple physical disks, then it might be advantageous
to use striping on logical volumes. This can improve read/write performance, especially if
large files (larger than 4 MB) are concerned.
The Linux LVM implementation has a "snapshot" capability. This allows you to make instant
copies of logical volumes. There are several benefits from this. Consider for instance the
situation where your logical volume contains a database which needs to be "up" at all
times, but does not allow you to make backups while running. In that case, with LVM, you
can stop the database, make a snapshot of the logical volume that holds the database, and
start the database again. This whole procedure takes less than a minute. After this is done,
you can mount the snapshot logical volume and make the backup at your leisure.

V1.2.2 BKM2MIF
Student Notebook
Uempty Kernel information about LVM can be obtained from the /proc/lvm tree.
LVM configuration is stored in /etc/lvmconf. Since the LVM commands are able to modify
these configuration files themselves, it is almost never necessary to edit these files by
hand.
Unlike other LVM implementations (like AIX), the Linux LVM implementation does not (yet?)
support mirroring.
Student Notebook
$
&
*$ " 4
#%*

!%
4
#
,.%

>>>4
#
"2
%
#

>>> # 4
#
Figure 7-17. RAID LX032.0
Notes:
RAID, which is short for "Redundant Array of Inexpensive Disks" was developed separate
from LVM as a technique to increase the performance of hard disks by packing a large
number of them together.
This was done because people had observed that typical PC hard disks, especially in the
early days of the PC, were slower, less reliable and smaller than the then-used
mainframe-quality disks, but were also less expensive.
So what people started doing was pack a large number of them together, with some
additional control software (usually implemented on a dedicated hardware chip), and use
them as if it were one logical device that was either faster, more reliable or larger than the
individual disks, but was still less expensive than buying one mainframe-quality disk that
would do the same.
It is important to note that the three features (speed, reliability or size) are, to a certain
extent, mutually exclusive. It is possible to create a RAID array that is both faster, more
reliable and larger than a single disk, but this requires a lot of hardware. Usually, RAID
arrays are only used to boost either speed, reliability or size, but not all simultaneously.

V1.2.2 BKM2MIF
Student Notebook
Uempty
$
& 0=1
$", $",8

$",(
( ; ( 7 ( (
7 @ < : 7 7
< = J ; < <
: ) @ = : :
J (8 ) (8 J J
$",:

% $",J

( 7
( 7
< :
<
:
J ;

J ;
@ =
@ =
) (8
)
(8
Figure 7-18. RAID Levels (1) LX032.0
Notes:
In the RAID standards, several different "levels" have been defined. All these levels have
different ways of storing the data on disk and thus will exhibit different characteristics.
The first method, RAID-Linear is actually not listed in the RAID standard. It is implemented
in Linux as a way of simply combining two or more partitions on different disks into one,
larger block device. First the first partition is written until it is full, and then the second disk
is used.
RAID level zero, or RAID-0 for short, is nearly the same as RAID-Linear. With RAID-0
however, data is striped across the different disks. This means that reading or writing a
large file actually puts both disks to work, which theoretically will lead to a doubled
throughput (that is, if your controller, bus, memory and CPU can sustain that). If one disk is
larger than the other, then the last part of the data will not be striped but just stored on the
larger disk.
It would seem that RAID-0 is always preferable over RAID-Linear, but in reality, it is not.
Consider for instance the situation where one of your disks crashes. With RAID-Linear,
there is a good chance that you can retrieve at least half of your files. With RAID-0, every
Student Notebook
single file (except for the really small ones) was stored at least partly on the disk that had
crashed. You should therefore use RAID-0 only for data which can be missed or easily
restored.3
RAID-1 uses the second (and third disk) for mirroring: data written to the first disk is written
to all other disks as well. This will cost a lot of disk space, but means that you can sustain
multiple disk crashes without losing your data.
RAID-4 also offers redundancy, but not by mirroring but by storing parity information4 on a
separate disk. Should one disk (or the parity disk) fail, then the data on this disk can be
calculated from the data on the other disks. RAID-4 therefore needs at least three disks.
RAID-4 uses striping to store the data blocks on disk for increased performance.
RAID-5 is similar to RAID-4 in that it calculates the parity of two disk blocks and stores this
in a third disk block. It also stripes the data onto the disks. The difference between RAID-4
and RAID-5 is that RAID-4 stores all parity information on the same disk. This disk then
quickly becomes a bottleneck, unless this disk is significantly faster than the others. With
RAID-5, the parity information is striped too, leading to better performance.
Several other RAID levels exist, but these are not implemented in Linux, and not widely
used anyway.
3
The author of this course uses a RAID-0 array for storing the /export filesystem of a network install server. If a disk fails, the data on it
can simply be restored from the distribution CDs.
4 The parity in this case is calculated by XORing the data on disk 1 with the data on disk 2. If one of the three elements (disk1, disk2,
parity) should fail, then that element can be calculated based on the other two.

V1.2.2 BKM2MIF
Student Notebook
Uempty
$
& 0:1
$"##

$",J ** $",(
2$"#
$" / K $ $
? %
# %

<4(D%
7 . . <D ! %&
.
8 7 <D
( 7 (D ! -,(%

: < 7D ! (%
% %
J < 7D ! (%
!2 #
Figure 7-19. RAID Levels (2) LX032.0
Notes:
As seen in the visual, the different RAID levels use different ways of storing the data on
disk. This leads to different characteristics. What you should note is that RAID-5 is not
"better" than RAID-1. It is just different and might or might not be suited for your
circumstances.
Student Notebook
!$
&"
$"
"
4%
-
%
2%
$"#
# ..
$"
"

4%
D

' # 4+
$"#
! "%
Figure 7-20. Linux RAID Support LX032.0
Notes:
Linux supports both software RAID and hardware RAID.
Software RAID means that all the RAID logic is built into the Linux kernel. The user can
access the partitions directly, or go through the RAID layer and access the RAID volumes,
which are called /dev/mdn. To implement this, you need the raidtools package, which is
usually supplied as part of your distribution. For Software RAID, the only thing you need is
more than one (IDE and/or SCSI) hard disk. In fact, you can even test it by using multiple
partitions on one single disk, but that negates any benefit you might want to gain from RAID
Hardware RAID is typically implemented in special adapter cards, which look like SCSI
controllers (in fact, they usually are) but contain some special RAID chipsets. Most of these
controllers are supported by Linux. In fact, Linux just detects a single large disk instead of
multiple, smaller ones. Configuring these adapter cards might require special software, but
once the cards are configured, no additional software is needed.

V1.2.2 BKM2MIF
Student Notebook
Uempty
!"#$
&

!$"

' 4$"+
!..
'
'

$ '
(*

'
$

" &$"#..>

$"# ..>
3 AA>A>
! %#A#A 8
Figure 7-21. Linux Software RAID Implementation LX032.0
Notes:
To implement software RAID under Linux, you need to do the following:
First, create the partitions you will want to use as part of your RAID array, if you are not
going to use whole disks. Of course, these partitions should all be created on different
disks, or else the whole idea of RAID is not applicable (Linux Software RAID does allow
you to use multiple partitions on the same disk though, for testing purposes). The partitions
created should have type fd (hexadecimal).
Then, create the /etc/raidtab file. This file contains the logical name and characteristics for
your RAID volume (/dev/mdn) and then lists the disks that make up that volume.
When this is done, you need to initialize the RAID volume with mkraid, after which you
need to start your RAID subsystem with raidstart It is useful to know that the raidstart -a
command is usually part of the startup scripts (rc.sysinit) that come with your distribution.
When all is done, you can access the block device /dev/mdn as any block device.
Student Notebook
$ $
&
$"
%
2 ! ""3

%
$"#
$"A

$'A+
$".
' +
!
$",: $",J !2 G
4
%
" % %,

%

%
$", $",8

Figure 7-22. Additional RAID Considerations LX032.0
Notes:
There are a few things to note when using RAID:
Always put your RAID partitions on different disks, or you will nullify any advantage that
RAID might try to give you.
If possible, use different SCSI and/or IDE controllers for the different disks (or partitions)
that make up your RAID volume. This will increase your performance and reliability.
Never use RAID for your /boot partition, and note that if you use RAID for your root (/)
partition, you will have to create an initial root disk.
Software RAID-4 and RAID-5 needs a lot of CPU time to perform the parity calculations.
For maximum reliability, RAID-4 and RAID-5 allows you to configure spare disks. These
disks (usually only one per array) are not used, until one of the other disks in the array fails.
If that happens the RAID software will automatically start using the spare disk instead of the
disk that failed. The data on that disk is created automatically from the parity information on
the other disks.

V1.2.2 BKM2MIF
Student Notebook
Uempty Do not use RAID-Linear or RAID-0 for swap space. The kernel itself can stripe swap data
over multiple swap spaces, if multiple swap spaces are defined, and can do this faster than
the RAID subsystem. On the other hand, using RAID-1, RAID-4 or RAID-5 can be used to
increase the reliability of your swap subsystem.
Student Notebook

1) T/F RAID volumes can be used as Physical Volumes in an LVM setup.
2) Mirroring is offered by RAID level:

a. Linear
b. Zero
c. One
d. Four
e. Five
3) What command is used to create a RAM disk?

______________________________________________
Notes:
1.
2.
3.

V1.2.2 BKM2MIF
Student Notebook
Uempty
' "
5%##

5%#%%

%$/%1/# $"
#
5%#

**
1 /

# %&
&
$" 4
#
# "3 ! "%
##
#%
Notes:
Student Notebook

V1.2.2 BKM2MIF
Student Notebook
Uempty Unit 8. Filesystems

This unit will teach you what filesystems are and how to handle them.

• Describe what a file is
• Describe what a filesystem is
• List the possible filesystems
• Describe the function of inodes
• Create/mount/unmount filesystems
• Create predefined mounts
• Set up user and group quota

Accountability:
• Exercises
© Copyright IBM Corp. 2001, 2002 Unit 8. Filesystems 8-1

Student Notebook

!A A
!

.
Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty
; %M
! #

- '

+

! #
' +

4
5%!,P#

%,P"

Figure 8-2. What is a File? LX032.0
Notes:
A UNIX file is a consecutive number of bytes with no internal structure. Applications will
have to define their own internal structure (for instance records). These files are stored and
referenced in a filesystem. One file can have multiple references (file names).

Student Notebook
; % M

" #

$ #
%#

%
%

$"1/#

$/%
Figure 8-3. What is a Filesystem? LX032.0
Notes:
The references to a file (the file names) are usually stored in a hierarchical system of
directories, subdirectories and so on.
By using a mechanism called the virtual filesystem the internals of each filesystem are
hidden from the user.
A filesystem is mounted on a mount point, which is an empty directory in another (already
mounted) filesystem. The root filesystem is activated at system startup, and contains the
mount points for all other filesystems.
A filesystem can be stored in any block device.

V1.2.2 BKM2MIF
Student Notebook
Uempty
% "
/ 47
-4<$ "5/T 4
?2-"F 444
,(7,(;,<71- ', +
'? A7+, '/ +,
' +
1! F 4
!,$?/'" ?);;8+
2/ ? '2-"F,% / ,? +
- '-% +
/5 ' +-! '-#-+
A
'%
+
Figure 8-4. Filesystems Supported LX032.0
Notes:
Linux supports a wealth of filesystems. Its native filesystem is ext2fs, the second extended
filesystem. Currently a number of new filesystems for Linux are being developed and are
starting to become available in distributions. These include ext3, ReiserFS, IBM’s JFS and
xfs. All have distinct advantages over ext2fs, but are not as well tested yet.
Filesystems from other operating systems are also supported.

Student Notebook
$/'(
A%
# %(87:'+

5% #

%
" '" 4 +%
'
+ %
%
6 , , ' ' ' 6 , , ,' ' ' '
Figure 8-5. A Typical UNIX Filesystem LX032.0
Notes:
Most filesystems used on a Linux system are typical UNIX filesystems regarding the layout
of the filesystem. When creating (formatting) the filesystem in the partition, the partition is
split up in blocks of 1024 bytes each (default). Each block is given a specific function:
• Superblock
• Inode (short for index node) block
• Indirect block
• Data block
It is not possible to combine functions in a block.

V1.2.2 BKM2MIF
Student Notebook
Uempty
"
% #

'=()<(;<=J
>>>+
!
A

5%&

%

6 , , ' ' ' 6 , , ,' ' ' '
Figure 8-6. Superblock LX032.0
Notes:
The first block of the filesystem (block 1) will be the superblock. It is a very important block,
since it contains information about the rest of the filesystem. Copies therefore are kept on
block 8193, 16385 and so on. Should block 1 become corrupt, then mount will attempt to
use the other superblocks.
The superblock contains general information about the filesystem, for instance, the time of
last usage, the last used mountpoint, the blocksize, and so on. Furthermore, the superblock
(indirectly) points to the list of free inodes and the list of free blocks. Last, the superblock
contains an (indirect) pointer to the root directory of the filesystem.

Student Notebook

0
!( 1
7J;':
%(87:+
!

& >>>
!
%
!
%
%
%
" %
%
%

%

%

%
6 , , ' ' ' 6 , , ,' ' ' '
Figure 8-7. Inodes (Index Nodes) LX032.0
Notes:
An inode is 256 bytes large. With a blocksize of 1024 bytes, this means that there are four
inodes in a block. Each inode contains information about a file: user/group information,
permissions, size, ctime (creation time), atime (last accessed time) and mtime (last
modified time).
It also contains information about the data blocks where the file resides. This structure is a
little complicated but very efficient:
The first twelve data blocks (12 KB) are directly addressed; the block numbers are stored in
the inode itself.
The next data blocks are indirectly addressed. The inode contains a pointer to an indirect
block, and the indirect block contains the block numbers of the data blocks. Since each
pointer is four bytes, we can address 256 data blocks, assuming a blocksize of 1024 bytes.
The next 65536 data blocks are double indirectly addressed: The inode contains a pointer
to a double indirect block, the double indirect block contains pointers to indirect blocks, and

V1.2.2 BKM2MIF
Student Notebook
Uempty the indirect block contains pointers to the data blocks (again assuming a blocksize of 1024
bytes).
The next 16777216 data blocks are triple indirectly addressed. If you read this far you
should be able to figure out how that works. The theoretical maximum filesize in the ext2fs
filesystem is therefore something like 16 GB. However, due to restrictions in other areas,
the maximum filesize in practice is 2 GB.

Student Notebook
&
!

>

G'?
#
+
" <;): ;:(@ " =<)( )8:(

;:(@ > <;): )8:( 4&>
&(87: >> (< &7(
8 4& =<)( 8

8 =<)(
8
%7

Figure 8-8. Data Blocks LX032.0
Notes:
The data blocks finally contain the data of the file itself.
A file may be of a special type: a directory. In this case the data block will contain the file
names in that directory, and the number of the corresponding inode. This leads to a very
interesting concept: a file may have multiple names, even in multiple directories, as long as
the directories are on the same filesystem.

V1.2.2 BKM2MIF
Student Notebook
Uempty
"

%>

- #
- %#

5%&'(87:78:=:8);
+
5,
, ':8);+
Figure 8-9. So... LX032.0
Notes:
It is not important to know the exact internal structure of the ext2fs filesystem. What is
important to know is that there are two important components of a filesystem: inodes and
data blocks. Any file needs an inode and one or more data blocks. If there are no more
inodes or data blocks available in the filesystem, the filesystem is full.
If you really want to use your filesystem to the limit, it is important to tune it according to the
data you expect.
The blocksize is 1024 bytes by default. However, this size should be increased if you expect
a large number of large files.
The bytes-per-inode is 4096 by default. With a blocksize of 1024 this means that for every
four data blocks there is one inode available. If you expect a large number of small files,
decrease this value, since you will probably want one or two inodes per data block.
In general, it is easier to explain to the users why a filesystem is full if there are no more
data blocks left, than it is to explain that a filesystem is full if you ran out of inodes. And

Student Notebook
since an inode is smaller than a data block, you usually overestimate the number of inodes,
just to be sure. The default values of mke2fs also do this.

V1.2.2 BKM2MIF
Student Notebook
Uempty
% %
#

$ 0$1
4
M444
N
0
M
%

/%%

-!
34

#
4
Figure 8-10. Other Filesystem Features LX032.0
Notes:
All filesystems are able to store your files, possibly under multiple names. They also all
support the default UNIX permissions (rwxrwxrwx). They do however differ in the additional
features that they can offer. Some of the features that can be offered by filesystems are:
• Access Control Lists: These are lists of user and/or group names with the permissions
that these users/groups might have on the file. This allows you to set permissions that
go further than the standard possibilities. It is for instance possible to define that a
certain group is able to execute a program with the SUID bit set, and another group is
able to execute it, but without the SUID bit.
Currently, the Linux kernel itself does not have support for ACLs, although certain
filesystems may support it. A kernel patch is available to add ACL support to the Linux
kernel, but this patch has not been integrated into the mainstream kernel (at the time of
this writing).
• Journaling: This is a technique where every intended write action is first listed in a
journal (a fixed-size file or partition) and only then performed. If the action has
succeeded, this is listed in the journal as well.

Student Notebook
This of course leads to a performance decrease, but yields one important benefit: When
the system crashes, you don't have to do an fsck of the whole disk to look for
inconsistencies, but just need to look at the journal and retrieve all transactions that
were started but not finished. Only the disk areas that were involved in those
transactions need to be searched.
An fsck on a crashed journaled filesystem will typically only take a few seconds, while a
non-journaled filesystem may easily take several minutes, depending on the size of the
filesystem.
• Extended File Attributes: This allows you to specify additional attributes of a file. An
example is the immutable flag, which prevents anyone from modifying or deleting the
file (even root), as long as this flag is set.
• Labels: These are labels that are attached to the filesystem itself (in the superblock).
This allows you to specify a filesystem label instead of a device name in your /etc/fstab
file. The advantage of this is that if you add or remove any disks and/or partitions, that
your filesystems can still be found, even though they might now be located on a
differently named device.
Apart from this, filesystems also differ in various optimization details. For example:
• Filesystems like ReiserFS and JFS do not use a linear list to hold the contents of a
directory, but use binary or B+ trees for this. These trees are far faster to search and
thus increase performance if you have a large number (1000 or more) files in one
directory. This typically happens on news server, for instance.
• Some filesystems use a variable number of inodes, which are added and deleted when
needed. This avoids the problem of running out of inodes, while you still have data
blocks left.
• Filesystems may also use data blocks more efficiently, by storing multiple, smaller files
in one data block.
• Some filesystems can work efficiently with “sparse files”. Sparse files are files which are
mostly empty. They are the result of programs who open a new file for writing, and then
lseek to a location somewhere in the file to write something there. The area before the
written area is empty and need not be saved on disk - until the program actually starts
writing there. Sparse files are common in databases.

V1.2.2 BKM2MIF
Student Notebook
Uempty
%
! #

:

% S

,%&%&
,,
,
,%%%
34

"$';;'<77
Figure 8-11. Creating a Filesystem LX032.0
Notes:
Once we have decided which block device we are going to use, and the type of filesystem
we want, we are going to create it. This is usually done with some variation on the mkfs
command, such as mke2fs, mkreiserfs or mkjfs.
Typical options include the blocksize to use, and the bytes-per-inode number. This last
number determines the number of inodes to create on the filesystem, and should reflect the
average size of the files on your filesystem, rounded down to the nearest 2n kilobytes
(1024, 2048, 4096, ... bytes).1
1
If you round up rather than down, then you will run out of inodes before you run out of data blocks. That's harder to sell to your users.

Student Notebook
%
2

#

'
+
?

?

?

%
)
5 1#3#"!&#) # !

Figure 8-12. Mounting a Filesystem LX032.0
Notes:
Mounting a filesystem is done with the mount command. The syntax is:
mount [-t <type>] [-o <options>] <device name> <mount point>
For instance: mount -t iso9660 -o ro /dev/cdrom /mnt/cdrom to mount the
cd-rom device /dev/cdrom, which contains an iso9660 filesystem on the mount point
/mnt/cdrom, read-only.
To show all mounted filesystems, use the mount command without arguments:
[root@sys1 /root]# mount
/dev/hda2 on / type ext2 (rw)
/dev/hda6 on /mountpoint type ext2 (rw)
/dev/cdrom on /mnt/cdrom type iso9660 (ro)
none on /proc type proc (rw)
[root@sys1 /root]# _

V1.2.2 BKM2MIF
Student Notebook
Uempty
% " "
AA
#3#"!%#' 1!

%1
#3#"!# 1!
%%
#3#)#) #)&&/ !

//
#3#/#) #) !

//
#3#"!&#) # ! 1!
//
;
( 1 )!'>
.,B#' #' 1!

%1
.,B## 1!
%%
#3#)#) #)&&/ !

//
#3#/#) #) !

//
#3#"!&#) # ! 1!
//
Figure 8-13. Mounting Filesystems at System Startup LX032.0
Notes:
If filesystems need to be mounted automatically at system restart, or if you need to create
shortcuts for fast mounting of common filesystems, add them to /etc/fstab. This file contains
lines for each filesystem to be mounted. Every line consists of six fields:
• The block device which contains the filesystem.
Recent kernels also allow a "label" to be specified here, instead of the device. This is the
label that is stored in the ext2 superblock. The kernel searches all ext2 filesystems for
the filesystem holding this label and mount the first filesystem where the label matches.
This is very useful if you make changes to your partition tables or the order of your disks
(in particular, SCSI disks).
Labels are currently only supported on ext2 filesystems.
• The mountpoint at which the filesystem needs to be mounted.
• The type of the filesystem. Recent kernels also allow the "auto" type, which indicates
that the kernel itself should try to figure out the filesystem type. This is useful for
removable media, in particular floppy disks.

Student Notebook
• The options.
• A dump indicator (see man fstab).
• A sequence indicator for fsck (see man fstab).

V1.2.2 BKM2MIF
Student Notebook
Uempty

1

/

2
#
#
$
#$,

?

3 4

?

:AA

Figure 8-14. Mount Options LX032.0
Notes:
There are various options you can specify when mounting a filesystem. These options
change the way the filesystem behaves while accessing it.
Options can be specified both when mounting a filesystem manually, by using the -o flag,
and can be specified in the /etc/fstab file, in the fourth column. In both cases it is important
that options should be separated by commas and not by spaces.
Some important options include:
noauto - Do not automatically mount the filesystem at startup. If this is not specified, the
filesystems will automatically be mounted at system startup, or when issuing the mount
-a command.
user - Allow ordinary users to mount this filesystem. Handy for floppy and CD-ROM
drives. Only the user that mounted the filesystem can unmount it.
users - Same as user, but every user can unmount the filesystem.
owner - Same as user, but with the restriction that the user that wants to mount the
filesystem has to be the owner of the device.

Student Notebook
ro - Mount the filesystem read-only

nodev - Do not allow usage of block and character special devices on the filesystem.
noexec - Do not allow execution of programs on the filesystem.
nosuid - Do not allow suid and sgid bits to take effect. nodev, noexec and nosuid are
mainly used for security reasons.
For more options see man fstab and man mount.

V1.2.2 BKM2MIF
Student Notebook
Uempty
' %
,P%

?

4
#
2
#

?
A
)
#3#)
A
)
#) #)
Figure 8-15. Unmounting Filesystems LX032.0
Notes:
Unmounting a filesystem is done with the umount command (note: not unmount). You
either have to supply the device name or the mount point, and umount will figure out the
rest.
If filesystems are defined in /etc/fstab, you can unmount them all with one command:
umount -a
Or unmount all filesystems of a given type:
umount -t msdos -a

Student Notebook
%
!%

" %

/

/M
E
%
3..=
! %
? ,

Figure 8-16. Checking a Filesystem LX032.0
Notes:
It is of the utmost importance that the internal structure of a filesystem is at a consistent
state at all times. The Linux kernel works really hard at trying to achieve this. On the other
hand, for performance reasons the filesystem is not updated synchronously with all user
program writes. This is called "write caching" and means that a write action by a user is not
necessarily automatically done on disk. In fact, it may take up to 30 seconds for this to be
done.
When in the meantime the system crashes, for instance because of a power failure, the
filesystem is left in an unstable state and needs to be repaired before it can be used. This is
done by running the fsck program, usually from rc.sysinit. fsck detects the type of
filesystem and runs the specific check program accordingly.

V1.2.2 BKM2MIF
Student Notebook
Uempty Although the implementation details may change, the general behavior of all these fsck
programs is always the same:
• When the fsck program detects that the filesystem was unmounted cleanly, then no
further checks are performed.2
• If the filesystem was not clean, the consistency will be checked. On a non-journaled
filesystem this basically means that the whole filesystem needs to be scanned, while a
journaled filesystem only needs to scan the filesystem areas which are listed as possibly
dirty here.
• If minor errors are detected, then these are usually corrected automatically.
• If major errors are detected, then the system drops you into a shell and you need to fix
these errors manually. This is typically done with the fsck -y command.
Filesystem checks can also be started by hand. This can only be done on filesystems that
are not mounted at all, or are mounted read-only.
2
Cleanly unmounted means that the filesystem was properly unmounted. This allows the kernel first to bring the filesystem in a
consistent state, where all cached write actions are actually written out. As the last action, the kernel writes the "clean" bit to the
superblock.

Student Notebook
!:.!B"

4<M 47

*>M *&' (8/5+

47
4< : 3
# 47,P4< : 3
247A4<
: 47
47
474

' +
: 47
4: & 47
Figure 8-17. ext2/ext3 Specific Information LX032.0
Notes:
The ext3 filesystem standard adds journaling capability to the ext2 filesystem standard.
This is implemented using a special, hidden ".journal" file. The file size of this file is
arbitrary, but 10 MB is recommended.
Because of this implementation method, the filesystem is fully compatible with ext2. It is
therefore really easy to upgrade to ext3.
When creating an ext3 filesystem, use mke2fs -j. When upgrading an existing ext2
filesystem, run the tune2fs -j command.
Downgrading ext3 to ext2 is easy too, since any (cleanly unmounted) ext3 filesystem can
be mounted as ext2.
Some tools that may be useful on an ext2/ext3 filesystem are:
• tune2fs: Tune an ext2 filesystem. This allows you to alter the number of inodes on your
filesystem, for instance.
• debugfs: This allows you to debug an ext2 filesystem. It allows you to retrieve all
information from superblocks, directories and inodes, for instance.

V1.2.2 BKM2MIF
Student Notebook
Uempty • chattr: Change attributes of files on an ext2 filesystem.

Files on an ext2 filesystem can have a number of additional attributes, which can be
useful in some situations. Note that not all attributes are currently implemented by the
Linux kernel.
• e2label: Change the filesystem label in the superblock. This label can be used in the
first column of your /etc/fstab file.
• resize2fs: Resize an ext2 filesystem. The filesystem needs to be unmounted first,
before it can be resized.

Student Notebook
%""

4 $

$ <7/5M

$
$

34 (888S

2
$
4O &$
34
$

Figure 8-18. ReiserFS Specific Information LX032.0
Notes:
ReiserFS is a filesystem that was designed specifically for Linux by Hans Reiser. Two
features stand out, compared to ext2:
ReiserFS uses a 32 MB journal as part of the filesystem. This allows journaling of all
filesystem transactions. The fixed size of 32 MB however makes ReiserFS less suitable for
small filesystems.
ReiserFS uses balanced trees instead of linear lists for indexing directories. This makes it
useful for filesystems that hold a large number (1000+) files in one single directory.
Some useful commands for ReiserFS are:
• debugreiserfs: Debug a ReiserFS filesystem.
• resize_reiserfs: Resize a ReiserFS filesystem.
Extending a ReiserFS filesystem can be done without unmounting it, but if you want to
reduce it in size, you need to unmount it first.

V1.2.2 BKM2MIF
Student Notebook
Uempty
N%""

T "5/"FA? A7

25S 4

*
* #
,

!
2
! 4 T
!
T

!T
Figure 8-19. JFS Specific Information LX032.0
Notes:
JFS is the Journaling Filesystem from IBM's AIX and OS/2, which was ported to Linux and
made available under the GPL. Like ReiserFS, it decided not to use linear lists for
directories, but uses B+trees. It also supports "sparse" files, which are files which are
mostly empty. The empty parts of that file will not occupy a disk block until actual data is
written to them.
JFS will also support ACLs in the near future.
Some useful JFS commands are:
• extendfs: Extend a JFS. For this, the filesystem does not need to be unmounted.
Reducing a JFS is not possible.
• xpeek: This allows you to debug a JFS.

Student Notebook
<
N A

,
5 % A

.

24 ,P
24 ,P
D

4

Figure 8-20. Quota Concepts LX032.0
Notes:
Quota are used to limit the amount of data a user can store on a specific filesystem. A user
can have different quota on different filesystems. Quota are usually based on the amount of
disk blocks a user has in use, although you can also put limits on the number of inodes. In
addition to that, you can also create group quota, which limit the number of blocks/inodes a
group can use.
A user quota is usually made up of two numbers: the so-called "Soft limit" and the "Hard
limit". When a user (or group) exceeds the soft limit, he will receive warnings that he has
exceeded the quota limit, but the operation will succeed. When a user tries to exceed the
hard limit, the operation will fail.
As soon as the user exceeds the soft limit, the grace period will start. When that period is
over, the user will get errors instead of warnings when he tries to write files. So, by setting
the soft limit and the grace limit to a reasonable value, users are able to exceed their soft
limit for a short period of time, usually just enough to request a quota upgrade...

V1.2.2 BKM2MIF
Student Notebook
Uempty
<
!
N

%
-
"

,
# .
I I

N%

/
II
!
AA
N%
I
4 AA>A>
3
Figure 8-21. Quota Implementation on Linux LX032.0
Notes:
Quota support in Linux is compiled into the kernel, so you don't need to run extra daemons.
What you do need to do is indicate that a certain filesystem uses quota when that
filesystem mounts. This is done with two mount options: usrquota and grpquota. After
mounting, you need to turn quota on with the quotaon command. In addition to that, you
also need to specify the quota themselves. This is done in the files aquota.users and
aquota.groups3 in the root of the filesystem.
3
Earlier implementations used the quota.user and quota.groups file. To convert the old format in the new format, use convertquota.

Student Notebook
- <
/AA
#3#"!1# 1!
%%
; ".C .
C
#3#"'#) #)&&/ !
//
#3#"!<!!!
//
#3#/#) #) !
//
#!
//
#3# 3 (B)B&1///
$

>
!
>C
.
>C
Figure 8-22. Enabling Quota LX032.0
Notes:
So how do we go about enabling quota? The first step is to change the /etc/fstab file to
indicate that a certain filesystem uses quota. Obviously we will want to enable quota every
time the system boots, that's why we specify it here.
The next step is remounting the partitions. This ensures that all options are re-read from
the /etc/fstab file.
Now that quota are enabled on this filesystem, we need to calculate the actual usage, and
store this in the aquota.users and aquota.groups file. This is done with the quotacheck
command.
Finally, we have to turn the quota on with the quotaon command. Quota checking is now
fully functional.

V1.2.2 BKM2MIF
Student Notebook
Uempty
<
I

U3"?$

2.I36 7
C
!

%
#3#"!8'0
%/*//) ; B1////"!B1///>

8/*) ; B/"!B/>
D
.I36 7
D
I3
!
.I3!=3!:!B!C
Figure 8-23. Configuring Quota LX032.0
Notes:
After quota checking is turned on, we can specify the quota per user or group. This is done
with the edquota command.
edquota is a somewhat strange command. It reads the quota.users and quota.groups file
(which are binary files), extracts the relevant information and writes it to a temporary file. It
then starts your favorite editor (identified with the $EDITOR shell variable) and lets you edit
this temporary file. After you finished, it will read the contents of the temporary file and
merge it back into the quota.users and quota.groups file. For this reason, you should be
careful editing the temporary file. If you change the wrong fields, edquota will get confused
and will not do what you expected it to do.
The syntax of edquota is really straightforward. Use the -u option to edit user quota, use
the -g option to edit group quota, and use the -t option to edit the grace period (which is the
same for everyone on the system).
A very useful feature of edquota is the copying of quota information. If you want tux2, tux3
and tux4 all to have the same quota limits as tux1, just run the command edquota -p tux1
-u tux2 tux3 tux4 and you're done.

Student Notebook
<

I
$
.
! 4
# .

%DE
!
20E
!

%;
/%>
)'0E
!) (!E
!) (!
#3#"!8%/*//1////1///8/*//
I
$
.

! 4
AE
!#3#"!8
0) )
F
"!(!
"!(!
557877/8//&71//
=

%GG%//%///%//*!%%1%%1%%

155%*&%///%//88//
Figure 8-24. Quota Information LX032.0
Notes:
If you need to know how you are doing with the quota, there's two commands available:
The quota command shows the quota of one individual user. It can be executed by anyone
on the system, but a regular user can only see his own quota.
The repquota command shows all quota information of all users and groups. It can only be
executed by root.

V1.2.2 BKM2MIF
Student Notebook
Uempty

1) How many inodes and data blocks do you need for a file on an
ext2 filesystem
a. with size 0?
b. with size 1?
c. with size 2000?
d. with size 12289 (12 K+1)?
______________________________________________
What are the two methods of copying a file to a (not yet

2)
mounted) MS_DOS floppy?
______________________________________________
3) What files are important with respect to quotas?

______________________________________________
Notes:
1.
2.
3.

Student Notebook
"
C
C

"
! A A

N
Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty Unit 9. Kernel Compilation and Configuration

This unit will teach you why and how to recompile your kernel, and how
to configure kernel parameters.

• Describe why kernel compilation is sometimes desirable
• Install kernel sources
• Compile the kernel
• Install the kernel
• Configure the kernel

Accountability:
• Exercises
© Copyright IBM Corp. 2001, 2002 Unit 9. Kernel Compilation and Configuration 9-1
Student Notebook

%

" %
!,$?/
"
!
%
" %
! % %
Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty
;+ M
% .

!

%
2
#
34
A#
%
G
Figure 9-2. Why Kernel Compilation LX032.0
Notes:
After installation of a Linux system the kernel from the distribution is installed, so kernel
compilation is usually not necessary. There is actually only one situation in which you will
be forced to recompile your kernel: if you have hardware which is not supported in the
standard distribution kernel.
However, most people choose to recompile the kernel even when support for all their
hardware is already available. The reason for this is that support for devices not present in
your computer wastes valuable kernel memory, and increases boot time. People usually
prefer a "lean and mean" kernel.
Of course, there may be other compelling reasons for a kernel compilation, such as
upgrade to a newer kernel version or when using experimental or development kernels. But
for most people, the main reason for compiling a new kernel is fun!
Student Notebook
"
(> " %

!,$?/
"
7> ! >
<> $ #

:> #

J> !%
;> !
@> ! 5
=> $
Figure 9-3. Compilation Steps LX032.0
Notes:
There are several steps in kernel compilation. First, you have to install the kernel source,
usually in /usr/src/linux-version. These sources can be installed from the distribution disks,
which contain the source to the kernel supplied by the distribution, or from the Internet (for
instance at www.linux.org or www.kernel.org).
The next step is configuring the kernel by answering a lot of questions about whether
support for a certain adapter or device should be compiled in or not.
After this, you need to clean the kernel source tree of any old temporary files, and need to
recreate dependency information.
Then the kernel compilation process can begin. This involves compiling a new kernel image
and compiling and installing the kernel modules.
After compilation, lilo will have to be configured so that it will boot this kernel instead of the
standard /vmlinux kernel. After that, reboot your system and it will boot the new kernel.

V1.2.2 BKM2MIF
Student Notebook
Uempty

+ "

%

%
3 3 3
"
4,YHUVLRQ>>&AA
34! !34
#

Figure 9-4. Installing Kernel Source LX032.0
Notes:
Kernel sources can be obtained from a variety of sources. They are available on the
distribution CD-ROM as kernel-source-version.i386.rpm and can be installed using the Red
Hat Package Manager (rpm): rpm -i kernel-source-version-i386.rpm.
Installation will automatically happen in /usr/src/linux-version.
You can also download the kernel from the Internet, for instance, at www.linux.org or
www.kernel.org. These kernel sources are usually gzipped tarfiles (.tar.gz), and should
initially be placed in /usr/src. Then uncompress and untar them using tar -xzvf
linux-src.version.tar.gz.
In order to be absolutely sure that no configuration options were preserved from the person
who created the rpm or .tar.gz file, run the make mrproper command in the kernel
directory (/usr/src/ linux-version). This will ensure that all configuration information is
deleted.
Student Notebook
+
! %

#
"

!
!
"#
#%
#

? % .
Figure 9-5. Configuring the Kernel LX032.0
Notes:
Before you start the compilation process you will have to determine what support should be
compiled in. For this, you will need to know your hardware, and you will need to know what
function your system will fulfill. For instance, your system can only act as a firewall if firewall
support is compiled into the kernel.
To configure your kernel, run the make config command in the
/usr/src/linux-version-directory. You will be presented a lot of questions1. For most of the
questions, help is available by entering the question mark. If you are unsure, accept the
default.
Recently, two more ways of configuring the kernel configuration parameters were added:
make menuconfig and make xconfig. Both will offer you a menu-based structure to set
the parameters, instead of having to answer all questions sequentially. That is especially
convenient if you made errors while answering.
All configuration options are stored in a single flat file called .config in the directory
/usr/src/linux-version.
1
Kernel version 2.4.18 asks about 1200 questions!

V1.2.2 BKM2MIF
Student Notebook
Uempty If you already have a working .config file, for instance because you already compiled a
previous version of the Linux kernel, you can import this .config file into your new kernel
configuration by running make oldconfig. This will read your old configuration file and
will only ask you the questions that are new with this kernel.
Student Notebook
+
! %

AA AYHUVLRQ %
1 AAA 4A/%
! 3F$13$ "?-
%
/#

/#

2

? " $%' +

Figure 9-6. Kernel Modules LX032.0
Notes:
Certain kernel parts may be configured and compiled as modules. This means that they
are not part of the kernel image, bzImage, but are available on disk as a separate file.
There are several advantages to this scheme:
• The modules do not consume memory until they are needed
• System boot is faster, because there is less loading to do
However, there is also a disadvantage: the loading of a module costs some time. This may
be a burden for often-used hardware.
Modules can only be loaded after the system is fully booted up. Therefore, if you have any
hardware which is already needed in the boot process, compile it into the kernel, and not as
separate modules.
You can also create an "initial root disk", which is a special file (actually, a filesystem in a
file) which contains the necessary modules, typically your SCSI and/or RAID modules. This
file is loaded into memory by Lilo. The kernel then loads the modules off this initial root

V1.2.2 BKM2MIF
Student Notebook
Uempty disk, and then mounts the proper root disk. To create an initial root disk, use the mkinitrd
command.
Modules are stored in /lib/modules/version, where the version number is determined in
/usr/src/linux/Makefile. If you are working with multiple kernel images from the same kernel
version, it is a good idea to use the EXTRAVERSION directive in the Makefile to distinguish
between the different images and module sets.
Student Notebook
+

!
>>

!%

4

!
%
/%J,;8
!% '&" +
AAA 4,YHUVLRQAA<=;A

!

/%7,;8
Figure 9-7. Compiling the Kernel LX032.0
Notes:
After configuration you will want to clean up the installation tree. This means removing all
the old temporary files (*.o, *.a) and kernel images.
After that, re-create the dependency files. This will take a few minutes.
Then it is time to compile the kernel itself. Do this with the make bzImage command.2 The
compilation process will take somewhere between 5 and 60 minutes, depending on the
speed of your processor and the amount of code to compile. It creates the compressed
kernel image (called bzImage) in /usr/src/linux-version/arch/i386/boot.
2
Technically, there are three ways of compiling the kernel image, which differ in the amount of compression applied, and where the
kernel will be loaded:
• make Image does not apply any compression to the kernel image. This means that with the current kernels, the kernel image
becomes far too big to handle. It is not used anymore.
• make zImage applies compression to the kernel image and prepends a decompress program to it. When the kernel is loaded in
memory and executed, the decompress program first decompresses the kernel and loads it below the 1 MB memory limit. It then
starts the kernel proper. This scheme can be used when only a few hardware drivers are compiled into the kernel.
• make bzImage compresses the kernel in nearly the same way as make zImage does. Only the decompress program loads parts of
the kernel above the 1 MB memory limit. This allows for more hardware drivers in the kernel image itself, instead of in modules.
Configuring the kernel so that a zImage can be produced is rather demanding. Most people therefore build a bzImage.

V1.2.2 BKM2MIF
Student Notebook
Uempty If you configured certain kernel parts to be compiled as modules, you will need to compile
them too, by issuing the make modules command.
Note: There is also an option "make zlilo" or "make bzlilo" available. This will automatically
set up lilo for you, after the bzImage is created. Your /etc/lilo.conf file has to be set up for
this, or else this will be a tricky exercise. We therefore will not use this command in this
course.
Student Notebook

+
!
% A
.BGE..4
..4
3
!
>
> A
" .." 3
.. 3
"
O
!" $%
3.. 3
Figure 9-8. Installing the Kernel LX032.0
Notes:
To install the kernel, it needs to be copied to /boot. For convenience, rename the kernel
image so that it includes the full version number (including the EXTRAVERSION). This will
save a lot of trouble later, if you compile more kernels.
It is a good idea also to copy and rename the System.map and .config files. These files are
not strictly needed for the correct operation of the kernel, but are useful as a reference later
in case of problems.
To install the modules, run the make modules_install command. This will automatically
install all modules in /lib/modules/version.
If you need to load modules to access your root filesystem, for instance because your root
filesystem is on a RAID, LVM or SCSI volume, or if your root filesystem is formatted as
ext3, ReiserFS or JFS, then you need an initial root disk. This initrd is created with the
mkinitrd command, and should also be stored in /boot.

V1.2.2 BKM2MIF
Student Notebook
Uempty

3..
%
$
> "
$ %

%$
%$ $ $

%&'
%$ (
$%
%
,
%$ $(97&'6:
$%
%
,
>
Figure 9-9. Configuring Lilo LX032.0
Notes:
After the kernel compilation has finished, you will need to reconfigure the /etc/lilo.conf file
so that it will boot the new kernel. If you are unsure of the quality of the new kernel (for
instance, because it is a development kernel), it is possible to make the choice at boot time.
You can leave the kernel image in /usr/src/linux-version/arch/i386/boot, but most people
choose to copy the kernel image to /boot. We will assume that you copied it there too, and
called it /boot/bzImage. We also assume that you added "-WL" to your EXTRAVERSION in
/usr/src/linux-version/Makefile
Your lilo.conf file will look as follows then:
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
image=/boot/vmlinuz
label=linux
Student Notebook
root=/dev/hda1
read-only
image=/boot/bzImage-2.2.14-5.0-WL
label=develop
root=/dev/hda1
read-only
This will allow you to boot your original kernel by typing linux at the boot:-prompt, and your
development kernel by typing develop.
Now reinstall LILO by issuing the lilo command.

V1.2.2 BKM2MIF
Student Notebook
Uempty
2'
3...

%
>$ $$ "
>$ %
"%'
%'

%-'.'/$

(
:-;*?/
-'.'/
(;*? %?
;*?
:-;*6:/
-'.'/
$(9;*6: %?
;*6:
Figure 9-10. Configuring GRUB LX032.0
Notes:
Because GRUB is able to read its configuration file at boot time, you only need to alter it
now. You don’t need to reinstall GRUB after changing the file.
Student Notebook
"
!,, # 3 #

%
!%%
,2

" A#AA
Figure 9-11. Reboot System LX032.0
Notes:
After the kernel is compiled and LILO is reconfigured to boot the new kernel image, you can
try it out. Reboot your system and boot with the new kernel image. Watch the screen
carefully for any error messages. If needed, you can scroll up with Shift-PgUp. You can
also execute the dmesg command to retrieve the messages. Most messages will also be
written to /var/log/messages, so you can always retrieve them later.
If no errors occur, you can log in and start working.

V1.2.2 BKM2MIF
Student Notebook
Uempty
+ /
! %

"
# A
A

.. . .C.O#

=7.. . .C.O#
#
CO#
3# CO#,=
AA> 3
Figure 9-12. Configuring Kernel at Run Time LX032.0
Notes:
Several kernel parameters can be changed at run time. An example of this is IP forwarding,
which can be turned on and off while the system is running. All these changeable
parameters have a virtual file representation in /proc/sys.
To list the current setting, simply list the file to the screen with the cat command. To change
a setting, simply echo the new setting to the file. And if that is not yet simple enough, the
command sysctl has been created which can do this for you. With this command you can
also list and change the settings. But one thing is very useful: sysctl allows you to store all
setting in a file, usually /etc/sysctl.conf, and to apply all these settings at once by executing
sysctl -p.
Student Notebook

/

#

AA AYHUVLRQA >

/ %
#
0 # 7>8>6-
0 # 7>7>6
" %
/
AAA 4A A >4
Figure 9-13. Loading Modules LX032.0
Notes:
When you have compiled certain parts of the kernel as modules, they will be stored in
/lib/modules/kernel-version, and need to be loaded when they are needed.
Loading modules can be done manually with the insmod command. To see which modules
are loaded, use the lsmod command. To unload modules, use the rmmod command. In
addition to this, there are two more advanced commands available, which actually make
use of these three commands. depmod goes through the available modules in /lib/modules
and finds out the dependencies between the modules. These dependencies are then
stored in /lib/modules/kernel-version/modules.dep, and used when modules are loaded.
modprobe then uses the modules.dep file to load a module and all the modules it is
dependent on. In addition to that, modprobe and depmod also read the file
/etc/conf.modules (or /etc/modules.conf, depending on your distribution), which may
contain module configuration options.
A fairly new command is modinfo. This command displays information about the module.
What information is displayed depends on the options given:
• -a displays the author

V1.2.2 BKM2MIF
Student Notebook
Uempty • -d displays the description

• -p displays all possible parameters
Unfortunately, most authors of Linux kernel modules have not yet included this information
in the module itself, so don't be surprised if modinfo yields less information than you had
hoped for. This is supposed to improve in the future.
Dynamic loading of modules is also possible. For the 2.0 series of kernels, this was done
with kerneld, a user-space daemon which took care of it. With the 2.2 series of kernels and
higher, this is completely integrated in the kernel itself.
Student Notebook
/

AA > AA >
'
+
> "
'$

'C%& %'?''

#

/,??
2

3 9 9 3 4

399 34

Figure 9-14. Configuring Modules at Load Time LX032.0
Notes:
When modules are checked for dependencies with depmod and when they are loaded
with modprobe, the options from /etc/conf.modules or /etc/modules.conf (depending on
your distribution) is being read. There are four things that can be specified here:
• The alias specifies the name of the module that is to be loaded to support a specific
device. In the example above, if someone wants to use the /dev/tr0 device, the kernel
automatically loads the ibmtr module, which contains the kernel code for that device.
• The options line specifies the specific options to be passed to the module when it is
being loaded. This can be very useful if you have two or more identical Token Ring cards
for instance, who only have different IRQ and/or I/O settings. The options line is then
used to distinguish them from each other.
The Module-HOWTO in /usr/doc/HOWTO/mini gives a short summary of the various
options that are available. For specific information about a module you will need to run
modinfo or dig into the source. (Most modules have a list of possible options right at the
start of the source code.)

V1.2.2 BKM2MIF
Student Notebook
Uempty • The pre-install, install and post-install lines allow you to specify scripts that are to be
started when loading a module.
• the pre-remove, remove and post-remove lines alloy you to specify scripts that are to
be started when unloading a module.
Student Notebook

1) Why would you recompile the Kernel?

______________________________________________
2) Where can you obtain the Kernel source?
______________________________________________
3) What are the steps involved in Kernel compilation?
______________________________________________
______________________________________________
______________________________________________
______________________________________________
______________________________________________
______________________________________________
______________________________________________
______________________________________________
Notes:
1.
2.
3.

V1.2.2 BKM2MIF
Student Notebook
Uempty
"
%

" %
!
%
" %
! %
Notes:
Student Notebook

V1.2.2 BKM2MIF
Student Notebook
Uempty Unit 10. Memory Management

This unit will teach you how Linux manages its memory.

• Describe the principles of memory management in Linux
• Create paging space partitions
• Create paging space files

Accountability:
• Exercises
© Copyright IBM Corp. 2001, 2002 Unit 10. Memory Management 10-1
Student Notebook
Objectives
After completing this unit, students should be able to:

Describe the principles of memory management in Linux
Create paging space partitions
Create paging space files
Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty
Linux Memory Management
Total memory available for processes = real memory +

paging space - kernel memory (~1 MB)
First megabyte of real memory is used for kernel program
and kernel data -> not for applications
A bzImage kernel might use more than 1 MB
Rest is used for processes
Pages in real memory will be paged out to disk if
necessary
Unused real memory will be used for disk caching
The maximum amount of usable memory (on 32-bit
architectures) is 4 Gb
Except i686 with "enterprise kernel": 64 GB
Maximum amount on 64-bit architectures is 16 EB
Figure 10-2. Linux Memory Management LX032.0
Notes:
Linux memory management uses a very simple but effective scheme: About one megabyte
of your memory is used for the kernel program and kernel data. This area, on Intel systems,
also holds the memory area for devices (640 KB - 1 MB). That means that roughly the first
megabyte of your system cannot be used for applications.
The rest of your real memory is used for processes. If all processes combined use more
memory than is available, pages will be paged out to disk into paging space.
If there is memory to spare in your system, it will be used for caching data from disk.
On Intel-32 (the 386 up to and including the Pentium), Linux can use a total of 4 Gb of real
memory. Starting with the Pentium Pro and later models, sometimes written down as i686,
Intel added PAE, which stands for Processor Address Extension. This allows memory
addresses of 36 bits to be used instead of 32 bit, and thus extends the total amount of real
memory on the system to 64 GB. Individual applications however are still limited to 32 bit
addresses and thus cannot allocate more than 4 GB.1
1
Technical issues under Linux currently limit this to 3 GB.
Student Notebook
On 64-bit architectures, the total amount of addressable real memory is 16 Exabyte. That's
more than the total amount of memory that has been produced so far on this planet.

V1.2.2 BKM2MIF
Student Notebook
Uempty
Example: Lightly Loaded System
paging space
unused
used for caching

real memory
used by programs
kernel memory used by kernel
Figure 10-3. Example: Lightly Loaded System LX032.0
Notes:
On a lightly loaded system all processes will fit in real memory. There will be real memory
left, which will be used to cache data on disk so that it can be accessed very fast.
Student Notebook
Example: Heavily Loaded System
unused
paging space
used by programs
used for caching

real memory
used by programs
kernel memory used by kernel
Figure 10-4. Example: Heavily Loaded System LX032.0
Notes:
On a heavily loaded system, less often used processes will be swapped out to disk (paging
space), and only the most used processes will remain in real memory. The remaining real
memory will be used for caching. Linux uses a very efficient and effective, but non-tunable
algorithm to decide whether to give up caching space or to swap out processes if real
memory becomes full. If the computer is used very heavily, Linux might be forced to swap
active processes out to disk. Obviously this is very bad for performance. The solution is to
add more memory.

V1.2.2 BKM2MIF
Student Notebook
Uempty
Creating Paging Space
We need an empty partition/LV/RAID volume

Partition type 82 (Linux swap)
Create paging space in that partition
mkswap -c /dev/hda3
Activate paging space
swapon /dev/hda3
Add to /etc/fstab
Deactivating paging space is done using swapoff
In real time, no reboot necessary
Only if enough memory is available
Paging can also be done to a file (less efficient)
Create a large file and use it as if it were a partition
Figure 10-5. Creating Paging Space LX032.0
Notes:
There are three steps in creating and activating paging space:
First, create an empty partition, LVM logical volume or RAID volume. Then, initialize a
paging space in that partition with the mkswap command. Last, activate the paging space
by using the swapon command. If the paging space needs to be activated at system
startup, add an entry for this paging space to the /etc/fstab file.
The minimum size of the paging space is 40 KB, and the maximum size is 2 GB when using
kernel version 2.2 and up. In addition to that, the maximum number of paging spaces is 8.
See the manual page of mkswap for details.
It is possible to use paging files too.2 This is less efficient than paging space and therefore
should be used only in an emergency. The procedure for that is nearly the same, only you
have to create a large file first, instead of a partition. So, the sequence becomes (for a 50
MB swapfile):
2
In fact, any block device can be used as paging device. Even a floppy disk or RAM disk.
Student Notebook
# dd if=/dev/zero of=/tmp/pagingfile bs=1024k count=50

# mkswap /tmp/pagingfile
# swapon /tmp/pagingfile
Deactivating a paging space is done using the swapoff command. In contrast to most UNIX
versions, this is possible on a running system, as long as the space can be missed. If the
amount of total memory becomes less than the amount needed, Linux will start to kill off
random processes. So be careful with this command.

V1.2.2 BKM2MIF
Student Notebook
Uempty
Useful Commands
top displays memory, CPU and process statistics

continuously
uptime displays system uptime + load
free displays memory statistics
ps displays processes
sync flushes the cache to disk
xosview graphically displays a system overview
xload graphically displays system load
xsysinfo graphically displays system information
Figure 10-6. Useful Commands LX032.0
Notes:
Some useful commands are:
• top, which displays useful statistics about memory usage, CPU usage and processes. It
runs continuously, giving you a very clear picture about what your system is doing. Note,
however, that top costs about 1 to 10% CPU time, depending on the options, refresh
interval and CPU speed. Most of the statistics top will show you can also be shown
individually, using the uptime, free and ps commands, respectively. Despite the CPU
penalty, some system administrators choose to run top continuously throughout the day.
• sync, which flushes all cached data to disk. If you want to be absolutely sure that your
data is written to disk, use the sync command.
• xosview, xload and xsysinfo display roughly the same information as top, but
graphically.
Student Notebook
Checkpoint
1) How much memory is available for applications in general?

______________________________________________
2) What happens with the first megabyte of memory?

______________________________________________
3) What is the difference between a paging partition and a paging

file? Which is more efficient?
______________________________________________
4) What does top do?

______________________________________________
Notes:
1.
2.
3.
4.

V1.2.2 BKM2MIF
Student Notebook
Uempty
Summary
Memory management
Paging space partitions
Paging space files
Useful commands
Notes:
Student Notebook

V1.2.2 BKM2MIF
Student Notebook
Uempty Unit 11. Scheduling

This unit describes how jobs can be scheduled on the system.

• Use crontab files to schedule jobs on a periodic basis
• Use the at command to schedule jobs or series of jobs at some time
in the future.
• Use the batch command to schedule jobs in a queue, to alleviate
immediate system demand.

Accountability:
• Exercises
© Copyright IBM Corp. 2001, 2002 Unit 11. Scheduling 11-1

Student Notebook
Objectives

Use crontab files to schedule jobs on a periodic basis
Use anacron to schedule jobs on a workstation
Use the at command to schedule a job or series of jobs
at some time in the future
Use the batch command to schedule jobs in a queue, to
alleviate immediate system demand
Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty
Scheduling
Automate routine tasks

Run commands at a specific moment in the future
The crond daemon performs the scheduling for the
crontab files
The anacron command performs the execution of
anacron jobs
The atd daemon is responsible for execution of jobs
submitted by the at and batch command
Figure 11-2. Scheduling LX032.0
Notes:
Scheduling is basically about submitting jobs for future execution, once or periodically. A
number of programs and daemons work together to give the user maximum flexibility in this
regard.

Student Notebook
Vixie Cron
Invented by Paul Vixie

For repeating tasks
Jobs are configured by adding them to a crontab file
Syntax:
[minute] [hour] [day-of-month] [month] [day-of-week] [job]
crond wakes up every minute and goes through all files
If a match is found, job is executed
The crontabs of users are stored in
/var/spool/cron/username
The system-wide crontab file is /etc/crontab
The system-wide crontab directory is /etc/cron.d
Figure 11-3. Vixie Cron LX032.0
Notes:
Cron was originally invented by Paul Vixie. That's why it is usually called Vixie Cron. It is
used for repeating tasks, for instance tasks that need to be run every day, week, month or
year.
To configure these tasks, or jobs as they are commonly called, you need to add them to a
crontab file, using the syntax described above. When the crond daemon is started or
restarted, it reads all crontab files and stores them in memory. crond then wakes up every
minute and searches through the list of crontab entries for all entries that are to be
executed, and executes them. It then goes to sleep for another minute.
There are a number of places where crontab files are stored:
• User crontab files are stored in /var/spool/cron/username.
• The system crontab file is /etc/crontab.
• All files in /etc/cron.d are also considered crontab files and are read by crond.

V1.2.2 BKM2MIF
Student Notebook
Uempty
User Crontab Example
0 8 * * * Once_a_day
0,30 9 * * * Twice_a_day
0,30 8-18 * * * Twenty_Two_times_a_day
*/5 * * * * Every_five_minutes
12 13 1 * * Once_a_month
49 23 16 9 * Once_a_year
0 15 * * 1 Every_monday
32 14 1 1 1 ???
Figure 11-4. User Crontab Example LX032.0
Notes:
The visual above shows an example of a user crontab file. You can see that it has six
columns.
Columns 1 through 5 denote the time that the job is going to be executed. In order, the
columns denote the minute, hour, day of the month, month and day of the week that the job
is to be executed. An asterisk works like a wildcard, meaning that every time matches.
The last column is the command that is to be executed at that specific time.
Take a look at the first entry:
0 8 * * * Once_a_day
This means that the entry matches precisely when the minute is zero and the hour is eight.
The other time entries don't matter. This means that the command Once_a_day will be
executed at precisely 8 am, every day.
All other entries work exactly the same, except for the last example. On a first glance the
last example would only be executed on January 1st, if January 1st is a Monday. So, on
average, it would be executed only once in seven years. Obviously, this would be ridiculous

Student Notebook
since the life span of an average server is only three years or so. You would be better off
submitting jobs like this by hand. So the last entry actually means: Every Monday and
January 1st.

V1.2.2 BKM2MIF
Student Notebook
Uempty
crontab Command
A regular user can edit his crontab file, but cannot signal
crond to re-read that file afterwards
crontab command runs SUID root, so can signal crond
Three usage methods:
crontab -l List your crontab file
crontab -r Remove your crontab file
crontab -e Edit your crontab file using $EDITOR
To regulate the use of crond, list the users involved in
one of the following files:
/etc/cron.allow (strongest)
/etc/cron.deny
Figure 11-5. crontab Command LX032.0
Notes:
The crond daemon is responsible for the execution of the jobs stated in the crontab files.
For this to work, it needs to run as root in order to be able to switch to the correct userid.
This leads to a problem however: If a user updates his or her personal crontab file, it needs
to signal the crond daemon that the file has changed. But since the crond daemon is
running as root, a regular user can't signal it.
To solve this problem, the crontab command is added to the system. This command runs
SUID root, so it is able to signal the crond daemon that a file was changed.
There are three ways of invoking the crontab command:
• crontab -l lists your current crontab file.
• crontab -r removes your crontab file and then signals crond that a change has occurred.
• crontab -e edits your current crontab file using your favorite editor (as specified by the
$EDITOR variable). After the editor finishes, the crond daemon is signaled that a change
has occurred.

Student Notebook
Not every user needs to be able to use cron. That's why you are able to regulate its use
through two files: /etc/cron.allow and /etc/cron.deny.
If a user wants to use the cron facility, and none of the two files exist, the usage is allowed.
If the file /etc/cron.allow exists, the username has to be in it in order to be able to use cron.
If the file /etc/cron.allow does not exist, but the file /etc/cron.deny exists, the username
should not be in it in order to be able to use cron.
If both files exist, then only cron.allow is read and everybody not in it is automatically
denied usage of cron. That is why cron.allow is called the strongest.

V1.2.2 BKM2MIF
Student Notebook
Uempty
System Crontab
The system crontab file is /etc/crontab

The system crontab directory is /etc/cron.d
All files in this directory will also be read by cron
Syntax a little different:
Specifies environment variables
Specifies userid to run command as
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly
Figure 11-6. System crontab LX032.0
Notes:
The crontab files in /var/spool/cron are used to run tasks on behalf of users. But there will
also be a number of tasks that need to be run on behalf of the system administrator. For a
variety of reasons which we will not discuss here it is not desirable to put these commands
in /var/spool/cron/root1. That's why an additional crontab file and a cron directory were
created.
The syntax of the /etc/crontab file and of the files in the /etc/cron.d directory is the same as
that of a user crontab file, with only two exceptions:
• The sixth column specifies the user the command has to run as, and the command itself
starts in the seventh column.
• The first few lines of the file specify the environment variables that need to be set before
the command runs.2
1
Actually, quite a few Unix systems still do this.
2
With a user crontab, the environment variables are set using the .bash_profile and .bashrc scripts in the users home directory.

Student Notebook
Anacron
Most crontab jobs typically run at night, when the system

is not in heavy use
But... most workstations are switched off at night!
The solution: Anacron
Runs commands periodically
At night if the system is on
At startup to catch up on any missed jobs
Jobs specified in /etc/anacrontab
Anacron is called
By the system startup scripts
By cron
Job execution information stored in /var/spool/anacron
Figure 11-7. Anacron LX032.0
Notes:
Anacron is a recent addition to Linux. It is created after people started to use Linux as their
personal workstation instead of a server.
Using Linux as a workstation, sometimes even on a laptop, means that, in general, Linux is
switched off at night and thus all default cleanup jobs never run.
Anacron was created to combat this problem. It consists basically of two things:
• The anacron command. This command is called when the system starts and
periodically (every day) by cron. But note: it is not a daemon in the sense that it runs
continually.
• The /etc/anacrontab file. This file specifies the jobs that need to be executed
periodically, and the period in which they need to be executed.
Every time anacron is started, it checks the /etc/anacrontab file to see which jobs need to
be executed, and it checks the /var/spool/anacron directory to see what was the last time
these jobs were executed. If a job has not been executed recently enough, it executes the
job and updates the information in /var/spool/anacron.

V1.2.2 BKM2MIF
Student Notebook
Uempty
/etc/anacrontab
Syntax:
[period] [delay] [identifier] [job]
Period is number of days after which a job should run
Delay is number of minutes to wait before starting a job
Identifier is used to uniquely identify a job
Job can be any shell command
Example:
SHELL=/bin/sh
PATH=/usr/sbin:/usr/bin:/sbin:/bin
1 5 cron.daily run-parts /etc/cron.daily

7 10 cron.weekly run-parts /etc/cron.weekly
30 15 cron.monthly run-parts /etc/cron.monthly
Figure 11-8. /etc/anacrontab LX032.0
Notes:
The /etc/anacrontab file governs the workings of anacron. It specifies four things for each
job:
• The period (in days) after which the job needs to be executed.
• The delay (in minutes) anacron should wait before executing a job. This feature is added
to ensure that not all pending jobs are started simultaneously, immediately when the
system is started.
• A unique identifier which is used in the /var/spool/anacron directory structure to identify
the time a job has run.
• The job itself, usually a shell command.
Additionally, the /etc/anacrontab file also specifies a number of shell variables at the start of
the file, just like the /etc/crontab file.

Student Notebook
at
Run a command once in the future
# at 4am
ps aux
^d
# at -f bshfile 16:00 + 3 days
Figure 11-9. at LX032.0
Notes:
The at command can be used to run a command once in the future. The at command will
make a file (Bourne shell script) in the /var/spool/var directory. This file will be read and
executed by the atd daemon at the specified time.
To enter an at job you must enter the time you want the job to be executed. Some
examples of the at command are:
# at 4am run the at job at the next 4am.
# at 6pm run the at job at the next 6pm.
# at 16 ditto
# at 16:00 ditto
# at 5pm + 4 days run the at job at 5am over 4 days.
# at 4 tomorrow run the at job tomorrow at 4am.

V1.2.2 BKM2MIF
Student Notebook
Uempty
# at -f commandfile 19 run the commands in commandfile at 7pm.
# at 19 < commandfile ditto
The output of the commands run by atd will be mailed to you if you didn't specify output
redirection.

Student Notebook
batch
run a command when the system load is low enough.

Command will be run when average workload is below
0.8
$ batch
echo workload is low enough
<ctrl-d>
Figure 11-10. batch LX032.0
Notes:
When you start a command, then this command will get executed by the system no matter
what the workload on the machine is. This also happens with commands started by the
crond and atd daemons. These jobs will get run no matter how busy the system is. More
commands will also mean that the overall performance of the machine will degrade.
The batch command gives you a means of entering a command which will affect the
performance of the system to a lesser extent. With the batch command you give the
system the chance to decide when a job should be started.

V1.2.2 BKM2MIF
Student Notebook
Uempty
Controlling at jobs
List all jobs

$ at -l
$ atq
Cancel a job
$ at -d job
$ atrm job
Regulate the use of at

/etc/at.allow (strongest)
/etc/at.deny
Figure 11-11. Controlling at Jobs LX032.0
Notes:
Jobs issued by the at and batch commands can be viewed by the atq or at -l
command.
To cancel a job use the at -d or atrm command followed by the job number. Controlling
at batch jobs is done using /etc/at.allow and /etc/at.deny.

Student Notebook
Checkpoint
1) What command can be used to look at your crontab jobs?

______________________________________________
2) What tool would you use to run a daily cleanup job on your
workstation?
a. cron
b. anacron
c. at
3) How do you regulate the use of the crond and atd daemon?
______________________________________________
Notes:
1.
2.
3.

V1.2.2 BKM2MIF
Student Notebook
Uempty
Summary
Scheduling is used to execute tasks in the future

cron and anacron jobs are executed repetitively
at and batch jobs are run once
cron jobs are run by the crond daemon

anacron jobs are run by the anacron program, which is
called when the system starts up and, periodically, by
crond
at jobs are initiated by the atd daemon
batch jobs are executed by the atd daemon
Notes:

Student Notebook

V1.2.2 BKM2MIF
Student Notebook
Uempty Unit 12. Backup and Restore

This unit describes how a system can be backed up and restored.

• Identify reasons for performing backups
• Discuss backup implementation issues
- Backup program to be used
- Media to be used
- Frequency of the backup
- Type of backup
• List the different backup methods supported

Accountability:
• Exercises
© Copyright IBM Corp. 2001, 2002 Unit 12. Backup and Restore 12-1
Student Notebook
Objectives

Identify reasons for performing backups
Discuss backup implementation issues
Backup program to be used
Media to be used
Frequency of the backup
Type of backup
List the different backup methods supported
Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty
Why Back Up?
Data is very important

Expensive or impossible to recreate
Disaster recovery
Hardware failure
Software failure
Damage due to installation or repair
Accidental deletion
Malicious users or break-ins
Long-term archive
System administration
Transfer of data between systems
Reorganizing file systems
Defragmentation
Checkpoint before and after an upgrade
Figure 12-2. Why Back Up? LX032.0
Notes:
The data on a computer is usually far more important and expensive to replace than the
machine itself, if it can be replaced or recreated at all. It is therefore important to ensure
that this data cannot get lost.
There are a number of reasons which can cause data loss:
• Hardware failure
• Software failure
• Damage due to installation or repair
• Accidental deletion by a user or by the system administrator
• Malicious users, malicious system administrators or malicious outsiders who broke into
your system.
To guard against these reasons, backups are necessary, but there may also be other
reasons to perform backups.
Student Notebook
Devising a Backup Strategy
Devise backup scheme

full, system, data
incremental
Select backup tool
Select backup media
Consider off-site storage
Document backup procedure
Figure 12-3. Devising a Backup Strategy LX032.0
Notes:
Before inserting tapes and/or floppies in the computer, it is a good idea to sit down and
think through the whole backup strategy. A good backup strategy basically has three
qualities:
• The backup procedure is simple to perform, even for untrained personnel, and has
minimum impact on system availability.
• The backup procedure allows for access to data, even in the worst-case scenario.
• The restore procedure can be performed by just about anyone who has knowledge
about Linux in general.
In order to obtain a backup strategy which fulfills these three qualities, there is a number of
decisions to be made. These decisions will be covered in the next visuals.

V1.2.2 BKM2MIF
Student Notebook
Uempty
Backup Schemes
Full backup
Preserves the whole system
System backup
Preserves system directories and files
Must include backup/restore tools
Usually on bootable media (floppy, CD-Writable)
Data backup
Preserves user data
Incremental backup
Only backup files that changed
Very fast, but takes more time to restore
Must be used carefully
Needs more media
Figure 12-4. Backup Scheme LX032.0
Notes:
It is not always necessary to back up everything that is stored on the hard disk of a
computer. That's why there are a number of different backup types possible.
The first backup type is the full backup. As the name implies, this backup contains
everything stored on disk, with the possible exception of /tmp. When this backup is
restored, the system can continue working where it left of. The disadvantage is that a
system backup takes a long time to perform.
A system backup only backs up the operating system itself, and any application programs
that were installed. This is useful when doing system upgrades.
A data backup only backs up the user data.
An incremental backup only backs up files that have changed since the last (incremental,
full or data) backup. Before restoring an incremental backup, you will always need to
restore the other backup too.
Student Notebook
Sample Backup Scheme
Full Backup
Every month on a new tape;
tape is saved forever
System Backup After system maintenance
Data Backup Every weekend
Incremental Backup Every monday evening
Incremental Backup Every tuesday evening
Incremental Backup Every wednesday evening
Incremental Backup Every thursday evening
Incremental Backup Every friday evening
Figure 12-5. Sample Backup Scheme LX032.0
Notes:
This visual shows a sample backup scheme. A number of different backups are made:
• Every month, a full backup of the whole system is made on a fresh tape. This tape is
then stored, for instance in a tape vault, and will remain there forever. Duplicates of this
tape might be stored off-site. The reason for storing tapes forever is twofold:
- All countries have laws that specify that certain data should be kept available for a
number of years (up to 50 years). By keeping the tapes available, you are fulfilling this
legal obligation.
- Certain events or activities only occur once a year or less. It is very likely that people
will delete files as part of a cleanup operation and discover after a year or so that they
still need that one special script/file/macro that was used last year too. If you still have
it on tape, you certainly made their day.
• After system maintenance, a system backup is made. If these are kept for at least a
month or so, you can always trace back which file has changed at which moment in time,

V1.2.2 BKM2MIF
Student Notebook
Uempty and therefore figure out why the system's behavior has changed. Plus, it allows you to
do a downgrade rather easily.
• Every weekend, a data backup is made. This backs up all the user data.
• Every weekday evening, an incremental backup is made. This backs up the user files
that have changed since the last data or incremental backup.
Obviously, you are free to implement your own scheme.
Student Notebook
Backup Devices
Tape drive
Large capacity
Use new tapes regularly!
CD-Recordable or CD-RW
Cheap but relatively slow
(Removable) Hard disk
Fast but expensive
Diskette drive
Always available but cumbersome for large backups
Zip, Jaz drive
Large capacity but not really standard
Network
Useful in large installations; usually requires
commercial software (for instance ADSM)
Figure 12-6. Backup Devices LX032.0
Notes:
Various devices and media can be used to perform backups.
Tape drives are excellent devices for performing backups. They are comparatively fast,
cheap and have a large capacity. There is one disadvantage though: reading from and
writing to tape means that the tape itself has to glide along the read/write head at high
speed. The friction caused by this movement wears the tape out pretty quickly, and it is
therefore important to use new tapes regularly.
CD-Recordables and CD-ReadWrites are a fairly new way of backing up. They are cheap
and have a large capacity. The disadvantage is that they are pretty slow, and that it is
currently hard to predict how long the data on the CD will actually be readable. A few years
is not a problem, but there have not been tests with storing data for more than a dozen
years.
Hard Disks are very useful to do backups on. They are fast but relatively expensive. And
unless you have a removable hard disk, they cannot be taken away from the computer,
which doesn't help you if your computer burns down or is stolen.

V1.2.2 BKM2MIF
Student Notebook
Uempty A diskette drive is also a good alternative if you don't have a lot to back up. It is slow and
you might need a lot of media, but a diskette can be read just about anywhere, since it is
the only removable media which is available by default in any computer.
A Zip drive or Jaz drive may also be a good alternative to floppy disks. They are relatively
fast and have a large capacity. The biggest disadvantage is that these are not standard
media types. If your computer burns down, or your Zip drive breaks down, you will have a
hard time reading your precious backups.
Backing up over the network is a good idea in large installations. In such environments
however, the backup strategy usually becomes complex enough to warrant the usage of
commercial backup solutions such as ADSM.
Student Notebook
Default Backup Tools
tar
Backs up individual files
Widely available
Excellent for transferring data between platforms
cpio
Backs up individual files
Widely available
Difficulties with many symbolic links
dump
Backs up whole filesystems
Can handle incremental backups (9 levels)
Figure 12-7. Default Backup Tools LX032.0
Notes:
Linux by default only has three backup commands available, although various distributions
sometimes do offer additional commands.
tar and cpio roughly do the same thing: they back up individual files into a tar or cpio file
which can for instance be written to a block device such as a tape. The choice between tar
and cpio is a matter of preference.
dump is a tool which can back up complete filesystems. It can handle special files (such as
in /dev) and symbolic links, and it can make incremental backups up to 9 levels.

V1.2.2 BKM2MIF
Student Notebook
Uempty
tar Command
Traditional UNIX tape archive command

Backup with tar:
tar cvf home.tar /home
Restore with tar:
tar xvf home.tar
List contents of a tar backup:
tar tvf home.tar
To add compression: use z option
tar zcvf home.tar.gz /home
To include leading "/": use P option
tar cPvf etc.tar /etc
To make a multivolume backup: use M option
tar cvfM /dev/fd0 1440 /home
Figure 12-8. tar Command LX032.0
Notes:
The tar (tape archiver) utility has been used with UNIX systems for many years. You could
say that it is an old command. Unfortunately, it is not user friendly and can be quite difficult
at times, especially when you are unfamiliar with the syntax to make tar do useful things.
With tar you can combine many files into one large file, which makes it easier to move the
collection to another disk or make a backup to tape.
The general syntax is:
tar <options> [files]
The available options can be lengthy. Files can be specified with or without wildcards. An
example to create a tar archive is:
tar cvf archive11.tar /home/johan
Which combines all the files in /home/johan into a tar archive named archive11.tar.
Student Notebook
Options:
c create an archive file
v verbose it, displays messages
f use the filename archive11.tar as the output file
z compress the tar image
P don't strip the leading "/" from the filename. Note: You need to supply this option
both when creating and reading from the tar file.
M make a multivolume archive. The number specifies the amount of 1k blocks that
fit on each archive.

V1.2.2 BKM2MIF
Student Notebook
Uempty
cpio Command
Common UNIX backup command

Backup with cpio:
cpio -ov <files> > <device>
find /home cpio -ov > /dev/fd0
Restore with cpio:
cpio -iv[-dum] [files] < <device>
cpio -ivdum "/home/j*" < /dev/fd0
List contents of a cpio backup:
cpio -itv < <device>
cpio -itv < /dev/fd0
Figure 12-9. cpio Command LX032.0
Notes:
cpio stands for CoPy Input Output
This command is similar to tar. However it can use archive files in a number of different
formats, including the tar format. Normally cpio reads the names of the files to copy into the
archive from standard input (stdin) and produces the archive as standard output (stdout).
When extracting files from an archive, cpio reads the archive as standard input.
As with tar, some options can be given in both a short, single-letter form or a more
descriptive word form. On the other hand, the syntax of the two forms differs when the
option must be followed by additional information.
In the short form, you must use a space between the option and the additional information.
With the word form you must separate the two options with an equal sign and NO space. It
should be used with care, as it will not preserve, unless instructed to do so, the ownership
and permissions of files.
Student Notebook
In fact, cpio can even lose the directory structure on the restore side. When using cpio to
copy files into a directory, you must give the name of the target directory as an argument to
cpio.
cpio is a raw I/O copier. It is very useful for moving information between systems.

V1.2.2 BKM2MIF
Student Notebook
Uempty
dump Command
To backup a complete filesystem

Can handle symbolic links and special device files
Can handle incremental backups up to 9 levels
Information is stored in /etc/dumpdates
To make a full backup of the /home filesystem
dump -0 -a -u -f /dev/fd0 /home
To make an incremental backup of the /home filesystem:
dump -5 -a -u -f /dev/fd0 /home
To restore a dumped filesystem:
cd /home
restore -r -f /dev/fd0
Figure 12-10. dump Command LX032.0
Notes:
dump is a backup tool which can backup whole filesystems. It correctly handles symbolic
links and special device files, and it can handle incremental backups up to 9 levels.
Information about these incremental backups is stored in the file /etc/dumpdates.
Restoring a backup made by dump is done with the restore command.
Student Notebook
Other Backup Tools
taper: menu driven tool for backing up to tape

BRU2000: http://www.bru.com
Lone-Tar: http://www.cactus.com
PerfectBACKUP+: http://www.merlinsoftech.com
Backup/9000: http://www.facer.com.au
AMANDA: http://sourceforge.net/projects/amanda/
IBM/Tivoli Storage Manager (TSM):
http://www.tivoli.com/products/linux
Figure 12-11. Other Backup Commands LX032.0
Notes:
There are a number of other programs available for Linux that can help you to back up and
restore files. Some of these are open source projects or are otherwise free to use, and
others are commercial products. Their features range from a simple menu-interface to tar
and cpio to advanced, network based backup solutions which can support major
enterprises in their data storage needs.

V1.2.2 BKM2MIF
Student Notebook
Uempty
Document Backup Procedure
Ensure anyone (not just you) can perform a restore

You may be far away when disaster strikes
Always allow for the worst-case scenario
Useful to have a hardcopy list of all files on media held
along with the media
Keep hardcopies of all scripts that were used
Keep install images and boot media of operating system
along with backups
Label media with the command used to create it, also the
blocksize
Figure 12-12. Document Backup Procedure LX032.0
Notes:
Why would you document your backup procedure? Well, for one simple reason: you will
probably not be there when the need for a restore arises. According to Murphy, you will
probably be on a well-deserved vacation in some far corner of the earth when disaster
strikes. That's why you've got documentation. So others can perform your job, if necessary.
When writing the documentation, always allow for the worst-case scenario. Even allow for
the loss of documentation itself - so make hardcopy backup copies of the backup
documentation and store them with the backups themselves. Keep hardcopy lists of files
that are on the backup media, and keep hardcopy printouts of the scripts and commands
that were used to create the backups. Remember: if your computer burns down, you've got
no means to read softcopy materials on how to restore data until you actually restored it...
Furthermore, keep the installation images, boot media and everything you need to install a
pristine system with the restore tools on it. Store these next to your backups. It is a great
idea to use dump to back up your system, but if you don't have the means of installing a
system with the restore command on it, your backups are of no use.
Student Notebook
And last, it is always a good idea to write the commands which were used to create the
backup on the backup media itself. Even if the documentation is lost, a good system
administrator can usually figure out how to restore a backup when he sees the command
used to make it.

V1.2.2 BKM2MIF
Student Notebook
Uempty
Additional Backup Considerations
Use new media regularly

Keep monthly full backups indefinitely
Verify old backups regularly
Test recovery procedure before you have to
Consider off-site storage of backups
Check filesystems before backing up
Don't backup open files unless your backup tool can
handle it (esp. databases!)
Don't throw away old backup hardware before converting
your backups
11 common backup mistakes (and how to avoid them):
http://www.bru.com/mistakes.html
Figure 12-13. Additional Backup Considerations LX032.0
Notes:
These are just some additional backup considerations which may seem obvious now, but
which are forgotten a lot of time.
Do take a look at http://www.bru.com/mistakes.html. It lists the 11 most made backup
mistakes, and how to avoid them.
Student Notebook
Checkpoint
1) What is the difference between A and B?

A: find /home/francis -print I cpio -ov >/dev/rmt0
B: find . -print I cpio -ov >/dev/rmt0
______________________________________________
2) Which one of the following commands supports multilevel
incremental backups?
a. tar
b. dump
c. cpio
3) T/F An incremental backup will always back up the operating

system files.
4) T/F It is not necessary to use the dash (-) with the option in the tar
command.
5) When did you last back up your files?
______________________________________________
Notes:
1.
2.
3.
4.
5.

V1.2.2 BKM2MIF
Student Notebook
Uempty
Unit Summary
In order to perform successful backups, consider the
Frequency
Media to be used
Backup schedule
Backup procedure
Restore procedure
Type of backup
Backups can be initiated on a single file or on an entire
file system
There are many backup tools which can be used
Notes:
Student Notebook

V1.2.2 BKM2MIF
Student Notebook
Uempty Unit 13. User Administration

This unit describes how users and groups can be managed on the
system.

• Add, change and delete users
• Add, change and delete groups
• Manage user passwords
• Communicate with the user community

Accountability:
• Lab exercises
© Copyright IBM Corp. 2001, 2002 Unit 13. User Administration 13-1
Student Notebook

" %

/

!
Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty
"
2 D

2 . 2 .
2 ." 2 ."

2

"
Figure 13-2. Security Concepts LX032.0
Notes:
The security of a Linux system is based on a user being assigned a unique name, user ID
(UID) and password. When a user logs in, the UID is used to validate all requests for file
access.
When a file is created, the UID associated with the process that created the file is assigned
to the file. Only the owner or root can change the access permissions.
Users that require access to a set of files are placed in groups. A user can belong to
multiple groups. Each group has a unique name and Group ID (GID). Every user will
always be member of at least one group. This is called the primary group. In addition to
that, users may also be members of other groups. These are called secondary groups.
Student Notebook
' )

2

! 4
#

>>>
2

! ' +
?
Figure 13-3. User Hierarchy LX032.0
Notes:
The most important user (from a system administrative point of view) is the root user. The
file permissions do not apply to root so he can read, change and delete any file he wants to.
In fact, root can do just about anything, except for obvious things like writing to read-only
mounted filesystems (CD-ROM), unmount busy filesystems and so on. Furthermore, most
system administration tasks can only be executed by the root user.
Besides the root user, Linux has a number of other users too. These users should not be
used to login but are there for the convenience of some applications and daemons. These
users should not be used to carry out any administration task; use the root user for this.
The last type of user account is the normal user account. The purpose of these accounts is
to give ordinary users the opportunity to login to a Linux system and carry out tasks.

V1.2.2 BKM2MIF
Student Notebook
Uempty
2

#
3#

#

A
D

>

Figure 13-4. Groups LX032.0
Notes:
The creation of groups to organize and differentiate the users of a system or network is part
of system administration. The guidelines for forming groups should be part of the security
policy. Defining groups for large systems can be quite complex and once a system is
operational, it is very hard to change the group structure. Investing time and effort in
devising group definitions before your system arrives is recommended.
There are two groups on the system:
User groups
User groups should be made for people who need to share files on the system, such as
people who work in the same department, or people who work on the same project.
System-defined groups
The system-defined groups are used to control certain subsystems.
There are two different kinds of groups available to users. The first group is the primary
group. The primary group is used by the system when you create a file (and directory).
Every file created is assigned a group and this is the primary group of the user creating the
Student Notebook
file. The group set is the set of groups determining the permissions you have on a given
file or directory. The group set is used by the system when you want to work with a file or
directory.

V1.2.2 BKM2MIF
Student Notebook
Uempty
' /

A
!5(( (
5 "(

!)
A!
!)

A

!)
A)5#")#
!)

A
5
!)
!
A
)5(( (
5 "(

!)
% %
A
)5
!)
A
)5F
!)
Figure 13-5. Command Line User Tools LX032.0
Notes:
Linuxconf is a graphical tool to manage your users. There are also a number of command
line tools to do the same.
These tools are:
adduser or useradd
A tool to add users to your system. After creating the user account, linuxconf will prompt
you for a password for that user. The adduser and useradd command will only create the
user account. You have to set the password manually afterwards.
userdel
Remove users from your system. The -r option also removes the contents of the user's
home directory, and the directory itself.
usermod
Change settings of a user. This command can also be used to lock and unlock a user
account. This is done by putting an exclamation point in front of the password in
/etc/shadow.
Student Notebook
..
% #

AA%

L
#
#
Figure 13-6. /etc/skel LX032.0
Notes:
When a user logs in, the shell will try to read some configuration files from its home
directory. These files can be made manually by the root user or by the user itself but they
can also be copied automatically to the home directory of the user.
The /etc/skel directory is the directory that contains a number of skeleton files. These files
are copied to the home directory of a user when this user account is first created.

V1.2.2 BKM2MIF
Student Notebook
Uempty
2/

A(
!(
!)

A(
(
!)
!
A(
)5 O !)(
!)
Figure 13-7. Command Line Group Tools LX032.0
Notes:
You could also use the command tools to manage your groups.
Student Notebook
#
! H

A!

!%
%
/
AA

A)0!P
!)Q
Figure 13-8. Passwords LX032.0
Notes:
Users can change their passwords by using the passwd command. Root can also use this
command to reset passwords of other users.
As a default passwords are stored in the /etc/passwd file. When you use shadow files, the
password will be stored in the /etc/shadow file.
A useful tool is mkpasswd. This generates a random password and, optionally, assigns this
password to a user.

V1.2.2 BKM2MIF
Student Notebook
Uempty
.. #
P R" !)# QA! # #!
// # #' #'!"
' %%' #'
!) 11!) #'
!)<8!)#3!#!)
8*#3!##
/ #' #' #
"
&/"
#' #' #"

"! */"! #' #' #"!
)!7%1)!#3!##)!
%< #3!##

%/%8
#3!##

! %%/! #
(!)%1%//(!)#
#(!)
("%<</("#
#'#("5! !
%8/4 F#")#
':'#
%//1<<$ 3# #$%%##' #!

%/%/%4
" (
;%>#")#
%#' #'!"

1/1/14
" (
;1>#")#
1#' #'!"
Figure 13-9. /etc/passwd LX032.0
Notes:
Most user information is stored in /etc/passwd. It contains a line for each user, and values
on the line are separated by colons.
From left to right, each line consists of:
• The login name of the user.
• An "x", meaning that the encrypted password is stored in /etc/shadow.
• The User ID (UID) of the user.
• The Primary Group ID (GID) of the user.
• The full name of the user. Some system administrators also choose to include location,
room number, telephone numbers and so forth in this field.
• The home directory of the user.
• The preferred shell of the user.
This file is world readable, meaning that everyone can read (but not write) to this file.
Student Notebook
.. #
P R" # QA! # #"!
D%D&!D/3, %:SF!T= /%/*7*/*5%5%%<8<7888
' U%/*7*/*5%5%
!) U%/*7*/*5%5%
!)U%/*7*/*5%5%
U%/*7*/*5%5%
U%/*7*/*5%5%
"
U%/*7*/*5%5%
"! U%/*7*/*5%5%
)!U%/*7*/*5%5%
U%/*7*/*5%5%

U%/*7*/*5%5%
! U%/*7*/*5%5%
(!)U%/*7*/*5%5%
("U%/*7*/*5%5%
U%/*7*/*5%5%
'U%/*7*/*5%5%
VV%/*7*/*5%5%

%D%D9?
6C+D-E)*C E.: W6'!#%/*15%5%5%%/*7*%<8<*<&

1D%D( &$D# 2-S4)W@E"<*1$*F*/%/*%5%5%5%5%%<88/7*&
Figure 13-10. /etc/shadow LX032.0
Notes:
The passwords of the users are stored in /etc/shadow. This file contains, from left to right:
• The username
• The MD5 encrypted password of the user. MD5 encryption is a one-way encryption,
meaning that once encrypted, a password can never be decrypted. To test whether an
entered password is correct, the entered password is encrypted too and compared to
the encrypted password in /etc/shadow. MD5 encryption is rather new. Older UNIXes,
and other Linux distributions might still be using the old crypt algorithm. The real
advantage of MD5 is that the allowed password length is increased from 8 to 256
characters.
A "*" means that this user does not have a password. That user account can therefore
not be used to login.
• The day the password was last changed (number of days since Jan 1st, 1970).
• Number of days before the password may be changed again.
• Number of days after which the password has to be changed again.

V1.2.2 BKM2MIF
Student Notebook
Uempty • Number of days the user will be warned of a password expiry.

• Number of days after expiry, after which the account is disabled.
• The day the account was disabled.
• A reserved field.
The /etc/shadow password file should be read/writable by root only. Other users should not
be able to read this file at all.
Student Notebook
..
P R
)# QA! # #(

/
' % ' !)
!) 1 ' !)
< ' !)
!)8 !)!)
===
'

%//
%
%/%

)%/1

1</

1<%

1<1
! 1%
1<<

%/%

1/1
Figure 13-11. /etc/group LX032.0
Notes:
The /etc/group file contains group information. From left to right:
• The group name
• The group password. Group password are ancient UNIX concepts which are no longer
being used. For backwards compatibility this field is kept alive though.
• The Group ID (GID)
• The list of users that have this group as their secondary group.

V1.2.2 BKM2MIF
Student Notebook
Uempty
.. ..
!
P R" !)# QA! # #

?!
!*=<;9!"!!>
- X ! X)
P R" !)# QA
Figure 13-12. /etc/issue and /etc/issue.net LX032.0
Notes:
The /etc/issue and /etc/issue.net files contain the login message shown at login time. The
/etc/issue file is shown by the mingetty process, and /etc/issue.net is shown by the telnet
server when a client logs in over the network.
The /etc/issue and /etc/issue.net files may contain escape sequences: a backslash
followed by a single character. These escape sequences are then replaced with dynamic
information such as the date, the architecture and the kernel version when the file is
displayed. For a list of these escape codes, see man mingetty
Student Notebook
&
AA

>
"{)-. 4..

>
Figure 13-13. Message of the Day LX032.0
Notes:
The message of the day is stored in /etc/motd. Under normal conditions, users will see the
contents of this file on their screen when they login.
Users who login graphically will not see the motd. The .hushlogin file is used to disable the
motd facility. When you create this file in your home directory (it may be an empty file), you
don't see the motd at login times anymore.

V1.2.2 BKM2MIF
Student Notebook
Uempty

1) What file does the bash shell not use?

a. /etc/profile
b. $HOME/.login
c. $HOME/.bash_logout
d. /etc/bashrc
2) Where are the passwords of users stored?

______________________________________________
Notes:
1.
2.
Student Notebook
"
2

2 AA

AA
D
AA

Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty Unit 14. User-Level Security

This unit introduces the concepts of Linux users and groups, and also
the files that contain the user account information.

• Define ways of controlling root access on the system
• Define the use of SUID, SGID and Sticky Bit permission bits
• Identify the data files associated with users
• Describe the concepts of PAM

Accountability:
• Exercises
© Copyright IBM Corp. 2001, 2002 Unit 14. User-Level Security 14-1
Student Notebook

2" D" %5

"

/
Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty
' 3"#
$ ?1

!
% '>>
"-+
#'>> % %+
'>>
+
$4 ? #
" 4

Figure 14-2. User-Level Security Overview LX032.0
Notes:
With user-level security we mean the security issues that surround the users that log in to
your systems. Securing this properly requires two steps:
The first step is authentication. Authentication means: verifying that you indeed are who
you say that you are. In theory, there are several methods of achieving this:
• By showing that you know something, such as a password or PIN code.
• By showing that you have something, like a smart card, ATM card, key or token.
• By showing that you are something, for instance by using biometric data such as finger
prints, retina scans and so forth.
The second step is authorization. Authorization means that we have established that you
are who you say that you are, but need to determine what you're allowed to do on the
system. This is implemented in Linux using file permissions.
Student Notebook
$ 0$1
4

"

3

" #
/

4
Figure 14-3. Pluggable Authentication Module (PAM) LX032.0
Notes:
The Pluggable Authentication Modules (PAM) is a set of modules that allow you to be very
flexible about your authentication mechanisms.
It is implemented as a suite of shared libraries that are used by the different programs that
need authentication services. It was initially developed by Sun Microsystems but later
adapted for Linux.

V1.2.2 BKM2MIF
Student Notebook
Uempty
$ $
#

#
AA

Figure 14-4. Authentication before PAM LX032.0
Notes:
For a system administrator, the situation before PAM was far from ideal. Every application
that ran on a system required its own security and authentication mechanism. Some of
them were based on /etc/passwd, /etc/group and /etc/shadow, like login and ftp (although
ftp also knew the "anonymous" login possibility), and others used their own authentication
mechanisms. A program which was supposed to be very secure might actually employ a
layered approach, maybe incorporating biometric authentication techniques like retina
scans or voice recognition.
All these different authentication mechanisms are a nightmare for system administrators,
because if the administrator wants to add a user, he has to do that in multiple places. Plus,
the system administrator wasn't free to choose his own method. Suppose for instance, that
a university decides to supply all students with a chipcard which is used for the restaurant,
the library and the computer facilities as the authentication device. With a scheme like this,
it is close to impossible to implement that.
Student Notebook
$ #$
#

/
AA
> /
2A
?
Figure 14-5. Authentication with PAM LX032.0
Notes:
With PAM, every application that needs some kind of authentication, needs to be rewritten
to use the PAM authentication mechanisms. But then, the only thing that program has to
do, is ask PAM: "Is this user authorized to use me?". And PAM will tell the program yes or
no.
To authenticate that user, the system administrator can set up different authentication
mechanisms, and specify which program should use which kind of authentication
mechanism.
There is a couple of authentication mechanisms currently available:
• Userid/password checking
• Anonymous login (for example, for anonymous ftp)
• Deny, for services that may not be used
• Secure tty, meaning that logging in is only allowed from a secure terminal

V1.2.2 BKM2MIF
Student Notebook
Uempty But of course, PAM allows the system administrator to add its own mechanisms, like retina
scans, voice recognition, fingerprint readers, chipcard readers, time-driven mechanisms
(only allowed to login during office hours) and so forth.
Which service uses which authentication mechanism is specified in configuration files in
/etc/pam.d. There is one configuration file for each service, and there is a default
configuration file, called other, which is used when a specific configuration file is not
available.
Student Notebook
$ !

P R % QA! # #!)=#(
AY .+5%=/
!
"E
#'#
#!)O
=
!
"E
#'#
#!)O !0=3B )5!
"
!
"E
#'#
#!)O ( =
!
E
#'#
#!)O !0=3B )5!
"
!E
#'#
#!)O !0=3B )5!
"
E
#'#
#!)O !0=3B )5!
"
! #'#
#!)O =
P R % QA! # #!)=# )5!

"
AY .+5%=/
A4"!
5( ! =
AF"! (' " )!
" (
=
!
"E
#'#
#!)O 3=
!
"
#'#
#!)O
=0!
"
0
!
"E
#'#
#!)O =
!
E
#'#
#!)O
=
!E
#'#
#!)O!0'= B< B
!
#'#
#!)O
=
0
O!
" 0)"!
!E
#'#
#!)O =
E
#'#
#!)O) =
E
#'#
#!)O
=
Figure 14-6. PAM configuration files example LX032.0
Notes:
The visual above shows two actual configuration files. Every file you will encounter within
PAM is split up in four sections, which apply to the four phases of the login process:
1. Verify the authentication of the user, usually by checking the password.
2. Manage the account. For instance force a user to change its password if the password
used is expired.
3. Change the password itself. This phase can also be called from the passwd program.
4. Manage the session where the user logged in.
The first file is the configuration file which is used for the login process. From top to bottom,
the lines mean roughly:
• Require that, if root tries to authenticate itself, the tty he logs in from is listed in
/etc/securetty.
• For the rest of the authentication process, go to the filesystem-auth.

V1.2.2 BKM2MIF
Student Notebook
Uempty • When the filesystem-auth passes the authentication phase, also require that a user
cannot log in as long as the file /etc/nologin exists. In this case, print the contents of the
file to the screen.
• For the account management, go to the filesystem-auth.
• For the password management, go to the filesystem-auth.
• For the session management, go to the filesystem-auth, but also execute the
pam_console module. This module makes a console user owner of certain console
devices such as /dev/fd0 and /dev/cdrom.
As you can see, this file defers a lot of work to the system-auth file. A lot of services do that,
and that makes system-auth the central place where you can make important changes.
Here's the breakdown of the system-auth file:
• In the authentication phase, first load a number of environment variables from the file
/etc/security/pam_env.conf.
• Require that the user performs standard UNIX authentication, that is, supplies a valid
password.
• If the above steps fail, deny access.
• After logging in, perform normal UNIX account checks, including for an expired
password.
• If the user wants to change his password, test it before to verify that it is not easy to
crack.
• If the user changes the password, store it the usual UNIX way, in the
username/password database.
• If the password did not pass the steps above, deny the password change.
• When the session is started, apply various limits to the user, such as a maximum
number of processes.
• Apply the usual UNIX session management to the session, such as logging things in the
wtmp and utmp files.
More information on PAM can be found in /usr/share/doc/pam-version This includes a
description of every function of every PAM module.
Student Notebook
$

I 4>$2-"F '
+

I%>!%

I
>3

I > AA 4

I>A

I>
AA

I >A

I%>" /

I >
#/ #
AA
Figure 14-7. Common PAM Modules LX032.0
Notes:
Various modules exist as part of the PAM library, and can be used by applications. And
obviously you can write your own modules, for instance if you actually decide to use
biometric authentication mechanisms.
Some PAM modules require configuration files. Typically, these files are stored in
/etc/security.

V1.2.2 BKM2MIF
Student Notebook
Uempty
$4
& 4

34
#
?
4
2"

' +
34
2"

#
AA

!
$

$

Figure 14-8. Principles of Authorization LX032.0
Notes:
Authorization is generally based on file permissions. These permissions tell you what files
to read and write, what directories to go to, and what programs to execute. File permissions
apply to all users, except root.
It is impossible for users to upgrade their own security level (in other words, become root),
unless the program that is being executed has a special SUID bit set. We will talk about this
later. Some programs that have this bit set, and thus allow you to perform an action which
would otherwise not be allowed are:
• passwd: When you change your password, the file /etc/shadow needs to be updated.
For this, you need root permissions.
• mount: To be able to mount a floppy or CD requires access to the /dev/fd0 and
/dev/cdrom devices. This is usually reserved for root.
• su: This stands for "switch user". It allows you to run a shell as another user. It is most
often used to start a shell as root.
Student Notebook
• sudo: This was invented when people started noticing that sometimes users need to
execute scripts or complicated commands as root, without allowing them to actually
become root. Traditional methods would either mean giving these users the root
password, or set the SUID bit on that particular command. The first is not desirable for
obvious reasons, but the second can be too permissive too: The user would be able to
run the command with any arguments that he would choose.
sudo only allows specific users to run specific commands with specific options as
specific users, and nothing more.
Make sure that you always use absolute paths to programs when creating a sudoers
file, since otherwise users might change their $PATH variable and use sudo to start
arbitrary scripts in their own $HOME/bin directory.

V1.2.2 BKM2MIF
Student Notebook
Uempty
%
>

2 2

2 2

4 2 4 2

2"
#"
D"
#
"
"

% ?

Figure 14-9. File Permissions LX032.0
Notes:
There are a number of permission bits associated with files and directories. These
permissions are:
r (read)
User can read the contents of the file or directory.
File: less file
Directory: ls
w (write)
User can modify the contents of a file or create and delete files in a directory.
File: vi file (and make some adjustments)
Directory: rm file
x (execute)
User can execute the file or enter a directory.
File: file
Directory: cd directory
Student Notebook
SUID (Switch UID)

If the file gets executed, it will run with an effective UID of the owner of the file. This
permission is not supported on shell scripts. This permission has no meaning on
directories.
SGID (Switch GID)
On an executable file it means that when the file runs, the process runs with an effective
GID of the group owner of the file. On a directory it means that any file/directory made
within the directory will have the same group ownership as the directory rather than the
primary group of the user. SUID and SGID programs are hackers' favorites. When a hacker
has entered your system he will usually leave some SUID /SUID programs ("trojan horses")
around. With these programs he is then able to gain root access anytime he is logged on
as a regular user, even without knowing the root password. It is therefore important that the
system administrator knows which SUID and SGID programs are installed on the system.
They can be listed with the following command:
find / -perm +6000 -ls
Sticky Bit
On an executable file (thus, a program) this bit used to mean that the program should not
be removed from memory after it was executed. The next time the program were to be
executed, the program would start significantly quicker. With modern memory management
this usage is no longer implemented. On a directory it means that even if the directory has
global write permissions, users cannot delete a file in that directory unless they either own
the file or the directory.

V1.2.2 BKM2MIF
Student Notebook
Uempty

A")* = 55
A")*= 55
A");*= 55
!
A" Z" !

A"( ! !
A" Z" = ! !
Figure 14-10. Changing Permissions LX032.0
Notes:
File permissions are changed with the chmod command. There are special flags which can
be used to change to the SUID, SGID and sticky bits.
chmod {[ugoa]{+-=}[rwx]|[ug]{+-=}s|[0]{+-=}t} file
The octal method can also be used:
chmod <octal> file
The owner of a file can be changed using the chown command. Only root can execute this
command.
chown user[.group] file ...
The owner or root can change the group ownership of a file with the chgrp command. The
owner can only change the group to another group in his group set.
chgrp group file ...
Student Notebook

, % AA

" # % U?/3A>I

# %
877
887
Figure 14-11. umask LX032.0
Notes:
The umask specifies what permission bits will be set on a new file when it is created. The
umask is an octal number that specifies the which of the permission bits will not be set. On
a file, the execute permissions can never be set automatically.
The root user has a different umask than normal users. For root, the default umask is 022
and for normal users this will be 002.
For example, a umask of 022 specifies that the permissions on a new file will be 644 and
on a new directory will be 755. A umask of 000 would give 666 permissions on a file and
777 on a directory.
To view the current umask value, just run the umask command.
The default umask for all users is specified in the /etc/profile file. For specific users, it could
be set in the $HOME/.bashrc file.

V1.2.2 BKM2MIF
Student Notebook
Uempty
-!? /&
!
>

> E

> E

!

>

>

> '

/ A .
Figure 14-12. Example: Creating a Team Directory LX032.0
Notes:
The visual shows an example of the steps that you need to undertake to create a team
directory: A directory which allows multiple people in the same group to share files.
Student Notebook
$
&
H

$
Figure 14-13. Root Access LX032.0
Notes:
If the root password is known by too many people, no one can be held accountable for
changes in the system. The root password should be limited to the lowest number of users
possible. The fewer people who know the root password the better. However, do not make
the mistake of keeping the root password as your personal secret. Should you be on
vacation and the systems crash, key personnel should be able to gain root access to the
systems. A good method to achieve this is to put the root password in a sealed envelope
and store it in a safe somewhere.
The system administrator should ensure that distinct root passwords are assigned to
different machines. You may allow normal users to have the same passwords on different
machines, but never do this for root.
Attempts to become root through su can be investigated. Successful and unsuccessful
attempts may be logged by the audit system.
Red Hat Linux has remote login (through telnet) for root disabled by default: root is only
able to login on consoles that are listed in /etc/securetty.

V1.2.2 BKM2MIF
Student Notebook
Uempty

D"!)

D
!
A"!)

2 3 # XVHU
Figure 14-14. su LX032.0
Notes:
The su command runs in a subshell with the effective user ID and root privileges (if no
username is specified). You will be asked for root's password before you gain root
permissions. To end the session, type exit or <ctrl-d> and this will return you to the original
shell session and privileges.
For example, su ferry will give you the privileges of Ferry, but you will still be in the
environment of the user issuing su. su - ferry will set up the environment as if you had
logged in as ferry.
Student Notebook

4

AA4

3
/
4
4
%-0/
34

2#QBDF QOB %..?
#Q6FNF 8F %000.000.000
!#QD 9PO!+R%$
.$
C
6FNF 8F %- /$

BDF QOB
%- /D 9PO!+R
Figure 14-15. sudo LX032.0
Notes:
The sudo command, as mentioned, allows users to execute specific commands with the
authentication of another user, on specific hosts. Which combination is possible is
configured in the /etc/sudoers file.
The basic syntax of this file is easy:
user host = [(newuser)] command
Which means that user is allowed to execute command as newuser on host. If no
newuser is specified, it is assumed that the command is executed as root.
What makes this complicated, but also terribly flexible, is that for all four elements, macro
definitions can be added. These macros are typically written in capital letters, and there is a
special ALL macro defined as well. See the visual for an example of this.
The /etc/sudoers file supports a large number of options as well, which govern for instance
whether a user is allowed to add any options to the command or not. For examples of this,
see the sudoers manual page.

V1.2.2 BKM2MIF
Student Notebook
Uempty Because of security and locking issues, only edit this file with the visudo command, not
with a regular editor.
Student Notebook
"
A#AA ,

A#AA ,
A#AA ,
A#AA
,
A#A A
,
Figure 14-16. Security Logs LX032.0
Notes:
/var/log/lastlog
Records the last time a user logged in. This file can be examined with the lastlog
command.
/var/log/messages
This is the general log file. Most applications and daemons will write log information to this
file. The messages file is an ASCII file which can be viewed with tail -f or more.
/var/log/secure
Keeps track of the failed login attempts. Use more /var/log/secure to view the
contents of this file.
/var/log/wtmp
All successful logins are saved in this file. This file can also be examined with the who
command. Another tool for viewing this file is the last command.

V1.2.2 BKM2MIF
Student Notebook
Uempty /var/run/umtp
Logs the users currently logged in the system. The default output of the who command is
the contents of this file.
Student Notebook
'
A C

A" 4
A#AA
A#AA
A

A!

A! (
A !5 (8

4 >2
>
Figure 14-17. Useful Commands LX032.0
Notes:
The graphic shows you the commands you can use to examine the contents of some of the
security logs mentioned on the previous foil.
The tail -f command loops forever trying to read more characters at the end of the file,
on the assumption that the file is growing.

V1.2.2 BKM2MIF
Student Notebook
Uempty

1) What is the purpose of /etc/issue.net?

______________________________________________
2) Which of the following statements are true?

a. A user belongs to only one group
b. The chmod g+s command sets the sticky bit
c. The root user has UID=0 and GID=0
d. The root user is responsible for the permissions on all files
e. The umask for users is 002
Notes:
1.
2.
Student Notebook
"
3# 4
#

>

4

% 2" D" %

2
%
!"" .
Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty Unit 15. Logging

This unit will teach you how to use logging.

• Describe logging concepts
• Configure the syslog daemon
• Use the logger program
• Use the logrotate program

Accountability:
• Exercises
© Copyright IBM Corp. 2001, 2002 Unit 15. Logging 15-1

Student Notebook

!
2

2

Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty

1

2A"2 4%
AA>

%

AA>
% %
Figure 15-2. Logging Concepts LX032.0
Notes:
Various daemons generate information which might be of interest. Since these daemons
don't run as foreground processes, they cannot print that information to the screen.
Because of that, and because you might want to keep this information for later reference,
this logging information is usually stored on disk.
In the early days of UNIX, every program wrote this information to its own logging file. This
worked quite well for the programmer of the daemon, but was the system administrators
nightmare:
• Every log file had its own syntax
• Every daemon had its own way of selecting which items to log
• It was nearly impossible to do other things with the log items, like sending it to another
host or displaying things on the console.
For this reason most daemons (but not all!) nowadays make use of a facility called the
syslog daemon. The concept is very simple:

Student Notebook
Every daemon that wants something to be logged creates the log message. It then tags
this message with a facility (where did it come from) and a priority (how important is the
message). It then sends this item to the syslog daemon, either through UDP/IP or through
a UNIX socket (a special file in the filesystem).
The syslogd daemon receives the message and decides, based on the facility and priority
fields, what to do with the message. This can be one or more of the following actions:
• Discard it
• Send it to the syslogd on another system
• Add it to a file on disk
• Write it to a user (similar to the write command)
• Write it to all users (similar to the wall command)
The syslogd daemon is configured through the /etc/syslogd.conf file.
There is one program that doesn't log through the syslog daemon directly, and that is the
kernel itself. For technical reasons the kernel developers chose not to include the syslog
system calls in the kernel itself, but used a simplified scheme to do kernel logging. The
kernel log daemon (klogd) receives the kernel log input, converts it into syslog format and
logs it to the syslog daemon. It is then handled as normal syslog input. The klogd daemon
is usually started and stopped together with the syslogd daemon.

V1.2.2 BKM2MIF
Student Notebook
Uempty
% 9
3

%

>>>

>>>

>
Figure 15-3. Facilities, Priorities LX032.0
Notes:
The facility defines the source of the message. The following facilities are defined:
• auth (authentication)
• auth-priv (authentication - privileged; items logged here may contain sensitive
information such as unencrypted passwords)
• cron (scheduling)
• daemon (any daemon)
• kern (kernel messages)
• lpr (printing subsystem)
• mail (mail subsystem)
• mark (only for internal use)
• news (news subsystem)
• security (same as auth; should no longer be used)
• syslog (the syslog daemon itself)
• user (user messages)
• uucp (unix to unix copy)
• local0 through local7 (for custom applications)

Student Notebook
The priority defines the importance of the message. The following priorities are defined:
• debug (debugging information; should normally be discarded)
• info (general information)
• notice (something to keep an eye on)
• warning (something might go wrong)
• warn (same as warning; should no longer be used)
• err (something is going wrong but it's probably not very serious)
• error (same as err; should no longer be used)
• crit (something is failing)
• alert (alert the sysadmin)
• emerg (wake the whole staff; break out the emergency handbooks)
• panic (same as emerg; should no longer be used)
Obviously the priority is only an indication of the seriousness of the message. If you have a
Linux server with two applications on it: a mission-critical DHCP server and a mail server
which is only used to send statistic information twice a day, you will probably pay more
attention to a warning from the DHCP server than to a panic of the mail server.

V1.2.2 BKM2MIF
Student Notebook
Uempty
..
U= [)!= [!

"3= #3!#(#)!(
!
"3=U#3!#(#

)!=U#3!#(#)!(
0 =U[U=B #3#
0 =U[U=B
U=)(U
U=)(R!) =!)=)
Figure 15-4. /etc/syslog.conf LX032.0
Notes:
The file above is an example /etc/syslog.conf file. Each line of the file contains two fields:
the selector and the action field.
The selector field determines for which messages this action is valid. This is indicated by
specifying "<facility>.<priority>", which means that the action is valid for all log messages
from <facility> with priority <priority> or higher (if you specify <facility>.=<priority>, only the
specified priority matches). Multiple selectors may be specified on one line, as long as they
are separated by a semicolon, and not contain any spaces. In addition to that, the wildcard
'*' can be used, which will match all facilities or priorities.
The action field determines what to do with the log items that match. There are several
possibilities:
• Append it to a file, in which case the action is the filename. You need to specify the full
pathname of the file, starting with a '/'. It is possible to specify special files as well, like
/dev/console.

Student Notebook
• Send it to someone by using the write command. In this case, the action is the
username of the recipient. Multiple recipients may be specified, separated by a comma.
• Send it to everyone on the system using wall. In this case the action is a '*'.
• Send it to the syslogd daemon on another system. In this case the action is a '@',
followed by the hostname of the receiving system.
Note that, when sending the message to another system, the selection criteria from that
/etc/syslog.conf file are applied too.
Also note that the log items are sent over the network unencrypted. If your log messages
contain privileged information, such as plain-text passwords, they may be intercepted.

V1.2.2 BKM2MIF
Student Notebook
Uempty

4,
OP>O
PO P
A((5!) = 4"!
A !5%#3!#(#)!(
'%7%&<8<1
)((!) = 4"!
D((50 =! - ! V !(:V

D
+!()(R" ! '%7%&81<71///===
" ((- ! V !(:V
Figure 15-5. logger Command LX032.0
Notes:
Logging is usually built-in into the daemon. But we may also want to do some logging
ourselves, especially if we are writing complex scripts. That's what the logger command is
for.
The logger command is really simple. The only thing you need to do is specify the facility,
priority and the message itself, and it will be sent to the syslogd daemon. See the example
above.
Note that the logger command is not a privileged command; every user can make use of
this command to log any message to the syslogd daemon. It is important to be able to
recognize messages coming from the logger command since users might try to fool you
into panicking.

Student Notebook

**

!
#
!
#
! #
!
#
2
!

&
! AA>
Figure 15-6. logrotate Command LX032.0
Notes:
When a log file grows, there comes a point in time where you might want to clean it out. If
you don't do that, you will end up with a full /var filesystem before you know it - and you are
not able to tell from the logfile what is wrong with your system...
To clean out the logfiles Linux uses the logrotate command. This command, which is
normally run from cron, cleans out all the specified logfiles. Based on the information in the
/etc/logrotate.conf file, it can do any of the following things with the log file:
• It can copy the contents of the log file to an archive log file. This file is usually named the
same as the log file, with a number appended.
• It can compress the archive log file so that it uses less space on your filesystem.
• It can mail the logfile to someone.
• It can clean the current log.
• It can delete old archive logs, ensuring that only a limited amount of archive logs are
being saved.

V1.2.2 BKM2MIF
Student Notebook
Uempty The decision when to rotate a log can be based on two criteria: size of the logfile (for
instance: rotate when the file size exceeds 50 kilobytes) or the time of day (for instance:
rotate at midnight).

Student Notebook
"..
0
! 8

!
A)

# #( ! =
#3!#(# )\
) "
! /&&8
)
! %
]
#3!#(#)!(\
@//0
!
#
#' #0!5?F (

]
#3!#(#
\
)!!) R!) =!)=)
!
#
#' #0!5?F (

]
Figure 15-7. Sample /etc/logrotate.conf LX032.0
Notes:
The /etc/logrotate.conf file starts with a section that describes global options: options that
apply to all files that need to be rotated. In the sample above, the following global options
are defined:
• Rotate all files weekly.
• Only keep four archive logs around.
• Send all errors to root.
• Create a new, empty logfile after rotation.
• The compress function is commented out, so no compression is being done.
The next line, "include /etc/logrotate.d", tells the logrotate command to read all files in the
/etc/logrotate.d directory and to add the contents of those files to this file. This way
programs (and thus, logfiles that need to be rotated) can be added to the system without
the need for the install program (rpm) to change existing files.
The next couple of lines each define a logfile that needs to be rotated. If no options are
given, the default options are used.
For a complete list of possible options, consult the manual page for logrotate.

V1.2.2 BKM2MIF
Student Notebook
Uempty
$ 4
&

M#

$
'
#+
' #+
2

,#
%

,
%, %

Figure 15-8. Analyzing Logfiles LX032.0
Notes:
Logfiles are not collected for fun. They contain valuable information about the overall health
of your system, and things that went wrong. It is therefore a good idea to analyze your
logfiles regularly.
There are several strategies for analyzing a logfile:
• You can read through the whole logfile. With short logfiles this generally is not a
problem, but it quickly becomes tedious when your logfiles are longer than a few
hundred lines. Nevertheless, in case of strange problems it might be necessary anyway,
so that you can correlate different logfile entries.
• You can search through the logfile (using grep or vi’s search capability) for interesting
items. This is typically done when you are looking for something specific, such as all the
actions of a particular user in a particular timeframe. Searching for specific items like
this is called a positive search.
• You can perform a negative search through the logfile. A negative search typically uses
a list of non-interesting items. Using for instance the grep -v command the logfile is

Student Notebook
analyzed and all non-interesting items are filtered out. This, in theory, leaves you with
only the interesting items to look at.
Obviously, this doesn’t work correct immediately. The list of non-interesting items
therefore changes a lot over time.
• You can use automated tools for logfile analysis. These tools analyze the logfile line by
line, and are capable of doing both positive and negative searches. Some tools are
even capable of correlating different log lines with each other.
Several automated tools exist for logfile analysis:
• The easiest tool for logfile analysis is grep. It can be used for on-the-fly analysis, or can
be put into a logrotate postrotate script for positive and negative searches (with the -v
option), of which the results are then emailed to the administrator. grep allows you to
list the expression to search for on the command line, but the expression to search for
can also be stored in a file, which is then referenced using the -f option.
• logcheck is a simple script which checks your logfiles from a cron job. It uses grep and
grep -v extensively in a smart combination. Another advantage of logcheck over plain
grep is that logcheck keeps track of what it has analyzed already, so it will not present
results twice.
• swatch is a heavy-duty logfile analysis tool which is really popular in the UNIX network
administrators world. It is highly configurable and is capable of performing real-time
logfile analysis: you’ll hear of any problems only a few seconds after the log lines are
added to the logfile, instead of having to wait for a scheduled logfile analysis.
• logwatch is a series of perl scripts that are able to check different logfiles and services.
Logwatch itself knows the default behavior of just about every service that might be
running on your Linux system, and filters the interesting log items automatically. Therein
lies its weakness too: it is really hard to configure logwatch for a specific situation or
service. The logwatch configuration directory, /etc/log.d, is a myriad of scripts,
configuration files and symbolic links which make it real hard to figure out where to
make a change to get a certain thing to be reported or not.
Depending on your distributions, one or more of these tools might already be installed by
default, or need to be installed separately.
A last note: most automated tools submit their results by e-mail, and don’t submit a report if
there’s nothing to report. That means that not receiving a report may have two causes:
• There is nothing to report
• Your e-mail subsystem is broken
Beware of this last pitfall, especially if you use these tools to monitor a large number of
systems who do not all send in a report every day.

V1.2.2 BKM2MIF
Student Notebook
Uempty

1) What is the purpose of the syslogd daemon?

______________________________________________
2) What does the logger command do?

______________________________________________
3) What does logrotate do?

______________________________________________
Notes:
1.
2.
3.

Student Notebook
"
'-+ 4

Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty Unit 16. Printers

This unit describes how to set up a printer and spooling mechanism in
Linux.

• Describe the purpose and benefits of a queuing system
• Identify the major components that are responsible for processing a
print request
• Add a print queue
• Submit jobs for printing
• View the status of the printer queues
• Manage printer queues

Accountability:
• Exercises
© Copyright IBM Corp. 2001, 2002 Unit 16. Printers 16-1

Student Notebook

.

" M

.

.
M

1
.
/
.
Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty
' 9 < 9
N N
*%* **
Figure 16-2. Users, Printer Queues, Printers LX032.0
Notes:
All printer queue mechanisms work roughly the same way: A user creates a print job, and
places this print job in a print queue. The print queue is usually a directory somewhere in
/var/spool. A special program called the "queue daemon" periodically checks the print
queues and prints the jobs in order of arrival.
This basic queueing feature is built into every queueing mechanism available, but the
mechanisms differ in the "extras":
• Whether or not multiple (identical) printers can serve one queue.
• Whether or not jobs can easily be moved from one queue to another.
• Whether or not jobs can easily be prioritized.
• To what extent user authentication and authorization is implemented.
• To what extent accounting and/or quota's are implemented.

Student Notebook
#

2
"

!

! #
M

E

>

#M

5%
Figure 16-3. Printing Overview LX032.0
Notes:
There are several steps that a print job has to pass through before the ink actually hits the
paper.
First, the user has to submit the job to the printer subsystem. There are several ways that
this can be done, depending on the subsystem involved. The most common way is by
using a command such as lpr to submit a file to the printer. But the user might also make a
network connection to submit a job, or use a program that can make use of an API
(Application Programming Interface) to submit the job.
Once the job is submitted, it reaches the printer spool daemon. This program is responsible
for performing all subsequent tasks. The spool daemon checks to see if the printer is
available, and if the printer is not available (yet), temporarily stores the file in a spool
directory, together with accounting information such as the owner of the job and the printer
requested.
When the job is ready to be processed further, it is sent through one or more print filters.
These filters convert the job (which is generally in ASCII or Postscript) into a format which
is suitable for the printer, if the printer does not support the print format directly. Another

V1.2.2 BKM2MIF
Student Notebook
Uempty feature of the print filter is to perform color conversion, so that the colors on paper match
the color on your display exactly. This is especially important in the publishing world.
The last hurdle to take is the printer backend. This backend performs the actual submission
of the print job to the printer, depending on how the printer is connected to the system.
Almost all printer subsystems support parallel and serial printers, and most printer
subsystems also support USB and various types of network connections.
A printer subsystem has to be managed too. There are two things that need to be
managed:
• The configuration of the printer subsystem itself, such as printers attached and the type
and make of each printer.
• The print jobs themselves. Print jobs may need to be reassigned to other queues,
cancelled or promoted to the top of the queue.
And obviously you also need to manage the printers themselves: make sure there is ample
supply of paper and ink or toner. Printers jam or break down and need to be fixed, or need
periodic maintenance. Physical management of printers is outside the scope of this course,
however.

Student Notebook
"
5
5
'
A
+
$!((@)

4
Q
Q

- 4E "F
$

5
2 4
!2 '! 2 4 +
!

5 "'" +
2 4
34
WKH
Figure 16-4. Common Printing Subsystems LX032.0
Notes:
The BSD (Berkeley Software Distribution) style printing subsystem is the traditional printing
subsystem of Linux, and was common in all distributions up to about two years ago. It is
very easy to configure, easy to understand but lacking a lot of features.
The AT&T style printing subsystem was not often used under Linux, but other UNIX
systems (such as AIX) use it. The reason we mention it here nevertheless is that LPRng
and CUPS will support the AT&T user interface commands to submit jobs.
LPRng (LPR Next Generation) was written as the successor of BSD printing. To a large
extent it uses the same configuration files and commands, but has a few additional
features. LPRng is used as the default printing subsystem in Red Hat.
CUPS is a completely new, modular implementation of a printing subsystem. It is one of the
first printing subsystems that support the new IPP (Internet Printing Protocol) standard,
which is in the process of being accepted by the IETF as a proposed standard. IPP is
layered on top of HTTP and offers a far richer functionality than the older method of
network printing (LPD). CUPS is currently being introduced into Linux distributions. Red

V1.2.2 BKM2MIF
Student Notebook
Uempty Hat for instance has started shipping CUPS in version 7.3, although not as the default
printer subsystem yet.

Student Notebook
"& "
2 4#

M

I M
$ # M
A
.

#{
(/- .

AA

& AA>.#AA>

4

5%

%
Figure 16-5. BSD Printing Subsystem LX032.0
Notes:
The BSD printing subsystem is the oldest printer subsystem that you might find on a Linux
distribution. It uses a single configuration file, called /etc/printcap, which contains all the
information about all printers in your environment. This printcap configuration file needs to
be repeated on every UNIX system (including workstations) in your environment, leading to
a management nightmare in large installations.
A user submits a job with the lpr command. He or she is able to choose the printer with the
-P option, or by setting the $PRINTER variable beforehand. The job is then send to the lpd
daemon, which spools the job, runs it through a user-defined filter and then sends it to the
printer itself, which may be attached to a parallel port or may be a network-attached LPD
printer.
As said, the print filter is user defined: you have to configure the print filter yourself.
Numerous hours have been wasted on creating print filters manually but recent
distributions have included filters (typically based on ghostscript) which can automatically
detect the type of file being printed (typically limited to ASCII and Postscript) and convert it
into a format suitable for the printer. One of the problems that a print filter author faces is

V1.2.2 BKM2MIF
Student Notebook
Uempty that the printer subsystem has no means of communicating the type of print job to the filter.
So it’s up to the print filter to determine the type of print job and apply the correct
conversions to it.
Print jobs that have been submitted to a BSD printing subsystem can be followed with the
lpq command, and can be cancelled with the lprm command. Furthermore, the system
administrator can run the lpc command, which allows him/her to prevent jobs being
submitted to the queue, prevent jobs being sent to the printer, and to promote jobs to the
top of the queue.
In traditional BSD printing, several modern features are not supported. This includes:
• Migrating jobs from one queue to another
• Queues with multiple printers attached for load balancing
• Queue authorization based on username
• Color conversions
Traditional BSD printing supports network printing too. On the print client, the only thing
you have to do is identify the print server and printer queue name in the /etc/printcap file.
On the server, it requires you to alter the /etc/hosts.equiv or /etc/hosts.lpd file to include the
names of all clients that are allowed to print.

Student Notebook
(!2 0 1

5

.%

/

.
/#M .
"

>
>.#

!
AA
>
AA
>

AA

/5-! T3"$3!%
Figure 16-6. LPR Next Generation (LPRng) LX032.0
Notes:
Some distributions have started to use LPRng, the LPR Next Generation print spooling
mechanism. This LPRng was written by Patrick A Powell in order to overcome the
limitations and security problems of the BSD Printer Spool Package.
LPRng is completely downwards compatible with BSD lpr/lpd. This means that in essence,
the /etc/printcap file format has not changed, that the same directories and files are still
being used, and that the same commands still work. However, some additional features
have been added. Among these are:
• Multiple printers per queue. This means that if you have a number of (preferably
identical) printers, you can all assign them to the same queue, and user jobs will be load
balanced over all these printers.
• It is possible to move jobs from one queue to another, for instance if a printer is down.
• Several additional backends, for instance for SMB printers (printers attached to
MS-Windows servers), NCP printers (printers attached to Novell servers) and
JETDIRECT printers (network printers that attach directly to the network).

V1.2.2 BKM2MIF
Student Notebook
Uempty There are more features added, but these are the most important ones.
LPRng also offers increased security. The lpd daemon no longer runs as root, for instance,
but can run with user privileges. LPRng no longer uses hosts.lpd and hosts.equiv, thus
removing conflicts with rlogin, rsh and rcp. Instead, it uses the /etc/lpd.perms file to
configure remote printing authentication. Authentication can be based on both the
hostname and the username of the user submitting the job, which allows for a more
granular approach.
The last new file is /etc/lpd.conf, which holds a large number of configuration options for
LPRng.

Student Notebook
'(
A " 0'"1
!

2-"F

#

!
-%' "+
! '%
+

#%

'
2 5+
-%'" /5-!T3"$3!+

#

#

AA>
>
Figure 16-7. Common UNIX Printing System (CUPS) LX032.0
Notes:
CUPS is the Common UNIX Printing System. It is a printing system written completely from
scratch, and is designed to make use of the latest features of printers, such as network
attached printers, color laser printers and so forth. It can run on any UNIX system, not just
Linux.
CUPS supports various frontends. Of course, it is still possible to submit a print job using a
command (both lpr and lp are included by default), but it is also possible to submit a print
job via the network (both via LPD and IPP) and by using a C API. The latter makes it
possible to integrate printer support into an existing application. kprint is an application
that makes use of the C API.
CUPS also supports various backends. These includes backends for local ports (parallel,
serial and USB) and various network protocols, such as LPD, IPP, SMB, NCP and
JETDIRECT.
Also included is the notion of printer classes: pools of identical printers which handle jobs
between them to achieve load balancing.

V1.2.2 BKM2MIF
Student Notebook
Uempty And CUPS also includes support for color models and color conversion, which, if
configured correctly, can ensure that a certain color will always look the same, independent
of the media used (regular monitor, LCD panel, paper). This is vital for the publishing
industry.

Student Notebook
!
!
'5 $ !2 +
" $/
2

!

!

5

$
#

Figure 16-8. Configuring Linux Printing LX032.0
Notes:
The first thing you need to do when configuring a printing subsystem is to take a look at
what printing subsystems are offered by your distribution, and install the corresponding
RPMs, if they have not yet been installed.
Some distributions may offer multiple printing subsystems. Red Hat and Debian are
examples of this. In that case, the distribution might support the alternatives command
which, through a series of ingeniously placed symbolic links, allows you to choose between
different installed printer subsystems with a single command. On a Red Hat system, the
command that lets you choose between LPRng and CUPS is alternatives --config print.
For more information, see man alternatives.
The next step is to configure your printers. The configuration files involved depend on the
printer subsystem. It is best to use a system administration program to perform this
configuration, since these programs generally also allow you to set up your print filters, and
these can be really hard to set up by hand. When done, make sure the printer subsystem is
restarted and test everything.

V1.2.2 BKM2MIF
Student Notebook
Uempty The last thing you might want to configure is remote printing. For security reasons, remote
printing is generally disabled by default, and some steps may be required to allow it.

Student Notebook
"&
5 AA

>

@K N
@%

@K

@>'@K /4 &'89 +
@@K

@
%
'@K #
@"%

"@ "
'

7<'@K
#M

+
@%

'@K
@>'@K
@@K
@%
@
%
7<'@K $

@"%

'"@
AA

Figure 16-9. Creating Printer Queues LX032.0
Notes:
Creating new printer queues used to be very tedious. To give you an idea, here's the
shortlist of steps you'd have to go through:
1. Create the spool directory.
2. Add some special files to the spool directory (.seq, errs, status and lock).
3. Install an input filter. Input filters are used to convert the print job to a format the printer
can understand. A simple text job probably doesn't need much conversion, except
maybe for fixing stair-stepping, 1but most print jobs in the Unix world are actually
PostScript documents, which may need to be converted to another format to print
correctly on non-PostScript printers. This is usually done by ghostscript. In that case,
the print filter is nothing more than a simple wrapper script around ghostscript
4. Add the correct entry to /etc/printcap.
1 Stair stepping is caused by printing Unix text files (in which a line is terminated with only the LF character) to a printer which expects
MS-DOS formatted text (in which a line is actually terminated with CF/LF). Your text will then look like this:
This is line one.
This is line two.
This is line three.

V1.2.2 BKM2MIF
Student Notebook
Uempty 5. Start the lpd daemon.

Fortunately, most distributions nowadays come with special management tools, such as
Red Hat’s printtool, a GUI based tool which allows you to set up print queues with the click
of a mouse, or have included printer configuration into the default system administration
tools, such as SuSEs YaST.

Student Notebook
"&

4
5 Ê

_^ !)_
^ !)_`5 Ê

_
.
M
E5 Ê

_
$ #
M .
)5 Ê

_^Z'
)'_
/
.
5 Ê

_P))! Q
.
:4,BÊ

_
Figure 16-10. BSD User Commands LX032.0
Notes:
To submit a job to the printer, the lpr command is being used. This will place a copy of the
file to be printed in the spool directory and will inform the queue daemon about it. The -P
option to lpr will allow you to select the printer the job needs to be printed on.
If your job is a PostScript file it will probably already be formatted and contain page
numbers and so forth. If your job is a plain text file however, you may want to add headers,
page numbers and other information. This can be done with the pr command. The output
of pr can then be piped into lpr.
Users can also view the jobs that are currently queued up for a printer with the lpq
command, and can remove their own jobs with the lprm command.
The lpc command allows you to manage your printers. It can be used in two ways:
interactively and non-interactively. Interactive mode is started when you just enter the lpc
command. You will see an lpc> prompt, which allows you to enter lpc commands.
Non-interactive mode is started when you enter the lpc commands directly after lpc on the
command line.

V1.2.2 BKM2MIF
Student Notebook
Uempty Here is the full list of commands that lpc supports:

Table 1: lpc commands
Command Operation
help [command] Prints a short description of each command
Terminates the spooling daemon on the local host and then
abort <printer> disables printing for the specified printers. Use “all” to indicate all
printers
Removes temporary files, data files and control files that cannot
clean <printer>
be printed.
Turns the specified printer queue off; new jobs will not be
disable <printer>
accepted
down <printer> Turns the specified printer queue off, disables printing and puts a
<message> message in the status file.
enable <printer> Enables spooling; allows new jobs into the spool queue
quit
Exits from lpc
exit
Starts a new printer daemon; use it when the printer daemon, lpd,
restart <printer>
dies, and has left jobs to be printed.
start <printer> Enables printing and starts the daemon for the listed printers.
status <printer> Displays the status of daemons and queues on the local system
Stops a spooling daemon after the current job completes and
stop <printer>
disables printing
topq <printer>
Places the jobs in the order listed at the top of the printer queue
[jobnum] [user]
up <printer> Brings up everything and starts a new daemon.
If no queue name is given, the default queue name lp will be used. Users can override this
behavior by setting the PRINTER shell variable to the name of their default queue.

Student Notebook

2 3 3'$+

' 3+

! AA

AA
>
!
! AA
>

$
$
5
'
>+
$
Q

Figure 16-11. Configuring LPRng Printing LX032.0
Notes:
Since LPRng is downwards compatible with BSD, the previous visual still applies.
However, configuration of LPRng is even harder than BSD, especially because of the more
advanced print filters that are included by default in LPRng, so it is even more
recommended to use system administration tools for this purpose.
On Red Hat, the preferred tools are printconf-tui and printconf-gui, which offer a
text-based and a graphical user interface, respectively. On SuSE, the preferred tool is yast.
The file /etc/lpd.perms is not configured by printconf or yast. This file details what local
and remote users are able to do on this print server: submit jobs, cancel jobs and so forth.

V1.2.2 BKM2MIF
Student Notebook
Uempty
'"

! #

AA#;<(
# AA

!2

#
%

!2
5
'
>+
*, *
!2
Q

Figure 16-12. Configuring CUPS LX032.0
Notes:
If you decide CUPS, then you can configure it via a web browser interface. cupsconfig is a
simple frontend which activates a suitable browser and lets it connect to http://server:631.
Obviously the cupsd daemon has to be running first.
CUPS can be configured extensively via this browser interface. However, in some
situations it might be necessary to dig into the configuration files (generally stored in
/etc/cups) by hand.
CUPS supports a large number of filters, some of which are overlapping. That means when
you configure your printer, you will see multiple filters to choose from. The best approach is
to test the different filters with your workload, to see what filter yields the best result.
Once configured, CUPS supports all BSD printing commands. Note that lpc only works in
read-only mode: you cannot make changes to the printing subsystem with lpc. In addition
to this, CUPS also comes with replacements for the standard AT&T printing commands.

Student Notebook

1) T/F One of the advantages of queues is that each user can have a
different default queue set up for them.
2) Can any user bring the print queue down? Name a few people
who can.
______________________________________________
3) T/F Once the printer is down, no more jobs can be submitted to the
queue.
4) Can users delete all their print jobs in a specific queue? If so,
how?
______________________________________________
Notes:
1.
2.
3.
4.

V1.2.2 BKM2MIF
Student Notebook
Uempty
"

#

%
4

5
$
!2
!

Notes:

Student Notebook

V1.2.2 BKM2MIF
Student Notebook
Uempty Unit 17. Troubleshooting

This unit will teach you the basics of troubleshooting a Linux system.

• Perform basic problem determination
• Use the rescue mode

Accountability:
© Copyright IBM Corp. 2001, 2002 Unit 17. Troubleshooting 17-1

Student Notebook

2
Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty
/
" 4

$.

0

0

0
#
34

2

$
"
-

Figure 17-2. Troubleshooting LX032.0
Notes:
Troubleshooting is a short name for identifying and fixing problems. Most people consider it
an art form, which takes years to get proficient in. This unit will give you some general
techniques and tools that will help you in becoming proficient in it too.
Troubleshooting generally requires you to have a deep understanding of the underlying
system and its dependencies, of the troubleshooting tools that are available on your
system. And a lot of experience helps a lot too.
Useful things to have include documentation, reference systems and internet access. But
there are two things that are most often forgotten:
Having no outside distraction is really important, especially when solving critical problems
on production systems. It is really hard to solve a pressing problem if the phone rings every
minute. In fact, large system administrator groups typically have emergency scenarios
where one team member is tasked with answering the phone and talking to management
so that the others are able to direct their full attention to the problem.

Student Notebook
Having a sparring partner with more-or-less equal knowledge of the system is also
indispensable, since he or she might see things or think of things that you did not, and vice
versa.

V1.2.2 BKM2MIF
Student Notebook
Uempty

$'

+
% #
$
2 4%#
!%,##
-% S-
/

C
4
!

!%
A

5.

D
Figure 17-3. Identifying the Problem LX032.0
Notes:
Identifying the problem usually starts with reading the logfiles, both the generic logfiles
(such as /var/log/messages) and the applications specific logfiles, which are usually
located in or under /var/log as well. Most services have a debugging switch which greatly
increases the output to the logfile, especially if you reconfigure your /etc/syslog.conf file to
log debug output too.
If your logfiles don't give you a clue, read the configuration files for the service that you are
debugging. Use syntax checkers like checkpc where available.
Don't forget that a problem in a service might be caused by a problem in an underlying
service, such as networking, DNS, PAM, full filesystems, wrong permissions or things like
the X Font Server (xfs).
It might be useful to compare the actual situation with a working reference system, for
instance your own laptop running Linux.

Student Notebook
It might also be useful to check the web. Various websites, including the one from your
distributor, include bug tracking databases which can greatly help you if you use them
properly. Documents from the Linux Documentation Project (LDP) can also help.

V1.2.2 BKM2MIF
Student Notebook
Uempty
9

' + '+
%
2

2

J KJ
K

J KJ
K
$.
4

#
Figure 17-4. strace, ltrace LX032.0
Notes:
strace and ltrace are excellent troubleshooting tools: They allow you to run a program and
will display on the screen (or in a file) every system call or library call that that program
made, what the parameters were, and what the result of that system call was. Combined
with a little programming experience gives this you the ability to trace exactly what a
program is trying to do, and why it failed.

Student Notebook
%!
4
#

!

5

5 A
%

5
Figure 17-5. Fixing the Problem LX032.0
Notes:
Once the error has been found, it needs to be fixed. This is typically a trivial task, but may
become more complicated if the system refuses to boot properly because of that error. In
that case, there is a number of things you can do:
• Boot from the boot disk that was created during the installation process. This boot disk
usually consists of a boot loader (LILO or GRUB), a Linux kernel and (if needed) an
Initial Root Disk. This allows you to bypass any problem that might exist in your master
boot record or in your /boot partition, but will not help you if the problem is in your root
filesystem or further along in the boot process.
A boot disk is typically created with the mkbootdisk shell script, and is system specific
to a certain degree:
- The boot loader configuration contains the device name of your root partition, typically
something like /dev/hda5. If your root partition has moved, you need to specify a new
one at the LILO or GRUB boot prompt with linux root=/dev/hda6

V1.2.2 BKM2MIF
Student Notebook
Uempty - The kernel on the boot disk is optimized for your processor. This means that you
cannot use a boot disk created on a Pentium-II machine to boot a regular Pentium
machine.
- The initial root disk on the boot disk only contains the modules that are needed on
your system.
• Boot into single user mode. This requires the boot process, up to and including the
/etc/rc.sysinit file to be in full working order, but might help you if you have a problem
starting certain services.
• Boot into a rescue mode. In this case, the full boot process is done from CD-ROM or the
network. This allows you to fix virtually any problem on disk.

Student Notebook

5 *#* !,$?/ %

! 4
2

- E

/ A#
$ A4

$ %A

$
$

E A

#
% A%A%A

Figure 17-6. Rescue Mode LX032.0
Notes:
The rescue mode is a special boot process from a "live" filesystem on CD-ROM or over the
network. "Live" in this respect means that the filesystem is either accessed from
CD-ROM/network directly, or the CD-ROM/network contains an image of a live filesystem
that is loaded into a RAM disk. In both cases, the live filesystem contains enough utilities to
fix almost any problem on disk.
Most distributions include the rescue mode as an option in the installation process and/or
include special CDs which allow you to boot into a rescue mode.1 But other companies
may make rescue CD-ROMs too. A popular giveaway at trade shows for instance is a
bootable business card (a CD-ROM cut to credit card size) which include a Linux rescue
mode.2 This is useful since the rescue mode is completely independent of the distribution
used. It is perfectly possible to use the SuSE rescue mode to repair a Red Hat system, for
instance.
1
Red Hat 7.2 Professional for instance comes with a System Administration CD, which includes a very complete rescue mode.
2
Linuxcare for instance does this.

V1.2.2 BKM2MIF
Student Notebook
Uempty Note that because rescue modes have to operate in limited environments, they usually can
not include large programs. Some distributions, including Red Hat, therefore leave out vi
and only include the tiny text editor pico.
No matter which rescue mode you use, some steps will have to be done after the boot
process has finished:
• Create /dev device entries with mknod. Most rescue modes do not include the hundreds
of device entries that a normal /dev filesystem would contain (with the resulting space
loss) but include an intelligent mknod command which will make these device entries for
you, with the proper major and minor numbers.
• Run fdisk to view and/or fix the partition table.
• Run fsck to check each filesystem for errors.
• Run mount to mount each filesystem, usually starting at a location like /mnt/sysimage.
Once these steps have been performed, you are ready to fix the problem. This will require
you to go into the filesystems and edit files and so forth. Going into the filesystems can be
done with the regular cp command, but this might cause problems when you try to run
commands like lilo or rpm, because these programs use absolute pathnames which
cannot be resolved.
If you encounter this, it's best to use the chroot command. This performs the chroot()
system call, which makes the specified directory the root of your filesystem, and then starts
a shell. All commands executed and pathnames referenced in this shell are now relative to
the directory that you chrooted into, instead of relative to the root of your rescue disk. This
means that commands like lilo and rpm will work without any special options.
You can exit the chrooted environment by exiting the shell with exit.
When you finished fixing the problem, you need to umount each filesystem in the proper
order. In addition to this, it is wise to perform a sync every now and then, to make sure that
changes are indeed written to disk.3
When all filesystems are unmounted, you can reboot your system. Don't forget to take out
your boot media!
Some rescue modes try to perform the mknod/fdisk/fsck/mount sequence automatically.
3
The umount command will perform a sync automatically, but we're not taking chances here, are we?

Student Notebook

1) T/F Internet access is required for troubleshooting.
2) If your X server does not start, then the problem might also be:
a. The network
b. The font server
c. A full filesystem
d. All of the above
Briefly describe the order of tasks to perform in the rescue

3) mode.
______________________________________________
Notes:
1.
2.
3.

V1.2.2 BKM2MIF
Student Notebook
Uempty
' "
4

.

##
%E
#
%

#
#

" H %
4
Notes:

Student Notebook

V1.2.2 BKM2MIF
Student Notebook
Uempty Unit 18. Policies and Procedures

This unit will talk about the policies and procedures that most
organizations have in place to manage their system management.

• Discuss the need for policies and procedures
• Discuss user and administrator policies
• Discuss system management procedures

Accountability:
© Copyright IBM Corp. 2001, 2002 Unit 18. Policies and Procedures 18-1
Student Notebook
Objectives

Discuss the need for policies and procedures
Discuss user and administrator policies
Discuss system management procedures
Notes:

V1.2.2 BKM2MIF
Student Notebook
Uempty
About Your Systems
The systems you manage are not your own

Paid for by management
Intended for use by the users
You are expected to implement and manage the system
so that it is
100% secure
extremely easy to use
and costs nothing...
Figure 18-2. About Your Systems LX032.0
Notes:
As a system administrator, you are faced with an almost impossible task. Your systems are
paid for by the management of your company, and are intended for the users to do their
regular work on. Management and the users expect you to make sure that these systems
are 100% secure, extremely easy to use and cost virtually nothing.
Student Notebook
The Dilemma
Ease of use
Secure Economical
Figure 18-3. The Dilemma LX032.0
Notes:
The three requirements from the previous visual, security, ease of use and low cost are
perpendicular to each other. It is usually fairly easy to attain one of the requirements, it is
not impossible to attain two requirements, but it is virtually impossible to attain all three
requirements.
Having a really secure and yet really easy to use system is usually really expensive. But on
the other hand, cheap and easy to use systems are typically not very secure. This is the
dilemma that system administrators face day to day. And since it's not the system
administrator but the users who need to use the system, and the management that needs
to pay for them, we can let these two groups of people handle the tough decisions. That's
why we need policies: To clarify the relationship between management, system
administrators and users.

V1.2.2 BKM2MIF
Student Notebook
Uempty
Policies
Policies help you

Determine the balance between security, ease-of-use
and cost
Set the expectancy level of users
Set the expectancy level of system administrators
Set the expectancy level of management
Determine what is acceptable use and what is not
In most jurisdictions, regular law has not yet caught up
with advances in ICT technology
In that case, policies "augment" the law
Typical policies:
User policy
Administrator policy
Security policy
Figure 18-4. Policies LX032.0
Notes:
Policies are typically dry documents that spell out what is required of the users and
administrators with respect to the computer systems. They are full of legal language and
are not really interesting reading material. But yet, they are really important since they are
sort of a "contract" between management, administrators and users, and determine the
relation, obligations and expectations towards each other.
In most jurisdictions, common law has not yet caught up with the rapid advances of the ICT
industry. This leaves a legal void which needs to be filled with a user policy. As an example,
if I work in a bakery and decide to add some extra ingredients to the dough which
eventually makes people ill, I can be prosecuted for a number of things, starting with
disregarding hygiene codes that govern food-processing industries. On the other hand, if I
work as a system administrator and upload a trojan horse program to a system which
performs a full filesystem delete if my user account is ever wiped out, there is no law which
applies. At least, in a large number of countries. In these cases, policies that are signed by
the users and administrators (or better yet, that are part of your employment contract) sort
of "augment" the law in the sense that they will be used in the court of law as a legally
binding contract which was violated.
Student Notebook
User Policy
Describes how users can get access to the system

Hostnames, login procedures
How to contact the help desk
Describes what the users can expect from the system
Applications that are available/supported
Privacy policy
Service times
Quota policy
Describes what is expected of the users
Password policy
Usage policy
Users need to be aware of user policy and express
consent before access to systems is granted
Figure 18-5. User Policy LX032.0
Notes:
A user policy typically describes how users can get access to the systems, what they can
expect from the systems, and what is expected of them. These policies typically come in
the form of handy booklets which also double as simple manuals for using the system.
Some things that need to be listed in a user policy are:
• The applications that are supported by the system, and the level of support that can be
expected.
• The privacy policy with regards to personal and group files, e-mail and such.
• The service times: At what hours can the user expect that applications/servers are
running and that the help desk is operational.
• Quota on disk space, CPU time and bandwidth.
• The password policy: How often do passwords need to be changed. What are the
criteria for "good" passwords. Are users allowed to divulge passwords to others?
• Is usage of the systems for private purposes allowed and if so, when and how much?

V1.2.2 BKM2MIF
Student Notebook
Uempty Users need to be aware of the user policy and need to express their consent to it before
access is granted. The best measure to achieve this is to include a reference to it in the
employees contract. But if this is impossible (for instance if your users are not employees,
but university students or customers) you might need other ways of getting this consent.
Student Notebook
Administrator Policy
Describe what is expected of administrators

Education level
Confidentiality
Availability
Describe usage of administrator privileges
Only su to root if really needed; use sudo otherwise
root password maintenance
Describe what to do when an administrator has to violate
other policies (e.g. privacy)
Administrators need to be aware of administrator policy
and express consent before administrator access to
systems is granted
Figure 18-6. Administrator Policy LX032.0
Notes:
Administrators are users with special privileges and obligations. This typically requires a
different policy. It can specify things like when to use the root account and when not, and
special procedures for handling the root password.
But one really important thing to consider is the fact that the administrator can, and
sometime has to violate the users privacy policy. It might be necessary for an administrator
to look in the mail file or home directory of a user, to solve a problem there. The
administrator policy can specify the measures that have to be taken to protect the privacy of
users in cases like this, such as
• Actions that violate the users rights will always be performed under supervision of a
colleague, who verifies that the level of violation was limited to that needed to solve the
problem. If no colleague is available for supervision, then all actions need to be logged
using script and reviewed by a colleague later.
• If possible, the users are warned beforehand. If that is not possible, users are informed
afterwards.

V1.2.2 BKM2MIF
Student Notebook
Uempty Just as with user policies, the administrator needs to express his consent before access is
granted. This is typically not a problem for permanent employees, but might be for
temporary contractors. In this case, having a stack of "sign here" forms at hand can be
beneficial.
Student Notebook
Security Policy
Describes the level of security that needs to be applied to

various systems and applications
Describes the technical measures taken to reach that
level of security
Authentication
Authorization
Logging
Detection
Response
Tradeoff: cost of security vs. cost of data
Figure 18-7. Security Policy LX032.0
Notes:
The security policy describes the level of security that needs to be applied to various
systems and applications, and describes the technical measures that need to be taken to
reach that level of security. It is typically a tradeoff between the cost of security versus the
cost of the data on the systems.

V1.2.2 BKM2MIF
Student Notebook
Uempty
Procedure Handbook
A procedure handbook describes common system

administration tasks
Advantages:
Reduces errors
Prevents forgetting steps
Helps train new administrators
Common procedures:
Adding/removing a workstation/server
Adding/removing user accounts
Adding/removing printers
Backups
Regular/emergency power down of important systems
Upgrading the operating system or critical software
Typically a living, on-line document
Figure 18-8. Procedure Handbook LX032.0
Notes:
Another document that you might want to create is a procedure handbook. This document
describes common system administration tasks, and help you prevent errors.
Common tasks that are described in a procedure handbook are:
• Adding/removing a workstation/server to/from the network
• Adding/removing a user account
• Adding/removing printers
• Creation and storage of backups
• Regular and emergency shutdown and restart of important systems
• Upgrades of operating systems and critical software
A procedure handbook is typically a living, online document which is updated when
procedures change.
Student Notebook
Management of System Management
The system management process needs to be managed

too
Things to consider:
Testing procedures
Change management
Service Level management
Management of licenses
Management of maintenance contracts
Management of contracters
Disaster planning
Hiring/Firing/Training system administrators
Purchasing guidelines
Figure 18-9. Management of System Management LX032.0
Notes:
The system management process needs to be managed too. Things to consider in this
respect are:
• Testing procedures. How do you test your systems/applications for proper performance.
If new hardware/software is delivered, what procedures apply to this? Do you need
separate testing, staging and production servers?
• Change management. This applies to recording all changes that are made to the
configuration of systems, and allows you (if done right) to roll back changes easily if they
do not have the required result.
• Service Level management. This includes regular audits to see if the service levels that
were agreed on with the users are being achieved, and reporting this to the user and/or
management.
• Management of licenses. Most commercial software vendors issue licenses that allow
you to use their software only on a limited number of systems, or with only a limited

V1.2.2 BKM2MIF
Student Notebook
Uempty number of simultaneous users. License management allows you to track all this, and to
obtain additional licenses when needed.
• Management of maintenance contracts. This includes keeping track of all maintenance
contracts, both for hardware and software, and determining if these contracts are really
needed. It might be cheaper to do without a maintenance contract and pay per-incident
fees if something happens.
• Management of contractors. Contractors are typically only hired for a single job but are
always looking for opportunities to extend or expand the contract. Keeping track of what
your contractors are doing is important because you don't want to become too
dependent on them.
• Disaster planning. This typically comes down to brainstorming what steps to take in case
of a disaster, like a fire which destroys the computer floor, or worse.
What is important to remember is that certain truths in daily life might not be true in case
of a disaster. What if you are not able to enter your building, because of a fire next door?
Does everybody know how to contact everybody else, even when outside the office?
What if one or more administrators get an accident and end up in hospital or worse? Is
crucial information, such as root passwords, available from somewhere else? What if the
computer floor, including the backup tapes near the machines, are destroyed
completely? Can you recreate your whole infrastructure and everything from your off-site
backups?
• Hiring/firing/training system administrators. When hiring, do you give them all privileges
right away or do you wait a certain amount of time? When firing, what procedures do you
perform to make sure that he/she did not leave any trojan horses in the system? What
do you do with the data that was stored in the administrators home directory?
• Purchasing guidelines. What brand of equipment do you buy? Are you going to buy
rack-mounted equipment or not? When purchasing equipment, do you do a
recalculation for weight of racks, power consumption and air conditioning? Are you
always shopping around for the best bargain or are you going to stick to one vendor?
The latter certainly makes warranty and maintenance contracts easier.
Student Notebook
Checkpoint
1) T/F Under no circumstances is a system administrator allowed to

violate privacy policies.
2) Where would you write down which steps to take if a new user
account needs to be added to the system?
a. User policy
b. Procedure handbook
c. Security policy
d. Administrator policy
3) What are the three dilemma factors to consider in system

management?
______________________________________________
Notes:
1.
2.
3.

V1.2.2 BKM2MIF
Student Notebook
Uempty
Unit Summary
Policies that govern the use and administration of your

systems are essential for a healthy organization
Common law has not yet caught up with advances in ICT;
in this case, policies "augment" the law
Policies that you might want are user policies,
administrator policies and security policies
Procedures help you perform common tasks without
making mistakes or forgetting steps
Notes:
Student Notebook

V1.2.2
Student Notebook
AP Appendix A. Checkpoint Solutions

Unit 1
1. True
2. b
3. Keep humidity levels sufficiently high (at least 40%) to prevent
buildup of static electricity
Ground all equipment
Use prevention measures like touching the grounded case and/or
using wrist straps and antistatic mats when maintaining equipment
Unit 2
1. False
2. d
3. On the boot diskette or on an NFS server.
Unit 3
1. BIOS, Boot Loader, Linux, init.
2. By setting runlevel 5 as the default runlevel in /etc/inittab.
Unit 4
1. Red Hat: setup, authconfig, kbdconfig, mouseconfig, ntsysv,
sndconfig, timeconfig, Xconfigurator
SuSE: YaST, YaST2
Caldera: LISA
2. Download webmin-version.tar.gz from http://www.webmin.com
Untar it in the directory /usr/src
Go to the /usr/src/webmin-version directory
Run ./setup.sh and answer all questions
Start your web browser and connect to port 10000
Unit 5
1. Install, freshen and upgrade, uninstall, query and verify.
2. rpm -V -f /etc/sendmail.cf
Unit 6
1. It is the X-Windows server and controls the hardware (graphical
adapter, monitor, mouse, keyboard).
© Copyright IBM Corp. 2001, 2002 Appendix A. Checkpoint Solutions A-1

Student Notebook
It allows other applications to use the hardware.

2. It displays the borders around the windows and presents a
graphical way of starting and stopping applications and managing
their windows.
3. By starting the application on the remote host with the correct
-display option or $DISPLAY variable set.
You need to allow this first though. This is done using either xauth
or xhost.
Unit 7
1. True
2. c
3. There is no command per se. A RAM disk is created automatically
as soon as you start using it.
Unit 8
1. Size 0: 1 inode and 0 data blocks
Size 1: 1 inode and 1 data block
Size 2000: 1 inode and 2 data blocks
Size 12289: 1 inode and 12 data blocks directly from the inode, an
indirect block, and an extra data block. Total 14 data blocks.
2. mounting it and using the cp command
using the mtools (mcopy in this case)
3. /etc/fstab to specify which filesystems use quota
quota.users and quota.groups in the root of the filesystem
Unit 9
1. Because there is either too much or not enough hardware support
on the system.
Because you want to be involved in kernel development.
Because it is fun.
2. On the internet or from your distribution CDs.
3. Install kernel source
make mrproper
vi Makefile (change EXTRAVERSION)
make config, make menuconfig or make xconfig
make clean
A-2 Linux System Administration © Copyright IBM Corp. 2001, 2002

V1.2.2
Student Notebook
AP make dep
make bzImage
make modules
make modules_install
cp arch/i386/bzImage /boot/bzImage-version
cp System.map /boot/System.map-version
cp .config /boot/Config-version
mkinitrd -f /boot/initrd-version.img version
vi /etc/lilo.conf; lilo or vi /boot/grub/grub.conf
Unit 10
1. Real memory + paging space - ~ 1MB
2. It is reserved for the kernel
3. A paging partition is directly written in the partition table and to
disk, while a paging file has to go through the filesystem
4. top continuously displays some vital system information on the
screen
Unit 11
1. crontab -l
2. b
3. /etc/cron.deny and /etc/cron.allow
/etc/at.deny and /etc/at.allow
Unit 12
1. A will back up the files using the full pathnames, whereas
B will back up the file names using the relative pathnames
B can also restore its file into any directory.
2. b
3. False
4. True
5. Yesterday evening and you checked it this morning.
© Copyright IBM Corp. 2001, 2002 Appendix A. Checkpoint Solutions A-3

Student Notebook
Unit 13
1. b
2. In /etc/shadow.
Unit 14
1. Display a welcome message to users logging in remotely
2. c, e
Unit 15
1. It receives all logging requests and forwards it to the right
destination, depending on priority and facility
2. It sends logs messages to the syslogd daemon
3. It rotates the log files
Unit 16
1. True
2. No - only system administrators or root
3. False
4. Yes, they can - by only specifying a queue name and not individual
job numbers
Unit 17
1. False
2. d
3. mknod, fdisk, fsck, mount, chroot, fix the problem, exit, sync,
umount, reboot
Unit 18
1. False
2. b
3. Security, ease-of-use and cost.
A-4 Linux System Administration © Copyright IBM Corp. 2001, 2002

V1.2.2
ackpg

Linux System Administration Lx03

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Linux System Administration Lx03

Încărcat de

Drepturi de autor:

Formate disponibile

V1.2.2.

Linux System Administration

(Course Code LX03)

IBM Learning Services

June 2002 Edition

Course Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Unit 1. Physical Planning and Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Unit 2. Advanced Linux Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Unit 3. Startup and Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

© Copyright IBM Corp. 2001, 2002 Contents iii

Unit 4. System Administration Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Unit 5. Packaging Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Unit 6. X Window System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

iv Linux System Administration © Copyright IBM Corp. 2001, 2002

TOC Sample /etc/X11/XF86Config-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16

Unit 7. Block Devices, RAID and LVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Unit 8. Filesystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

© Copyright IBM Corp. 2001, 2002 Contents v

Data Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-10

Unit 9. Kernel Compilation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Unit 10. Memory Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

vi Linux System Administration © Copyright IBM Corp. 2001, 2002

TOC Unit 11. Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

Unit 12. Backup and Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1

Unit 13. User Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1

© Copyright IBM Corp. 2001, 2002 Contents vii

Unit 14. User-Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1

Unit 15. Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1

Unit 16. Printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-1

viii Linux System Administration © Copyright IBM Corp. 2001, 2002

TOC Unit 17. Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-1

Unit 18. Policies and Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-1

Appendix A. Checkpoint Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

© Copyright IBM Corp. 2001, 2002 Contents ix

x Linux System Administration © Copyright IBM Corp. 2001, 2002

© Copyright IBM Corp. 2001, 2002 Trademarks xi

xii Linux System Administration © Copyright IBM Corp. 2001, 2002

ref Course Description

© Copyright IBM Corp. 2001, 2002 Course Description xiii

• Apply user-level security

xiv Linux System Administration © Copyright IBM Corp. 2001, 2002

© Copyright IBM Corp. 2001, 2002 Agenda xv

xvi Linux System Administration © Copyright IBM Corp. 2001, 2002

Uempty Unit 1. Physical Planning and Maintenance

What This Unit Is About

What You Should Be Able to Do

How You Will Check Your Progress

Figure 1-1. Objectives LX032.0

1-2 Linux System Administration © Copyright IBM Corp. 2001, 2002

Figure 1-2. Issues in Physical Planning and Maintenance LX032.0

  

"  # 

Figure 1-3. Computer Room LX032.0

1-4 Linux System Administration © Copyright IBM Corp. 2001, 2002

       !  "

"  '()*+% # 

Figure 1-4. Rack Mounted vs. Lots of Boxes on Shelves LX032.0

1-6 Linux System Administration © Copyright IBM Corp. 2001, 2002

Uempty The advantages of rack-mounting all your equipment is obvious:

1-8 Linux System Administration © Copyright IBM Corp. 2001, 2002

/         

1-10 Linux System Administration © Copyright IBM Corp. 2001, 2002

% &   "   " 

/%   

" #

! "

" '()*+% #

/

%& " "

/%

5

' "

/ #

" $/

$

""-

!$?/ -

-% # #

$ % '/5$+

%)%+) 9(7=/*

/5$'+ AA

AA

K & >

K # #>

K$ 4 #J

" " 0" 5 1