Sys Admin

V2.0.0.
cover
Front cover
Linux System
Administration I:
Implementation
(Course Code LX03)
Student Notebook
ERC 3.0
IBM Certified Course 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® DB2® Domino™
Hummingbird® Lotus® OS/2®
PS/2® XT™
Windows and Windows NT are trademarks of Microsoft Corporation in the United States,
other countries, or both.
Intel and Pentium are trademarks of Intel 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.
Linux is a registered trademark of Linus Torvalds in the United States and other countries.
Other company, product and service names may be trademarks or service marks of others.
July 2003 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.
© Copyright International Business Machines Corporation 2001, 2003. 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.
V2.0
Student Notebook
TOC Contents
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Course Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Certification Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
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-4
Red Hat "Kickstart" Installs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6
SuSE "autoinstall" Installs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
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
LILO - Linux Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7
/etc/lilo.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
GRand Unified Bootloader (GRUB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10
GRUB - Grand Unified Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12
/boot/grub/grub.conf or /boot/grub/menu.lst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
Kernel Booting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15
Initial RAM Disk (initrd) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17
init . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19
/etc/inittab (Red Hat/SuSE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20
Starting Services (System V init style) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22
© Copyright IBM Corp. 2001, 2003 Contents iii

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Student Notebook
Configuring Services per Runlevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-24

Starting and Stopping Services Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-25
Booting Linux in Single-User Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-26
Shutting Down a Linux System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-27
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-28
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-29
Unit 4. System Administration Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2
System Administration Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3
Red Hat "setup" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-5
Red Hat “redhat-config-*” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6
SuSE "YaST" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8
Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9
Webmin Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-10
Webmin Screenshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-11
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-12
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-13
Unit 5. Packaging Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2
RPM 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 (Red Hat only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .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
hello.spec Prep, Build, Install and Files Section . . . . . . . . . . . . . . . . . . . . . . . . . . .5-19
RPM Build Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-20
After RPM Build Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-21
Integrated Package Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-22
Keeping Up To Date (Red Hat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-23
Keeping Up To Date (SuSE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-24
Debian Package Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-25
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-27
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-28
Unit 6. X Window System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2
X Window System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3
X - Client/Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4
Examples of X Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6
X Servers in Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-7
iv Linux System Administration I © Copyright IBM Corp. 2001, 2003

V2.0
Student Notebook
TOC XFree86 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8

XFree86 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9
Starting X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
Stopping X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13
Session Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14
X Networked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15
X Applications Networked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16
Applications over TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17
X Sessions Networked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19
X Sessions over TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20
Chooser Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22
Font Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-23
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26
Unit 7. Kernel Compilation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
Why Kernel Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Compilation Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4
Installing Kernel Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5
Patching the Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6
Configuring the Kernel Compile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8
Kernel Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10
Compiling the Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12
Installing the Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14
Reboot System and Start New Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16
Loading Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17
Configuring the Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19
Sidestep: Device Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20
Configuring the Kernel at Boot Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22
Configuring Modules at Load Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-25
Configuring the Running Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-27
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-28
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-29
Unit 8. Character Devices, PCMCIA and USB . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2
Character Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
Character Device Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4
Virtual Character Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5
Serial Devices, Modems and ISDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7
Serial Terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-9
Parallel and PS/2 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11
Sound Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12
PCMCIA and USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-13
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-16
© Copyright IBM Corp. 2001, 2003 Contents v

Student Notebook
Unit 9. Block Devices, RAID and LVM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-2
Block Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-3
Block Device Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4
Floppy Disks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5
Hard Disks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6
Hard Disk Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8
Partitioning Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-10
RAM Disks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-11
The "loop" Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-12
Logical Volume Management (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-13
Logical Volume Management (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-15
LVM Implementation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-16
Physical Volume Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-17
Volume Group Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-18
Logical Volume Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-19
Striping Logical Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-20
Extending/Reducing a Volume Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-21
Extending/Reducing a Logical Volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-22
LVM Backup and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-23
Additional LVM Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-24
RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-25
RAID Levels (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-26
RAID Levels (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-28
Linux RAID Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-29
Linux Software RAID Implementation (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-30
Linux Software RAID Implementation (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-31
Watching a Running RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-32
Spare Disks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-33
Additional RAID Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-34
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-36
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-37
Unit 10. Filesystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2
What is a File? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3
What is a Filesystem? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-4
The Virtual Filesystem Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-5
Filesystems Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-6
A Typical UNIX Filesystem: ext2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-7
Superblock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-8
Inodes (Index Nodes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-9
Data Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-11
So... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-12
Other Filesystem Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-14
Creating a Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-16
Mounting a Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-17
Mounting Filesystems at System Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-18
vi Linux System Administration I © Copyright IBM Corp. 2001, 2003

V2.0
Student Notebook
TOC Mount Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-20

Unmounting Filesystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-22
Checking a Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-23
ext2/ext3 Specific Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-25
ReiserFS Specific Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-27
JFS Specific Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-28
Comparing Filesystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-29
SHMFS Specific Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-30
Quota Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-31
Quota Implementation on Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-32
Enabling Quota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-33
Configuring Quota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-34
Quota Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-36
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-37
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-38
Unit 11. Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
Linux Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3
Example: Lightly Loaded System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4
Example: Heavily Loaded System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5
Creating Paging Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6
Useful Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-8
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-10
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-11
Unit 12. Scheduling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2
Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3
Cron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4
User crontab Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6
crontab Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-8
System crontab File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-9
Anacron (Red Hat only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-10
/etc/anacrontab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-12
at . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-13
batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-15
Controlling at Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-16
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-17
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-18
Unit 13. Backup and Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-2
Backup Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-3
Incremental vs. Differential Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-4
Sample Backup Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-5
Sample Monthly Backup Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-7
Backup Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-8
© Copyright IBM Corp. 2001, 2003 Contents vii

Student Notebook
Default Backup Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-10

tar Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-11
GNU tar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-13
cpio Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-14
dump Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-15
LVM Snapshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-16
dd Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-18
Other Backup Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-20
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-21
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-22
Unit 14. User Administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-2
Security Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-3
User Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-4
Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-5
User Private Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-7
Shadow Password Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-8
Command Line User Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-10
/etc/skel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-11
Command Line Group Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-12
Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-13
/etc/passwd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-14
/etc/shadow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-15
/etc/group and /etc/gshadow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-17
/etc/issue and /etc/issue.net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-18
Message of the Day . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-19
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-20
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-21
Unit 15. User-Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-2
User-Level Security Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-3
Pluggable Authentication Module (PAM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-4
Authentication before PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-5
Authentication with PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-6
PAM configuration files example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-8
Common PAM Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-11
Principles of Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-12
File Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-14
Changing Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-16
umask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-17
Example: Creating a Team Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-18
Root Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-19
su . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-20
sudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-21
Security Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-23
Useful Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-24
viii Linux System Administration I © Copyright IBM Corp. 2001, 2003

V2.0
Student Notebook
TOC Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-25

Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-26
Unit 16. Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-1

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

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-2
Users, Printer Queues, Printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-3
Printing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-4
Common Printing Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-6
BSD Printing Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-7
LPR Next Generation (LPRng) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-9
Common UNIX Printing System (CUPS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-11
CUPS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-13
Printer Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-14
CUPS Configuration with lpadmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-15
CUPS Configuration with a Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-16
CUPS Configuration with kprinter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-17
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-18
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-19
Unit 18. Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-2
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-3
Identifying the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-5
strace, ltrace, ldd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-7
Core Dumps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-9
Fixing the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-11
Rescue Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-13
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-15
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-16
Unit 19. Policies and Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-2
About Your Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-3
The Dilemma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-4
Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-5
User Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-6
© Copyright IBM Corp. 2001, 2003 Contents ix

Student Notebook
Administrator Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-8

Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-10
Procedure Handbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-11
Management of System Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-12
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-14
Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-15
Appendix A. Checkpoint Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1
Appendix B. Certification Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X-1
x Linux System Administration I © Copyright IBM Corp. 2001, 2003

V2.0
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® DB2® Domino™
Hummingbird® Lotus® OS/2®
PS/2® XT™
Windows and Windows NT are trademarks of Microsoft Corporation in the United States,
other countries, or both.
Intel and Pentium are trademarks of Intel 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.
Linux is a registered trademark of Linus Torvalds 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, 2003 Trademarks xi

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

V2.0
Student Notebook
pref Course Description

Linux System Administration I: Implementation
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 character devices, PCMCIA and USB.
• 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
© Copyright IBM Corp. 2001, 2003 Course Description xiii

Student Notebook
• Perform user administration

• 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
• Character Devices, PCMCIA and USB
• 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 I © Copyright IBM Corp. 2001, 2003

V2.0
Student Notebook
pref 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 - Kernel Compilation and Configuration
Exercise 7 - Kernel Compilation and Configuration
Day 3
Unit 8 - Character Devices, PCMCIA and USB
Unit 9 - Block Devices, RAID and LVM
Exercise 9 - Block Devices, RAID and LVM
Unit 10 - Filesystems
Exercise 10 - Filesystems
Unit 11 - Memory Management
Exercise 11 - Memory Management
Day 4
Unit 12 - Scheduling
Exercise 12 - Scheduling
Unit 13 - Backup and Restore
Exercise 13 - Backup and Restore
Unit 14 - User Administration
Exercise 14 - User Administration
Unit 15 - User-Level Security
Exercise 15 - User-Level Security
© Copyright IBM Corp. 2001, 2003 Agenda xv

Student Notebook
Day 5
Unit 16 - Logging
Exercise 16 - Logging
Unit 17 - Printers
Exercise 17 - Printers
Unit 18 - Troubleshooting
Exercise 18 - Troubleshooting
Unit 19 - Policies and Procedures
xvi Linux System Administration I © Copyright IBM Corp. 2001, 2003

V2.0
Student Notebook
pref Certification Information

Several professional certifications currently exist for Linux. This
course, combined with other Linux courses, will prepare you for all of
them. For more information, see appendix B.
This course, in combination with other courses, has been certified by
ProCert (http://www.procert.com) as appropriate course material for
preparing for LPI certification tests. The statement below reflects this.
Linux Professional Institute Statement

“This course is specifically designed to provide you with the skills,
knowledge and understanding required to become professionally
certified by LPI. To learn more about LPI certifications, or to
register to take an official LPI certification exam, visit www.lpi.org.”
© Copyright IBM Corp. 2001, 2003 Certification Information xvii

Student Notebook
xviii Linux System Administration I © Copyright IBM Corp. 2001, 2003

V2.0
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, 2003 Unit 1. Physical Planning and Maintenance 1-1
Student Notebook

Figure 1-1. Objectives LX033.0
Notes:
1-2 Linux System Administration I © Copyright IBM Corp. 2001, 2003

V2.0
Student Notebook
Uempty

2 2
& )

!
Figure 1-2. Issues in Physical Planning and Maintenance LX033.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 LX033.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

V2.0
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 LX033.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.

V2.0
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 to 5 inches high containing up to 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 LX033.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.

V2.0
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
@

#

" :8A,;8A

@!
*52@** *
B **

<>:(7
52@
B * *.(788852@
Figure 1-6. Air Conditioning LX033.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.

V2.0
Student Notebook
Uempty Air conditioning capacity is expressed in "BTU/hr" (British Thermal Units), which is a
standard unit for measuring heat generated. One BTU equals 1055 Joules. Thus, to cool
one Watt of power converted into heat, you need 3.412 BTU/hr. For reference, a human
being produces about 300 BTU/hr when performing regular office work.
Air conditioning capacity is sometimes also expressed in "tons". This relates to the capacity
needed to freeze a ton of water in 24 hours. One ton equals 12,000 BTU/hr. Consequently,
a ton of air-conditioning is able to remove 12000 * 1055 Joules / 3600 seconds equals
about 3500 Watt of heat - the heat generated by about 10 medium-sized servers.
Coincidentally, in moderate climates, it takes about 3500 Watt to keep a one-ton A/C unit
operating. This leads to a simple rule of thumb: you need a Watt of air-conditioning for
every watt that your computers use.
Student Notebook
%& " "
/%

% 4

#

!

C!B7C" C
!

!

Figure 1-7. Fire Detection and Suppression System LX033.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.

V2.0
Student Notebook
Uempty

5

D

@

,
#
! ,
,
2
& @@

.

!%

0
4
Figure 1-8. Best Practices LX033.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

V2.0
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 LX033.0
Notes:
Write down your answers here:
1.
2.
3.
Student Notebook
' "
/ #

%,
.

4

4

.

%

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

V2.0
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 Red Hat kickstart installs
• Discuss SuSE AutoYaST installs

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

Perform a network installation
Discuss network install servers
Discuss Red Hat kickstart installs
Discuss SuSE AutoYaST installs
Notes:

V2.0
Student Notebook
Uempty
Network Installations
Installations where packages to install are downloaded

from the network
Network protocols supported depends on distribution
NFS
FTP
HTTP
SMB
Requires a network install server
Usually requires special network-enabled boot media
Figure 2-2. Network Installations LX033.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
supported by the boot diskette, you might also need an additional diskette which contains
the device support in the form of Linux kernel modules.
Student Notebook
Network Install Server
Should be a Linux/UNIX server

Content of all relevant CDs copied to disk
Use a naming scheme that allows multiple
versions/distributions to be exported
e.g. /export/rh80, /export/rh9, /export/suse82
Typically NFS, sometimes (anonymous) FTP, HTTP,
SMB
For Red Hat, copy at least .discinfo, RedHat/ and
images/
For SuSE, copy CD 1 completely, from all other CDs
copy suse/ and media*
Figure 2-3. Network Install Server LX033.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.

V2.0
Student Notebook
Uempty 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 .discinfo file, and the RedHat/
and images/ directories. For a SuSE distribution, make sure you copy the whole CD1, at
least the suse/ directory and the media* files of the subsequent CDs.
Student Notebook
Red Hat "Kickstart" Installs

Red Hats method of automating installations
Involves a "ks.cfg" file with three sections:
Install commands: answers to questions of installation
process
%packages section: List of packages/package groups
to be installed
%pre, %post section: List of pre or post-install
commands to be executed
Create ks.cfg manually or with redhat-config-kickstart,
or use /root/anaconda-ks.cfg (created during installation)
ks.cfg can be put on boot floppy or on NFS server
NFS also requires a DHCP server
Kickstart installs started with linux ks or linux ks=floppy
at syslinux boot:-prompt
Edit syslinux.cfg for automation
Figure 2-4. Red Hat "Kickstart" Installs LX033.0
Notes:
"Kickstart" is Red Hat’s 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.xml file. These package groups are
identified with an ampersand, for instance "@ Printing Support".
• 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.

V2.0
Student Notebook
Uempty 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/rh80
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=100
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
@ Printing Support
@ X Window System
@ GNOME Desktop Environment
@ KDE Desktop Environment
@ Development Tools
@ Kernel Development
@ Network Servers
%post
adduser tux1
echo tux1 | passwd --stdin tux1
adduser tux2
echo tux2 | passwd --stdin tux2
Kickstart files can be created by hand, but Red Hat has also released a tool which may
help you generate kickstart files: redhat-config-kickstart (formerly known as ksconfig).
This tool is available on the distribution CDs in the ksconfig RPM. As an added bonus, the
Student Notebook
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.
The kickstart configuration file can be stored on the boot 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 bootdisk.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

V2.0
Student Notebook
Uempty
SuSE "AutoYaST" Installs
SuSE method of automating installs

Involves an autoyast configuration file (XML) containing
all installation information:
General settings for keyboard etc.
Partition settings
Packages
Pre- and post install scripts
Create configuration file with yast autoyast
Store file on floppy or on network server
Start installation with boot parameters:
install=nfs://10.0.0.1/export/suse82
autoyast=file:///profiles/myprofile.xml
Figure 2-5. SuSE "autoinstall" Installs LX033.0
Notes:
SuSE also supports autoinstallations. On the most recent distributions, this is done through
AutoYaST. Earlier SuSE distributions used other, more complicated and limiting ways of
performing autoinstallations.
AutoYaST installations revolve around a huge, XML based file containing all the installation
information. This file can technically be created by hand, but that’s a huge task. It is far
easier to use yast autoyast to create this file.
This file can then be saved on a floppy disk or on the network server. You then need to boot
the system from regular boot media. In order to start the install, you need to supply two
URLs to the boot loader:
• The first URL is the URL where the installation images can be found. This URL
generally has the form install=nfs://10.0.0.1/export/suse82
• The second URL is the URL where the AutoYaST file can be found. This URL generally
has the form autoyast=file:///profiles/myprofile.xml
Student Notebook
In addition to this, you might also need to specify the network adapter and type. This
typically looks like: insmod=eepro100 netdevice=eth0.
Just as with Red Hat, it is possible to modify the syslinux.cfg file on the boot floppy to start
the installation manually.

V2.0
Student Notebook
Uempty
Checkpoint
1) T/F A network install 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 some possible locations where a Red Hat Kickstart or

SuSE AutoYaST file can be stored?
______________________________________________
______________________________________________
Notes:
1.
2.
3.
Student Notebook
Unit Summary
Network install servers are convenient means of software

distribution, both for doing upgrades and installs
A network install server typically exports multiple versions
of multiple distributions via NFS, FTP or HTTP
To perform a network install you typically need a special
boot diskette, and sometimes additional module disks as
well
Red Hat "Kickstart" and SuSE "AutoYaST" install
methods allow you to automate installations
Notes:

V2.0
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 autostarting services
• Boot Linux in single-user mode
• Perform a proper shutdown of a Linux system

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

4

! #
5 4 ,

4
Figure 3-1. Unit Objectives LX033.0
Notes:

V2.0
Student Notebook
Uempty
!"%#

# &
5"B
'%

#
>>>+
2D$25"B
4% &

$

#
>>>#
Figure 3-2. Linux Startup Flow LX033.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

"
!% 'B +

,#
/
B#
!%#

%
!,$B/
%
/5$# 4
Figure 3-3. Basic Input Output System LX033.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, IRQ assignment to devices, 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.
Another thing the BIOS might do is configure (IRQ, DMA, I/O addresses) or disable
peripherals (such as serial ports, parallel ports, network adapters, keyboards, mice and
sound cards) that are integrated on the motherboard.

V2.0
Student Notebook
Uempty

/5$'/5$+
&(75'+
5"B
!
::;
'

+
;: #
!*
7* *
Figure 3-4. Master Boot Record LX033.0
Notes:
The Master Boot Record or MBR is the first sector (512 bytes) of the boot device. It
contains three things:
• A 446 bytes boot loader program: Software to bootstrap the operating system.
• The partition table: A 64-byte table which describes how the rest of the disk is split up
into partitions.
• A 2-bytes magic number, which is used to check whether this is a valid MBR.
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.

V2.0
Student Notebook
Uempty

+ !
"B
/5$ '(+
!
@@>
"B *
*'! +

"B
'! +
*@@
* @ @
"B7 , @@

&# &
*@@>* "B
'! +
Figure 3-5. LILO - Linux Loader LX033.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
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)
1
The numbers are the major and minor numbers of the device. 0300 is your first IDE disk, 0800 is your first SCSI disk.
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.
Student Notebook
,,
9@#@ ('/5$+

9@@

9@@> 7
9@@>

%B
98 '(@(8+
9@@# & B 4 %
9 4 @@# &

@#@
9@#@ ,

9* 9(7=/* * 9(7=/*

%
,
9@#@( , 4

9 **
"B

>
9@#@
Figure 3-6. /etc/lilo.conf LX033.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.

V2.0
Student Notebook
Uempty 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 or INITial Ram
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.
Student Notebook
3 ' 43' 5
/5$'+ @@

'(> +
2
- # "B
! @@@> '$+
@@@ >' 3+
" /5$+

B
2 ,
B
!

D$25
/

@2

Figure 3-7. GRand Unified Bootloader (GRUB) LX033.0
Notes:
GRUB (GRand Unified Boot Loader), 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.

V2.0
Student Notebook
Uempty 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 (Red Hat) or menu.lst (SuSE). On a regularly booted Linux
system, this file is thus referenced as /boot/grub/grub.conf or /boot/grub/menu.lst. 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.3
• 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 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.
Student Notebook
3' +3 '
/5$ (
(
( '! +
#

( '8<+@@7
!
3
4
@@@ >
7 '8<+@# &
$
#* *
@@@>
Figure 3-8. GRUB - Grand Unified Bootloader LX033.0
Notes:
The visual shows the GRUB startup sequence graphically.

V2.0
Student Notebook
Uempty
,,, ,,,

!
" ! #

$

%%&

!
" '(
)) ! )

'(
))

*
+,#

!
-
.
!
.
/

*
+,

!
-
.
!
.
/
Figure 3-9. /boot/grub/grub.conf or /boot/grub/menu.lst LX033.0
Notes:
The GRUB configuration file, /boot/grub/grub.conf (Red Hat) or /boot/grub/menu.lst
(SuSE), 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.
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.
Student Notebook
root The root partition of the filesystem. All files that are referenced later on
are stored on this filesystem. Specifying root is not required, but you will
have to identify the root partition every time you mention a file instead, as
is done with the SuSE stanza.
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.
Note that different distributions can and have made extensions to grub, which allow for
instance graphics to be used.

V2.0
Student Notebook
Uempty
" 6
B %

B ' <=;+%

%
!2 %
Figure 3-10. Kernel Booting LX033.0
Notes:
When the user selects a Linux operating system in the boot loader, then the boot loader will
load the Linux kernel.
Because of space constraints, the Linux kernel is compressed, but has an uncompress
program attached 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.
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.

V2.0
Student Notebook
Uempty

$& 4 5
" $/%' + %

' ! "1/
$"4<+

!

$/%
40

4
%

Figure 3-11. Initial RAM Disk (initrd) LX033.0
Notes:
Not all hardware is supported in the core kernel image. In fact, almost all hardware support
in Linux today comes in the form of modules. These modules are pieces of code that are
loaded into kernel memory only if required.
This works well, but leads to a minor problem if kernel modules are needed to mount the
root filesystem. This can happen, for instance because:
• The root filesystem sits on a hard disk type for which support was not compiled into the
kernel image. This applies mostly to SCSI
• LVM or RAID was used, and LVM or RAID support was not compiled into the kernel
image.
• The root filesystem uses ext3, JFS or ReiserFS as filesystem type, and support for
these filesystems was not compiled into the kernel image.
In these cases, you are going to need an Initial RAM Disk (sometimes also called an Initial
Root Disk). This is a file containing a compressed image of an ext2 filesystem, which in turn
contains two things:
Student Notebook
• A linuxrc script
• The kernel modules that are needed
The initrd image is loaded into memory by the boot loader, just like the Linux kernel. When
the Linux kernel starts, it detects the presence of the initrd. It then proceeds to uncompress
and mount this filesystem as temporary root. The kernels last direct action is then to start
the linuxrc script.
The linuxrc script loads all the required modules, mounts the true root filesystem and then
executes a system call pivot_root. This switches the position of the initrd and the true root
filesystem. From that point on, the actual root filesystem is mounted at its correct location,
and linuxrc is able to continue the boot process by starting the /sbin/init program.

V2.0
Student Notebook
Uempty

% !

@@
# ##
$ ##
8
(
7 -
<
:

;

#
-B
# 7 9 7 9
Figure 3-12. init LX033.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
yourself), and 5 is the same, but with an X-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
,, 4;,""<5

$ 3
# # #<
< <
& > & > @@>@> '$+

@@>@> @@ >@ @@ >@' 3+
88@@>@8 88@@ >@8 $ @@>@'$+@@ >@
((@@>@( ((@@ >@( ' 3+ #

77@@>@7 77@@ >@7
<<@@>@< <<@@ >@<
::@@>@: ::@@ >@:
@@>@ @@ >@
;;@@>@; ;;@@ >@;

!$,,333
!$,,333
,
@ @ ,<, @ @ ,,:
$ # $ # 4#
(7<:
@ @ ( (7<:
@ @ ,, (
'1
77<:
@ @ 7 77<:
@ @ 7
<7<:
@ @ < <7<:
@ @ < #,(,;+
:7<:
@ @ : :7<:
@ @ :
7<:
@ @ 7<:
@ @
;7<:
@ @ ; ;7<:
@ @ ;
$ 4 #

4
@@((@
,

'4
% + #
Figure 3-13. /etc/inittab (Red Hat/SuSE) LX033.0
Notes:
The most important lines of the /etc/inittab file are shown here. Because there are minor
differences in Red Hat’s and SuSE’s /etc/inittab file, they are shown side by side.
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 (RH) or /etc/init.d/boot
(SuSE) 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

V2.0
Student Notebook
Uempty • Deleting various lockfiles which may have been left over from a crash
• Enabling the clock
The third set of lines tells init to run the /etc/rc.d/rc or /etc/init.d/rc in runlevels 0 through
6, with the runlevel as parameter. We will look at this script in the next visual.
After that, the trap for the Ctrl-Alt-Delete three-finger salute is set. This means that if you
press this key combination, the shutdown command 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 prefdm command, which in
turn will start xdm, gdm or kdm. These programs will present a graphical login screen.
This is unique to Red Hat: SuSE starts this through a regular init script (covered in the next
few visuals).
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
" " 4" > 5

@@>@<'$+
@@ >@<' 3+
@@>@<>@06
@@
@@>@<>@ 6
' %
@

+
0, . . .1

+++ 23 ) 4 25 6,7

6,
+++ 23 ) 4 25 67

6
+++ 23 ) 4 2% +7

+
+++ 23 ) 4 2% 667

66

+++ 23 ) 4 %.7 ..
Figure 3-14. Starting Services (System V init style) LX033.0
Notes:
The rc script is a very important script. Although small, it is responsible for starting almost
all services that are active in the runlevel that was specified as parameter.
What this script basically does is the following:
• It changes to the directory /etc/rc.d/rc<runlevel>.d4
• 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.5
• 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.6 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
4
This directory is a symlink to /etc/init.d/rc<runlevel>.d in SuSE
5
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.
6
Depends on the distribution used.

V2.0
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, the administrator 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
"
2

0, , %
#>
0..
$
,
.6
4 44144#4)4
4 44144#4)4

0..
$.6

0..
$
,
.6
4 44144#4)4
4 44144#4)4

Figure 3-15. Configuring Services per Runlevel LX033.0
Notes:
The name and place of the symbolic link to the init.d script thus determines whether a
service is started or stopped in a certain runlevel. But managing these scripts by hand is
really tedious7. That’s why several tools exist for this.
The most common tool is chkconfig. It allows you to list the current configuration (with the
--list option) and to turn individual services on and off.
Each of the service scripts includes information for chkconfig listing the default runlevels
for which the service should be on or off, and the default priority. This leads to the following:
• chkconfig <service> off switches the service off for all runlevels
• chkconfig <service> on switches the service on for the runlevels listed in the service
script. In most cases, this is runlevels 2 through 5.
If you want chkconfig to work on other runlevels than the default 2 through 5, you can
specify this with the --levels <levels> option.
In addition to chkconfig, you can also use your distributions system management tool
(redhat-config-services or yast) to manage these services.
7
In some UNIX variants, you are actually required to do this.

V2.0
Student Notebook
Uempty
" " "

> @

#
B $

B 37 9 % >

B
#
0,!
.,
%66
$4895:
%
$4895:
,,0.,
%
$+,!
.
%
$,!
.
Figure 3-16. Starting and Stopping Services Manually LX033.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 pathname8, but that requires typing a lot of
slashes and dots. Most distributions therefore have created some sort of shortcut which is
faster to type:
• 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.
• On a SuSE system, a symbolic link with the name rc<service> is automatically created.
This links to the init.d script.
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
! " +'
,2/
- % ' %+
-#
-
%'$+
1
"B* *

,

/,/2
)RU/LQX[W\SHOLQX[IRU:LQGRZVW\SHZLQ
%RRW
,
$
D$25* *

! #
# + #
Figure 3-17. Booting Linux in Single-User Mode LX033.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 or /etc/init.d/boot and then start a bash shell. It will not start all the
normal services, so users can't log in over the network.
On a Red Hat system, the single user mode will not even ask for a root password. This is
done so that it can be used if you forgot your root password, and need 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). The safest
course of action here is to do a full reboot (shutdown -r now).

V2.0
Student Notebook
Uempty
" &# !"
B-B

2 # !,,

2

$
34

,++;
,++

/

Figure 3-18. Shutting Down a Linux System LX033.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, kdm or

gdm) in Red Hat and in SuSE?
__________________________________________________
Notes:
1.
2.

V2.0
Student Notebook
Uempty
' "
4

5"B
5"B /5$ 4
/5$ '"BD$25+
4%
'" $/
%+
" % !
,
%

5 "B

D$25

4
# !,,
Notes:
Student Notebook

V2.0
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, 2003 Unit 4. System Administration Tools 4-1
Student Notebook

,

,

Notes:

V2.0
Student Notebook
Uempty
" $ ?
"

%

/

4,
,
,

.
,
C
B

C
! 4 C

4C
Figure 4-2. System Administration Tools LX033.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.

V2.0
Student Notebook
Uempty
;@ @
/ , , #

4,
Figure 4-3. Red Hat "setup" LX033.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
• lokkit: Firewall configuration
• mouseconfig: Mouse configuration
• netconf: Network configuration
• printconf: Printer configuration
• timeconfig: Timezone configuration
All these tools can also be started directly from the command line.
Student Notebook
;@+ +B@
D2",
, , %
, ,
, ,
Figure 4-4. Red Hat “redhat-config-*” LX033.0
Notes:
Recently, Red Hat has begun creating graphical tools for system management, and has
been phasing the text-based tools out. These tools are all separate programs, who each
start with redhat-config-.
As of Red Hat 9, the following tools exist:
redhat-config-bind DNS Server configuration
redhat-config-date Local time, timezone and time server configuration
redhat-config-httpd Web server configuration
redhat-config-keyboard Local keyboard configuration
redhat-config-kickstart Kickstart install configuration
redhat-config-language Local language configuration
redhat-config-mouse Local mouse configuration
redhat-config-network Network settings configuration

V2.0
Student Notebook
Uempty redhat-config-nfs NFS Server configuration

redhat-config-packages RPM Package management
redhat-config-printer Printer configuration
redhat-config-proc /proc/sys configuration
redhat-config-rootpassword Change the root password
redhat-config-samba SMB Server configuration
redhat-config-securitylevel iptables firewall configuration
redhat-config-services System V services configuration
redhat-config-soundcard Soundcard detection and configuration
redhat-config-users User and Group management
redhat-config-xfree86 Graphical adapter, monitor detection and configuration
There is no front-end (like setup) to integrate these tools. Instead, they are integrated in
the KDE and GNOME “start” button menus.
Student Notebook
""<@D"?@

Figure 4-5. SuSE "YaST" LX033.0
Notes:
YaST (Yet another Setup Tool) is the preferred system administration tool on a SuSE
system. It is created by SuSE to work specifically with SuSE and does not work on any
other distribution. It cannot be easily extended but, within its limitations, is quite powerful
and works well.
If you start yast from the command line, you will get a text-based menu. This program
offers the same functionality as the graphical yast.To start the graphical yast from the
command line, type yast2.

V2.0
Student Notebook
Uempty
F

@@> >
B
#

%
5 B

2

/

2 4# 4

,
-
/
Figure 4-6. Webmin LX033.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.
Student Notebook
F

,>

@@> >
+# +

(8888

Figure 4-7. Webmin Installation LX033.0
Notes:
Webmin installation is really simple. On the Webmin website (http://www.webmin.com) you
will find a single RPM file which works for all Linux distributions. Download and install it,
and you’re done. Webmin is automatically started just like any other service.
Accessing webmin is done by launching a web browser such as netscape, konqueror,
galeon, mozilla, lynx, links, opera and even Internet Explorer. Connect to the server,
port 10000. You need to login with a username and password, and can then use any of the
available modules to configure your system.

V2.0
Student Notebook
Uempty
F "
Figure 4-8. Webmin Screenshot LX033.0
Notes:
This is an example screenshot of Webmin.
Student Notebook

1) Name some distribution specific tools.

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

______________________________________________
______________________________________________
______________________________________________
______________________________________________
______________________________________________
Notes:
1.
2.

V2.0
Student Notebook
Uempty
"
%

,

4
/ 4 #

,

Notes:
Student Notebook

V2.0
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
• Keep your system up to date

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

Student Notebook
Objectives

Describe the basic principles of RPM
Install RPM packages
Describe the RPM build process
Create simple SPEC files
Keep your system up to date
Notes:

V2.0
Student Notebook
Uempty
RPM Package Manager (RPM)
Used for package management

Management of source files
Build process
Distribution of binary files
Developed by Red Hat Software Inc, but GPLed
Other Linux distributions use it too, e.g. SuSE
Requirement of LSB
.rpm files can be created by distributor or others
RPM database (/var/lib/rpm) contains database of
installed packages
Can use PGP/GPG for package signing (verification of
authenticity)
Figure 5-2. RPM Package Manager (RPM) LX033.0
Notes:
The RPM Package Manager1 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.
1 It used to be called the Red Hat Package Manager, but Red Hat changed its name to emphasis that other distributions use it too. The
new official name is RPM Package Manager, and yes, that’s a self-referencing acronym (SRA), just like GNU.

Student Notebook
RPM Philosophy
developer distributor
application.tar.gz application.tar.gz SPEC file
patches sample config files
application.src.rpm
rpm -bb on sparc
rpm -bb on i386 rpm -bb on s390
application.sparc.rpm application.i386.rpm application.s390.rpm
Note: Red Hat 8.0 and up uses rpmbuild instead of rpm for building RPMs
Figure 5-3. RPM Philosophy LX033.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.

V2.0
Student Notebook
Uempty When a developer develops a new version of its software, the only thing the distributor
theoretically needs to do is rerun the rpm -bb command, and a new version can be
distributed.
Red Hat 8.0 and up uses the rpmbuild command instead of rpm when building RPMs.
This change was introduced so that Red Hat would be able to separate the
install/query/verify/deinstall functionality from the build functionality into two separate
RPMs.

Student Notebook
RPM Installing, Freshening and Upgrading
Installs, freshens or upgrades an RPM

Freshen: only install if an older RPM was installed
Upgrade: always install, but uninstall older RPM first
Basic syntax:
rpm -i package-filename.rpm (install)
rpm -F package-filename.rpm (freshen)
rpm -U package-filename.rpm (upgrade)
Useful options:
-v be verbose
-h print 50 hash marks during installation
# rpm -ihv package-10.2-67.i386.rpm

package: ##################################################
Figure 5-4. RPM Installing, Freshening and Upgrading LX033.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

V2.0
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, program and documentation files are automatically overwritten.
Configuration files are another matter altogether: Depending on the MD5 checksum of the
original, actual and new configuration file, the configuration file may be left in place, may be
overwritten, may be saved with an extension .rpmsave, or may be saved with an extension
.rpmorig. In fact, rpm can distinguish between six different cases. For more information,
see the Maximum RPM book.
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
RPM Uninstalling
For uninstalling an RPM use the -e option
# rpm -e kdelibs3
error: removing these packages would break dependencies:
kdelibs3 >= 3.1 is needed by kdebase3-3.1.1-63
libDCOP.so.4 is needed by kdelibs3-cups-3.1.1-13
...
Options:
--nodeps ignore any dependency breaks
Figure 5-5. RPM Uninstalling LX033.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.

V2.0
Student Notebook
Uempty
RPM Querying
Queries the contents of an installed RPM

Basic syntax:
rpm -q package-name
Options:
-a query all installed packages
-f <file> query package which owns file.
-p <package-file> query package-file
-i display package information
-l display package files
-s display state of all files
-d display documentation files
-c display configuration files
Figure 5-6. RPM Querying LX033.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 dig program is in? Try rpm -qf `which dig` or
rpm -qif `which dig`
• Need to know what documentation is available for a specific command, and man
-k commandname does not work? Try rpm -qdf `which nslookup`
• Need a lot of data to test a network connection? Try rpm -qila
• 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 *.rpm
do
rpm -q -l -p $package | grep -q pico
if [ $? = 0 ]
then
echo $package
fi
done

V2.0
Student Notebook
Uempty
rpmdb Database (Red Hat only)
rpmdb-version.rpm: Database of all capabilities that all

RPMs provide
Allows you to use the --redhatprovides option
# rpm -iv rpmdb-redhat-7.0-0.20000830.i386.rpm
rpmdb-redhat
# rpm -iv xboard-4.0.7-3.i386.rpm

error: failed dependencies:
chessprogram is needed by xboard-4.0.7-3
# rpm -q --redhatprovides chessprogram
gnuchess-4.0.pl80-6
# rpm -iv gnuchess-4.0.pl80-6.i386.rpm
gnuchess
# rpm -iv xboard-4.0.7-3.i386.rpm
xboard
Note: SuSE solves dependency conflicts through YaST

Figure 5-7. rpmdb Database (Red Hat only) LX033.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 or mailx is
installed, as long as at least one of these is present. This works fine, but obviously makes it
a little difficult to determine which packet to install if a certain capability is missing.
Red Hat has solved this with the rpmdb database. 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.
Starting with 8.0, Red Hat automatically suggests packages if a capability is missing, but
the rpmdb database is installed and the capability is listed there. Unfortunately, there is no
way of automatically installing all required packages.
SuSE does not solve this within the rpm program, but instead has integrated automatic
dependency checking in yast. yast also installs all the missing RPMs automatically.

Student Notebook
RPM Verifying
Verifies the actual files with the original RPM

size S
MD5 checksum 5
permissions,type M
owner U
group G
modification time T
symbolic link L
device D
# rpm -V kdelibs3
.M...... /opt/kde3/kpac_dhcp_helper
.......T /opt/kde3/share/mimelnk/application/x-applix.desktop
a dot (.) means: test passed
Figure 5-8. RPM Verifying LX033.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 checks whether the
contents of a file have changed.
S File size. This checks whether the size of the file has changed.
L Symbolic link. This verifies whether a certain symlink has changed.
t File modification time. This checks whether the file modification timestamp
(mtime) has changed.
d Device. This verifies whether 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?
M Mode. Are permissions, SUID, SGID bits and the file type still the same?

V2.0
Student Notebook
Uempty 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
RPM Signatures
RPM's can be signed by the distributor
To verify signature:
Obtain public key of distributor
CD-ROM
Internet
Add public key to keyring using gpg --import (RPM v3)
or rpm --import (RPM v4)
Verify package with rpm --checksig
redhat# rpm --import /mnt/cdrom/RPM-GPG-KEY
suse# gpg --import /mnt/cdrom/pubring.gpg
# rpm --checksig passwd-0.64.1-1.i386.rpm

passwd-0.64.1-1.i386 md5 gpg OK
Note: You can list the installed keys with "gpg --list-keys"
(RPM v3) or "rpm -qa gpg-pubkey*" (RPM v4)
Figure 5-9. RPM Signatures LX033.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: rpm --import /mnt/cdrom/RPM-GPG-KEY. Note that some
distributions (for instance, SuSE), perform this step automatically while installing.
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.

V2.0
Student Notebook
Uempty
Creating RPMs
RPM creation process is governed by a SPEC file, which
contains all information required to create source and
binary RPMs on all architectures
Preamble Information about the package
Prep Preparation commands for the build
process
Build Commands to build the software
Install Commands to install the software
Install script Scripts to be executed before or after the
package is installed/uninstalled
Verify script Additional script to verify installation
Clean script Additional script to clean up after build
File list List of all files that make up the binary RPM
Used to create both the source and binary RPM
SPEC file normally part of the source RPM
Figure 5-10. Creating RPMs LX033.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.
Not all sections are required. For instance, if you want to create an RPM which just
contains a number of shell scripts, you can leave the build section empty. Shell scripts do
not need to be compiled, after all.
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.

V2.0
Student Notebook
Uempty
Example Scenario: Hello, World!
# tar -ztvf
hello-1.0.tar.gz
hello-1.0/hello.c
hello-1.0/Makefile
hello-1.0/README
hello-1.0/hello.c: hello-1.0/README:
#include <stdio.h> (c) IBM Copyright 2002
main() This program is licensed under
{ the GPL.
printf("Hello, World!\n");
} This program prints the text
"Hello, World!" on your screen.
hello-1.0/Makefile: This is an excellent way to start
your day - some people even
all: hello consider it better than getting a
random fortune cookie every
hello: hello.c morning!
gcc -o hello hello.c
To build, simply type make
clean: To install, simply type make
rm -f hello install
install: hello
cp hello /usr/bin
Figure 5-11. Example Scenario: Hello, World! LX033.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.
Note that the "command" lines in a Makefile are indented with tabs, not with spaces.
• 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
hello.spec Preamble Section
#
# SPEC file for hello world program
#
Summary: Hello, World program
Name: hello
Version: 1.0
Release: 1
Copyright: GPL
Group: Applications/Useless
Source: hello-1.0.tar.gz
Distribution: Useless Linux 1.0
Vendor: IBM Learning Services
Packager: John Doe <john@ls.ibm.com>
%description
This program prints the text "Hello, World!" on your screen.
This is an excellent way to start your day - some people even
consider it better than getting a random fortune cookie every
morning!
Figure 5-12. hello.spec Preamble Section LX033.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.

V2.0
Student Notebook
Uempty
hello.spec Prep, Build, Install and Files Section
%prep
rm -fr $RPM_BUILD_DIR/hello-1.0
tar -zxvf $RPM_SOURCE_DIR/hello-1.0.tar.gz
%build
cd $RPM_BUILD_DIR/hello-1.0
make
%install
cd $RPM_BUILD_DIR/hello-1.0
make install
%files
%doc $RPM_BUILD_DIR/hello-1.0/README
/usr/bin/hello
Figure 5-13. hello.spec Prep, Build, Install and Files Section LX033.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
RPM Build Process
RPM needs a special directory structure for building

packages: /usr/src/redhat (RedHat) or
/usr/src/packages (SuSE)
Put all SPEC files in /usr/src/{redhat|packages}/SPECS
Run {rpm|rpmbuild} -b<stage> <spec file>
# rpmbuild -ba /usr/src/redhat/SPECS/hello.spec
... tons of messages....
Wrote /usr/src/redhat/RPMS/i386/hello-1.0-1.i386.rpm
Wrote /usr/src/redhat/SRPMS/hello.1.0-1.src.rpm
Figure 5-14. RPM Build Process LX033.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/SOURCES (on a Red Hat system) or /usr/src/packages/SOURCES (on a
SuSE system) and the SPEC file in /usr/src/{redhat|packages}/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:
rpm -bp Will only execute the %prep stage
rpm -bc Will execute %prep and %build
rpm -bi Will execute %prep, %build and %install
rpm -bb Will execute %prep, %build, %install and create a binary RPM
rpm -bs Will create a source RPM
rpm -ba Will create a binary and source RPM
Note that Red Hat, starting with version 8.0, uses the rpmbuild command instead of rpm
when building RPMs. The options are the same.

V2.0
Student Notebook
Uempty
After RPM Build Process
Source RPM located in

/usr/src/{redhat|packages}/SRPMS
Binary RPM located in
/usr/src/{redhat|packages}/RPMS/<arch>
Can use binary RPM as any RPM:
# rpm -qip hello-1.0-1.i386.rpm

Name : hello Relocations: (not relocateable)
....
# rpm -qlp hello-1.0-1.i386.rpm
/usr/bin/hello
# rpm -ivh hello-1.0-1.i386.rpm
hello ##################################################
# hello
Hello, World!
# rpm -e hello
Figure 5-15. After RPM Build Process LX033.0
Notes:
When the build process is finished, the source RPM is located in
/usr/src/{redhat|packages}/SRPMS, and the binary RPM is located in
/usr/src/{redhat|packages}/RPMS/<arch>. The binary RPM can then be queried, installed
and deinstalled as any other RPM.

Student Notebook
Integrated Package Management
redhat-config-packages yast (install and remove software)
Figure 5-16. Integrated Package Management LX033.0
Notes:
Each distribution comes with its own tools for integrated package management. Shown in
the visual are redhat-config-packages (Red Hat) and yast (SuSE). Other tools also exist,
notably gnorpm (from the GNOME project) and kpackage (from the KDE project).
redhat-config-packages and yast will automatically look for RPM files in the same place
where the files came from during installation. If your RPM files are in another location, then
you need to specify this manually. For redhat-config-packages, this is done with the -t
option. For yast, this is integrated in one of its menus.

V2.0
Student Notebook
Uempty
Keeping Up To Date (Red Hat)
"Red Hat Network" (RHN)

Free and commercial subscriptions available
Create and manage account and systems on
http://rhn.redhat.com
Register individual systems with up2date --register
Use up2date to bring system up to date, or use web
interface at http://rhn.redhat.com (requires rhnsd
daemon running on system)
Figure 5-17. Keeping Up To Date (Red Hat) LX033.0
Notes:
It is important to keep your system up to date. You can of course do this manually, by
downloading the latest RPMs from your distributors website every now and then, and then
install them using rpm -F. When managing multiple systems, this quickly will become
tedious. Because of this, distributors have created additional programs to do this quickly.
Red Hat’s solution is called the "Red Hat Network". For this to work, you need to create an
account on http://rhn.redhat.com, and register your systems with up2date --register.
From that point on, you can update your systems in two ways:
• By running the up2date on the system itself. This will check which updates are
available and, depending on the options given, download and install them automatically.
• By using the web interface at http://rhn.redhat.com. This allows you to apply updates to
multiple systems simultaneously. Managing your systems from this website requires
you to run the rhnsd (Red Hat Network Service Daemon) on each system.
The Red Hat Network is principally a commercial service, but free demo accounts are
available.

Student Notebook
Keeping Up To Date (SuSE)
you (Yast Online Update): Program that

downloads/installs patches from any SuSE mirror
Figure 5-18. Keeping Up To Date (SuSE) LX033.0
Notes:
SuSE uses a less advanced technique than Red Hat for keeping up to date. On a SuSE
system, you will find the you program (Yast Online Update). This program can connect to
any SuSE mirror (including internal mirrors you host yourself), and download and install
any available patch from there.
With you, there is no way to easily manage tens or hundreds of servers like with RHN.

V2.0
Student Notebook
Uempty
Debian Package Management
Debian uses its own package format and management

tools
Red Hat Debian
Filenames hello-1.0-1.src.rpm hello_1.0-1.tar.gz
hello-1.0-1.i386.rpm hello_1.0-1.deb
Install rpm -i dpkg -i
Upgrade rpm -U, rpm -F dpkg -i
Deinstall rpm -e dpkg -r
Query rpm -q dpkg -p
Front-ends redhat-config-packages apt-get
yast, up2date, you dselect
Package descriptor file hello.spec hello/debian/control
hello/debian/rules
Build a package {rpm|rpmbuild} -b dpkg -b,
dpkg-buildpackage
To convert between DEB and RPM packages use Alien
Figure 5-19. Debian Package Management LX033.0
Notes:
Debian and Debian-based distributions (such as Corel Linux) do not use RPM as their
package format, but use Debian packages instead. These can be recognized by their .deb
extension.
Debian packages have a different internal layout and as a consequence require different
tools too. The most important tool is dpkg, which can be compared to rpm. It is used to
install, deinstall and query packages. Debian also has a number of front-ends, including
apt-get and dselect. apt-get is comparable to up2date: It allows the user to automatically
download packages and upgrade a system over the internet. dselect is comparable to
GnoRPM or kpackage: it offers a menu-driven front-end for dpkg.
The dpkg configuration file is /etc/dpkg/dpkg.cfg, and information on packages installed
by dpkg can be found in /var/lib/dpkg/*. The apt-get configuration file can be found in
/etc/apt/apt.conf, and the list of servers that it tries to contact is in /etc/apt/sources.list.
Debian package creators use the same philosophy of "pristine sources", source packages
and so forth. Instead of having a single SPEC file though, Debian uses two different
descriptor files. debian/control contains the information about the package, such as

Student Notebook
version, description and so forth, and debian/rules is a Makefile-like file containing the
actual build instructions. To build a package, use dpkg -b, which really is a front-end for
dpkg-buildpackage. Also useful are the unpack command, for unpacking a Debian
archive, and dpkg-reconfigure, for reconfiguring a Debian package.
If you need to install RPMs on a Debian system or vice versa, you can use the Alien
package to convert between the two.

V2.0
Student Notebook
Uempty
Checkpoint
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.

Student Notebook
Unit Summary
RPM is a versatile tool for package management

An RPM can be a source RPM or binary RPM
A source RPM contains the pristine package source,
patches, sample configuration files and a SPEC file
The SPEC file contains details about the build process
A binary RPM contains the compiled code and is specific
for an architecture
Several integrated package management tools exist
Each distribution has its own solution for keeping up to
date with patches
Debian has its own package format: .deb
You can convert between .rpm and .deb using Alien
Notes:

V2.0
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, 2003 Unit 6. X Window System 6-1

Student Notebook

! =;

2# %
Notes:

V2.0
Student Notebook
Uempty
_F #"
D
2" 2-"
" #
/"
! ! " >
" 4

2 ,#
Figure 6-2. X Window System LX033.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
_+ ,"$

#
! ,
( ! ,

,(
! ,
&
,&
Figure 6-3. X - Client/Server Architecture LX033.0
Notes:
The X Window 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

V2.0
Student Notebook
Uempty • 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.

Student Notebook
<! _"

#
$B/
2-"@ 4
#

2-"@ 4 ! #

' +
/ ,
#

D2"

>>

#
!
Figure 6-4. Examples of X Stations LX033.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.
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.
• 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.
• Xnest is an X client that implements an X server. In other words: it is an X server in a
window. This is useful for testing.
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.

V2.0
Student Notebook
Uempty
_" !
# 4=;

B

@@>4=;>
B## 4
/,
@@> %>
D

@@>4>
Figure 6-5. X Servers in Linux LX033.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.

Student Notebook
_%`q
=;# <>4'
+
#

=;/ '/
+
=;1D(;' (;,1D
+
=; 1D'
1D
+
=; <'
<
+
=;)888'
%)888
+
>>>
=;# :>4B

Figure 6-6. XFree86 LX033.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.

V2.0
Student Notebook
Uempty
_%`q
!
# =;
D

/
/
0
@@((@=;! =;! ,:
!
_%`q+ " =;
+ +!`q $
"_z~D"? 3
Figure 6-7. XFree86 Configuration LX033.0
Notes:
On every system which will run the XFree86 X 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
Most monitors today are Multi-Sync monitors, meaning that they accept a wide range of
driving frequencies, and are protected against driving frequencies that would damage it.
One exception is an LCD panel, which in a lot of cases only accepts a refresh rate of
exactly 60 Hz. With all other refresh rates, the LCD panel simply will not show anything.
Because of this, most configuration tools (see below) include a description for a “Generic
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.

Student Notebook
LCD panel”, for each of the most commonly used resolutions. If you’ve got an LCD panel,
use one of these descriptions.
It used to be that you had to set up this file all by yourself, but nowadays there are several
programs available that can help you out in about 99% of the situations.

V2.0
Student Notebook
Uempty
" _
=; #

!
=; #
'
?+
#
!++
,

Figure 6-8. Starting X LX033.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 files in
your home directory. Each distribution has a different setup for determining the favorite
window manager, but fortunately it’s not really relevant how each distribution does this:
Most Linux systems will employ a display manager (covered in the next visual) which
allows you to choose your window manager.
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
X server on display ":1". When you start X via startx you need to make sure that startx

Student Notebook
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>.

V2.0
Student Notebook
Uempty
" _
2

=;
2# %

" %!,,5%

=;

! @@((@=;! ,:
Figure 6-9. Stopping X LX033.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
"
/ ,
=;
B

$=;
B
4

!

#'$+
1#' 3+
Figure 6-10. Session Managers LX033.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 desktop environment comes with its own session manager. The most common are
xdm, kdm and gdm.
The session manager is started from init in runlevel 5 (Red Hat) or with a regular System V
service script in /etc/init.d (SuSE).

V2.0
Student Notebook
Uempty
_#
! !

#!@"
! #!@" %
#
" #

!
Figure 6-11. X Networked LX033.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:
• 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
_$ #
4 =;
/

!@"
' + ' 4 +
-%
Figure 6-12. X Applications Networked LX033.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).

V2.0
Student Notebook
Uempty
$ ?,

B ' +
,
,6-,
4

,6%,
4
,

! !
!2

,
.
,
4
,$

! #

,
,/,
Figure 6-13. Applications over TCP/IP LX033.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 contact4, and <displaynumber>
the screen to use.5
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.
4
One system might be running multiple servers, although this is rare.
5
One X server may handle multiple screens simultaneously on so-called dual-headed systems.

Student Notebook
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 smartest way however is to use ssh, since this protocol has the ability to
automatically transfer the xauth record to the host, and set the $DISPLAY variable so
that all data is transmitted via a secure session. This means that the only thing you
need to do is:
ssh host xeyes
rsh and ssh are both covered in the LX07 “Linux Network Administration I”
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.

V2.0
Student Notebook
Uempty
_" #
4 =;
/
!@"

-%
Figure 6-14. X Sessions Networked LX033.0
Notes:
The visual shows the next level of networking X. 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
_" ?,

B 4

>
!
3 4 ,

3%

3 >
B
_+7 9
Figure 6-15. X Sessions over TCP/IP LX033.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.

V2.0
Student Notebook
Uempty For kdm, there are again two things you need to do:
• You need to edit /etc/kde/kdm/Xaccess (Red Hat) or
/opt/kde3/share/config/kdm/Xaccess (SuSE) 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 /etc/kde/kdm/kdmrc (Red Hat) or /opt/kde3/share/config/kdm/kdmrc
and enable xdmcp direct and indirect requests.
For gdm, the procedure is again different. Here, you only need to edit
/etc/X11/gdm/gdm.conf (Red Hat) or /etc/opt/gnome2/gdm/gdm.conf (SuSE) to enable
xdmcp direct and indirect requests.
When you're done setting up your display manager, you need to restart it. This is for
instance done by switching to runlevel 3, and then back to 5 (init 3; sleep 10; init 5).
Then, you need to start the X server on the X station. 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
"
"
/ #

* *.
/

_+ 7 9
Figure 6-16. Chooser Sessions LX033.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>

V2.0
Student Notebook
Uempty
% "
##

%
#%
=; % #
! ##
!
?(88
2-"%@
@> , 4@?(88
! @@((@@
#
=;!
=;! ,:
%.

,
.6 ,42

42
&%.

$ #

Figure 6-17. Font Server LX033.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 (xfs). 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.
SuSE, by default, does not use a font server. Red Hat configures and uses a font server on
the local system by default, which is accessible through a UNIX socket only.

Student Notebook
The specification in /etc/X11/XF86Config on a Red Hat system will thus look like this:
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 in the xfs configuration file
/usr/X11R6/lib/X11/fs/config.

V2.0
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
' "

! =;

2# %
Notes:

V2.0
Student Notebook
Uempty Unit 7. 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
- From distribution CD-ROM
- From Internet
• Patch the kernel
• Compile the kernel
• Install the kernel
• Configure the kernel and the kernel modules

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

Describe why kernel compilation is sometimes desirable
Install kernel sources
From distribution CD-ROM
From Internet
Patch the kernel
Compile the kernel
Install the kernel
Configure the kernel and the kernel modules
Notes:

V2.0
Student Notebook
Uempty
Why Kernel Compilation?
Standard distribution kernel may not be adequate

Specific hardware not supported
Too much hardware support
Consumes memory
System startup takes longer
Upgrade to newer version
Experimental/development kernel
Fun!
Figure 7-2. Why Kernel Compilation LX033.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!
Note: Most commercial distributions will only give you support if you run their unmodified
software. This means that a system running a home-compiled kernel will generally not
receive support, unless you can boot it into the original kernel, and show that the problem
exists there too. So always keep the original kernel around!
Student Notebook
Compilation Steps
1. Install kernel source

From distribution CD-ROM
From Internet
2. Create configuration file .config
3. Remove old temporary files
4. Discover dependency information
5. Compile kernel image and kernel modules
6. Install kernel image and kernel modules
7. Configure Boot Loader
8. Reboot system
Figure 7-3. Compilation Steps LX033.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, your boot loader will have to be configured so that it will boot this kernel
instead of the standard kernel. After that, reboot your system and it will boot the new
kernel.

V2.0
Student Notebook
Uempty
Installing Kernel Source
From distribution: use rpm to install the kernel sources

package
# rpm -ivh kernel-source-version.rpm
From Internet: Download linux-version.tar.gz or

linux-version.tar.bz2 and unpack in /usr/src
# cd /usr/src
# tar -zxvf /root/linux-version.tar.gz
# tar -jxvf /root/linux-version.tar.bz2
After installation, clean the tree really well to remove all

configurations changes made by the distribution builder
# cd /usr/src/linux-version
# make mrproper
Figure 7-4. Installing Kernel Source LX033.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. Installation will typically be done
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 gzipped or bzipped tarfiles (.tar.gz or .tar.bz2).
You can uncompress and untar them using tar -xzvf linux-version.tar.gz or
tar -xjvf linux-version.tar.bz2. These tar files unpack in the current directory, so make
sure your working directory is /usr/src (or, for instance, /usr/local/src or your home
directory).
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
Patching the Kernel
Changes to the kernel are typically distributed as

"patches"
A patch lists only the difference between the old and
the new version of the code; does not contain
unmodified code
Patches are generated with the diff command
# diff -u oldfile.c newfile.c > /tmp/file.diff
# diff -urN olddirtree newdirdtree > /tmp/tree.diff
Use the patch command to apply a patch to your

sourcetree
# patch -p0 < linux-dummy-patch
patching file Makefile
...
Use the -R option to remove a previous applied patch

Figure 7-5. Patching the Kernel LX033.0
Notes:
When kernel developers modify the kernel source code, for instance to fix bugs, add
support for new hardware or change functionality, they typically do not publish the updated
code, but publish their updates in the form of patch files. A patch file only lists the
differences between the old and the new code, but does not contain any unmodified code1.
This has a number of advantages:
• Other kernel developers can look at the patch file and immediately see what changes
were made.
• A single patch file can contain changes that were made to different files. This makes it
easier to apply an atomic change that impacts multiple files.
• Since patch files only contain the modified code, multiple developers can
simultaneously release changes to a single file, as long as their individual changes
don’t overlap. In almost all cases, the resulting patch files can be applied in any order,
independent of each other.
1 Not entirely true. A patch file typically contains the few lines of unmodified code that surrounds the modified code. This means that if
the line numbers don’t match exactly, the patch program can find the correct lines to patch by looking at this unmodified “context” code.

V2.0
Student Notebook
Uempty • A patch file is generally much smaller than the updated code, because the unmodified
code is not included.
As an example, the compressed Linux kernel code for 2.4.19 is about 26 MB, while the
patch to go from 2.4.18 to 2.4.19 is only about 4.5 MB.
Linux kernel developers are required to submit their patches in “unified diff” format. This is
generated with the diff -u command. To create a patch of a single file, use the command
diff -u oldfile newfile > /tmp/patch. To create a patch of a whole directory tree, use the
command diff -urN oldtree newtree > /tmp/patch.
When creating a patch of a whole Linux kernel tree, make sure that the tree is clean of any
local configuration files and object files (make mrproper). Alternatively, use the -X dontdiff
option to diff, which forces diff to ignore all files listed in the “dontdiff” file. This file is kept up
to date by the kernel developers.
To apply a patch, use the command patch -p0 < /tmp/patch. The -p0 option is used to
ignore the base directory of the tree. This ensures that you can apply a patch in
/usr/src/linux which was originally created from a tree in /root/linux, for instance.
It is also possible to remove or reverse-apply a patch. This is done using the -R option.
When patching files, patch might not always be able to find the piece of code to modify, for
instance because it has moved, or modified by another patch. In this case, patch creates
“reject files”, with the *.rej extension. These files are again in patch format, so it is usually
easy to modify these files (for instance, correct the line numbers) and run them through
patch again.
Student Notebook
Configuring the Kernel Compile
Configure all kernel compilation options

Configuration stored in .config file
Editing .config is hard...
Use the make utility instead:
make config (command line)
make menuconfig (ncurses based - much easier)
make xconfig (Tcl/Tk based GUI)
Figure 7-6. Configuring the Kernel Compile LX033.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 questions2. 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.
2
make config for kernel version 2.4.18 asks about 1200 questions, when executed on the IA-32 architecture!

V2.0
Student Notebook
Uempty If you already have a working .config file, for instance because you already compiled a
previous version of the Linux kernel, or because your distribution includes the .config file
with which the distributor compiled your current 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
Kernel Modules
Certain kernel parts may be configured as modules

Separate files in /lib/modules/<KERNELVERSION>, not
in kernel image
Module advantages:
Do not consume memory unless actually used
Drivers can be reconfigured during uptime
System boot is faster
Module disadvantages:
Loading costs a little time
Use modules only for hardware which is not needed
directly at system boot, or create an Initial RAM Disk
(initrd) containing the needed modules
Figure 7-7. Kernel Modules LX033.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 or GRUB. The kernel then loads the modules off this

V2.0
Student Notebook
Uempty initial root disk, and then mounts the proper root disk. To create an initial root disk, use the
mkinitrd (Red Hat) or mk_initrd (SuSE) command.
Note: The initial root disk is loaded into a RAM disk. Because of this, the name “Initial RAM
disk” is used as well.
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
Compiling the Kernel
Most important targets:

make clean
Cleans up old .o, .a files, and so forth
make dep
Checks dependencies
make bzImage
Compiles kernel
May take 5-60 minutes
Creates kernel image (bzImage) in
/usr/src/linux-<VERSION>/arch/<CPUTYPE>/boot
make modules
Compiles modules
May take 2-60 minutes
Can be combined: make clean dep bzImage modules
Figure 7-8. Compiling the Kernel LX033.0
Notes:
After configuration you will want to clean up the installation tree with make clean. This
means removing all the old temporary files (*.o, *.a) and kernel images.
After that, re-create the dependency files with make dep. This will take a few minutes.
Then it is time to compile the kernel itself. Do this with the make bzImage command.3 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.
3
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 on Intel systems, but can still be used on other architectures (PowerPC, S/390, ...)
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.

V2.0
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
Installing the Kernel
Copy kernel image to /boot

cp arch/i386/boot/bzImage /boot/bzImage-version
Copy System.map and .config to /boot for later reference
cp System.map /boot/System.map-version
cp .config /boot/Config-version
Install modules
make modules_install
Create Initial RAM Disk if needed
Red Hat: mkinitrd -f /boot/initrd-version.img version
SuSE: mk_initrd -k bzImage-version -i initrd-version
Configure LILO or GRUB to include new kernel
Figure 7-9. Installing the Kernel LX033.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:
• The System.map file is a file containing the location of all kernel symbols (global
variables, subroutines) within the kernel. This information is vital for kernel developers
in case of a kernel panic to determine at what location the kernel panicked.
The System.map file is also occasionally used by the kernel logger (klogd) and by the
ps command.
• The .config file is never used by any program on the system, but is useful for later
reference.
To install the modules, run the make modules_install command. This will automatically
install all modules in /lib/modules/version.

V2.0
Student Notebook
Uempty 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 disk4. This initrd is created with the
mkinitrd (Red Hat) or mk_initrd (SuSE) command, and should also be stored in /boot.
The last step is configuring LILO or GRUB so that the new kernel is included in the
configuration. When using LILO, don’t forget to run the lilo program afterwards.
4
Sometimes also called an Initial RAM Disk.
Student Notebook
Reboot System and Start New Kernel
Ctrl-Alt-Delete or shutdown -r now

Select new kernel in boot loader
Check kernel boot messages for errors
With Shift-PgUp
With dmesg
In /var/log/messages
Check functionality of kernel
Amount of memory detected
All devices working properly?
Performance?
Figure 7-10. Reboot System and Start New Kernel LX033.0
Notes:
After the kernel is compiled and your boot loader 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.

V2.0
Student Notebook
Uempty
Loading modules
Modules can be loaded manually

insmod loads a single module
lsmod lists all loaded modules
rmmod removes a single module
depmod determines module dependencies
(in: /lib/modules/version/modules.dep)
modprobe loads a module and modules it depends on
modinfo displays information about a module
Modules are loaded dynamically when the kernel discovers
it needs to, based on information in /etc/modules.conf
More information in
/usr/src/linux/Documentation/modules.txt
Figure 7-11. Loading Modules LX033.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.
Student Notebook
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
• -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 done: when the kernel finds out that it needs a module
to activate support for a device, it will load the module automatically. 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. In order to
know what module is needed for which device, the /etc/modules.conf file is used. This file
will be covered in a few pages.

V2.0
Student Notebook
Uempty
Configuring the Kernel
Certain kernel configuration options can be set after

kernel compile
Some possibilities for configuration:
When kernel image boots
Amount of Memory used
Root filesystem to mount
When modules are loaded
Hardware present, hardware settings
Through /proc/sys mechanism
Software functions, such as IP forwarding
Figure 7-12. Configuring the Kernel LX033.0
Notes:
The .config file only configures the kernel compilation process, and is not used afterwards.
But once the kernel has been installed, we might need to do more configuration. This
typically pertains to the hardware environment the kernel has to run in, and various
software options within the kernel.
This configuration can take place in three different stages:
• When the kernel boots, through kernel boot parameters
• When modules are loaded, through the module loader interface
• Through the /proc/sys mechanism, when the kernel and modules are running
Student Notebook
Sidestep: Device Configuration
Every device needs an IRQ line and an I/O address to

communicate.
Some devices may benefit from DMA
The Linux kernel is capable of configuring Plug 'n' Play
devices (PCI and ISA PnP) automatically
Non-PnP devices need to be configured manually
through jumpers, dip-switches or NVRAM settings
If you've got multiple, identical devices, use IRQ and I/O
addresses to tell them apart
Figure 7-13. Sidestep: Device Configuration LX033.0
Notes:
Every device on the system needs to communicate with other devices, particularly with the
CPU and the memory. On an Intel platform, this is done by way of an IRQ (Interrupt
ReQuest) and an I/O (Input/Output) address:
When a device, such as a network adapter card, wants to communicate with the CPU, it
stores the data it wants to communicate at a special memory-mapped I/O address5. It then
signals the CPU that data is waiting by sending it an interrupt via the IRQ line. The CPU
interrupts whatever it is doing (hence the name interrupt), copies the data from the I/O
address to its proper location and then continues its regular work.
The same mechanism is used when the CPU wants to communicate with the adapter card.
High-bandwidth devices such as disk controllers can also benefit from Direct Memory
Access: using a special DMA channel they get access to a special, reserved memory area.
This memory area is typically far larger than the memory-mapped I/O area and thus
requires far fewer interrupts to transfer large amounts of data.
5
A memory-mapped I/O address means that the memory on the adapter card is mapped into the main memory region. If the CPU
accesses this memory area, it is not handled by the main memory, but by the memory on the adapter card.

V2.0
Student Notebook
Uempty It used to be so that each and every device needed its own IRQ and I/O address. This
effectively limited the number of devices in a PC to about five to eight or so. Today, under
certain conditions, certain devices may share an IRQ. But still, all these IRQs, I/O
addresses and DMA channels need to be configured properly.
In the early days of the PC, when all PCs used ISA buses and devices, you had to
configure all devices manually. This was typically done using dip switches, jumpers or
special configuration programs. The PCI standard changed all this, by introducing a
technique called “Plug ‘n’ Play”, or PnP for short. PnP is a mechanism whereby every
device can identify itself to the BIOS or the Operating System with a manufacturer ID, a
device ID and a list of its possible configurations. Depending on the BIOS setting “Plug ‘n’
Play OS [y/n]”, the BIOS or the OS will then configure all devices so that they don’t conflict
with each other.
PnP has been ported to ISA devices as well. This technique is called ISAPnP. However,
since a BIOS generally can’t configure these devices, this had to be left to the Operating
System.
Initially, the Linux kernel was not capable of handling PnP devices. This was handled in two
ways:
• PCI devices (which are by definition PnP) were configured by the BIOS. This was
achieved by setting the BIOS parameter “PnP OS” to No.
• ISAPnP devices were handled by two user-space tools: pnpdump would create a file
/etc/isapnp.conf which contained all devices and all their possible settings. By
uncommenting the correct IRQ and I/O statement in the file you could create a
non-conflicting situation manually. When the system booted, the program isapnp was
called automatically, typically from rc.sysinit. isapnp would then configure all ISAPnP
devices according to the configuration in /etc/isapnp.conf.
With the 2.4 kernel however, this scheme is obsolete. The 2.4 kernel contains full support
for PnP devices, including ISAPnP.
Student Notebook
Configuring the Kernel at Boot Time
Done by adding arguments to the kernel line in the boot

manager
LILO: use "append" statement
GRUB: add to "kernel" line
Examples:
mem=128M Identify amount of memory to kernel
root=/dev/hda3 Identify root FS to mount
ro Mount root FS readonly
init=/sbin/init First program to run
hdc=ide-scsi Use hdc as emulated SCSI device
vga=ask High-resolution text mode selection
For more information see
/usr/src/linux/Documentation/kernel-parameters.txt
Figure 7-14. Configuring the Kernel at Boot Time LX033.0
Notes:
The first way of configuring the kernel is when the kernel itself boots. Just like any other
program, the kernel accepts arguments to its “command line”. However, since the
command line of the kernel can’t be accessed directly, you need to work with your boot
loader to achieve this:
• For LILO, kernel arguments can be added to the “append” statement. An /etc/lilo.conf
stanza for the kernel then looks like this:
image=/boot/bzImage-2.4.18-Test
label=new
root=/dev/hda3
read-only
append="mem=128M"
In this case, mem=128M will be used as one of the kernel arguments6.
6 In fact, the other two arguments are root=/dev/hda3 and ro, so we could have said append="root=/dev/hda3 ro mem=128M" and
then leave out the separate root=/dev/hda3 and read-only lines.

V2.0
Student Notebook
Uempty • For GRUB, you can add kernel arguments directly on the “kernel” line. An
/etc/grub/menu.lst stanza for the kernel then looks like this:
title new
root (hd0,0)
kernel /bzImage-2.4.18-Test ro root=/dev/hda3 mem=128M
There are several parameters that can be useful here. Some of these, and their usage, are:
mem=128M Disables the auto-detection of memory and limits the amount of
memory used to the amount indicated. Note that the capital M
(for Megabytes) is required: else the kernel tries to use 128
bytes, which immediately leads to a kernel panic.
This parameter can be used, among other things, in the
process of sizing a system: trying out the amount of memory
that a production system can get by with.
root=/dev/hda3 This identifies the root filesystem to be mounted. This is
normally set up correctly and should not be changed. It can be
used however if you want to boot your system using a Linux
kernel on a floppy disk.
ro This is again a standard value. It ensures that the root
filesystem is mounted read-only. That makes it possible for the
bootup scripts to perform an fsck on the filesystem. The bootup
scripts then do a remount to mount the filesystem read-write.
init=/sbin/init This identifies the program that should be started first, as soon
as the kernel finishes booting. Normally, this is /sbin/init, but if
that program is corrupt, or /etc/inittab is corrupt, you can also
specify, for instance, init=/bin/bash. This gives you a bash
prompt immediately, and allows you to do recovery of init and
/etc/inittab.
Note however that specifying init=/bin/bash performs no
startup scripts whatsoever. This means that only the root
filesystem is mounted, read-only. You will have to do a remount
to read-write of the root filesystem, and possibly mount other
filesystems as well, in order to do something useful.
hdc=ide-scsi This means that the ide-scsi module is used to handle the hdc
device. The ide-scsi module is a special module which uses an
IDE disk to emulate a SCSI disk. This is not required for regular
disk drives and CD/DVD players, but is a requirement for
CD-Writers, since the cdrecord program can only handle SCSI
CD-Writers.
After the kernel has booted, the CD-RW is now available as
/dev/scd0 instead of /dev/hdc.
Student Notebook
vga=ask Ask the user what high-resolution text mode to use. This will
presented through a menu of possible resolutions. If you found
a resolution that suits you, then you can also configure that
resolution as default by using vga=<identifier>.

V2.0
Student Notebook
Uempty
Configuring Modules at Load Time
Specify in /etc/modules.conf
# cat /etc/modules.conf
alias eth0 eepro100
alias eth1 eepro100
options eth0 irq=9
options eth1 irq=10
alias identifies the module which implements a device

options are specific for each module
Use modinfo to obtain specific information
pre-install, install, post-install execute scripts when
loading a module
pre-remove, remove, post-remove execute scripts
when unloading a module
Figure 7-15. Configuring Modules at Load Time LX033.0
Notes:
When modules are checked for dependencies with depmod and when they are loaded
with modprobe, the options from /etc/modules.conf are 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 eth0 device, the kernel
automatically loads the eepro100 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 Ethernet cards
as in the example. The options line is then used to distinguish them from each other.
Other uses of the options line exist as well. As an example, you can use them to force
Ethernet cards into full-duplex mode, or force Token-Ring cards to a ringspeed of 16
Mbps.
Student Notebook
For specific information about the options that a module supports you will need to run
modinfo -p <modulename> or dig into the source. (Most modules have a list of
possible options right at the start of the source code.)
• 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.
Although most distributions do not use it, it is also possible to put an include statement in
the modules.conf file, which ensures that other files (typically located in /etc/modules.d) are
included. This helps keep your modules.conf file clean.

V2.0
Student Notebook
Uempty
Configuring the Running Kernel
Certain kernel settings can be changed while running

All these settings have an entry somewhere in /proc/sys
Example: Setting up IP-Forwarding
# cat /proc/sys/net/ipv4/ip_forward
0
# echo 1 > /proc/sys/net/ipv4/ip_forward
sysctl command gives easy interface to this
# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
# sysctl -w net.ipv4.ip_forward=0
net.ipv4.ip_forward = 0
The sysctl -a options prints out all current settings, the -p option
reads settings from the /etc/sysctl.conf file (done at startup)
Figure 7-16. Configuring the Running Kernel LX033.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.
These changes however are not persistent. Because of this, the sysctl utility has been
created which can do this for you: it allows you to store all settings in a file, usually
/etc/sysctl.conf. As part of the bootup scripts, the sysctl -p command is executed. This
reads all settings from /etc/sysctl.conf and applies them.
With the sysctl command you can also list and change settings manually, but this is not
often used.
Student Notebook
Checkpoint
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.

V2.0
Student Notebook
Uempty
Unit Summary
Why kernel compilation

Installing kernel sources
Compiling the kernel
Installing the kernel
Configuring the kernel
Notes:
Student Notebook

V2.0
Student Notebook
Uempty Unit 8. Character Devices, PCMCIA and USB

This unit describes character devices and the workings of the PCMCIA
and USB subsystems.

After completing this unit, you should be able to
• Describe the main characteristic of a character device.
• Configure serial, parallel and PS/2 ports
• Configure a sound card
• Describe the PCMCIA subsystem
• Describe the USB subsystem

Accountability:
• Checkpoint
© Copyright IBM Corp. 2001, 2003 Unit 8. Character Devices, PCMCIA and USB 8-1
Student Notebook

#>
!
@7

!
!/!"
2 5
Notes:

V2.0
Student Notebook
Uempty
&
*!#* #

* *'*%*+
34

! '% +

$
-#
Figure 8-2. Character Devices LX033.0
Notes:
As you may know already, any device on a Linux/UNIX system is either characterized as a
“character device” or a “block device”. The difference between these is that a block device
allows random seeks, and a character device doesn’t: a character device can only be read
from and written to serially.
A lot of devices in Linux are character devices:
• The console itself
• Any serial terminals that are attached to the system. (A serial terminal is a combination
of monitor and keyboard, which is attached via a serial cable to a serial port.)
• Printers
• Sound cards
• The random number generator
• The null device, which is typically used to discard unwanted data
Student Notebook
&
##
@#
0, !
.+ # 9. ! .,
.+ 19. ! ,6
.+ 6) 9. ! 6
.+++ 19. !
.+ 9. ! 6,
.+ 9. !
.++ 9. ! -
.++ .6)9. ! -%
.++ 9. !
.+++ #9. ! "
Figure 8-3. Character Device Naming LX033.0
Notes:
All character devices have a representation in /dev. As you can see, the permission fields
as shown by ls -l all start with a “c”, which indicates a character device.

V2.0
Student Notebook
Uempty
>&
*-*#

@#@ 5%E

@#@&"
&
*$ *#
@#@ 3

,%

@#@ 3

,

,

34
!
'<7/5+
0
! " 6 ,+6
;, 3.1
Figure 8-4. Virtual Character Devices LX033.0
Notes:
On any Linux system, there are four virtual character devices: Devices that have a
representation in /dev, but don’t have matching hardware.
These devices are:
/dev/null Used as the “bit bucket”, to discard unwanted output of a
command or script. Example: find / 2> /dev/null
/dev/zero Used as an infinite supply of binary zeroes: If you do a cat
/dev/zero, the output will be all ASCII character 0’s.
Unfortunately, this is an undisplayable character, so you need
to do hexdump -v /dev/zero to see anything at all.
/dev/zero is typically used to create large, empty files. The
following command, for example, creates a 1M file:
dd if=/dev/zero of=bigfile bs=1M count=1
Student Notebook
/dev/random Truly random numbers are really important in the field of

computer security. It is really hard to generate truly random
numbers on a “deterministic device”1, such as a computer.
In the past, programs requiring random numbers have always
used pseudo-random numbers, and each program had its own
implementation to generate these. This has caused a lot of
security problems.
To solve this, Linux implements the /dev/random device, which
holds a large number of random numbers (called the “entropy
pool”). These random numbers are truly random, and are
derived from random events in the outside world, such as
mouse movements. It is for instance really illustrative to do:
hexdump /dev/random
And then move the mouse.
/dev/urandom The problem with /dev/random is that the entropy pool is
generally not overly large: after a few hundred to thousand
random characters the entropy pool is empty. If a program
requires more than this amount of randomness, it should have
to wait before someone moves the mouse. Obviously, mouse
events are rare on a heavily loaded server in a computer room.
To solve this problem, /dev/urandom was introduced. This
device generates truly random numbers as long as the entropy
pool is not empty, but starts generating pseudorandom
numbers (based on the earlier random numbers) as soon as the
entropy pool is empty.
1
A deterministic device is a device which always gives the same output when presented with the same input.

V2.0
Student Notebook
Uempty
"& ~
"&
@#@ 8@#@ (

!B/( !B/7
/

*
*#
>>!
#
#
" ' , +
" -@#@"8@#@"(>>>

'"$¡"@B2$
+

0,,
! -%
6 1 )##
5 >

>
Figure 8-5. Serial Devices, Modems and ISDN LX033.0
Notes:
The devices /dev/ttyS0 and /dev/ttyS1 represent the serial devices COM1 and COM2,
respectively. In some documentation you might still find references to /dev/cua0, /dev/cua1
and so forth. The usage of these devices is deprecated: it still works, but you should not
use them anymore. The reason is that the ttyS* devices support locking and cua* devices
do not.
Serial ports are typically used to connect modems to your system, so that you can connect
to an ISP, or that others can dial-in to your system, typically using the PPP protocol. (This is
covered in the LX07.)
Using special “multiport” cards, you can add more serial devices to your system (up to 128
in most implementations). This is particularly useful if you are an ISP and want to connect
lots of dial-in modems to your systems. Multiport cards are for instance manufactured by
Cyclades.
Certain devices create other serial ports too. There are two devices where this is
particularly true:
Student Notebook
• Internal modems. These modems have an ISA or PCI form factor so that they can be
built into the actual computer case. A true internal modem will configure itself so that it
acts as a separate COM3 (/dev/ttyS2) or COM4 (/dev/ttyS3) serial port. However, most
internal modems today are so-called “winmodems”, which do not truly implement a
serial port with attached modem, but rather require a special driver to operate. This
driver then uses the CPU for modulation and demodulation, instead of having a special
modulation/demodulation chip itself.
Most manufacturers of winmodems only release drivers for Windows operating systems
(hence the name Winmodems). To the best knowledge of the author, only Lucent
(Lucent winmodem) and IBM (MWave) have released information and/or drivers for
Linux. Using these modems is still far from trivial, however: You typically need to
compile, configure and run a special daemon under Linux to be able to use your
modem.
• ISDN cards. ISDN cards are not “modems” since they do not do modulation and
demodulation. Instead, they are properly called “network adapters”. Their device
representation thus is /dev/isdn0, /dev/isdn1 and so forth.
Most dial-up software however is not able to work with such adapters, and Linux
therefore implements a number of pseudo-modem devices called /dev/ttyI0, /dev/ttyI1
and so forth. These pseudo-modems accept the regular Hayes compatible AT
command set, and thus can be used by all dialer programs2.
The first four serial devices on a system are by default configured by the Linux kernel, who
detects the UART type and sets IRQ and I/O parameters correctly. If you have more than
four serial devices, you can set their UART type, IRQ and I/O parameters manually with the
setserial command.
Another reason why you might want to use setserial is to configure a higher bps rate than
usual, such as 115.2 Kbps. This is for instance required when you’ve got an external ISDN
modem.
2
The only difference is that these modems generally require the use of the AT&E command to set the MSN (Multiple Subscriber
Number).

V2.0
Student Notebook
Uempty
"?
#

"5/<((
!
' +

4@@
0. .

;

% 4 1#4,6+4 ,;
$-) -% !
41#4,6+4 , ,;
$-,1

* 4 9 8<=:88*

Figure 8-6. Serial Terminals LX033.0
Notes:
Serial Terminals (sometimes called “dumb terminals”) are devices which combine a
keyboard and a monitor into one device, and are connected to the system via a serial cable
to the serial port. Depending on the model, you may need a null-modem cable or a straight
cable. The serial cable may involve modems as well, allowing you to do easy remote
management of the system. Serial terminals are not used often anymore, but can be useful
since it allows you to have a console attached to the system over a long distance, without
requiring a network. And serial consoles are really useful in large clusters, because they
require less cabling than KVM switches.
A serial terminal can be anything from the IBM 3151, a PC with terminal emulation software
(such as minicom) or a hand-held PDA with terminal emulation software.
To configure a serial terminal under Linux, you need to run a “getty” on the serial port. This
is most commonly done from /etc/inittab, and the getty most often used for this in Linux is
mgetty.
Student Notebook
mgetty will automatically configure a modem for dial-in. If you’re running mgetty directly
on a serial cable, without a modem involved, use the -r option to prevent modem
initialization.
Linux also supports having the console on a serial port. This means that you can run Linux
on a box without a graphical adapter, which is really useful in large clusters. To force Linux
to use a serial port as console, even if a graphical adapter is present, use the boot option
console=ttyS0. The default settings on the serial port are 9600,8N1. To change these
settings you can add options to the console boot option. In addition to this, you can also set
LILO to use the serial port as console. For more information, see the file
/usr/src/linux/Documentation/serial-console.txt.

V2.0
Student Notebook
Uempty
",z
@#@
8@#@
(( 7

@#@
4 @7
' %+
Figure 8-7. Parallel and PS/2 Ports LX033.0
Notes:
/dev/lp0 and /dev/lp1 represent LPT1 and LPT2, respectively.
/dev/psaux represents the PS/2 port used for your mouse.
Student Notebook
"

% #@#@
>
4
B ,B
' %
+,$
,# 4 '

# % +,
3
!

>5

$, ,
3
Figure 8-8. Sound Cards LX033.0
Notes:
When a sound card has been detected and activated, the kernel activates the /dev/dsp
(digital sound processor) interface. This interface accepts multiple simultaneous streams of
sound data, so that multiple applications can send their output to the sound card together.
Sound card support is built-in in the Linux kernel and thus requires only that the correct
kernel modules are loaded. However, the sheer number of sound cards available on the
market today has lead to an equally large amount of kernel modules. For this reason it is
usually best to configure a soundcard using a special administration tool such as alsaconf,
yast (SuSE) or redhat-config-soundcard (Red Hat).

V2.0
Student Notebook
Uempty

$ '"
!/!"'%!5+ 2 5#

#%
B!/!"'(;,+
!5'<7,+ 2 5%
@ @

#
##'!/!"+
'2 5+
0,,;
(, !
. 4 4
(, !
. 4 4
0..,,
%. 4
# );

.
48-:
%. 4
.
Figure 8-9. PCMCIA and USB LX033.0
Notes:
Both PCMCIA (also known CardBus)3 and USB devices are detected by modern 2.4
kernels automatically. If the kernel has support for the particular device, then it is
configured and activated automatically.
For historic reasons, PCMCIA devices require the presence of the cardmgr daemon, who
uses configuration data in /etc/pcmcia (particularly the *.opts files) to configure a device
properly (this might change in the future).
CardBus and USB devices use the PCI hotplug interface: The kernel first activates the
device, and then calls the /sbin/hotplug script for user-space configuration. The same
happens when the device is removed. In the future, when systems are available that
support hot-pluggable PCI cards and other hot-pluggable devices, they will use this
mechanism too.
Obviously, removing a device which is in use might lead to problems such as dropped
connections, corrupted data and so forth. It is therefore a good idea to manually deactivate
3
Technically, all 16-bit cards are PCMCIA devices, and 32-bit cards are CardBus cards. From the outside, CardBus cards can be
recognized by 8 little notches on the top of the connector, while a PCMCIA card is flat.
Student Notebook
network interfaces, unmount filesystems and so forth, before removing the hot-pluggable
device which implements this network interface or filesystem.
Information on USB and CardBus devices can be obtained from the /proc/bus/usb and
/proc/bus/pci virtual filesystem, respectively. The usbview and lsdev commands are
deprecated and no longer present in most distributions, and the same applies to the
/etc/usbmgr configuration directory.
In order to list the modules that are required for supporting a specific USB device, use
usbmodules <device>. In most cases, this will include one of the modules usb-uhci.o
and usb-ohci.o, depending on the type of USB controller you have.

V2.0
Student Notebook
Uempty

1) T/F A character device allows random "seeks".
2) What is the difference between /dev/random and

/dev/urandom?
3) What script is used for configuring all hotplugged devices?
Notes:
Write your answers down here:
1)
2)
3)
Student Notebook
' "
!##

E
34
# %

#,, E

!/!"2 5 ,
#
, ,

Notes:

V2.0
Student Notebook
Uempty Unit 9. 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, 2003 Unit 9. Block Devices, RAID and LVM 9-1
Student Notebook

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

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

V2.0
Student Notebook
Uempty
&
*5%#* #

'*%*+ # *%*
# &>
%
(7<:;?=
8(7:8);

%#
%'
+

%
1%#'$" 1/+
Figure 9-2. Block Devices LX033.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
&
%##

@#
0, !
;++ 66- $ !
;++
,1 $ !
;++
, $ ! ,
8(>>>
%' 4=+

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

V2.0
Student Notebook
Uempty
%&

% &

& '# +

0 !

;,
., ,. ..6.
- (

$

-
$
-
%

#'4
@#@87==8+
Figure 9-4. Floppy Disks LX033.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%' @#+
/47

/47

!,$B/'"+
# @#@>>>
! "' !
" +

,>>>
/4?(% '

+
-
D 4
# "3

!,$B/
&
#>>>
# @#@>>>&>>>4
Figure 9-5. Hard Disks LX033.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.
IDE device numbering is based on how the device is connected:
• The master on the first bus on the first adapter is hda
• The slave on the first bus on the first adapter is hdb
• The master on the second bus on the first adapter is hdc
• and so forth.

V2.0
Student Notebook
Uempty 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
multiple SCSI adapters may be used simultaneously.
SCSI device naming is largely based on the SCSI ID: The SCSI drivers will detect and
activate each and every adapter and SCSI bus in turn, and subsequently activate each
device on that bus starting with the lowest SCSI ID. This number can be manipulated,
typically by setting a jumper combination, dip switch combination or rotary dial. All devices
are assigned a device entry in the order in which they were detected. So the first drive
detected becomes sda, the second device becomes sdb, and so forth.2 Obviously, the first
drive detected is also used as the boot device.
Obviously, it is of the utmost importance that no two SCSI devices on the same bus have
the same ID number. This can be checked by looking at the output of the dmesg
command, or by entering the SCSI BIOS when the system boots. Note that the SCSI
adapter always needs one ID for itself too.
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.
Information on your SCSI devices can be obtained from the /proc/scsi directory, and with
the command scsi_info <device>.
2
This causes a problem if new disks are inserted with IDs lower than the existing drives. Suppose you’ve got one SCSI bus with two
disks connected to it. The disks use ID 3 and 6, respectively, and are named sda (device with ID 3) and sdb (device with ID 6). If you
were to add a disk with ID 5, then this new disk becomes sdb, and the disk with ID 6 becomes hdc. This might lead to boot problems,
particularly when the disk partitions need to be fsck-ed and mounted, and their names (/dev/hdb1, for instance) are hard-coded in
/etc/fstab, instead of using ext2 filesystem labels.
Student Notebook
;&
"3 ! "%

/4

B

4

4

' 4 4)"3(( ! "+
% /5$

(

)
)
7

4

4
4@
@
;
4
4@ @
?
4

4
Figure 9-6. Hard Disk Partitions LX033.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.3
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.
3
Most of the earliest IBM PCs came without a hard disk and only had one 5.25" floppy disk of 360 KB...

V2.0
Student Notebook
Uempty 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
subdevices. One is used for the device itself, four for the primary partitions, which leaves
11 for the logical partitions.
Student Notebook
?
/
! B @
¡
! @&@ #@

B
4
!
4

%
1#!B *%*

B
B @7 4>>>

D 4
#> >
! @&@ #@

%

4

Figure 9-7. Partitioning Tools LX033.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.

V2.0
Student Notebook
Uempty
$&
$/%%#

&

4

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

$/%
0
! " ! ;, .
0.! ! .
0! !
+ # 1 4#4 . 6,,+
+ 1 4#4 . $6

0
, !
Figure 9-8. RAM Disks LX033.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.
Student Notebook
?@@&
*
*#%#
4
4 (;
#
06;

$ 66-
06%%&
,
.
Figure 9-9. The "loop" Device LX033.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.

V2.0
Student Notebook
Uempty
> 45
%
#
#
1
& #

& %&
1 / #
#
B 1 '%
+
1 D
'1D+
1 '1+

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

%
& 13
&1D1
Figure 9-10. Logical Volume Management (1) LX033.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.
Student Notebook
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).

V2.0
Student Notebook
Uempty
> 4z5

#
#
'%
+ '%
+
3 3 3 3 3 3
3 3 3 3 3 3
3 3 3 3 3 3
#
#
Figure 9-11. Logical Volume Management (2) LX033.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.
Student Notebook
>
#
% @

'
84=+
4 %
" &
# '%
+
6!. ! 1
6!. ! ;
!#
*#88*
#
!$.!$ ! 1 ! ;
!# *#88* #
!.# 3! !$
! ,,,%#
Figure 9-12. LVM Implementation Overview LX033.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.

V2.0
Student Notebook
Uempty
>
79
" &
#
'
+
1 D

1
1D'> 3
&
$+
+ 797 97 9

/#3 1 1 #

79

1
Figure 9-13. Physical Volume Commands LX033.0
Notes:
Three commands allow you to manage your physical volumes:
pvcreate This command initializes a physical volume. Among other things, this
means that a Volume Group Descriptor Area (VGDA) is added at the start
of the PV. This VGDA will later contain LVM information, such as the size of
the physical extents.
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.
Student Notebook
>3
+ 7 97 97979

!#
1 D
'1D+

1 '1+ 1 '1+ 1 '1+
79

#
79
#
Figure 9-14. Volume Group Commands LX033.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.
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.
vgremove This command deletes a volume group.

V2.0
Student Notebook
Uempty
>
+7 9+ 7 97979

!# #
1 '1+ 1 1 1
1 D
'1D+

1 '1+ 1 '1+ 1 '1+
7979

#
7979
$ ##
Figure 9-15. Logical Volume Commands LX033.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.
lvremove This command removes a logical volume.
Student Notebook
" >
1

1

0!.1 3
-,
6!!$

#
#
'%
+ '%
+
3 3 3 3 3 3
3 3 3 3 3 3
3 3 3 3 3 3
#
@#@#88@
#
Figure 9-16. Striping Logical Volumes LX033.0
Notes:
Logical Volumes can be striped. This means that the logical volume is spread out over
several disks. This greatly increases performance for large data transfers, especially if the
disks are attached to separate controllers as well.
A slight disadvantage of striping is that if any of the disks involved fails, then your LV is lost.

V2.0
Student Notebook
Uempty
<! , >3
#1
1 D
#4 #

#34 1

# #
0!$!$ ! .)

0!$.!$ ! ,#
&94..!$6!$ ;-,6-,
.
! ! ,#
06!! ! ,# ! .)
0!$.!$ ! ,#
Figure 9-17. Extending/Reducing a Volume Group LX033.0
Notes:
After a while you will find that the original LVM scheme that you created when you installed
the system is not suitable for your needs anymore. With the traditional partitioning scheme,
you needed considerable downtime of your system to rearrange your partitions.
With LVM, you can add disks to the system and then, while the system is running, add
these disks to volume groups. You can then migrate physical extents to this new disk, and
take the old disk out of the volume group. All this while the system is running: You don’t
even have to unmount the logical volumes involved.
Extending a volume group with a new physical volume is done with vgextend. Moving
physical extents from one physical volume to another is done with pvmove, and reducing
the volume group is done with vgreduce.
Student Notebook
<! , >

4 @ %1
#4 @#
2,

&
2,

& 3
! @-B4 @ %
1
'34 @ % #+
0!/1 3 ! !$ -!
!
$
!,
"66-,
.;-
!
$$
.! ! !$ -!1 3(
!
$
.;.6!$6,-,
!$
.! ! !$ -!,..,,-
0!. ! ,-, -,
6!

Figure 9-18. Extending/Reducing a Logical Volume LX033.0
Notes:
Just like we could extend a volume group, we can also extend logical volumes. This is done
simply by adding physical extents at the end of the logical volume, or taking them away
from the end. The commands for this are lvextend and lvremove.
Important note: If you extend or reduce a logical volume with lvextend and lvremove,
then you are not automatically enlarging or shrinking the filesystem inside. This is a
separate step and will be covered in the next unit.

V2.0
Student Notebook
Uempty
>
"#
#1/
1D# >
(>#%
1D 1D 1D
@@# @# >

7>#, # >
1D 1D 1D
Figure 9-19. LVM Backup and Recovery LX033.0
Notes:
When backing up your system, it is vitally important to save the LVM metadata (which is
stored in the VGDA) as well. (Just as it is equally important to save the partition table of a
system when doing a backup.)
Creating a text file that contains the LVM metadata is done with the vgcfgbackup
command. The resulting text file, /etc/lvmconf/<vgname>.conf can be archived just like any
file.
In the event you need to restore your system, you can create your LVM configuration with
the vgcfgrestore command. Obviously, you also need to restore the data stored in your
logical volumes as well in that case, but that’s another topic.
Student Notebook
$ >
41/
*
*

! %

1/ ,,
"1/, @@
1/

2 %1/
41/

'C+
Figure 9-20. Additional LVM Considerations LX033.0
Notes:
There are several considerations when working with LVM:
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.
Kernel information about LVM can be obtained from the /proc/lvm tree.
When you have filesystems on an LVM Logical Volume, and these filesystems are listed in
the /etc/fstab file to mount them automatically, make sure that the LVM module (“lvm-mod”)
is included in the Initial Root Disk (initrd).
Unlike other LVM implementations (like AIX), the Linux LVM implementation does not (yet?)
support mirroring.

V2.0
Student Notebook
Uempty
$
&
*$ " 4
#%*

!%
4
#
,.%

>>>4
#
"2
%
#

>>> # 4
#
Figure 9-21. RAID LX033.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.
Student Notebook
$
& 45
$", $",8

$",(
( ; ( 7 ( (
7 ? < : 7 7
< = ; < <
: ) ? = : :
(8 ) (8
$",:

% $",

( 7
( 7
< :
<
:
;

;
? =
? =
) (8
)
(8
Figure 9-22. RAID Levels (1) LX033.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

V2.0
Student Notebook
Uempty 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.4
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 information5 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.
4
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.
5 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.
Student Notebook
$
& 4z5
$"##

$", ** $",(
2$"#
$" / $
,
, $
B %
# % '6+ '6+ <4(D%
7 . . <D ! %&
.
8 7 <D
( 7 (D ! -,(%

: < 7D ! (%
% %
< 7D ! (%
!2 #
'6+
% %&
Figure 9-23. RAID Levels (2) LX033.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.

V2.0
Student Notebook
Uempty
!$
&"
$"
"
4%
-
%
2%
$"#
# ,,
$"
"

4%
D

' # 4+
$"#
! "%
Figure 9-24. Linux RAID Support LX033.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.
Student Notebook
!"#$
&
45
!$"

!' 4$"+
!,,
0. .
;

! !

!

,,
6,
,,6;.
.,
"
!
. !

,
!
. ! ;

,
Figure 9-25. Linux Software RAID Implementation (1) LX033.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.

V2.0
Student Notebook
Uempty
!"#$
&
4z5
" &$"# %@#@ 8

$"#@#@ 8
@#@ 8 %#
0, !

0 !

4

Figure 9-26. Linux Software RAID Implementation (2) LX033.0
Notes:
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
F $
&
$"

0. 6. ,
,

,4 8
:8
#:
,.,
4 .
!
# ,. 8: ,; 8 : , 81:, 8 :
)11;.,!#1.$
8 :8:
,!
.,47
*2* #

>"
#** 1

Figure 9-27. Watching a Running RAID LX033.0
Notes:
To check the health status of your RAID subsystem, view the contents of the /proc/mdstat
file. This contains all the information you need.
Particularly important are the letters between the square brackets. These signal the health
status of each of the disk or disk partitions that make up a RAID volume. A “U” means that
the device is up and running normally, but an “F” means that the device failed. You should
investigate this and possibly replace the device as soon as possible.

V2.0
Student Notebook
Uempty
"&
%$"(@$" %

%
0. .
;

,6
,,
!
. ! ,
,6
,

%

%%#>>>
Figure 9-28. Spare Disks LX033.0
Notes:
To make a RAID-1 or RAID-5 configuration more fail-save, you can add spare disks. These
disks sit idle until one of the active disks fails. The spare disk is then used in place of this
active disk.
For a RAID-1 volume, this means that the spare disk is now being mirrored with the other
disks. For a RAID-5 volume, this means that the parity information, together with the data
remaining on the other disks, is used to re-create the data that is now lost.
You may wonder why a RAID-1 configuration can benefit from spare disks, while this disk
can also be configured to perform continuous mirroring anyway. The reason is simply
performance: keeping disks mirrored costs time. It is faster to have two mirrored disks and
one spare, than to have three mirrored disks.
Student Notebook
$ $
&
$"
%
2 ! ""3

%
$"#
$"@

"$", @@
$"

$",: $", !2
$", $",8

4%

Figure 9-29. Additional RAID Considerations LX033.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 any other
filesystems listed in /etc/fstab (that are mounted automatically), you need to include the
RAID modules (“linear”, “raid0”, “raid1”, “raid5” and/or “xor”) in your Initial Root Disk (initrd).
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.

V2.0
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.

V2.0
Student Notebook
Uempty
' "
5%##

5%#%%

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

**
1 /

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

V2.0
Student Notebook
Uempty Unit 10. 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, 2003 Unit 10. Filesystems 10-1

Student Notebook
Objectives

Describe what a file is
Describe what a filesystem is
List possible filesystems
Describe inodes
Create/mount/unmount filesystems
Create predefined mounts
Set up user and group quota
Notes:

V2.0
Student Notebook
Uempty
What is a File?
Consecutive number of bytes

No internal structure by default (applications define their
own structure)
Stored and referenced in a filesystem
Can have multiple references (names)
Special files exist
Block, Character -> Device
Pipes, Sockets -> Interprocess communication
Figure 10-2. What is a File? LX033.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
What is a Filesystem?
Place to store files and refer to them

Hierarchical structure through use of directories
A filesystem can be stored on any block device
Floppy disk
Hard disk
Partition
RAID, LVM volume
File (for use with a loop device)
RAM disk
/usr /lib /etc /bin /var /sbin
Figure 10-3. What is a Filesystem? LX033.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.

V2.0
Student Notebook
Uempty
The Virtual Filesystem Switch
user or system programs

vi ls mv rm file strings cat touch ...
file oriented system calls

open() read() write() close()
VFS abstraction layer
ext2/
reiserfs iso9660 vfat
ext3
Figure 10-4. The Virtual Filesystem Switch LX033.0
Notes:
Linux supports a large number of filesystems. You will find a full list on the next page. All
these filesystems have their own way of storing data and metadata on disk. However, a
typical user is not interested in the internal workings of these filesystems, but needs a
single way of dealing with them all. That is the job of the VFS (Virtual Filesystem Switch)
abstraction layer.
Typical user programs such as vi, ls and others use four primitive system calls to work with
files: open(), close(), read() and write(). (There are a few others for working with
directories, permissions and so forth.) These system calls are translated into the
appropriate, filesystem-specific system calls by the VFS layer. Because of this, a user is
presented with a uniform interface to each filesystem.
Note that the VFS layer emulates certain features if the filesystem does not support these.
For instance, Linux is able to mount a VFAT (MS-DOS, Windows) filesystem. A VFAT
filesystem does not support permissions however. The VFS layer therefore will always
present a default set of permissions to the user. These permissions can be set when the
filesystem is mounted, but cannot be changed.

Student Notebook
Filesystems Supported
Traditional: ext2
Newest: ext3, ReiserFS, IBM JFS, xfs
Other UNIX: minix, ext, xiafs
FAT-12, FAT-16, FAT-32, VFAT, NTFS (read-only)
HPFS (OS/2) read-only, HFS (Macintosh) read-only
AFFS (Amiga), System V, Coherent, Xenix
CD-ROM (ISO 9660)
UMSDOS (UNIX-like FS on MS-DOS)
NFS (Network File System)
SMBFS (Windows share), NCPFS (Novell Netware share)
/proc (for kernel and process information)
SHMFS (Shared Memory Filesystem)
Figure 10-5. Filesystems Supported LX033.0
Notes:
Linux supports a wealth of filesystems. Its traditional filesystem is ext2, 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 ext2, but a clear winner has not been
identified. As an example, Red Hat currently uses ext3 as their default filesystem, while
SuSE uses ReiserFS by default.
Filesystems from other operating systems are also supported.

V2.0
Student Notebook
Uempty
A Typical UNIX Filesystem: ext2
Partition divided into blocks of 1024, 2048 or 4096 bytes

Blocksize depends on size of fs and expected usage
Blocks can have different usage:
Superblock
Inode (Index node) block
(Double, Triple) indirect block
Data block
S I I D D D S I I ID D D D
Figure 10-6. A Typical UNIX Filesystem: ext2 LX033.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.

Student Notebook
Superblock
First block of filesystem, several copies (at 8193, 16385,

...)
Contains general info on filesystem
Last mounted time/place
Block size
Pointers to free inodes
Pointers to free blocks
Pointer to root of filesystem
Figure 10-7. Superblock LX033.0
Notes:
The first block of the filesystem (block 1) will be the superblock1. 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.
1 Block 1 is the second block in the partition. But the first block of the partition, block 0, is never used for the filesystem since this block
might contain a boot loader.

V2.0
Student Notebook
Uempty
Inodes (Index Nodes)
128 bytes (8 per block of 1024 bytes) owner/group

file type
Contains information about a file:
file size
owner, group, type, size, file permissions
permissions, ctime, atime, mtime, ... time stamps:
create time
Contains pointers to data blocks access time
modification time
Contains pointers to an indirect link counter
block, a double indirect block and a additional flags
triple indirect block (ACL, EXT2_FLAGS)
pointers to data blocks
Figure 10-8. Inodes (Index Nodes) LX033.0
Notes:
An inode is 128 bytes large. With a blocksize of 1024 bytes, this means that there are eight
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 (256*256) data blocks are double indirectly addressed: The inode contains
a pointer to a double indirect block, the double indirect block contains pointers to indirect

Student Notebook
blocks, and the indirect block contains pointers to the data blocks (again assuming a
blocksize of 1024 bytes).
The next 16777216 (256*256*256) 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 ext2 filesystem is therefore something like 16 GB, when 1K blocks are used.

V2.0
Student Notebook
Uempty
Data Blocks
Contain file data

File may be a directory, in which case the data is the list
of file names and inodes in that directory.
So multiple file names may point to the same inode! (Or
files may have multiple names)
Inode 3694 Data 6417 Inode 8391 Data 9041
type: d name inode type: f This is the

data: 6417 . 3694 data: 9041 file xyz.
size: 1024 .. 13 size: 21
user: 0 xyz 8391 user: 0
group: 0 abc 8391 group: 0
link: 2
A directory A regular file

Figure 10-9. Data Blocks LX033.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.

Student Notebook
So...
The most important components of a filesystem are the

inodes and the data blocks.
The filesystem is full if
No more inodes are available
No more data blocks are available
So tune your filesystem according to the number of bytes
per file
Blocksize (1024, 2048 or 4096 possible)
Bytes-per-inode (4096 default)
Figure 10-10. So... LX033.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 can be 1024, 2048 and 4096. This size is chosen when the filesystem is
created, based on the expected usage of the system. If you expect a lot of small files,
choose a small blocksize. If you expect a large number of large files, choose a larger
blocksize.
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.

V2.0
Student Notebook
Uempty 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
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.

Student Notebook
Other Filesystem Features
Filesystems can have other features that can be useful:

Access Control Lists (ACL)
Allow more extended permissions, not just rwxrwxrwx
Not yet supported by VFS abstraction layer
Journaling
Keeps a journal of operations that are going to take
place, and operations that were successfully committed
Makes fsck far faster
Slight performance decrease
Extended file attributes
Examples: immutable, auto compression, undeletable
Labels
Allow mounting based on label instead of device name
Performance optimizations
Figure 10-11. Other Filesystem Features LX033.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 other partition) and only then performed. If the action has
succeeded, this is listed in the journal as well.

V2.0
Student Notebook
Uempty 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.
At the point of this writing, only the ext2/ext3 filesystem supports labels, and only Red
Hat is configured to use them.
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.

Student Notebook
Creating a Filesystem
Creating a filesystem is done with an mkfs variant

mke2fs, mke2fs -j
mkreiserfs
mkjfs
Typical options:
-b blocksize sets blocksize
-i bytes-per-inode sets number of inodes
-c checks disk for bad blocks
Example:
# mke2fs -b 1024 -i 4096 -c /dev/hda6

...
Writing inode tables: done
Writing superblocks and filesystem accounting info: done
...
#
Figure 10-12. Creating a Filesystem LX033.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 mke2fs2, 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).3
2
mke2fs is used to create an ext2 filesystem. mke2fs -j creates an ext3 filesystem.
3
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.

V2.0
Student Notebook
Uempty
Mounting a Filesystem
Using the mount command:

Supply device name
Supply mount point (empty directory)
# mount -t ext3 /dev/hda6 /mnt/extra
# mount -o nodev,noexec /dev/system/mylv /usr/local/proj1
Optional: supply filesystem type

Optional: supply other options
Optional: use different superblock
To show mounted filesystems, use mount without
arguments
Figure 10-13. Mounting a Filesystem LX033.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 ext3 (rw)
/dev/hda6 on /mountpoint type ext3 (rw)
/dev/cdrom on /mnt/cdrom type iso9660 (ro)
none on /proc type proc (rw)
[root@sys1 /root]# _

Student Notebook
Mounting Filesystems at System Startup
Add to /etc/fstab:
/dev/hda1 /boot ext3 defaults 1 2
/dev/hda5 / ext3 defaults 1 1
/dev/cdrom /mnt/cdrom iso9660 noauto,ro,user 0 0
/dev/fd0 /mnt/floppy msdos noauto,user 0 0
/dev/hda6 /mnt/extra ext3 defaults 0 0
Alternative notation, using ext2/ext3 filesystem labels

(used by Red Hat)
LABEL=/boot /boot ext3 defaults 1 2
LABEL=/ / ext3 defaults 1 1
/dev/cdrom /mnt/cdrom iso9660 noauto,ro,user 0 0
/dev/fd0 /mnt/floppy msdos noauto,user 0 0
LABEL=extra /mnt/extra ext3 defaults 0 0
Figure 10-14. Mounting Filesystems at System Startup LX033.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/ext3 superblock. The kernel searches all ext2/ext3
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/ext3 filesystems, and the use of these
labels also requires modifications of utilities (e.g. mount) and scripts. Only Red Hat has
made these modifications and uses filesystem labels by default. SuSE does not support
filesystem labels at all.
• The mountpoint at which the filesystem needs to be mounted.

V2.0
Student Notebook
Uempty • 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.
• The options.
• A dump indicator (see man fstab).
• A sequence indicator for fsck (see man fstab).

Student Notebook
Mount Options
Various options can be used when mounting a filesystem:

auto: Mount fs automatically when booting
noauto: Do not mount fs automatically
user: Users are allowed to mount this fs
owner: Same as auto but user must be owner of device
ro: Read only
rw: Read-Write
For more options, see man mount
Figure 10-15. Mount Options LX033.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.

V2.0
Student Notebook
Uempty 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.

Student Notebook
Unmounting Filesystems
Filesystem may not be in use -> check with fuser

Open files
Programs being executed
Active directories
# fuser -v /usr
USER PID ACCESS COMMAND
/usr root Kernel mount /usr
Use the umount command with either

The device name
The mount point
Or both
# umount /dev/cdrom
# umount /mnt/cdrom
Figure 10-16. Unmounting Filesystems LX033.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

V2.0
Student Notebook
Uempty
Checking a Filesystem
Checking a filesystem is done automatically when the

system boots
If a filesystem is cleanly unmounted, no further checks
are done
Minor errors repaired automatically
Major errors drop you in a shell; allows you to do a
more thorough check manually
fsck -y /dev/hda1
Can start filesystem checks manually as well with fsck
Only on filesystems that are mounted read-only or not
mounted at all
Figure 10-17. Checking a Filesystem LX033.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.

Student Notebook
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.4
• 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.
4
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.

V2.0
Student Notebook
Uempty
ext2/ext3 Specific Information
ext3 adds journaling to ext2 using a special, hidden

".journal" file of arbitrary size (recommended: 10 MB)
Thus, downwards compatible with ext2
For new ext3 filesystems, use mke2fs -j
For converting ext2 -> ext3, use tune2fs -j
Useful ext2/ext3 commands:
tune2fs tunes an ext2 filesystem
debugfs debugs an ext2 filesystem
chattr changes ext2 extended attributes of a file
immutable
compressed
undeletable
and so forth (see man chattr for details)
e2label changes filesystem label of an ext2 filesystem
resize2fs can resize an unmounted ext2 filesystem
Figure 10-18. ext2/ext3 Specific Information LX033.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.

Student Notebook
• 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.

V2.0
Student Notebook
Uempty
ReiserFS Specific Information
Filesystem for Linux only, created by Hans Reiser

32 MB journal by default (minimum 2 MB)
Thus, do not use ReiserFS for small filesystems
Journal may be in the filesystem itself or on a separate
partition
ReiserFS uses balanced trees instead of linear directory
lists
Extremely useful for directories which contain 1000+
files
Useful commands:
debugreiserfs debugs a ReiserFS filesystem
resize_reiserfs resizes a ReiserFS filesystem
Extending can be done on a mounted filesystem
Reducing can only be done on an unmounted
filesystem
Figure 10-19. ReiserFS Specific Information LX033.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 by default. (Its minimum size is 513 blocks of 4k each, so a
little over 2 MB.) This journal is usually part of the filesystem, but it can also be stored in a
separate partition.
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.

Student Notebook
JFS Specific Information
Journaling filesystem from IBM AIX / OS/2

Uses B+ trees for fast directory indexing
Will support ACLs in the future
Useful commands:
extendfs extends a JFS filesystem
Can be done without unmounting first
JFS does not support reducing a filesystem
xpeek allows you to debug a JFS filesystem
Figure 10-20. JFS Specific Information LX033.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.
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.

V2.0
Student Notebook
Uempty
Comparing Filesystems
Journaled Filesystems used by Linux:
ext2 ext3 jfs reiser xfs
yes yes yes

Journal no (10 MB (auto (32 MB yes
default) resized) default)
yes, but yes, but only

yes - only
resizeable only when when yes yes
when mounted
unmounted unmounted
maximum File: 2TB File: 2TB File: 4PB File: 16TB File: 2TB
size FS: 16TB FS: 16TB FS: 32PB FS: 1EB FS: 8EB
I-Nodes I-Nodes
I-Nodes I-Nodes
(completely (completely
type (allocated B-Tree (allocated in a
block block
in a b-tree) b-tree)
oriented) oriented)
Figure 10-21. Comparing Filesystems LX033.0
Notes:
The visual shows a quick comparison of the filesystems we mentioned here. Also included
is XFS, the filesystem that was donated to Linux by SGI. XFS is not used in the major
distributions though.
Note that the maximum size for files and filesystems shown is always calculated when the
maximum blocksize is used. In addition to this, the kernel or your application may not
support files or filesystems of the sizes mentioned.
For reference:
• A kilobyte is 1024 (210 ) bytes.
• A megabyte is 1024 kilobyte, or 220 bytes. The capacity of a CD is about 650 megabyte.
• A gigabyte is 1024 megabyte, or 230 bytes. The largest PC hard disks currently available
are about 250 GB in size.
• A terabyte is 1024 gigabyte, or 240 bytes.
• A petabyte is 1024 terabyte, or 250 bytes.
• An exabyte is 1024 petabyte, or 260 bytes.

Student Notebook
SHMFS Specific Information
SHMFS: POSIX compliant Shared Memory Filesystem

Filesystem stored in memory, expands when used to
required size
Not persistent across reboot
Typically mounted on /dev/shm
Required by certain applications
Figure 10-22. SHMFS Specific Information LX033.0
Notes:
The last filesystem we want to cover here is the Shared Memory Filesystem, or SHMFS in
short. It is a POSIX compliant filesystem, which resides in memory. You can think of
SHMFS as a RAM disk formatted as a filesystem. The difference is that SHMFS
automatically grows and shrinks as needed, while formatting a RAM disk would yield a
filesystem with a fixed size. But as with a RAM disk, it is not persistent across a reboot.
Most distributions enable an SHMFS by default, typically mounted on /dev/shm. Red Hat
does this with an entry in /etc/fstab, while SuSE enables it from /etc/init.d/boot.swap, which
in turn is called from /etc/init.d/boot. The maximum size of the SHMFS is configurable, but
is usually set to half the amount of real memory in the system.
SHMFS is required by certain applications, among which Apache, Oracle and SAP.

V2.0
Student Notebook
Uempty
Quota Concepts
Quota limit the amount of data a user/group is allowed to

store
Defined on a per-filesystem basis
Based on block and/or inode usage per user or group
Per quota two limits: Soft and Hard
User exceeds soft limit -> warning only
User exceeds hard limit -> error
Grace period identifies how long the soft limit may be
exceeded
After that period, a user gets errors instead of warnings
20 MB 5
each user may consume

only 20 MB permanently and Filesystem 300 MB
25 MB temporarily
Figure 10-23. Quota Concepts LX033.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...

Student Notebook
Quota Implementation on Linux
Quota support compiled into the kernel

No daemon necessary
Implemented on a per-filesystem basis
A user can have different quota on different filesystems
Stored in aquota.user and aquota.groups in the root
of the filesystem
Quota checking should be enabled when mounting the
filesystem
Mount options: usrquota, grpquota
Can be specified in /etc/fstab
Quota checking should be turned on after mounting with
the quotaon command
Automatically executed from bootscript after mount -a
Figure 10-24. Quota Implementation on Linux LX033.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.user and
aquota.group5 in the root of the filesystem.
5
Earlier implementations used the quota.user and quota.groups file. To convert the old format in the new format, use convertquota.

V2.0
Student Notebook
Uempty
Enabling Quota
Modify /etc/fstab
/dev/hda2 / ext3 defaults 1 1
/dev/hda4 /home ext3 defaults,usrquota,grpquota 1 2
/dev/hdb /mnt/cdrom iso9660 noauto,owner,ro 0 0
/dev/hda3 swap swap defaults 0 0
/dev/fd0 /mnt/floppy msdos noauto,owner 0 0
none /proc proc defaults 0 0
none /dev/pts devpts gid=5,mode=620 0 0
Create aquota.user and aquota.group in the

filesystem's root directory
Remount the partition
Calculate current usage and turn on quota checking
# touch /home/aquota.user /home/aquota.group
# mount -o remount /home
# quotacheck /home
# quotaon /home
Figure 10-25. Enabling Quota LX033.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.user and aquota.group 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.

Student Notebook
Configuring Quota
Done with the edquota command

Starts $EDITOR (default: vi) in a subshell
Only edit the block/inode soft/hard quota numbers!
User quota: edquota -u <username>
Disk quotas for user tux1 (uid 501):
Filesystem blocks soft hard inodes soft hard
/dev/hda4 10700 20000 25000 407 0 0
/dev/hda9 320 300 350 23 30 50
~
~
~
"/tmp/Edp.a9fSEQK" 3L, 213C
Group quota: edquota -g <groupname>

Grace period: edquota -t
Copy quota: edquota -p tux1 -u tux2 tux3 tux4
Figure 10-26. Configuring Quota LX033.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 aquota.user and aquota.group 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 aquota.user and aquota.group 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. You are only supposed to edit the fields under
“soft” and “hard”: four fields per filesystem in total.
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).

V2.0
Student Notebook
Uempty 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
Quota Information
quota command
Reports on the quota of one user
Can be executed by anyone
A regular user can only view his own quota
tux1$ quota
Disk quotas for user tux1 (uid 501):
Filesystem blocks quota limit grace files quota limit grace
/dev/hda4 10700 20000 25000 407 0 0
repquota command
Reports on the quota of all users and groups
Can only be executed by root
root# repquota /dev/hda4
Block limits File limits
User used soft hard grace used soft hard grace
root -- 848804 0 0 56892 0 0
.
tux1 ++ 1500 1000 1500 7days 112 112 115 none
tux2 -- 176 1000 1500 44 0 0
Figure 10-27. Quota Information LX033.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.

V2.0
Student Notebook
Uempty
Checkpoint
1) Assuming a blocksize of 1024, 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
Unit Summary
What is a file?
What is a filesystem?
Supported filesystems
Inodes
Creating/mounting/unmounting filesystems
Predefined mounts
Quota
Notes:

V2.0
Student Notebook
Uempty Unit 11. 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, 2003 Unit 11. Memory Management 11-1
Student Notebook

4
!

!

Notes:

V2.0
Student Notebook
Uempty
!
#

9 ¥

,% '¦(/5+
%

% ,§

&" % (/5
$

%

2 %
4 ' <7,
+:D5
34
;=;*
% *;:D5
/4 ;:,(;35
Figure 11-2. Linux Memory Management LX033.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
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.
1
Technical issues under Linux currently limit this to 3 GB.
Student Notebook
<!"

% %
Figure 11-3. Example: Lightly Loaded System LX033.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.

V2.0
Student Notebook
Uempty
<!;"

% %
Figure 11-4. Example: Heavily Loaded System LX033.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.
Student Notebook
"

@1@$"#
'

+

=7' 4
+
!

0,+6 ! ,1
#

0,+66 ! ,1
#

!%

0. 6. ,+6,

-6%
",

-
! ,16

)##)1 )
Figure 11-5. Creating Paging Space LX033.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.

V2.0
Student Notebook
Uempty # 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.
If you want to make your swap space permanent, you can add this to /etc/fstab, just like a
filesystem.
Student Notebook
'

!2

¥

%
! #

##
!

!

#

Figure 11-6. Useful Commands LX033.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.

V2.0
Student Notebook
Uempty • vmstat displays memory and some other statistics (swap in and out, I/O bytes in and
out, interrupts, context switches and CPU usage) on one line, and repeats this every n
seconds. (n is an optional vmstat parameter.)
• procinfo displays processor statistics.
Student Notebook

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.

V2.0
Student Notebook
Uempty
' "
/

2
Notes:
Student Notebook

V2.0
Student Notebook
Uempty Unit 12. Scheduling

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

• Use crontab files to schedule jobs on a periodic basis
• Use anacron to schedule jobs on a workstation
• 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, 2003 Unit 12. Scheduling 12-1

Student Notebook

2

2 %
2

2 .
#
Notes:

V2.0
Student Notebook
Uempty
"
%

$

4

4

Figure 12-2. Scheduling LX033.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

! %'+

¨

@#@
@ '$+
@#@
@ @' 3+
4
©§© §©§© §©%§© §
##

@@ >' + @@ > '$+
@#@
@ @ @#@
@ @ ' 3+
Figure 12-3. Cron LX033.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.

V2.0
Student Notebook
Uempty Being able to schedule tasks is really useful for recurring tasks that you don’t want to think
about every hour, day or week. Examples include:
• Backups
• Periodically checking whether key processes are still running
• Periodic cleanup of directories
• Periodically sending status messages by mail
• Automated starting and stopping of services which should only be available at certain
times
All output of commands that are run by cron are automatically mailed to the user who
configured these jobs. But obviously you can send the output anywhere you want, including
to pagers and to cellphones with SMS, as long as the pager or cellphone can be reached
via a scriptable interface.
As system administrator, you may want to regulate the use of cron. This can be done using
two files: /etc/cron.allow and /etc/cron.deny. (On a SuSE system, these files are
/var/spool/cron/allow and /var/spool/cron/deny, respectively). These files are checked in
turn:
• 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 (/var/spool/cron/allow) exists, the username has to be in it in
order to be able to use cron.
• If the file /etc/cron.allow (/var/spool/cron/allow) does not exist, but the file /etc/cron.deny
(/var/spool/cron/deny) exists, the username should not be in it in order to be able to use
cron.
If both files exist, then only the allow file is read and everybody not in it is automatically
denied usage of cron. That is why the allow file is called the strongest.

Student Notebook
' <!
9.-
1 +
.-
1 +-+
,-
# &!-
!
,
1 9.
1 ) 9.-
# &!--
1 ¡¡¡.!¢
Figure 12-4. User crontab Example LX033.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

V2.0
Student Notebook
Uempty 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.

Student Notebook

2"

.;
.; $ #
.; 3 ª3"B$
0.;
1 # .!
$.£ , ;
+
¤
¤
¤
6 .; #
Figure 12-5. crontab Command LX033.0
Notes:
All user crontab files are stored in /var/spool/cron, and cannot be edited by the users
directly. Users therefore need to invoke the crontab command to edit their files.
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.

V2.0
Student Notebook
Uempty
" %

%>@@
4
©"/3§ ©2"§ ©!B//-§
%& ;
,
, ;
4 , ,;
4 ,;
4 ;
4 ,
; +, ;

39
# ,
; ., .,
# ! ,6 . , .-
! ,6 . , .
-
) ! ,6 . , .+-
! ,6 . , .
-
Figure 12-6. System crontab File LX033.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
$ 4; 5
/

5>>> %

$

¨
,,

¨4 ,, ,
-
3
Figure 12-7. Anacron (Red Hat only) LX033.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.

V2.0
Student Notebook
Uempty SuSE does not support anacron (yet?) Instead, they choose to implement the same
behavior through a series of scripts which are called from cron. This basically works as
follows: /etc/crontab contains a job, run-crons, which runs every 15 minutes. This job
checks for the existence of a series of marker files in /var/spool/cron/lastrun, one for each
of the directories /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly and /etc/cron.monthly. If
the marker file does not exist, then the jobs are executed, and the marker file is created
afterwards. Four other crontab entries make sure that the correct marker file is deleted
every hour, day, week and month, respectively.

Student Notebook
,,
34

%& ;
,
, ,;
4 , ;
4 ,;
4 ;

#.
-6, . .
-
2 .+-6, . .+-
1 #.-6, . .-
4
86
:8-:8

:8¥;:

" .
¨
Figure 12-8. /etc/anacrontab LX033.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.

V2.0
Student Notebook
Uempty

$
0
6,
¦/
0;,
)4 /1-,
0.
,66;,,£+/

Figure 12-9. at LX033.0
Notes:
The at command can be used to run a command once in the future. It creates a script in the
/var/spool/at (Red Hat) or /var/spool/atjobs (SuSE) directory, containing the commands to
be executed. 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.
# at -f commandfile 19 run the commands in commandfile at 7pm.
# at 19 < commandfile ditto

Student Notebook
The output of the commands run by atd will be mailed to you if you didn't specify output
redirection.

V2.0
Student Notebook
Uempty

>

! #%
8>=
%

;.
.+
,+$
.7
Figure 12-10. batch LX033.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. 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 indicate that a
job should be delayed until the workload on the system is below a certain threshold.

Student Notebook

0
1 1 # 4 #
1 #42
01
.

#
$
@@>' +
@@>
Figure 12-11. Controlling at Jobs LX033.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.

V2.0
Student Notebook
Uempty

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.

Student Notebook
' "
4%

4
#

3

4
Notes:

V2.0
Student Notebook
Uempty Unit 13. Backup and Restore

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

• Discuss backup schemes
• Discuss backup media
• List the different backup tools supported in Linux

Accountability:
• Exercises
© Copyright IBM Corp. 2001, 2003 Unit 13. Backup and Restore 13-1
Student Notebook

%

%

%

4
Notes:

V2.0
Student Notebook
Uempty
"
%

#
%

#
/ %
@
2 '
!,+

%
#
" %

B %

1%
/
-
Figure 13-2. Backup Schemes LX033.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 or differential 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 (full or data) backup too and possibly all the incremental
backups that have been made since then.
Student Notebook

&
( 7 < :
( 7 <
%
( ( (
%
Figure 13-3. Incremental vs. Differential Backup LX033.0
Notes:
The visual lists the difference between an incremental and a differential backup: An
incremental backup backs up the differences between the current situation and the last
differential backup, while a differential backup backs up the differences between the current
situation and the last full backup, irrespective of differential backups in between.
The difference is academic: most backup tools only have a very primitive way of doing
incremental/differential backups, and the backup tools that do support this typically support
more levels, so that you can make your own combination.
With dump, for example, it is possible to take a backup every day of the week, which backs
up the changes made on the last two days. In other words, an incremental backup against
the previous-but-last backup.

V2.0
Student Notebook
Uempty
" "
5%
3#

E

##
5%

5%
3#%
" 5%

3#/ #
" 5%

3##
" 5%

3# #
" 5%

3##
" 5%

3##
Figure 13-4. Sample Backup Scheme LX033.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 (e.g. financial) 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
Student Notebook
time, 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.

V2.0
Student Notebook
Uempty
" "
" ? F ? % "

z

* q `

z *
z *
q
z *
` z z zz
z
z *
z zq z z` z
z*
z *

Figure 13-5. Sample Monthly Backup Scheme LX033.0
Notes:
The visual shows a backup scheme for a full month, using the schedule of the previous
visual.
Student Notebook
&

#

2

!,$!,$1
!
#
'$ #+%
4
#
%#
# %

«
¨&#

-%
2 E.
' /+
Figure 13-6. Backup Devices LX033.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-R, CD-RW and DVDs are a fairly new way of backing up. They are cheap and have a
large capacity. The disadvantage is that they are comparatively low, 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. But,
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.

V2.0
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 almost 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
& ?

5%
#
#
34

5%
#
#
%

5%

! %
')#+

2 % ,,
%

Figure 13-7. Default Backup Tools LX033.0
Notes:
Linux by default only has four 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.
dd is a tool which is not designed to do backups, but can be used as such. It makes a
bit-for-bit dump of a disk or filesystem and can thus be used to restore systems to an exact
state.

V2.0
Student Notebook
Uempty

2-"
#
5%

0.!
$
0!8
,.:
%

0!
Figure 13-8. tar Command LX033.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
This command creates (c) an archive called archive11.tar (f archive11.tar), and is verbose
(v) in what it does.
Important to note here is that tar does not conform to the regular way of specifying options:
It first requires the user to list all relevant options, and if any of these options require
Student Notebook
arguments, then these arguments are listed straight after one another. Finally, the last
argument(s) list the files to be archived.
Other options include:
x extract files from an archive
t list files in an archive

V2.0
Student Notebook
Uempty
3'
D-2#

#
!

'&
+
'&
7+
0".!$"
0¥.!;"

0.!
% # %

0.!3 !
Figure 13-9. GNU tar LX033.0
Notes:
The tar command that is provided by the GNU project has a number of important features
that set it apart from traditional tar. These features include compression with gzip or bzip2,
another way of working with pathnames, and multivolume backups.
The first feature is support for compression using gzip (using the z option) or bzip2 (using
the j option). bzip2 compression is better but not really standard yet.
Traditional tar always included the leading slash in the tar archive. This meant that a file
would always be restored at the exact same place. In most cases, this is not what you
want. Because of that, GNU tar strips the leading slash from the pathname when making a
tar archive. If you want the leading slash to be included, you can use the P option though.
The last feature is the M option, which allows you to create multivolume backups. This is
useful for backing up to a floppy disk, for instance.
Student Notebook

! 2-"%

5%

0.6
!
,77!
.7
0
.6
!7 !
$

0.6

!8:8
,:!
.7
0.6

! ¥ !

%

0.6

!!
.7
0.6

! !
Figure 13-10. cpio Command LX033.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.
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.

V2.0
Student Notebook
Uempty

%

! %

)#
" @@

06 ;.6
6
06 ;.6§,4 6
,
&%

0.
0,! ;.6
6

,+ ¡8- :
Figure 13-11. dump Command LX033.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.
dump can also back up to another system, using the rsh protocol. This feature is not often
used today though: If you want to make network backups, then there are far better tools
available, including Amanda and Tivoli.
Restoring a backup made by dump is done with the restore command.
Student Notebook
>"
1/
# %

, #
'>
+

, ,
B
4

%

1
@#@#88@ # @#@#88@ #
0 ! !$ -!

0!. 3,-!,6 ! !$ -!
0 ! !$ -!
06 ! , ! !$ -!,6¨¨©
7!! ! !$ -!,6
Figure 13-12. LVM Snapshots LX033.0
Notes:
LVM Snapshots are not backup tools as such, but can be really useful when creating
backups.
An LVM snapshot can be though of as a direct copy of a logical volume, but this copy is
deferred until data on the original logical volume actually changes. Until that time, the
physical extent is “shared” between the original LV and the snapshot LV.
The advantage of this over a real LV copy is that a snapshot, even of very large LVs, can be
done in a very short time, because no actual data needs to be copied. The only thing that
needs to be done is allocate the blocks for the snapshot, and some administration. This
rarely takes more than a second.
This is really useful if you are running programs (e.g. databases, web servers and the like)
that need to be running as close to 24 hours a day as possible, but need to be backed up
nevertheless in a consistent state. With LVM snapshots, the interruption in service can be
kept down to mere seconds:
• Stop the service

V2.0
Student Notebook
Uempty • Unmount the filesystem

• Take an LV snapshot
• Mount the filesystem
• Start the service again
This whole procedure should not take more than 10 seconds. After this, the LV snapshot
contains an image of the unmounted filesystem, which can be backed up when time
permits.
Student Notebook

! %,,

%
%%%

0
! ,
$;, 3
0
,
$ ! .;, 3
%%
/5$
0
! , ;
$;,# .

0
! " ! ;, 3
0
! ! ;, 3
Figure 13-13. dd Command LX033.0
Notes:
The dd command is not a backup command per se, but can be used as such. It basically
copies data bit-for-bit to and from disks, filesystems, floppy disks or files.
dd can for instance be used to create disk images: files which have the exact size as the
original disk. These disk images can then be used to clone a system, or to restore it to its
original state.

V2.0
Student Notebook
Uempty The syntax of dd is rather strange. Instead of using regular options, it only accepts
arguments. Here are some example arguments:
if= Input file
of= Output file
bs= Block size, in bytes. May also use the abbreviation K, M or G,
for kilo-, mega- and gigabytes, respectively.
The block size identifies the block size that dd uses.
Experience has shown that the default block size of 512 bytes
is too small to obtain good performance when working with local
disks. It is therefore recommended to use a block size of 1M or
more when working with local disks (including floppy disks).
count= Number of blocks to copy
Student Notebook
?

# %

5$27888
@@>>
,
@@>>
5!02¥
@@> >
5%
@)888
@@>> >
/-
@@> >
"5/@# / ' /+

@@>#> @
@ 4
Figure 13-14. Other Backup Tools LX033.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.

V2.0
Student Notebook
Uempty

1) What is the difference between A and B?

A: ILQGKRPHIUDQFLVSULQWFSLRRY!GHYUPW
"
B: ILQGSULQWFSLRRY!GHYUPW
"
______________________________________________
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.
Student Notebook
' "

"
%

.
/
5%

5%

$

%
5%

%

Notes:

V2.0
Student Notebook
Uempty Unit 14. User Administration

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

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

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

/

!
Notes:

V2.0
Student Notebook
Uempty
"
2
D

2 . 2 .
2 ." 2 ."

2

"
Figure 14-2. Security Concepts LX033.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

! ' +
B
Figure 14-3. User Hierarchy LX033.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.

V2.0
Student Notebook
Uempty
3

#
3#

#

@
D

>

Figure 14-4. Groups LX033.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.
Student Notebook
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
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.

V2.0
Student Notebook
Uempty
' 3
2#D
#
*
#
*

#
#
3#
'>> +
#
$. & '>>
>>>+
$2#D
3

**
* * * *
Figure 14-5. User Private Groups LX033.0
Notes:
In the previous visual we’ve seen that every user is a member of at least one group. By
default, in most UNIX and Linux systems, this is a generic group called “users” or “staff”.
But some distributions, including Red Hat, have introduced something called “User Private
Groups”.
With this scheme, a group is created for each and every user account. This account is
made member of that group. The user name and group name are the same, as are the UID
and GID numbers.
This has an advantage over the traditional scheme in that it is easier to give someone (for
instance a secretary) access to someone elses home directory (for instance the boss’
directory): Simply make the secretary member of the boss group. With the traditional
scheme, still used by SuSE, this is virtually impossible.
And note that this scheme still allows all the things the traditional scheme allows as well:
groups related to a project, where every project member is member of the group and can
access the files of that group.
Student Notebook
"# #"

'

>>>+
2

2

@@¬

!

2

@@ >

@@¬ >>>
Figure 14-6. Shadow Password Suite LX033.0
Notes:
In the early days of UNIX, all user information, including the encrypted password, was
stored in /etc/passwd. This file needs to be readable for the whole world: programs such as
ls, for instance, need to be able to perform UID <-> username mapping.
This meant that every user on the system could get a list of all the encrypted passwords of
all users, which he or she could then subject to a dictionary attack. When CPUs were
comparatively slow by today’s standards, this was a lot of work and not really practical.
Today however, dictionary attacks take mere seconds, and with hardware which is currently
available to wealthy hackers, a brute force attack which tries out every possible password
is becoming feasible.
It is therefore of paramount important that also the encrypted passwords of the users are
shielded from ordinary users. This is performed by the shadow password suite. This suite
of programs and libraries adds two additional files to the system: /etc/shadow and
/etc/gshadow. These files are read-write only for root, so ordinary users can’t get access to
them, except for a few carefully written SUID programs that are part of the shadow
password suite.

V2.0
Student Notebook
Uempty The shadow password suite also implements password aging: a mechanism that forces the
user to change his/her password every now and then. These parameters are stored in
/etc/login.defs.
Student Notebook
' ?

0,$,'
.6
06,,+

0,
!
0,$,,'!

% %

0,
0,
Figure 14-7. Command Line User Tools LX033.0
Notes:
adduser or useradd
A tool to add users to your system. The adduser and useradd command will only create
the user account. You have to set the password manually afterwards. Depending on the
configuration in /etc/login.defs, useradd creates the home directory of the user as well. To
always create the home directory, regardless of these settings, use the -m option.
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.

V2.0
Student Notebook
Uempty
,,
% #

+
@@%
" $+
++
%

0,#
0, . -+,1
Figure 14-8. /etc/skel LX033.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.
Student Notebook
3?

0$66$
,
0$6+
0$66$
,
@

0,'6$
,
0$6,,+ 6$
,

0$6,,+
,6$
,

,$6,,+ 6$
,

,$6,,+6$
,
Figure 14-9. Command Line Group Tools LX033.0
Notes:
You could also use the command tools to manage your groups.
An interesting feature of UNIX/Linux is that you, as the superuser, can assign group
administration rights to other users. This allows group administrators to add users to their
group, and remove them from their group. Obviously, the user accounts themselves still
need to be created by the superuser.

V2.0
Student Notebook
Uempty
#
!

D
%

!
4

06,,+1
ª+6,,+4

06,,+1
¥9«-
0.$1
3

4
3
4 )
*
$4
.
!42

Figure 14-10. Passwords LX033.0
Notes:
Users can change their passwords by using the passwd command. Root can also use this
command to reset passwords of other users.
A useful tool is mkpasswd. This generates a random password and, optionally, assigns
this password to a user. Note that the mkpasswd command is not installed by default. On
a Red Hat system, it is part of the expect RPM, while on a SuSE system, it is part of the
whois RPM.
Another useful tool is chage. This allows you to view and change the password aging
information.
Student Notebook
,, #
@@
,

0. . 6,,+
44 4 44 4 ;
;,

6,
44# 4# 4,
4 ! ,6 6,
4 ;
,

1 44#124 44 1 4 ;
;,

**
(+
7+
'4

#+
<+2"
:+D"
+D3!B ' +
;+
?+
Figure 14-11. /etc/passwd LX033.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.

V2.0
Student Notebook
Uempty
,, #
!

@@
0. . ,+

;
4 4 224 4424 4 4

4 9¬35.2+%¬ª; 4 24 44 4 4 224 1#1
4 ($%)«* 5®"12«22 4 2 4 44 4 4 4 1#
(+
7+

' +
<+ ' ¨ (()?8+
:+

+

;+
4

?+
4

=+ ¨ (()?8
Figure 14-12. /etc/shadow LX033.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.
Student Notebook
• 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.

V2.0
Student Notebook
Uempty
,, ,, #
0. . $6
44 4
;
44 4;

444;

,-,4414;

444

6$
,44# 4
,
44# 4
44# 4
0. . $,+

6$
,4¢4
,4
Figure 14-13. /etc/group and /etc/gshadow LX033.0
Notes:
The /etc/group file contains group information. From left to right:
• The group name
• The group password. This is set to “x” if the group password is in /etc/gshadow.
• The Group ID (GID)
• The list of users that have this group as their secondary group.
The /etc/gshadow file contains extended 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 name of the group administrator
• The list of users that have this group as their secondary group.
Student Notebook
,, ,,
!
0. .
,,
*.'

.

5©©
#%

.

®%
®

®

* *
Figure 14-14. /etc/issue and /etc/issue.net LX033.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

V2.0
Student Notebook
Uempty
&
@@

0. .
%%&39'&
+6$
,,-,+

;!
;;+ 6 6
$

";<, 4,,

>
Figure 14-15. Message of the Day LX033.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.
Student Notebook

1) What is a User Private Group

a. A group for users who need privacy
b. A group which has the same name as the user; this user has this group as
its primary group
c. A group which is used for sharing files between the members of this group
d. The "staff" group
2) Where are the passwords of users stored?

______________________________________________
Notes:
1.
2.

V2.0
Student Notebook
Uempty
"
2

2 @@

@@
D
@@

Notes:
Student Notebook

V2.0
Student Notebook
Uempty Unit 15. 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, 2003 Unit 15. User-Level Security 15-1
Student Notebook

2" D" %5

"

/
Notes:

V2.0
Student Notebook
Uempty
' +"#
$ 1

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

' >+

Figure 15-2. User-Level Security Overview LX033.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
$ 4$5
4

"

3

" #
/

4
Figure 15-3. Pluggable Authentication Module (PAM) LX033.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.

V2.0
Student Notebook
Uempty
$ $
#

#
@@

Figure 15-4. Authentication before PAM LX033.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
$ #$
#

/
@@
> /

#
@@

Figure 15-5. Authentication with PAM LX033.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 are a number of authentication mechanisms currently available. Some of the more
important are:
• 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

V2.0
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
$ %<!
0. . 6 $

0¯3

; ,.
- 6,.-,

; ,.
- 6
,

; ,.
- 6$
,

; ,.
- 6!,
..

; ,.
- 6
,
6,,+

; ,.
- 6..
;,-1-6
6,,+

; ,.
- 6
,,#,+
,,,

; ,.
- 6

,,
,,,

; ,.
- 6
,
,,,
6

; ,.
- 6.,,
-/

Figure 15-6. PAM configuration files example LX033.0
Notes:
The visual above shows an example PAM configuration file. Every file you will encounter
within PAM is split up in four sections, which apply to the four phases of the login process:
1. auth: Verify the authentication of the user, usually by checking the password.
2. account: Manage the account. For instance force a user to change its password if the
password used is expired.
3. password: Change the password itself. This phase can also be called from the passwd
program.
4. session: 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:
• When the user tries to authenticate, perform the following checks:
- Require that root only logs in from a tty listed in /etc/securetty.
- Check that the UNIX password is correct.

V2.0
Student Notebook
Uempty - Don’t allow a regular user in if the file /etc/nologin exists. Instead, print the contents
of the file /etc/nologin.
- Set a number of environment variables used in the login process.
• For the account management, only perform the regular UNIX checks of password
expiration.
• When a user sets a password, perform a dictionary attack first. Then, set the password
using the regular UNIX files.
• When the users session is set up, apply a number of limits (CPU, memory, ...), and
perform standard UNIX login tasks, such as switching to the appropriate user ID. If the
user logs in on the console, make the user owner of certain console devices such as
/dev/fd0 and /dev/cdrom.
More information on PAM can be found in /usr/share/doc/pam-version This includes a
description of every function of every PAM module.
Note that the file in the visual is not an actual file, but merely an example.
Some actual examples of a Red Hat system are:
/etc/pam.d/login:
#%PAM-1.0
auth required /lib/security/$ISA/pam_securetty.so
auth required /lib/security/$ISA/pam_stack.so service=system-auth
auth required /lib/security/$ISA/pam_nologin.so
account required /lib/security/$ISA/pam_stack.so service=system-auth
password required /lib/security/$ISA/pam_stack.so service=system-auth
session required /lib/security/$ISA/pam_stack.so service=system-auth
session optional /lib/security/$ISA/pam_console.so
/etc/pam.d/system-auth:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth required /lib/security/$ISA/pam_deny.so
account required /lib/security/$ISA/pam_unix.so
password required /lib/security/$ISA/pam_cracklib.so retry=3 type=

password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5
shadow
password required /lib/security/$ISA/pam_deny.so
session required /lib/security/$ISA/pam_limits.so
Student Notebook
As you can see, Red Hat uses the pam_stack.so module to refer to a generic
system-auth file. This file is modified by authconfig and used in virtually any PAM
authentication configuration file.
The $ISA shell variable is used to distinguish between 32-bit and 64-bit architectures.
An actual example from a SuSE system is:
/etc/pam.d/login:
#%PAM-1.0
auth requisite pam_unix2.so nullok #set_secrpc
auth required pam_securetty.so
auth required pam_nologin.so
auth required pam_env.so
auth required pam_mail.so
account required pam_unix2.so
password required pam_pwcheck.so nullok
password required pam_unix2.so nullok use_first_pass use_authtok
session required pam_unix2.so none # debug or trace
session required pam_limits.so
As you can see, SuSE uses pam_unix2 instead of pam_unix. The reason for this is
largely historic: SuSE did not like the quality of the earlier pam_unix.so module, and
decided to write its own. Today, the quality and functionality of pam_unix and pam_unix2
is virtually equal.

V2.0
Student Notebook
Uempty
$
/

4>$2-" '
+

#> # #

%>!%

>3

%>!%
' 3 +

> @@ 4

>@

>

>@

%>" / '$ +

> !2

>

>#
#/ #
@@
Figure 15-7. Common PAM Modules LX033.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.
Student Notebook
$
& 4

34
#
B
4
2"

' +
34
2"

#
@@

!
$

$

1 '%+
2"
%
%@

Figure 15-8. Principles of Authorization LX033.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.

V2.0
Student Notebook
Uempty • 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. The list of users and commands that they are allowed
to run is in /etc/sudoers.
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.
• Various games may have their SUID bit set. This is usually needed to implement some
sort of highscore tracking.
Apart from kernel bugs, SUID programs are the only means for a hacker to gain root
privileges when he is logged in as a regular user. This means that all SUID programs on
the system should be known to the system administrator and checked/updated regularly for
security problems.
The following command will list all SUID programs on your system:
find . -perm +6000 -ls
Student Notebook
%
>

2 2

2 2

4 2 4 2

2"
#"
D"
#
"
"

% B

Figure 15-9. File Permissions LX033.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

V2.0
Student Notebook
Uempty 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 /SGID 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.
Student Notebook

.

0. 2##/.

0,.

++16¥ ) 1 # 1 4#1.

0.2##$/, -6$
,-6$
+, 6¥ 2 2 4#-6$
0.2##/, 6,,+
,6,,+
+,1,+21) 1 1 2 )416,,+
!
0.+¥

.
0.$6,
.
0.+¥,
.
Figure 15-10. Changing Permissions LX033.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 ...

V2.0
Student Notebook
Uempty

, % @@

" # % ªB/3@>

ªB/3@>

# %
877
887'
#
+877
'+
Figure 15-11. umask LX033.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 may have a different umask than normal users. For root, the default umask is
022 and for normal users this will be 002 (when User Private Groups are used) or 022
(otherwise).
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/.bash_profile or $HOME/.profile file.
Student Notebook
<! ?&
!
0$66$
,

0,'6$
,
4
0$6,,+ 6$
,
!

0
$6, 6$
,
0.$66$
, $6, 6$
,
0.22 $6, 6$
,
Figure 15-12. Example: Creating a Team Directory LX033.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.

V2.0
Student Notebook
Uempty
$
&

$
Figure 15-13. Root Access LX033.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.
Most Linux systems have remote login (through telnet) for root disabled by default: root is
only able to login on consoles that are listed in /etc/securetty.
Student Notebook

+

,
,,+4
0+

2 , #
34

,. ,;
6+
,,+4

(.,,,$- 4
,-,
,$
$+,-,ª9*¢
Figure 15-14. su LX033.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.

V2.0
Student Notebook
Uempty

4

.

-B #
@@4

3
/
4
4
9' +
0. . ,,
,
,9&9% 1
,
,*&(%&&%++++++ +++

,ª3% , ;
6
, ;
6
*&(%&&% ,;
,!
.6,
9&9%6
,!ª3%
Figure 15-15. sudo LX033.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
This 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.
Student Notebook
Because of security and locking issues, only edit this file with the visudo command, not
with a regular editor.
Note that the intention of sudo is to allow users to execute a specific command as another
user, most often root, without having to supply that users password. This also leads to a
security risk if the command that is allowed can be used for something unintended. As an
example, if you let a user start vi, through sudo then that user is able to edit that particular
file. But by using the :r and :w commands in vi, the user is also able to edit other files
owned by root. And by using :! in vi, the user is able to execute any command as root. You
should therefore be really careful in configuring your /etc/sudoers file, so that it cannot be
used to edit arbitrary files or execute arbitrary programs.

V2.0
Student Notebook
Uempty
"
@#@@ ,

@#@@ ,
@#@@ ,
@#@@
,
@#@ @
,
Figure 15-16. Security Logs LX033.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.
/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
'
0+ C

0+ 4
@#@@
@#@@
0

0,

0,$
Figure 15-17. Useful Commands LX033.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.

V2.0
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. When User Private Groups are used, the default umask of a user is 002,
and 022 otherwise
Notes:
1.
2.
Student Notebook
' "
/' /+

1/ #
@

& 4

2" D"
#
& #

& #

2"@ D"

Notes:

V2.0
Student Notebook
Uempty Unit 16. 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, 2003 Unit 16. Logging 16-1

Student Notebook

!
2

2

Notes:

V2.0
Student Notebook
Uempty

1

2@"2 4%
@@>

,,

,,,# ~
~#
Figure 16-2. Logging Concepts LX033.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.

V2.0
Student Notebook
Uempty
% ~
3

%

>>>

>>>

>
Figure 16-3. Facilities, Priorities LX033.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.

V2.0
Student Notebook
Uempty
,,
0 . ,-,$.

$

,-,$
0,. .

08.

-6

-: 8$:
0 &64
0,,$,6

-+
$+
;,
0 ! -
+ ! -
0,,$,6

-.

$$;-3
0+
;,
$$

.

036,4

°
°6
! ! $ ,,$,
6
! ! $ ,.
° .
! .,
° .

$
$§,-,
..
Figure 16-4. /etc/syslog.conf LX033.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.
In order to receive log messages on this other system, you need to allow incoming UDP
traffic on port 514, and you need to configure the syslog daemon for incoming
messages through this port. This is done by starting the syslog daemon with the -r
option. You can typically enable this in the startup configuration file
/etc/sysconfig/syslog, which is read by the startup script /etc/init.d/syslog.

V2.0
Student Notebook
Uempty

4,
©§>©
§© §
0$$6

,
,,
0
! $ ,,$,
; )41416
$$4

,
,,
$$66
.56
.¢,$ª9*¢

3,,$,-,$§,
; )441
,$$456
.¢,$ª9*¢
Figure 16-5. logger Command LX033.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
!

&
! @@>
Figure 16-6. logrotate Command LX033.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.

V2.0
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. . $.
0';6
,-;!+
;-.6
,
+-

,
.
0.,!.
$
,
$
!
.-

. . $
0.6
,,$
,
! $ +6±
-
. ))6

²
! $ ,,$,±
,
"#
6,
, ;

,-,$
,.
6
²
Figure 16-7. Sample /etc/logrotate.conf LX033.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.

V2.0
Student Notebook
Uempty
$
&

#

$
'
#+
' #+
2

~+~~
#~
# #

,
%, %

Figure 16-8. Analyzing Logfiles LX033.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. 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.
logcheck can be found on http://www.psionic.com
• logdigest is based on logcheck, and works generally the same. All configuration files
are in /etc/logdigest. It is available on SuSE, although it is not installed by default.
• 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.
logwatch is installed on a Red Hat system by default.
• logsurfer again uses positive and negative matches to browse through a logfile, but it
uses a slightly more elaborate pattern file, /etc/logsurfer.conf.
logsurfer is available on a SuSE system by default, although it is not automatically
installed.
• 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.
The “hear” in the last sentence can be taken literally: If your pager or cellphone has a
scriptable interface, then swatch can send the relevant log entries to your pager or
cellphone (SMS) automatically.

V2.0
Student Notebook
Uempty 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 or disabled
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.

Student Notebook

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.

V2.0
Student Notebook
Uempty
' "
'-+ 4

Notes:

Student Notebook

V2.0
Student Notebook
Uempty Unit 17. 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, 2003 Unit 17. Printers 17-1

Student Notebook

.

"

.

.

1
.
/
.
Notes:

V2.0
Student Notebook
Uempty
' ~ ~
¡ ¡
*%* **
Figure 17-2. Users, Printer Queues, Printers LX033.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
"

!

! #

E

>
#

# % 5%
Figure 17-3. Printing Overview LX033.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

V2.0
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
'
@
+
$!((?)
¯
¯

- 4E "
$

5
2 4
!2 '! 2 4 +
!

5 "'" +
2 4 $
3
34
2-"
Figure 17-4. Common Printing Subsystems LX033.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 was used briefly 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
Hat for instance has started shipping CUPS in version 7.3, and made it the default in
version 9.

V2.0
Student Notebook
Uempty
"& "
2 4#

$ #
@
.

#
?< .

@@

& @@>.#@@>

4

5%

%
Figure 17-5. BSD Printing Subsystem LX033.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

Student Notebook
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.

V2.0
Student Notebook
Uempty
!3 4 5

5

.%

/

.
/# .
"

>
>.#

!
@@
>
@@
>

@@

/5-! ¨3"$3!%
Figure 17-6. LPR Next Generation (LPRng) LX033.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).

Student Notebook
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.

V2.0
Student Notebook
Uempty
'
_ " 4'"5
!

2-"

#

!
-%' "+
! '%
+

#%

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

#

#

@@>
>
Figure 17-7. Common UNIX Printing System (CUPS) LX033.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.

Student Notebook
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.

V2.0
Student Notebook
Uempty
'"#
!
!
5%

!
' +
!2 ,"

5 '
>>>+
1 '

>>>+
5%
%

Figure 17-8. CUPS Overview LX033.0
Notes:
The visual shows an overview of CUPS. Important to note is that CUPS can be configured
using several methods, and that CUPS allows several frontends to be used for submitting
print jobs.

Student Notebook

,,

#

06,
6

06,
6

!
Figure 17-9. Printer Classes LX033.0
Notes:
Before covering the configuration of CUPS, we also need to cover “printer classes”. A
“printer class” is a group of multiple more-or-less identical printers. When a user submits a
job to a printer class instead of to an individual printer, the print job will be printed using the
printer in that class that happens to be free.
Printer classes thus allow you to put multiple, inexpensive printers next to each other and
get the same performance as a single, more expensive printer. And you will get
redundancy on top of it too.
Obviously, the more the printers are alike, the easier it is to administer a printer class. And
obviously users will also appreciate the fact that you put all printers in the same location.

V2.0
Student Notebook
Uempty
'" #
!2

"

,

, /'+
, ! 2,
,# #'2$"+
,3 3
,

, $ #

Figure 17-10. CUPS Configuration with lpadmin LX033.0
Notes:
The first of the three CUPS administration methods is through the command-line tool
lpadmin. It allows you to add and remove printers, and to manage printer classes.
When adding a printer, you need to specify what printer model you have. In order to obtain
the list of supported models, use the command poll_ppd_base -a, and pick the printer you
need.
The printer device is a URI (Uniform Resource Identifier). Some examples of URIs are:
• file:/dev/lp0
• http://hostname:631/ipp/port1
• lpd://hostname/queue
• smb://hostname/sharename

Student Notebook
'" # #
22$
@@# ;<(
Figure 17-11. CUPS Configuration with a Browser LX033.0
Notes:
CUPS is usually configured through a browser, connecting to the cupsd daemon at port
631. This gives an easy to use interface for performing the most common management
tasks.
Note that cupsd, by default, only allows connections from localhost (127.0.0.1).

V2.0
Student Notebook
Uempty
'" #

03

!

Figure 17-12. CUPS Configuration with kprinter LX033.0
Notes:
The third way of configuring CUPS is through its built-in API. An API (Application
Programmers Interface) allows an application programmer to build its own tools, and
communicate with the cupsd daemon using a standard interface.
The most commonly used tool for configuring CUPS through this API is kprinter, which is
the default printer dialog for all KDE applications. It was originally written only to provide an
interface to submit jobs, but has later been extended to also allow configuration of printers.
It is expected that more tools will emerge in the future that make use of the CUPS API for
job submission and printer configuration.

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.

V2.0
Student Notebook
Uempty
' "

#

%
4

5
$
!2
!

Notes:

Student Notebook

V2.0
Student Notebook
Uempty Unit 18. 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, 2003 Unit 18. Troubleshooting 18-1

Student Notebook

2
Notes:

V2.0
Student Notebook
Uempty
?
" 4

$.

0

0

0
#
34

2

$
"
-

Figure 18-2. Troubleshooting LX033.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.

V2.0
Student Notebook
Uempty

$'

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

C
4
!%
!

!%
Figure 18-3. Identifying the Problem LX033.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).
If you’re in a situation where multiple system administrators manage the same system(s),
then it might be a good idea to start keeping change documentation for each system. This
will generally at least provide hints as to what has changed.

Student Notebook
It might be useful to compare the actual situation with a working reference system, for
instance your own laptop running Linux.
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.

V2.0
Student Notebook
Uempty
~~
~

' + '+

%
2

2

$.
4

#

.
'
+
2

Figure 18-4. strace, ltrace, ldd LX033.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 which 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.
ldd is a program which shows you what shared libraries are used by a program, and where
these shared libraries reside. Shared libraries are libraries of code which are shared
(hence their name) by a number of programs. They typically reside in /lib or /usr/lib, and
can be updated independently of the program itself. The /etc/ld.so.conf file lists all the
directories (except for /lib and /usr/lib) which contain shared libraries, and the ldconfig
command reads all these directories, updates any symbolic links and then writes the cache
file /etc/ld.so.cache, which is then used by the runtime linker, ld.so. ld.so is typically
automatically invoked by a program that uses shared libraries.
On a well-designed distribution, shared libraries should all be installed correctly due to
RPM’s dependency mechanism. Shared library problems typically only occur when this

Student Notebook
mechanism is bypassed, when software is installed manually, or when the shared libraries
themselves are upgraded incorrectly.

V2.0
Student Notebook
Uempty
&

@

#

#&
>>>
" % #
*
* #
**

©!,®§

"

!

.
#

# +"+
Figure 18-5. Core Dumps LX033.0
Notes:
Due to programming or compilation errors, programs may misbehave in certain ways:
• They may try to access memory outside their assigned memory area
• They may try to perform illegal instructions. For instance, a program might try to run a
Pentium-III specific instruction on a 80386.
• They may try to divide by zero.
In most cases, the kernel will detect this behavior1, interrupt the program and dump the
current state of the program to a “core file”. This file is usually called “core” and may be
several megabytes in size.
It is also possible to force the creation of a core dump by sending the program the
SIGQUIT signal. This is usually done with <Ctrl-\>. Note however that it is possible for the
programmer to write a signal handler that assigns a different meaning to this signal.
1 In fact, it’s usually the CPU that detects these illegal instructions. The CPU will then suspend the program and start the error handler of
the kernel.

Student Notebook
This core file can then be used by the programmer to figure out what went wrong in his/her
program. For this, the programmer will typically use a debugger such as gdb to read the
core file. For other users, a core file is normally not interesting and can safely be deleted. In
fact, most system administrators will run a cron job which deletes all core files older than
three days automatically.
If you don’t want core dumps to be saved, you can set the maximum size of them to zero
with the command ulimit -S -u 0 or ulimit -H -u 0. With the -S option, you are setting a soft
limit which can be increased later on, and with the -H option you are setting a hard limit
which cannot be increased. Most distributions will set a soft core dump limit of zero by
default.

V2.0
Student Notebook
Uempty
%!
4
#

!

5

5 @
%

, ,
5
Figure 18-6. Fixing the Problem LX033.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 (kernel image, initrd), 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

Student Notebook
- 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.
On a Red Hat system, the single user mode does not prompt for the root password.
Therefore, it can be used to recover the root password if that was lost. A SuSE system
does require the root password before booting in single user mode, and can thus not be
used to recover the root password.
You can also use a boot parameter such as init=/bin/bash or init=/bin/sh. This uses
/bin/bash or /bin/sh as first program to start, instead of /sbin/init, and thus gives you a
shell prompt immediately. The only disadvantage of this, compared to the single user
mode, is that your boot scripts have not yet been executed. This means that only the
root filesystem is mounted, read only. Before you can do anything useful you will
probably have to mount this read-write with the command mount -o remount,rw / and
you might also need to mount other filesystems with mount -a.
• 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.

V2.0
Student Notebook
Uempty

5 *#* !,$B/ %

! 4
2

/ @#
$ @4

#1/@$"#
$ %@

$
$

E @

#
% @%@%@

Figure 18-7. Rescue Mode LX033.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, sometimes the size of a credit card, which allow you to boot into a
rescue mode. But credit-card sized rescue CDs are a popular giveaway at trade shows as
well.
You can use these rescue CDs real easy 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.
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.

Student Notebook
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.
• Activate LVM and/or RAID subsystems.
An LVM detection can be done automatically with the vgscan command. This
automatically detects all your volume groups. You then need to activate them with the
vgchange -a y <vgname> command, after which your logical volumes are available
normally.
Activating RAID subsystems basically involves a raidstart command. This command
obviously requires your /etc/raidtab file to be intact.
• 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 cd command, but this might cause problems when you try to run
commands like lilo or rpm, because these programs use absolute pathnames, hard-coded
in configuration files. This cannot always be resolved easily.
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.2
When all filesystems are unmounted, you can reboot your system. Don't forget to take out
your boot media!
To make this easier for novice users, some rescue modes try to perform the
mknod/fdisk/fsck/mount sequence automatically. This works great if you need to recover a
root password, but may actually be a hindrance when you need to fix a partition table
problem.
2
The umount command will perform a sync automatically, but we're not taking chances here, are we?

V2.0
Student Notebook
Uempty

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.

Student Notebook
' "
4

.

##
%E
#
%

#
#

" %
4
Notes:

V2.0
Student Notebook
Uempty Unit 19. 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, 2003 Unit 19. Policies and Procedures 19-1
Student Notebook

Notes:

V2.0
Student Notebook
Uempty
$D"

"
4

(88A
4
>>>
Figure 19-2. About Your Systems LX033.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
?&
3
3
Figure 19-3. The Dilemma LX033.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.

V2.0
Student Notebook
Uempty

,,

4
#
4
#
4
#

"

# "!
"
* *

2

Figure 19-4. Policies LX033.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
'

%
4

#@

#

#
¡

,

4

2

2
4

Figure 19-5. User Policy LX033.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.
• How users can obtain support: via telephone, e-mail or personal contact, and when this
support is available.

V2.0
Student Notebook
Uempty • 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?
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
$
4

3 #
!
#

#
B E

#

'>>
#+

4

Figure 19-6. Administrator Policy LX033.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.

V2.0
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
"
#

#

%
#

&

$

#>
Figure 19-7. Security Policy LX033.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.

V2.0
Student Notebook
Uempty
;

%
%
#
$
#

!

@ # % @#
@ #
@ #

5%

$@

2

# ,
Figure 19-8. Procedure Handbook LX033.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
"

!
##
/
/
/

@ @

Figure 19-9. Management of System Management LX033.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

V2.0
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?
If possible and practical, test disaster recovery procedures. In most cases however,
disaster recovery cannot be tested due to the sheer costs involved in renting floor
space, equipment and so forth.
• 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

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.

V2.0
Student Notebook
Uempty
' "
#

&
!
# "!E

* *

%
% %

Notes:
Student Notebook

V2.0
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 server and controls the hardware (graphical adapter,
monitor, mouse, keyboard).
© Copyright IBM Corp. 2001, 2003 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. False
2. /dev/random is blocking: it does not generate more random data
when the entropy pool runs out. /dev/urandom is non-blocking: it
switches to pseudo-random data once the entropy pool runs out.
3. /sbin/hotplug
Unit 8
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 9
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 10
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.
A-2 Linux System Administration I © Copyright IBM Corp. 2001, 2003

V2.0
Student Notebook
AP 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
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 11
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 12
1. crontab -l
2. b
3. /etc/cron.deny and /etc/cron.allow
/etc/at.deny and /etc/at.allow
Unit 13
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
© Copyright IBM Corp. 2001, 2003 Appendix A. Checkpoint Solutions A-3

Student Notebook
3. False
4. True
5. Yesterday evening and you checked it this morning.
Unit 14
1. b
2. In /etc/shadow.
Unit 15
1. Display a welcome message to users logging in remotely
2. c, e
Unit 16
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 17
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 18
1. False
2. d
3. mknod, fdisk, fsck, mount, chroot, fix the problem, exit, sync,
umount, reboot
Unit 19
1. False
2. b
3. Security, ease of use and cost.
A-4 Linux System Administration I © Copyright IBM Corp. 2001, 2003

V2.0
Student Notebook
AP Appendix B. Certification Information

As mentioned in this course, Linux is not a product which is owned by a single company.
Instead, it is developed by a loose team of volunteers on the Internet. As such, there is no
"natural" body responsible for Linux certification. At this moment, at least four organizations
have tried to fill this void and have come up with their own Linux certification program. IBM
supports three of these organizations:
• The Linux Professional Institute (http://www.lpi.org) is an organization run by
volunteers with the sole purpose of implementing a vendor-neutral certification program
for Linux. They are sponsored by a number of Linux-related companies, among which
IBM. The certification tests are delivered by VUE (Virtual University Enterprises)
(http://www.vue.com). LPI aims to implement three levels of certification, of which the
first two levels are currently ready.
UnitedLinux (the consortium of Linux distributors SuSE, SCO, TurboLinux and
Conectiva, http://www.unitedlinux.com) has announced a UnitedLinux certification,
which will be an extension of the LPI certification.
• CompTIA (http://www.comptia.org) is the organization that has, in the past, already
developed a number of certifications that are aimed mostly at helpdesk personnel and
hardware engineers. Recently CompTIA introduced the Linux+ exam, which is aimed
at Linux Professionals with 6 months of experience with Linux. CompTIA tests are also
delivered by VUE, and by Prometric (http://www.prometric.com).
• Red Hat (http://www.redhat.com) is the distributor of Red Hat Linux, one of the leading
commercial Linux distributions. As part of their service organization they have
developed their own education leading to the Red Hat Certified Technician and Red
Hat Certified Engineer exams. In contrast to the other Linux exams, the RHCT and
RHCE exams are performance based, which means that the examinee takes place
behind an actual Red Hat Linux system and needs to demonstrate his/her skills on this
system. The practical components of the RHCT exam takes about 2.5 hours, while the
practical component of the RHCE exam take about five hours.
For all three certification programs, the support of IBM extends to the following:
1. Involvement and/or active support in developing the certification program, the exam
objectives and test questions.
2. Where appropriate: sponsoring the certification program.
3. Developing courseware and teaching courses to prepare students for certification, and
where possible certifying this course material for the exams involved.
4. Exam delivery.
© Copyright IBM Corp. 2001, 2003 Appendix B. Certification Information B-1

Student Notebook
IBM IT Education Services Courseware

IBM IT Education Services started developing courseware for Linux at the end of 1998,
when no certification programs for Linux existed. The Linux curriculum was heavily
modeled after the AIX curriculum, but has changed since to reflect the different ways Linux
and AIX are being used today. IBM's Linux course material is not tied to any particular
distribution, and is also not tied to any particular certification.
The total curriculum consists of more than fifteen courses that cover the Linux Operating
System, and an even larger number of courses that cover IBM middleware that runs on
Linux (such as DB2, MQ Series, Lotus Domino and so forth) and IBM hardware. For the
purpose of certification though, only seven courses are important:
The LX02 (Linux Power User) is the entry course in the IBM/Linux curriculum. Its aim is to
teach a Linux novice to install and configure Linux so that he/she is able to run Linux on
his/her personal workstation or home system in an environment that is mostly based on
MS-Windows.
The LX03 (Linux System Administration I: Implementation) is the main system
administration course. Its aim is to teach a Linux user the techniques and practices used in
installing, configuring, running and maintaining a Linux-based server.
The LX07 (Linux Network Administration I: TCP/IP and TCP/IP Services) is the main
network administration course. Its aim is to teach a Linux system administrator how to
configure TCP/IP and various TCP/IP services that run on Linux.
The LX22 (Linux Perl Programming) is the course that covers Perl programming.
The LX23 (Linux Bash Programming) is the course that covers Bash shell programming
and the various programs that are typically used in shell programs, such as grep, awk and
sed.
The LX24 (Linux Network Administration II: Network Security and Firewalls) covers
the configuration of a full-function firewall under Linux. As such, it also covers a number of
security aspects of Linux that are not particularly related to firewalls, but apply to any
networked system.
The LX25 (Linux as a Web server - Apache) is the course which covers Apache, the most
commonly used web server on Linux and other UNIX platforms.
The LX26 (Linux integration with Windows - Samba) is the course which covers Samba,
the product which emulates a networked Windows NT server to the network.
All these courses are available from IBM IT Education Services and selected business
partners (pricing and availability may differ from country to country). For information on
pricing and scheduling, contact your local IBM IT Education Services representative.
IBM IT Education Services has developed these courses so that they can be taken in a
logical order. Furthermore, the organization of topics into courses is such that at the end of
a course, a student is able to fully grasp a topic, and is able to apply this successfully on his
Linux system(s).
B-2 Linux System Administration I © Copyright IBM Corp. 2001, 2003

V2.0
Student Notebook
AP From Education to Certification

IBM’s arrangements of topics into IBM’s Linux courses is not always consistent with the
requirements of the supported certifications. This leads to a problem when determining
which courses are needed for which certification. A certain test might require "installation
and basic configuration" of a product. This is covered by a certain IBM/Linux course, but
that very same course also covers "advanced configuration", which might be the subject of
an entirely different test.
As an example, IBM has one, two-day course about Samba (the LX26), which fully covers
the whole Samba product and its possibilities. Samba knowledge is tested by the LPI in two
places though: Test 102 (topic 1.13, objective 4) requires the examinee to "install and
configure Samba using the included GUI tools or direct edit of the /etc/smb.conf file" (which
is covered in the first two units of the LX26), while test 201 (topic 2.9, objective 1) requires
that "the candidate should be able to set up a Samba server for various clients, including
setting up a login script and setting up and nmbd WINS server" (which is the end objective
of the LX26).
This problem is too fundamental to solve by simply changing or rearranging the course
material, apart from the fact that we think that it is not desirable to specifically write courses
for certification. One of the purposes of this attachment is therefore to identify the areas
where IBM's course material does not match with certification objectives.
© Copyright IBM Corp. 2001, 2003 Appendix B. Certification Information B-3

Student Notebook
Education/Certification Matrix
The following table lists the required and recommended courses for each of the supported
certification programs:
CompTIA LPI Red Hat
Course
Linux+ Test 101 Test 102 Test 201 Test 202 RHCT RHCE
LX02 Required Required Required Required Required Required Required
LX03 Required Required Required Required Required Required Required
LX07 Recomm. Required Required Required Required
LX22 Recomm.
LX23 Recomm. Recomm.
LX24 Required Recomm.
LX25 Recomm. Recomm. Required Recomm.
LX26 Recomm. Required Recomm.
Remarks to the table:
1. Required means: the subjects covered in this course are essential knowledge to pass
the exam.
Recommended means that a small portion of the exam (less than 5%) is covered in the
course listed. It is possible to pass the exam without this knowledge. Students do so
however at their own risk and should compare their knowledge with the exam
objectives.
2. CompTIA Linux+ also requires intimate knowledge of PC hardware in general (Domain
7) which accounts for 19% of the exam. This includes knowledge of the BIOS, IRQs, I/O
ports, DMA, ATA devices, SCSI devices, IEEE 1394 devices, PCMCIA devices, ISA
devices, PCI devices, APM and the ability to configure and replace them, were
applicable. This part of the exam is not related to Linux and thus not covered in any of
IBM’s Linux courses. CompTIA’s own education (and other education) that leads to
CompTIA A+ certification may be used to obtain this knowledge.
3. ProCert (http://www.procert.com) has certified these courses as appropriate course
material for preparing for LPI certification tests. This certification is only valid if all
courses, including the courses that are listed here as “recommended” are taken before
attempting an LPI certification test.
4. IBM IT Education Services is a Red Hat Authorized Training Partner and as such
allowed to teach the Red Hat courses RH033, RH133 and RH253. These courses can
be used as an alternative to LX02, LX03 and LX07, respectively, to prepare for
RHCT/RHCE certification. They cannot be used for other certifications though, and
these courses are not scheduled in all countries.
B-4 Linux System Administration I © Copyright IBM Corp. 2001, 2003

V2.0
Student Notebook
IX Index
Symbols /etc/shadow 14-8, 14-10, 14-15
$DISPLAY 6-17 /etc/skel 14-11
$PRINTER 17-7 /etc/sysctl.conf 7-27
$RPM_BUILD_DIR 5-19 /etc/syslog.conf 16-7
$RPM_SOURCE_DIR 5-19 /etc/syslogd.conf 16-4
%packages 2-6 /etc/X11/XF86Config 6-9
%post 2-6 /etc/X11/XF86Config-4 6-9
%pre 2-7 /proc/lvm 9-24
.config 7-8, 7-14 /proc/sys 7-27
.hushlogin 14-19 /sbin/hotplug 8-13
.rpmorig file 5-7 /sbin/init 7-23
.rpmsave file 5-7 /var/log/lastlog 15-23
.Xauthority 6-18 /var/log/messages 15-23, 18-5
/boot 3-9 /var/log/secure 15-23
/boot/grub/grub.conf 3-13 /var/log/wtmp 15-23
/boot/grub/menu.lst 3-13 /var/run/umtp 15-23
/dev/dsp 8-12
/dev/lp0 8-11 A
/dev/null 8-5 Access Control List 10-14
/dev/psaux 8-11 ACL. See Access Control List
/dev/random 8-6 adduser 14-10
/dev/sda 9-7 administrator policy 19-8
/dev/shm 10-30 air conditioning 1-10
/dev/ttyS0 8-7 Air conditioning capacity 1-11
/dev/urandom 8-6 air fans 1-14
/dev/zero 8-5 AIX 9-24, 10-28
/etc/anacrontab 12-10, 12-12 Alien 5-26
/etc/at.allow 12-16 alsaconf 8-12
/etc/at.deny 12-16 anaconda-ks.cfg 2-8
/etc/cron.allow 12-5 anacron 12-10
/etc/cron.deny 12-5 apt-get 5-25
/etc/crontab 12-9 at 12-13
/etc/fstab 10-18, 10-20, 10-22, 10-30, 10-33 -d option 12-16
/etc/group 14-17 -l option 12-16
/etc/gshadow 14-8, 14-17 ATAPI 9-7
/etc/init.d/boot 3-20 atd 12-13
/etc/init.d/rc 3-21 atime 10-9
/etc/inittab 3-19, 3-20, 3-27, 7-23 atq 12-16
/etc/isapnp.conf 7-21 atrm 12-16
/etc/issue 14-18 authconfig 4-5, 15-10
/etc/ld.so.conf 18-7 authentication 15-3
/etc/lilo.conf 3-7, 3-8 authorization 15-3
/etc/login.defs 14-9, 14-10
/etc/logrotate.conf 16-12
/etc/modules.conf 7-25 B
/etc/motd 14-19 B+ trees 10-15, 10-28
/etc/nologin 15-9 bash 3-26
/etc/passwd 14-14 Basic Input Output System 3-4
/etc/rc.d/rc 3-21 batch 12-15
/etc/rc.d/rc.sysinit 3-20 binary RPM 5-15
/etc/securetty 15-8 binary trees 10-15
/etc/security 15-11
© Copyright IBM Corp. 2001, 2003 Index X-1

Student Notebook
BIOS. See Basic Input Output System -display 6-17

block device 8-3, 9-3 dmesg 3-16, 7-16, 9-7
boot device 3-4 double indirect block 10-9
boot loader 3-5, 7-4 dpkg 5-25
British Thermal Units 1-11 dselect 5-25
dump 10-19, 13-10, 13-15
DVD 2-3
C
carbon monoxide 1-12
CardBus 8-13 E
cardmgr 8-13 e2label 10-26
cat 7-27 echo 7-27
CD-ROM 2-3 edquota 10-34
character device 8-3 EEPROM 3-4
chattr 10-26 E-IDE 9-6
chkconfig 3-24 electric power 1-8
chmod 15-16 ext2 10-6, 10-25
chroot 18-14 ext3 3-17, 10-6, 10-25
circuit breakers 1-8 extended partition 9-8
cleaning 1-14 extendfs 10-28
computer room 1-4
console 8-3
convertquota 10-32 F
core dump 18-9 fdformat 9-5
core file 18-9 fdisk 3-5, 9-10, 18-14
cpio 13-10, 13-14 file 10-3
Cron 12-4 filesystem 10-3
crond 12-4 fips 9-10
crontab 12-4, 12-8 fire detection 1-12
-e option 12-8 fire suppression 1-12
-l option 12-8 font server 6-23
-r option 12-8 free 11-8
crypt 14-15 freeramdisk 9-11
ctime 10-9 fsck 10-15, 10-19, 10-23, 18-14
Ctrl-Alt-Backspace 6-13 -y option 10-24
Ctrl-Alt-Delete 3-21, 3-27 full backup 13-3, 13-5
CUPS 17-6, 17-11 fuses 1-8
cupsd 17-16, 17-17
curses 4-3
G
galeon 4-10
D gdb 18-10
data backup 13-3, 13-6 gdm 3-21, 6-14, 6-21
Data block 10-7 General Public Licenc 5-3
data block 10-11 getty 3-21
dd 13-10, 13-18 ghostscript 17-7
Debian 5-25 GID 14-3, 14-14
Debian packages 5-25 gnorpm 5-22
debugfs 10-25 GNU 5-3
debugreiserfs 10-27 GPL. See General Public License
depmod 7-17, 7-25 grace period 10-31
dictionary attack 14-8, 15-9 GRand Unified Boot Loader 3-10
diesel generator 1-9 grep 16-13
diff 7-7 -v option 16-13
directory 10-11 ground 1-13
Disk Druid 9-10 Group ID 14-3
X-2 Linux System Administration I © Copyright IBM Corp. 2001, 2003

Student Notebook
grub 3-11 konqueror 4-10

GRUB. See Grand Unified Boot Loader kpackage 5-22
grub-install 3-11 kprint 17-11
kprinter 17-17
ks.cfg file 2-6
H ksconfig 2-7
Hard disks 9-6 KVM switches 8-9
Hard limit 10-31
Hardware RAID 9-29
Hardware-HOWTO 3-15 L
hexdump 8-6 Labels 10-15
hotplug 8-13 last 15-23
hot-pluggable devices 8-13 lastlog 15-23
humidity 1-10 ldconfig 18-7
Hummingbird eXceed 6-6 ldd 18-7
Hurd 3-6 lilo 3-7, 18-14
LILO. See Linux Loader
links 4-10
I Linux Documentation Project 18-6
IBM MWave 8-8 Linux Loader 3-5, 3-7
IDE 9-6 linuxrc 3-18
immutable 10-15 logcheck 16-14
incremental backup 13-3, 13-6 logdigest 16-14
Indirect block 10-7 logger 16-9
indirect block 10-9 logical partition 9-8
init 3-19, 3-21, 3-23, 6-14, 7-23 Logical Volume Management 9-13
Initial RAM Disk 3-17 Logical Volumes 9-14
Initial Root Disk 3-17 logrotate 16-10, 16-12
initial root disk 7-10 logsurfer 16-14
initrd 7-15, 9-24, 9-34 logwatch 16-14
Inode 10-7 lokkit 4-5
inode 10-9, 10-11 loop device 9-12
inode block 10-7 lp 17-11
insmod 7-17 lpadmin 17-15
internal modems 8-8 lpc 17-8
Internet Explorer 4-10 lpd 17-7
IPP 17-6 lpq 17-8
isapnp 7-21 lpr 17-4, 17-7, 17-11
ISDN cards 8-8 -P option 17-7
ISO images 9-12 lprm 17-8
iso9660 10-17 LPRng 17-6, 17-9
ls
-l option 8-4
J lsdev 8-14
JFS 3-17, 10-6, 10-28
lseek 10-15
Joules 1-11
lsmod 7-17
Journaling 10-14
ltrace 18-7
Lucent winmodem 8-8
K lvcreate 9-16, 9-19
kdm 3-21, 6-14, 6-21 lvdisplay 9-19
kernel 3-15, 7-3 lvextend 9-22
kernel modules 3-17, 7-10 LVM 3-17
Kernel sources 7-5 LVM metadata 9-23
kerneld 7-18 LVM. See Logical Volume Management
Kickstart 2-6 lvm-mod 9-24
klogd daemon 16-4 lvremove 9-19, 9-22

Student Notebook
LX07 8-7 network install server 2-3, 2-4

lynx 4-10 network installation 2-3
null device 8-3
null-modem cable 8-9
M
make bzImage 7-12
make bzlilo 7-13 O
make clean 7-12 opera 4-10
make config 7-8 OS/2 10-28
make dep 7-12
make menuconfig 7-8
make modules 7-13 P
make modules_install 7-14 PAE. See Processor Address Extension
make mrproper 7-5 PAM modules 15-11
make oldconfig 7-9 PAM. See Pluggable Authentication Modules
make xconfig 7-8 parted 9-10
make zlilo 7-13 partition table 3-5, 9-10
man 4-4 partitioning 9-8
Master Boot Record 3-4, 3-5 PartitionMagic 9-10
master boot record 9-8 passwd 14-13, 15-12
MBR. See Master Boot Record password 14-3, 15-8
MD5 14-15 password aging 14-9
Memory chips 1-13 patch 7-7
Metro-X 6-7 patch files 7-6
mgetty 8-9 Paul Vixie 12-4
mirroring 9-24 PCMCIA 8-13
mk_initrd 7-11, 7-15 permission bits 15-14
mkbootdisk 18-11 Physical Extents 9-13
mke2fs 10-16 Physical Volume 9-13
-j option 10-25 pico 18-13
mkfs 10-16 pivot_root 3-18
mkinitrd 3-9, 7-11, 7-15 Pluggable Authentication Modules 15-4
mkjfs 10-16 pnpdump 7-21
mknod 18-14 poll_ppd_base 17-15
mkpasswd 14-13 POSIX 10-30
mkraid 9-31 prefdm 3-21
mkreiserfs 10-16 primary group 14-6
mkswap 11-6 primary partitions 9-8
modinfo 7-18 printconf 4-5
modprobe 7-17, 7-25 printer class 17-14
mount 9-12, 10-17, 10-18, 15-12, 18-14 printer queue 17-3
-o option 9-12, 10-17, 10-20 pristine sources 5-4, 5-15
-t option 10-17 procedure handbook 19-11
mount point 10-4 Processor Address Extensio 11-3
mouse 8-11 procinfo 11-9
mouseconfig 4-5 protected mode 3-16
mozilla 4-10 ps 11-8
mtime 10-9 pvcreate 9-16, 9-17
multiport cards 8-7 pvdisplay 9-17
MWave 8-8 pvmove 9-17, 9-21
N Q
netconf 4-5 Quota 10-31
netscape 4-10 quota 10-36
network adapter 2-3 quotacheck 10-33

Student Notebook
quotaon 10-32, 10-33 -h option 5-7

-i option 5-6
--import option 5-14
R --nodeps option 5-7
rack-mounted 1-6 -q option 5-9
RAID 3-17 --redhatprovides option 5-11
RAID. See Redundant Array of Inexpensive Disks -U option 5-6
RAID-0 9-26 -V option 5-12
RAID-1 9-27 -v option 5-7
RAID-4 9-27 RPM Package Manager 5-3
RAID-5 9-27 RPM. See RPM Package Manager
RAID-Linear 9-26 rpmbuild 5-5, 5-20
raidstart 9-31 rpmdb 5-11
-a option 9-31 runlevel 3-19
raidtools 9-29
RAM disk 9-11
random number generator 8-3 S
rc 3-22, 3-25 script 19-8
reboot 18-14 SCSI 3-17, 9-7
Red Hat Network 5-23 SCSI ID 9-7
Red Hat Package Manager 5-3 scsi_info 9-7
redhat-config-bin 4-6 security policy 19-10
redhat-config-date 4-6 Self-Referencing Acronym 5-3
redhat-config-httpd 4-6 serial terminal 8-3
redhat-config-keyboard 4-6 serial terminals 8-9
redhat-config-kickstart 2-7, 4-6 service 3-25
redhat-config-language 4-6 Session Manager 6-14
redhat-config-mouse 4-6 setserial 8-8
redhat-config-network 4-6 setup 4-5
redhat-config-nfs 4-7 SGID 15-15, 15-16
redhat-config-packages 4-7, 5-22 shadow password suite 14-8, 14-9
redhat-config-printer 4-7 Shared Memory Filesystem 10-30
redhat-config-proc 4-7 shutdown 3-21, 3-26, 3-27
redhat-config-rootpassword 4-7 sine wave 1-9
redhat-config-samba 4-7 Single-User Mode 3-26
redhat-config-securitylevel 4-7 Smoke detectors 1-12
redhat-config-services 3-24, 4-7 snapshot 9-24
redhat-config-soundcard 4-7, 8-12 Soft limit 10-31
redhat-config-users 4-7 Software RAID 9-29
redhat-config-xfree86 4-7 sound card 8-12
Redundant Array of Inexpensive Disks 9-25 Source RPM 5-4
ReiserFS 3-17, 10-6, 10-27 spare disks 9-34
reject files 7-7 sparse files 10-15
repquota 10-36 SPEC file 5-15, 5-16, 5-17
rescue mode 18-13 %doc identifier 5-19
resize_reiserfs 10-27 files section 5-19
resize2fs 10-26 install section 5-19
restore 13-15 preamble section 5-18
rhnsd 5-23 prep section 5-19
rmmod 7-17 SRA. See Self-Referencing Acronym
rpm 5-3, 5-7, 5-20, 18-14 stand-alone 1-6
-b command 5-20 startx 6-11
-bb option 5-4 Sticky Bit 15-15
--checksig option 5-14 sticky bit 15-16
-e option 5-8 strace 18-7
-F option 5-6, 5-23 striping 9-20

Student Notebook
su 15-12, 15-19, 15-20 V

sudo 15-13, 15-21 VFS. See Virtual Filesystem Switch
SUID 15-15, 15-16 vgcfgbackup 9-23
Sun Microsystems 15-4 vgcfgrestore 9-23
Superblock 10-7 vgchange 9-18
superblock 10-8 vgcreate 9-16, 9-18
Surge Arresters 1-9 VGDA. See Volume Group Descriptor Area
swap space 9-35 vgdisplay 9-18
swapoff 11-6, 11-7 vgexport 9-18
swapon 11-6 vgextend 9-18, 9-21
swatch 16-14 vgreduce 9-21
sync 11-8, 18-14 vgremove 9-18
sysctl 7-27 vi 18-13
syslog daemon 16-3 virtual filesystem 10-4
syslogd Virtual Filesystem Switch 10-5
-r option 16-8 vmstat 11-9
syslogd daemon 16-4 Volt 1-8
System Administration Tools 4-3 Volume Group 9-13
system backup 13-3, 13-5 Volume Group Descriptor Area 9-17, 9-23
System.map 7-14
W
T wall 16-4, 16-8
tail Watt 1-8, 1-11
-f option 15-24 Webmin 4-9
tar 13-10, 13-11 Webmin installation 4-10
temperature 1-10 which 5-10
timeconfig 4-5 who 15-23
ton 1-11 window manager 6-4
toolbox 1-14 winmodems 8-8
top 11-8 write 16-4, 16-8
triple indirect block 10-10 WRQ Reflection X 6-6
tune2fs 10-25
U X
X server 6-4
UID 14-3, 14-14 X station 6-4
ulimit 18-10 X Window System 6-3
umask 15-17 xauth 6-18
umount 10-22, 18-14 xbanner 6-4
Uninterruptable Power Supplies 1-9 xcalc 6-4
UNIX socket 6-6, 16-4 xdm 3-21, 6-14, 6-20
up2date 5-23, 5-25 xedit 6-5
UPS. See Uninterruptable Power Supply xeyes 6-4
uptime 11-8 XFree86 6-7
USB 8-13 XFS 10-6
usbmodules 8-14 xfs 6-23, 6-24, 18-5
usbview 8-14 xhost 6-18
user account 14-4 Xi Graphics 6-7
user ID 14-3 xload 11-8
user policy 19-5, 19-6 xosview 11-8
User Private Groups 14-7 xpeek 10-28
useradd 14-10 xsysinfo 11-8
userdel 14-10 xterm 6-4
usermod 14-10

Student Notebook
Y
yast 3-24, 4-8, 5-11, 5-22, 8-12
Yast Online Update 5-24
YaST. See Yet another Setup Tool
yast2 4-8
Yet another Setup Tool 4-8
you 5-24

Student Notebook

V2.0
backpg
Back page
®

Sys Admin

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sys Admin

Uploaded by

Copyright:

Available Formats

V2.0.0.

Front cover

IBM Certified Course Material

July 2003 Edition

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

Certification Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

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, 2003 Contents iii

Configuring Services per Runlevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-24

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

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

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

iv Linux System Administration I © Copyright IBM Corp. 2001, 2003

TOC XFree86 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8

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

Unit 8. Character Devices, PCMCIA and USB . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

© Copyright IBM Corp. 2001, 2003 Contents v

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

Unit 10. Filesystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

vi Linux System Administration I © Copyright IBM Corp. 2001, 2003

TOC Mount Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-20

Unit 11. Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

Unit 12. Scheduling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1

Unit 13. Backup and Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-1

© Copyright IBM Corp. 2001, 2003 Contents vii

Default Backup Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-10

Unit 14. User Administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1

Unit 15. User-Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1

viii Linux System Administration I © Copyright IBM Corp. 2001, 2003

TOC Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-25

Unit 16. Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-1

Unit 17. Printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-1

Unit 18. Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-1

Unit 19. Policies and Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-1

© Copyright IBM Corp. 2001, 2003 Contents ix

Administrator Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19-8

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

Appendix B. Certification Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1

x Linux System Administration I © Copyright IBM Corp. 2001, 2003

© Copyright IBM Corp. 2001, 2003 Trademarks xi

xii Linux System Administration I © Copyright IBM Corp. 2001, 2003

pref Course Description

© Copyright IBM Corp. 2001, 2003 Course Description xiii

• Perform user administration

xiv Linux System Administration I © Copyright IBM Corp. 2001, 2003

© Copyright IBM Corp. 2001, 2003 Agenda xv

xvi Linux System Administration I © Copyright IBM Corp. 2001, 2003

pref Certification Information

Linux Professional Institute Statement

© Copyright IBM Corp. 2001, 2003 Certification Information xvii

xviii Linux System Administration I © Copyright IBM Corp. 2001, 2003

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 LX033.0

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

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

  

"  # 

Figure 1-3. Computer Room LX033.0

" #

! "

" '()*+% #

/

%& " "

/%

5

' "

/ #

2D$25"B

4% &

>>>#

!% 'B +

"B7 , @@

9@@> 7

9@@>

9* 9(7=/* * 9(7=/*